Управление программными проектами. Учебное пособие

−изменяемость виртуальной машины – включает аппаратное обеспечение и операционную систему на целевом компьютере;

−оборотное время компьютера – применяется при разработке.

Атрибуты проекта. Атрибуты, связанные с практикой и инструментами:

− практика современного программирования – структурные или ОО-

технологии;

− современные инструменты программирования – CASE-инструменты,

хорошие отладчики, инструмент, используемые при выполнения тестирования; − сжатие (или расширение) графика – отклонение от идеала всегда удручает,

но меньшая степень отклонения всегда лучше, чем большая.

Атрибуты персонала. Некоторые атрибуты применяются для описания исполнителей работ:

−способности аналитика;

−опыт в создании приложений;

−способности программиста;

−опыт в области виртуальных машин, включая операционную систему и аппаратное обеспечение;

−опыт в области языков программирования, включая инструменты и

практику.

Детализированная модель СОСОМО. Программа разбивается на специфические продукты и компоненты этих продуктов. Согласно Боэму (Boehm),

подобное разбиение называется трехуровневой иерархией продуктов: система,

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

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

101

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

Анализ драйверов затрат производится отдельно для каждого компонента.

Подсистемы и модули наследуют драйверы затрат системы. Они называются: RELY, VIRT, TURN, MODP, TOOL и SCED. Модули наследуют драйверы затрат подсистемы. Эти драйвера называются: DATA, TIME, STOR, ACAP, AEXP.

Драйверы затрат модуля имеют такие названия: KLOC, AAF, CPLX, PCAP, VEXP и

LEXP.

Действия по разработке проекта разбиваются на фазы. В работах Боэма используются четыре основных фазы: требования (RQ), разработка проекта продукта (PD), детализированный дизайн продукта (DD), кодирование и тестирование разрабатываемого модуля (CUT). Интеграция и тестирование (IT) , а

также поддержка (MN) описываются на протяжении всего жизненного цикла. Фазы могут применяться для разбиения систем, подсистем и /или модулей. На каждой фазе могут применяться различные множители трудозатрат. Различные значения множителей драйверов затрат устанавливаются на каждом из трех уровней иерархии программных продуктов (система, подсистема, модуль), а также на каждой фазе внутри иерархий.

Преимущество модели СОСОМО:

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

−применяемый в данном случае процесс является повторяемым;

−метод позволяет добавлять уникальные факторы корректировки, связанные

сданной организацией;

−он является достаточно универсальным и может поддерживать различные

«режимы» и «уровни»;

−идеально подходит для проектов, между которыми нет существенных отличий относительно размера, сложности или протекания процесса;

−возможно высшая степень калибровки с опорой на предыдущий опыт;

102

−обязательная документация;

−простота в применении.

Недостатки модели СОСОМО:

−игнорируется изменяемость требований;

−игнорируется документация и другие требования;

−игнорируются атрибуты заказчика – навыки, кооперирование, знания и способность к реагированию;

−слишком упрощается влияние вопросов безопасности;

−игнорируются проблемы обеспечения безопасности ПО;

−не учитывается среда разработки ПО;

−игнорируются уровни взаимодействия персонала;

−игнорируются многие вопросы, связанные с аппаратным обеспечением;

−все уровни зависят от оценки размера – точность оценки размера оказывает влияние на точность оценки затрат, время разработки, подбор персонала

иоценку производительности;

−оценки, основанные на опыте, могут быть некорректным по причине устаревания используемых хронологических данных либо по причине забывчивости специалиста по оценке;

−существует зависимость между знаниями по драйверам затрат и количеством времени, затраченного на каждой фазе.

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

созданных с применением спиральных моделей, а также приложений,

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

103

Фактически СОСОМО II включает три различные модели:

− Композиционная прикладная модель – эта модель подходит для проектов,

созданных с помощью современных инструментальных средств, применяемых для

«строительства» GUI. Модель основывается на новых объектных точках.

− Модель ранней разработки проекта – эта модель применяется для получения приближенных оценок проектных затрат и периода выполнения проекта перед тем, как будет определена архитектура в целом. В случае используется небольшой набор новых драйверов затрат и новых уравнений оценки. Также в качестве базы используется набор не настраиваемых функциональных точек либо

KSLOC.

− Пост-архитектурная модель СОСОМО – наиболее детализированная модель COCOMOII, которая используется после разработки общей архитектуры проекта. В состав этой модели включены новые драйверы затрат, новые правила подсчета строк, а также новые уравнения.

5.4 Математическая модель SLIM

В регрессионном моделировании делается упор на создание формулы, которая лучше всего представляет точки данных рассеяния. В математическом моделировании главным является сопоставление данных с формой существующей математической функции. В начале 1960-х годов, Питер В. Норден (PeterV.Norden)

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

Позднее, в 1970-х годах, Лоуренс Ш. Патнам (LawrenceH.Putnam) применил результаты Нордена к жизненному циклу разработки ПО. При этом проверялось существование оптимальной кривой подбора персонала для текущего проекта. Он начал свою работу с 50 проектов, имеющих отношение к американской армии, а

теперь располагает эмпирическими сведениями о нескольких тысячах проектов.

104

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

«зачистку требований», разбиение на фазы либо последовательную доставку,

повторное использование, а также применение коммерческих готовых продуктов.

Преимущества модели SLIM:

−поддерживает исчерпывающий набор инструментов менеджмента разработки ПО, выполняющих поддержку программ на протяжении всего жизненного цикла;

−способствует приобретению «хороших привычек» членами команды инжиниринга и менеджмента;

−предлагает эффективное планирование с добавлением значений, особенно при работе с большими проектами;

−использует линейное программирование, статистическое моделирование,

оценку программ, а также техники обзора, применяемые при оценке затрат на

разработку ПО;

−позволяет выбирать «разработку проекта по затратам», если пользователь выбирает ввод размера и желаемого количества человеко-месяцев;

−позволяет организации настраивать фазы жизненного цикла и ключевые стадии для данной среды;

−упрощает стратегический процесс принятия решений;

−поддерживает оптимальную политику управления персоналом в контексте среды разработки, реализует анализ;

−поддерживает информацию о количестве дефектов;

−в модели SLIM выводится минимальное время, а также соответствующие

затраты, включая анализ чувствительности, в ходе выполнения которого

105

показывается, как изменяются значения, т.е. подобно тому, как варьируются оценки

размеров в трех стандартных реализациях.

Недостатки модели SLIM

−ее лучше всего использовать при работе с большими проектами;

−для использования модели необходимо заранее определить размер ПО;

−оценки являются сверхчувствительными к технологическому фактору;

−модель очень чувствительна к времени поставки (td);

−модель очень чувствительна к оценке размера;

−предполагается использование жизненного цикла каскада, который не отображается на инкрементальный итеративный процесс разработки либо на рациональный унифицированный процесс;

−пользователи должны помнить о необходимости добавления фаз и интегральных задач, таких как программный менеджмент;

−этот инструмент является сложным, - вряд ли будет возможным с его помощью за 2-5 минут модифицировать модель;

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

Контрольные вопросы

1 Опишите модель СММ и процесс оценивания.

2Перечислите ориентиры и этапы оценки трудозатрат разработки ПО.

3Опишите модель конструктивных затрат СОСОМО.

4Опишите математическую модель SLIM.

106

6 Введение в программный инжиниринг

Программный инжиниринг (разработка ПО) не относится к компьютерным наукам в полном смысле этого слова. Скорее он служит проводником идей в неких абстрактных языках программирования. Впервые появившись в далеком 1968году,

разработка ПО с полным правом может быть отнесена к самому современному виду инженерной деятельности: «Название «программный инжиниринг» было далеко не случайным, ибо оно выражало потребность индустрии по производству ПОв теоретических основах в практических дисциплинах, которые являются вполне устоявшимися в традиционном инженерном деле» [16]. В своем выступлении на этой конференции Фриц Бауэр определил программный инжиниринг как

«реализацию в применение четко выработанных инженерных принципов с целью разработки экономичного ПО, которое является надежным и может выполняться на реальных компьютерах» [17].

6.1 Определение программного инжиниринга в модели СММ SEI

Модель CMM имеет отношение к группе моделей программного процесса,

разработанных на широкой базе, поддерживаемой сообществом разработчиков ПО.

Представляя собой норматив, модель CMM идентифицирует возможности организации, относящейся к категории той или иной степени зрелости.

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

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

Модель CMM не является сборником предписаний на все случаи жизни. Здесь не указывается, каким образом организация должна устанавливать атрибуты

процесса. Также её применение не гарантирует немедленный успех. Процесс

107

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

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

–определенный – указывается способ, требуемый для выполнения дела;

–документированный – разработан таким образом, что может быть известным

ииспользуемым в дальнейшем;

–изученный – обучение на основе документации;

–практичный – может применяться на практике, а не откладываться в «долгий

ящик»;

–поддерживаемый – доступный, пересмотренный и улучшенный;

–контролируемый – изменения одобрены «участниками собственного дела»;

–верифицирован – процесс выполняется корректно;

–проверен – выполняется именно то процесс, который необходим;

–измеренный – оцененная производительность применяется в качестве базиса для контроля и улучшения процесса;

–способность к улучшению – гибкость и способность к изменениям.

Назначение процесса инжиниринга программных продуктов заключается в последовательном выполнении хорошо продуманного процесса инжиниринг, в

результате чего достигается информация всех соответствующих действий,

направленных на быстрое и эффективное получение корректных и совместимых программных продуктов.

Цели программного инжиниринга:

Цель 1. Определяются, интегрируются и последовательно выполняются задачи, связанные с процессом программного инжиниринга, а в результате чего разрабатывается ПО.

108

Цель 2. Поддерживается взаимная совместимость между программными продуктами.

Действия программного инжиниринга:

Действие 1. Производится интеграция в определенный процесс программного проекта уместных методов и инструментов программного инжиниринга.

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

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

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

Действие 5. Тестирование ПО производится в соответствии с определенным программным процессом проекта.

Действие 6. Планируется и выполняется интегрированное тестирование,

соответствующее определённому программному процессу проекта.

Действие 7. Планируется и выполняется системное тестирование, а также тестирование пригодности ПО. В результате проверяется степень соответствия ПО сформулированным по отношению к нему требованиям.

Действие 8. Разрабатывается и поддерживается документация в соответствии с определенным программным процессом проекта Она используется на этапе эксплуатации и поддержки ПО.

Действие 9. Производится сбор и анализ данных о дефектах, полученных входе выполнения экспертных оценок и тестирования ПО.

109

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

Процесс программного инжиниринга представляется собой «применение систематического, упорядоченного и исчисляемого подхода к разработке,

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

Кодирование и тестирование

Рисунок 6.1– Не используйте этот жизненный цикл

6.2 ПО, инжиниринг и программный инжиниринг

При определении понятия ПО используют некий исторический контекст. До

1968 года термин «программный инжиниринг» вообще не применялся. Если руководствоваться определением ПО как совокупности объектов, которые

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

является устройство, автоматизирующее прядильный процесс.

Первое появление широко распространенного ПО датируется 1890 годом.

Именно в это время в Американских центрах по проведению переписи населения

110