Автор работы: Пользователь скрыл имя, 09 Февраля 2014 в 18:21, лабораторная работа
Выбор жц зависит от многих факторов, среди которых можно выделить следующие:
• наличие ресурсов (время, люди, деньги, программные продукты для разработки);
• сложность продукта (количество подсистем в продукте, новизна продукта);
• стоимость разрабатываемого продукта и стоимость модернизации продукта;
• прогнозируемое время жизни продукта;
Министерство образования и науки Российской Федерации
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ,
МЕХАНИКИ И ОПТИКИ»
ФАКУЛЬТЕТ СРЕДНЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
Лабораторная работа №1
на тему «Определение модели жизненного цикла разработки программного продукта».
По дисциплине «ТРПП»
Специальность «Программное обеспечение вычислительной техники и автоматизированных систем» (230105)
Преподаватель: Антонов М.Б. «_____»____________2009г.
|
Выполнили студенты группы 456 дневного отделения: Жгунова Е.В. Кузнецова Л.С. Корнилов С.А. Хохлов К.О. |
Санкт-Петербург
2008/2009
Выбор оптимальной модели жц пп – это один из факторов, дающий возможность выпустить продукт в срок, с высоким качеством и в рамках установленного бюджета.
Выбор жц зависит от многих факторов, среди которых можно выделить следующие:
Модель жизненного цикла описывает этапы разработки, связь между ними и последовательность их выполнения. Выбор не оптимальной модели может привести к привлечению дополнительных ресурсов, возникновению непредвиденных ситуаций, срыву сроков поставок и, как результат, к недовольству заказчика. В каждом проекте на этапе планирования выбирается одна из моделей жизненного цикла.
Каскадная модель. Предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Переход на следующий этап может происходить только после завершения предыдущего. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта получается на начальных этапах, после завершения обследования
Основной недостаток каскадного подхода : требования к ПО "заморожены" в виде технического задания на все время его создания. Пользователи могут внести свои замечания только после того, как работа над ПО будет полностью завершена. Сложно управлять рисками некоторых типов (таких, как риски, связанные с использованием новых технологий или риски некорректного определения требований). Подобные риски могут проявить себя только на этапе реализации и в случае неточного изложения требований или их изменения в течение длительного периода создания ПО , пользователи получают систему, не удовлетворяющую их потребностям, что в нашем случае неприемлемо.
Модель применяется в проектах, где изначально ясны как объем работ, так и требования к продукту. В эту категорию попадают сложные системы с большим числом задач вычислительного характера, системы реального времени и др.
V-образная модель (модель верификации) по сути это та же каскадная, только в конце каждого этапа жизненного цикла разработки, а зачастую и в процессе выполнения этапа, осуществляется проверка взаимной корректности требований различных уровней, а также всех полученных внутренних и внешних данных. Данная модель позволяет более оперативно проверять корректность разработки, однако, как и в каскадной модели, предполагается, что на каждом этапе разрабатываются документы, описывающие поведение всей системы в целом и все требования чётко установлены, также нельзя вносить изменения на разных этапах жизненного цикла,а тестирование требований происходит слишком поздно, поэтому внесение изменений влияет на выполнение графика работ. Данную модель целесообразно использовать при разработке программных продуктов, главным требованием для которых является высокая надёжность.
Спиральная модель предполагает циклическое выполнение всех этапов каскадной модели, в результате чего реализуемость технических решений проверяется с помощью прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка. Таким образом, углубляются и конкретизируются все детали проектируемого ПО и в результате получается вариант, который удовлетворяет всем требованиям заказчика.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ей решения необходимо ввести временные ограничения на каждый из этапов ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Другими недостатками спиральной модели являются: трудоёмкость внесения изменений; большой объем документации по проекту, затрудняющий программирование; сложность переноса на другие платформы.Трудозатраты при внедрении спиральной модели оказываются значительно завышены, а управление проектом требует настоящего искусства, потому спиральная модель подходит для больших и сложных продуктов, когда требования неясны, а часть функциональности будет меняться по ходу проекта или высоки риски.
Модель быстрой разработки. Их суть заключается в отказе от всего лишнего, что не относится непосредственно к созданию программного продукта, а за основу берутся лишь наиболее эффективные методы создания ПО. Особое внимание уделяется вопросам взаимодействия с заказчиком, организации продуктивной работы и тестированию. Основное преимущество состоит в том, что сравнительно небольшие группы разработчиков способны справляться с проектами за то же время, которое необходимо при применении более традиционных методов командами на порядок большей численности. Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым ПП; повторно используются компоненты уже существующих программ. Ее недостатками является то, что в случае невозможности постоянного участия заказчиков в процессе разработки, это может негативно сказаться на ПП; для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами; существует риск, что работа над ПП никогда не будет завершена, так как может оказаться зациклена – здесь встает проблема вовремя остановиться. Быстрая разработка плохо подходит для крупных проектов и ориентирована в основном на небольшие и средние.
Модель прототипирования. Быстрая частичная реализация продукта для определения требований к продукту. Использование прототипов помогает обеспечить создание продукта, максимально близкого к реальным потребностям пользователей. Модель применяется в проектах, где необходимо сократить неопределённость требований. Жизненный цикл разработки ПП начинается с разработки плана проекта , затем выполняется быстрый анализ, после чего создаются база данных (если, конечно, она используется в ПП), пользовательский интерфейс и выполняется разработка необходимых функций. В результате этой работы получается документ, содержащий частичную спецификацию требований к ПП. Данный документ в дальнейшем является основой для итерационного цикла быстрого прототипирования. В результате прототипирования разработчик демонстрирует пользователям готовый прототип, а пользователи оценивают его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователи и разработчики. Этот процесс продолжается до тех пор, пока пользователи не будут удовлетворены степенью соответствия ПП, поставленным перед ним требованиям. Затем прототип демонстрируют пользователям с целью получения предложений по его усовершенствованию, которые включаются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной. После этого получают от пользователей официальное одобрение (утверждение) функциональных возможностей прототипа и выполняют его окончательное преобразование в готовый ПП.
Недостатки:
Итерационная модель (или инкрементальная модель). В соответствии с итеративной моделью имеются четыре основные фазы жизненного цикла разработки ПО (начало, исследование, построение и внедрение). На каждой фазе проект проходит множество итераций, приводящих к созданию работоспособных версий. Сначала разрабатываем общий каркас приложения, затем после каждой итерации либо переделываем либо добавляем новую функциональность. Таким образом, с завершением каждой итерации, продукт развивается инкрементно. В результате каждой итерации получаем постепенной приближение к нужному продукту, причем оценивать его могут все вовлеченные в проект участники. Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат. Модель применяется в проектах, где предполагается, что функциональность продукта будет наращиваться.
Выбор модели:
В связи с тем что заказчик не является специалистом в области ПО, он обычно плохо воспринимает «голые» спецификации продукта. Для того чтобы преодолеть информационный барьер между заказчиком и разработчиком и снизить риск получения продукта, который не соответствует выдвигаемым требованиям, применим подход, направленный на создание прототипов, представляющих собой полностью или частично рабочие модели готовой системы. Таким образом мы значительно улучшим взаимопонимание между всеми участниками процесса за счет последовательного, эволюционного развития системы на основе итеративного уточнения прототипов.
Аргументирование выбора модели:
Решающими факторами в выборе оптимальной модели создания ПП являются ограниченные временные рамки, бюджет, неясность требований на начальном этапе разработки и возможность их корректировки впоследствии. В связи с этим требуется модель обеспечивающая возможность уточнения требований и характеристик ПП, возможность его изменения и дополнения программного продукта в процессе и после разработки, гарантирующая выполнение заказа в срок и максимально качественно.
Каскадная модель не подходит потому что заказчик может внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПП заказчик получает систему, не удовлетворяющую его потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.
v-образная модель жизненного цикла так же как и каскадная не приспособлена к возможным изменениям требований заказчика. Может возникнуть потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.
Спиральная модель имеет усложнённую структуру, а соответственно повышенную стоимость и сложность в управлении, есть возможность образования бесконечной спирали (каждая ответная реакция заказчика может породить новый цикл), что также повышает стоимость проекта и временные затраты.
Модель быстрой разработки не всегда дает гарантии качества, только в маленьких проектах и необходимы только высококвалифицированные опытные разработчики.
Модель прототипирования. Так как решение сложных задач может отодвигаться, некоторые важные пункты могут быть упущены или недоработаны, что отражается на качестве. Заказчик же может с каждым прототипом вносить все новые и новые изменения, что приводит к значительному увеличению количества прототипов, каждый новый прототип означает дополнительные затраты времени и ресурсов, а в итоге – снижение рентабельности проекта.
В итоге, перебрав все представленные варианты можно предположить, что оптимальной моделью жизненного цикла для данного проекта будет инкрементная модель. Она объединяет в себе главные преимущества спиральной, каскадной и прототипной моделей.
Итерационная организация процесса имеет целый ряд преимуществ.