ОПИ-2. Министерство науки и образования рф
 Скачать 1.52 Mb.
|
|
два основных этапа. Первый этап состоит в оценивании размера - масштаба проекта, на втором этапе представление об этих размерах наряду с информацией о других факторах среды разработки используется для оценивания трудозатрат и, соответственно, стоимости и продолжительности работ. Оценка технико-экономических показателей программных средств. Основными ресурсами у разработчиков при создании сложных комплексов программ являются: допустимые трудозатраты на разработку ПС с требуемым качеством; время - длительность полного цикла создания программного продукта; необходимое и доступное число специалистов соответствующей квалификации. Потребность в этих ресурсах в наибольшей степени зависит от размера - масштаба и сложности разрабатываемого ПС. Когда впервые рассматривается масштаб нового проекта ПС, интуитивные и экспертные оценки его трудоемкости могут отличаться от конечного значения примерно в полтора раза в ту или другую сторону. Рисунок 1 иллю- стрирует достоверность, с которой могут быть получены оценки трудоемкости или стоимости ПС, представленные в виде функции этапа ЖЦ (горизонтальная ось), или уровень знаний о предполагаемой работе над ПС. Такая достоверность оценок обусловлена уровнем неопределенности на данном этапе знаний о конечном содержании и возможном размере программного продукта. Хотя на рис.1 представлена симметричная картина, общая тенденция состоит в том, что на начальных этапах оценки затрат чаще всего занижаются. Эта неопределенность уменьшается по мере детализации и углубления содержания и функций проекта, как только фиксируются конкретные принципы функционирования и концепция ПС. На этом этапе оценка достоверности размера уменьшается приблизительно до 40%. Рис.1 Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти вопросы могут быть разрешены во время разработки структуры и спецификаций требований к ПС и тогда можно оценить размер ПС с точностью до 15 -20%. После завершения разработки и подтверждения проектных спецификаций при детальном проектировании комплекса про- грамм может быть определена структура внутренних данных и функции программных компонентов. На этом этапе оценка размера и трудоемкости проекта может составить около 10%. Неопределенности оценок могут быть обусловлены: особенностями конкретных алгоритмов, управления их работой, обработки ошибок, инициализации и завершения сеансов работы и т.д. Эти уточнения размеров ПС и компонентов могут быть решены к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса программ и его трудоемкости порядка 5 - 10%, связанная с тем, насколько хорошо программисты понимают спецификации, в соответствии с которыми они должны кодировать программу. Основной вывод, вытекающий из рис.1, состоит в необходимости быть последова- тельным при определении исходных данных при оценке ТЭП для различных компонентов программного продукта и этапов проектирования. В общем случае желательно достигать сбалансированного набора целей оценивания ТЭП комплекса программ, который бы давал примерно одинаковую величину уровня неопределенности для всех исходных данных и компонентов ПС. По мере выполнения проекта, оценки ТЭП необходимо пересматривать и изменять, когда это становится выгодным или не- обходимым. Можно начинать с определения оценок трудоемкости в соответствии с точностью определения размера ПС по данным спецификаций требований с учетом минимума факторов, но при дальнейшем анализе уточнять оценки с точностью деталей функционирования и с учетом влияния совокупности важнейших факторов и характеристик проекта. Рис.2 При оценках ТЭП целесообразно учитывать: - цели оценивания ТЭП должны быть согласованы с потребностями в информации, способствующей принятию решений на соответствующем этапе проекта ПС; - достоверность оценок ТЭП должны быть сбалансированы для различных компонентов системы и величина уровня неопределенности для каждого компонента должна быть примерно одинаковой, если в процессе принятия решения все компоненты имеют одинаковый вес; - следует возвращаться к предшествующим целям оценивания и изменять их, когда это необходимо для ответственных бюджетных решений, принимаемых на ранних этапах и влияющих на следующие этапы. Измерение размера, оценка и составление графика разработки сложным образом переплетаются в процессе планирования проекта. На самом деле довольно сложно создать реальный график (учитывающий обязанности исполнителей, их зависимости, перекрытие действий, а также дату поставки продукта) без информации об объеме трудозатрат, требуемых для выполнения каждой задачи (например, определения нагрузки сотрудников на месяц). Достаточно трудно оценить объем трудозатрат, необходимых для выполнения задачи, без достоверной информации относительно ее размера. Таким образом, измерение размера (сложности) предшествует оценке ТЭП, а эта оценка, в свою очередь, предшествует составлению графика работ. Каждое из этих важных действий проекта может быть выполнено с помощью различных методик. Недостаточно достоверные оценки влекут проблемы взаимодействия разработчика с заказчиком и увеличивают степень риска проекта. В индустрии ПС часто обращаются к использованию метрики LОС, единицы измерения, хорошо знакомой практикам в области разработки ПС. Они находят ее комфортной и простой в применении. Какая бы технология не использовалась, оценка размера будущего продукта является весьма важной, поскольку она является частью одной наиболее важной задачи проекта: установка реальных ожиданий. Нереальные ожидания, основанные на неточных оценках, представляют собой одну из частых причин провала проектов. Зачастую причина кроется не в недостаточной производи- тельности команды проекта, а в неточном предвидении уровня этой производительности и размера проекта. Точное оценивание ТЭП обеспечивает улучшенный контроль над проектом и является жизненно важным в деле проектного менеджмента. Для обеспечения точного оценивания в первую очередь следует иметь представление относительно размера продуцируемого ПС. Эта величина должна определяться на ранних стадиях цикла разработки и выражаться в единицах, которые являются достаточно простыми. Исходные данные реальных завершенных разработок для оценивания ТЭП, собираются, накапливаются и обрабатываются, с начала 70-х годов в разных отечественных организациях и за рубежом. Они позволили получать и прогнозировать основные обобщенные технико-экономические показатели процессов разработки ПС. При этом компоненты операционных систем, драйверы, средства контроля и тестирования, а также повторно используемые компоненты обычно не учитывались при оценке размера вновь созданных комплексов программ и трудоемкости их полной разработки. Поэтому технико-экономические показатели проектов этого периода можно отнести к полностью оригинальным разработкам комплексов программ. При этом обычно рассматривался полный технологический процесс разработки ПС от начала подготовки технического задания (ТЗ) до завершения испытаний базовой версии ПС. Учитывались все категории специалистов, участвующих в создании программ и обеспечивающих разработку, а также все виды работ, связанные с созданием программного продукта на выделенном интервале времени. Теоретические работы и системный анализ до подготовки ТЗ в значениях ТЭП не учитывались. Наиболее полно и подробно основные закономерности и влияние факторов на технико-экономические показатели процессов разработки сложных ПС в 70 - 80 годы, представлены в материалах Б.У. Боэма под названием «Инженерное проектирование программного обеспечения» для более десяти моделей прогнозирования. В 1981 году на основе исследования процессов разработки 63 проектов ПС опубликована модель прогнозирования ТЭП под названием КОМОСТ. В последующем, эта модель развита, детализирована и опубликована как СОСОМО, а в 2000 году под названием СОСОМО II. В этой модели на основе анализа более 160 реальных проектов разработки комплексов программ различной сложности уточнены рейтинги влияния выделенных факторов на основные ТЭП. Эти данные ниже используются и рекомендуются как базовые для прогнозирования затрат при создании ПС. Кроме того, в 1988 году опубликованы результаты анализа ТЭП комплексного проекта ПРОМЕТЕЙ на основе обобщения результатов разработки свыше 250 отечественных проектов сложных ПС, отдельные фрагменты которых также использованы ниже. В общем случае для оценки технико-экономических характеристик новых проектов необходимы исходные данные: - обобщенные характеристики использованных ресурсов и технико- экономические показатели завершенных разработок - прототипов ПС, а также оценки влияния на их характеристики различных факторов объекта и среды разработки; - реализованные и обобщенные перечни выполненных работ и реальные графики проведенных ранее разработок различных классов ПС; - цели и содержание частных работ в процессе создания сложных комплексов программ и требования к их выполнению для обеспечения необходимого качества ПС в целом; - структура и содержание документов, являвшихся результатом выполнения частных работ. Наиболее важен учет и анализ факторов на начальных этапах разработки, когда прогнозируются первичные совокупные затраты С р на создание ПС (табл.1). На этих этапах неопределенность оценки параметров и факторов наибольшая (рис.1), тем не менее применение приводимых характеристик позволяет избегать наиболее крупных ошибок при оценке затрат, которые делаются экспертами без детального анализа влияния факторов. Подобный анализ является базой для рационального распределения ресурсов и для управления их использованием по мере развития проекта. Учет и прогнозирование возможного изменения затрат в зависимости от основных параметров способствует упорядочению процесса разработки ПС и концентрации усилий на тех факторах, которые могут дать максимальный эффект уменьшения затрат в конкретных условиях создания комплекса программ. После проведения структурного проектирования и распределения ресурсов ПС возможна ошибка в оценке затрат на разработку приблизительно в полтора-два раза меньше, а перед программированием она может уменьшаться до 10 - 15%. Такие достоверности можно получить, конечно, только при подробном анализе и оценке влияния важнейших факторов. Этапы жизненного цикла программ существенно различаются между собой степенью определенности и прогнозируемости их характеристик. Соответственно изменяются возможности подготовки и достоверность планов проведения работ. В процессе разработки сложных программных средств уточняются и детализируются их спецификации требований, функции, структура и характеристики компонентов. Поэтому на начальных этапах, особенно принципиально новых проектов, трудно спланировать точно все последующие этапы. В результате планирование проводится итерационно в соответствии с последовательным повышением достоверности и точности сведений об объекте и среде разработки. Разработка сложных ПС, особенно на начальных и завершающих этапах, характеризуется высокой долей творческого труда. Поэтому трудоемкость и длительность отдельных операций и частных работ существенно зависят от индивидуальных особенностей их исполнителей и характеристик конкретного проекта. Вследствие этого отсутствует достоверная кооперационная статистика разработки программ, и пока невозможно создать типовые нормативы на большинство частных операций при создании ПС. Отсюда принципиальной особенностью планирования разработки комплексов программ является активное участие руководителей и заказчиков проекта в составлении планов на базе исследованных характеристик прототипов завершенных разработок ПС и их личного опыта. Такие планы должны иметь разумные ограничения в детализации работ на уровне, обеспечивающем необходимую управляемость всего процесса проектирования. В процессах и системах автоматизации планирования и управления разработкой ПС целесообразно учитывать следующие их особенности: - последовательную, иерархическую детализацию и поэтапное уточнение планов и прогнозов в соответствии с повышением полноты и достоверности исходных данных об объекте и среде разработки, получаемых в процессе создания ПС; - использование прототипов технико-экономических показателей, перечней и графиков частных работ как основных исходных данных для прогнозирования и планирования разработки новых ПС; - целесообразность и возможность выбора первичного прототипа перечня работ, достаточно адекватного исходным данным проектируемого ПС, и возможность его уточнения проектировщиком; - регистрацию, обобщение и хранение реализованных рабочих планов и значений ТЭП для их использования в качестве прототипов при планировании последующих аналогичных разработок. Таким образом, в процессе планирования после использования прототипов для прогнозирования и планирования очередной разработки происходит ее реализация, данные которой могут быть использованы в качестве прототипов для последующих проектов. Тем самым может быть создана последовательно уточняющаяся база данных, позволяющая повышать достоверность прогнозирования и планирования разработок ПС определенного класса. Внутри этого цикла может происходить разработка конкретного ПС, для которой характерно также последовательное уточнение и детализация про- гнозов и планов. В качестве базового варианта целесообразно принять статистические данные ТЭП, перечень работ и документов жизненного цикла создания наиболее сложного встроенного комплекса программ реального времени (табл.1). На основе этих исходных данных могут быть оценены ТЭП для полного цикла разработки ПС конкретного вида в более простых случаях путем исключения из базового варианта работ и документов, в которых отсутствует необ- ходимость. По оставшимся работам могут быть оценены ТЭП для вариантов и выбран из них предпочтительный. Для технико-экономического анализа процесса создания программ важнейшей составляющей являются совокупные трудовые затраты - трудоемкость С на непосредственную разработку ПС. Трудоемкость разработки программных средств наиболее сильно зависит от размера — масштаба программ, выраженного числом операторов на ассемблере или строк на языке программирования высокого уровня. В п. 4 обсуждался вопрос о способах и единицах измерения размера разрабатываемых программ и обоснована целесообразность проводить эти оценки в числе операторов (команд) на языке ассемблера. Реальное изменение создаваемых в настоящее время сложных ПС от 10 4 до 10 7 строк (LОС) определяет диапазон трудоемкости разработки таких программ от человеко-года до десятков тысяч человеко-лет. Широкий диапазон изменения размера создаваемых программ в наибольшей степени определяет значения суммарной трудоемкости их разработки. Подтверждена по большому числу проектов высокая статистическая корреляция между размером комплексов программ в операторах на ассемблере и трудоемкостью их разработки. С другой стороны, отсутствуют какие либо данные о значительном преимуществе других мер размера и сложности при прогнозировании затрат на разработку сложных и сверхсложных ПС. Объем программ в числе операторов на ассемблере характеризуется простотой и экономичностью определения, а также удобством для расчетов и прогнозирования. Опыт подсказывает, что по мере увеличения размера комплекса программ возрастают не только абсолютные, но и относительные затраты на разработку каждой строки текста в программе. Вследствие этого затраты труда при разработке одной строки текста в программах разного объема могут различаться в несколько раз. Согласно материалам М.Х. Холстеда («Начала науки о программах»), трудоемкость разработки программного модуля пропорциональна квадрату размера программы. Модульно- иерархическое построение крупных ПС позволяет замедлить квадратичный рост сложности и соответствующей ей трудоемкости разработки при увеличении размера программ. Суммарную трудоемкость разработки сложного ПС можно представить двумя сомножителями. Первый сомножитель является доминирующим, он прямо пропорционален размеру программ П и отражает практически линейное возрастание трудоемкости создания любых программ при увеличении их размера. Однако при увеличении размера программ в ряде случаев наблюдается более быстрый рост их сложности разработки, чем описываемый простой линейной зависимостью. Логично предположить, что по мере увеличения размера ПС возрастает относительная трудоемкость разработки каждой строки в программе. Это обстоятельство можно учесть поправочным вторым сомножителем, отражающим изменение трудоемкости на разработку каждой строки в программе при увеличении ее размера. В ряде исследований размер базы данных либо совсем не учитывается, либо включается в объем ПС. Этому способствует также развитие теории сложности в направлении преимущественного анализа функциональной сложности программ при почти полном игнорировании сложности данных и их влияния на технико-экономические показатели. В статистической теории сложности программ показано, что для программных модулей и относи- тельно небольших групп программ велика корреляция между числом имен переменных и числом операторов в программе. Однако для сложных и сверхсложных ПС эта корреляция меньше, что определяет необходимость разделения ПС на два типа: на осуществляющие преимущественно логическую обработку относительно небольшого потока данных и на информационно-поисковые системы при наличии больших баз данных и относительно простой их логической обработке. Для характеристики этих типов программ может использоваться отношение числа имен переменных к числу строк или операторов текста программ. Для первого типа ПС это отношение не превышает десяти процентов, а для второго оно может значительно превышать единицу и достигать десятков и сотен. Затраты при разработке ПС второго типа оказываются зависящими от размера базы данных, который влияет на сложность взаимодействия программ с данными. Хотя размеры базы данных для сложных ПС по числу типов имен переменных изменяются в очень широких пределах, приблизительно от 10 3 до 10 8 , их непосредственное влияние на трудоемкость разработки строки в программе даже при числе переменных, в десятки раз превышающем размер программы, оценивается на уровне 10%. При этом степень этого влияния трудно формализовать, так как большую роль играет структура базы данных и ее функциональное назначение. Поэтому далее этот фактор отдельно не учитывается и только для очень больших и сложных структур баз данных рекомендуется увеличивать трудоемкость на десяток процентов. Накопленный опыт создания ПС позволил выделить группы факторов, влияющих на выбор технологии и на затраты С (рис.2). Абсолютная величина С, так же как и длительность разработки, зависят от ряда факторов, которые могут изменять их в различных направлениях. Наибольшее влияние на них оказывает размер ПС, который из всех параметров изменяется в самом широ- ком диапазоне. Поэтому при первичной оценке непосредственных затрат и длительности полного цикла разработки сложных ПС размер программ используется в качестве базового доминирующего параметра. Остальные факторы можно учитывать поправочными коэффициентами при уточнении интегральных показателей. Для совокупностей ПС первого и второго классов, исследовалась зависимость трудоемкости разработки программ С от их объемов - П. Для аппроксимации зависимости трудоемкости от размера ПС наиболее часто использована степенная функция вида: С = АхП Е (1) При разработке ПС большого размера в значительной степени, должна возрастать сложность разработки по сравнению с ПС малого объема, так как в больших программах существенно усложняются взаимосвязи компонентов по информации и управлению, а также становятся более трудоемкими процессы планирования и управления проектом в ходе разработки. Выдвинутая гипотеза, о возрастании трудоемкости разработки с ростом размера ПС быстрее, чем по линейному закону, справедлива, если показатель степени в полученном уравнении регрессии Е > 1. По методу наименьших квадратов в ряде работ определены коэффициенты A и Е в уравнениях степенной регрессии, показывающие характер зависимости трудоемкости от размера ПС. В таблице 3.1. представлены значения коэффициентов регрессии для моделей КОМОСТ, СОСОМО и ПРОМЕТЕЙ, для основных классов проектов программных средств. Выражение (1) с использованием этих коэффициентов и значений П размера ПС в тысячах строк ассемблера рекомендуется для прогнозирования трудоемкости полной разработки в человеко-месяцах. Таблица 2 Коэффициенты моделей для оценки трудоемкости разработки программных средств Коэффициент А Коэффициент Е Модель и тип программных средств 2,4 1,05 Базовая - КОМОСТ 3,6 3,0 2,4 1,20 1,12 1,05 Детализированная модель СОСОМО: - встроенный; - полунезависимый; - независимый. 2,94 1,15 СССОМО 11.2000 Крупный проект 100 KSLOC 10,0 6,1 1,21 1,17 ПРОМЕТЕЙ Системы реального времени; Информационно-поисковые системы. При разработке крупномасштабных ПС делаются большие затраты на создание технологии, средств автоматизации и унификации разработки, чем при разработке малых ПС. Небольшие ПС часто разрабатываются неопытными коллективами, которые к тому же пренебрегают автоматизацией технологии и применением современных методов структурного проектирования комплексов программ. Так как малые ПС во многих случаях относятся исторически к первому временному периоду — 70 - 90-е годы, когда уровень автоматизации технологии был низок, то и трудоемкость их разработки была достаточно высокой. Эти обстоятельства приводят к тому, что возрастает трудоемкость создания относительно небольших. ПС, а рост суммарных затрат на разработку крупных ПС замедляется, что отражается на величине показателя степени Е, значения которого в некоторых анализируемых выборках иногда получены меньше единицы. Если бы представилась возможность получить ТЭП по однородной выборке ПС разного объема, разработанных по единой технологии на более или менее одном интервале времени, то, конечно, трудоемкость возрастала бы при увеличении П с коэффициентом Е > 1. На практике часто пользуются упрощенной линейной зависимостью трудозатрат от размера ПС (Е = 1). Такое упрощение при недостаточном объеме статистических данных и отсутствии сведений по заранее обусловленным (управляемым) значениям факторов разработки ПС иногда можно считать допустимым. На рис. 3 по уравнениям регрессии (1) построены в логарифмическом масштабе зависимости трудозатрат от размера для ПС двух классов. Первый (встроенные - СРВ) и второй (ИПС) классы ПС, отчетливо различаются по трудоемкости разработки. Более высокой точности оценки трудоемкости разработки только по одной переменной - размеру ПС, по-видимому, невозможно получить, так как процесс разработки зависит от большого числа факторов, которые следует учитывать при оценке трудоемкости. Наибольшие трудозатраты обычно необходимы для разработки крупномасштабных комплексов программ реального времени, так как данный класс программ используется в наиболее ответственных автоматизированных системах. |