|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Трассировка и контроль
Каждая задача, помеченная в плане, отслеживается руководителем проекта. При отставании в решении задачи применяются утилиты повторного планирования. С помощью утилит определяется влияние этого отставания на промежуточную веху и общее время конструирования. Под вехой понимается временная метка, к которой привязано подведение промежуточных итогов. В результате повторного планирования: q могут быть перераспределены ресурсы; q могут быть реорганизованы задачи; q могут быть пересмотрены выходные обязательства. Планирование проектных задач
Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2. Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для последующих параллельных задач. Системный анализ проводится с целью: 1) выяснения потребностей заказчика; 2) оценки выполнимости системы; 3) выполнения экономического и технического анализа; 4) распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.); 5) определения стоимости и ограничений планирования; 6) создания системной спецификации. В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация. Анализ требований дает возможность: 1) определить функции и характеристики программного продукта; 2) обозначить интерфейс продукта с другими системными элементами; 3) определить проектные ограничения программного продукта; 4) построить модели: процесса, данных, режимов функционирования продукта; 5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования. Результаты анализа сводятся в спецификацию требований к программному продукту. Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования. После получения всех модулей ПО решается задача тестирования интеграции — объединения элементов в единое целое. Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика. Ромбиками на рис. 2.2 обозначены вехи — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи. Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи. Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи. Обычно используют следующие оценки: 1. Раннее время начала решения задачи (при условии, что все предыдущие задачи решены в кратчайшее время). 2. Позднее время начала решения задачи (еще не вызывает общую задержку проекта). 3. Раннее время конца решения задачи . . 4. Позднее время конца решения задачи . . 5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Тк. п. Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач. Рекомендуемое правило распределения затрат проекта — 40-20-40: q на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ — 5%); q на кодирование — 20%; q на тестирование и отладку — 40%. Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.) |