10.а

Менеджмент разработки
программных изделий
10.а
Концептуальная база проекта как
основа его развития
1
Понятие концептуальной базы проекта
Необходимо согласование интересов всех инициаторов работ
Это согласование целесообразно выделить как специальную деятельность
системы
Концептуальная база (неформально) — стихийно или целенаправленно
формируемый
свод
понятий,
Описание
того,
поставок
что
врабочих
данном
каким
образом правил и соглашений в коллективе разработчиков,
который организует исполнителей
проекта: того,
намерения
превращаются в
Описание
как в данном
продуктов
проекте
понимается
в
последовательности,
под
предполагается
действовать
в
конкретные виды согласованныхпроекте
активностей
проверяются рабочие
которая
качеством
наиболее
продукта
целесообразна
и
процесса
ситуациях, которые
по различным
Неосознанность
формирования
vs
документальное
фиксирование
Описание
того,
какие
показатели Статические
Описание системы
продукты
и
как
они
оцениваются
для
его
производства,
достижения
решения
а
также
задач
мер,
причинам
грозят
срывом
работ
Что
фиксировать?
Зависит
Как
фиксировать?
рабочих
продуктов измеряются, и изменяемые
деятельностей
проекта
как от:
автоматизации
которые
предполагаются
пользовательской
для
– специфики
– виспециальном(ых)
Описание
какиедокументе(ах)
связи между (дополняемые)
как
когдатого,
это осуществляется
единого
целого,проекта
связанного
деятельности
достижения
качества
– выбранной
– неформально
(+ и –) имеются, в дальнейшем
рабочими
продуктами
между
собой и методологии
с окружением
документы
(Общий) план развития проекта и концептуальная
база
какие из них считаются
планы по направлениям (конкретизация
зависит от методологии)
существенными,
как и когда они
Стратегии развития проекта (возможные
и предпочтительные варианты)
отслеживаются
Концептуальная база включает в себя:
Основные материалы
Дополнительные (обязательные!) материалы
•
•
•
•
Концепции развития проекта
План релизов
Стратегия минимизации рисков
Стратегия управления качеством
• Методики тестирования и оценивания рабочих
продуктов
• Методики измерения качества и других
показателей рабочих продуктов
• Соглашение об отслеживаемых связях
2
Метафора проекта как Рабочей книги
(по материалам Центра объектно-ориентированных технологий IBM)
Весь проект — (большая) Рабочая книга, разделы которой отражают суть рабочих
продуктов всей проектной деятельности
Вводная часть книги — концептуальная база проекта (структурирована в соответствии со
структурой концептуальной базы)
Главы основной части — сведения о релизах (структурируются также, как выстраивается
выполнение итераций)
Заключительная часть — описание деятельности по оценке выполненного проекта
⇒ Общий план развития проекта — это содержание Рабочей книги:
Метафора замечательна тем, что отражает параллель между проектной деятельностью и
тем, что делает технический писатель, составляя документацию по проекту.
Можно считать, что Рабочая книга действительно пишется по ходу выполнения
проектной деятельности, и это одна из методических рекомендаций данного подхода
Коллективное авторство /лучше — свой проект для ключевых разработчиков/ или
одобрение /хуже/ или всего лишь согласие /еще хуже, но все-таки приемлемо!/
Метафора легко распространяется за пределы разработки проекта!
(Изменяемые /дополняемые/ документы — переписывание книги)
Предпроектная подготовка стратегий оправдана и полезна:
• в это время можно охватить всю систему проектных деятельностей, которые предстоит
выполнять менеджеру и его коллективу в течение жизненного цикла. Это позволит, в
частности, точнее оценить ресурсные потребности;
• априорные стратегии, пусть даже корректируемые в дальнейшем, более объективны,
чем случайные, которым будет следовать менеджер, если заранее не подготовится
3
Материалы проекта
Категории уровням согласования:
a) индивидуальные — материалы, с которыми имеет дело работник,
для поддержки собственной деятельности;
b) рабочие — материалы, которые готовятся для использования
работниками коллектива, выполняющими проект;
c) внутрифирменные — материалы, которые предъявляются
руководству фирмы;
d) официальные — материалы, требующие согласования как с
руководством фирмы, так и с заказчиком.
К каким категориям могут относиться материалы концептуальной базы?
• Концепции развития проекта
•
•
•
•
•
•
План релизов
Стратегия минимизации рисков
Стратегия управления качеством
Методики тестирования и оценивания рабочих продуктов
Методики измерения качества и других показателей рабочих продуктов
Соглашение об отслеживаемых связях
Обязательны для предъявления заказчику —
концепции развития проекта и план релизов
правовые, финансовые нормы и соглашения
Эти сведения + распределение
ресурсов (включая время)
утверждаются
4
Концепции развития проекта
Общие принципы и положения — соглашения, которые зависят от проектного задания
лишь косвенно (определяют принимаемую стратегию развития) ⇒профиль проекта
Специальные принципы и положения — соглашения, которые определяются
спецификой проектного задания (предметная область разработки, характер
использования результатов проектирования и т.п.)
Общие принципы для всех этапов:
• как проверяется корректность получаемых результатов (рабочих продуктов этапа);
• как формируются релизы и версии рабочих продуктов, какая дисциплина внесения
изменений в рабочие продукты рекомендуется, как она контролируется;
• способы оценки продуктивности деятельности и продвижения к цели этапа, а также
процедура мониторинга качества рабочих продуктов;
• приемы, методы, технологии, а также прототипы, используемые в работах этапа.
Специальные принципы и положения:
• специфичные этапы и контрольные точки
• фиксация понятий, обозначений и терминов, общих для проекта — основа глоссария
• декомпозиция проекта (ее тип)
• дополнительные сведения (по усмотрению)
Преимущества разделения принципов:
• Документальное разделение принципов помогает отделять общее от специфичного и
в дальнейшем развитии
• Общие принципы — основа методики управления проектом (переиспользование +
новые приемы) Гораздо труднее использовать повторно что-либо, пока это
документально не разделено;
• Концепции развития проекта полезно просмотреть в конце проекта (выделить то, что
«работало», а что нет, и почему).
• Документ, в котором общее отделено от частного, допускает гораздо более
результативное изучение, нежели разного рода проектно-ориентированные
документы.
Хорошие концепции развития проекта предохраняют от недопонимания и бесполезных
обсуждений, как проект должен развиваться
5
Предостережение: возможен догматизм переиспользуемого!
Общие принципы для этапов проекта
Для этапов, связанных с планированием — структура получаемых рабочих
продуктов (планов), инструменты, применение которых полезно для
поддержки составления плана и отслеживания планируемых работ
Для этапов, связанных с определением требований и со спецификациями —
форматы документального представления требований, инструменты для
работы с ними: извлекать, сортировать, выставляя приоритеты по
различным критериями др. + как заказчик и конечные пользователи смогут
влиять на развитие требований
Для этапов, связанных с анализом и конструированием — нотация,
применяемая для моделирования (ситуаций использования и сценариев,
иерархий классов и системы взаимодействий и т.д.)
Для этапов программирования — используемый и целевой языки. Если
целесообразно, то система инструментальной поддержки и принципы
интеграции кода (чаще это относят к специальным принципам и
положениям)
Для этапов оценки — принципы верификации, тестирования и средств
поддержки тестирования (генерация тестов и база данных тестов), а также
аттестации; принципы оценки качества и средств поддержки управления
качеством (возможно, сами методики)
«Абсолютной» независимости общих принципов от реалий проекта нет! Они
верны лишь при выполнении условий-постулатов проекта.
6
WBS (work breakdown structure) —
метод декомпозиции проекта
Пример того, что отнести к общим и
специальным принципам
Ошибка абсолютизации
7
Потребности ресурсов — оценка (кадровые,
технические, финансовые и временные)
+ Концептуальная база проекта (ключевые моменты
подхода к разработке)
Минимальная схема
Рациональная схема
две схемы распределения ресурсов
• Варианты развития проекта и проектное
(техническое задание)
8
Принимаемый вариант развития проекта
Руководство
фирмы
Менеджер
проекта
Минимальная и
рациональная
схемы
Коллектив
исполнителей
Вариант развития
проекта
согласование
Заказчик
Проектное (техническое)
задание
Предъявление проектных материалов
Предпроектные материалы
Секреты
фирмы
Материалы, получаемые заказчиком
9
Планирование релизов
10
Управление рисками: понятия рисков
•
Причины риска — определенные события или обстоятельства в проекте или в
его окружении, которые вызывают неопределенность
– технические (сбои и задержки поставок и др.);
– политика руководства фирмы и заказчика (компетентность, расчет на удачу,
кредитоспособность, репутация и др.);
– рыночная конъюнктура;
– внутренние причины рисков:
• сбои в используемом окружении,
• неточность предъявляемых требований,
• ненадежность подрядчиков,
• ненадежность кадров.
•
Риск — может привести к воздействию на процесс достижения целей проекта:
– к негативному воздействию, если в результате траектория проектной деятельности
выходит из области допустимости,
– к нейтральному воздействию, если траектория не выходит из этой области,
– к позитивному воздействию, новая траектория не только остается допустимой, но и
по разным причинам оказывается предпочтительнее других траекторий, которые
могли бы реализоваться, если бы рисковая ситуация не возникла;
•
Последствия — незапланированные отклонения траектории выполнения
проекта, возникшие в результате того, что событие или обстоятельство,
квалифицированное как риск, произошли.
11
Управление рисками
• Project Risk Management — процессы, обеспечивающие
–
–
–
–
–
планирование возможности рисков,
их идентификацию,
анализ,
разработку откликов и
контроль в течение жизненного цикла проекта
• Риски — неопределенные события или обстоятельства,
возникновение которых может привести к воздействию на процесс
достижения целей проекта
• Реальные риски — это те события, которые действительно
характеризуются неопределенностью
• План управления рисками — идентификация рисков данного проекта
и мероприятия, снижающие зависимость его от рисков:
– Идентификация рисков ⇒ список идентифицированных рисков
– Выставление приоритетов рискам ⇒ определяются риски, которые будут
отслеживаться в проекте. Остальные не отслеживаются, но игнорируются
обоснованно (реально можно отследить не более 10-15 рисков)
– Установление возможности влияния на риски (на причины и на
воздействия)
12
Схема связей составляющих риска
Причина
Дано
• В результате (по причине)
<определенное событие>
Риск
Неопределенно
– вместо этого нужно подставить
конкретную причину
идентифицируемого риска
• может случиться
<риск>,
– нужно подставить
наименование риска
• что может привести к
Воздействие
Возможно
<воздействию>
– нужно подставить варианты
того, что может произойти
13
Уровни влияния на риски
1.
Исключение риска (avoid). Некоторые рискованные ситуации могут быть исключены
полностью. К сожалению, невозможно исключение всех рискованных ситуаций.
Исключение риска осуществимо не всегда, но при планировании работы с рисками для каждого из
них следует попытаться найти варианты исключения (преодоление выявленных причин
возникновения иска, т.е. создание условий, которые приведут разрыву связи причина — риск).
2.
Переключение риска (transfer) — частный случай исключения, когда риск переносится
из сферы влияния проекта на окружение. К этому уровню относятся все варианты
контрактных соглашений, но не только они. Оперируя рисками нужно стараться
предусмотреть способы переключения.
К сожалению, эта стратегия является исключением риска только для разработчиков, но не для
проекта в целом.
3.
Уменьшение риска (mitigate). Если риск не может быть исключен, можно постараться
уменьшить вероятность его появления на практике (оперирование с причинами).
Нужно, чтобы подобные решения делались не в ответ на ситуацию, а заранее.
Пример уменьшения риска — объявление (для заказчика, руководства и коллектива) о пересмотре
требований, когда становится понятным, что график выполнения работ может быть сорван
Предупреждение ущерба от риска (accept). Когда не получается удовлетворительно
уменьшить риск, следует подготовиться к встрече неприятности так, чтобы
минимизировать потери, т.е. снизить вероятность негативного воздействия и уменьшить
само воздействие (оперирование с последствиями). Если это удается, то продолжение
проекта во многих случаях оказывается успешным
Планируемые отклики на риски — мероприятия на указанных уровнях в различной
комбинации, возможно, дополненные более тонкой реакцией на возникновение риска
В результате рискового события, влияния на него, а также его воздействия на проект
возможно появление, так называемых, вторичных рисков, т.е. тех, которые без этого не
могли бы возникнуть. Их также следует оценивать, для них также нужно
предусматривать влияния.
Исполнители должны быть осведомлены о возможных рисках и о плане управления ими.
14
4.
Ситуации, которые нужно избегать и учитывать,
составляя план управления рисками
• Задержка начала проекта никогда не компенсируется;
• Если сетевой график выполняется с большими нарушениями сроков,
трудно ожидать создание хорошего продукта;
• Если пользовательский интерфейс не является интуитивно понятным
и превышает уровень компетенции потребителя изделия, продукт
будет плохо распространяться;
• Упущенные возможности требуют дополнительных усилий при их
более поздней реализации и увеличивают затраты;
• Не протестированный продукт снижает репутацию разработчиков;
• Не стоит рассчитывать на постоянство пользовательских намерений,
никогда нельзя знать, что хочется пользователю и чего на самом деле
ему нужно.
• Как следствие, необходимо планировать время на переделку того, что
в начале проекта казалось приемлемым.
15
Управление качеством проекта
16