12
программного продукта, а заканчивается в момент полного его изъятия с
эксплуатации.
ЖЦ разработки АИС начинается с стадии анализа, где участники
процесса обсуждают требования, которые предъявляются к конечному
продукту.
Основная цель этой стадии – это определение детальных требований
непосредственно к системе. Кроме того, необходимо убедиться также в том,
что полностью все участники поняли поставленные задачи правильно и то, как
каждое требование будет реализовываться.
Зачастую, при обсуждении участвуют также разные специалисты по
тестированию АИС, которые уже на первых стадиях разработки требований
вносят собственные пожелания и корректирует процесс.
На стадии проектирования программисты и разработчики,
руководствуясь требованиями, выполняют разработку высокоуровневого
дизайна системы.
Разнообразные вопросы, возникающие при проектировании,
обсуждаются со всеми сторонами, включая и заказчика. Определяются также
технологии, которые используются в проекте, ограничения, загрузка команды,
временные рамки, бюджет. [37]
Утвержденный дизайн АИС определяет перечень всех разрабатываемых
программных компонентов, а также взаимодействие с разного рода сторонами,
функциональные характеристики АИС, используемые БД и многое другое.
На этом этапе используются для упрощения визуализации
проектирования так называемые нотации, то есть, схематическое выражение
характеристик для разрабатываемой системы.
После того как дизайн и все требования АИС утверждены, происходит
непосредственный переход к последующей стадии ЖЦ – непосредственно
разработке. Тут начинается написание программистами программного кода
АИС в соответствии с требованиями.
13
Системные администраторы выполняют настройку программного
обеспечения АИС, пользовательский интерфейс и логику ее работы с
сервером.
Кроме этого, программисты пишут специальные Unit-тесты для
непосредственной проверки правильности работы программного кода
каждого из компонентов системы, проводят просмотр написанного кода, а
также создают промежуточные версии и разворачивают готовую АИС в
программной среде.
Данный цикл повторяется, пока все требования не реализуются.
Стадия программирование предполагает 4 основных стадии: [31]
– определение алгоритмов;
– формирование исходного кода;
– компиляция кода;
– тестирование.
Этап оформления документации выделяют условно, поскольку, те или
другие документы создаются практически на всех стадиях ЖЦ программы. Но,
тем не менее, помимо разного рода проектной документации и записей,
сопровождающих разработку, существуют также и иные текстовые
документы, которые описывают, к примеру, функции программы, а также
способы ее применения.
Всего существует четыре уровня документации:
– проектная;
– техническая;
– пользовательская;
– маркетинговая.
На этапе тестирования тестировщики занимаются поиском
некорректностей в программном обеспечении АИС и сравнивают описанное
поведение системы в требованиях с реальным состоянием.
14
В фазе тестирования можно обнаружить пропущенные при разработке
неточности. При обнаружении дефекта, составляется отчет об ошибке, что
передается разработчикам. [29]
Последние его быстро исправляют и тестирование повторяется для того,
чтоб убедиться, что найденная проблема была полностью исправлена, а само
исправление причиной появления новых неточностей не стало.
Когда программа полностью протестирована, а также в ней больше нет
серьезных дефектов, надо выполнить релиз и передачу ее конечным
пользователям – в этом состоит этап внедрения и поддержки АИС.
После выпуска каждой новой версии программы непосредственно в
работу включается только отдел технической поддержки. Все его сотрудники
обеспечивают связь с пользователями, а также их поддержку и
консультирование.
Указанная выше последовательность стадий ЖЦ может по-разному
осуществляться в процессе создания АИС на практике. Поэтому в теории АИС
присутствует понятие модели ЖЦ.
Каскадная модель – это модель процесса разработки ПО АИС, ЖЦ
которой выглядит в качестве потока, последовательно проходящий фазы от
анализа требований до интеграции и поддержки.
Непосредственно процесс разработки реализуется при использовании
упорядоченной последовательности шагов. [23]
Модель предусматривает, что все последующие шаги начинаются после
полного завершения реализации предыдущего шага. Стоит отметить, что на
всех шагах этой модели выполняются организационные и вспомогательные
процессы, включающие управление проектом, а также управление качеством
и оценку, менеджмент конфигурации, верификацию и аттестацию, разработку
документации.
Непосредственно в результате завершения таких шагов формируются
промежуточные программные продукты, которые изменяться на следующих
шагах не могут.
15
Жизненный цикл каскадной модели можно изобразить схемой,
показанной на рисунке 4:
Рисунок 4 – Пример осуществления каскадной модели ЖЦ АИС
Основными достоинствами модели являются:
– стабильность предоставленных требований на протяжении ЖЦ
разработки;
– на каждой из стадий формируется законченный набор
документации;
– понятность и определенность шагов модели, а также простота её
применения.
Каскадная модель зарекомендовала себя хорошо при построении
простого ПО АИС, когда в начале разработки достаточно точно можно
сформулировать все нужные требования. [19]
Инкрементная модель подразумевает разработку ПО АИС с линейной
последовательностью нескольких стадий, но только в несколько инкрементов
(или версий), то есть, с запланированным улучшением ПО за все время ЖЦ,
пока разработка не подойдет к концу (рисунок 5).
Разработка ПО ведется итерациями, которые содержат циклы обратной
связи между некоторыми этапами. Межэтапные корректировки дают
возможность учитывать реально существующее влияние результатов
16
разработки с точки зрения различных этапов, время жизни каждого с них
растягивается полностью на весь срок разработки.
Рисунок 5 – Инкрементная модель
В самом начале работы над утвержденным проектом определяются
практически все основные требования для системы, они подразделяются на
стадии разной важности.
После чего выполняется непосредственная разработка системы по
принципам приращения, так, чтоб разработчик мог применять данные,
полученные при разработке ПО. [17]
Такие инкременты должны добавлять системе определенную степень
функциональности.
При этом работу начинают выполнять с компонентов с самым высшим
приоритетом.
Если части системы определены, то берут первую часть, а потом
начинают её детализировать, применяя для этого самый подходящий процесс.
В это же время можно уточнить требования для других частей, что в текущей
совокупности имеющихся требований данной работы являлись
недоступными.
17
Если есть надобность, можно вернуться к этой части позже. Если часть
уже полностью готова, она поставляется к заказчику, который может
применять её непосредственно в работе.
Это дает возможность клиенту уточнить требования и для следующих
компонентов. Потом разработчики занимаются созданием следующей части
системы.
Основные этапы этого процесса – это простая реализация подмножества
таких требований к программе, а также совершенствование модели в версиях
последовательных релизов, пока не будет полностью реализовано ПО по всей
своей полноте. [13]
При использовании спиральной модели жизненного цикла (рисунок 6)
на каждом из витков спирали выполняется создание новой версии продукта,
при чем уточняются требования проекта и определяется его качество.
Рисунок 6 – Спиральная модель ЖЦ
18
Особое внимание при этом стоит уделить начальным этапам разработки,
а именно, проектированию и анализу, где реализуемость технических решений
обосновывается посредством создания программных прототипов.
Данная модель собой представляет процесс разработки ПО, сочетающий
в себе проектирование, постадийное прототипирование для сочетания
преимуществ нисходящей и восходящей концепции, которые делают упор на
исходные этапы ЖЦ: анализ, проектирование. [11]
Отличительной особенностью модели является внимание рискам,
которые влияют на организацию ЖЦ.
На таких этапах проектирования и анализа реализуемость технических
решений, а также степень удовлетворения потребностей проверяется путем
создания так называемых прототипов.
При чем каждый виток спирали будет соответствовать созданию
работоспособного фрагмента системы. Это позволяет уточнять требования,
характеристики и цели проекта, определить уровень качества разработки,
спланировать разные работы следующих витков спирали.
1.3 Проектирование и основные технологии разработки АИС
В основе проектирования разного рода АИС лежат две взаимосвязанные
компоненты:
– стандарты разработки;
– методика разработки.
Главные понятия, подходы, а также определения проектирования для
АИС регламентируются 3-я видами программной и конструкторской
документации:
– системой конструкторской документации;
– системой программной документации;
– комплексом руководящих документов.
Составом проектной документации является комплекс стандартов и
других руководящих документов для АИС, который включает в себя указания
19
на автоматизированные системы и информационные технологии, а также
требования по содержанию документов.
Целью проектирования является выявление относительно простой
структуры АИС, называемой архитектурой. [7]
Проект – это целенаправленное и ограниченное по времени изменение
отдельной системы для изначально четко определенных целей, достижение
которых определяет процесс завершение проекта, вместе с установленными
требованиями к результатам, риску, срокам, рамкам расходования средств.
Методология проектирования под собой предполагает наличие
концепции, принципов проектирования, которые реализуются набором
методов проектирования, что, в свою очередь, поддерживаются некоторыми
инструментами проектирования.
Организация такого проектирования предполагает определение
инструментария взаимодействия проектировщиков с заказчиком при создании
проекта ЭИС, что могут также быть поддержаны набором специфических
средств.
Такие методы проектирования АИС можно классифицировать по
типовых проектных решений, уровню использования средств автоматизации,
адаптивности к изменениям.
По степени автоматизации инструменты проектирования разделяются
на такие методы: [1]
– ручного проектирования, для которого проектирование
составляющих АИС осуществляется без применения специальных
программных инструментальных средств, а процесс программирования – на
алгоритмических языках программирования (ЯП);
– компьютерного проектирования, что производит генерацию и
настройку проектных решений, которые основываются на использовании
специальных инструментальных средств.
По степени использования проектных решений различают такие методы
проектирования АИС:
20
– методы оригинального проектирования, при котором проектные
решения создаются «с нуля» по требованиям АИС;
– типового проектирования, которые предполагают конфигурацию
АИС с готовых типовых решений (программных компонентов).
Основными технологиями проектирования АИС являются:
– технология нисходящего проектирования;
– технология исходящего проектирования.
Основное назначение для нисходящего проектирования – это служить
средством разбиения задачи на несколько меньшие подзадачи таким образом,
чтобы каждая подзадача рассматривалась независимо.
На рисунке 7 показаны методологии проектирования:
Рисунок 7 – Типы проектирования АИС
При применении восходящего метода проектирования выделяются
функции нижнего уровня в первую очередь, для которых должно выполнять
работу АИС.
Такие функции реализуются при использовании программных модулей
нижних уровней.
Далее на основе таких модулей проектируются другие программные
компоненты, которые относятся к более высокому уровню.
21
Данные компоненты выполняют реализацию программных функций
более высокого уровня. [34]
Самым основным недостатком указанного метода является тот факт, что
разработчики начинают реализацию проекта с вовсе несущественных деталей.
Все это затрудняет в значительной степени проектирование проекта в целом.
Обычно применяются сочетания на практике этих двух стилей
проектирования программ. Такое сочетание также часто реализуют многими
методами:
1) Первый способ сочетания: надо выделить ключевые (или наиболее
важные) составные компоненты для промежуточных уровней ПО. [26] Далее
проектирование выполняется восходящим и нисходящим механизмами
одновременно (рисунок 5).
2) Другой способ сочетания: при применении этого способа можно
спроектировать модули самого нижнего с уровней (те, что именно необходимо
проектировать заранее), а далее программа проектируется нисходящим и
восходящим способами (рисунок 8).
Рисунок 8 – Проектирование совместным методом
При таком методе проектирования самой важной задачей считается
согласование так называемого интерфейса между нижними и верхними
уровнями программы.
В первой главе выпускной квалификационной работы рассмотрены
основные определения теории автоматизированных информационных систем,