|
Deliver software in time, not when ready.
Спиральная модель жизненного цикла
Любая коммерческая компания при разработке программных продуктов движется по "циклу разработки программного продукта".
Смотрим на картинку:
что мы видим?
- начинаем разработку с проектирования программы,
- пишем спецификацию (документ, в котором описаны API, цели, экономическое обоснование, поток данных программы, т.п. - т.е. продукт полностью описан на бумаге)
- дальше пишем код.
- отлаживаем.
- внедряем.
- опять анализируем. после чего повторяем весь цикл заново.
Постепенно продукт начинает выполнять свои функции.
Теперь посмотрим на цикл от Microsoft
Тоже самое:
- анализ - в результате получаем спецификацию
- проектирование - в результате спецификация / документация
- разработка - в результате имеем код
- отладка - в результате релиз
- внедрение у заказчика
- и повторяем так бесконечно
Еще один вариант - в жизненном цикле продукта предусмотрено создание прототипа. т.е. это полезно, чтобы выбить из заказчика деньги как можно раньше.
Замечания:
- Цель - выпуск новой версии продукта. Невозможно пропускать какие-то стадии, нужно проходить полный цикл стадии за стадией.
- Есть и другие модели жизненного цикла: водопадная и т.п.
Длина жизненного цикла в неделях
Начинается с "от чего зависит длина цикла?" Зависит от:
- как часто можно показывать новую версию пользователям и клиентам?
- как часто можно измерить прогресс
- как часто разработчик и заказчик могут уточнять планы
Если весь проект - три месяца, то нужно сделать хотя бы 5 циклов. Собрать 5 пачек баг-репортов.
Читайте подробнее www.informit.com
Еще раз,
когда выпускать новую версию программы?
- если прошло 30 дней,
- если исправлена 1 критическая бага
|
