1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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

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 при поддержке правительственных структур США и Организаций-разработчиков ПО постоянно раз­ вивает и совершенствует эту модель, учитывая все новейшие дос­ тижения в области создания и сопровождения ПО.

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

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

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

75

рами США. СММ не является предписанием, она не предписы­ вает организации, каким образом развиваться. СММ описывает характеристики организации для каждого из уровней технологи­ ческой зрелости, не давая каких-либо инструкций как перехо­ дить с уровня на уровень. Организации может потребоваться нес­ колько лет для перехода с первого на второй уровень и совсем ма­ ло времени для перехода с уровня на уровень далее. Процесс со­ вершенствования технологии создания ПО отражается в страте­ гических планах организации, ее структуре, используемых техно­ логиях, общей социальной культуре и системе управления.

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

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

Постоянное процессы совершенствование (optimizing)

процессов J

Управляемые

процессы Прогнозирование (managed)

результатов

Стандартныепроцессы iT Стандартизация (defined)

процессов ff

Повторяемые

процессы Упорядочение (repeatabfe)

процессов — —

Начальный уровень f—' (Initial)

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

76 Глава 1

ти СММ. Надписи на стрелках определяют особенности совер­ шенствования процессов при переходе с уровня на уровень.

Уровни со второго по пятый могут характеризоваться через операции, направленные на стандартизацию и (или) модерниза­ цию процессов создания ПО, и через операции, составляющие сами процессы его создания. При этом первый уровень является как бы базой, фундаментом для сравнительного анализа верхних уровней.

На уровне 1 (начальном) основные процессы создания и сопровождения ПО носят случайный характер и выполняются хаотично. Успех выполнения проекта всецело зависит от индиви­ дуальных усилий персонала. На этом уровне, как правило, в орга­ низации не существует стабильной среды, необходимой для соз­ дания и сопровождения ПО.

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

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

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

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

77

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

Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов (key process areas — КРА). Модель СММ содержит 18 таких групп, пос­ ледняя версия модели CMMI — 20 фупп. Уровень 2 СММ харак­ теризуется наличием в организации следующих процессов (их наименования соответствуют CMMI):

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

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

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

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

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

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

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

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

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

78

Глава 1

На данном уровне к процессам уровня 2 добавляются следую­ щие процессы:

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

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

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

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

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

•обучение;

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

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

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

Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффек­ тивности выполнения проектов. На этом уровне в организации создается специальная фуппа, ответственная за состав операций, из которых состоят процессы, — фуппа по разработке процессов создания ПО (software engineering process group — SEPG).

Ha основе единой технологии для каждого проекта могут раз­ рабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные про­ цессы создания ПО» (project's defined software process).

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

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

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

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

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

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

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

79

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

В рамках всей организации разрабатывается единая програм­ ма количественного контроля производительности создания ПО

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

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

Результаты выполнения процессов на четвертом уровне ста­ новятся предсказуемы, поскольку они измеряемы и варьируются в рамках заданных количественных офаничений. На этом уровне появляется возможность заранее планировать заданное качество выполнения процессов и конечной продукции.

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

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

•внедрение технологических и организационных инноваций;

•причинно-следственный анализ и разрешение проблем. Процессы создания и сопровождения ПО характеризуются

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

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

80

Глава 1

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

Каждый последующий уровень дополнительно обеспечивает более полную обозримость самих процессов создания и сопро­ вождения ПО.

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

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

На третьем уровне определена внутренняя структура «черных ящиков», т.е. задачи, из которых состоят процессы. Внутренняя структура представляет собой путь, по которому стандартные процессы в организации применяются в конкрет­ ных проектах. Звено управления и исполнители в необходимой степени детализации знают свои роли и ответственность в рамках проекта. Руководство заранее подготовлено к рискам, которые могут возникнуть в процессе выполнения проекта. Так как стан­ дартизированные и документированные процессы становятся «прозрачными» для обозрения, сотрудники, непосредственно не занятые в проекте, могут своевременно получать точные сведе­ ния о его текущем состоянии.

На четвертом уровне выполнение процессов жестко привязывается к инструментальным средствам, что дает возмож­ ность определения количественных характеристик их трудоем­ кости и качества выполнения. Руководители, имея объективную