Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Информатика и ВТ Брукшир.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
5.07 Mб
Скачать

6.2.2Разработка программного обеспечения на практике

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

6.2.3Этапы разработки программного обеспечения

Разработка программного обеспечения включает в себя анализ, проектирование, реализацию и тестирование (рис. 6.2).

6.2.4Анализ

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

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

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

6.2.5Проектирование

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

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

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