книги / Надежность программного обеспечения систем обработки данных
..pdfсивов данных Однако не существует пока какой-либо строгой количественной меры оценки влияния этого фак тора иа стоимость разрабатываемого продукта.
Одним из факторов, отнесенных к окружающей сре де, является наличие и полнота документации. Затраты на разработку документации составляют в большинстве случаев до 10% общих затрат на разработку ПО.
Учет рассмотренных факторов при оценке затрат на разработку ПО является достаточно сложной проблемой. Эта сложность усугубляется еще тем, что некоторые из факторов противоречивы, например сложность программы и ее качество, надежность и квалификация персонала. Обычно при предварительной оценке затрат приводят агрегирование факторов, часто целая группа факторов выражается через один обобщенный показатель.
Считается, что основными ресурсами проекта созда ния ПО являются трудовые ресурсы, машинное время, стоимостные ресурсы и время, истекшее с начала работы. Ход разработки проекта обычно документируется в соот ветствии с принятыми стандартами учета. Накапливаемые данные генерируются инструментом, точность которого неизвестна Так, часто обобщение и учет трудовых затрат, в большинстве случаев ежемесячных, основаны, скорее, на воспоминаниях, чем иа точных данных Не все трудовые затраты, которые относятся к разработке, в действитель ности к ней относятся Обычно только часть рабочего времени расходуется на разработку
4.4 МЕТОДЫ ОЦЕНКИ СТОИМОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Традиционные процедуры определения стоимости лю бой деятельности начинаются с оценки размеров работы, срока начала выполнения и общей продолжительности, устанавливаются количественная и качественная оцен ки потребности персонала для проведения заданной ра боты На основе полученных данных производится оценка расходов, связанных с проведением работ. Можно выде лить ряд подходов к проведению оценки ПО.
Оценка сверху вниз. Лицо, выполняющее оценку (сметчик), основывается на общей стоимости или стоимо сти отдельных крупных составных частей проекта. Нали чие опыта предыдущей работы в сочетании с интуицией позволяют Провести распределение стоимости между от дельными компонентами системы. Это решение не исклю-
чает таких издержек при оценке, как высокая вероятность пропуска специальных или сложных проблем, а также недостаток деталей типа алгоритма конкретного модуля и т. д., необходимых для оправдания назначаемых сто имостей.
Оценка сходств и различий. Сметчик распределяет выполняемую работу по уровням детализации, где сходст ва и отличия от предыдущих проектов наиболее очевид ны. Рабочие единицы, которые не могут сравниваться изза отсутствия аналогов, оцениваются отдельно други ми методами.
Оценка соотношений. Этот подход мог бы называться как сопоставление по эталону, т. е. применительно к клас су продукта ПО имеются в базе данных некоторые оцен ки затрат на создание того или иного продукта ПО. Сметчик, основываясь на коэффициентах соотношения эталона н оцениваемого объекта, вырабатывает оценку применительно к создаваемому продукту.
Предварительно каждый модуль оценивается по воз можному числу объектных команд, классифицируется по нх типу и сложности. Соответствующая матрица стоимо сти строится на основе данных стоимостей нз базы данных в терминах стоимости команды определенного типа ПО и уровня относительной сложности. Другие эмпирические отношения также могут быть использованы в общем про цессе оценки (например, норма использования ЭВМ на отладку одной команды исходного кода, количество об служивающего персонала на одного программиста и т. д.).
Этот метод прост, позволяет быстро выполнить оценку, удобен и полезен как в намечаемой сфере применения, так и за ее пределами. К недостаткам метода можно от нести необходимость достаточно представительной базы данных стоимости для множества оцениваемых ситуаций.
Оценка по стандартам. Этот метод базируется на из вестных (стандартных) нормах затрат на выполнение единицы работы. Стандарты могут стать устойчивыми справочными данными при условии постоянной их кор рекции с учетом накапливаемого опыта разработки и достижений передовых разработчиков. Метод прост, до ступен и точен только тогда, когда одинаковые операции выполняются повторно и доступны хорошо отработанные документы по объектам оценки. Точность метода повыша ется при увеличении глубины градации видов работ. К недостаткам метода можно отнести то, что редко ПО разрабатывается повторно.
92
Оценка с н и з у вверх. По этой методике вся оценивае мая работа делится на относительно небольшие самостоя тельные части или единицы работ. Разбиение продолжа ется до тех пор, пока не будет ясно, какие шаги и способ ности потребуются для решения элементарной задачи. Далее каждая элементарная составляющая оценивается с учетом стоимости с получением итога стоимости по всему ПО.
Преимуществом данного подхода является то, что ра бота по оценке может быть поручена даже простым ис полнителям, не обладающим достаточным опытом. Выпол няя детальную оценку по элементарным конструкциям ПО, сметчик не ощущает общей стоимости продукта ПО, что не накладывает ограничений на его работу.
Процесс оценки почти всегда выполняется с исполь зованием двух или более описанных выше подходов. Например, оценка методом «сверху вниз» может быть уточнена и проверена оценкой по методу «снизу вверх».
Одним из используемых алгоритмов оценки стоимости создаваемого ПО является алгоритм фирмы TRW. Он основан иа предположении, что стоимость ПО изменяется пропорционально числу команд. Для каждой опознанной процедуры производится оценка количества объектных команд и категорий сложности. Данные исторического плана по стоимости получения одной команды извлека ются из базы данных.
Оценка выполняется группой проектирования, опреде ляющей параметры оцениваемого объекта, и группой системного анализа, осуществляющей поддержание базы данных стоимостных значений. Кроме того, группа систем ного анализа выполняет распределение ресурсов по эта пам цикла разработки, разрабатывает графики выполне ния работ и определяет требуемую квалификацию ис полнителей.
Далее» алгоритмом предусматривается получение об щей стоимости за период выполнения работ в соответст вии с входными параметрами, затрат по категориям тру да, стоимости, связанной с каждым видом выполняемой работы и использованием ЭВМ для контроля, отладки и тестирования. Выход алгоритма рассматривается как «пробная оценка» в смысле ее сопоставления с наложен ными стоимостными ограничениями на проект.
Первым шагом алгоритма предусматривается распре деление компонентов ПО по категориям сложности с учетом затрат иа разработку. Категории ПО выбраны н а
93
основе опыта и объединяют функционально различные виды объектов ПО:
1)управляющая программа, осуществляющая кон троль за выполнением программ;
2)программы ввода-вывода, обеспечивающие переда
чу информации в (из) ЭВЛ1); ■ 3) программы обработки данных последовательных вычислений;
4) программы, выполняющие логические и математи ческие преобразования;
5) программы управления данными внутри ЭВМ. ' Следующим шагом является оценка размеров и слож ности будущего продукта ПО разработчиками. Для того чтобы сбалансировать стоимость и риск, разработчик может использовать доступные ему элементы ПО из биб лиотечного набора с учетом стоимости на адаптацию. С другой стороны, методика новой разработки может быть оценена тем технологическим риском, который бу дет иметь место при попытке получения надежной и эф фективной программы. Решающим моментом в определе нии стоимости является оценка сложности программы, так как здесь могут быть допущены определенные откло нения из-за отсутствия однозначных утверждений. От по лученной стоимости берутся процентные отношения на до полнительные прямые и косвенные затраты. В результате суммирования получается общая стоимость разработки Продукта ПО.
Существуют различные подходы к оценке сложной Программы. Так, например, возможна оценка по установ ленной шкале сложности иа основе следующих входов:
характеристика используемой ЭВМ, характеристика используемого языка программирова
ния, приблизительное число команд программы,
сходство с предыдущими разработками.
Для снижения субъективности в начальной стадии оценивания необходимо четко решить вопрос, разраба тывается новая уникальная программа или подобная программа уже разрабатывалась, какова истинная слож ность разработки программы и т. д.
Следующим шагом алгоритма является идентифика ция этапов разработки, тестирования и передачи разра ботанного ПО по назначению. Для каждого этапа тре буется оценка распределения затрат. Обычным считается Правило распределения «сорок-двадцать-сорок», т. е. 40%
м
стоимости приходится на лроектирование и анализ, 20%— на кодирование и отладку, 40%— иа контроль и тестирование.
Четвертый шаг алгоритма — определение действий внутри каждого этапа разработки при помощи массива действий и связанной с ним матрицы стоимостей. Состав ными частями этапов являются процессы. Так, если при нято выделять 3 этапа и 10 процессов внутри них, то будем иметь матрицу действий 3X10.
Последний шаг алгоритма состоит в установке на чальных условий для оценки стоимости и включает по строение таблицы данных, основанной иа задании заказ чика на разработку; ввод графика разработки; верхних оценок затрат проектирования и накладных расходов. Другие прямые расходы обычно задаются в размере 3% и расходы иа документацию — в размере 10% стои мости разработки.
Общий выход алгоритма оценки стоимости включает следующие показатели:
стоимость разработки программы, включающую задан ные накладные расходы или накладные расходы, вычис ленные на основе исторических данных;
среднюю стоимость команды, число команд и катего рии сложности;
общее потребное время ЭВМ на программу; графическое отображение расписания работ на уровне
граф-схем событий; распределение стоимости по процессам разработки
на программу в абсолютном значении и в % от общей суммы;
группировку стоимости по модулям (если программа разделена на модули) и процедурам;
загрузку по месяцам выполнения работы в разрезе руководящего персонала, исполнителен и обслуживаю щего персонала, а также оценки потребного машинного времени по месяцам и совокупную стоимость разработки.
Выход алгоритма стоимости является «набором проб» для группы системного анализа. Этот набор используется в комбинации с информацией всех других источников для того, чтобы проверить правомочность распределения стои мости по целям проектирования. Анализ полученных дан ных позволяет внести корректировки и получить оконча тельный вариант набора показателей, определяющих стоимость продукта ПО.
Одним Н8 нерешенных вопросов является оценка про-
изводительности труда программистов. В качестве рабо чего стандарта фирма TRW обосновала оценку произво дительности труда как одну объектную команду за чело веко-час работы, что эквивалентно 156 командам за че ловеко-месяц или 1870 командам за человеко-год.
Установлено, что человеко-месяц накладных расходов на разработку изменяется в пределах от 4300 до 4900 дол ларов Это значит, что при типичном разделении труда в группе программирования среднее значение стоимости од ной команды составит от 27,5 до 31,5 доллара. Из при веденных количественных характеристик следует, что раз брос в оценках достаточно велик, а это еще раз ставит вопрос о полноте и качестве оценочной базы данных стоимости. В связи с этим одной из первоочередных задач решения стоимостных оценок проектирования ПО продолжает и далее оставаться совершенствование под хода к обновлению базы данных.
Другой проблемой, субъективный характер которой влияет на стоимость ПО, является оценка сложности. Необходимо знать, как зависит производительность программирования от сложности разрабатываемой про блемы. Набор факторов, определяющих оценку слож ности, не является однозначно выявленным и ранжиро ванным.
Не ясно также, как влияет выбор ЭВМ р ее конфигу рации на производительность труда программиста. Здесь имеется в виду то, как конкретная проблемная програм ма адаптируется на данную ЭВМ (в смысле набора опера ций и предоставляемых возможностей). Важно также то, что предоставляет операционная система для разраба тываемого Проекта ПО.
Ранее был показан значительный разброс в произво дительности труда различных программистов. Естествен ным кажется вопрос о том, как личные качества програм миста, его образовательный и культурный уровень влия ют на выполняемую работу. Важность решения этой проблемы с учетом разброса в оценках производитель ности в пределах от 1 до 5 еще раз подчеркивается при разработке больших систем ПО, включающих миллионы команд.
Наличие технических стандартов и критериев оценки труда программиста способствует исключению большого разброса в производительности труда. Но эти же меро приятия, лишая человека возможности творческого труда, делают любимую работу обычным регламентированным
96
трудом. С другой стороны, наличие даже плохого стан дарта для такой массовой профессии, как программиро вание, лучше, чем отсутствие стандарта, так как, по край ней мере, он дает представление о направлении прило жения усилий по достижению производительности тру да.
До сих пор неясно, как зависит стоимость создания ПО от полноты и необходимости выдвинутого набора целей продукта ПО. Если еще раз акцентировать внимание на том, что стоимость этапа проектирования и анализа составляет 40% общей стоимости проекта, то стоит снова обратиться к проблемам разработки требований, формули-т ровки целей и спецификации. Далее будет показана не обходимость привлечения заказчика к работе над проек том. Сейчас же можно отметить, что работа на обсуждае мой стадии создания ПО связана с неполной информаци ей. Недостаток информации на начальной стадии может привести к резкому увеличению стоимости проекта ПО.
Есть определенные проблемы и в применении методов оценки стоимости создаваемого ПО. Так, например, за-12*5 дача системы оценки стоимости заключается в сведении к минимуму различий между оценками предсказанной и фактической стоимости. Известны в общем плане пути достижения минимума расхождения, однако детали про блемы остаются нерешенными.
В целом проблема оценки стоимости разработки ПО находится сейчас на начальной стадии развития. Однако перевод к индустриальным методам разработки ПО практически невозможен без решения вопросов предва рительной оценки стоимости и устранения расхождений между прогнозируемой и фактической стоимостью.
|
Вопросы к главе 4 |
1 |
Сформулируйте причины сложности оценки стоимости ПО |
2 |
В чем состоят специфические особенности ПО? |
3. |
Ранжируйте факторы, определяющие стоимость разработки ПО. |
4.Дайте оценку преимуществ и недостатков приведенных методоа оценки стоимости ПО.
5Дайте характеристику основных направлений работ по оценке за трат на ПО
вСформулируйте причины, сдерживающие проведение работ по оцен ке затрат на ПО
97
Р а з д е л II
ТЕХНОЛОГИЧЕСКИЕ МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ
Как ранее отмечалось, создание программного обес печения включает несколько этапов, содержащих процес сы разработки ПО. В подготовленном проекте эти процес сы явно идентифицированы с тем, чтобы было можно установить контрольные точки начала и завершения каж дого из них, реализовать соответствующую технологию разработки и иметь возможность оценить качество вы* полнения работы на каждом этапе.
Методы проведения работ на каждом из этапов в зна чительной мере определяют надежность разрабатываемо
го программного обеспечения. Например, начальный этап проектирования включает процессы формирования требо ваний пользователя к системе, описание целей разраба тываемой системы и создание ее спецификаций. Целью проектирования на данном этапе является высокоуров невая проработка с определением интерфейса пользова теля будущей системы ПО.
Внешнее проектирование системы ПО включает раз работку ее архитектуры и проектирование структуры программ на базе детальных спецификаций. Процесс по строения архитектуры предусматривает разделение систе мы на некоторый набор программ, подсистем или компо нентов с определением интерфейса между ними. Целью процесса проектирования структуры программ является выделение модулей и определение интерфейса между ни ми. Результатом данного процесса в общем случае явля ется набор модулей н описание их взаимосвязей.
Этап проектирования и кодирования модулей включа ет процессы проектирования структуры каждого модуля, его логики и кодирования на конкретном языке програм мирования.
Системы программного обеспечения, как и любые другие технические системы, проходят после завершения проектирования стадию контроля. При этом контроль
Эв
системы ПО обладает существенными отличиями от кон троля технической системы. Основные отличия Состоят в том, что любая система ПО является необслуживаемой и, как правило, логически гораздо более сложной. Процесс контроля системы ПО осуществляется тестиро ванием как ее функциональных возможностей, так и ло гики работы.
Система ПО проектируется при наличии неполной ин формации относительно окружающей среды функциони рования. Кроме того, специфические условия труда про граммиста и особенности продукта этого труда являются следствием внесения ошибок, количество и степень влия ния которых на систему достаточно неопределенны и за висят от совокупности различных объективных и субъек тивных факторов. Спроектированные системы ПО, как правило, не пригодны к эксплуатации без целенаправлен ного и глубокого тестирования. В большинстве случаев приходится иметь дело с системами, стоимость разработки и тестирования которых высока, поэтому процесс контро ля схематично можно представить в следующем виде.
Система проектируется как совокупность формально самостоятельных составных частей — модулей. Модули разрабатываются и тестируются с учетом удовлетворе ния частных задач и требований на их реализацию. Если в процессе тестирования достигается заданная степень надежности модулей системы, то можно переходить к их интеграции и испытаниям системы в целом. Если в про цессе тестирования обнаруживаются ошибки в составных частях или в системе в целом, то, обрабатывая инфор мацию об ошибке, устанавливают породившую ее при чину. По результатам подобных исследований проводится доработка составных частей или системы в целом, цель которой — устранение предполагаемых или установлен ных причин появления ошибок.
В случае установления причин появления ошибок и их устранения повышается надежность системы. Тести рование продолжается до тех пор, пока не будет достиг нут приемлемый или заданный уровень надежности.
Процесс поиска и устранения ошибок можно рассмат ривать как некоторую последовательность этапов контро ля системы, на каждом из которых она выступает с раз личным уровнем надежности. Сложность доведения про граммы до рабочего состояния определяется тем, на сколько четко было организовано и выполнено ее про ектирование и разработка.
4* |
99 |
Приведенная выше общая схема (см. рис. 3.1) разра ботки и контроля иллюстрирует основные зависимости между процессами, однако их не следует рассматривать как некоторый предписываемый план создания любого проекта системы ПО. Эта схема отражает общую после довательность работ, т. е. какие процессы должны быть завершены к моменту начала выполнения работ очеред ного процесса.
Упрощенность схемы разработки и контроля не должна породить чувство простоты выполнения работы, так как в реальных условиях между процессами существуют обратные связи. Например, на этапе внешнего проекти рования может быть обнаружена неполнота в определе нии целей, что потребует немедленного возврата и исправ ления недостатков. Кроме чисто ошибочных ситуаций, большое влияние может оказать и такой фактор, как стои мость реализации запланированных функций, что также приведет к необходимости проведения повторных работ по спецификации.
Г л а в а 5
ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ НА НАЧАЛЬНОМ ЭТАПЕ ПРОЕКТИРОВАНИЯ
Различие между успешной и неуспешной работой системы лежит в согласованности и полноте специфика ции, целей и системных требований, а также в точности перевода этих тоебований в стоимостные и временные показатели с учетом требующегося для разработки обо рудования.
Первоначальным источником ошибок в ПО являются недостатки в процессе формулировки требований к систе ме и определения ее целей. Основная причина возникно вения этих ошибок заключается в неправильном толко вании или ошибочном понимании потребностей пользо вателя. Еще больше ошибок попадает в разработку на стадии перевода требований и целей во внешние специ фикации системы. Практика показывает, что далеко не все специалисты уделяют этим процессам достаточное внимание.
Наибольший урон ПО в процессе его функциониро вания наносит неправильное представление специфика ций системы, ошибочное определение целей или систем ных требований.
ИМ