Расчет трудозатрат на разработку ПО САПР

Нисходящее программирование.

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

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

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

- нисходящее проектирование может быть совмещено с выполнением отладки программы нисходящим методом.

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

Процесс программирования необходимо планировать, контролировать и завершать в заданные сроки. Кроме того, работу программистов нужно оплачивать по результатам их труда (в зависимости от его качества, количества и интенсивности). Для этого нужны нормы и нормативы труда, позволяющие сравнивать и оценивать планируемые и фактические результаты. На основе опытно-статистических данных были разработаны нормативные документы и стандарты, например, “Укрупненные нормы времени на разработку, изготовление и сопровождение программных средств вычислительной техники” (М.: Экономика, 1988). Данный нормативный документ имеет целый ряд изъянов. Прежде всего он недостаточно формализован, а потому громоздок и неудобен в применении. Кроме того, в нем зафиксированы соотношения, существовавшие десяток лет тому назад, которые к настоящему времени уже изменились и имеют тенденцию к дальнейшим изменениям. Таким образом, данный нормативный материал, основанный на данных анализа прошлых лет и построенный не на прогнозных характеристиках, а на данных анализа опыта прошлых лет и построенный в виде систем таблиц, не выполняет одну из своих основных функций – стимулировать прогресс в конкретной области нормирования.

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

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

Для быстрой приближенной оценки трудоемкости и длительности разработки программного изделия для САПР может использоваться б а з о в а я м о д е л ь , состоящая из нескольких формул:

,

где t – трудоемкость разработки программного изделия, чел.-мес.; n – число тысяч исходных команд;

,

где Т – продолжительность разработки программного изделия, мес.;

П_Р = 1000 n / t ,

где П_Р – производительность труда группы разработчиков программного изделия, (исх. команд / чел.-мес.);

Ч_И = t / T ,

где Ч_И – среднее число исполнителей, чел., рассчитываемое исходя из заданных характеристик трудоемкости и длительности разработки программного изделия.

Таблица 4.1

Характеристики программного изделия ПО САПР стандартных размеров

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

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

Организация процесса конструирования

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

Определение технологии конструирования программного обеспечения

Технология конструирования программного обеспечения (ТКПО) — система ин­женерных принципов для создания экономичного ПО, которое надежно и эффек­тивно работает в реальных компьютерах [64], [69], [71].

Различают методы, средства и процедуры ТКПО. Методы обеспечивают решение следующих задач:

- планирование и оценка проекта;

- анализ системных и программных требований;

- проектирование алгоритмов, структур данных и программных структур;

кодирование;

тестирование;

сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматиче­скую поддержку методов. В целях совместного применения утилиты могут объ­единяться в системы автоматизированного конструирования ПО. Такие системы принято называть САSЕ-системами. Аббревиатура САSЕ расшифровываетсякак Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

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

- порядок применения методов и утилит;

- формирование отчетов, форм по соответствующим требованиям;

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

- формирование «вех», по которым руководители оценивают прогресс.

Процесс конструирования программного обеспечения состоит из последователь­ности шагов, использующих методы, утилиты и процедуры. Эти последовательно­сти шагов часто называют парадигмами ТКПО.

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

Рассмотрим наиболее популярные парадигмы ТКПО.

Классический жизненный цикл

Старейшей парадигмой процесса разработки ПО является классический жизнен­ный цикл (автор Уннстон Ройс, 1970) [65].

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

Системный анализ задает роль каждого элемента в компьютерной системе, взаи­модействие элементов друг с другом. Поскольку ПО является лишь частью боль­шой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элемен­ту». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этане начинается решение задачи планирования проекта ПО. В ходе пла­нирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.

Анализ требований относится к программному элементу — программному обеспе­чению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируются в спецификации анализа. Здесь же завершает­ся решение задачи планирования проекта.

Рис. 1.1. Классический жизненный цикл разработки ПО

Проектирование состоит в создании представлений:

- архитектуры ПО;

- модульной структуры ПО;

- алгоритмической структурыПО;

- структуры данных;

- входного и выходного интерфейса (входных и выходных форм данных).

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

Кодирование состоит в переводе результатов проектирования в текст на языке про­граммирования.

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО.Цели изменений:

- исправление ошибок:

- адаптация к изменениям внешней для ПО среды;

- усовершенствование ПО но требованиям заказчика.

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

Как и любая инженерная схема, классический жизненный цикл имеет достоин­ства и недостатки.

Достоинства классического жизненного цикла; дает план и временной графикповсем этапам проекта, упорядочивает ход конструирования,

Недостатки классического жизненного цикла:

1) реальные проекты часто требуют отклонения от стандартной последовательно­сти шагов;

2) цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

3) результаты проекта доступны заказчику только в конце работы.