Совершенствование процессов работы с требованиями
Парадигма управления качеством, как способ организации производства, появилась давно. Идеи, заложенные в группе стандартов ISO9000 1, уходят корнями, в частности, и в такие "советские" изобретения, как поддержка рационализаторских предложений, наставничества и др.
В современной концепции процессно-ориентированной организации бизнеса процесс непрерывного совершенствования качества занимает одну из ключевых позиций.
Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.
SEI (Software Engineering Institute – Институт программной инженерии) - http://www.sei.cmu.edu. Научно-исследовательский институт, созданный на базе университета Карнеги-Меллона в Питсбурге в рамках деятельности комиссии Министерства обороны США по исследованию проблем, возникающих при разработке программных продуктов в организациях министерства. Наиболее значимые и известные продукты деятельности института – модели зрелости предприятия программной инжинерии CMM, CMMI.
EPC SEI Capability Maturity Model - Integrated [for Software Engineering and Systems Engineering] – модель зрелости для программной и системной инженерии –. http://www.sei.cmu.edu/reports/10tr033.pdf, созданная в развитие модели CMM (гиперссылка на CMM). Унаследовав от CMM описание пяти уровней зрелости организации, дополнительно определяет 22 процессные области (группы процессов программной инженерии). Набор моделей CMMI включает три модели: CMMI for Development (CMMI-DEV) (http://www.sei.cmu.edu/reports/10tr033.pdf), ориентированная на организации, занимающиеся разработкой программного и аппаратного обеспечения, а также комплексных систем; CMMI for Services (CMMI-SVC, http://www.sei.cmu.edu/reports/10tr034.pdf, ориентированная на сервисные службы и CMMI for Acquisition (CMMI-ACQ), ориентированная на организации, приобретающие IT-продукты и услуги. Все они имеют номер 1.3 (ноябрь 2010 года).
|
|
|
Модели совершенствования
ISO9000
Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) [14.1]. Подъем экономики послевоенной Японии во многом был обусловлен идеями, заложенными в TQM.
Качество - термин, который для одних означает необходимость делать то, что желает потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. [14.1].
Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как определить, что работа завершена? Необходимо также продумать, как вы собираетесь управлять данным процессом и как его можно усовершенствовать.
|
|
|
Основные принципы ISO9000:
· Концентрация на потребностях заказчика;
· Активная лидирующая роль руководства;
· Вовлечение исполнителей в процессы совершенствования;
· Реализация процессного подхода;
· Системный подход к управлению;
· Обеспечение непрерывных улучшений;
· Принятие решений на основе фактов;
· Взаимовыгодные отношения с поставщиками.
Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно общий характер и не учитывают специфику предприятий отрасли IT. Для этого были разработаны специализированные подходы, рассмотренные ниже.
SEI-CMM, SEI-CMMI
Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.
Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации - разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в [14.2-14.3]). Данный стандарт получил широкую известность, значительное количество западных IT-компаний сертифицировано по CMM.
|
|
|
В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем [14.3].
CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) соответствует структуре SW-CMM с небольшими уточнениями наименований уровней. Пять уровней зрелости содержат 22 области технологических процессов, показанных в таблице 14.1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation), содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).
В непрерывном представлении вместо уровней зрелости определяются шесть уровней способностей (capability levels) для каждой области технологических процессов. Это представление позволяет каждой организации решать, какой уровень способностей ей соответствует в каждой из 22 областей технологических процессов.
Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая "Управление требованиями", но, в отличие от предыдущего стандарта, на уровне 3 есть и отдельная область "Разработка требований". Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований [14.3].
|
|
|
| Таблица 14.1. | ||
| Уровень зрелости | Название | Области процессов |
| 1 | Начальный | (нет) |
| 2 | Управляемый | Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и анализ Обеспечение качества процессов и продуктов Управление конфигурацией |
| 3 | Определенный | Разработка требований Техническое решение Интеграция продуктов Верификация Валидация Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление риском Анализ и разрешение вопросов |
| 4 | Количественно управляемый | Производительность организационных процессов Количественное управление проектом |
| 5 | Оптимизирующий | Организационные нововведения и их развертывание Случайный анализ и разрешение |
Область процессов "Управление требованиями"
Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых "Свойства требований" ) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования:
· обеспечение записи источников низкоуровневых или вторичных требований;
· трассирование каждого требования вниз, к вторичным требованиям, и его размещение по функциям, объектам, процессам и исполнителям;
· установка горизонтальных связей между требованиями, принадлежащими к одному типу.
Область процессов "Разработка требований"
В CMMI-SE/SW описаны три набора приемов разработки требований:
· приемы, определяющие полный набор требований клиентов, которые затем используются для разработки требований для продукта (выявить нужды заинтересованных в проекте лиц; преобразовать нужды и ограничения в требования клиентов);
· приемы, определяющие полный набор требований для продукта (установить компоненты продукта; разместить требования по компонентам продукта; определить требования к интерфейсу);
· приемы получения вторичных требований, понимания требований и их подтверждения (установить оперативные концепции и сценарии; определить требуемую функциональность системы; проанализировать вторичные требования; оценить стоимость, сроки и риск создания продукта; утвердить требования).
Как в СММ, так и в CMMI формулируются цели, к которым проект или организация по разработке ПО должны стремиться в различных областях процессов. В них также рекомендуются технические приемы, помогающие достичь этих целей.
CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14.1).
Рис. 14.1.
Принципы совершенствования
В [14.3] сформулированы следующие принципы совершенствования качества программных систем:
· поэтапность,
· непрерывность,
· цикличность,
· наличие стимула,
· ориентация на цели,
· проектный подход.
Мероприятия по совершенствованию процессов следует вводить поэтапно. Людям нередко бывает тяжело отказываться от старых привычек, привыкать к новому. Предложенные изменения должны пройти проверку опытом; не все из предложенного обязательно даст эффект, какие-то новации придется пересмотреть, от чего-то - отказаться.
Непрерывность - один из ключевых принципов управления качеством: часто мероприятия проводятся в виде кампании, которая затухает после получения сертификата. Организация, которая стремится к лидерству, должна поддерживать "дух качественной работы" постоянно.
Бизнес-процесс улучшения требований характеризуется цикличностью (см. Процесс совершенствования): его основные этапы повторяются на все более высоком уровне. Циклы оптимизации в софтверных организациях удобно приурочивать к проектам, выполняемых в рабочих группах. Анализ недостатков целесообразно производить тогда, когда они в "оперативной памяти" группы проекта, например - один раз в середине проекта и один - сразу после его окончания. Каждый проект по-своему уникален и несет в себе потенциал для улучшения процессов.
Основным стимулом к изменениям К.Вигерс считает трудности, с которыми столкнулась команда проекта, например:
· разработчики не уложились в график, потому что непонятные и неоднозначные требования попали к ним поздно;
· разработчикам пришлось много работать сверхурочно, потому что непонятные или расплывчатые требования были уточнены слишком поздно в процессе разработки;
· попытка тестирования системы не удалась, потому что тестировщики не понимали, что продукт должен делать;
· нужная функциональность была реализована, но пользователи не удовлетворены вялой производительностью, неудобством работы или другими недостатками качества продукта;
· организации пришлось пойти на высокие расходы на сопровождение, потому что клиентам потребовалась масса дополнительных функций, которые следовало определить во время составления требований;
· организация-разработчик ПО приобрела плохую репутацию поставщика продуктов, которые не нравятся клиентам.
Изменения технологических процессов должны быть целеориентированы. Примеры целей:
· уменьшение объема работы, вызванного проблемами с требованиями;
· повышение точности планирования и реалистичности планов;
· снижение (исключение) числа ситуаций появления новых требований на финишных этапах проекта.
Действия по совершенствованию процессов должны планироваться, контролироваться и управляться, как мини-проекты. Это упрощает выделение требуемых ресурсов, отслеживание перемен и оценки результативности изменений.
Процесс совершенствования
На рис. 14.2 показан типовой цикл совершенствования процессов при создании программного обеспечения [14.3].
Рис. 14.2.
Оценка текущих приемов
В соответствии с принципом целенаправленности, в работы по совершенствованию необходимо начать с формулировки целей и оценкой, насколько существующие процессы соответствуют данным целям. Для целей оценки применимы известные в бизнес-моделировании и анализе требований методы и приемы: от проведения интервью и постановочных семинаров до фиксации модели "Как есть".
Эффективным способом является привлечение внешних консультантов, которые могут составить непредвзятый взгляд на положение в вашей компании.
Результатами оценки является список обнаруженных сильных и слабых сторон в текущих процессах, а также, начальные рекомендации по совершенствованию (переходу к модели "Как надо").
Планирование
В соответствии с принципом проектного подхода к проведению мероприятий по совершенствованию, для мини-проекта совершенствования необходимо проделать все то, что обычно делается при инициации проектов: осуществить декомпозицию работ; выделить ресурсы, назначить исполнителей; создать планы работ.
Стратегический план описывает общую программу совершенствования процессов в вашей организации. Тактические планы действий затрагивают конкретные области совершенствования, например процесс сбора требований или процедуру назначения приоритетов [14.3]. В каждом плане действий должны быть указаны цели действий по совершенствованию, участники и отдельные задачи. План также дает возможность отслеживать выполнение процесса совершенствования, отмечая выполнение отдельных задач.
В плане действий не должно быть более 10 пунктов; срок его реализации не должен превышать 2-3 месяца.
Ниже приведен шаблон декомпозиции задачи управления требованиями [14.3].
1. составить проект процедуры управления изменениями;
2. проверить и модифицировать процедуру управления изменениями;
3. провести пробное испытание процедуры управления изменениями для проекта;
4. модифицировать процедуру управления изменениями на основе обратной реакции по пробному испытанию;
5. оценить инструментальные средства выявления проблем и выбрать одно из них для поддержки процедуры управления изменениями;
6. приобрести выбранное инструментальное средство выявления проблем и настроить его для поддержки конкретной процедуры;
7. внедрить новую процедуру управления изменениями и инструментальное средство в организации.
Дата добавления: 2021-03-18; просмотров: 99; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!