Шпаргалка по "Технологии программирования и UML"

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

      13. Достоинства и недостатки CMM/CMMI.

 

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

CMM/CMMI

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

Успех CMM предопределило несколько  факторов. Этот стандарт был одним  из первых, изначально учитывающих  специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает  пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Таблица 1. Уровни модели CMM

№ уровня	Название уровня	Ключевые области процесса
1	Начальный	Если организация находится  на этом уровне, то ключевых областей процессов  для нее не предусмотрено
2	Повторяющийся	Управление программными конфигурациями. Обеспечение качества программных  продуктов. Управление контрактами  подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями
3	Определенный	Экспертные оценки. Координация  взаимодействий проектных групп. Инженерия  программного продукта. Комплексный  менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса
4	Управляемый	Менеджмент качества ПО. Управление процессом на основе количественных методов
5	Оптимизируемый	Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет  последовательно внедрять CMM, используя  стандарт в качестве руководства, которое  может обеспечить постоянное совершенствование  процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое  имя – SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

 

Таблица 2. Развитие стандартов CMM

Название стандарта	Описание
System Engineering CMM (SE-CMM)	Ориентирован на вопросы системного инжиниринга – разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий  и функционирование)
Trusted CMM (T-CMM)	Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО
System Security Engineering CMM (SSE-CMM)	Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в  том числе и безопасность членов команды создателей
People CMM (P-CMM)	Рассматривает вопросы развития персонала  в софтверных организациях
Software Acquisition CMM (SA-CMM)	Охватывает вопросы приобретения программных продуктов у внешних  организаций
Integrated Product Development CMM (IPD-CMM)	Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого  отдела компании

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

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

 

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

 

Таблица 3. Соответствие уровней CMM/CMMI

№ уровня	Уровень зрелости CMM	Уровень зрелости многоуровневого  представления CMMI	Уровень возможностей непрерывного представления CMMI
0	–	–	Незавершенный
1	Начальный	Начальный	Выполнимый
2	Повторяющийся	Управляемый	Управляемый
3	Определенный	Определенный	Определенный
4	Управляемый	Управляемый количественно	Управляемый количественно
5	Оптимизируемый	Оптимизируемый	Оптимизируемый

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

14. Модульное программирование (МП).

 

Архитектура МП позволяет:

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

Технологию МП поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.

Использование МП упрощает разработку программ несколькими программистами:

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

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

Узкие места МП:

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

Стремление уменьшить количество связей между отдельными частями  программы приводит  к появлению  объектно-ориентированного программирования (ООП).

 

 

 

 

 

 

    15. Суть спиральной модели ЖЦ

 

 Спиральная модель была впервые  сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.

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

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

Каждый виток имеет следующую  структуру (секторы):

-определение целей, ограничений и альтернатив проекта;

-оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;

-разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;

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

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

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

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