Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Жизненный цикл программного обеспечения 71

• повторяющегося цикла, при котором разработчики по мере

того,

как приложение начинает обретать форму, запрашива-

ют и реализуют в продукте требования, полученные в ре-

зультате взаимодействия с заказчиком.

Основные принципы подхода RAD:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждой из

стадий жизненного цикла ПО;

• обязательность вовлечения пользователей в процесс разра-

ботки;

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

щих

внесение изменений

проект

сопровождение готовой

системы;

• использование прототипирования, позволяющее полнее

выяснить и удовлетворить потребности пользователей;

• тестирование

развитие проекта, осуществляемые одновре-

менно с разработкой;

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

мой командой профессионалов;

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

рование и контроль выполнения работ.

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

профессионалов, имеющих опыт в проектировании, программи-

ровании и тестировании ПО, способных хорошо взаимодейство-

вать с конечными пользователями и трансформировать их пред-

ложения

рабочие прототипы.

Жизненный цикл ПО в соответствии с подходом RAD состо-

ит из четырех стадий:

• анализ и планирование требований;

• проектирование;

• реализация;

• внедрение.

RAD наиболее хорошо подходит для относительно неболь-

ших проектов, разрабатываемых

для

конкретного заказчика, и не

применим для построения сложных расчетных профамм, опера-

ционных систем или программ управления сложными объектами

в реальном масштабе времени, т.е. программ, содержащих боль-

шой объем (сотни тысяч строк) уникального кода, а также сис-

тем, от которых зависит безопасность

людей

(например, управле-

ние самолетом или атомной электростанцией).

72 Глава 1

Естественное развитие каскадной

спиральной моделей при-

вело к их сближению и появлению современного итерационного

подхода, который по существу представляет собой рациональное

сочетание этих моделей. Различные варианты итерационного

подхода реализованы в большинстве современных технологий и

методов: Rational Unified Process (RUP), Microsoft Solutions

Framework (MSF), XR

1.4.

СЕРТИФИКАЦИЯ И ОЦЕНКА ПРОЦЕССОВ

СОЗДАНИЯ ПО

1.4.1.

ПОНЯТИЕ ЗРЕЛОСТИ ПРОЦЕССОВ СОЗДАНИЯ ПО.

МОДЕЛЬ ОЦЕНКИ ЗРЕЛОСТИ СММ

Организации, работающие в области разработки, поставки,

внедрения и сопровождения ПО и системной интеграции, все

больше ощущают, что в основе их конкурентоспособности лежат

качество и низкий уровень себестоимости, технологичность про-

изводства.

Руководители таких организаций не всегда могут сформиро-

вать стратегию совершенствования и развития технологии дея-

тельности своей компании; на рынке труда специалистов необхо-

димой квалификации явно недостаточно. Вместе с тем в области

совершенствования технологических процессов разработки и

эксплуатации ПО международный опыт долгие годы был недос-

таточно обобщен и формализован. Только в начале 1990-х годов

американский Институт профаммной инженерии (SEI) сформи-

ровал

модель

технологической зрелости организаций СММ^ (Ca-

pability Maturity Model), определив уровни технологической зре-

лости и их отличительные черты. В течение десятилетия СММ

прошла апробацию в целом ряде организаций, ее эффективность

и достоверность проверили заказывающие организации, постав-

Оценка и аттестация зрелости процессов создания и сопровождения

программных средств и информационных систем (ISO/IEC TR 15504-

СММ) / Пер. с англ. А.С. Агапова и

др.

—

М.: Книга и бизнес, 2001.

Жизненный цикл программного обеспечения 73

щики по, компании, осуществляющие разработку заказного

ПО,

занимающиеся оффшорным профаммированием.

Сегодня на западе компания-разработчик практически испы-

тывает большие трудности с получением заказов, если она не ат-

тестована по СММ. Заказчики требуют гарантий технологичнос-

ти компании-исполнителя, гарантий того, что исполнитель не

может оказать некачественную услугу.

Оценка технологической зрелости компаний может исполь-

зоваться:

• заказчиком при отборе лучших исполнителей (например, в

тендере);

• компаниями-производителями ПО для систематической

оценки состояния своих технологических процессов и вы-

бора направлений их совершенствования;

• компаниями, решившими пройти аттестацию, для оценки

«размеров бедствия», т.е. своего текущего состояния;

• аудиторами для определения стандартной процедуры аттес-

тации и проведения необходимых оценок;

• консалтинговыми фирмами, занимающимися реструктури-

зацией компаний и служб поставщиков информационных

технологий и связанных с ними услуг.

По мере повышения технологической зрелости организации

процессы создания и сопровождения ПО становятся более стан-

дартизованными и согласованными. При этом формализация

процессов позволяет стандартизовать ожидаемые результаты их

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

ния проектов.

Зрелость процессов (software process maturity) —

это степень их

управляемости, контролируемости и эффективности. Повыше-

ние технологической зрелости означает потенциальную возмож-

ность возрастания устойчивости процессов и указывает на сте-

пень эффективности и согласованности использования процес-

сов создания и сопровождения ПО в рамках всей организации.

Реальное использование процессов невозможно без их докумен-

тирования и доведения до сведения персонала организации, без

постоянного контроля и совершенствования их выполнения.

Возможности хорошо продуманных процессов полностью опре-

делены. Повышение технологической зрелости процессов озна-

чает, что эффективность и качество результатов их выполнения

могут постоянно возрастать.

74 Глава 1

В организациях, достигших технологической зрелости, про-

цессы создания и сопровождения ПО принимают статус стандар-

та, фиксируются в организационных структурах и определяют

производственную тактику и стратегию. Введение их в статус за-

кона влечет за собой необходимость построения необходимой

инфраструктуры и создания требуемой корпоративной культуры

производства, которые обеспечивают поддержку соответствую-

щих методов, операций и процедур ведения дел даже после того,

как из организации уйдут

те,

кто все это создал.

Модель СММ развивает положения о системе качества орга-

низации, формируя критерии ее совершенства

—

пять уровней

технологической зрелости, которые в принципе могут быть дос-

тигнуты организацией-разработчиком. Наивысшие

—

четвертый

и пятый уровни

—

это фактически характеристика организаций,

овладевших методами коллективной разработки, в которых про-

цессы создания и сопровождения ПО комплексно автоматизиро-

ваны и поддерживаются технологически.

Начиная с 1990 г. SEI при поддержке правительственных

структур США

Организаций-разработчиков ПО постоянно раз-

вивает

совершенствует эту

модель,

учитывая все новейшие дос-

тижения в области создания и сопровождения ПО.

СММ представляет собой методический материал, определя-

ющий правила формирования системы управления созданием и

сопровождением ПО и методы постепенного и непрерывного по-

вышения культуры производства. Назначение СММ

—

предос-

тавление организациям-разработчикам необходимых инструк-

ций по выбору стратегии повышения качества процессов путем

анализа степени их технологической зрелости и факторов, в на-

ибольшей степени влияющих на качество выпускаемой продук-

ции. Фокусируя внимание на небольшом количестве наиболее

критичных операций и планомерно повышая эффективность и

качество их выполнения, организация таким образом может до-

биться неуклонного постоянного повышения культуры создания

и сопровождения ПО.

СММ

—

это описательная модель в том смысле, что она опи-

сывает существенные (или ключевые) атрибуты, которые опреде-

ляют, на каком уровне технологической зрелости находится орга-

низация. Это нормативная модель в том смысле, что детальное

описание методик устанавливает уровень организации, необхо-

димый для выполнения проектов различной сложности и про-

должительности по контрактам с правительственными структу-

Жизненный цикл программного обеспечения

рами США. СММ не является предписанием, она не предписы-

вает организации, каким образом развиваться. СММ описывает

характеристики организации для каждого из уровней технологи-

ческой зрелости,

не

давая каких-либо инструкций

как

перехо-

дить

уровня на

уровень.

Организации может потребоваться нес-

колько

лет для

перехода

первого на второй уровень

совсем ма-

ло времени для перехода с уровня на уровень

далее.

Процесс со-

вершенствования технологии создания ПО отражается

страте-

гических планах организации, ее структуре, используемых техно-

логиях, общей социальной культуре и системе управления.

На каждом уровне устанавливаются требования,

при

выпол-

нении которых достигается стабилизация наиболее существен-

ных показателей процессов. Выход

на

каждый уровень техноло-

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

го количества компонентов в процессах создания ПО, что в свою

очередь приводит

повышению их производительности

каче-

ства. На

рис.

1.7 показаны пять уровней технологической зрелое-

Постоянное

совершенствование

процессов

Оптимизируемые

процессы

(optimizing)

Прогнозирование

результатов

Управляемые

процессы

(managed)

Стандартизация

процессов

Стандартные

процессы

(defined)

Упорядочение

процессов

Повторяемые

процессы

(repeatabfe)

—

Начальный

уровень

f—'

(Initial)

Рис.

1.7. Пять уровней технологической зрелости СММ

76 Глава 1

ти СММ. Надписи на стрелках определяют особенности совер-

шенствования процессов при переходе с уровня на уровень.

Уровни со второго по пятый могут характеризоваться через

операции, направленные на стандартизацию и (или) модерниза-

цию процессов создания ПО, и через операции, составляющие

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

как бы базой, фундаментом для сравнительного анализа верхних

уровней.

На уровне 1 (начальном) основные процессы создания и

сопровождения ПО носят случайный характер и выполняются

хаотично. Успех выполнения проекта всецело зависит от индиви-

дуальных усилий персонала. На этом уровне, как правило,

орга-

низации не существует стабильной среды, необходимой для соз-

дания и сопровождения ПО.

Успех проекта при этом, как правило, полностью зависит от

степени энергичности и опыта руководства и профессионально-

го уровня исполнителей. Может случиться, что энергичный ру-

ководитель преодолеет все препятствия в процессе выполнения

проекта и добьется выпуска действительно жизнеспособного

профаммного продукта. Но после того, как такой руководитель

оставит свой пост, исчезнет и гарантия того, что следующий по-

добный проект будет успешным. При отсутствии необходимого

уровня управления проектом положение не сумеет спасти даже

передовая технология.

Процессы на первом уровне характеризуются своей непред-

сказуемостью в связи с тем, что их состав, назначение и после-

довательность в процессе выполнения проекта меняются слу-

чайным образом в зависимости от текущей ситуации. Вслед-

ствие этого перерасходуются выделенные средства и срываются

графики работ. Подготовка способных

знающих специалистов

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

всех уровнях зрелости, но на первом уровне это единственная

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

татов.

На уровне 2 (уровне повторяемых процессов) процессы

управления проектом позволяют обеспечивать текущий контроль

стоимости проекта, графика его выполнения и выполняемых

функций. Дисциплина выполнения проекта такова, что сущест-

вует возможность прогнозирования успешности выполнения

проектов по созданию аналогичных профаммных продуктов.

Жизненный цикл программного обеспечения 77

На этом уровне планирование проектных работ и управление

новыми проектами базируется на опыте успешно выполненных

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

является наличие формализованных и документированных эф-

фективных процессов управления проектами, что позволяет ис-

пользовать положительный опыт успешно завершенных проек-

тов.

Эффективными могут называться процессы, которые доку-

ментированы, реально используются, поддаются количествен-

ной оценке и пригодны для модернизации. Необходимо, чтобы

персонал был обучен их применению.

Каждый уровень СММ, начиная со второго, характеризуется

наличием ряда так называемых основных групп процессов (key

process areas

—

КРА). Модель СММ содержит

таких

групп,

пос-

ледняя версия модели CMMI

—

20 фупп. Уровень

СММ харак-

теризуется наличием в организации следующих процессов (их

наименования соответствуют CMMI):

• управление требованиями;

• управление конфигурацией;

• планирование проекта;

• мониторинг и контроль проекта;

• управление контрактами;

• измерения и анализ;

• обеспечение качества процесса и продукта.

Процессы на втором уровне можно охарактеризовать как упо-

рядоченные

связи

тем,

что они заранее планируются, и их вы-

полнение строго контролируется, за счет чего достигается предс-

казуемость результатов выполнения проекта.

увеличением

ус-

ложнением проектов внимание смещается с технических аспек-

тов

их

выполнения на организационные

управленческие аспек-

ты.

Выполнение процессов требует от персонала более эффек-

тивной и слаженной работы, что, в свою очередь, требует изуче-

ния документированного передового опыта в целях повышения

профессионального мастерства.

На уровне 3 (уровне стандартизованных процессов) про-

цессы создания

ПО

документированы, стандартизованы и предс-

тавляют собой единую технологическую систему, обязательную

для всех подразделений организации. Во всех проектах использу-

ется опробованная, утвержденная и возведенная в статус стан-

дарта единая технология создания и сопровождения ПО.

78 Глава 1

На

данном уровне к процессам уровня

добавляются следую-

щие процессы:

• спецификация требований;

• интефация продукта;

• верификация;

• аттестация;

• стандартизация процессов организации;

• обучение;

• интефированное управление проектом;

• управление рисками;

• анализ и принятие решений.

Основным критерием использования и, при необходимости,

корректировки процессов на этом уровне является помощь звену

управления и техническим специалистам в повышении эффек-

тивности выполнения проектов. На этом уровне в организации

создается специальная фуппа, ответственная за состав операций,

из которых состоят процессы,

—

фуппа по разработке процессов

создания ПО (software engineering process group

—

SEPG).

Ha основе единой технологии для каждого проекта могут раз-

рабатываться свои процессы с учетом его особенностей. Такие

процессы в СММ называются «проектно-ориентированные про-

цессы создания ПО» (project's defined software process).

Описание каждого процесса включает в себя условия его вы-

полнения,

входные

данные,

стандарты и процедуры выполнения,

механизмы проверки (например, экспертные оценки), выходные

данные и условия завершения.

описание процесса также вклю-

чаются сведения об инструментальных средствах, необходимых

для его выполнения, и указание на роль, ответственную за его

выполнение.

Главное назначение уровня 4 (уровня управляемых процес-

сов)

—

текущий контроль над процессами. Управление должно

обеспечивать выполнение процессов в рамках заданного качест-

ва. Могут быть неизбежные потери и временные пики в измеря-

емых результатах, которые требуют вмешательства, но в целом

система должна быть стабильна.

На уровне

добавляются следующие процессы:

• управление производительностью и продуктивностью;

• количественное управление проектом.

На этом уровне на практике применяется детальная оценка

качества как процессов создания, так и самого создаваемого

Жизненный цикл программного обеспечения 79

программного продукта. При этом применяются количественные

критерии оценки.

рамках всей организации разрабатывается единая програм-

ма количественного контроля производительности создания ПО

и его качества. Для облегчения анализа процессов создается еди-

ная база данных процессов создания и сопровождения ПО для

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

универсальные методики количественной оценки производи-

тельности процессов и качества их выполнения. Это позволяет

проводить количественный анализ и оценку процессов создания

и сопровождения ПО.

Результаты выполнения процессов на четвертом уровне ста-

новятся предсказуемы, поскольку они измеряемы и варьируются

рамках заданных количественных офаничений. На этом уровне

появляется возможность заранее планировать заданное качество

выполнения процессов и конечной продукции.

Основное назначение уровня 5 (уровня оптимизируемых

процессов)

—

последовательное усовершенствование и модерни-

зация процессов создания и сопровождения ПО.

целях плано-

вой модернизации технологии создания ПО

организации созда-

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

торого являются

сбор

данных по выполнению процессов, их ана-

лиз,

модернизация имеющихся и создание новых процессов, их

проверка на пилотных проектах и придание им статуса стандар-

тов предприятия.

На уровне

добавляются следующие процессы:

• внедрение технологических

организационных инноваций;

• причинно-следственный анализ и разрешение проблем.

Процессы создания и сопровождения ПО характеризуются

как последовательно совершенствуемые, поскольку организа-

ция прилагает постоянные усилия по их модернизации. Это

совершенствование распространяется как на выявление допол-

нительных возможностей используемых процессов, так и на

создание новых оптимальных процессов и использование но-

вых технологий.

Нововведения, которые могут принести наибольшую выгоду,

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

рамках всей организации. Персонал, принимающий участие в

выполнении проекта, анализирует дефекты и выявляет причины

их возникновения. Процессы создания ПО оцениваются в целях

80 Глава 1

предотвращения повторения ситуаций, приводящих к дефектам,

а результаты оценки учитываются в последующих проектах.

Каждый последующий уровень дополнительно обеспечивает

более полную обозримость самих процессов создания и сопро-

вождения ПО.

На первом уровне процессы являются аморфными

(«черными ящиками»), и их обозримость весьма Офаничена. С

самого начала состав и назначение операций практически не оп-

ределены, что порождает значительные трудности в определении

состояния проекта и его продвижения. Требования по выполне-

нию процессов задаются бесконтрольно. Разработка ПО в глазах

менеджеров (особенно тех, кто сам не является программистом)

иногда выглядит как черная магия.

На втором уровне выполнение требований пользователя

и создание ПО контролируемы, поскольку определена база для

процессов управления проектом. Процесс создания ПО может

рассматриваться как последовательность «черных ящиков», ко-

торые можно контролировать

точках перехода из одного «ящи-

ка»

другой - зафиксированных

этапах.

Даже если руководитель

не знает, что делается «внутри ящика», точно установлено, что

должно получиться

результате выполнения процесса, и опреде-

лены контрольные точки его начала и завершения. Поэтому уп-

равление может распознавать проблемы

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

«черных ящиков» и своевременно на них реагировать.

На третьем уровне определена внутренняя структура

«черных ящиков», т.е. задачи, из которых состоят процессы.

Внутренняя структура представляет собой путь, по которому

стандартные процессы в организации применяются в конкрет-

ных проектах. Звено управления и исполнители в необходимой

степени детализации знают свои роли

ответственность

рамках

проекта. Руководство заранее подготовлено к рискам, которые

могут возникнуть в процессе выполнения проекта. Так как стан-

дартизированные и документированные процессы становятся

«прозрачными» для обозрения, сотрудники, непосредственно не

занятые в проекте, могут своевременно получать точные сведе-

ния о его текущем состоянии.

На четвертом уровне выполнение процессов жестко

привязывается к инструментальным средствам,

что

дает возмож-

ность определения количественных характеристик их трудоем-

кости и качества выполнения. Руководители, имея объективную