Читаем Модель зрелости процессов разработки программного обеспечения полностью

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

Ожидается, что организации, достигающие наиболее высоких уровней зрелости CMM, должны обладать процессом, который способен производить ПО высокой надежности с предсказуемыми затратами и в пределах рабочих графиков. По мере роста понимания того, как достигаются наиболее высокие уровни зрелости, одни существующие группы ключевых процессов будут уточнены, а другие могут быть добавлены в модель. Концепция CMM произошла из идей о процессах, впервые появившихся в промышленности, но, в отличие от промышленных процессов, процессы разработки не заостряют внимание на тиражировании своей продукции — они нацелены на вопросы проектирования и являются наукоемкой деятельностью [Curtis 88].

Рис. 2.2. Трехфазная диаграмма Джурана: планирование, контроль и улучшение качества

<p>2.3. Представление о производственном процессе</p>

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

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

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

Требования поступают в производственный процесс неконтролируемым образом, что отражается на продукте. Разработка ПО часто представляется чем-то сродни черной магии (особенно менеджерами, слабо знакомыми с программным обеспечением).

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

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

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

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT