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

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 16 (всего у книги 21 страниц)

Еще одним исследователем, распознавшим важность производственник процессов, оказалась Вудворд. В одном из относительно редких исследований, в которых собирались данные по большому числу организаций, она проанализировала 100 промышленных предприятий Южного Эссекса в Англии… Внутри часто выделяемых категорий «штучного», «серийного» и «массового» производств Вудворд провела дальнейшее деление на 11 типов производственных подсистем. «Цельной продукцией она называет такую продукцию, которая производится как отдельная единица – поодиночке, сериями или массовым производством». «Объемная продукция измеряется с помощью веса или объема, к ней относятся химикаты, жидкости и газы».

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

Рис. 6.8. Производственные системы. (Joan Woodward, Industrial Organization Theory and Practice (London. Oxford University Press, 1965.) Печатается с разрешения.)

С продвижением по шкале от систем типа I к системам типа XI резко возрастает возможность развивать контроль над производственными операциями, физические ограничения на продукцию становятся более изученными и понятными… Однако наиболее хорошо разработанные процедуры контроля за продукцией можно найти в фирмах, выпускающих серийную продукцию, где имеется некоторая степень сомнения в предсказанных результатах. Производству предшествуют энергичные и продолжительные попытки обойти физические ограничения путем постановки более сложных целей. Трудности изучения эффективности контроля становятся наибольшими в штучном производстве, особенно на стадии производства прототипа. Предсказать результаты работ по разработке ни в терминах временных затрат, ни в терминах денежных вложений не удается никогда[36]36
  Woodward Joan, Industrial Organization Theory and Practice (London. Oxford University Press, 1965).


[Закрыть].

Я хочу пояснить, что же это все означает для меня. Вудворд говорит, что наиболее сложным из всех производственных процессов с точки зрения управления является процесс штучного производства. Программа – это «штучная продукция», она характеризует процесс производства как трудноконтролируемый, а затем добавляет, что «предсказать результаты работ по разработке ни в терминах временных затрат, ни в терминах денежных вложений не удается никогда». Насколько же возрастает верность всего сказанного по отношению к разработке программ, которые производятся поштучно и которые по сути являются чем-то неосязаемым. Разработка, по определению, не может быть связана предварительными расчетами денежных затрат, графиков и результатов. Если вам кажется, что вам удалось все предусмотреть, значит вы занимались не разработкой, а каким-то другим делом, которое следует называть как-нибудь иначе в зависимости от того, что в действительности делалось.

«Эффект заброшенных функций» при разработке больших программ

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

Здесь мы сталкиваемся с явлением под названием «заброшенные функции». Необходимо выработать некоторый приблизительно определенный набор функций. По мере приближения срока сдачи работ руководитель разработки начинает понимать, что реализовать все обещанные функции в срок нельзя. Как воздушный шар, теряющий высоту, группа разработчиков избавляется от балласта «необязательных» функций. График «выдерживается», работа завершается «успешно», несмотря на то что в потайной комнате несколько расторопных людей поспешно подключаются к работе, которую должна была бы выполнять вычислительная машина. Теперь все заботы по подключению к системе этих заброшенных функций ложатся на плечи членов группы продолжающейся разработки. Поскольку фаза разработки, построенная по методу «большого взрыва» заканчивается, все оставшиеся недоработки маскируются под названием «сопровождение». Число занятых в этой работе людей обычно значительно уменьшается; группа «сопровождения» по сути является группой разработки (см. рис. 6.9)

Рис. 6.9. Заброшенные функции. [Такую табличку надо было бы повесить на все обещанные функции.]

Рис. 6.10. Число функций по отношению к моменту сдачи системы.

Рис. 6.11. Миф об уменьшении занятости.

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

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

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

«Привычка, – говорит Марк Твен, – состоит в том, чтобы выделить для каждой вещи свое место, а затем рассовать все по-другому».

«Мы восходим на небеса по руинам наших самых сокровенных надежд, обнаруживая в конце концов, что наши неудачи были на самом деле нашими победами». Эмос Элкотт.

Рис. 6.11 представляет собой иллюстрацию к мифу о количестве занятых в разработке крупной сложной программной системы людей. Эта диаграмма оказывается правильной только для небольших простейших программ. И все же ее продолжают выдавать за график распределения усилий при разработке программного обеспечения!

Планирование развития

Как же проектировать систему, учитывая ее возможное развитие, заранее зная, что требования к ней могут измениться? Надо руководствоваться по крайней мере девятью следующими принципами:

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

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

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

4. Нам следует использовать табличные методы управления логикой работы программы. Изменяя строку таблицы, вы меняете алгоритм. Мы использовали этот метод в системе диспетчерского контроля авиалиний. Структура авиалиний определялась таблицами, что избавляло нас от необходимости изменять алгоритмы программ, работавших в разных центрах (всего был 21 центр). Таким образом, у нас была одна программа и 21 таблица для 21 центра.

5. Необходимо устанавливать стандарты программирования и настаивать на их выполнении. Стандарты не пользуются популярностью, но необходимы.

6. Следует организовать строгий и детальный контроль. Мы затронем этот вопрос в разделе, посвященном руководству проектом.

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

8. Для обеспечения сопровождения программ нужно заранее планировать сохранение средств тестирования и разработки.

9. Все это необходимо предусмотреть при составлении бюджета.

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

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

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

Но, что еще хуже, на начальном этапе проектирования игнорировалась необходимость делать программы «понимаемыми»! Это приводит к тому, что лишь небольшое число людей, часто работающих на самом нижнем уровне, понимают, что делается в конкретных программах, – и вот им то и приходится принимать ответственные решения.

Занятость

Число программистов не просто сохраняется на низком уровне, оно уменьшается, это вызвано тем, что при малейшей вашей невнимательности ваших программистов переманивают другие. Нехватка программистов одновременно и тяжела и страшна. Нехватка разработчиков программного обеспечения еще страшнее, причем положение с ними постоянно ухудшается. Типичный ход работ над проектом напоминает приведенную на рис. 6.12 диаграмму. Сплошная линия обозначает планируемое число занятых в проекте. Точечная линия обозначает фактическую занятость. Дефицит на стадии А восполняется дополнительными затратами на стадии В.

Рис. 6.12. Подключение людей.

Рис. 6.13. Распределение людских ресурсов при разработке программного обеспечения.

Разработчики постоянно утверждают, что дефицит, возникающий на стадии А, будет преодолен «уже в следующем месяце», но сделать этого не удается почти никогда.

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

Эволюционный подход к разработке больших систем

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

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

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

Вероятно, именно в этом заключается наиболее значительное отличие систем запуска человека в космос (NASA) и диспетчерского контроля авиалиний (FAA) от огромного множества других больших систем. И NASA, и FAA планировали и финансировали сохранность группы разработки на период до 10 лет! Обе организации понимали, что их системы будут развиваться в течение столь длительного времени.

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

Эта идея о необходимости «версий» была подана мне в 1970 г., когда в комитете Конгресса готовились к публичному слушанию дела о разработке системы диспетчерского контроля за авиаперевозками. Один из экспертов конгресса, изучавший вместе со мной материалы, пришел к выводу, что FAA и IBM будут подвержены критике, поскольку «тот факт, что выпущено семь версий программы, доказывает, что группа не знала, что нужно делать». Я сказал ему, что подготовлюсь к ответу на это обвинение за несколько дней.

Случилось так, что буквально на следующий день после этого я встретился со своей хьюстонской группой и узнал, что у них была «версия 14.7» – т. е. всего, если отвлечься от непонятных обозначений с десятичными дробями, было по крайней мере четырнадцать версий, – и все-таки человек высадился на Луну!

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

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

Что мы имеем – или должны иметь – (с точки зрения программного обеспечения) в первой версии программной системы, состоящей из двух весьма различающихся множеств программ, которые будут выполняться одновременно:

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

2. «Начальное множество» прикладных программ, с которыми пользователь может начать работу со своей системой и а) извлекать из нее пользу и б) находить новые и более хорошие способы работы, которые можно будет добавлять в последующие версии или варианты программ. Такой процесс подключения новых функций продолжается в течение всего периода жизни системы.

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

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

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

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

Задачи руководства программным обеспечением проекта

Руководство разработкой программного обеспечения весьма непростое дело. Нужно решать и управлять решением огромного количества мелких, но и важных задач. Ниже следует список, представляющий собой оглавление «Военного стандарта ВМФ США 1679» – разработку программного обеспечения систем вооружения. Все основные пункты мы уже рассмотрели, но и более мелкие могут играть важную роль и сейчас, и в дальнейшем. Этот список прекрасно иллюстрирует трудности задачи разработки:

Общие требования

Руководство разработкой программного обеспечения

Требования к проектированию

Формирование программ

Гарантия качества

Руководство конфигурацией

Управление подрядными работами

Отклонения и отказы от требований

Подробные требования

Требования к производительности программ

Вспомогательная информация для требований о производительности программ

Анализ производительности программ для вычислительных машин

Области применения

Функции

Документация, необходимая для требований по производительности программ

Описание системы вооружения

Функциональное описание

Подробные функциональные требования

Регулируемые параметры

Системные ресурсы

Требования к проектированию программ

Вспомогательная информация для требований к проектированию программ

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

Документация, необходимая для требований к проектированию программ

Распределение функций

Функциональная схема программы

Распределение ресурсов и резервы

Проектные ограничения

Проектирование базы данных

Межсистемные взаимодействия

Стандарты программирования

Управляющие структуры

Вставляемые/копируемые сегменты

Структура входов-выходов

Отслеживание связей в программах

Самомодифицируемость

Рекурсивные программы

Размер

Ветвления

Перемещаемость

Формат текста программ

Соглашения, принятые при программировании

Символическая параметризация

Система именования

Численные соглашения

Символические константы и переменные

Выражения из разнотипных операндов

Группирование

Значащие цифры

Структурированные словесные описания

Резюме

Комментарии и примечания в программах

Формат входных записей

Эффективность выполнения

Включения/копирования сегментов на исходном языке

Операторы входного языка

Блок-схемы

Производство программ

Организация производства программ

Руководство ресурсами

Язык

Использование библиотек и управление ими

Последовательная нумерация

Распечатки

Распечатки программ

Распечатки перекрестных ссылок

Карты загрузки

Регенерация программ

Выполнение программ

Анализ выполнения программ

Нефункциональное выполнение

Функциональное выполнение

Тесты программ

Тесты модулей

Тесты подпрограмм

Тесты производительности программ

Комплексный тест систем(ы)

Отчетность об ошибках в программном обеспечении

Категория отчетов об ошибках в программном обеспечении

Приоритет отчетов об ошибках в программном обеспечении

Рассылка отчетов об ошибках в программном обеспечении

Гарантия качества

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

Уровни отчетности

Участие в обсуждениях

Пересмотр планов

Проектирование программ

Кодирование программ

Тесты

Представляемые элементы

Отчетность

Авторство

Приемлемость программ

Дополнительные требования к приемлемости программ

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

Окружение тестирования

Тестируемое программное обеспечение

Документация тестов качества программного обеспечения

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

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

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

Тестирование качества тестирования качества программного обеспечения

Возможность сокращенного тестирования качества программного обеспечения

Тесты качества программного обеспечения и вспомогательные программы сопровождения

Ошибки во время тестирования

Ограничения на тесты качества программного обеспечения

Ограничения из-за ошибок

Временные ограничения

Руководство конфигурацией

Идентификация конфигурации

Основные варианты

Определение документации

Управление конфигурацией

Изменения в программном обеспечении

Изменения в документации

Панели управления конфигурацией программного обеспечения

Вычисление статуса конфигурации

Руководящий контроль

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

Требования к ресурсам

Обзоры положения дел

Предметы обзоров положения дел

Пункты, по которым проводятся обзоры положения дел

Обзоры документации

Специальные обзоры

Инспекции и прослушивания

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

Результаты процесса разработки

Что же мы получаем в результате процесса разработки программного обеспечения? Основные результаты таковы:

1. Конечно же, программы, которые будут выполняться, ну а что же еще?

2. Руководства для пользователей. Инструкции и описания, которые сделают систему понятной для пользователя и помогут работать с ней.

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

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

План разработки или проекта

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

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

Рис. 6.14. Результаты процесса разработки программного обеспечения.

1) спецификации требований;

2) рабочую схему организационной структуры с указанием сроков реализации;

3) схему расстановки кадров;

4) бюджет;

5) документирование рабочих стандартов. Руководитель разработки поочередно обращается то к плану, то к результатам его воплощения, модифицирует план и опять начинает этот цикл сначала. Рис. 6.15 выглядит просто, но следовать предложенной на нем схеме очень трудно. Самое важное место на схеме отводится пересмотру графика, бюджета или функций (см. маленький прямоугольник слева). Когда дела идут скверно, чем-то приходится поступиться – и этим должно быть что-то из этой тройки. Руководство обычно медленно соглашается с изменениями плана

Рис 6.15. Цикл планирования и управления.

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

Производительность труда и оценки

Производительность труда – это скорость производства окончательных программ, вполне готовых к работе. Определяется она как отношение объема работ, выполненных при разработке, к продолжительности этих работ. Производительность труда обычно измеряется в строках программы, отнесенных к человеко-месяцу (или человеко-году). Ниже мы рассмотрим некоторые проблемы, связанные с введением такого способа измерения.

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

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

Нам не известно, как надо измерять производительность труда при программировании или разработке программного обеспечения. Мы только начинаем разрабатывать терминологию и средства измерения. Многого мы еще не понимаем. Для описания трудности работы мы используем такие термины, как «тяжелая» или «очень тяжелая», «большая» или «огромная». От таких терминов особой помощи ждать не приходится.

Более полезным оказывается способ измерения, связанный с подсчетом числа команд или строк текста программы (СТП). Используя это понятие, мы, например, говорим, что данная работа или функция – скажем, составление платежной ведомости – требует 50 тыс. строк программы.

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

	2 мес	1 мес
	2000	900
	100 °CТП/чел. – мес	90 °CТП/чел. – Мес

Наше измерение в строках текста за единицу времени приводит к поощрению неэффективного проектирования или небрежного программирования. Программист А работает по плохому проекту и имеет «рыхлую» программу и поэтому за единицу времени смог написать больше строк текста программы.

База данных по производительности труда

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

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

Когда я захотел представить группу, добившуюся колоссальной производительности труда при работе над проектом для газеты «Нью-Йорк таймс», к премии за выдающиеся достижения, я обнаружил, что во всей фирме IBM не имелось данных о производительности труда.

Мы решили, что начнем измерять строки программ. У нас уже были, в наших отчетах по контракту, записи о часах работы каждого члена группы, времени, использованном на каждую работу, о категориях всех наших сотрудников (руководитель, аналитик, программист и т. д.) и об их заработной плате. У нас были сведения обо всем – так мы думали. И почти сразу же мы обнаружили, что никто из нас не имел точного определения «строки программы»! А также и «человеко-месяца»!

Определения терминов «строка программы» и «человеко-месяц»

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

Два значения термина «строка программы»

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

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

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

Итак, термин «строка программы» имеет два значения, причем полезными оказываются оба значения:

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

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

Даже получив эти определения, нельзя выйти из тупика.

Определение строки текста исходной программы. Строка текста программы – это любая входная запись длиной до 80 символов (выполняемая и невыполняемая), написанная программистом или используемая в нашей системе программного обеспечения во время его работы. Имеется по крайней мере два типа таких операторов. К одному типу относятся операторы, не предназначенные для переноса в рабочую программу, к которым относятся операторы, написанные, отлаженные, использованные и исключенные (возможные примеры исключаемых операторов: некоторые программы имитации, некоторые моделирующие программы, некоторые тестовые программы), не выполняемые во время использования программы. К этому же типу относятся примечания и описания данных. К другому типу относятся операторы, из которых формируется рабочая программа и которые используются в момент работы программы.

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

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

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

Категории программного обеспечения

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

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

Рис. 6.16. Программное обеспечение используемое/создаваемое на различных стадиях фазы разработки/использования.

2) инструментальное обеспечение – программное обеспечение разработки; программное обеспечение тестирования.

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

1) программного обеспечения фазы использования или операционного программного обеспечения;

2) сопровождения разработки операционного программного обеспечения, включая и «выброшенные программы», например управляющие программы;

3) сопровождения разработки аппаратуры, включаемой в систему;

4) проведения тестирования системы;

5) сопровождения проектирования, например моделирующие программы;

6) руководящего контроля, например PERT, подсчета стоимости.