Разработка программы перевода чисел

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

1. процесс разработки выполняется поэтапно;

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

• каждую стадию могут выполнять независимые команды (все документировано);

• позволяет достаточно точно планировать сроки и затраты.

3. При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     1.3.2 Другие типы моделей ЖЦ ПО

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

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

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

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

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

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

     Инкрементная (пошаговая) модель.

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

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

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

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

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

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

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