Возможности модели жизненного цикла программной системы (потенциальность модели) должна соответствовать сложности реализации программного продукта.
Сложность реализации программного продукта определяется уровнем неопределенности требований к потребительским свойствам конечного продукта
Code-and-fix model
Реализация программного продукта сводится к непосредственному кодированию задачи в том виде, как она понимается.
Особенностями этой модели являются:
•Трудность модификации и развития ПП из-за недостаточно проработанной проектной стадии.
•Вследствие того, что задача кодировалась как понималась, т.е. стадия изучения и согласования пользовательских требований реализовывалась посредством экспериментирования с уже готовой программой, функциональные возможности программного продукта редко полностью согласуются с потребностями пользователей
•Сложность тестирования программного продукта.
Stagewise model
Разработка программного продукта сводится к следующей последовательности действий:
•Планирование разработки.
•Разработка операционной спецификации.
•Кодирование.
•Параметрическое тестирование модулей.
•Тестирование сборки.
•Опытную эксплуатацию.
•Оценку системы пользователем.
|
|
|
|
|
|
|
Waterfall model |
|
|
|
|
||||||
Оценка реалистичности |
|
|
|
Оценка |
|
|
|
|
|
|
|
|
|||||
программного продукта |
|
|
|
|
|
|
|
|
|
|
|||||||
возможности реализации |
|
|
|
|
|
|
|
||||||||||
|
|
|
при допустимых ресурсах |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
Требования к программному |
|
|
|
|
|
|
|
|
|
|
|
|||||
|
продукту, планы создания |
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
программного продукта |
Проверка правильности |
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
Проектирование |
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
Контроль правильности |
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
проектных решений |
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Детальное |
|
|
|
|
|
Контроль |
|
|
|
|
|||
|
|
|
|
проектирование |
|
|
|
|
|
|
|
|
|||||
|
|
|
|
правильности спецификаций |
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
программных компонентов |
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
Кодирование |
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
Помодульное тестирование |
|
||||||
|
|
|
|
|
|
|
|
Интеграция модуля |
Контроль |
|
|
||||||
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
на соответствие |
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
программного продукта |
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
требованиям |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Опытная эксплуатация |
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
Системное тестирование |
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Промышленная |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
эксплуатация |
|
Переоценка |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
желаний пользователя |
|||
Инкрементальная модель жизненного цикла
UR |
SR |
AD |
DD1 |
TR1 |
OM1 |
DD2 
TR2 
OM2
UR – требования пользователей SR – системные требования
AD – проектирование архитектуры DD – детальное проектирование TR – передача пользователю
OM – эксплуатация и обслуживание
Источник: ESA PSS-05-0
Общий вид V-модели жизненного цикла |
5 |
|
й и н
а
в
о
б
е р
т
а к
т
е В
В е т к а к о н с т р у и р о в а н и я
Методологическая основа упомянутых моделей жизненного цикла
Методологическую основу приведенных моделей жизненного цикла составляет нисходящая разработка программных систем. Предполагается, что в начале проекта известны (с приемлемым уровнем неопределенности) требования к потребительским свойствам конечного продукта на момент завершения проекта.
Обоснованный выбор модели жизненного цикла
«Знание сравнения» есть моделирование, т.е. наше восприятие проблемной ситуации определяется сравнением с теми проблемными ситуациями, которые имели место в прошлом.
Источник: Давыдов М.Г., Лисичкин В.А., 1977
Замечание 1. У субъекта имевшие ранее место проблемные ситуации представляются в форме онтологий.
Обоснованный выбор модели жизненного цикла (продолжение)
Определение: Ситуация есть принуждение к решению, свобода же состоит в самом решении
Hartmann N., 1941
Замечание 2. «Ситуация – феномен неоднозначный; в ней нельзя распознать меру вклада свободы и жесткого положения вещей»
Источник: Зотов А.Ф., 2010
Пример: Обильный снегопад - явление объективное, природное. Но вот осознается оно по-разному: у владельца автомобиля снегопад порождает волнение, связанное с возможными «пробками» на дорогах; у работника жилищно- коммунального хозяйства (ЖКХ) возникает озабоченность, справится ли с ним снегоуборочная техника, имеющаяся в службах ЖКХ; дети предвкушают удовольствие поиграть в снежки и т.д.
Источник: Виттих В.А., 2013
Множественность моделей жизненного цикла программных продуктов
...Известно, что человеческое познание на каждом новом этапе своего развития снова возвращает людей к одним и тем же вопросам, которые Гейне называл «проклятыми». Примером может служить многообразие средств передачи сигналов (факельный телеграф в древней Греции; радиотелеграф; спутниковая связь; ...). Коренные проблемы человеческого бытия не могут быть решены раз и навсегда и передаются из поколения в поколение, уточняясь, обогащаясь новым содержанием.
Источник: Давыдов М.Г., Лисичкин В.А., 1976
Замечание. Можно предположить, что в способы обработки информации также относятся к классу «проклятых» вопросов. Если более узко рассматривать способы создания программных продуктов, то можно выделить такие подходы как коды; структурно- ориентированное программирование; объектно-ориентированное программирование; SOA, ...)