27.4.1. Оценивание уровня развития
Говоря о модели SEI оценки уровня развития, иногда забывают о том, что главной целью создания модели было намерение Министерства обороны США оценить возможности поставщиков программного обеспечения. На данный момент пока не существует четких требований к достижению определенного уровня развития организаций-разработчиков. Однако принято считать, что у организации, достигшей высокого уровня, больше шансов выиграть тендер на поставку ПО. В будущем от компаний потребуется определенный уровень развития (скорее всего, это будет третий уровень по модели SEI) для того, чтобы участвовать в тендерах Министерства обороны.
Модель оценки уровня развития ориентирована в основном на оценивание всей организации, а не отдельных проектов. С точки зрения разработчиков, это справедливо. Если организация находится, скажем, на первом уровне модели, это совсем не значит, что ее проекты должны котироваться так же низко. Отдельные команды программистов могут работать на более высоком уровне.
Основой оценивания уровня организации-разработчика является анкета, которая должна определить ключевые процессы в деятельности организации. Она заполняется путем опроса менеджеров разных проектов. Ответы, занесенные в анкету, анализируются, после чего выводится общий счет. Модель процесса оценивания показана на рис. 27.7.
Рис. 27.7. Процесс оценивания уровня развития организации
Основной недостаток этого процесса оценивания, на наш взгляд, состоит в чрезмерном внимании к достижению высокого уровня. Организация обязана выполнить все предписанные моделью действия на определенном уровне, только тогда ей будет присвоен этот уровень. Даже если организация достигла 80% по второму уровню и 70% по третьему, все равно она будет котироваться первым уровнем. Здесь уместен более структурированный подход, учитывающий применяемые в данной организации виды деятельности и стандарты.
Метод оценивания уровня развития и совершенствования производственного процесса SPICE отличается большей гибкостью. Этот метод был предложен в качестве основы для улучшения стандарта ISO. В нем были сохранены уровни модели SEI, но добавлены другие ключевые виды деятельности (например, процесс "заказчик-поставщик"), которые проходят через все уровни.
Целью проекта Bootstrap было расширение и адаптация модели SEI к более широкому кругу организаций. В результате появилась одноименная модель, в которой сохранены основные принципы модели SEI, однако имеется ряд нововведений.
• Предлагается система управления качеством для поддержки процесса совершенствования производства ПО.
• Проведено разграничение организации, методологии и технологии.
• Предложена базовая модель процесса разработки ПО (создана по образцу модели, используемой в Европейском аэрокосмическом агентстве).
Рассматриваемые модели оценки развиваются с учетом всех альтернативных подходов.
27.5. Классификация процессов совершенствования
Классификация процессов совершенствования производства программного обеспечения по модели SEI больше подходит для процесса разработки больших и длительно эксплуатируемых систем, создаваемых большими компаниями-разработчиками. Для малых и средних компаний-разработчиков данная модель подходит не в полной мере.
Вместо того чтобы разбивать процесс совершенствования производства на уровни и строить между ними нестойкие взаимосвязи, рациональнее, по моему мнению, применить обобщенную классификацию процессов совершенствования производства, которая подходит большинству организаций и программных проектов.
Можно выделить несколько общих типов процессов совершенствования:
1. Неформальный процесс. Не имеет четко выраженной модели совершенствования производства. Его с успехом может использовать отдельная команда разработчиков. Неформальность процесса никоим образом не исключает такие формальные действия, как управление конфигурацией; однако при этом сами действия и их взаимосвязи не предопределены заранее.
2. Управляемый процесс. Имеет подготовленную модель, которая управляет процессом совершенствования. Модель определяет действия, их график и взаимосвязи между ними.
3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными CASE-средства поддержки проектирования и анализа процессов.
4. Процесс непосредственного совершенствования. Имеет четко поставленную цель совершенствования технологического процесса, для чего существует отдельная строка в бюджете организации и определены нормы и процедуры внедрения нововведений. Частью такого процесса является количественный анализ процесса совершенствования.
Эту классификацию не назовешь четкой и исчерпывающей - некоторые процессы могут одновременно относиться к нескольким типам. Например, неформальность процесса является выбором команды разработчиков. Эта же команда может выбрать определенную методику разработки, имея при этом все возможности непосредственного совершенствования процесса. Такой процесс подпадает под классификацию неформальный, методически обоснованный, непосредственного совершенствования.
Необходимость приведенной классификации обусловлена тем, что она предоставляет своего рода костяк для комплексного совершенствования технологии создания ПО и дает возможность организации выбирать разные типы процессов совершенствования. На рис. 27.8 показаны соотношения между разными типами программных систем и процессами совершенствования их разработки.
Знание типа разрабатываемого продукта сделает соответствие между программными системами и процессами совершенствования, показанное на рис. 27.8, полезным при выборе процесса совершенствования. Например, требуется создать программу поддержки перехода ПО с одной компьютерной платформы на другую. Такая программа имеет достаточно короткий срок эксплуатации, поэтому в ее разработке не требуются стандарты и специальное управление процессом совершенствования, как при создании долгоживущих систем.
Многие технологические процессы в наше время имеют CASE-средства поддержки, поэтому их можно назвать поддерживаемыми процессами. Методически обоснованные процессы поддерживаются инструментальными средствами анализа и проектирования. Эффективность средства поддержки зависит от применяемого процесса совершенствования. Например, в неформальном процессе могут использоваться типовые средства поддержки (средства прототипирования, компиляторы, средства отладки, текстовые процессоры и т.п.). Вряд ли в неформальных процессах будут использоваться на постоянной основе более специализированные средства поддержки.
Рис. 27.8. Применимость процессов совершенствования
На рис. 27.9 показан широкий спектр средств поддержки, применяемых при разработке ПО. Эффективность отдельных средств напрямую зависит от типа выбранного процесса совершенствования. Например, с финансовой точки зрения только инструментальные средства анализа и проектирования подойдут для сопровождения методически обоснованного процесса. Специализированные средства применяются для совершенствования определенных процессов разработки ПО.
Рис. 27.9. Средства поддержки процессов совершенствования