Программное обеспечение и его разработка
Шрифт:
Таблица 4.13 Характеристики программного обеспечения проектов и программного обеспечения как продукции
| Проекты — - - — - - — - - —> | <- - — - -Продукция | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Расчет налоговых отчислений | Хьюстон | Инструментальные программы мин. обороны | Контроль авиаперевозок FAA | Бортовые навигационные системы на кораблях | «Wizard of Avis» | Сопровождение ракет | Телевизоры | Компилятор с Кобола для IBM 370 | Обработка текстов | |
| Число пользователей | 1 | 1 | 1 | десятки | сотни | сотни | тысячи | тысячи | тысячи | тысячи |
| Число
| 1 | 1 | 1 | 1 | неск. | 1 | 1 | 1 | 1 | 1 |
| Посредники между пользователем и разработчиком | Нет | Нет | Да | Да | Да | Да | Да | Да | Да | Да |
| Параллельная разработка | Нет | Да | Да | Да | Да | Нет | Да | Да | Нет | Да, затем Heт |
| Требования пользователя или рынка | Пользователь | Пользователь | Пользователь | Пользователь | Пользователь | Пользователь | Пользователь | Рынок | Рынок | Рынок |
| Конкуренция после построения программного обеспечения | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да | Да |
| Финансовый риск | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да | Да |
| Сопровождение программного обеспечения | В | В | В | В | В | Н | Н Апп. — инт Аппар. прод. с прогр. обесп. | В Прогр. — инт. Товарное прогр. обесп. | В Прогр. — Инт. |
Требования к проектам и продукции. Выработать требования к системе «Аполлон» гораздо легче, чем к системе управления процессом обработки слов. Дело заключается в том, что ошибки при определении требований исправлять в первом случае значительно легче. Руководство программой Аполлон имело тесный контакт со всеми, кто будет пользоваться программным обеспечением, и вполне способно управлять ими.
Такая тесная связь позволяла легче справляться с некоторыми не очень грубыми ошибками. Если бы о каждой незначительной ошибке или изменении приходилось сообщать сотне или более пользователям, очевидно, что работа по их извещению отняла бы много сил.
Для выработки хорошо составленных требований к разрабатываемому программному обеспечению, предназначенному для продажи многим пользователям, необходимо проводить исчерпывающее исследование их нужд и пожеланий, а затем еще выяснять конъюнктуру рынка. Нам нужно не просто удовлетворить требованиям большого числа пользователей, нам нужно выиграть соревнование с другими системами.
В случае проектов конкурентная борьба разворачивается только в момент выбора группы разработчиков. Определение требований к товарному программному обеспечению — это сложный процесс, которым длительное время вынуждены заниматься большие коллективы людей.
Размах работ при разработке проектов и товарных программ.
В большинстве проектов для построения высоконадежных или высокоскоростных систем приходится разрабатывать уникальные программы. Для многих проектов необходимо создавать специальные средства для их разработки. С другой стороны, условия создания товарных программ носят более ограниченный характер. Продукция обычно более четко очерчена, все интерфейсы, используемые для связи с другими частями программного обеспечения, детально проработаны. Если, например, мне нужно разрабатывать транслятор с Кобола или программу печати платежных ведомостей, то совершенно необязательно начинать с разработки новой операционной системы. Писать команды, образующие интерфейс с операционной системой, безусловно, необходимо, но разрабатывать саму систему нет нужды. Напротив, шансы на разработку операционной системы резко увеличиваются, если поступает задание разработать программу для штурманского дела. (См. рис. 4.23.)
Существует много процессов, позволяющих некоторую часть программного обеспечения, работающую всего в одном месте, превратить в «стандартное» программное обеспечение, годное к продаже в сотни организаций. Такой процесс иногда называется доведением программы до товарного уровня. Создание продукции на основе обычной программы походит на процесс инженерного сопровождения, имеющий место при разработке аппаратуры.
Часто рассказываемая с иронией апокрифическая история о группе из трех гениев, за один вечер работы где-то в гараже написавших программу, за разработку которой некая компания обещала потом около 300 тыс. долларов, однако весьма поверхностна. Конечный результат этих двух процессов просто невозможно сравнивать. Чтобы по-настоящему понять эту разницу, давайте предположим, что некто обращается к нам — большой компании — с работающей программой и предлагает продавать эту программу тысячам пользователей и поддерживать ее. Предположим, мы действительно верим, что на этом можно что-то заработать. Составим список того, что нам необходимо будет проделать с этой программой. Список этот, далеко не исчерпывающий, приведен ниже.
— Пересмотреть существующую документацию, если она действительно существует.
Нам необходимо пересмотреть не только конечную документацию, относящуюся к рабочей программе, но и начальную — что делает эта программа, что она не делает, ограничения, инструкции пользователям.
— Создать документацию на продукцию.
Создать рекламную литературу, кратко описывающею нашу продукцию.
— Тщательно протестировать имеющуюся программу. Проверить граничные условия. Тот факт, что программа работает в одном месте, не означает, что она годится для работы во многих местах. Может, например, так оказаться, что все данные, которые я передаю программе, находятся в некотором ограниченном диапазоне. При использовании на многих вычислительных машинах входные данные могут существенно различаться. Мы должны протестировать систему при всех граничных условиях, если они уже определены. Если же нет, мы должны провести тестирование с целью их определения.
— Пример граничных условий
| Входное значение | Предел | |
|---|---|---|
| Платежная ведомость | Недельный заработок | 9999.99 — нуль, отрицательных нет |
| Радиолокатор | Дальность | от 1000 футов до 99 432 футов |
— Сделать пользовательскую документацию ясной. Очень маловероятно, что программа, используемая всего в одном месте, имеет достаточную документацию. Все инструкции носят неформальный характер, часто передаются от разработчика пользователю устно. Однако для передачи программы тысяче пользователей мне нужно составить четкую, ясную инструкцию, написанную понятным языком, иначе моя продукция будет отвергнута.
— Сделать рабочую программу ясной. Исследовать программу: убедиться, что в ней нет «никуда не ведущих условных переходов», «тупиков», мертвых концов и т. д.; добавить команды «защиты», необходимые на случай нарушения граничных условий на параметры.
— Модуляризация/расслоение.
Для обеспечения эффективной и достаточно дешевой модификации и модернизации особенно необходимо просмотреть всю программу на предмет выделения в ней отдельных модулей и не зависящих друг от друга частей.