Автоматизация бизнес-процессов продажи билетов ООО "Зритель"

Computer Associates ERwin 4.0 использовалась для проектирования логической и физической структуры БД. В качестве нотации использовалась нотация IDEF1X. ERwin был разработан для поддержки таких стандартов моделирования как IDEF1X и IE. Методология IDEF1X поддерживает многоуровневую структуру модели. Более того высокой уровень модели меньше будет зависеть от физической реализации БД. Например, одна и та же модель БД спроектирована для СУБД DB2 будет отличаться от той же модели БД для СУБД MS SQL, но на более высоких уровнях они (модели) будут одинаковыми. Этот принцип и используется в ERwin. Computer Associates ERwin поддерживает генерацию БД для многих серверов. Генерация БД реализована через механизм ODBC-драйверов. Также поддерживается генерация SQL-скрипта БД. Этот метод и был использован при генерации БД модулю.

HTML - (HyperText Markup Language) язык разметки гипертекста. Представляет собой организованную совокупность маркеров, которые интерпретируются браузером определенным образом. В связи с конкуренцией за рынки сбыта компаний Microsoft и Netscape не было разработано единого стандарта этого языка. Это поставило разработчиков web-дополнений в тяжелое положение, из-за того, что было необходимо поддерживать два основных стандарта HTML: стандарт от Microsoft и Netscape. Но вскоре появился единственный стандарт от консорциума W3, но и сейчас браузеры компаний-производителей не всегда в полном объеме поддерживают этот стандарт.

CSS - (Cascading Style Sheets) каскадные таблицы стилей являют собой простую технологию определения и присоединения стилей к HTML документу. Стиль - это все то, что определяет внешний вид документу при его отображении в окне браузера: шрифт, цвет, границы таблиц, их цвет, позиционирование объектов и др. Таблица стилей - это шаблон, который руководит форматированием HTML тэгов в web-документе.

PHP является слабо типизирующим языком. Был избран именно этот язык благодаря его сходству со структурами управления на язык С++. Кроме того, использование этого языка в разработке web-дополнений является достаточно распространенным явлением. Это в большинстве случаев обусловлено его доступностью и простотой.

JavaScript - используется в основном для проверки данных пользователя и реализации интерактивности web-дополнений. Скрипт выполняется со стороны клиента. Его синтаксис очень похож синтаксис С++. Имеет встроенные объекты, которые позволяют обращаться к некоторым функциям браузера.

1.5.3 Обоснование проектных решений по программному обеспечению

Из-за того, что Internet-технологии в своем большинстве являются открытыми технологиями, для разработки самих дополнений можно использовать любой текстовый редактор. Но для разработки дополнений данной квалификационной работы использовался профессиональный пакет разработки web-страниц Macromedia Dreamweaver MX, который соединяет в себе скорость визуальной разработки сайтов и точность ручной разработки. Кроме того этот пакет поддерживает разработку PHP-скриптов.

В качестве языка серверных вставок используется бесплатный скрипт-язык PHP. Он удобен для разработки серверных вставок и, кроме того, из-за того, что его интерпретатор реализован в виде модулей, поддерживается многими HTTP-серверами.

Для хранения и выборки данных используется СУБД Interbase компании Borland Software Corporation. Она зарекомендовала себя как легкая СУБД с достаточно высокими скоростными показателями и малой потребностью системных ресурсов. Кроме того, по сравнению со стандартной для решения задач данного типа СУБД MySQL, СУБД Interbase имеет достаточные функциональные возможности для последующей интеграции в подсистемы торговой организации. Это, прежде всего, объясняется поддержкой триггеров, процедур, которые сохраняются на сервере, и представлений.

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

Для разметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperText Markup Language). Сам язык реализован в виде дескрипторов маркеров, которые описывают размещения элементов страницы, а также дополнительные характеристики каждого элемента.

II Проектная часть

2.1 Разработка проекта автоматизации: информационный менеджмент

2.1.1 Этапы жизненного цикла проекта автоматизации

Очевидно, что функции, выполняемые разработчиками проекта, в ходе его развития претерпевают изменения, как, в прочем, и сам проект. Сначала он существует в виде заявки на разработку, затем -- как функциональные и технические требования, далее -- как спецификации разрабатываемого изделия, набор программных модулей, скомпонованная из модулей система и т.д. Этот перечень можно рассматривать как один из примеров модели жизненного цикла программного изделия, т.е. представления эволюции разработки и последующего использования программной системы.

Жизненный цикл -- это проекция пользовательского понятия «время жизни» на понятие разработчика «технологический цикл (цикл разработки)».

Необходимость внесения изменений в действующие программы есть по сути дела продолжение разработки программного обеспечения после передачи его пользователю и в течение всего времени жизни программ. Деятельность, связанная с решением довольно многочисленных задач такой продолжающейся разработки получила название сопровождения программного обеспечения (Рис. 2.1.)

	Использование
Разработка
	Продолжающаяся разработка
	(сопровождение)

Рис. 2.1. Разработка, использование и сопровождение
программного обеспечения

Исторически развитие концепций жизненного цикла связано с поиском для него адекватных моделей. Как и всякая другая, модель жизненного цикла является абстракцией реального процесса, в которой опущены детали, несущественные с точки зрения назначения модели. Разнообразие назначений определяет разнообразие моделей.

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

Фазы разбиваются на ряд этапов (Рис. 2.1., 2.2.).

Рис. 2.2. Модель жизненного цикла проекта

Разработка начинается с идентификации потребности в новом приложении, а заканчивается передачей продукта разработки в эксплуатацию.

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

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

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

На следующем этапе реализации, или кодирования каждый из этих модулей программируется на своем наиболее подходящем для данного приложения языке. С точки зрения автоматизации этот этап традиционно является наиболее развитым.

Далее фаза разработки заканчивается этапом тестирования (автономного и комплексного) и передачей системы в эксплуатацию.

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

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

Таким образом, данный проект по автоматизации содержит семь этапов, разделенных во времени (Рис. 2.3.).

Рис. 2.3. Модель жизненного цикла проекта автоматизации

2.1.2 Разработка и описание проекта автоматизации, плана-графика автоматизации и сетевой модели задач

План-график -- это поэтапно разбитая и упорядоченная по времени выполнения последовательность работ проекта. Его содержание позволяет руководству планировать деятельность коллектива разработчиков проекта как подразделения фирмы в целом. Как правило, план предъявляется заказчику с тем, чтобы заказчик ориентировался в сроках поэтапного выполнения задания. Это внешние функции календарного плана.

Обычный план-график представляется в виде таблицы со следующей структурой:

Таблица 2.1.

Обычный план-график

Наименование работ (тема, работа, задача, задание)	Сроки выполнения начало/конец	Ответственный исполнитель и исполнители, роли	Требуемые ресурсы и сроки их предоставления план/факт	Примечания
	план	факт
1	2	3	4	5	6

Столбец 1 заполняется в соответствии с разбиением заказанного проекта на составляющие. Обычно глубина рубрикации разбиения зависит от уровня проработанности того или иного фрагмента проекта. По мере углубления декомпозиции и уточнения задач вводятся новые строки таблицы, которые должны вписываться в ранее составленную структуру и не противоречить ограничениям, налагаемым ранее (сроки, исполнители, ресурсы).

Распределение времени и контроль над ним -- назначение столбцов 2 и 3. В них указываются календарные даты планируемого (столбец 2) и фактического (столбец 3) сроков выполнения работы, задачи или задания. Планируемое начало работы -- это самая ранняя дата, после которой можно приступать к выполнению; конец -- это предельный срок отчета исполнителей перед менеджером. Иногда граф планируемых сроков дополняется критическими и целесообразными сроками начала/конца работы. Это позволяет менеджеру более точно следить за распределением временных ресурсов.

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

Распределение технических ресурсов и задание сроков их предоставления -- содержание столбца 5. Здесь указывается необходимая для выполнения задания техническая, а в ряде случаев, и программная база. Иногда этот раздел дополняется сведениями о лицах, отвечающих за выполнение указываемых требований. Это удобно как для менеджера, так и для ответственных исполнителей: наглядно видны нарушения поставок (несоответствия между плановыми и фактическими сроками). Полезным расширением состава сведений столбца 5 является включение в него информации о зависимости работ внутри проекта, т.е. перечисление заданий (в том числе, ссылки на другие строки данного календарного плана), без выполнения которых осуществимость планируемых работ нарушается. Отслеживание зависимостей работ -- это более содержательная задача выполнения проекта по сравнению с тем, что можно получить через только что указанное расширение календарного плана, и ей в дальнейшем будет уделено внимание.

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

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

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

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

Графы специально приспособлены для планирования времени и в этом качестве они более универсально применимы. Для сетевого планирования очень больших проектов применяют сочетание событийно-ориентированных графовых описаний проекта и графов зависимостей работ.

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

Для нашего проекта сетевая модель работ представлена на рис. 2.4. Здесь каждая из вершин графа зависимостей снабжается атрибутом длительности выполнения работы. Здесь возможны варианты: минимально необходимое и рациональное время выполнения работы, длительность выполнения работы как функция от квалификации исполнителей и т.п. Атрибут длительности позволяет расположить граф зависимостей вдоль временной оси, как это изображено на рис. 2.4. Изображение графа зависимостей в привязке к временной оси называется сетевым графиком выполнения работ.



Рис. 2.4. Сетевая модель работ проекта автоматизации

Как показывает рисунок, построение сетевого графика не однозначно: рис. 2.4 (а) демонстрирует задание одновременности «начал» работ, а рис. 2.4 (б) -- их «окончаний». Жирными стрелками на рисунке выделена последовательность работ 3, 4, 10, 13, 14, которая определяет общую длительность проведения всех работ, выполняемых параллельно. При жесткой фиксации длительностей работ быстрее, чем за время

t (Р3) + t (Р4) + t (Р10) + t (Р13) + t (Р14)

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

Возможно, что длительность работ жестко не фиксируется, в частности, когда она рассматривается как функция от используемых ресурсов (к примеру, некоторая работа выполняется за время t1 силами k1 исполнителей, и за t2 при использовании k2 исполнителей). Тогда правомерно ставить задачу перераспределения ресурсов и построения критического операционного маршрута, оптимального с точки зрения того или иного критерия.

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

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

§ максимально возможная ресурсная потребность;

§ минимально необходимое время выполнения работы (при условии полной ее ресурсной обеспеченности).

Следующие характеристики каждой работы определяются после построения сетевого графика:

§ время, когда данная работа в принципе может начаться (по графику) -- время возможного начала работы;

§ время, позднее которого данная работа не должна продолжаться -- время допустимого конца работы.

В ходе выполнения проекта определяются и указываются на графике:

§ время фактического начала работы;

§ время текущего планового завершения работы;

§ время фактического завершения работы.

Наконец, в каждый текущий момент выполнения проекта определяются:

§ текущая ресурсная обеспеченность (как доля максимально возможной потребности);

§ объем работы, выполненный и оставшийся к текущему моменту времени.

Приведенный список адаптируется к условиям выполнения проекта. Методы привязки указанных параметров к сетевому графику могут быть различны. В частности, они зависят от системы автоматизации сетевого планирования (если ее использование в проекте предусмотрено то, как правило, такая система дает свои возможности оперирования с параметрами, сопутствующими сетевому графику). Тем не менее, можно указать на ряд общих положений, которых стоит придерживаться при любом варианте сетевого планирования (в том числе и при отсутствии средств его автоматизации):

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

Целесообразно варьировать уровень детализации работ и отслеживаемых параметров на сетевых графиках, а также на отдельных операционных маршрутах. Большей детализации требуют текущий и ближайший следующий этапы, больше отслеживаемых параметров требуется для критического маршрута;

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

§ время возможного начала работы,

§ время допустимого конца работы,

§ время фактического начала работы,

§ время фактического конца работы,

§ текущий момент выполняемой в настоящее время работы.

2.1.3 Характеристика архитектуры разрабатываемого проекта

Архитектура разрабатываемого проекта содержит, прежде всего, ряд основных элементов и связей между ними (Рис. 2.5).

Рис. 2.5. Общая архитектура разрабатываемого проекта

Характеристика структурных единиц информации исходных сообщений, при такой архитектуре, приведена в табл. 2.2.

Таблица 2.2.

Характеристика структурных единиц информации исходных сообщений

Тип строки	Наименование структурной единицы информации	Обозначение	Шаблон
Прайс-лист
Заглавный	Дата прайс-листа Наименование категории билета	Pr_date Pr_cat	99.X(8).9999 X(50)
Информационный	№ билета Наименование билета Цена билета	Pr_id Pr_name Pr_price	999999 X(150) 99999,99
Платежное поручение
Заглавный	№ платежного поручения	Por_id	9999
Информационный	Дата оформления поручения Дата получения банком Плательщик Банк плательщика Код плательщика Код банка плательщика Дебет счета № Получатель Код получателя Банк получателя Код банка получателя Кредит счета № Сумма платежа Назначение платежа Дата проведения банком	Por_date Por_bk_date Por_plat_naim Por_bk_plt_naim Por_plat_id Por_plat_bnk_id Por_deb_c Por_pol_naim Por_pol_id Por_bnk_pol Por_bnk_pol_id Por_cred_c Por_sum Por_nazn Por_bnk_prov	99.X(8).9999 99.X(8).9999 Х(50) Х(50) Х(14) Х(6) Х(14) Х(50) Х(14) Х(50) Х(6) Х(14) 99999,99 Х(80) 99.X(8).9999
Реестр подтвержденных заказов
Заглавный	Дата реестра	Re_date	99.99.9999
Информационный	Номер заказа Код клиента ПІБ клиента Сумма заказа Вид оплаты	Re_ord_id Re_clt_id Re_clt_fio Re_ord_sum Re_paysys	99999 99999 Х(70) 99999,99 Х
Итоговый	Всего	Re_sum	9999999,99

2.1.4 Характеристика этапа внедрения разрабатываемого проекта

Основной составляющей этапа внедрения является тестирование. План тестирования отвечает на вопросы кто, когда, что и как тестирует в данном проекте. Он специфицирует, какого вида тесты нужно проводить для проверки результатов, и в каком порядке. Если проект требует специальных видов проверок (например, используемых программно-технических ресурсов), это также отражается в плане.

Зачем нужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключается в двух положениях:

· во-первых, обнаружение ошибок как можно раньше позволяет избавиться от напрасной реализации неправильных решений, от использования неправильных (а потому переделываемых в дальнейшем) компонентов, от обременительных возвратов к уже пройденному;

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

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

· какие результаты тестируются, каким методом и как определяется, что тестирование выполнено;

· как для деятельности данного вида определяется период тестирования -- время, отводимое для тестирования в плане итерации;

· какие кадровые и технические ресурсы требуются для каждого из периодов тестирования;

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

Наиболее просты для планирования тестирования рабочие продукты, связанные с анализом и конструированием: требуется проверка полноты, непротиворечивости и соответствия получаемых результатов исходным положениям (требованиям -- для анализа и спецификациям -- для конструирования). Период тестирования здесь можно определить довольно точно. Он зависит от размеров рабочего продукта и заранее составляемого перечня вопросов, требующих ответа при изучении материалов, которые рассматриваются как содержание тестировочной работы. Кадровые ресурсы для такого тестирования также вполне определены: как правило, изучение материалов рабочего продукта не может быть поручено нескольким исполнителям, т.е. данный вид тестирования не допускает распараллеливания. Нет проблем и с определением технических ресурсов, а также с тем, что считать окончанием тестирования (получение ответов на весь перечень вопросов). В качестве инструментальной поддержки такого рода тестирования используются обычные средства работы с текстами.

Более сложным для планирования является тестирование программных рабочих продуктов. Главные причины тому -- неопределенная сложность программирования как этапа жизненного цикла. Она непосредственно зависит от решаемых на данном этапе задач, от использования инструментария поддержки (в частности, от языка и системы программирования), а также от квалификации исполнителей рабочего продукта. Кроме того, именно на этапе проверки программных рабочих продуктов проявляют себя ошибки более ранних этапов, что вносит существенный вклад в неопределенность планирования тестирования. Эти трудности практически непреодолимы при последовательной стратегии развития проекта. Для возвратно-поступательного итеративного наращивания они во многом сглаживаются за счет обозримости свода задач каждой из итераций.

Конкретные методики, позволяющие планировать процессы тестирования программных рабочих продуктов, связываются с разделением системы тестов на группы, отвечающие за проверку различных аспектов итерации:

· тесты для проверки функциональности;

· тесты для проверки корректности преобразований данных;

· интерфейсные тесты;

· специфичные для данного проекта (итерации) тесты.

Для каждой итерации определяется, что именно проверяется путем тестирования: идентифицируются тестируемые ситуации и что в этих ситуациях следует проверять (возможно, в виде базового набора тестов каждой группе), и что считается правильным для данной ситуации. Требуется, чтобы в каждой тестируемой ситуации было определено, от каких программных и документных компонентов проекта она зависит. Эти сведения используются в ходе диагностики и исправления найденных ошибок.

Для проекта в целом устанавливаются единые правила протоколирования ошибок. В протоколе целесообразно указывать не только ошибочные ситуации, но и в результате чего они проявили себя. Очень полезен, а для проектов с требованием высокого качества тестирования обязателен пополняемый банк тестов со средствами автоматической (по крайней мере, автоматизированной) проверки выполнения имеющихся тестов, накапливаемых в банке.

При планировании тестирования для проекта в целом и для каждой итерации устанавливается требуемый уровень качества тестирования: высокий, средний и низкий (возможна и другая градация). Для его задания используются сведения уточненного заказа и соглашения из Концепций развития проекта. Уровень качества тестирования -- неформальный показатель, отражающий какое количество ошибок, оставшихся после проведения тестирования, считается допустимым (учитывается, что одни ошибки исправляются на текущей итерации, а другие -- в ходе последующих итераций, возможно, в следующих релизах). Этот показатель прямо связывается с выделением времени и других ресурсов, для проведения тестирования, выполнения диагностики и исправления ошибок:

· высокий -- требует выделения для тестирования времени 95% и более из суммарного времени, отведенного для работ данной итерации;

· средний -- для тестирования требуется от 20% до 50% из суммарного времени работ данной итерации;

· низкий -- для тестирования отводится порядка 5% суммарного времени работ данной итерации.

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

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

Фиксируемые в ходе тестирования ошибки указывают на необходимость их исправления, которое может быть проведено либо в рамках текущей итерации, либо на последующих итерациях. Какой из этих вариантов для конкретной ошибки должен быть принят, определяется в рамках специальной деятельности, называемой диагностикой ошибки. Цели диагностики:

указать причину ошибки;

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

установить когда исправление будет сделано.

С точки зрения распределения ролей исполнителей проекта тестировщик решает только задачу фиксации ошибок, и, вообще говоря, оставляет в стороне задачу диагностики, решение которой -- функция проектировщика подсистемы и разработчиков.

Критерием того, что исправление ошибки следует перенести на последующие итерации, служит информация о том, что на данной итерации не хватает ресурсов: временные рамки или дефицит кадров итерации не позволяют осуществить исправление. Если это так, то менеджеру надлежит позаботиться о корректировке общего плана работ последующих итераций. Как вариант, в рамках плана управления рисками допускается увеличение сроков текущей итерации, которое должно быть согласовано с заказчиком и планировщиком.

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

2.1.5 Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ

Основной характеристикой этапа эксплуатации проекта является выпуск релизов по анализу этапа.

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

Таким образом, план релизов строиться, исходя из двух, возможно, противоречивых устремлений:

· логики поступательного развития и

· важности постепенного предоставления средств заказчику, которому план дает представление о последовательности удовлетворения требований к изделию.

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

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

Из этого следует, что план выпуска релизов должен составляться и утверждаться как можно раньше. Фактически все обязательные предпроектные работы (составление документов о концепции развития проекта и распределении ресурсов, построение план-графика работ) исходят из пользовательского представления процесса разработки как последовательности поставок -- релизов проектируемого изделия. В частности, при составлении плана выпуска релизов и его согласовании выясняется, какие решения неприемлемы для компании, для заказчика. Если проблемы окажутся неразрешимыми, то это свидетельствует о том, что от заказа придется отказываться, и чем раньше выяснятся подобные обстоятельства, тем менее болезненным будет разрыв отношений со всех точек зрения.

Вообще говоря, работа над планом выпуска релизов -- это отбор вариантов на основе анализа наиболее общих требований, учитывающая, что из того, что хочется получить заказчику, можно сделать наиболее скоро. Но без детализации требований зачастую невозможно отдать предпочтение тому или иному варианту. Поэтому план выпуска релизов должен быть открыт для включения альтернативных вариантов, которые отсеиваются при детализации на основе опыта развития проекта. Целесообразно производить ревизию плана релизов после завершения работ каждой итерации, т.е. на ее этапе оценки. В это время производятся комплексные измерения проекта, которые уточняют предварительную оценку продуктивности выполнения работ и полезности получаемых рабочих продуктов. Полученная информация позволяет корректировать план релизов и сделать его более реалистичным. Новая версия плана утверждается после появления очередного релиза.

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

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

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

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

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

2.1.6 Ожидаемые риски на этапах жизненного цикла и их описание

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

Причины возможного срыва работ весьма разнообразны, они зависят от конкретных условий и не сводятся лишь к техническим аспектам. Разработчики должны учитывать такие особенности ведения проекта, как техническая политика руководства фирмы и заказчика, их компетентность, их расчет на удачу, с одной стороны, а с другой -- кредитоспособность, репутацию тех, кто предлагает заказ. Риск невыполнения проекта может быть связан и с изменением рыночной конъюнктуры. Наконец, есть чисто внутренние причины рисков: сбои в используемом окружении (программном и техническом), неточность предъявляемых требований, ненадежность подрядчиков и др. и, возможно, кадров (нельзя исключать, что принятый на ключевую роль работник откажется от контракта в самый неподходящий момент).

Чтобы снизить влияние рисков на развитие проекта, менеджер должен разработать специальный план, называемый далее планом управления рисками. Содержание этого плана -- идентификация рисков для данного проекта и мероприятия, снижающие зависимость проекта от рисков.

Преодоление рисков может осуществляться на нескольких уровнях:

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

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

Уменьшение риска. Если риск не может быть исключен, можно постараться уменьшить его появление на практике. Продолжая пример с увольнением работника, для снижения вероятности этого следует предугадать причины поступка и постараться создать для работника более комфортные условия (повысить заработную плату, создать льготы и т.п.). Нужно, чтобы подобные решения делались не в ответ на заявление об увольнении, а заранее. Это сохранит определенную стабильность в коллективе, которая сама по себе является методом уменьшения риска.

Другой пример уменьшения риска -- объявление (для заказчика, руководства и коллектива) о пересмотре требований, когда становится понятным, что график выполнения работ может быть сорван. Как и в предыдущем случае, важным моментом здесь является упреждение, т.е. пересмотр требований не в ответ на нарушение графика, а в качестве превентивной меры.

Предупреждение ущерба от риска. Когда не получается удовлетворительно уменьшить риск, следует подготовиться к встрече неприятности так, чтобы минимизировать потери. Если это удается, то продолжение проекта во многих случаях оказывается успешным. В примере с увольнением следует как можно скорее найти замену данному работнику. Естественно, время выполнения проекта увеличится (в частности, потому что новому работнику придется входить в курс дела), но работа все-таки будет продолжена. Это так, но при одном условии: на всех уровнях проектирования заложена возможность отчуждения результатов труда от разработчиков. Если результаты персонифицированы, то трудности подмены для некоторых ролей могут оказаться непреодолимыми.

Примеров подобного контроля из области техники можно привести множество (бамперы и дворники автомашин, плавкие предохранители, дублирующие и сети т.д.). В практике конструирования программного обеспечения для предупреждения последствий риска используются строго регламентированные технологические приемы и методы разработки.

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

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

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

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

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

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

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

Составление плана управления рисками -- это необходимая часть подготовки к началу проекта хотя бы по той причине, что он влияет на распределение ресурсов. Она начинается с фиксации и ранжирования всех возможных рискованных ситуаций и планируемых реакций на них. Кроме того, определяются временные издержки и цена мероприятий, которые планируется выполнять, когда риски проявляют себя. Таким образом, план управления рисками представляет собой перечень рисковых ситуаций с планируемыми реакциями на них, временными издержками и затратами на их проведение. Эти сведения дополняют затратные характеристики проекта и его план-график, тем самым, расширяя схему финансовых и временных потребностей проекта.

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

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

Ниже приводится перечень (далеко неполный) ситуаций, которых должен избегать менеджер, и которые он должен учитывать, составляя план управления рисками:

· задержка начала проекта никогда не компенсируется;

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

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

· упущенные возможности требуют дополнительных усилий при их более поздней реализации и увеличивают затраты;

· не протестированный продукт снижает репутацию разработчиков;

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

2.1.7 Оценка стоимостных параметров проекта автоматизации

При определении финансовых потребностей показатели, задаваемые в ходе выяснения технических и кадровых ресурсов, переводятся в денежное выражение. Для каждого из таких показателей должны быть известны нормативы перевода. Это либо стандартизованные (внешние и внутрифирменные) коэффициенты, либо просто цены используемых в проекте билетов и услуг. Если по каким-либо причинам точных нормативов перевода нет, то вместо них применяются экспертные оценки. Например, при приглашении для участия в проекте конкретного специалиста может оказаться, что требования его заработной платы не соответствуют квалификационной сетке ставок, принятой в компании. Для такого сотрудника приходится вводить индивидуальный норматив перевода почасовой занятости в денежное выражение.

Цены на билеты и услуги также могут варьироваться. В этой связи использование их как нормативов перевода означает не точное определение финансовых потребностей, связанных с приобретением данного билета или с получением услуги, а указание нижней и верхней границ требуемых денежных средств. В практике оценки финансовых ресурсов для программных проектов применяются расчеты следующих видов:

· по минимальной границе цен,

· по максимальной границе цен,

· по средней величине между максимальной и минимальной ценой или

· по средневзвешенной величине.

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

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

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

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