Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие модели ЖЦ:
- каскадная (водопадная) модель (70-85 г.г.);
- спиральная модель (86-90 г.г.).
- инкрементальная модель
Инкрементальная модель
Когда число итераций возрастает настолько, что каждая новая итерация предоставляет слишком малое количество новых возможностей по сравнению с предыдущей, то такую модель процесса разработки называют инкрементальной разработкой.
Например, Кукумано и Сэлби [21] подготовили доклад по процессу, используемому в некоторых отделениях корпорации Microsoft, где обновления программного кода и документации предоставляются ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимo иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации (рис. 1.10). Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т.д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит лучше всего, если следующая стадия п+1 начинается по возможности после того, как обновление всех модулей на стадии п закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.
1 План управления программным проектом
2 Проектная документация программного обеспечения
3 Спецификация требований к программному обеспечению
