§ минимальная кадровая и техническая ресурсная потребность, без удовлетворения которой выполнение работы невозможно;
§ максимально возможная ресурсная потребность;
§ минимально необходимое время выполнения работы (при условии полной ее ресурсной обеспеченности).
Следующие характеристики каждой работы определяются после построения сетевого графика:
§ время, когда данная работа в принципе может начаться (по графику) -- время возможного начала работы;
§ время, позднее которого данная работа не должна продолжаться -- время допустимого конца работы.
В ходе выполнения проекта определяются и указываются на графике:
§ время фактического начала работы;
§ время текущего планового завершения работы;
§ время фактического завершения работы.
Наконец, в каждый текущий момент выполнения проекта определяются:
§ текущая ресурсная обеспеченность (как доля максимально возможной потребности);
§ объем работы, выполненный и оставшийся к текущему моменту времени.
Приведенный список адаптируется к условиям выполнения проекта. Методы привязки указанных параметров к сетевому графику могут быть различны. В частности, они зависят от системы автоматизации сетевого планирования (если ее использование в проекте предусмотрено то, как правило, такая система дает свои возможности оперирования с параметрами, сопутствующими сетевому графику). Тем не менее, можно указать на ряд общих положений, которых стоит придерживаться при любом варианте сетевого планирования (в том числе и при отсутствии средств его автоматизации):
Сетевой график можно строить как для проекта в целом, так и для отдельных его этапов. Кроме того, для больших проектов полезно использовать сетевые графики работ групп исполнителей и даже отдельных исполнителей;
Целесообразно варьировать уровень детализации работ и отслеживаемых параметров на сетевых графиках, а также на отдельных операционных маршрутах. Большей детализации требуют текущий и ближайший следующий этапы, больше отслеживаемых параметров требуется для критического маршрута;
Дуги графа зависимостей работ являются важной, но менее информативной частью сетевого графика по сравнению с выстраиваемой последовательностью работ. Гораздо важнее изображать временную вариантность выполняемых работ. В частности, по этой причине в большинстве систем сетевого планирования предписывается изображать явно все области возможного выполнения работ, т.е. отмечать:
§ время возможного начала работы,
§ время допустимого конца работы,
§ время фактического начала работы,
§ время фактического конца работы,
§ текущий момент выполняемой в настоящее время работы.
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
Х(50)
Х(14)
Х(6)
Х(80)
Реестр подтвержденных заказов
Дата реестра
Re_date
99.99.9999
Номер заказа
Код клиента
ПІБ клиента
Сумма заказа
Вид оплаты
Re_ord_id
Re_clt_id
Re_clt_fio
Re_ord_sum
Re_paysys
99999
Х(70)
Х
Итоговый
Всего
Re_sum
9999999,99
2.1.4 Характеристика этапа внедрения разрабатываемого проекта
Основной составляющей этапа внедрения является тестирование. План тестирования отвечает на вопросы кто, когда, что и как тестирует в данном проекте. Он специфицирует, какого вида тесты нужно проводить для проверки результатов, и в каком порядке. Если проект требует специальных видов проверок (например, используемых программно-технических ресурсов), это также отражается в плане.
Зачем нужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключается в двух положениях:
· во-первых, обнаружение ошибок как можно раньше позволяет избавиться от напрасной реализации неправильных решений, от использования неправильных (а потому переделываемых в дальнейшем) компонентов, от обременительных возвратов к уже пройденному;
· во-вторых, легче обнаружить и исправить ошибку не в результате следствий из нее, которые сделали противоречие явным, а во время ее появления, когда ошибка не «обросла» многими связями и влияниями на другие компоненты программной системы.
Конкретный план тестирования может быть составлен, когда готов план итераций проекта, т.е. после прохождения контрольной точки 2 жизненного цикла проекта «Общие требования и общий план составлены». До этого момента целесообразно разработать общие положения о тестировании, которые служат технологическим регламентом в дальнейшем. Эти положения фиксируют следующее. Для каждой деятельности, определенной в плане итераций, для каждой итерации и для проекта в целом указывается:
· какие результаты тестируются, каким методом и как определяется, что тестирование выполнено;
· как для деятельности данного вида определяется период тестирования -- время, отводимое для тестирования в плане итерации;
· какие кадровые и технические ресурсы требуются для каждого из периодов тестирования;
· какие инструменты используются при тестировании данного вида деятельности.
Наиболее просты для планирования тестирования рабочие продукты, связанные с анализом и конструированием: требуется проверка полноты, непротиворечивости и соответствия получаемых результатов исходным положениям (требованиям -- для анализа и спецификациям -- для конструирования). Период тестирования здесь можно определить довольно точно. Он зависит от размеров рабочего продукта и заранее составляемого перечня вопросов, требующих ответа при изучении материалов, которые рассматриваются как содержание тестировочной работы. Кадровые ресурсы для такого тестирования также вполне определены: как правило, изучение материалов рабочего продукта не может быть поручено нескольким исполнителям, т.е. данный вид тестирования не допускает распараллеливания. Нет проблем и с определением технических ресурсов, а также с тем, что считать окончанием тестирования (получение ответов на весь перечень вопросов). В качестве инструментальной поддержки такого рода тестирования используются обычные средства работы с текстами.
Более сложным для планирования является тестирование программных рабочих продуктов. Главные причины тому -- неопределенная сложность программирования как этапа жизненного цикла. Она непосредственно зависит от решаемых на данном этапе задач, от использования инструментария поддержки (в частности, от языка и системы программирования), а также от квалификации исполнителей рабочего продукта. Кроме того, именно на этапе проверки программных рабочих продуктов проявляют себя ошибки более ранних этапов, что вносит существенный вклад в неопределенность планирования тестирования. Эти трудности практически непреодолимы при последовательной стратегии развития проекта. Для возвратно-поступательного итеративного наращивания они во многом сглаживаются за счет обозримости свода задач каждой из итераций.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18