Главная › Претензионный порядок › Модели жизненного цикла информационных систем. Модели жизненного цикла для разработки программных систем

Модели жизненного цикла информационных систем. Модели жизненного цикла для разработки программных систем

Вопрос 143

модели ЖЦ ПО

Понятие жизненного цикла программного обеспечения (ЖЦ ПО) является одним из базовых в программной инженерии. Жизнен ный цикл программного обеспечения определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Под моделью Ж Ц ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ПО: каскадная модель (1970 -1985 гг.) и спиральная модель (I986 - 1990 гг.).

В однородных ЭИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название - водопад (waterfall)) (рис. 1.3). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.

разработки ПО

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

Преимущества применения каскадного способа заключаются в следующем:

на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

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

Каскадный подход хорошо зарекомендовал себя при построении ЭИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные системы с большим количеством задач вычислительного характера, системы реального времени и др.

В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает иной вид (рис. 1.4).

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

Основным недостатком каскадного подхода являются существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей. Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: 1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; 2) за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе. В рамках каскадного подхода требования к ЭИС фиксируются в виде технического задания на все время ее создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 1.5).

Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Глава 2. Спецификация программного продукта

Выбор жизненного цикла программного продукта

Жизненный цикл ПП – это период времени, начинающийся с момента принятия решения по необходимости создания ПП и заканчивающийся его полным изъятием из эксплуатации.

Модель жизненного цикла ПО - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Модели жизненного цикла ПП

1. Водопадная (каскадная, последовательная) модель.

Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.

2. Итерационная модель.

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

По выражению Т. Гилба, «эволюция - прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».

3. V-образная модель.

V-образная модель была создана как итерационная разновидность каскадной модели. Целями итераций в этой модели является обеспечение процесса тестирования. Тестирование продукта обсуждается, проектируется и планируется на ранних этапах жизненного цикла разработки. План испытания приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы - на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели. Помимо планов, на ранних этапах разрабатываются также и тесты, которые будут выполняться при завершении параллельных этапов.

4. Модель быстрого прототипирования.

Модель быстрого прототипирования предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.

Начало жизненного цикла разработки помещено в центре эллипса. Совместно с пользователем разрабатывается предварительный план проекта на основе предварительных требований. Результат начального планирования - документ, описывающий в общих чертах примерные графики и результативные данные.

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

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

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

5. Спиральная модель.

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;
необходимость выполнения ещё одной итерации;
степень полноты и точности понимания требований к системе;
целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID.

Схема работы спиральной модели выглядит следующим образом. Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом, начальные стадии, связанные с анализом и планированием представлены более подробно с добавлением новых элементов. В каждом цикле выделяются четыре базовые фазы:

Определение целей, альтернативных вариантов и ограничений.

Оценка альтернативных вариантов, идентификация и разрешение рисков.

Разработка продукта следующего уровня.

Планирование следующей фазы.

«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку ПО. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания. Следующий цикл начинается с планирования требований и деталей ЖЦ продукта для оценки затрат. На фазе определения целей устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки спецификация требований (с указанием рисков и стоимости), готовится демо-версия ПО для анализа требований заказчиком.

Следующий цикл – разработка проекта – начинается с планирования разработки.

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

Следующий цикл – реализация ПО – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов.

Фаза разработки выполняется по каскадной модели с выходом – действующим вариантом (прототипом) продукта.

Отмечаются некоторые особенности спиральной модели:

До начала разработки ПО, есть несколько полных циклов анализа требований и проектирования.
Количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи
В модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.

Спиральная модель (по отношению к каскадной) имеет следующие преимущества:

Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.
Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика
Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.
Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.
Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.

Основные недостатки спиральной модели связаны с ее сложностью:

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

Спиральную модель целесообразно применять при следующих условиях:

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

Аннотация.

Введение.

1. Жизненный цикл ПО

Введение.

Шаги процесса программирования по Райли

Введение.

1.1.1. Постановка задачи.

1.1.2. Проектирование решения.

1.1.3. Кодирование алгоритма.

1.1.4. Сопровождение программы.

1.1.5. Программная документация.

Вывод к п. 1.1

1.2. Определение ЖЦПО по Леману.

Введение.

1.2.1 Определение системы.

1.2.2. Реализация.

1.2.3. Обслуживание.

Вывод к п. 1.2.

1.3. Фазы и работы ЖЦПО по Боэму

1.3.1. Каскадная модель.

1.3.2. Экономическое обоснование каскадной модели.

1.3.3. Усовершенствование каскадной модели.

1.3.4. Определение фаз жизненного цикла.

1.3.5. Основные работы над проектом.

Литература.

Введение

Промышленное применение компьютеров и растущий спрос на программы поставили актуальные задачи существенного повышения производительности разработки ПО , разработки индустриальных методов планирования и проектирования программ, переноса организационно-технических, технико-экономических и социально-психологических приемов, закономерностей и методов из сферы материального производства в сферу применения компьютеров. Комплексный подход к процессам разработки, эксплуатации и сопровождения ПО выдвинул ряд насущных проблем, решение которых исключит «узкие места» в проектировании программ, уменьшит сроки завершения работ, улучшит выбор и адаптацию существующих программ, а может быть и определит судьбу систем со встроенными ЭВМ.

В практике разработок больших программных проектов зачастую отсутствует единый подход к оцениванию затрат труда, сроков проведения работ и материальных затрат, что сдерживает повышение производительности разработки ПО, а в конечном счете – эффективное управление жизненным циклом ПО. Поскольку программа любого типа становится изделием (кроме, может быть, учебных, макетных программ), подход к ее изготовлению во многом должен быть аналогичен подходу к производству промышленной продукции, и вопросы проектирования программ становятся чрезвычайно важными. Эта идея лежит в основе книги Б.У. Боэма «Инженерное проектирование программного обеспечения», которую мы использовали при написании данной курсовой работы. В этой книге под проектированием ПО понимается процесс создания проекта программного изделия.

1 Жизненный цикл ПО

ВВЕДЕНИЕ

ЖЦПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения (ЖЦПО), шагов процесса программирования, каскадная и спиральная модели. Но все они содержат общие основополагающие компоненты: постановка задачи, проектирование решения, реализация, обслуживание.

Наиболее известной и полной, пожалуй, является структура ЖЦПО по Боэму, включающая восемь фаз. Она и будет представлена в дальнейшем наиболее подробно.

Одним из возможных вариантов может послужить описание верхнего уровня по Леману, включающее три основные фазы и представляющее описание ЖЦПО в самом общем случае.

И, для разнообразия, – приведем шаги процесса программирования, представленные Д.Райли в книге «Использование языка Модула-2». Это представление, по-моему, является весьма простым и привычным, с него и начнём.

1.1 Шаги процесса программирования по Райли

Процесс программирования включает четыре шага (рис. 1):

постановка задачи, т.е. получение адекватного представления о том, какую задачу должна выполнить программа;

проектирование решения уже поставленной задачи (в общем, такое решение является менее формальным, чем окончательная программа);

кодирование программы, т. е. перевод спроектированного решения в программу, которая может быть выполнена на машине;

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

Рис. 1.Четыре шага программирования.

Программирование начинается с того момента, когда пользователь , т.е. тот, кто нуждается в программе для решения задачи, излагает проблему системному аналитику. Пользователь и системный аналитик совместно определяют постановку задачи. Последняя затем передается алгоритмисту , который отвечает за проектирование решения. Решение (или алгоритм) представляет последовательность операций, выполнение которых приводит к решению задачи. Поскольку алгоритм часто не приспособлен к выполнению на машине, его следует перевести в машинную программу. Эта операция выполняется кодировщиком. За последующие изменения в программе несет ответственность сопровождающийпрограммист. И системный аналитик, и алгоритмист, и кодировщик, и сопровождающий программист – все они являются программистами.

В случае большого программного проекта число пользователей, системных аналитиков и алгоритмистов может оказаться значительным. Кроме того, может возникнуть необходимость вернуться к предшествующим шагам в силу непредвиденных обстоятельств. Все это служит дополнительным аргументом в пользу тщательного проектирования программного обеспечения: результаты каждого шага должны быть полными, точными и понятными.

1.1.1 Постановка задачи

Одним из наиболее важных шагов программирования является постановка задачи. Она выполняет функции контракта между пользователем и программистом (программистами). Как и юридически плохо составленный контракт, плохая постановка задачи бесполезна. При хорошей постановке задачи как пользователь, так и программист ясно и недвусмысленно представляют задачу, которую необходимо выполнить, т.е. в этом случае учитываются интересы как пользователя, так и программиста. Пользователь может планировать использование еще несозданного программного обеспечения, опираясь на знание того, что оно может. Хорошая постановка задачи служит основой для формирования ее решения.

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

Характеристики Хорошей Постановки Задачи:

Точность , т.е. исключение любой неоднозначности. Не должно возникать вопросов относительно того, каким будет вывод программы при каждом конкретном вводе.

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

Ясность , т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи – это единственный контракт между ними.

Часто требование точности, полноты и ясности находятся в противоречии. Так, многие юридические документы трудно понять, потому что они написаны на формальном языке, который позволяет предельно точно сформулировать те или иные положения, исключая любые самые незначительные разночтения. Например, некоторые вопросы в экзаменационных билетах иногда сформулированы настолько точно, что студент тратит больше времени на то, чтобы понять вопрос, чем на то чтобы на него ответить. Более того, студент вообще может не уловить основной смысл вопроса из-за большого количества деталей. Наилучшая постановка задачи та, при которой достигается баланс всех трех требований.

Стандартная форма постановки задачи.

Рассмотрим следующую постановку задачи: «Ввести три числа и вывести числа в порядке».

Такая постановка не удовлетворяет приведенным выше требованиям: она не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться по одному на строке или все числа на одной строке? Означает ли выражение «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком они были введены.

Очевидно, что подобная постановка не отвечает на множество вопросов. Если же учесть ответы на все вопросы, то постановка задачи станет многословной и трудной для восприятия. Поэтому Д. Райли предлагает для постановки задачи пользоваться стандартной формой, которая обеспечивает максимальную точность, полноту, ясность и включает:

наименование задачи (схематическое определение);

общее описание (краткое изложение задачи);

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

пример (хороший пример может передать сущность задачи, а также проиллюстрировать различные случаи).

Пример. Постановка задачи в стандартной форме.

НАЗВАНИЕ

Сортировка трех целых чисел.

ОПИСАНИЕ

Ввод и вывод трех целых чисел, отсортированных от меньшего числа к большему.

Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «–».

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

1) Если введено менее трех чисел, программа ждет дополнительного ввода.

Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под стадией создания ПО понимается часть процесса создания ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами. В состав жизненного цикла ПО обычно включаются следующие стадии:

1. Формирование требований к ПО.
2. Проектирование.
3. Реализация.
4. Тестирование.
5. Ввод в действие.
6. Эксплуатация и сопровождение.
7. Снятие с эксплуатации.

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

планирование работ, предваряющее работы над проектом. Основными задачами этапа являются: определение целей разработки, предварительная экономическая оценка проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы;

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

построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей:

модели "AS-IS" ("как есть"), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

модели "ТО-ВЕ" ("как должно быть"), отражающей представление о новых технологиях работы организации.

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

Переход от модели "AS-IS" к модели "ТО-ВЕ" может выполняться двумя способами:

1. Совершенствованием существующих технологий на основе оценки их эффективности.
2. Радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).

Построенные модели имеют самостоятельное практическое значение. Например, модель "AS-IS" позволяет выявлять узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе дальнейшая разработка ЭИС или нет. Кроме того, модель облегчает обучение сотрудников конкретным направлениям деятельности организации за счет использования наглядных диаграмм (известно, что "одна картинка стоит тысячи слов").

Стадия проектирования. Она, как правило, включает следующие этапы:

* разработка системного проекта. На этом этапе дается ответ на вопрос: "Что должна делать будущая система?", а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели "ТО-ВЕ". Документальным результатом этапа является техническое задание;
* разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ISO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных стадиях.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ПО: каскадная модель (1970-1985 гг.) и спиральная модель (1986-1990 гг.).

В однородных ЭИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название - водопад (waterfall)) (рис. 1.3). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.

Преимущества применения каскадного способа заключаются в следующем:

В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает иной вид (рис. 1.4).

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

1. Пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки.
2. За время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

В рамках каскадного подхода требования к ЭИС фиксируются в виде технического задания на все время ее создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 1.5). Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждой стадии позволяет переходить на следующую стадию, не дожидаясь полного завершения работы на текущей. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

Процесс функционирования и сопровождения

Процесс функционирования представляет стадию жизненного цикла, когда программный продукт ежедневно используется, а работа предыдущей системы (ручной или автоматизированной) постепенно сокращается. Постепенное сокращение - обычно поэтапный процесс. В ситуациях, где это возможно и выполнимо, организация обычно использует новую и старую системы параллельно в течение некоторого времени. Это обеспечивает отход назад, если новое изделие не удовлетворяет бизнес-требованиям.

Процесс функционирования совпадает с началом сопровождения изделия . В программной инженерии сопровождение имеет несколько отличное значение по сравнению с обычным использованием этого слова. Во-первых, сопровождение - это не только незапланированная фиксация возникающих проблем. Сопровождение планируется и оплачивается на ранних стадиях жизненного цикла. Во-вторых, сопровождение включает развитие изделия. В некоторых итеративных моделях жизненного цикла, могут даже оказаться трудноразличимыми разработка и сопровождение. В литературе сопровождение обычно разделяется на:

● корректирующее (действия по обслуживанию) - выявление дефектов и ошибок, обнаруженных при работе;

● адаптивное - изменение ПО в ответ на изменения в вычислениях или в бизнес-среде;

● совершенствующее - развитие изделия путем добавления новых особенностей или улучшения его качества.

Стоимость сопровождения значительна за время жизни ПО. Она значительна потому, что изделие остается в действии в течение долгого времени. Большие системы предприятий настолько фундаментальны, что они сохраняются действующими с помощью использования любых доступных технологий«поддержки жизни». Такие системы называются унаследованными системами .

Конечно, их следовало бы удалить, но для них нет никакой замены. Действительно, когда решение об удалении системы, в конечном счете, принято, это делается не потому, что унаследованная система больше не полезна для организации, а потому, что нет технических возможностей дальше сохранять ее в работе. Не должно быть сюрпризом, что сопровождение является главной причиной, почему это технически невозможно - через какое-то время сопровождение настолько уничтожает структурную ясность ПО, что оно дальше не может поддерживаться.

Жизненный цикл ПО определяет «что», но не «как» выполнять в процессе программной инженерии. Программная инженерия в значительной степени - социальное явление, определяемое внутренней организационной культурой предприятия. Предприятие может выбрать базовую модель жизненного цикла , но специфические особенности жизненного цикла и то, как работа будет сделана, уникальны для каждой организации и могут даже значительно отличаться от проекта к проекту. Программный продукт не изготавливается, он реализуется. Процесс создания и эксплуатации ПО - не эксперимент, который может быть повторен много раз с той же самой степенью успеха.

Рассмотрим, почему специфические особенности жизненного цикла должны быть приспособлены к организационной культуре и почему они отличаются от проекта к проекту:

● Опыт программной инженерии, навыки и знания коллектива разработчиков (если их недостаточно, должно быть включено в процесс разработки и время в соответствии с «кривой обучения»).

● Деловой опыт и знания (это намного более неприятно, чем предыдущий момент, потому что деловой опыт и знания легко не приобретаются).

● Вид предметной области (необходимы различные процессы, чтобы совершенствовать бухгалтерский учет или систему контроля электростанции).

● Изменения деловой атмосферы (изменения внешнеполитических, экономических, социальных, технологических и конкурентных факторов).

● Внутренние деловые изменения (изменения в управлении, условиях работы, финансовое здоровье предприятия и т. д.).

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

При условии вышеупомянутого обсуждения подходы к жизненному циклу ПО могут быть грубо разделены на две главные категории:

● «водопад с обратной связью»;

● итеративный пошаговый.

1 Жизненный цикл «водопад с обратной связью»

Модель водопада - традиционный жизненный цикл, реализованный и популяризируемый в 1970-х годах. Об этой модели было сказано, что она успешно использовалась во многих больших проектах прошлого. Большинство этих проектов было связано с пакетными (то есть не диалоговыми) системами, реализованными на языке КОБОЛ. Сегодня жизненный цикл «водопад» используется менее часто.

Жизненный цикл «водопад с обратной связью» может быть представлен так, как изображено на рис. 1.3. Это линейная последовательность стадий, из которых предыдущая стадия должна быть закончена прежде, чем может начаться следующая.

Завершение каждой стадии отмечается подписанием документа для этой стадии проекта. Обратные связи (обратные стрелки на рис. 3) между стадиями возможны и даже целесообразны. Обратная связь показывает не документированное, но необходимое изменение в более поздней стадии, которое должно быть завершено соответствующим изменением в предыдущей стадии.

Такой возврат может (хотя это бывает редко) продолжаться до начальной стадии - анализа требований.

Рисунок 1.3. Жизненный цикл «водопад с обратной связью»

Критический момент относительно методов водопада - то, что они являются монолитными : они применяются при разработке по принципу «выполнять одновременно» ко всей системе в целом и задают единственную дату поставки системы. Пользователь подключается только на ранних стадиях анализа требований и заканчивает техническим заданием. Позже в течение жизненного цикла пользователь находится в полном неведении, пока изделие не может быть протестировано им до его внедрения. Поскольку время задержки между началом проекта и поставкой ПО может быть существенным (месяцы или даже годы), доверие между пользователями и разработчиками может быть утеряно, и разработчикам придется все сложнее защищать проект и оправдывать израсходованные ресурсы.

Преимущества водопада с обратной связью:

1 Предписывает дисциплинированный подход к разработке ПО. Определяет ясные вехи в стадиях ЖЦ, облегчая, таким образом, руководство проектом.

2 Производит полную документацию для системы.

3 Требует завершения проектной документации перед переходом на следующие стадии.

4 Требует тщательного планирования проекта.

Недостатки водопада с обратной связью:

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

2 Монолитный подход может потребовать много времени для получения конечного продукта. Это может быть недопустимо для современного предприятия, требующего короткого срока возвращения инвестиций.

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

4 Документация может давать ложное представление относительно прогресса в проектировании. Имеется риск бюрократизировать работу.

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

6 Планирование проекта проводится на ранних этапах ЖЦ, когда имеется ограниченное понимание проекта. Риск неверной оценки требуемых ресурсов.