WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 33 |

принят и введен в действие постановлением Госстандарта России от декабря 1999 г. № 675-ст. Стандарт устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Стандарт определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов.

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

Группа стандартов ISO Серия стандартов ISO 9000:2000 устанавливает общие требования к системе менеджмента качества любой организации, желающей продемонстрировать свою способность стабильно давать продукцию, отвечающую требованиям потребителя и соответствующим нормативным требованиям, и способствующую повышению степени удовлетворенности потребителя. Стандарт основан на трех основополагающих идеях:

• ориентация на потребителя, • процессный подход, • постоянное улучшение.

Ориентация на потребителя означает, что качество (продукта, услуги) определяется как степень удовлетворенности потребителя.

Вопросы организации взаимодействия с потребителем занимают важное место в стандарте.

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

Принцип постоянного улучшения требует, чтобы все основные процессы были измеримыми и чтобы были установлены и определены процессы постоянного улучшения основных процессов.

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

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

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

Группа стандартов CMM/CMMI Группа стандартов CMM/CMMI была создана SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета КарнегиМеллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше — основные его положения были опубликованы еще в 1986 г. Основная идея стандарта состоит в использования модели CMM (Capability Maturity Model — модель зрелости возможностей) для приписывания каждой организации определенного уровня, с тем, чтобы организации можно было бы сравнивать по уровням. Список уровней приведен в таблице 2.

Таблица 3.

Уровни модели CMM № Название уровня Ключевые области процесса уровня 1 Начальный Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено 2 Повторяющийся Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями 3 Определенный Экспертные оценки. Координация взаимодействий проектных групп.

Инженерия программного продукта.

Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса 4 Управляемый Менеджмент качества ПО. Управление процессом на основе количественных методов 5 Оптимизируемый Управление изменением процесса.

Управление технологическими изменениями. Предотвращение дефектов Деление на уровни позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (таблица 3).

Таблица 4.

Развитие стандартов CMM System Ориентирован на вопросы системного инжиниринга Engineering CMM – разработку продуктов (анализ требований, (SE-CMM) проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование) Trusted CMM (T- Предназначен для обслуживания чувствительных и CMM) закрытых программных систем, которые требуют гарантии высокого качества ПО System Security Сфокусирован на аспектах безопасности Engineering CMM программной инженерии, обеспечивает безопасный (SSE-CMM) процесс разработки, в том числе и безопасность членов команды создателей People CMM (P- Рассматривает вопросы развития персонала в CMM) софтверных организациях Software Охватывает вопросы приобретения программных Acquisition CMM продуктов у внешних организаций (SA-CMM) Integrated Product Служит средой для интеграции усилий по Development разработке на всех этапах жизненного цикла и со CMM (IPD-CMM) стороны каждого отдела компании Однако практическое применение стандартов серии CMM показало, что они не обеспечивают безоговорочного успеха в разработке ПО. Эти стандарты не были хорошо согласованы между собой — одновременное внедрение различных модификаций CMM могло оказаться достаточно сложной задачей и приводило в недоумение специалистов организаций, которые с этим сталкивались.

Также существенная проблема CMM состоит в необходимости «выравнивания» всех процессов. Если организация пытается сертифицироваться на определенный уровень, то она должна обеспечить соответствующий уровень для всех своих процессов. Даже если специфика, методология или особенности разработки не располагают к выполнению определенных процессов, сертификация этого требует.

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI — Capability Maturity Model Integrated (CMMI) — Интегрированная модель зрелости возможностей. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее потребностям, стандарт CMMI имеет две формы представления — классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов. В таблице 4 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 5.

Соответствие уровней СММ и CMMI № Уровень Уровень зрелости Уровень уровня зрелости CMM многоуровневого возможностей представления непрерывного CMMI представления CMMI 0 – – Незавершенный 1 Начальный Начальный Выполнимый 2 Повторяющийся Управляемый Управляемый 3 Определенный Определенный Определенный 4 Управляемый Управляемый Управляемый количественно количественно 5 Оптимизируемый Оптимизируемый Оптимизируемый Стандарт SPICE Аббревиатура SPICE раскрывается как Software Process Improvement and Capability dEtermination. Основные цели SPICE:

• удовлетворение растущих потребностей в оценке возможностей процессов производства программного обеспечения в подразделениях;

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

Проект SPICE был начат ISO в июле 1991 года и к настоящему времени объединил лучшие из существующих в мире практик. В основу SPICE легли такие стандарты, как:

• STD (Compita);

• CMM (SEI);

• TRILLIUM (Bell);

• SQPA (HP);

• BootStrap (Esprit);

• HealthCheck (BT);

• ISO 9001;

• SAM (BT).

В отличие от одномерной модели CMM архитектура SPICE двумерна и состоит из так называемых «уровней возможностей», их насчитывается 6 (плюс 9 атрибутов процессов и 32 правила менеджмента); категорий процессов (5) и типовых процессов (29), а также наилучших известных практик (best known practices, их более 200). Центральной идеей SPICE является оценивание возможностей не одним числом, как в CMM, а путем построения так называемого профиля организации. Сама организация может проанализировать свою деятельность, выявить, какие из наилучших практик в ней применяются, а какие нет, и построить профиль — кривую, наглядно показывающую, в каких областях деятельности организация сильна, и где в ней узкие места. Наличие масштабируемого механизма самооценки является важнейшим достоинством SPICE. В таблице 5 проведено сравнение механизма самооценки SPICE и процедуры аудита в ISO 9000.

Таблица 6. Сравнение самооценки и аудита Самооценка Аудит Детальные критерии Абстрактные критерии Внутреннее участие Внешний, независимый Постоянная Краткий Позитивное суждение Негативное суждение Поиск фактов Поиск ошибок Взаимодействие Противостояние Открытость Защита Общее обсуждение Индивидуальные интервью SPICE предлагает достаточно подробную модель, предоставляющую пользователям свободу в выборе путей к улучшению работы. Модель улучшения процессов в SPICE трехмерна, где по одной оси откладывается Эффективность работы (удовлетворенность заказчиков, качество продукции и продуктивность), по другой — Возможности персонала, и по третьей — Адекватность процесса. Таким образом, можно выбирать траекторию улучшения процесса в трехмерном пространстве, где улучшения по каждой из осей идут параллельно с улучшениями по другой. Собственно, параллельность не является требованием, это, скорее, рекомендация, позволяющая избежать серьезных перекосов в процессе производства.

Хотя, как уже говорилось, SPICE вобрал в себя все самое лучшее из целого ряда популярных стандартов, он не стал простым их объединением. Для того чтобы показать, чем же SPICE отличается от своих предшественников, целесообразно провести сопоставление SPICE и других наиболее известных стандартов.

Таблица 7.

Сравнение SPICE и ISO SPICE ISO Развитая документация Малая документация Детальная модель Абстрактная модель Разработан для производства ПО Разработан для производства в целом Улучшение процессов и оценка Сертификация возможностей Требования к самооценке, Не содержит руководство по применению Дополняет ISO 9001 Дополнятся SPICE Таблица 8.

Сравнение SPICE и CMM SPICE CMM Двумерная структура Последовательная, одномерная структура Допускает гибкость в выработке Содержит предопределенный путь стратегии улучшения развития Уровни возможностей для каждого Единый уровень зрелости для всех процесса процессов Результаты требуют упрощения Результаты легко понимаемы Результаты очень подробные Упрощенные результаты 4.8. Заключение Менеджмент проектов по разработке программного продукта требует ясного осознания области эффективного применения, учета типа программного продукта, выбора подходящей модели жизненного цикла, знания соответствующих стандартов и проведения комплекса работ по внедрению.

4.9. «Карта памяти» по теме 4.10. Список использованной и рекомендованной литературы 1. Баранов С. Н. Управление программным проектом.

Лекции по спецкурсу "Технология программирования". - СПб: Санкт-Петербургский государственный электротехнический университет, рукопись, 1998.

2. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - СПб.: Символ-Плюс, 1999.

3. Эдвард Йордон. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. - М.: ЛОРИ, 2001.

4. Conger, Sue A. The New Software Engenering. Wadsworth Publishing Company, 1994.

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.