Автоматизация бизнес-процессов продажи билетов ООО "Зритель" (стр. 8 из 17)
Для нашего проекта сетевая модель работ представлена на рис. 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_datePr_cat | 99.X(8).9999X(50) |
| Информационный | № билетаНаименованиебилетаЦена билета | Pr_idPr_namePr_price | 999999X(150)99999,99 |
| Платежное поручение | |||
| Заглавный | № платежного поручения | Por_id | 9999 |
| Информационный | Дата оформления порученияДата получения банкомПлательщикБанк плательщикаКод плательщикаКод банка плательщикаДебет счета №ПолучательКод получателяБанк получателяКод банка получателяКредит счета №Сумма платежаНазначение платежаДата проведения банком | Por_datePor_bk_datePor_plat_naimPor_bk_plt_naimPor_plat_idPor_plat_bnk_idPor_deb_cPor_pol_naimPor_pol_idPor_bnk_polPor_bnk_pol_idPor_cred_cPor_sumPor_naznPor_bnk_prov | 99.X(8).999999.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_idRe_clt_idRe_clt_fioRe_ord_sumRe_paysys | 9999999999Х(70)99999,99Х |
| Итоговый | Всего | Re_sum | 9999999,99 |
2.1.4 Характеристика этапа внедрения разрабатываемого проекта
Основной составляющей этапа внедрения является тестирование. План тестирования отвечает на вопросы кто, когда, что и как тестирует в данном проекте. Он специфицирует, какого вида тесты нужно проводить для проверки результатов, и в каком порядке. Если проект требует специальных видов проверок (например, используемых программно-технических ресурсов), это также отражается в плане.
Зачем нужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключается в двух положениях:
· во-первых, обнаружение ошибок как можно раньше позволяет избавиться от напрасной реализации неправильных решений, от использования неправильных (а потому переделываемых в дальнейшем) компонентов, от обременительных возвратов к уже пройденному;
· во-вторых, легче обнаружить и исправить ошибку не в результате следствий из нее, которые сделали противоречие явным, а во время ее появления, когда ошибка не «обросла» многими связями и влияниями на другие компоненты программной системы.
Конкретный план тестирования может быть составлен, когда готов план итераций проекта, т.е. после прохождения контрольной точки 2 жизненного цикла проекта «Общие требования и общий план составлены». До этого момента целесообразно разработать общие положения о тестировании, которые служат технологическим регламентом в дальнейшем. Эти положения фиксируют следующее. Для каждой деятельности, определенной в плане итераций, для каждой итерации и для проекта в целом указывается:
· какие результаты тестируются, каким методом и как определяется, что тестирование выполнено;
· как для деятельности данного вида определяется период тестирования — время, отводимое для тестирования в плане итерации;
· какие кадровые и технические ресурсы требуются для каждого из периодов тестирования;
· какие инструменты используются при тестировании данного вида деятельности.
Наиболее просты для планирования тестирования рабочие продукты, связанные с анализом и конструированием: требуется проверка полноты, непротиворечивости и соответствия получаемых результатов исходным положениям (требованиям — для анализа и спецификациям — для конструирования). Период тестирования здесь можно определить довольно точно. Он зависит от размеров рабочего продукта и заранее составляемого перечня вопросов, требующих ответа при изучении материалов, которые рассматриваются как содержание тестировочной работы. Кадровые ресурсы для такого тестирования также вполне определены: как правило, изучение материалов рабочего продукта не может быть поручено нескольким исполнителям, т.е. данный вид тестирования не допускает распараллеливания. Нет проблем и с определением технических ресурсов, а также с тем, что считать окончанием тестирования (получение ответов на весь перечень вопросов). В качестве инструментальной поддержки такого рода тестирования используются обычные средства работы с текстами.