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

94
Продолжение таблицы 5.1
Обозначение
Наименование
Смысл в случае слияния стрелок
Смысл в случае разветвления стрелок
Асинхронное
«ИЛИ»
Один или несколько предшествующих процессов должны быть завершены
Один или не- сколько сле- дующих про- цессов должны быть запущены
Синхронное
«ИЛИ»
Один или несколько предшествующих процессов заверше- ны одновременно
Один или не- сколько сле- дующих про- цессов запус- каются одно- временно
Исключающее
«ИЛИ»
Только один пред- шествующий про- цесс завершен
Только один следующий процесс запус- кается
Объект ссылки изображается в виде прямоугольника, похо- жего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрест- ками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные
(unconditional), синхронные (synchronous) и асинхронные
(asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используе- мые в диаграммах переходов состояний объектов, не поддержи- ваются.
При внесении объектов ссылок помимо имени следует ука- зывать тип объекта ссылки. Типы объектов ссылок приведены в таблице 5.2.

95
Таблица 5.2 – Типы объектов ссылок
Тип объекта ссылки
Цель описания
OBJECT
Описывает участие важного объекта
GOTO
Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диа- грамме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться и стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на пере- кресток
UOB (Unit of
Behavior)
Применяется, когда необходимо подчеркнуть множе- ственное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовление изде- лия» несколько раз, после каждой единичной опера- ции. Обычно этот тип ссылки не используется для мо- делирования автоматически запускающихся работ
NOTE
Используется для документирования важной инфор- мации, относящейся к каким-либо графическим объек- там на диаграмме. Является альтернативой внесению текстового объекта на диаграмму
ELAB
(Elaboration)
Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках
5.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
Данное практическое занятие предполагает выполнение следующих этапов:
– изучить методические указания;
– создать функциональную модель и сценарий выбран- ного процесса;
– ответить на контрольные вопросы.
5.4 КОНТРОЛЬНЫЕ ВОПРОСЫ

96 3. Что представляют собой методологии функционального моделирования?
4. Что такое сценарии?

5. Какие виды сценариев вы знаете?
6. В чем отличие серверных элементов управления от кли- ентских?

7. Какие технологии программирования серверных сцена- риев вы знаете? В чем их отличие?
8. Для чего строится диаграмма IDEF3?

9. Чем диаграмма IDEF3 отличается от диаграммы IDEF0?
10. Как графически обозначается работа в диаграмме
IDEF3?

11. С какой целью между работами устанавливают перекре- сток?
12. Какие типы перекрестков вам знакомы?

97 6 РАЗРАБОТКА И ОФОРМЛЕНИЕ ПРЕДЛОЖЕНИЙ
ПО РАСШИРЕНИЮ ФУНКЦИОНАЛЬНОСТИ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
6.1 ЦЕЛЬ РАБОТЫ
Цель работы – описать и проанализировать информацион- ную систему, распределить роли в группе разработчиков.
6.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ
Проблемы управления программными проектами впервые проявились в 60-х – начале 70-х годов, когда провалились многие большие проекты по разработке программных продуктов. Были зафиксированы задержки в создании программного обеспечения
(ПО), оно было ненадежным, затраты на разработку в несколько раз превосходили первоначальные оценки, созданные программ- ные системы часто имели низкие показатели производительно- сти. Причины провалов коренились в тех подходах, которые ис- пользовались в управлении проектами. Применяемая методика была основана на опыте управления техническими проектами и оказалась неэффективной при разработке программного обеспе- чения.
Важно понимать разницу между профессиональной разра- боткой ПО и любительским программированием. Необходимость управления программными проектами вытекает из того факта, что процесс создания профессионального ПО всегда является субъектом бюджетной политики организации, где оно разрабаты- вается, и имеет временные ограничения. Работа руководителя программного проекта по большому счету заключается в том, чтобы гарантировать выполнение этих бюджетных и временных ограничений с учетом бизнес-целей организации относительно разрабатываемого ПО.
Руководители проектов призваны спланировать все этапы разработки программного продукта. Они также должны контро- лировать ход выполнения работ и соблюдения всех требуемых стандартов. Постоянный контроль за ходом выполнения работ

98 необходим для того, чтобы процесс разработки не выходил за временные и бюджетные ограничения. Хорошее управление не гарантирует успешного завершения проекта, но плохое управле- ние обязательно приведет к его провалу. Это может выразиться в задержке сроков сдачи готового ПО, в превышении сметной стоимости проекта и в несоответствии готового ПО специфика- ции требований.
Процесс разработки ПО существенно отличается от процес- сов реализации технических проектов, что порождает определен- ные сложности в управлении программными проектами:
Программный продукт нематериален. Программное обеспе- чение нематериально, его нельзя увидеть или потрогать. Руково- дитель программного проекта не видит процесс «роста» разраба- тываемого ПО. Он может полагаться только на документацию, которая фиксирует процесс разработки программного продукта.
Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства тех- нических систем хорошо изучены. Изучением же процессов соз- дания ПО специалисты занимаются только последнее время. По- этому пока нельзя точно предсказать, на каком этапе процесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту.
Большие программные проекты – это часто «одноразовые» проекты. Большие программные проекты, как правило, значи- тельно отличаются от проектов, реализованных ранее. Поэтому, чтобы уменьшить неопределенность в планировании проекта, ру- ководители проектов должны обладать очень большим практиче- ским опытом. Но постоянные технологические изменения в ком- пьютерной технике и коммуникационном оборудовании обесце- нивают предыдущий опыт. Знания и навыки, накопленные опы- том, могут не востребоваться в новом проекте.
Перечисленные отличия могут привести к тому, что реали- зация проекта выйдет из временного графика или превысит бюд- жетные ассигнования. Программные системы зачастую оказыва-

99 ются новинками, как в «идеологическом», так и в техническом плане. Поэтому, предвидя возможные проблемы в реализации программного проекта, следует всегда помнить, что многим из них свойственно выходить за рамки временных и бюджетных ог- раничений.
6.2.1 Процесс управления разработкой программного обес-
печения
Невозможно описать и стандартизировать все работы, вы- полняемые в проекте по созданию ПО. Эти работы весьма суще- ственно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие:
1. Написание предложений по созданию ПО.
2. Планирование и составление графика работ по созданию
ПО.
3. Оценивание стоимости проекта.
4. Подбор персонала.
5. Контроль за ходом выполнения работ.
6. Написание отчетов и представлений.
Первая стадия программного проекта может состоять из на- писания предложений по реализации этого проекта. Предложения должны содержать описание целей проектов и способов их дос- тижения. Они также обычно включают в себя оценки финансо- вых и временных затрат на выполнение проекта. При необходи- мости здесь могут приводиться обоснования для передачи проек- та на выполнение сторонней организации или команде разработ- чиков.
Написание предложений – очень ответственная работа, так как для многих организаций вопрос о том, будет ли проект вы- полняться самой организацией или разрабатываться по контракту сторонней компанией, является критическим. Не существует ка- ких-либо рекомендаций по написанию предложений, многое здесь зависит от опыта.
На этапе планирования проекта определяются процессы, этапы и полученные на каждом из них результаты, которые должны привести к выполнению проекта. Реализация этого плана

100 приведет к достижению целей проекта. Определение стоимости проекта напрямую связано с его планированием, поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана.
Контроль за ходом выполнения работ (мониторинг проекта)
– это непрерывный процесс, продолжающийся в течение всего срока реализации проекта. Руководитель должен постоянно от- слеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью. Хотя многие организации имеют механизмы формального мониторин- га работ, опытный руководитель может составить ясную картину о стадии развитии проекта просто путем неформального общения с разработчиками.
Неформальный мониторинг часто помогает обнаружить по- тенциальные проблемы, которые в явном виде могут обнару- житься позднее. Например, ежедневное обсуждение хода выпол- нения работ может выявить отдельные недоработки в создавае- мом программном продукте. Вместо ожидания отчетов, в кото- рых будет отражен факт «пробуксовки» графика работ, можно обсудить со специалистами намечающиеся программистские проблемы и не допустить срыва графика работ.
В течение реализации проекта обычно происходит несколь- ко формальных контрольных проверок хода выполнения работ по созданию ПО. Такие проверки должны дать общую картину хода реализации проекта в целом и показать, насколько уже разрабо- танная часть ПО соответствует целям проекта.
Время выполнения больших программных проектов может занимать несколько лет. В течение этого времени цели и намере- ния организации, заказавшей программный проект, могут суще- ственно измениться. Может оказаться, что разрабатываемый про- граммный продукт стал уже ненужным либо исходные требова- ния к создаваемому ПО просто устарели и их необходимо карди- нально менять. В такой ситуации руководство организации- разработчика может принять решение о прекращении разработки
ПО или об изменении проекта в целом с тем, чтобы учесть изме- нившиеся цели и намерения организации-заказчика.
Руководители проектов обычно обязаны сами подбирать ис- полнителей для своих проектов. В идеальном случае профессио- нальный уровень исполнителей должен соответствовать той ра-

101 боте, которую они будут выполнять в ходе реализации проекта.
Однако во многих случаях руководители должны полагаться на команду разработчиков, которая далека от идеальной. Такая си- туация может быть вызвана следующими причинами:
Бюджет проекта не позволяет привлечь высококвалифици- рованный персонал. В таком случае за меньшую плату привле- каются менее квалифицированные специалисты.
Бывают ситуации, когда невозможно найти специалистов необходимой квалификации, как в самой организации- разработчике, так и вне ее. Например, в организации «лучшие люди» могут быть уже заняты в других проектах.
Организация хочет повысить профессиональный уровень своих работников. В этом случае она может привлечь к участию в проекте неопытных или недостаточно квалифицированных ра- ботников, чтобы они приобрели необходимый опыт и поучились у более опытных специалистов.
Таким образом, почти всегда подбор специалистов для вы- полнения проекта имеет определенные ограничения и не является свободным. Вместе с тем необходимо, чтобы хотя бы несколько членов группы разработчиков имели квалификацию и опыт, дос- таточные для работы над данным проектом. В противном случае невозможно избежать ошибок в разработке ПО.
Руководитель проекта обычно обязан посылать отчеты о хо- де его выполнения, как заказчику, так и подрядным организаци- ям. Это должны быть краткие документы, основанные на инфор- мации, извлекаемой из подробных' отчетов о проекте. В этих от- четах должна быть та информация, которая позволяет четко оце- нить степень готовности создаваемого программного продукта.
Выделим следующие роли в группе по разработке ПО:
1. Руководитель – общее руководство проектом, написание документации, общение с заказчиком ПО.
2. Системный аналитик – разработка требований (составле- ние технического задания, проекта программного обеспечения).
3. Тестер – составление плана тестирования и аттестации готового ПО (продукта), составление сценария тестирования, ба- зовый пример, проведение мероприятий по плану тестирования.
4. Разработчик – моделирование компонент программного обеспечения, кодирование.

102
6.2.2 Планирование проекта разработки программного
обеспечения
Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предвидеть про- блемы, которые могут возникнуть на каких-либо этапах создания
ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий доку- мент, выполнение которого должно привести к успешному за- вершению проекта. Этот первоначальный план должен макси- мально подробно описывать все этапы реализации проекта.
Процесс планирования начинается, исходя из описания сис- темы, с определения проектных ограничений (временные ограни- чения, возможности наличного персонала, бюджетные ограниче- ния и т. д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и раз- мер проекта, а также распределением функций среди исполните- лей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Да- лее начинается циклическая часть планирования. Сначала разра- батывается график работ по выполнению проекта или дается раз- решение на продолжение использования ранее созданного графи- ка. После этого проводится контроль выполнения работ и отме- чаются расхождения между реальным и плановым ходом работ.
Далее, по мере поступления новой информации о ходе вы- полнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к из- менению графика работ. Если в результате этих изменений нару- шаются сроки завершения проекта, должны быть пересмотрены
(и согласованы с заказчиком ПО) проектные ограничения.
Конечно, большинство руководителей проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем.
Желательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше состав- лять «пессимистические» графики работ, чем «оптимистиче-

103 ские». Но, конечно, невозможно построить план, учитывающий все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пе- ресмотра проектных ограничений и этапов создания программно- го продукта.
План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все ви- ды планов, описанных выше. В других случаях план проекта опи- сывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта.
Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организа- ции-разработчика. Но в любом случае большинство планов со- держат следующие разделы.
1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т. д.), которые важны для управления проектом.
2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.
3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение.
4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программ- ного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приво- дится их стоимость совместно с графиком закупки и поставки.
5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выпол- нения проекта, приводится описание результатов («выходов») каждого этапа и контрольные отметки.
6. График работ. В этом графике отображаются зависимо- сти между отдельными процессами (этапами) разработки ПО,