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

Доведение программы до товарного уровня

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

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

— Пересмотреть существующую документацию, если она действительно существует.

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

— Создать документацию на продукцию.

Создать рекламную литературу, кратко описывающею нашу продукцию.

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

— Пример граничных условий

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

— Сделать рабочую программу ясной. Исследовать программу: убедиться, что в ней нет «никуда не ведущих условных переходов», «тупиков», мертвых концов и т. д.; добавить команды «защиты», необходимые на случай нарушения граничных условий на параметры.

— Модуляризация/расслоение.

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

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

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

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

— Выделить финансовые средства и определить состав группы сопровождения и необходимого для нее оборудования и т. д.

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

— Организовать систему «оповещения об ошибках».

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

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

При разработке программного обеспечения проектов подобные работы обычно не проводятся; для программного обеспечения как продукции они совершенно необходимы. «Гаражные программы» не могут стать товарными программами!

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