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

• Данная модель основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление требований. Проектирование разделяется на высокоуровневое и де­тальное (низкоуровневое). Разработка включает в себя кодирова­ние, а обзор — различные виды тестирования.

• Эта модель (рис. 3.3) была разработана как разновидность кас­кадной модели, в которой особое внимание уделяется верификации и аттестации ПП. Модель показывает, что тестирование продукта обсуждается, проектируется и планируется, начиная с ран­них этапов жизненного цикла разработки (на рис. 3.3 этот процесс обозначен штриховыми стрелками).

• На модели хорошо просматриваются взаимосвязи между аналитическими фазами и фазами проектирования, которые пред-

шествуют кодированию и тестированию. Штриховые стрелки показывают, что эти фазы надо рассматривать параллельно.

• Модель включает в себя следующие фазы: составление требований к проекту и планирование — определяются системные требования и выполняется планирование работ;

• составление требований к продукту и их анализ — составляется полная спецификация требований к программному продукту;

• высокоуровневое проектирование — определяются структура ПП, взаимосвязи между основными его компонентами и реализуемые ими функции;

• детальное проектирование — определяется алгоритм работы каждого компонента;

• кодирование — выполняется преобразование алгоритмов в го­товое программное обеспечение;

• модульное тестирование — выполняется проверка каждого ком­понента или модуля ПП;

• интеграционное тестирование — осуществляются интеграция ПП и его тестирование;

• системное тестирование — выполняется проверка функциони­рования ПП после помещения его в аппаратную среду в соответ­ствии со спецификацией требований;

• эксплуатация и сопровождение — запуск ПП в производство. На этой фазе в ПП могут вноситься поправки и может выполняться его модернизация.

Преимушества V-образной модели:

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

• предполагаются аттестация и верификация не только самого ПП, но и всех полученных внутренних и внешних данных;

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

Кроме перечисленных достоинств модель обладает и рядом недостатков:

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

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

Модель прототипирования (рис. 3.4) позволяет создать прототип ПП до или в течение этапа составления

требований к ПП.

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

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

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

• Модель прототипирования обладает целым рядом преимуществ:

• взаимодействие заказчика с

• разрабатываемой системой начи­нается на раннем этапе;

• благодаря реакции заказчика на прототип сводится к миниму­му число неточностей в требованиях;

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

• в процессе разработки всегда можно учесть новые, даже не­ожиданные требования заказчика;

• прототип представляет собой формальную спецификацию, воп­лощенную в ПП;

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

• заказчик всегда видит прогресс в процессе разработки ПП; возможность возникновения противоречий между разработчи­ками и заказчиками сведена к минимуму;

• уменьшается число доработок, что снижает стоимость разра­ботки:

• возникающие проблемы решаются на ранних стадиях, что рез­ко сокращает расходы на их устранение;

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

• Кроме указанных достоинств модели прототипирования присутсвует и целый ряд недостатков:

• решение сложных задач может отодвигаться на будущее;

• заказчик может предпочесть получить прототип, а не закон­енную полную версию ПП;

• прототипирование может неоправданно затянуться;

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

• Модель прототипирования рекомендуется применять в следующих случаях:

• требования к ПП заранее неизвестны,

• требования не постоянны или неудачно сформулированы;

• требования необходимо уточнить;

• нужна проверка концепции;

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

Тема: Оценка системы. Планирование работ.

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

Можно выделить следующие этапы этого процесса

• Понять предметную область

• Выделить проблемы для решения

• Найти возможные варианты решения

• Выбрать подходящий вариант решения

• Определить роль компьютерной программы в решении проблемы

• Определить пределы возможностей программы

• Оценить влияние программы на существующую систему

• Определить способ внедрения программы в существующую систему предприятия

• Оценить экономический эффект от внедрения программы

• Разработать функциональное описание для следующей стадии – системного анализа

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

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

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

Планирование работ по созданию программных продуктов Структура разделения работ по созданию ПП

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

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

Процесс планирования

• Как правило структура разделения работ представляет собой иерархию задач.

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

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