Помоги проекту - поделись книгой:
— Сделать рабочую программу ясной. Исследовать программу: убедиться, что в ней нет «никуда не ведущих условных переходов», «тупиков», мертвых концов и т. д.; добавить команды «защиты», необходимые на случай нарушения граничных условий на параметры.
— Модуляризация/расслоение.
Для обеспечения эффективной и достаточно дешевой модификации и модернизации особенно необходимо просмотреть всю программу на предмет выделения в ней отдельных модулей и не зависящих друг от друга частей.
—
— Протестировать программу со всем системным обеспечением, с которым ей придется работать.
Может случиться так, что товарное программное обеспечение будет работать в различном системном окружении. Перед выпуском продукция должна быть обязательно протестирована.
— Выделить финансовые средства и определить состав группы сопровождения и необходимого для нее оборудования и т. д.
Планирование сопровождения не проводится практически никогда. Основной аргумент: «Мы еще успеем этим заняться». Ну а пока раскачиваются, возникают невосполнимые убытки. В бюджете должны быть предусмотрены расходы на то, чтобы иметь возможность заменить или исправить программу, если в процессе эксплуатации выясняется, что это нужно сделать.
— Организовать систему «оповещения об ошибках».
Это просто сказать, но не просто выполнить. Для организации этих работ нужно выделить людей и определить процедуры. Хорошо спланированная и хорошо выполняемая работа может значительно повлиять на мнения пользователей о покупаемом ими программном обеспечении.
—
При разработке программного обеспечения проектов подобные работы обычно не проводятся; для программного обеспечения как продукции они совершенно необходимы. «Гаражные программы» не могут стать товарными программами!
Часть программного обеспечения может продаваться на рынке исключительно благодаря тому, что оно программное (т. е. может выполняться на вычислительной машине). Другие же программы неотъемлемы от аппаратуры, в комплексе с которой они продаются. На разработку этих различных видов программного обеспечения затрачиваются разные усилия. Примером системы первого типа является программа печати платежной ведомости. Второй тип программного обеспечения можно себе представить на примере программы обработки слов; эта программа в значительно большей степени, чем аппаратура, влияет на качество всей системы в целом, хотя и неотделима от нее.
Пользователь может не думать о том, на какой машине печатаются платежные ведомости, — т. е. выполняется соответствующая программа, конечно, до тех пор, пока этот процесс выполняется с достаточной степенью надежности. Если вычислительная машина находится на удаленном вычислительном центре, пользователь может даже и не знать, на какой машине и какой модели печатаются его ведомости.
В системах обработки слов аппаратура становится более существенным фактором, поскольку пользователь контактирует именно с ней. Важное значение приобретают характеристики аппаратуры, ее месторасположение, простота использования. Эти факторы отличают одну продукцию от другой. Однако большинство продающихся систем оборудовано практически одинаковой аппаратурой, и различать продукцию можно только по заложенному в них программному обеспечению, а не по этой аппаратуре.
Разработчик продукции, в которой программное обеспечение является ключевым фактором, на каждом шаге своего процесса разработки сталкивается с гораздо большей степенью интеграции аппаратуры и программ, чем руководитель разработки просто программ как продукции.
В результате появления микроэлектронных схем мы столкнулись с еще одним видом программного обеспечения, Во многих системах применение цифровых универсальных вычислительных машин оказывается более экономичным, чем использование специализированных схем. В память этих машин приходится записывать команды, а эти команды составляют целые программы.
Включение этого типа программ в нашу таксономию может оказаться весьма полезным. К тому же вопрос о том, как относиться к подобным устройствам и их программному обеспечению, терзает представителей деловых кругов.
Примером такой вычислительной машины, используемой вместо электронной схемы, может служить обычный телевизор, в котором для обработки входного сигнала применяется микропроцессор. В такую машину заносится не так уж много команд, не более двухсот, но затем программа размножается не менее чем для 500 тысяч микросхем, каждая из которых помещается в телевизор. Такое использование программ, программного обеспечения можно называть
Важнейшим пунктом при этом является правильность программы. Она должна быть правильной, иначе нам придется изъять у пользователей все 500 тысяч телевизоров и исправлять программу. Экономический эффект такой операции будет просто ошеломляющим. С некоторыми потребительскими товарами уже случались такие катастрофы. Что же будет, если наша микросхема будет позволять хранить все больше команд, оставаясь на прежнем уровне стоимости? Конечно же, инженеры попытаются вставить в микропроцессор более крупные программы. И если мы еще можем быть полностью уверены в правильности программы из двухсот команд, то 100 %-ная уверенность в правильности программ из 1000 или 10 000 команд нам недоступна.
Люди, определяющие политику, конечно, видят эту опасность и потому стараются разделить все программное обеспечение на два больших класса — аппаратно-интенсивные программы, которые не должны подвергаться никаким изменениям и, следовательно, не имеют права на ошибку, и программно-интенсивное программное обеспечение, исправление и модификацию которого мы всегда должны предусматривать.
Для обеспечения второго класса необходимо вводить различные стандарты — стандарты на языки программирования, стандарты на процесс разработки, стандарты на тестирование, на документацию и другие. Подробнее о стандартизации речь пойдет позднее. В аппаратно-интенсивных приложениях все эти стандарты не имеют экономического обоснования. Проведение разработки и использование в рамках жестких стандартных ограничений только увеличат стоимость разработки, причем довольно значительно — в 5–10 раз.
Поэтому нам вполне понятно желание разделить эти два класса. Если хорошо осведомленный руководитель видит и представляет себе все предстоящие затраты на разработку, управление разработкой пройдет четко. Но каким образом руководители предприятий
Легче всего провести грань между этими столь различными классами программного обеспечения, произвольно установив, что все разработки программ должны вестись с применением методов программно-интенсивных разработок в тех случаях, когда вычислительная машина, на которой будет использоваться данное обеспечение, имеет память размером от 2000 команд и более!
Конечно, это произвольное решение. Существуют примеры достаточно простых программ в 3000 команд, поскольку в них мало условных переходов. Но дело тут в том, что мы пытаемся уберечь ничего не подозревающих создателей аппаратуры от попадания в
Мы не знаем, каким должен быть предел емкости памяти — 2000, или 1000, или 4000. Эти пределы должны определяться руководством конкретных предприятий. Конечно, иногда можно требовать права на исключение. Имеются в виду случаи, когда создатели аппаратуры абсолютно уверены в ясности и стабильности сферы приложения их усилий, а также в своей способности писать безошибочные программы.
Если мы решим, что наша программа не имеет ни одной ошибки и выпустим нашу продукцию в свет, а потом вдруг обнаружим в небольшой программе, всего в 1000 команд, одну-единственную ошибку, мы будем принуждены возвращать себе и вскрывать тысячи микроволновых печей или посылать тысячи техников для замены микросхем в копировальных установках или телевизорах. Стабильность программы крайне важна для всего экономического успеха продукции. Любая ошибка как в определении требований, так и в реализации может оказаться
Человек, ответственный за программное обеспечение, прежде всего, конечно же, захочет выяснить, является ли данное приложение аппаратно-интенсивным. К разработке аппаратно-интенсивного программного обеспечения должны применяться иные, менее строгие стандарты.
Однажды меня попросили перечислить десять ведущих специалистов Соединенных Штатов по программному обеспечению. Я разделил свой список на три части. В первый список попали люди, действительно знающие, как надо строить, и построившие большие системы программ.
Во второй список я поместил имена тех, кто обладает обширными знаниями в области языков программирования и библиотек программ, т. е. в области инструментального обеспечения. Сюда попали многие деятели из различных университетов страны.
Третий список, однако, относился не к специалистам в области прикладных программ, а к тем, кто занимается построением обеспечения проектов. Прикладная область не представляет собой ничего сложного. Те же, кто разрабатывает программное обеспечение проектов, используют продукцию первых двух групп, соединяют их с прикладной областью и создают окончательную работающую систему. Они в прямом смысле интегрируют программное обеспечение, создавая самые большие, самые быстрые, самые сложные системы. Они построили систему управления воздушным транспортом, спутниками Земли, системы резервирования авиабилетов, военные командные и управляющие системы. Они создавали системные программы, объединяли их с прикладными, основывая свой труд на множестве инструментальных программ. Они руководили разработкой 100 млн. систем.
Наиболее важный вывод, следующий из этой классификации, состоит в том, что для каждой из этих областей необходимы различные таланты и мастерство!
Система общенациональной связи, предусматривающая также обслуживание, является огромным программным обеспечением проекта, но кроме того, требует создания также еще и многих товарных программ. Система передачи сообщений может соединять конторы клиентов и передавать данные с некоторого устройства (например, копировальной установки) одной конторы на другое устройство, находящееся в другом месте.
Для обеспечения работоспособности такой системы необходимо создать и заставить работать сеть средств передачи информации (микроволновые передатчики, спутники и т. д.), и средства хранения информации, и коммутационные устройства. Обслуживать систему должна небольшая группа людей, которые будут управлять средствами поддержки отдельных узлов сети и регулировать работу системы при возникновении переполнений.
Большая часть сети должна управляться с помощью вычислительных машин. Программы, которые нужно для этого написать и связать между собой, относятся к классу
Такая продукция:
— должна быть рассчитана на огромное число пользователей; тысячи этих пользователей могут работать в различных областях и отраслях;
— должна быть легкой в использовании, хорошо защищенной от случайных воздействий, хорошо приспособленной к возможным добавкам или исключениям;
— должна быть очень хорошо документирована;
— должна выполнять большое число функций, что поможет ей удовлетворить большое число пользователей;
— должна сопровождаться людьми, которые
— богатый набор ее функций должен быть перед реализацией тщательно выверен и определен;
— соревнование за пользователей начнется для нее после введения в эксплуатацию; конкурентами будут другие сети.
Таблица 4.14. Примеры программ и их соответствие классификации
| Ведомость | Расчеты орбит | Управление информационной системой | Система резервирования мест при авиаперевозках | Транслятор с Кобола | Программы сортировки и квадратного корня | Автоматизация конторского дела | Система ведения конторской документации | Телевизионный приемник | Система управления базой данных | Управление воздушным транспортом | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Время разработки | Н | Н | В | В | В | С | В | С | С | В | ОВ |
| Время использования или выполнения | Н | Н | В | В | Н | Н | В | Н | Н | В | ОВ |
| Время сопровождения | Н | Н | В | В | Н | Н | В | Н | Н | В | ОВ |
| Прикладное | V | V | V | V | * | V | V | V | V | ||
| Вспомогательное | V | ||||||||||
| Системное | * | V | |||||||||
| Масштаб | М | М | С | В | М | М | С | М | М | С | В |
| Сложность | |||||||||||
| Научная | Н | В | Н | Н | Н | С | Н | Н | Н | Н | Н |
| Логическая | Н-С | С | В | ОВ | В | С | В | С | Н | В | В |
| Обеспечение проекта | * | V | V | V | * | V | |||||
| Программная продукция | V | * | V | V | V | ||||||
| Продукция с аппаратно-интенсивным обеспечением | V | V | |||||||||
| Продукция с программно-интенсивным обеспечением | V | V | V |
V — обычно присутствует, * — может быть несколько вариантов, Н — низкий, С — средний, В — высокий, ОВ — очень высокий.
Таким образом, для разработки такой сети по обслуживанию деловых операций необходимо разрабатывать как обеспечение для проектов, так и отдельные программы как продукцию.
В табл. 4.14 приведены примеры различных программ и их распределение по категориям в соответствии с таксономией. В дополнение к этому дается грубая оценка трудности работы с данной программой на каждом из трех этапов жизненного цикла программы.
В гл.2 мы уже отмечали, что стоимость больших программ может достигать 90 % общей стоимости проекта.
Существуют и такие применения программного обеспечения, в которых стоимость программ неизмеримо мала по сравнению со стоимостью аппаратуры. Разработчики таких программ могут совершенно не замечать кризиса программного обеспечения.
Если от нас требуют разработать основную программу, используемую на одной и только одной вычислительной машине, например программу управления информационной системой для компании XYZ мы будем не вправе делить стоимость программы на число пользователей. К тому же число это равно 1, и вся стоимость накладывается на одного пользователя. Если же нам нужно вставить нашу программу в маленькую вычислительную машину внутри телевизора, мы разделим стоимость программ, написанных для этой машины, на общее число телевизоров, которые будут выпущены в эксплуатацию. Если разработка программ обошлась в 200 тыс. долларов, то после деления на 500 тысяч телевизоров получим удельную стоимость всего 40 центов. Все очень просто! О чем же волноваться? Пока программа правильна, никаких проблем и не существует. В табл. 4.15 представлено все многообразие «тиражей» различных вычислительных машин.
При разработке системного и прикладного обеспечения в рамках некоторого проекта, скажем для управляющего центра общенациональной системы связи, стоимость этого обеспечения может легко достичь 30 или даже 60 млн. долларов в расчете на одну станцию связи. Стоимость же программ для одного микропроцессора, встроенного в телевизор, как мы уже подсчитали, может оказаться в диапазоне 40 центов на штуку.
Если мы говорим о программном обеспечении и не употребляем рядом с этим термином никаких добавочных определений, то должны четко понимать, что при этом мы все очень сильно упрощаем. Лишь самые общие замечания, сделанные по поводу аппаратно-интенсивных приложений программного обеспечения, можно отнести также и на счет программно-интенсивных приложений, и наоборот.
| Программное обеспечение | Системное обеспечение |
| Обеспечение как продукция | |
| Обеспечение проектов | |
| Инструментальное обеспечение | |
| Тестирующее обеспечение | |
| Большое обеспечение | |
| Обеспечение для реального времени | |
| Пакетное обеспечение | |
| Прикладное обеспечение | |
| Диалоговое обеспечение | |
| и т. д. |
Мы не должны допускать предложений типа «70 % стоимости программного обеспечения приходится на этап продолжающейся разработки». Во многих случаях это правда; во многих — нет. Это слишком общее высказывание. Мы должны добиваться большей точности, использовать уточняющие определения. Люди, не являющиеся специалистами в области вычислительной техники, не только введены в заблуждение относительно вычислительных машин и их программного обеспечения, но также возмущены жаргоном и небрежностью, царящими в нашей отрасли[11]. Если профессионал не настаивает на точности высказываний, является ли он подлинным профессионалом?
Глава 5
Разработка программного обеспечения
Разделив все программное обеспечение на категории, изучим теперь подробнее процесс его разработки. Именно эта область доставляет в настоящее время наибольшие неприятности.
Свойства, присущие всем программам, дают нам возможность глубже проникнуть в более тонкие и более важные характеристики программ. Имеется по крайней мере 12 таких свойств или характеристик. Взгляните на табл. 5.1.
Таблица 5.1
| Характеристики программ | Обычно носят название |
|---|---|
| 1. Заставляет вычислительную машину выполнить задание | Функция |
| 2. Занимает память машины | Размер |
| 3. Тратит ресурсы ЦП | Эффективность |
| 4. Легкость использования | Практичность |
| 5. Легкость восстановления после сбоя | Устойчивость; восстанавливаемость |
| 6. Содержит ошибки | Правильность |
| 7. Требует времени для создания | График разработки |
| 8. Требует людей для создания | Людские ресурсы на разработку |
| 9. Требует специального инструментария для разработки | Материальные ресурсы на разработку |
| 10. Требует денег для создания | Стоимость |
| 11. Модифицируема | Архитектура, структура |
| 12. Существует по крайней мере в одной форме, а нужны две | Документация |
Стремление воплотить эти характеристики в программу приводит к конфликтам. В программах, написанных очень быстро (характеристика 7), обычно крайне неэкономно используется память и машинное время (характеристики 2 и 3) по сравнению с программами, которые писались медленнее. Быстро написанные программы часто не выполняют на все 100 % функции, которые они, по предположению, должны были выполнять (1). Программа может печатать почти любую ведомость, однако нам все же приходится держать двух сотрудников для выполнения функций, которые должна была бы (и могла бы) выполнять машина, но которые не были вовремя запрограммированы. Такое случается очень часто.
Если программа печати ведомости нужна нам к 1 июня будущего года, мы можем на этот срок включить дополнительно в группу разработки нескольких программистов, чтобы они помогли сократить время работы. Очевидно, что если на создание программы требуется 100 чел. — мес., то мы могли бы выделить на ее создание 10 программистов, которые будут работать в течение 10 мес. Но сделать эту же работу за один месяц, бросив на нее 100 человек, невозможно.
Укороченные графики могут совершенно разрушить попытки построить стройную, легко модифицируемую структуру (11). Малая стоимость разработки (10) находится в явном противоречии со всеми другими аспектами. (См. табл. 5.2.)
Таблица 5.2. Двенадцать характеристик программы
| Фаза разработки | Требует времени для создания | График разработки |
| Требует людей для создания | Группа разработки | |
| Требует специального инструментария для создания | Средства разработки | |
| Требует денег для создания | Стоимость | |
| Фаза использования | Заставляет машину выполнить задание | Функция |
| Занимает память машины | Размер | |
| Использует ресурсы ЦП | Эффективность | |
| Легка для использования | Практичность | |
| Легко восстанавливается до рабочего состояния | Восстанавливаемость | |
| Содержит ошибки | Правильность | |
| Фаза сопровождения | Модифицируема | Архитектура |
| Существует по крайней мере в одной форме, а нужны две | Документация |
После того как все разработчики представят свои оценки еще не испробованных возможных вариантов, руководство должно принять компромиссное решение.
Давайте посмотрим, какие характеристики существуют в фазе использования.
1. Каждая программа выполняет некоторую функцию, например, она может составлять платежную ведомость.
Здесь мы еще не можем давать численных оценок, но после некоторого наблюдения мы можем определить, действительно ли программа выполняет ту функцию, которая нам нужна.
2. Каждая программа при выполнении занимает некоторое место в памяти. Если памяти у машины мало, нам придется затратить время и людские ресурсы на то, чтобы сжать программу до нужных размеров.
3. При выполнении каждая программа использует некоторые ресурсы машины. Например, сколь быстро напечатает машина нужную нам ведомость по данной программе? Если наш центральный процессор работает медленно, разработчикам придется потрудиться над программой, чтобы выжать из процессора все, что только возможно.
4. Легкость использования. Некоторые программы весьма успешно отражают всякие попытки воспользоваться ими. Они не «дружественны пользователю». Легкость использования — это не случайно возникающее побочное следствие разработки, а качество, требующее тщательного проектирования и разработки специальных требований.
5. Чем больше программа, тем больше вероятность, что в ней имеются ошибки и что самое строгое тестирование не обнаружит их полностью. Большинство этих ошибок может обнаружиться только в необычных комбинациях данных и пользователей.
6. Каждая программа должна сохранять работоспособность. Некоторые из них перезапустить легко, другие сложнее. И опять эта характеристика является объектом тщательного проектирования.
Теперь рассмотрим характеристики фазы разработки.
7. Каждая программа требует на разработку некоторого времени. При разработке больших систем этого времени часто не хватает. И часто
8 Каждая программа создается некоторым числом программистов, работающих в течение некоторого времени (чел. — мес.).
9. Для создания любой программы нужны какие-нибудь инструменты. Ими могут быть вычислительные машины, производящие трансляцию с языков высокого уровня и тестирование, перфокарты, магнитные ленты, «пространство», программы для трансляции, тестирования и еще многое другое.
10. Для создания каждой программы необходимы денежные средства.
Теперь обратимся к характеристикам фазы сопровождения.
11. При возникновении новых требований их приходится отражать в программе. Программа, сработанная на скорую руку, труднее поддается модификации, чем программа, проектирование которой велось аккуратно и без спешки. Хорошо ли спроектировано, насколько модульно построено программное обеспечение?
12. Программы так часто хранятся только на магнитных лентах, что упоминание об этом стало уже избитой фразой. Бедняги, которых заставили исправлять в таких программах ошибки и расширять их возможности, должны проводить подлинные археологические раскопки, чтобы понять, что же
Теперь попытаемся представить все эти характеристики программ на диаграмме, иллюстрирующей жизненный цикл программы (см. рис. 5.1).
Заметьте, что четыре аспекта разработки относятся также и к продолжающейся разработке!
Поделиться книгой: