Методология и технология проектирования ЛИС

Методология и технология проектирования ЛИС

Современные методологии и реализующие их технологии проектирования АИС поставляются в электронном виде вместе с CASE-средствами (рассмотрены далее) и включают библиоте­ки процессов, шаблонов, методов, моделей и других компонен­тов, предназначенных для построения ПО того класса систем, на который ориентирована методология. Электронные методо­логии и технологии составляют ядро комплекса согласованных инструментальных средств разработки АИС [6, 8, 16—18]. Осо­бенности современных методологических решений проектиро­вания АИС невозможно реализовать без определенных техноло­гий проектирования, соответствующих масштабу и специфике проекта.

Технология проектирования АИС — это совокупность методов и средств проектирования АИС, а также методов и средств орга­низации проектирования (управление процессом создания и модернизации проекта АИС) [8, 16—18]. В основе технологии про­ектирования лежит технологический процесс (ТП), который оп­ределяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий.

Согласно [20] ТП проектирования АИС представляет собой совокупность последовательно-параллельных, связанных и со­подчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектирова­нии АИС, могут быть определены как неделимые технологиче­ские операции или как подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными, которые вырабатывают по установленным критери­ям оценки результатов проектирования.

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

Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АИС.

Основные требования, предъявляемые к выбираемой техно­логии проектирования, следующие:

•   созданный с помощью этой технологии проект должен от­вечать требованиям заказчика;

•   технология должна максимально отражать все этапы цикла жизни проекта;

•   технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;

•   технология должна способствовать росту производительно­сти труда проектировщиков;

•   технология должна обеспечивать надежность процесса про­ектирования и эксплуатации проекта;

•   технология должна способствовать простому ведению про­ектной документации.

Технология проектирования АИС реализует определенную методологию проектирования. В свою очередь, методология про­ектирования предполагает наличие некоторой концепции, прин­ципов проектирования и реализуется набором методов и средств.

Методы проектирования АИС можно классифицировать по степени использования средств автоматизации, типовых проект­ных решений, адаптивности к предполагаемым изменениям.

По степени автоматизации различают:

•   ручное проектирование, при котором проектирование ком­понентов АИС осуществляется без использования специ­альных инструментальных программных средств; програм­мирование производится на алгоритмических языках;

•   компьютерное проектирование, при котором генерация или конфигурация (настройка) проектных решений произ­водится с использованием специальных инструментальных
программных средств.

По степени использования типовых проектных решений разли­чают:

•   оригинальное   (индивидуальное)   проектирование,   когда проектные решения разрабатываются «с нуля» в соответст­вии с требованиями к АИС;

•   типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программ­ных модулей).

Оригинальное проектирование АИС предполагает максималь­ный учет особенностей автоматизированного объекта.

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

По степени адаптивности проектных решений различаются следующие методы:

•   реконструкция — адаптация проектных решений выполня­ется  путем  переработки  соответствующих компонентов (перепрограммирования программных модулей);

•   параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;

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

Сочетание различных признаков классификации методов проектирования обусловливает характер используемой техноло­гии проектирования АИС. Выделяются два основных класса технологии проектирования: каноническая и индустриальная (табл. 1.5). Индустриальная технология проектирования в свою очередь разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметриче­ски-ориентированное или модельно-ориентированное) проекти­рование. Использование индустриальных технологий проекти­рования не исключает использования в отдельных случаях канонической технологии [18, 19].

Каноническое проектирование АИС ориентировано на исполь­зование главным образом каскадной модели жизненного цикла АИС. Стадии и этапы работы такого проектирования описаны в ГОСТ 34.601-90.

В зависимости от сложности объекта автоматизации и набо­ра задач, требующих решения при создании конкретной АИС, стадии и этапы работ могут иметь различную трудоемкость. До­пускается объединять последовательные этапы и исключать не­которые из них на любой стадии проекта. Допускается также на­чинать выполнение работ следующей стадии до окончания пре­дыдущей.

Стадии и этапы создания АИС, выполняемые организация­ми-участниками, прописываются в договорах и технических за­даниях на выполнение работ.

Стадия 1. Формирование требований к АИС:

•    обследование объекта и обоснование необходимости созда­ния АИС;

•    формирование требований пользователей к АИС;

•    оформление отчета о выполненной работе и тактико-тех­нического задания на разработку.

Стадия 2. Разработка концепции АИС:

•              изучение объекта автоматизации;

• проведение необходимых научно-исследовательских работ; . разработка вариантов концепции АИС, удовлетворяющих требованиям пользователей;

•              оформление отчета и утверждение концепции.

Стадия 3. Техническое задание:

. разработка и утверждение технического задания на созда­ние АИС.

Стадия 4. Эскизный проект:

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

. разработка эскизной документации на АИС и ее части.

Стадия 5. Технический проект:

. разработка проектных решений по системе и ее частям;

•              разработка документации на АИС и ее части;

. разработка и оформление документации на поставку ком­плектующих изделий;

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

Стадия 6. Рабочая документация:

•              разработка рабочей документации на АИС и ее части;
• разработка и адаптация программ.

Стадия 7. Ввод в действие:

•   подготовка объекта автоматизации;

•   подготовка персонала;

• комплектация АИС поставляемыми изделиями (программ­ными и техническими средствами, программно-технически­ми комплексами, информационными изделиями);

• строительно-монтажные работы;

•              пусконаладочные работы;

• проведение предварительных испытаний;

•   проведение опытной эксплуатации;

•   проведение приемочных испытаний.

Стадия 8. Сопровождение АИС:

• выполнение работ в соответствии с гарантийными обяза­тельствами;

•              послегарантийное обслуживание.

Рассмотрим  специфику составляющих некоторых стадий подробнее.

Обследование — это изучение и анализ организационной структуры предприятия, его деятельности и существующей сис­темы обработки информации [20]. Материалы, полученные в ре­зультате обследования, используются для:

•    обоснования разработки и поэтапного внедрения систем;

•    составления технического задания на разработку систем;

•    разработки технического и рабочего проектов систем.

На этапе обследования целесообразно выделить две состав­ляющие: определение стратегии внедрения АИС и детальный анализ деятельности организации.

Основная задача первого этапа обследования — оценка ре­ального объема проекта, его целей и задач на основе выявлен­ных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком АИС самостоятельно, или с привлечением кон­салтинговых организаций. Этап предполагает тесное взаимодей­ствие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия — полу­чить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в ре­зультате интервью, бесед или семинаров с руководством, экспер­тами и пользователями.

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

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

Примерное содержание ТЭО:

•    ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;

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

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

•   описание выполняемых системой функций;

•   возможности развития и модернизации системы;

•   интерфейсы и распределение функций между человеком и системой;

•   требования к ПО и системам управления базами данных (СУБД).

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

Аналитики собирают и фиксируют информацию в двух взаи­мосвязанных формах:

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

•   сущности — информация о классах объектов, имеющих значение для организации и о которых собираются данные.

При изучении каждой функциональной задачи управления определяются:

•    наименование задачи; сроки и периодичность ее решения;

•    степень формализуемости задачи;

•    источники информации, необходимые для решения задачи;
. показатели и их количественные характеристики;

•    порядок корректировки информации;

•   действующие алгоритмы расчета показателей и возможные методы контроля;

•   действующие средства сбора, передачи и обработки инфор­мации;

•   действующие средства связи;

•   принятая точность решения задачи;

•   трудоемкость решения задачи;

•   действующие формы представления исходных данных и ре­зультатов их обработки в виде документов;

•   потребители результатной информации по задаче.

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

•   количество документов;

•   место формирования показателей документов;

•   взаимосвязь документов при их формировании;

•   маршрут и длительность движения документа;

•   место использования и хранения данного документа;

•   внутренние и внешние информационные связи;

•   объем документа в знаках.

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

На этапе обследования следует классифицировать планируе­мые функции системы по степени важности. Один из возможных форматов представления такой классификации — MuSCoW [22]. Эта аббревиатура расшифровывается так: Must have — необходи­мые функции; Should have — желательные функции; Could have — возможные функции; Won't have — отсутствующие функции.

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

Модели деятельности организации создаются в двух видах [6, 16, 18]:

•   модель «как есть» («as is») — отражает существующие в ор­ганизации бизнес-процессы;

•   модель «как должно быть» («to be») — отражает необходи­мые изменения бизнес-процессов с учетом внедрения АИС.

Уже на этапе анализа необходимо привлекать к работе груп­пы тестирования для решения следующих задач:

•              получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных сис­тем, СУБД и т. п.;

• разработки плана работ по обеспечению надежности АИС и ее тестирования.

Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Чем позже обна­ружены ошибки в проектных решениях, тем дороже обходится их исправление; худший вариант — их обнаружение на этапе внедрения. Таким образом, чем раньше группы тестирования начнут выявлять ошибки в АИС, тем ниже стоимость работы над системой. Время на тестирование системы и на исправление обнаруженных ошибок должно быть предусмотрено не только на этапе разработки, но и на этапе проектирования.

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

Результаты обследования представляют объективную основу для формирования технического задания на АИС [16—18].

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

При разработке технического задания (ТЗ) необходимо ре­шить следующие задачи:

•  установить общую цель создания АИС;

•  установить общие требования к проектируемой системе;

•  разработать и обосновать требования, предъявляемые к ин­формационному, математическому, программному, техни­ческому и технологическому обеспечению;

•  определить состав подсистем и функциональных задач;

•  разработать и обосновать требования, предъявляемые к подсистемам;

•  определить этапы создания системы и сроки их выполнения;

•  провести предварительный расчет затрат на создание сис­темы и определить уровень экономической эффективности ее внедрения;

•  определить состав исполнителей.

Типовые требования к составу и содержанию технического задания приведены в табл. 1.6.

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

Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

• функции АИС;

•    функции подсистем, их цели и ожидаемый эффект от вне­дрения;

•    состав комплексов задач и отдельных задач;

•    концепция информационной базы и ее укрупненная струк­тура;

•    функции системы управления базой данных;

•    состав вычислительной системы и других технических средств;

•    функции и параметры основных программных средств.

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

В соответствии с ГОСТ 19.102—77 стадия эскизного проек­тирования содержит два этапа: разработку эскизного проекта; утверждение эскизного проекта.

Первый этап разработки состоит из:

•    предварительной разработки структуры входных и выход­ных данных;

•    уточнения методов решения задачи;

• разработки общего описания алгоритма решения задачи;

•    разработки технико-экономического обоснования;

•    разработки пояснительной записки.

При этом допускается объединение и исключение некоторых работ.

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

Обязательные документы:

1)  уточненное техническое задание на проектирование и раз­работку АИС;

2)  спецификация квалификационных требований на АИС;

3)  комплект спецификаций требований на функциональные программные компоненты и описания данных;

4)  спецификация требований на внутренние интерфейсы компонент и интерфейсы с внешней средой;

5)  описание системы управления базой данных, структуры и распределения программных и информационных объектов в базе данных;

6)  проект руководства по защите информации и обеспече­нию надежности функционирования АИС;

7)  предварительный вариант руководства администратора АИС;

8)  предварительный вариант руководства пользователя АИС;

9)  уточненный план реализации проекта;

10) уточненный план управления обеспечением качества АИС;

11) пояснительная записка предварительного проекта АИС;

12) уточненный контракт (договор) с заказчиком на деталь­ное проектирование АИС.

Документы, оформляемые по согласованию с заказчиком:

1)  предварительное описание функционирования АИС;

2)  схема потоков данных между функциональными компо­нентами АИС;

3)  уточненная схема архитектуры АИС,  взаимодействия программных и информационных компонент, организации вы­ числительного процесса и распределения ресурсов;

4)  описание показателей качества компонент и требований к ним по этапам разработки АИС;

5)  отчет о технико-экономических показателях,  графике реализации проекта, распределении ресурсов и бюджета;

6)  таблица распределения специалистов по компонентам и по этапам работ;

7)  аттестаты разработчиков на право использования техно­логии и средств автоматизации разработки АИС;

8)  описание требований к составу и формам результирую­щих документов по этапам работ;

9)  план отладки программных компонент, обеспечения ее методами и средствами автоматизации тестирования;

10)  предварительное руководство для детального проектиро­вания, программирования и отладки компонент АИС;

11)  предварительный план продажи и внедрения;

12)  описание предварительной структуры базы данных.

На основе технического задания и эскизного проекта разра­батывается технический проект АИС.

Технический проект системы — это техническая документа­ция, содержащая общесистемные проектные решения, алгорит­мы решения задач, а также оценку экономической эффективности АИС и перечень мероприятий по подготовке объекта к вне­дрению.

На этом этапе осуществляется комплекс научно-исследова­тельских и экспериментальных работ для выбора основных про­ектных решений и расчет экономической эффективности систе­мы. Состав и содержание технического проекта приведены в табл. 1.7.

На стадии «Рабочая документация» осуществляется создание программного продукта и разработка всей сопровождающей до­кументации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АИС в действие и ее эксплуатации, а также для поддержа­ния уровня эксплуатационных характеристик (качества) систе­мы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.

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

В зависимости от взаимосвязей компонентов АИС и объекта автоматизации испытания могут быть автономные и комплекс­ные. В автономных испытаниях участвуют компоненты системы. Их проводят по мере готовности частей системы к сдаче в опыт­ную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных компонентов (подсистем) или для системы в целом.

Для планирования проведения всех видов испытаний разра­батывается документ «Программа и методика испытаний». Раз­работчик документа устанавливается в договоре или ТЗ. В каче­стве приложения в документ могут включаться тесты или кон­трольные примеры.

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

Затраты на выявление и устранение ошибок на более позд­них этапах проектирования возрастают примерно экспоненци­ально (рис. 1.10) [8, 16, 18].

Исследователи насчитывают 169 типов ошибок, сведенных в 19 больших классов:

1)логические;

2)   ошибки манипулирования данными;

3)   ошибки ввода-вывода;

4)   ошибки в вычислениях;

5)   ошибки в пользовательских интерфейсах;

6)  ошибки в операционной системе и вспомогательных про­
граммах;

7)  ошибки компоновки;

8)  ошибки в межпрограммных интерфейсах;

9)  ошибки в интерфейсах «Программа — системное ПО»;

10)  ошибки при обращении с внешними устройствами;

11)  ошибки сопряжения с базой данных (БД);

12)  ошибки инициализации БД;

13)  ошибки изменений по запросу извне;

14)  ошибки, связанные с глобальными переменными;

15)  повторяющиеся ошибки;

16)  ошибки в документации;

17)  нарушение технических требований;

18)  неопознанные ошибки;

19)  ошибки оператора.

Не все ошибки исходят от разработчика. По данным разных исследователей, от 6 до 19 % ошибок порождаются ошибками в документации [8, 16, 18].

Соотношение разработки и испытаний на различных этапах проектирования АИС приведено на рис. 1.11.

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

Методика отладки учитывает симптомы возможных ошибок:

•   неверная обработка (неправильный ответ, результат) —до 30%;

•   неверная передача управления — 16 %;

•   несовместимость программ с используемыми данными —15%;

•   несовместимость программ по пересылаемым данным —до 9 %.

При разработке отладочных заданий решаются следующие задачи:

•   составление тестов;

•   выбор точек, зон и маршрутов контроля;

•   определение перечня контролируемых величин и порядка фиксации их значений;

•   задание порядка тестирования;

•   оценка достоверности и трудоемкости отладки.

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

•              управления выводом;

•  моделирования процесса исполнения отлаживаемой про­граммы;

•  выдачи состояния компонент памяти в процессе исполне­ния программ;

•  проверки условий достижения определенных состояний в процессе исполнения программы;

•  установления тестовых значений исходных данных;

•  осуществления условных переходов в тестировании в зави­симости от результатов исполнения других макрокоманд или различных тестов;

•  выполнения служебных операций по подготовке програм­мы к тестированию.

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

1.  Используйте семантический, заранее продуманный подход к отладке, планируйте процесс отладки и тщательно проекти­руйте тестовые наборы данных с наиболее простых вариантов, исключая наиболее вероятные источники ошибок.

2.  Для упорядочения процесса тестирования собирайте и
анализируйте информацию:

•    об особенностях и статистике ошибок;

•    о специфике исходных данных и последовательности из­менения переменных в программе и их взаимном влиянии;

•    о структуре алгоритма и особенностях его программной реализации.

3.  В каждый момент времени определяйте местоположение только одной ошибки.

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