Особенности управления разработкой программного обеспечения
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
азчика, так и для создателя системы, поскольку позволяет продвигаться вперед, соблюдая интересы обеих сторон.
Однако у нее есть свои недостатки. Деление на функциональные блоки в целом замедляет процесс, так как возникает необходимость обеспечения их взаимодействия. Для многих решений этот метод неприменим, поскольку из них нельзя вычленить отдельные составляющие, которые могут быть поставлены и функционировать независимо. Существенно возрастает нагрузка и на руководящий персонал в связи с усложнением задач по координированию работ над отдельными составляющими системы, увеличивается стоимость внесения изменений в готовые компоненты, которые уже установлены и работают у заказчика.
Предложенная Барри Боэмом в 1988 году спиральная модель стала существенным прорывом в понимании природы разработки программного обеспечения, хотя объединяет каскадный подход и итерационный процесс проектирования на основе создания прототипов (рисунок 3).
Рис. 3. Спиральная модель Боэма
Спиральная модель Боэма сфокусирована на проектировании, разработка программного обеспечения происходит лишь на последнем витке спирали по обычной каскадной модели, однако этому предшествует несколько итераций проектирования на основе создания прототипов - при этом каждая итерация включает стадию выявления и анализа рисков и наиболее сложных задач.
Поскольку спиральная модель в основном охватывает именно проектирование, то в первоначальном виде она не получила широкого распространения в качестве метода управления всем жизненным циклом создания программного обеспечения. Однако главная ее идея, заключающаяся в том, что процесс работы над проектом может состоять из циклов, проходящих одни и те же этапы, послужила исходным пунктом для дальнейших исследований и стала основой большинства современных моделей процесса разработки программного обеспечения.
Впервые предложенная Филиппом Крачтеном в 1995 году, итеративная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рисунок 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах [9].
Рисунок 4- Итеративная модель разработки программного обеспечения
В соответствии с итеративной моделью имеются четыре основные фазы жизненного цикла разработки программного обеспечения (начало, исследование, построение и внедрение). На каждой фазе проект проходит множество итераций, приводящих к созданию работоспособных версий: на начальных создаются прототипы, уточняются требования, прорабатываются наиболее сложные проблемы; конечные приводят к созданию продукта, его совершенствованию и расширению функциональности.
Итеративная модель, помимо основных фаз, выделяет еще две группы процессов: рабочие (управление требованиями, анализ и проектирование, реализация, тестирование, развертывание) и вспомогательные (управление конфигурацией и изменениями, проектом и процессом). Количество и суть процессов варьируются в зависимости от потребностей разработчика, они также могут иметь свои циклы, которые не обязательно даже соответствуют основным фазам. Однако результатом рабочих процессов всегда является создание версий продукта.
Итеративная модель подобно спиральной дает возможность успешно справляться с рисками. Если во время работы над очередной версией будет установлено, что трудозатраты на реализацию необходимой функциональности слишком велики, то превышения бюджета и нарушения сроков можно будет избежать путем соотнесения приоритетов разработки и трудозатрат в начале каждой итерации. Таким образом, данная модель хорошо подходит для большинства типов программных проектов, но особенно ее преимущества заметны при работе над продуктами, предназначенными для выхода на свободный рынок, в силу изначальной ориентации на выпуск последовательных версий.
Самым известным и авторитетным стандартом качества следует iитать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за iет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 году, хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 голу. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания программного обеспечения. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, что, а не как делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.
Модель CMM (таблица 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA) [9].
Таблица 1-Модель СММ
Название уровняКлючевые области процесса1 - НачальныйЕсли организация находитс?/p>