Ис. Конспект лекций Маглинец Ю. А. Красноярск сфу 2007 Введение. Понятие и классификация требований
 Скачать 0.88 Mb.
|
|
Табл. 13-2. Другая форма представления связей трассируемости – дерево трассировок [15]. Литература к лекции 34. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил. 35. Л.Новиков. Введение в Rational Unified Process. http://www.interface.ru/rational/interface/151199/rup/main.htm 36. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002. 37. Соммервилл, Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 624 с.: ил. – Парал. тит. англ. 38. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005. http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf 8. Совершенствование процессов работы с требованиями План лекции Модели совершенствования ISO9000 SEI-CMM, SEI-CMMI Принципы совершенствования Процесс совершенствования Оценка текущих приёмов Планирование Создание и апробация новых процессов Оценка результатов и приятие решений Парадигма управления качеством, как способ организации производства, появилась давно. Идеи, заложенные в группе стандартов ISO9000 28 , уходят корнями, в частности, и в такие «советские» изобретения, как поддержка рационализаторских предложений, наставничества и др. В современной концепции процессно-ориентированной организации бизнеса процесс непрерывного совершенствования качества занимает одну из ключевых позиций. Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT. Модели совершенствования ISO9000 Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) [39]. Подъём экономики послевоенной Японии во многом был обусловлен идеям, заложенным в TQM. Качество – термин, который для одних означает необходимость делать то, что желает потребитель, для других — то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. [39]. Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как определить, что работа завершена? Необходимо также продумать, как вы собираетесь управлять данным процессом и как его можно усовершенствовать. 28 Наиболее распространённые стандарты в области управления качеством Основные принципы ISO9000: Концентрация на потребностях заказчика; Активная лидирующая роль руководства; Вовлечение исполнителей в процессы совершенствования; Реализация процессного подхода; Системный подход к управлению; Обеспечение непрерывных улучшений; Принятие решений на основе фактов; Взаимовыгодные отношения с поставщиками. Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно общий характер и не учитывают специфику предприятий отрасли IT. Для этого были разработаны специализированные подходы, рассмотренные ниже. SEI-CMM, SEI-CMMI Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон. Назначение стандарта – оценка уровня «зрелости» (maturity levels) организации – разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определённый, управляемый и оптимизирующий (подробнее см. в [22-8]). Данный стандарт получил широкую известность, значительное количество западных IT- компаний сертифицировано по CMM. В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем [8]. 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 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований [8]. Табл. 14-1 Уровень зрелости Название Области процессов 1 Начальный (нет) 2 Управляемый Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и анализ Обеспечение качества процессов и продуктов Управление конфигурацией 3 Определённый Разработка требований Техническое решение Интеграция продуктов Верификация Валидация Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление риском Анализ и разрешение вопросов 4 Количественно управляемый Производительность организационных процессов Количественное управление проектом 5 Оптимизирующий Организационные нововведения и их развёртывание Случайный анализ и разрешение Область процессов «Управление требованиями». Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых свойств требований ) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования: обеспечение записи источников низкоуровневых или вторичных требований; трассирование каждого требования вниз, к вторичным требованиям, и его размещение по функциям, объектам, процессам и исполнителям; установка горизонтальных связей между требованиями, принадлежащими к одному типу. Область процессов «Разработка требований». В CMMI-SE/SW описаны три набора приемов разработки требований: приемы, определяющие полный набор требований клиентов, которые затем используются для разработки требований для продукта (выявить нужды заинтересованных в проекте лиц; преобразовать нужды и ограничения в требования клиентов); приемы, определяющие полный набор требований для продукта (установить компоненты продукта; разместить требования по компонентам продукта; определить требования к интерфейсу); приемы получения вторичных требований, понимания требований и их подтверждения (установить оперативные концепции и сценарии; определить требуемую функциональность системы; проанализировать вторичные требования; оценить стоимость, сроки и риск создания продукта; утвердить требования). Как в СММ, так и в CMMI формулируются цели, к которым проект или организация по разработке ПО должны стремиться в различных областях процессов. В них также рекомендуются технические приемы, помогающие достичь этих целей. CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14-1). Разработка требований Управления требованиями Планирование проекта Мониторинг и контроль проекта Управление конфигурациями Техническое решение Интеграция продуктов Управление риском Верификация Валидация Рис. 14-1 Принципы совершенствования В [8] сформулированы следующие принципы совершенствования качества программных систем: поэтапность, непрерывность, цикличность, наличие стимула, ориентация на цели, проектный подход. Мероприятия по совершенствованию процессов следует вводить поэтапно. Людям нередко бывает тяжело отказываться от старых привычек, привыкать к новому. Предложенные изменения должны пройти проверку опытом; не всё из предложенного обязательно даст эффект, какие-то новации придётся пересмотреть, от чего-то – отказаться. Непрерывность – один из ключевых принципов управления качеством: часто мероприятия проводятся в виде кампании, которая затухает после получения сертификата. Организация, которая стремится к лидерству, должна поддерживать «дух качественной работы» постоянно. Бизнес-процесс улучшения требований характеризуется цикличностью (см. Процесс совершенствования ): его основные этапы повторяются на всё более высоком уровне. Циклы оптимизации в софтверных организациях удобно приурочивать к проектам, выполняемых в рабочих группах. Анализ недостатков целесообразно производить тогда, когда они в «оперативной памяти» группы проекта, например – один раз в середине проекта и один – сразу после его окончания. Каждый проект по-своему уникален и несёт в себе потенциал для улучшения процессов. Основным стимулом к изменениям К.Вигерс считает трудности, с которыми столкнулась команда проекта, например: разработчики не уложились в график, потому что непонятные и неоднозначные требования попали к ним поздно; разработчикам пришлось много работать сверхурочно, потому что непонятные или расплывчатые требования были уточнены слишком поздно в процессе разработки; попытка тестирования системы не удалась, потому что тестировщики не понимали, что продукт должен делать; нужная функциональность была реализована, но пользователи не удовлетворены вялой производительностью, неудобством работы или другими недостатками качества продукта; организации пришлось пойти на высокие расходы на сопровождение, потому что клиентам потребовалась масса дополнительных функций, которые следовало определить во время составления требований; организация-разработчик ПО приобрела плохую репутацию поставщика продуктов, которые не нравятся клиентам. Изменения технологических процессов должны быть целеориентированы. Примеры целей: уменьшение объема работы, вызванного проблемами с требованиями; повышение точности планирования и реалистичности планов; снижение (исключение) числа ситуаций появления новых требований на финишных этапах проекта. Действия по совершенствованию процессов должны планироваться, контролироваться и управляться, как мини-проекты. Это упрощает выделение требуемых ресурсов, отслеживание перемен и оценки результативности изменений. Процесс совершенствования На рис. 14-1 показан типовой цикл совершенствования процессов при создании программного обеспечения [8]. Оценка текущих приёмов Планирование действий по совершенствованию Открытия и рекомендации Создание и апробация новых технологических процессов Оценка результатов План действий Новые процессы; Результаты апробации; Опыт внедрения План следующего цикла совер- шенствования Рис. 14-1. Оценка текущих приёмов В соответствие с принципом целенаправленности, в работы по совершенствованию необходимо начать с формулировки целей и оценкой, насколько существующие процессы соответствуют данным целям. Для целей оценки применимы известные в бизнес- моделировании и анализе требований методы и приёмы: от проведения интервью и постановочных семинаров до фиксации модели «Как есть». Эффективным способом является привлечение внешних консультантов, которые могут составить непредвзятый взгляд на положение в вашей компании. Результатами оценки является список обнаруженных сильных и слабых сторон в текущих процессах, а также, начальные рекомендации по совершенствованию (переходу к модели «Как надо»). Планирование В соответствии с принципом проектного подхода к проведению мероприятий по совершенствованию, для мини-проекта совершенствования необходимо проделать всё то, что обычно делается при инициации проектов: осуществить декомпозицию работ; выделить ресурсы, назначить исполнителей; создать планы работ. Стратегический план описывает общую программу совершенствования процессов в вашей организации. Тактические планы действий затрагивают конкретные области совершенствования, например процесс сбора требований или процедуру назначения приоритетов [8]. В каждом плане действий должны быть указаны цели действий по совершенствованию, участники и отдельные задачи. План также дает возможность отслеживать выполнение процесса совершенствования, отмечая выполнение отдельных задач. В плане действий не должно быть более 10 пунктов; срок его реализации не должен превышать 2-3 месяца. Ниже приведёт шаблон декомпозиции задачи управления требованиями [8]. 1. составить проект процедуры управления изменениями; 2. проверить и модифицировать процедуру управления изменениями; 3. провести пробное испытание процедуры управления изменениями для проекта; 4. модифицировать процедуру управления изменениями на основе обратной реакции по пробному испытанию; 5. оценить инструментальные средства выявления проблем и выбрать одно из них для поддержки процедуры управления изменениями; 6. приобрести выбранное инструментальное средство выявления проблем и настроить его для поддержки конкретной процедуры; 7. внедрить новую процедуру управления изменениями и инструментальное средство в организации. Создание и апробация новых процессов Принцип поэтапности призывает не делать «революций» в совершенствовании процессов. Любая новация, описание которой найдено в литературе, заимствована из опыта коллег или разработана лично вами, должна пройти испытание на вашей команде и ваших проектах. Известный неполиткорректный принцип «что русскому хорошо – то немцу смерть» на языке современного менеджмента IT-проектов звучит, как «учёт системы ценностей, принятых в команде разработчиков» [43]. Апробация на реальных задачах – единственный гарантированный способ проверить – годится ли тот или иной инструмент для вашей команды. Чтобы не вовлекать в масштабные эксперименты значительные ресурсы существует способ пилотных (пробных) проектов. К.Вигерс предлагает следующие методические приёмы при апробации новых процессов: выбирайте для участия в пробных проектах людей, которые будут относиться к новым приемам беспристрастно и смогут дать им оценку. Это могут быть как сторонники, так и скептики, но они не должны быть ярыми противниками предлагаемых приемов; чтобы результаты было легко истолковать, определите количество критериев, по которым команда будет оценивать пробный проект определите заинтересованных лиц, которых следует проинформировать о том, что представляет собой пробный проект и почему он выполняется; подумайте о возможности испытания новых процессов по частям в разных пробных проектах. Так вам удастся вовлечь в испытание больше людей, что увеличивает осведомленность, количество откликов и сторонников; для более полной оценки поинтересуйтесь у участников пилотных проектов, что бы они почувствовали, если бы им пришлось вернуться к существующим приемам работы. Оценка результатов и приятие решений. Оценка результатов апробации новых процессов должна показать – достигнуты ли поставленные цели, стоит ли осуществлять широкомасштабное внедрение новаций, апробированных на пилотном проекте, либо «овчинка выделки не стоит». Среди ключевых вопросов в области оценки результатов можно выделить следующие [8]. Насколько гладко прошли пробные проекты и как эффективно они разрешили неопределенности в отношении новых процессов? Собираетесь ли вы менять что-либо в следующих пилотных проектах? Как прошло общее внедрение новых технологических процессов? Удалось ли вам довести до сведения каждого информацию о пользе новых процессов или шаблонов? Смогли ли участники понять и эффективно применить новые процессы? Собираетесь ли вы менять что-либо при проведении следующего внедрения? При оценивании результативности достижения поставленных целей следует различать мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится через значительное время. Необходимо учитывать эффект «кривой обучения» (learning curve) [8]: производительность падает, пока люди приспосабливаются к новым способам работы. Кратковременное падение производительности, иногда называемое «лощиной отчаяния» - в — это часть необходимого вклада, который ваша организация вносит в совершенствование процессов. Невзирая на все возможные трудности, мероприятия по улучшению качества при внимательном к ним отношении неизбежно приведут к повышению эффективности работы команды. |