Руководство программным проектом

Содержание

1. Введение

2. Руководство программным проектом

3. Планирование проектных задач

4. Конструктивная модель стоимости

5. Заключение

6. Список литературы

Введение

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

Рис. 2.1. Руководство в процессе конструирования ПО

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

2. Руководство программным проектом

Начало проекта

Перед планированием проекта следует:

· установить цели и проблемную область проекта;

· обсудить альтернативные решения;

· выявить технические и управленческие ограничения.

Измерения, меры и метрики

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

В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы.

Процесс оценки

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

Анализ риска

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

Планирование

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

Трассировка и контроль

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

В результате повторного планирования:

· могут быть перераспределены ресурсы;

· могут быть реорганизованы задачи;

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

3. Планирование проектных задач

Основной задачей при планировании является определение WBS - Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

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

Системный анализ проводится с целью:

1. выяснения потребностей заказчика;

2. оценки выполнимости системы;

3. выполнения экономического и технического анализа;

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

5. определения стоимости и ограничений планирования;

6. создания системной спецификации.

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

Анализ требований дает возможность:

1. определить функции и характеристики Программного продукта;

2. обозначить интерфейс продукта с другими системными элементами;

3. определить проектные ограничения программного продукта;

4. построить модели: процесса, данных, режимов функционирования продукта;

5. создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

Рис. 2.2. Типовая структура распределения проектных работ

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

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

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать