Материал: u_lectures

уменьшение объема работы, вызванного проблемами с требованиями;

повышение точности планирования и реалистичности планов;

снижение (исключение) числа ситуаций появления новых требований на

финишных этапах проекта.

Действия по совершенствованию процессов должны планироваться, контролироваться и управляться, как мини-проекты. Это упрощает выделение требуемых ресурсов, отслеживание перемен и оценки результативности изменений.

Процесс совершенствования

На рис. 14-1 показан типовой цикл совершенствования процессов при создании программного обеспечения [8].

Рис. 14-1.

Оценка текущих приёмов

В соответствие с принципом целенаправленности, в работы по совершенствованию необходимо начать с формулировки целей и оценкой, насколько существующие процессы соответствуют данным целям. Для целей оценки применимы известные в бизнесмоделировании и анализе требований методы и приёмы: от проведения интервью и постановочных семинаров до фиксации модели «Как есть».

Эффективным способом является привлечение внешних консультантов, которые могут составить непредвзятый взгляд на положение в вашей компании.

Результатами оценки является список обнаруженных сильных и слабых сторон в текущих процессах, а также, начальные рекомендации по совершенствованию (переходу к модели «Как надо»).

Планирование

Всоответствии с принципом проектного подхода к проведению мероприятий по совершенствованию, для мини-проекта совершенствования необходимо проделать всё то, что обычно делается при инициации проектов: осуществить декомпозицию работ; выделить ресурсы, назначить исполнителей; создать планы работ.

Стратегический план описывает общую программу совершенствования процессов

ввашей организации. Тактические планы действий затрагивают конкретные области совершенствования, например процесс сбора требований или процедуру назначения приоритетов [8]. В каждом плане действий должны быть указаны цели действий по совершенствованию, участники и отдельные задачи. План также дает возможность отслеживать выполнение процесса совершенствования, отмечая выполнение отдельных задач.

Вплане действий не должно быть более 10 пунктов; срок его реализации не должен превышать 2-3 месяца.

Ниже приведёт шаблон декомпозиции задачи управления требованиями [8]. 1. составить проект процедуры управления изменениями; 2. проверить и модифицировать процедуру управления изменениями;

3. провести пробное испытание процедуры управления изменениями для проекта;

4. модифицировать процедуру управления изменениями на основе обратной реакции по пробному испытанию;

5. оценить инструментальные средства выявления проблем и выбрать одно из них для поддержки процедуры управления изменениями;

6. приобрести выбранное инструментальное средство выявления проблем и настроить его для поддержки конкретной процедуры;

7. внедрить новую процедуру управления изменениями и инструментальное средство в организации.

Создание и апробация новых процессов

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

ваших проектах. Известный неполиткорректный принцип «что русскому хорошо – то немцу смерть» на языке современного менеджмента IT-проектов звучит, как «учёт системы ценностей, принятых в команде разработчиков» [43].

Апробация на реальных задачах – единственный гарантированный способ проверить – годится ли тот или иной инструмент для вашей команды. Чтобы не вовлекать в масштабные эксперименты значительные ресурсы существует способ пилотных (пробных) проектов.

К.Вигерс предлагает следующие методические приёмы при апробации новых процессов:

выбирайте для участия в пробных проектах людей, которые будут относиться к новым приемам беспристрастно и смогут дать им оценку. Это могут быть как сторонники, так и скептики, но они не должны быть ярыми противниками предлагаемых приемов;

чтобы результаты было легко истолковать, определите количество критериев, по которым команда будет оценивать пробный проект

определите заинтересованных лиц, которых следует проинформировать о том, что представляет собой пробный проект и почему он выполняется;

подумайте о возможности испытания новых процессов по частям в разных пробных проектах. Так вам удастся вовлечь в испытание больше людей, что увеличивает осведомленность, количество откликов и сторонников;

для более полной оценки поинтересуйтесь у участников пилотных проектов, что бы они почувствовали, если бы им пришлось вернуться к существующим приемам работы.

Оценка результатов и приятие решений.

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

Среди ключевых вопросов в области оценки результатов можно выделить следующие [8].

Насколько гладко прошли пробные проекты и как эффективно они разрешили неопределенности в отношении новых процессов?

Собираетесь ли вы менять что-либо в следующих пилотных проектах?

Как прошло общее внедрение новых технологических процессов?

Удалось ли вам довести до сведения каждого информацию о пользе новых процессов или шаблонов?

Смогли ли участники понять и эффективно применить новые процессы?

Собираетесь ли вы менять что-либо при проведении следующего внедрения? При оценивании результативности достижения поставленных целей следует

различать мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится через значительное время. Необходимо учитывать эффект «кривой обучения» (learning curve) [8]: производительность падает, пока люди приспосабливаются к новым способам работы. Кратковременное падение производительности, иногда называемое «лощиной отчаяния» - в — это часть необходимого вклада, который ваша организация вносит в совершенствование процессов.

Невзирая на все возможные трудности, мероприятия по улучшению качества при внимательном к ним отношении неизбежно приведут к повышению эффективности работы команды.

Литература к лекции

39.Калянов Г. Н. Консалтинг при автоматизации предприятий: Научнопрактическое издание. Серия «Информатизация России на пороге XXI века». —

М.: СИН-ТЕГ, 1997.

40.Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.

41.Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ.

— М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.

42.Руководство по применению стандарта ИСО 9001:2000 при разработке программного обеспечения/ Пер. с англ. А.Л. Раскина. – М.: РИА “Стандарты и качество”, 2002. – 104 с. – (“Дом качества”, вып. 9 (18)).

43.Коберн А. Быстрая разработка программного обеспечения. – М.: Лори, 2002. 314 с.

9. Требования в управлении проектом. Заключение

План лекции

От рамок проекта к экспресс-планированию Планирование проекта на основе требований, путь RUP

Требования в гибких методологиях Артефакты для работы с требованиями в гибких методологиях Планирование версий и итераций

Анализ требований и управление рисками Современные тенденции в развитии АИС и технологий их создания

Покупное или заказное ПО - критерии выбора Стратегии выбора решения Анализ требований

Анализ несоответствия Подход на основе лучших практик

Процесс выбора решения

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

Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например:

Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение?

Кто оплатит работы по анализу требований? (очевидно, Заказчик)

Как быть, если цена вопроса окажется непомерной и от проекта придётся отказаться – кто возместит Заказчику убытки на проведение исследований?

Разумный Заказчик сможет найти выход из этого непростого положения, например:

подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остаётся);

взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в «каскадных» схемах разработки) – путь прогнозирующих методологий

разделив с Разработчикам ответственность за конечный продукт, приготовившись день за днём работать с ним рука об руку вплоть до появления результата – путь гибких (agile) методологий.

От рамок проекта к экспресс-планированию

Начальную, самую грубую оценку проекта можно сделать на основании документа «Видение». Так, шаблон Vision/Scope MSF содержит список ключевых характеристик/функций, критерии приемлемости и (что очень важно) перечень характеристик/функций, которые лежат «вне рамок» проекта. Параллельно с проработкой концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и оцениваются главные риски проекта.

Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в [22] предлагается следующий подход: