Программные продукты и системы

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

Путь от концепции (спецификации требований) до конечного продукта — информационной системы или системы управления, называемый циклом жизни системы, сложен и извилист (рис. 1). Успех разработки проекта зависит от многих факторов;

—  Удовлетворяет ли разработанная система функциональным требованиям, определенным в начале проектирования?

—  Не вышла ли разработка проекта за рамки исходного бюджета?

—  Реализован ли проект в указанные календарные сроки?

При автоматизированном проектировании ответы на эти вопросы должны отражать:

— возможности и профессиональный уровень специалиста, занятого разработ кой проекта;

- степень участия руководства и потенциальных пользователей в процессе разработки;

—  уровень управления проектом;

—  методы и средства, используемые на конкретных этапах разработки систе мы;

—  качество документации проекта;

—  уровень обучения пользователя;

—  знания конечных пользователей о разработанной для них системе и т. д.

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

Пользователи обычно ждут обнадеживающих результатов (не принимая никакого участия в разработке) в течение 1-2 месяцев, и если эти результаты не соответствуют их запросам, то проект приходится заново переделывать.

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

Нет гарантии, что эти же ошибки не встретятся в следующем проекте. До тех пор, пока нет отструктурированного и четко описанного представления о разра-

Рис. 1. Схема процесса разработки системы

батываемой системе, работа будет оставаться секретом лишь опытных мастеров.

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

SOT — технология проектирования и разработки систем — предоставляет возможность решения данной проблемы.

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

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

• правила планирования процессов и промежуточный

контроль за выполнением проекта;

• подготовка функциональных спецификаций

и спецификаций структур данных;

• документирование алгоритма программы и т. д.

SD-« скелет» представляет собой структурированную базу знаний для планирования проекта. Список процессов определяет,ЧТО должно быть сделано. Подробные описания вместе с дополнительным набором рабочих методов указывают, КАКИМ ОБРАЗОМ выполнить каждый процесс, а стандарты на документацию

— КАК документировать результат (выходные данные) каждого процесса и разработанную конечную систему. Сеть процессов определяет, КОГДА выполнять процесс.

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

Теперь вкратце познакомимся с самим SDT-скелетом».

этапы разработки; подэтапы разработки; шаги проектирования.

Комментарий: — коды, содержащие Р, обозначают виры деятельности управления проекто?

—   средний цикл жизни проекта состоит примерно из 120 шагов проекта;

—   описание В12 представлено в разделе AD (рис. 2).

Для каждого процесса существует стандартизированная карта описания процесса.

Этот этап выполняется старшим системным аналитиком (SSA) совместно с представителем пользователей (UR). Им необходимы входные документы A42YI, B11Y1. результат их работы будет идентифицироваться как BI2Y2 (функциональная структура). Выходной результат следует документировать в соответствии со стандартом на документацию DSP-BI {описанный в компоненте DSP). Описательная часть карты может находиться на следующей странице.

Промежуточное кодирование документа: A42Y2 означает второй выходной результат (Y) шага 2 подэтапа 4 этапа А.

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

Этот набор состоит из проверенных технических и административных методов и средств управления проектом. Например: технические

WMT0I: Диаграммы потока информации (метод ISAC) МТ02: Блок-схемы системы и программы МТ10: Структурированные методы анализа и проектирования МТ11: Метод HIPO и т. д.

административные

МР01: Задание на присваивание и оценка МР02: Столбиковые диаграммы

МРОЗ: Сети, основанные на временных интервалах

МР04; Планирование человеческих ресурсов для осуществления проекта.

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

В SDT документация выполняет две основные функции:

—  обеспечение точной связи между группами во время разработки системы;

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

Стандарты в ходе выполнения проекта (DSP) структурируются в соответствии с операциями (AL, AD), а стандарты на конечную документацию системы (DSF) составляются в соответствии со структурой системы.

На рис. 4,а представлен стандарт для выходной спецификации BI2YI. Это общепринятый стандарт на неавтоматизированный режим проектирования. Если выбран автоматизированный метод проектирования, этот стандарт следует преобразовать в соответствии с правилами языка спецификаций, представленных на рис. 4,6. В этом случае нет необходимости составлять иерархические диаграммы: компьютер составит их и вставит в промежуточную и (или) конечную документацию.

Рис. Ь. Проектирование обычной системы

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

SAD (ПО для ускоренного проектирования).

SAD позволяет осуществлять доступ и (или) корректировку выходных результатов промежуточных операций посредством подключенных дисплейных термина лов к общей базе данных проекта. На рис. 6 представлена часть операции BI2YL

Стандарты SDT хранятся на дисках, поэтому SAD автоматически может проверять правильность спецификаций, вводимых перед их запоминанием в базе данных проекта. Стандарты (обозначены как BS 2) можно выбрать и ввести интерактивно как набор правил выражений на этапе инициализации проекта. С помощью этих правил можно сформулировать язык спецификаций, соответствующих конкретному этапу проектирования.

Для начальных этапов проектирования (А, В) можно выбрать конструкции, соответствующие естественному языку, а для конечных этапов — конструкции, соответствующие машин но-ориентированном у языку. Пример спецификации программы реального времени (этап D) приведен на рис. 7. Проектирование любого языка спецификаций с помощью языковых средств SAD выполняется достаточно просто: определяем типы предложений (т. е. заголовок программы и т. д.), несколько ключевых слов (PROG, BUFFER и т. д.), и типы атрибутов (текст, данные, событие, количество и т. д.), указываем, наконец, возможные связи этих предложений (например предложение RECEIVE может быть только частью PROGRAM ALGORITHM или предложения типа DO).

Таким образом можно создать свой собственный язык проектирования, ориентированный именно на данный проект.

В любом случае стандартный DSP-комплект SDT-яскелета» содержит образец языка для каждого этапа создания проекта. Дополнительно к стандартному комплекту имеются также наборы языков, созданные в результате предшествующего использования SDT. Его пользователи могут довольно просто скомпилировать свой собственный язык или взять один из уже существующих.

Преимущества метода автоматизированного проектирования:

—   Управленческий персонал с помощью команд S (Show), T (Trace), G (Grapl может получить промежуточную документацию на текущий момент отноа тельно любого объекта и на любом уровне детализации; используя программы з; просов SAD, можно сразу получить конечную или промежуточную документ; цию системы из базы данных проекта, указав при этом формат и перечень треб; емой документации для пользователей различных уровней.

—   Системные разработчики могут:

результат работы специфицировать в режиме А (автоматическое управление когда компьютер шаг за шагом запрашивает подробности выполнения каждо операции;

добавить или расширить хранимую в памяти спецификацию с помощью коман R (Refer), F (Format) или 1 (Insert);

изменить, реорганизовать или удалить что-либо из выходных данных, исполь зуя команды U (Update), С (Change), M (Move) или D (Delete);

получить подробную информацию о результатах работы коллег с помощью кс манд S, T, G;

используя команду Н (Help), получать всю необходимую информацию о правд лах ведения диалога.

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

Новое средство SDT/SAD позволяет сократить затраты на

проект и время разработки почти на 40% и значительно

повысить качество документации.

Рекомендуется использовать SDT на компьютерах с широкой сетью термина лов. В настоящее время SAD успешно функционирует на крупных ЭВМ тиш IBM, PDP-11 и некоторых персональных машинах. Для простоты совместимости система разработана на языке ФОРТРАН-IV (версия для персональных машин на языке БЕЙСИК). Объем оперативной памяти 56 Кбайтов.

Реализация SDT предполагает ряд подготовительных операций, обеспечивающих применение SDT-«скелета» в конкретном проекте. При этом необходимо скомпилировать новый «скелет», назовем его SDT-x.

На рис. 8 показан пример создания SDT-x «скелета» с учетом того, взят ли он из существующего «скелета» без модификации, с некоторыми модификациями, создан заново.

Рассматриваемый «скелет» может быть основным (SDT) или производным (SDT-1, SDT-2...) от уже существующих.

Например, если необходимо подготовить SDT-x для проекта управления процессом продувания плавильной печи, то следует использовать основной SDT-«cKe-лет» и «скелет» SDT проекта управления прокатным станом. В идеальном случае, если «скелеты» хранятся в памяти ЭВМ, то новый SDT-I проекта управления можно просто скомпилировать, используя редактор текста. Несмотря на то, что реализация SDT не слишком сложный процесс, при первом внедрении рекомендуется обратиться за помощью к специалисту по SDT.

В зависимости от объема проекта и существующих «скелетов» внедрение занимает от 0.5 до 3 месяцев.

Рекомендуемый состав группы реализации: руководитель проекта (для координации), старший системный аналитик, главный программист и специалист по SDT.

 Автоматизированная разработка систем имеет большие преимущества по сравнению с обычной, так как произво-

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

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

                                    Труд велик, но и велика отдача