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

Рис. 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 жизненного цикла проекта «Общие требования и общий план составлены». До этого момента целесообразно разработать общие положения о тестировании, которые служат технологическим регламентом в дальнейшем. Эти положения фиксируют следующее. Для каждой деятельности, определенной в плане итераций, для каждой итерации и для проекта в целом указывается:

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

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

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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14