Книга: Программное обеспечение и его разработка

Функциональные факторы

Функциональные факторы

1. Функции, количество Чем больше функций, тем больше нужно написать программ для их реализации. С ростом размеров программ трудность разработки программного обеспечения возрастает нелинейно.
2. Функции, сложность Программа вычисления коррекции орбиты для полета к Луне в 50 или более раз труднее, чем программа добавления очередного взноса за покупку в месячную кредитную карточку. Управляющие программы логически сложны, а логическая сложность представляет большую проблему, чем сложность научная.
3. Функции, ясность Некоторые функции (вспомните платежные ведомости) ясны и понятны. Другие находятся лишь в головах старых мастеров, и при попытке записать их на бумаге может возникнуть страшная путаница, а ведь без записи нельзя программировать. Особенно трудно работать с системами типа V.
4. Незамкнутый цикл, человек взаимодействует с работающей системой Системы, одним из элементов которых является человек, более сложны, чем какие-либо другие. Информацию для человека надо готовить особым образом; ответы, исходящие от него, надо приспосабливать к обстоятельствам; среди этих ответов может наблюдаться значительное разнообразие; человеку надо давать и дополнительную информацию, причем последовательность запросов нельзя сделать достаточно строгой, чтобы не получилось так, что он откажется от пользования системой.
5. Число различных пользователей программы Разные пользователи по-разному воздействуют и на вычислительную машину и на ее программное обеспечение. Стало аксиомой утверждение, что чем больше пользователей у программы, тем больше ошибок будет в ней обнаружено. Под пользователем понимается не просто отдельная вычислительная установка. Машины и программы для управления ракетами могут располагаться в сотнях различных мест, но способ использования у всех будет один и тот же.
6. Число запусков программы Если программа должна работать постоянно, нам надо позаботиться об эффективности (сколько аппаратуры необходимо для ее выполнения) в фазе использования. Если программа будет выполнена лишь единожды, ее эффективность не должна нас особенно волновать.
7. Число машин, на которых будет выполняться данная программа Если разрабатываемая программа будет выполняться только на одной машине, нам можно несколько меньше обращать внимания на используемые ею машинные ресурсы. Программа для радиолокатора, выполняемая на сотнях вычислительных машин, на сотнях кораблей, должна быть до предела отточена и сжата. Лишние затраты памяти будут умножаться в сотни раз.
8. Функции и их взаимодействия Некоторые сложные задачи весьма слабо взаимодействуют со всеми другими задачами, которые решаются на той же машине; другие же имеют настолько тесные связи, что оказываются буквально переплетенными.
9. Элементы данных Число и размеры элементов данных, их разнообразие, их взаимодействия, их изменчивость, все это может иметь огромное влияние на размер программы и на трудности, возникающие в фазе проектирования. Брукс замечает: «Покажите мне свои данные, и я смогу больше рассказать о вашей программе, чем в том случае, если мне покажут блок-схемы».
10. Ожидаемая частота внесения изменений в программу Если моя программа стабильна, т. е. изменяется не слишком часто, мне можно строить ее совершенна иначе, чем в том случае, когда я ожидаю, что она будет часто подвергаться изменениям.
11. Взаимодействие с другими системами Если наша вычислительная система должна полностью находиться в распоряжении каких-либо других систем, мы должны обязательна программировать так, чтобы учесть все типы возможных прерываний.
ФАКТОРЫ ФАЗЫ ИСПОЛЬЗОВАНИЯ
12. Доступная мощность ЦП Для выполнения задания каждая программа использует ЦП. Некоторые программы используют его более эффективно, чем другие. Когда ресурсы ЦП оказываются недостаточными, программистов просят так провести проектирование программ, чтобы они не просто выполнили задание, но выполнил его с учетом заранее описанных ограничений недостаточных ресурсов ЦП. И программисты пробуют и проверяют свою работу, и пробуют снова и снова. Программы будут работать, но с точки зрения времени программирования, это стоит очень дорого.
13. Доступные пути ввода/вывода Логически эта проблема не отличается от работы в условиях недостатка ресурсов ЦП, но в данном случае наибольшая потребность возникает в числе путей, по которым данные передаются в машину и из нее. Много стараний должны приложить программисты, чтобы передать весь поток данных через небольшое число «портов», имеющихся в машине.
14. Доступная основная память Опять та же проблема, но уже со стороны памяти. Для хранения программ требуется память, а если памяти не хватает, программист должен «подкачивать» программы в основную память для выполнения и затем откачивать их во вспомогательную память. Для этого приходится затрачивать как время, так и опять-таки пространство. Может быть и другой вариант, в котором приходится втискиваться в отведенные рамки, создавая проект, а затем снова пытаются втиснуться в них. В 1946 году фон Нейман написал в одной из своих работ, что память является ключом к производительности. Это верно и в наши дни; скорость работы с памятью и ее объем есть критические величины.
15. Доступная вспомогательная память Еще раз та же самая проблема; на этот раз со стороны вспомогательной памяти.
16. Надежность/Последствия отказов Двухдневный отказ в системе типа I может быть вполне допустимым. Конечно, он причинит неудобства, но катастрофы за собой не повлечет. Однако, ни часовой, ни 10-минутный сбои нельзя допускать ни в системе управления авиалиниями, ни в системе управления полетом космического корабля, ни в системе противоракетной обороны. Если последствия отказов значительны, нельзя пользоваться стандартной операционной системой (распространяемой поставщиками аппаратуры). Та же проблема возникает и в системах реального времени. В этих случаях либо пишут новую операционную систему, либо модифицируют старую.
17. Ограничения реального времени Если печать платежной ведомости длится 2.5 ч. вместо запланированных 2 ч, кого это по-настоящему волнует? Возникает лишь легкая досада. Но, если радиолокатор поворачивается за 6.4 с, вычислительная машина обязана принять от него данные, закончив к этому времени обработку предыдущей порции. Если этого не будет, система переполнится. В системе реального времени стандартная операционная система применяться не может. Сколько разных объектов может отслеживаться одновременно? Сколько заданий необходимо завершить перед тем, как приступать к решению новой задачи? Чем больше возможностей и необходимости такого рода, тем больше приходится создавать системных программ для управления потоком данных и содержания его в порядке. Примеры: системы разделения времени; управляющие и командные системы; системы диспетчеризации воздушного транспорта.
ФАКТОРЫ ФАЗЫ РАЗРАБОТКИ
18. Адекватность операционной системы Производители вычислительных машин обычно выпускают или сдают в аренду, или продают большие операционные системы вместе с аппаратурой, которая помогает распределять и управлять работой различных аппаратных компонентов вычислительной машины Однако эти операционные системы могут не вполне подходить для разработки программного обеспечения.
19. Время, выделенное на создание программного обеспечения Временной график становится доминирующим фактором в большинстве современных систем типа V. Причина кроется в том, что вычислительная машина и ее программное обеспечение обычно представляют собой лишь часть некоторой сложной системы. Спутники, корабли, оружие, ракеты, здания, фирмы — все это может задавать общий темп — а программное обеспечение должно быть готово одновременно с другими частями системы. Обычно график выдерживается — естественно за счет тех функций, которые надо выполнять. Сдается меньший набор функций, чем планировалось заранее, а недостающие вводятся в систему в более поздние сроки.
20. Доступность средств разработки Средства создания программного обеспечения, как и любой другой инструментарий, существенно воздействуют на производительность труда. Перед тем, как новую машину начнут использовать в качестве инструмента, ее тщательно изучают. Богатый набор мощных средств значительно повышает производительность труда.
21. Доступность машин для разработки программ Этот пункт имеет два аспекта. Во-первых, люди, строящие системы, понимают, что без вычислительной машины при разработке программного обеспечения обойтись очень трудно. Когда машины нет, либо она недостаточно мощна, все страшно замедляется. В то же время люди, незнакомые с ситуацией, не понимают того, что вычислительная машина представляет собой основное средство разработки во всем процессе создания программного обеспечения. Машина на стадии разработки используется столь же интенсивно, как и на стадии использования. Ну и конечно же машина необходима для тестирования программного обеспечения.
22. Знакомство группы, проводящей программирование, с аппаратурой Во всех областях человеческой деятельности нужно отводить время на приобретение опыта, это же относится и к программированию. Если наша группа программистов уже работала с данной аппаратурой, значит в прошлом она уже приобрела опыт, и от этой группы можно ожидать работы с большей производительностью труда.
23. Знакомство группы, проводящей программирование, с разработкой программного обеспечения Время на приобретение опыта, которое, как мы видели, нужно для работы с аппаратурой, нужно и для изучения инструментального программного обеспечения.
24. Число модулей Число модулей и связей между ними относится к ряду факторов, значительно влияющих на сложность выполняемой работы. Эта область сходна с пунктом «функции, их взаимодействия», но имеет и отличие от него в том смысле, что число модулей не обязательно связано с числом функций, поскольку количество модулей связано с методикой проектирования программ, а количество функций неотъемлемо от выполняемого задания.
25. Стабильность средств программного обеспечения Если средства создания программного обеспечения подвержены изменениям, этот и без того сложный процесс еще усложняется дополнительными, часто случайными проблемами. Примером может служить транслятор, в котором есть ошибки и который поэтому создает неправильные рабочие программы.
26. Стабильность аппаратуры Если используемая в фазе выполнения вычислительная машина находится в состоянии доводки, программисты часто не могут разобраться, где находится ошибка, в программе или в аппаратуре. Это вносит постоянную путаницу. Это, пожалуй, наихудшая из всех ситуаций, с которыми может столкнуться группа, разрабатывающая программное обеспечение.
27. Квалификация пользователя Пользователь есть настоящий заказчик и важнейшее звено группы разработки. Пользователь, ранее работавший с системой типа V, уже прошедший через весь этот процесс, является наилучшим из всех возможных партнеров разработчиков. Неопытный пользователь может полностью парализовать деятельность прекрасной группы разработчиков, поскольку новоиспеченные пользователи прокладывают себе дорогу к цели урывками.

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

Основной вклад в стоимость разработки программного обеспечения вносят:

1. Масштаб. Количество реализуемых функций.

2. Ясность. Степень, до которой понятны все реализуемые функции.

3. Логическая сложность. Число условных переходов в расчете на сто команд.

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

5. Взаимодействия с человеком. Насколько часты и интенсивны взаимодействия с системой.

6. Требования реального времени. Сколь быстро должна быть выполнена нужная функция.

7. Стабильность инструментального программного обеспечения. Достигло ли оно нужного уровня стабильности и зрелости?

8. Стабильность вычислительной машины, на которой будет выполняться система. Достигла ли нужного уровня стабильности вычислительная машина, на которой будет выполняться система.

Это самые главные из 27 факторов, которые мы перечислили выше.

Теперь на примере этих 8 факторов продемонстрируем, как стоимость программ может возрасти с одного доллара за строку до тридцати двух с половиной. Если рассмотреть все 27 факторов и использовать наихудший вариант по всем из них, мы можем получить увеличение стоимости до двухсот долларов за строку.

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

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

Программа, которой нельзя сбиваться, обойдется мне дороже, чем программа, которая выполняет ту же функцию, но при этом допустимы сбои. На сколько же это обходится дороже? Я оцениваю этот фактор — надежность, — коэффициентом 15. Следовательно, если создание «ненадежной» программы стоит один доллар за строку, то надежная программа будет обходиться по 15 долларов за строку.

Каждому из восьми основных факторов я могу приписать такие коэффициенты:

Масштабность (размер) от 1 до 8
Ясность от 1 до 10
Логическая сложность от 1 до 10
Последствия сбоев от 1 до 15
Взаимодействие с человеком от 1 до 5
Требования реального времени от 1 до 5
Стабильность вспомогательного программного обеспечения от 1 до 10
Стабильность вычислительной машины в фазе использования от 1 до 20

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


Рис. 6.19. Из чего складывалась общая оценка.

Однако в реальной ситуации редко может случиться так, что для каждого фактора будут наиболее неблагоприятные условия. Нужно попробовать оценить относительную трудность каждого из них для конкретной задачи по разработке. На рис. 6.19 приведены мои оценки для пакета программ размером в 10 000 строк для управления ракетой. Эти программы не должны сбиваться, должны обрабатывать данные, поступающие от радиолокатора каждые 4 с, никак не взаимодействовать с пользователем и работать совместно со стабильным вспомогательным программным обеспечением на «вполне стабильной» вычислительной машине. Логическая сложность минимальна, а ясность просто на отличном уровне.

Моя оценка стоимости — 32,5 доллара за строку — была получена суммированием стоимостей, показанных на диаграмме. Я начал с 1 долл. за строку, мне нужно было лишь определить множители.

По моему мнению, коэффициенты надо расставить так:

— множитель для логической сложности отсутствует

— множитель для ясности отсутствует

— множитель для взаимодействия с пользователем отсутствует

— множитель для стабильности вспомогательного программного обеспечения отсутствует

— множитель 5 для размера

— множитель 2,5 для реального времени

— множитель 15 для надежности

— множитель 10 для нестабильности вычислительной машины, применяемой в фазе использования

Все это вместе дает общую оценку в 32,5 доллара за строку. Еще раз повторю, что отдельные факторы должны умножаться на соответствующие коэффициенты, а общая стоимость определяется не перемножением, а суммированием по всем факторам.

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

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

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

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

Оглавление книги

Оглавление статьи/книги

Генерация: 1.264. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз