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

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

Модели деятельности организации создаются в двух видах [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.  Используйте средства регистрации и отображения инфор­мации об ошибках, включая в программу специальный отладочный код для распечатки выборочных значений переменных, со­общений об окончании отдельных участков программы, трасси­ровки, логических условий и т. п.