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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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