И. Соммервилл - Инженерия программного обеспечения (1133538), страница 137
Текст из файла (страница 137)
Особое вииманис было удслсно тсм кочиаииэм, которыс иодэли ваньки па фииапсиронаиис провитав от Министерства обороны. Результатом такой работы лвилась модель оцснки уровня рэзвитин в создании ПО. Модель оказалась чрезвычайно эффсктивным средством, сумевшим убсдить сообщсство программистов отнестись балан ссрьсзио к вопросу совсршсиствовапиэ ироцссса разработки ПО. Модель разбиваст процссс создания ПО на пять этапов (рнс. 25.5). т4асть 'Л.
Управление 524 Ркс. 255. Мад ель оценки у)ювял Рлэв иэшл ЯЕ! Первая версия модели оценки уровня развития подверглась жесткой критике эа свою неопределенность. Послс прнобрстения опыта применения этой модели (см. следующий раздел) была разработана ес новая всрсия [273]. В ней были сохранены все пять уровней, однако теперь они более строго соотносились с ключевыми составляющими процссса создания ПО (рнс. 25,6.).
Результатом совершенствования процесса должно быть внсдрс. К 2. 3. 4. 5. начальный у)юзека На этом уровне компания не имеет установленных процедур управления персоналом и планирования проскгов. Даже если формальные процедуры длл контроля над проектами и существуют, нст действующих механизмов про. верки правильности использования этих процедур. Такая компания может успешно заниматься разработкой ПО, однако качество коночного продукта, а также ход выполнения проскта (соблюдснис бюджста и графика работ) предсказать трудно.
У)люень яэээюреквя. В колгпании уже сложился определенный стиль управлснил, имсются систсчы управлспия качсством и конфигурацией. Название уровня обусловлено тем, что на данной стадии органиэация уже способна повторять проекты одного типа. Однако все-таки чувствустся недостаток организационной модсли технологического процесса. Успех проекта зависит в основном от улгсния менеджеров вдохновить команду разработчиков и от воэможности формализовать интуитивно понятный процесс разработки. Ураэель сэюковлекил.
Компания вводит стандартную технологию созданил ПО, обес. псчивая возможность совсршснствованил производственного процесса на количествснном уровне. Приводятся в действие процессуальные нормы, которые гарантируют выполнение стандартного процссса во всех проектах. Уровень управления. Компания уже имеет стандартную технологию создания ПО и программу сбора количественных данных. Накапливаются данныс о показатсллх программных продуктов и процесса производства, которыс впоследствии используются для совершенствования технологии разработки ПО.
У)юзека олтклкэлкик, которым предусматривается опредслснная приверженность организации-разработчика делу непрсрывпого совершенствования процссса созданил ПО. Это означает, что совсршепствование заложено в бюджете и плане дея. тельности организации и является ес нсо гьемлемой частью. 25. Совершенствование производства ПО 525 ние в производство этих ключевых составляющих, а не достижение некоторого уровня, определенного моделью. Такой подход бьи использован при разработке модели оценки уровня развития системы управления требованиями 132 Ц.
Рис. 25.6. Ключевые сосииюелюигие вРоиесси аадииия ПО (©3993 1ЕЕЕ) Работа над моделью оценки уровня развития в ЯЕ1 проводилась с учетом методов стати. стического контроля качества в промышленности. Допуская некоторое сходство между промышленным производством и производством программного обеспечения, я все же не ду. маю, что возможен простой перенос результатов, полученных в промышленности, в сферу разработки ПО. Как уже упоминалось в разделе 2бь1, качество програимного продукта может испытывать на себе влияние личностных факторов, например опыта и знаний программистов.
В этой области деятельности такие факторы не менее важны, чем производственные. Модель БН оценки уровня развития достаточно весома и важна, однако л бы пе сове. товал применять ее как единственную основу, определяющую весь процесс создания ПО. Она была предназначена в основном для компаний, которые занимаются разработкой программных систем для Министерства обороны, и служб, с ним связанных.
Эти системы отличаются большими размерами и длительным сроком эксплуатации, а также сложностью интерфейса с аппаратным обеспечением и другими системами ПО. Над созданием таких систем работают достаточно большие команды программистов, которые должны подчиняться требованиям н стандартам, разработанным Министерством обороны США. Б26 т4асть У1. Управление Первые трн уровня модели БЕ1 относительно легки для понимания. Среди основных составляющих процесса создания ПО есть и те, которые часто применяются в промышленном производстве. Некоторые оршнизации.разработчики в состоянии достигнуть высших уровней модели, однако стандарты и процедуры, используемые на этих уровнях, не всегда понятны широкому кр)ту специалистов [95].
Известны случаи, когда успешно работающая компания пе соответствует модели БЕ1, что вызвано обстоятельствами, присущими только дашюй организации. Проблемы, с которыми органиэация может столкнуться на высших уровнях модели, никоим образом не ставлт под сомнение полезность самой модели БЕ1. Однако на трн основныс проблемы все же стоит обратить внимание.
Именно они могут снизить возможности организации в создании высококачественных продуктов. 1. Модель сосредоточена исключительно на управлении проектом, а не на процессе созданпл программного продукта. В модели пс учтены такие важные факторы, как испол~ зовапие определенных технологий, например прототипирования, формальныхх и структурных методов, средств статического анализа и т.п. 2. В модели отсутствует анзлпз рисков и решений [51]. В главе 1 отмечалась важность оценки рисков, что позволяет обвар)живать проблемы прежде, чем они окажут воздействие на процесс разработки.
Б. Не определена область применения модели, хотя авторы признают, что модель не явллетгя универсальной и подходящей всем органиэациям. Однако авторы пе дают четкого разграничения организаций, которые могут или не могут внедрять модель в свою деятельность. Пебольшис компании находят эту модель слишком бюрократнчной. В ответ па эту «рптику были разработаны стратегии совергяснствования технологического процесса для малых организаций [174]. В рабате [271] проведено сравнение модели оценки уровня развития со стандартами ГБО 9000 управления качеством.
рассмотренными в главе 24. Здесь каждая составляющая процегса из модели оценки )ровня развития сравнивается с требованиями процесса управления качеством (см. табл. 24.1.). В большинстве случаев была отмечена взаилюсвязь междг составллющими процесса модели БЕ1 н требованиями 1БО 9000. Модель БЕ1 более детализирована и предоставляет основу длл совершенствования процесса соэданил ПО, что не предусмотрено в стандартах !БО 9000. Организации, которые дошли до второго пли третьего уровней развития по модели БЕ1, более др)тих соответствуют стандартам 1БО 9000. Однако в связи с определенной абстрактностью станлартов 1БО 9000 организации и на первом уровне развитии могут претендовать па соответствие этим стандартам.
Институт БЕ1 разработал несколько других моделей опенки уровня развития, например; модель оценки уровня развития процесса разработки программных систем (см. главу 2), модель оценки прпобрстешш, предназначенная лля оценки приобретенного организацией прогрзмлшого и аппаратного абеспеченнл, модель оценки уровня развития персонала (см. главу 22) и др. 25.4.1. Оценивание уровня развития Говоря о модели БЕ) оценки уровня развития, иногда забывают о том, что главной цс. лью создвппл модели было намерение Министерства обороны СШЛ оценить возможности поставщиков программного обеспечения.
На данный момент пока не существует чет'- ких требований к достижению определенного уровня развития организаций- разработчиков. Однако принято считать. что у организации, достигшей высокого уровня, больше вшпсов выиграть тендер па поставку ПО. В будущем от компаний потребуется определенный уровень развития (скорее всего, это будет третий уровень по модели БЕ1) для того, чтобы участвовать в тендерах Мпшютсрствэ обороны.
26. Совершенствование пронэводства ПО 627 Модель оценки уровня развития ориентирована в основном на оцениваиие всей организации, а не отдельных проектов. С точки зрения разработчиков, это справедливо. Если организация находится, скажем, на первом уровне модели, это совсем не значит. что ес проекты должны котироваться так жс пивко. Отдельные команды программистов могут работать на более высоком уровне. Основой оценивания уровня организации-разработчика является анкета, которая должна определить ключевые процессы в деятельности организации.
Оиа заполняется путем опроса менеджеров разных проектов. Ответы, занесенные в анкету, анализируются, после чего выводится общий счет. Модель процесса оцени ванна показана на рис. 26.7. Рис. 22 7. )уршзесс опеки вп пил уровня Рпзвиэ~ил п)зги иизп я и и Основной недостаток этого процесса оценивания. иа паш взгляд, состоит в чрезмерном внимании к достижению высокого уровня. Организация обязана выполнить все предписанные ьюделью действия на опредслешюм уровне, только тогда ей будет присвоен этот уровень.
Даже сели орпцшзацня достигла 80% по второму уровню и 70% по третьему, вес равно опа будет котироваться первым уровнем. Здесь уместен более структурированный подход, )читывающий применяемые в данной организации виды деятельности и стандарты. Метод оценивання уровня развития и соверп~енствоваипя пропзволствсппого процесса 5Р1СЕ [272, 106) отличается большей гибкостью. Этот метод был предложен в качестве основы для улучшешш стандарта 15О. В исм были сохранены уровни модели 5Е1, по добавлены другие ключсвыс виды деятельности (например, процесс "заказчик-поставщпк"), которые проходят через все уровни.
Целью проекта Вооснгар было расяшренис н адаптация модели 5Е1 к более широкому кр)тт организаций. И результате появилась одноименная модель )146, 206], в которой сохранены основные принципы подели 5Е1, однако имсетсл ряд нововведений. ° Предлагается система управления качеством для поддержки процесса совершенст- вования производства ПО. ° Проведено разграничение организации, методологии н технологии.
° Предложена базовая модель процесса разработки ПО (создана по образцу модели, используемой в Европейском аэрокосмическом агентстве). Рассматриваемые модели оценки развиваются с учетом всех альтернативных подходов. Я даже предполагаю, что, когда выйдет эта книга, уже будет создана новая версия модели оценки уровня развития, в которую войдут лучшие идеи, имсюьцисся в других моделях. Бу. дем надсятьсл, что именно опа станет признанным стандартом Лля оценнванпя и совершенствования процесса создания ПО. 528 Часть 'Л. Управление 25.5. Классификация процессов совершенствования Как уже отмечалось, классификация процессов совершенствования производства программного обеспечения по модели ЯЕ1 больше подходит для процесса разработки больших и длительно эксплуатируемых систем, создаваемых большими компаниями-разработчиками.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
