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

Содержание

1.  Введение

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

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

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

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

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

Введение

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

/>

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

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

/>Для проведения успешного проекта нужно понять объем предстоящих работ,возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи,необходимые усилия (стоимость), план работ, которому желательно следовать.Руководство программным проектом обеспечивает такое понимание. Оно начинаетсяперед технической работой, продолжается по мере развития ПО от идеи креальности и достигает наивысшего уровня к концу работ [32], [64], [69].

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. Типовая структура распределения проектных работ

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

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

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

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

Основнойрычаг в планирующих методах — вычисление границ времени выполнения задачи.

Обычноиспользуют следующие оценки:

1.        Раннее времяначала решения задачи Tinmin (при условии, что всепредыдущие задачи решены в кратчайшее время).

2.        Позднее времяначала решения задачи Tinmax (еще не вызывает общуюзадержку проекта).

/>3.        Раннее времяконца решения задачи Toutmin

Toutmin= Tinmin + Tреш

4.        Позднее времяконца решения задачи Toutmax

Toutmax= Tinmax + Tреш.

5.        Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих кувеличению длительности критического пути Tк.п.

Все этизначения позволяют руководителю (планировщику) количественно оценить успех впланировании, выполнении задач.

Рекомендуемоеправило распределения затрат проекта — 40-20-40:

·          на анализ ипроектирование приходится 40% затрат (из них на планирование и системный анализ- 5%);

·          на кодирование — 20%;

·          на тестирование иотладку — 40%.

Выполнение в ходе руководства проектом

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

Выполнение оценки проекта на основе LOC- и FP-метрик

Цель этойдеятельности — сформировать предварительные оценки, которые позволят:

·     предъявитьзаказчику корректные требования по стоимости и затратам на разработку программногопродукта;

·     составить планпрограммного проекта.

Привыполнении оценки возможны два варианта использования LOC- и FP-данных:

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

/>·     в качествеметрик, собранных за прошлые проекты и входящих в метрический базис фирмы.

Обсудим шагипроцесса оценки.

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

f1,f2,...,fn.

·     Шаг 2. Длякаждой функции f1планировщикформирует лучшую LОСлучшi (FРлучшi), худшую LOСХУДШi(FРХУДШi) и вероятную оценку LOСвероятнi (FРвероятнi).Используются опытные данные (из метрического базиса) или интуиция. Диапазонзначения оценок соответствует степени предусмотренной неопределенности.

·     Шаг 3. Длякаждой функции fi в соответствии с β-распределением вычисляетсяожидаемое значение LOC- (или FP-) оценки:

LOCожi = LOCлучшi+ LOCхудшi + 4 x LOCвероятнi) / 6.

·     Шаг 4. Определяетсязначение LOC- или FP-производительности разработки функции.

Используетсяодин из трех подходов:

1.        для всех функцийпринимается одна и та же метрика средней производительности ПРОИЗВср,взятая из метрического базиса;

2.        для i-й функциина основе метрики средней производительности вычисляется настраиваемая величинапроизводительности:

ПРОИЗВi= ПРОИЗВср х (LOСср / LOСожi),

где LOCcp — средняя LOC-оценка, взятая из метрического базиса (соответствует среднейпроизводительности);

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

В данноймодели для вывода формул использовался статистический подход — учитывалисьреальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) — дал ей название СОСОМО 81 (Constructive Cost Model) и ввелв ее состав три разные по сложности статистические подмодели [1].

Иерархиюподмоделей Боэма (версии 1981 года) образуют:

·          базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функциюразмера программы;

·          промежуточнаяСОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценкипродукта, аппаратуры, персонала и проектной среды;

·          усовершенствованнаяСОСОМО — объединяет все характеристики промежуточной модели, дополнительноучитывает влияние всех атрибутов стоимости на каждый этап процесса разработкиПО (анализ, проектирование, кодирование, тестирование и т. д.).

ПодмоделиСОСОМО 81 могут применяться к трем типам программных проектов. По терминологииБоэма, их образуют:

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

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

·          встроенный тип — программный проект разрабатывается в условиях жестких аппаратных,программных и вычислительных ограничений.

/>Уравнения базовой подмодели имеют вид

Е = abx (KLOCbb [чел-мес];

D= cb x (E)db[Mec],

где Е- затраты в человеко-месяцах, D — время разработки, KLOC — количествострок в программном продукте.

Заключение

СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразныезадачи управления программным проектом.

Рассмотримвозможности этой модели в задачах анализа чувствительности — чувствительностипрограммного проекта к изменению условий разработки.

Будемсчитать, что корпорация «СверхМобильныеСвязи» заказала разработку ПОдля встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторыимеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода непредусматривается. К проведению разработки привлекаются главный аналитик иглавный программист высокой квалификации, поэтому средняя зарплата в командесоставит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемнойобластью и полгода работает с нужной аппаратной платформой.

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

Оценкупост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

Из таблицыследует, что увеличение затрат в 1,3 раза из-за очень высокой сложностипродукта уравновешивается их уменьшением вследствие высокой квалификациианалитика и программиста, а также активного использования программных утилит.

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

1.        Боэм Б. У.Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985.511 с.

2.        Липаев В. В.Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат,1993. 384 с.

3.        Майерс Г.Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.

4.        Орлов С. А.Принципы объектно-ориентированного и параллельного программирования на языкеAda 95. Рига: TSI, 2001. 327 с.

5.        Чеппел Д.Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.

6.        Abreu,F. В., Esteves, R., Goulao, M.The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics.Proceedings of the TOOLS'96. Santa Barbara, California 20 pp. July 1996.