Файл: Модели процессов разработки программного обеспечения (Анализ процесса разработки программного обеспечения на примере бибилиотеки).pdf

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

Спиральная модель Боэма представлена на рисунку 1.3.

Рис. 1.3. Спиральная модель Боэма

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

Самый известный и авторитетный стандарт качества следует рассматривать как Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки программного обеспечения, вместе с производными. Он был создан SEI (Software Engineering Institute). Первая официальная версия стандарта была опубликована в 1993 году, хотя работа над ней началась гораздо раньше - ее основные положения были опубликованы в 1986 году. Успех CMM предопределен несколькими факторами. Этот стандарт был одним из первых изначально учитывая специфику создания программного обеспечения. Это было довольно просто и прозрачно, как понять и использовать, и регулировать, «что», а не «как», и поэтому подходит для различных моделей жизненного цикла, методологий разработки, и не накладывает каких-либо ограничений в отношении стандартов документации, инструментов.

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

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

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

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

Для того, чтобы исключить необходимость «выравнивать» процессов организации и быть более адаптированым к его потребностям бизнеса, а не наоборот, стандарт CMMI имеет две формы представления - классический, многоуровневые, соответствующий CMM, и новый, непрерывнф . Непрерывное представление рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процесса (Process Areas, PA).

Соответствие уровней зрелости стандартов CMM, CMMI представлен в таблице 1.1.

Таблица 1.1

Соответствие уровней зрелости стандартов CMM, CMMI

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

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

Модель зрелости процесса разработки программного обеспечения (СММ), разработанная инженерным институтом программного обеспечения в университете Карнеги-Меллона, предлагает пять уровней зрелости (таблица 1.2). Это помогает организациям повысить зрелость своих процессов разработки программного обеспечения, и организация может быть оценена и аккредитована в соответствии с этими уровнями.

Таблица 1.2

Уровни зрелости разработки программного обеспечения

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

1.3. Процесс управления разработкой программного обеспечения и его особенности

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

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

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

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

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

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

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

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

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

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

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

В управлении разработкой программного обеспечения необходимо учитывать некоторые его характеристики [17, с. 37]:

1) Установленные программы нематериальны. Это создает проблемы двух видов:

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

В мире программного обеспечения, можно создать что-нибудь из той же базовой конструкции. Поэтому, иногда кажется, что суть требуемых изменений в программе понятна, поскольку их выполнение требует особых усилий. Тем не менее, это не так. Работа с элементами программы в этом аспекте не очень отличается от работы с кирпичами и строительных блоков. А если эти блоки еще и стоят кое-как, то при попытке передвинуть их программиста вообще может «завалить»— отладка полученной программы потребует колоссальных усилий.

- переход к желаемому результату в разработке программного обеспечения очень трудно контролировать.

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

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

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