Файл: 1 разработка сценария внедрения.pdf

74
Продолжение таблицы 3.6
Риск
Вероятность
Степень ущерба
База данных, которая используется в программной системе, не обеспечи- вает обработку ожидаемого объема транзакций
Средняя
Серьезная
Недооценки времени выполнения проекта
Высокая
Серьезная
CASE-средства невозможно интег- рировать с другими средствами под- держки проекта
Высокая
Терпимая
Первоначальная нечеткая формули- ровка пользовательских требований привела к значительным изменениям системных требований, проявив- шихся на поздних стадиях разработ- ки проекта
Средняя
Терпимая
Невозможно организовать необхо- димое обучение персонала
Средняя
Терпимая
Скорость выявления дефектов в сис- теме ниже ранее спланированной
Средняя
Терпимая
Размер системы значительно пре- вышает первоначально рассчитан- ный
Высокая
Терпимая
Программный код, генерируемый
CASE-средствами, неэффективен
Средняя
Незначительная
Конечно, как вероятность рисков, так и возможный ущерб от них должны пересматриваться при поступлении дополнитель- ной информации об этих рисках и по мере реализации мероприя- тий по управлению ими. Поэтому подобные таблицы рисков должны переделываться на каждой итерации процесса управле- ния рисками.
После проведения анализа рисков определяются наиболее значимые риски, которые затем отслеживаются на протяжении всего срока выполнения проекта. Определение этих значимых рисков зависит от их вероятностей и возможного ущерба. В об- щем случае всегда отслеживаются риски с катастрофическими последствиями, а также риски с серьезным ущербом, значение вероятности которых выше среднего.

75
В некоторых статьях рекомендуется определить и отслежи- вать «10 верхних» рисков, но это не всегда обоснованная реко- мендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а может – пятнадцать. Но, конечно, количество рисков, по которым проводится мониторинг, должно быть обозримым. Большое ко- личество отслеживаемых рисков потребует огромного количества собираемой информации. Из списка рисков, представленных в табл. 3.6, для мониторинга следует отобрать те риски, которые могут привести к катастрофическим и серьезным последствиям для вашего проекта.
Планирование рисков заключается в определении стратегии управления каждым значимым риском, отобранным для монито- ринга после анализа рисков. Здесь также не существует обще- принятых подходов для разработки таких стратегий – многое ос- новывается на «чутье» и опыте менеджера проекта. В таблице 3.7 показаны возможные стратегии управления основными рисками, приведенными в таблице 3.6.
Таблица 3.7 – Стратегии управления рисками
Риск
Стратегия
Финансовые проблемы организации
Подготовить краткий документ для руково- дства организации, показывающий важность данного проекта для достижения финансо- вых целей организации
Проблемы неквалифици- рованного персонала
Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы

76
Продолжение таблицы 3.7
Риск
Стратегия
Болезни персонала
Реорганизовать работу команды разработчи- ков таким образом, чтобы обязанности и ра- бота членов команды перекрывали друг дру- га, вследствие этого разработчики будут знать и понимать задачи, выполняемые дру- гими сотрудниками
Дефектные системные компоненты
Заменить потенциально дефектные систем- ные компоненты покупными компонентами, гарантирующими качество работы
Изменения требований
Попытаться определить требования, наибо- лее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию
Реорганизация компании- разработчика
Подготовить краткий документ для руково- дства компании, показывающий важность данного проекта для достижения финансо- вых целей компании
Недостаточная произво- дительность базы данных
Рассмотреть возможность покупки более производительной базы данных
Недооценки времени вы- полнения проекта
Рассмотреть вопрос о покупке системных компонентов, исследовать возможность ис- пользования генератора программного кода
Существует три категории стратегий управления рисками.
1. Стратегии предотвращения рисков. Согласно этим стра- тегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исклю- чения потенциально дефектных компонентов, описанная в табли- це 3.7.
2. Минимизационные стратегии. Направлены на уменьше- ние возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков
(таблица 3.7).
3. Планирование «аварийных» ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следу- ет выполнить в случае проявления рисковой ситуации. В таблице
3.7 это стратегия поведения при возникновении финансовых про- блем у организации-разработчика.

77
Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В таблице 3.8 приведены признаки, кото- рые помогают определить тип риска.
Таблица 3.8 – Признаки рисков
Тип риска
Признаки
Технологические риски
Задержки в поставке оборудования или про- граммных средств поддержки процесса создания
ПО, многочисленные документированные техно- логические проблемы
Риски, связанные с персоналом
Низкое моральное состояние персонала, натяну- тые отношения между членами команды разра- ботчиков, низкое качество выполненной работы
Организационные риски
Разговоры среди персонала о пассивности и не- достаточной компетентности высшего руково- дства организации
Инструментальные риски
Нежелание разработчиков использовать про- граммные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства
Риски, связанные с системными требованиями
Необходимость пересмотра многих системных требований, недовольство заказчика ПО
Риски оценивания
Изменения графика работ, многочисленные отче- ты о нарушении графика работ
Мониторинг рисков должен быть непрерывным процессом, отслеживающим ход выполнения мероприятий по управлению рисками, при этом каждый основной риск должен рассматривать- ся отдельно.
3.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
Данное практическое занятие предполагает выполнение следующих этапов:
– изучить теоретический материал;
– построить временную и сетевую диаграммы для выбран- ного проекта;

78
– построить диаграмму распределения участников группы по этапам;
– построить список возможных рисков с указанием назва- ния риска, его описание и типа;
– провести анализ рисков;
– описать стратегию планирования рисков;
– построить отчѐт, включающий все полученные диаграм- мы и описание стратегии планирования рисков;
– ответить на контрольные вопросы.
3.4 КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Сложности в управлении программными проектами.
2. Перечислите виды планов.
3. Опишите план сопровождения.
4. Перечислите основные разделы плана.

79 4 СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДОЛОГИЙ
ПРОЕКТИРОВАНИЯ
4.1 ЦЕЛЬ РАБОТЫ
Цель работы – изучить методологии проектирования.
4.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ
Сравнительный анализ методологий проведем по следую- щим параметрам:
– адекватность средств рассматриваемой проблеме;
– согласованность с другими средствами структурного анализа;
– интеграция с последующими фазами проектирования системы.
4.2.1 Адекватность
Выбор той или иной методологии и нотации структурного моделирования напрямую зависит от специфики предметной об- ласти, для которой создается модель. Общая теория систем рас- сматривает модель любой предметной области в виде двух ос- новных множеств: объектов (сущностей, процессов) и отношений
(связей, зависимостей) между объектами. Элементарный подход к анализу специфики предметной области заключается в выясне- нии соотношения объектов и связей (чего больше?). Более слож- ные методологии анализа предметной области предполагают вы- деление подмножества базовых объектов и их свойств и класси- фикацию отношений. Теория систем, которая изучает прежде всего отношения предметной области, предполагает наличие у инструмента изучения развитых средств классификации отноше- ний, спецификации их семантики. Отсутствие у инструмента мо- делирования предметной области средств описания семантики отношений, ориентация его в большей степени на спецификацию семантики объектов (процессов) может привести к построению неадекватной модели.

80
В качестве основных предметных областей будем рассмат- ривать бизнес-процессы и системы обработки информации.
BPR – реорганизация бизнес-процессов. Под реорганизаци- ей понимают основательное переосмысление и перепланирование критических бизнес-процессов, имеющие целью резко улучшить их выполнение в отношении затрат, качества обслуживания и скорости. При этом бизнес-процесс представляет собой некото- рую деятельность, получающую входные данные одного или не- скольких типов и выдающую результат, имеющий ценность для клиента.
Для моделирования бизнес-процессов традиционно исполь- зуется методология SADT (точнее, ее подмножество IDEF0). Од- нако статическая SADT-модель полностью не решает задач реор- ганизации, для этого необходимо иметь возможность исследова- ния динамических характеристик бизнес-процессов. Одним из решений является использование динамических моделей, осно- ванных на цветных (раскрашенных) сетях Петри (CPN – Color
Petri Nets). Фактически SADT и CPN служат компонентами ин- тегрированной методологии реорганизации: SADT-диаграммы автоматически преобразуются в прообраз CPN-модели, который дорабатывается вручную и затем исполняется в различных режи- мах, чтобы получить соответствующие оценки.
Следует отметить, что не существует принципиальных ог- раничений для использования традиционных диаграмм потоков данных в качестве средства построения статических моделей бизнес-процессов. Более того, в настоящий момент доступен ряд методологий и продуктов динамического моделирования
(INCOME Mobile, CPN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые по- зволяют успешно решать подобные задачи.
Системы обработки информации. Любой класс систем ус- пешно моделируется при помощи DFD-ориентированных мето- дов: в этом случае вместо реальных объектов рассматриваются отношения, описывающие свойства объектов и правила их пове- дения. Примерами таких систем служат организационные систе- мы, системы документооборота, управления и другие системы, богатые разнообразными отношениями. В случае, если нотация
DFD не адекватна специфике предметной области (например,

81 предметная область с жесткими технологическими процессами: обработка деталей на станках, подготовка ракеты к запуску и т. п.), то для ее анализа применяются более адекватные средст- ва: технологические карты, диаграммы потоков управления и т. д.
По мнению специалистов в области проектирования инфор- мационных систем SADT-диаграммы значительно менее вырази- тельны и удобны для моделирования систем обработки информа- ции. Так, дуги в SADT-диаграммах жестко типизированы (вход, выход, управление, ресурс). В силу общности определения в
SADT отсутствуют средства детального описания содержания и структуры дуг (их семантики), за исключением именования. Ана- логичная проблема возникает и при описании блоков (процес- сов).
Однако DFD-диаграммы имеют удобные средства для опи- сания семантики потоков (представляемых дугами диаграммы) и правил преобразования входных данных в выходные (миниспе- цификации).
Применительно к системам обработки информации стирает- ся смысловое различие между используемыми в SADT входами- выходами, с одной стороны, и управлениями и механизмами, с другой: в системах обработки информации входы, выходы и управления являются потоками данных и правилами их транс- формации. Анализ системы при помощи потоков данных и про- цессов, их преобразующих, является более прозрачным и недву- смысленным.
В SADT отсутствуют выразительные средства для модели- рования особенностей систем обработки информации. DFD с са- мого начала создавались как средство проектирования информа- ционных систем (тогда как SADT – как средство проектирования систем вообще) и имеют более богатый набор элементов, адек- ватно отражающих специфику таких систем. Например, храни- лища данных являются прообразами носителей информации – файлов или баз данных; внешние сущности отражают взаимодей- ствие моделируемой системы с внешним миром.
Наличие миниспецификаций DFD-процессов нижнего уров- ня позволяет преодолеть логическую незавершенность SADT (а именно, обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и

82 построить полную функциональную спецификацию разрабаты- ваемой системы. Это позволит расширить возможности примене- ния созданной модели (например, ее можно будет использовать для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности).
Ограничения SADT, запрещающие использовать более пя- ти-семи блоков на диаграмме, вынуждают искусственно детали- зировать систему, что затрудняет понимание модели заказчиком, резко увеличивает объем и, как следствие, ведет к неадекватно- сти модели с реальной картиной.
4.2.2 Согласованность с другими средствами структурного
анализа
Речь идет о согласованности со средствами информацион- ного и временного моделирования системы. Поскольку SADT- диаграммы предназначены для моделирования систем общего класса и в них отсутствуют средства описания данных и событий, то согласование модели, например, с ERD- или STD- диаграммами практически невозможно или носит тривиальный характер.
В свою очередь, DFD-, ERD- и STD-диаграммы взаимно до- полняют друг друга и по сути являются согласованными пред- ставлениями различных аспектов одной и той же модели.
Отметим, что интеграция DFD – STD осуществляется за счет расширения классической DFD специальными средствами проектирования систем реального времени (управляющими про- цессами, потоками, хранилищами данных) и STD является дета- лизацией управляющего процесса, согласованной по управляю- щим потокам и хранилищам.
4.2.3 Интеграция с последующими фазами проектирования
системы
Важная характеристика методологии – ее совместимость с последующими этапами применения результатов анализа. Если речь идет о системах обработки информации, то результаты ана- лиза используются затем на фазах проектирования, реализации и тестирования системы. Здесь рассматриваются все методы и