Зачетный проект

Выполнил Трушин Никита

Группа 11-910
 Модель Waterfall
План:
1. Закупаем все инструменты
2. Так как мы работаем по каскадной модели, то сначала пишем требования, затем
дизайн документ.
3. После проверки всех двух вышеперечисленных артефактов переходим к коду.
4. Делаем код.
5. После создания, делаем систему тестов, исправляем
6. Чиним код, интегрируем
7. Сдаем заказчику

Дополнительные параметры:

1. Увы, полностью отыграть каскадную модель у нас не получится, так как заказчик
постоянно присылает новые требования. Так что будем определять одного
сотрудника(Andre, так как он самый опытный) на доработку и исправление
документа требований и дизайна.

Шаги разработки:
1. Первым делом закупаем все инструменты, для того, чтобы уменьшить количество
ошибок в наших артефактах.

2. Переходим к созданию требований. На него определяем трех человек, с

наибольшим стажем в графе RequirementsExperience. В нашем случае это Andre (10
лет), Anita (8 лет) и Calvin (9 лет). Начинаем разработку с помощью инструмента,
 который мы купили.

3. Требования созданы, переходим к проверке. На ревью документа определяем всех

сотрудников, для ускорения процесса.
4. По окончании проверки, определяем тех же людей, кто создавал требования на их
исправления. У нас набралось 52 ошибки. Начинаем исправлять.
5. Исправления сделаны, следовательно, этап документирования пройден, и мы
больше не принимаем требования от заказчика. На создание требований ушло 410
ед. игрового времени. Переходим к созданию дизайн документа. Как и в случае с
требованиями, определяем трёх людей с наибольшим стажем в графе
DesignExperience. Это опять Andre (11 лет), Anita(5 лет) и Emily (5 лет). Так же
используем купленный нами инструмент.
6. Разработка дизайн документа завершена, переходим к проверке. Опять определяем
весь персонал, для ускорения работы.

7. Проверка завершена, найдено 60 ошибок. По аналогии с требованиями, определяем

тех, кто создавал документ на исправление ошибок. После исправления ошибок,
этап проектирования можно считать завершенным, на него ушло 493 ед. игрового
времени. Переходим к написанию кода. Выбираем людей с наибольшим стажем,
без негативных характеристик в графе CodingExperience – Calvin (6 лет), Emily (6
 лет), Pedro (8 лет). Естественно, используем инструмент.

8. По окончании создания кода всем скопом проверяем написанное.

9. После проверки кода переходим к исправлению ошибок в нём и одновременно с

этим к написанию системы тестов. На исправление ошибок определим Andre,
 Emily и Calvin, на написание тестов – Pedro, Mimi, Anita. Используем инструменты.

10. Исправление кода завершилось раньше, определяем тех же людей на интеграцию

кода.
11. Код интегрирован, определяем Andre на доработку системы тестов.

12. Переходим к проверке системы тестов, на неё определяем всех.

13. После проверки исправляем систему, поручаем это Andre, Emily, Mimi, Pedro.

14. После исправлений, проводит тест системы. Этим займутся Andre, Pedro, Mimi.
15. Была обнаружена 61 ошибка. Исправлением в коде займутся Andre, Pedro, Calvin,
Emily.

16. После окончательного исправления ошибок, сдаем проект заказчику.

Итоги:
1. Мы выбились из срока на 123 ед. игрового времени и из бюджета на 31 тысячу
долларов. Это можно объяснить тем, что заказчик постоянно присылает новые
требования, которые игнорировать нельзя (подтверждено эмпирическим путем).
Отсюда и идут дополнительные затраты на изменение документа
требований/дизайна/кода.
2. Отыгрывать каскадную модель в данном симуляторе тоже проблематично, опять
же из-за новых требований.
3. На мой взгляд, в срок уложиться можно, если приниматься за каждый следующий
этап, не заканчивая предыдущий, но, это противоречит каскадной модели.
 Модель быстрого прототипирования
План:
1. Основной упор делаем на цикл создание части прототипа -> представление заказчику
-> доработка документа требований
2. Дизайном занимаемся после получения большинства требований, так как ошибки из
требований переходят в ошибки дизайна, и после каждой итерации цикла нам
приходится дополнительно тратить время на доработку дизайна.
3. Выбираем одинаковые языки для прототипирования и имплементации, для ускорения
последней.
4. Сдачу прототипов стоит выполнять тогда, когда значение EvaluatedPercent равняется
примерно 70.

Дополнительные параметры:
1. Эмпирическим путем был выбран язык Java. Для быстрой имплементации кода. У
VisualBasic быстрое создание прототипа, но на этапе имплементации он дает
значительный процент ошибок. Поэтому Java – он средний по скорости создания
прототипа, но ошибок будет меньше в итоговой сборке.
2. В любой момент времени может выполняться только одно действие всеми
сотрудниками, в отличие от Waterfall. Поэтому в отчете не будут указываться
имена/распределение обязанностей.

Шаги разработки:
1. Первым делом выбираем язык разработки и имплементации. Как уже было сказано
выше, в нашем случае это Java.
2. Собираем начальные требования у заказчика

3. После того как стартовые требования были собраны, начинаем делать документ
требований.

4. Посмотрим на текущий документ требований: в нём 28% ошибок, что сигнализирует о

том, что это не совсем то, о чем просит заказчик. Но мы в любом случае переходим к
 созданию прототипа.

5. После того, как начальные требование внедрены в прототип на 40 процентов, идем к

заказкчику, за дополнительными требованиями.
6. Заказчит дал нам новых требований, поэтому начинаем дорабатывать наш документ
требований.

7. После доработки снова делаем прототип. Как можно заметить, в требованиях

снизился процент ошибки.
8. После того, как процент оценки заказчиком снизился до 70, отправляем прототип ему.
9. После оценки снова переходим к доработке требований, так как снова появились
добавочные требования
10. Создаем прототип.
11. Когда значение EvaluatedPercent достигло 70% отправляем заказчику
12. После оценки заказчиком снова переходим к документу требований. Как только
закончим – идем разрабатывать прототип.
13. По достижении показателя PercentEvaluated 70 отсылаем прототип заказчику
14. После проверки доделываем требования и переходим к созданию дизайна системы.
15. Дизайн готов, переходим к имплементации системы.
16. Имплементация завершена, сдаем проект заказчику.

17. Итоговый результат – 88 баллов.

Итоги:
1. Проект был выполнен раньше срока на 48 ед. игрового времени – его можно было бы
потратить на доработку прототипов и согласование требований, дабы больше
удовлетворять пожеланиям заказчика
2. В данной «итерации» разработки удалось приблизиться к идеальному отношению по
времени разработки прототипа и отправки заказчику с доработкой требований.
3. Нужно уметь находить хорошее соотношение времени, затраченного на разработку
прототипа, так как если мы будем делать мало – то больше времени уйдет на
переговоры, нежели на разработку, а если будем делать много – то придется долго
дорабатывать и перерабатывать проект, дабы удовлетворить требования заказчика.
 Эволюционная модель
План:
1. Первым делом поручаем сотрудникам параллельно проанализировать риски,
сложность, составить требования и дизайн для каждого модуля
2. Начинаем имплементировать, так же параллельно.
3. Затем интегрировать, параллельно
4. После этого мы отправляем те модули, которые готовы и соответствуют
требованиям заказчика – параметр Total Satisfaction
5. На изменение требований заказчика реагируем быстро и определяем людей по
необходимости – если упал параметр Accuracy, то даем задачу Evolve Code
сотрудникам, после этого перекидываем на Integrate

Этапы разработки:
1. Анализируем риски на каждом из модулей, когда кто-то завершает работу, даем
ему анализ сложности, затем требования и дизайн.
2. Риски проанализированы, кто-то уже начал анализировать сложность.

3. Сложность модулей проанализирована, кто-то уже составляет требования, кто-то

ещё только начинает. Пока никак не реагируем на изменения в проекте от
заказчика.
4. Требования составлены, переходим к дизайну.

5. Дизайн готов, имплементируем.

6. По окончании имплементации, начинаем интегрировать код. Один модуль у нас
уже заинтегрирован, отправляем его заказчику

7. После этого, начинаем менять код, дабы повысить параметр Total Satisfaction

8. Это весь примерный план действий на выполнение проекта. Когда некоторые

модули готовы к сдаче – сдаем их, смотрим на результат, дорабатываем. При
изменении проекта заказчиком – перекидываем силы на тот, модуль, который
«пострадал» от правок больше всего. Т.е. снова Evolve Code, Integrate Насколько я
понял – ограничения по графику у нас нет, поэтому весь проект сдаем тогда, когда
показатель Total Satisfaction будет около 100 на каждом модуле. Время от времени
заказчик будет присылать настолько много требований, что проще будет начать
сначала разрабатывать проект «Start over!». Но, в моем случае мне скорее всего
повезло, потому что заказчик не сыпал изменениями как умалишенный. Поэтому,
 вот мой результат:

Итоги:
1. При эволюционной модели сроки разработки сильно зависят от частоты изменений
в проекте. Да, такая модель более приспособлена под частые изменения, но если
постоянно откатывать прогресс – разработка затянется надолго.
2. Необходимо часто выкладывать билды, дабы иметь на руках незначительные
изменения, а не сидеть и ждать, когда заказчик обнулит полностью проект.