Модель ЖЦПО code-and-fix; stagewize model

Подход " кодирование-исправление" (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование системы с самого первого дня, не занимаясь сколько-либо серьезным проектированием.

Все ошибки обнаруживаются, как правило, к концу кодирования и требуют исправления через повторное кодирование.

Фактически каждый из программистов, так или иначе, применял этот подход. Практически все учебные программы пишутся в таком стиле. Следует заметить, что при использовании данного подхода затрачивается время лишь на кодирование и заказчику легко демонстрировать прогресс в разработке в строках кода.

Этот подход может быть рекомендован к использованию в двух случаях.

· Для очень маленьких проектов, которые должны завершиться разработкой демонстрационного прототипа.

· Для доказательства некоторой программной концепции.

Code and fix (Кодирование и фиксирование)

Основная идея: Прозрачная задача, затем код. Метод использовался в 50гг. (слабые ЭВМ, ненадежные, реле, электро-вакуумные приборы)

- трудность модификации и развития программного продукта

-высокая вероятность того, что функциональность программного продукта не будет совпадать с потребностями пользователя

-сложность тестирования программного продукта (испытание; цель: доказать что программный продукт – плохой, в любой программе присутствует как минимум 1 ошибка).

Stagewise model (Постадийная модель)

1.Планирование разработки

2.Разработка спецификации (Привлечь людей, поставить задачу в четком виде)

3.Кодирование

4.Параметрическое тестирование модулей (Во время тестирования отдельных модулей ошибку легче найти)

5.Тестирование сборки

6.Опытная эксплуатация (Разработчиком)

7.Оценка системы пользователем

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

Разработка спецификации – процесс создания документа, в котором однозначно описано то, что должна делать программа, а также ее характеристики, требования к ней и т.д.

Причины появления stagewize model вместо code-and-fix

1. Сложность выросла

2. Над проектом работают много людей

3. Исчерпывающее тестирование невозможно; нужно убедиться об их работе в системе, а не только отдельных частей

4. 100% правильной работы никогда не получается, всегда есть ошибки; поэтому нужен специалист, который будет это все регулировать

5. Ошибка навязывания заказчику своего мнения «полочное ПО»