Жизненный цикл автоматизированной информационной системы

Анализ первичных требований и планирование работ

Данный этап предваряет инициацию работ над проектом. Его основными задачами являются: анализ первичных бизнес-требований, предварительная экономическая оценка проекта, построение план-графика выполнения работ, создание и обучение совместной рабочей группы.

Проведение обследования деятельности предприятия

В рамках данного этапа осуществляется:

1) предварительное выявление требовании, предъявляемых к будущей системе;

2) определение оргштатной и топологической структур предприятия;

3) определение перечня целевых задач (функций) предприятия;

4) анализ распределения функций по подразделениям и сотрудникам;

5) определение перечня применяемых на предприятии средств автоматизации.

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

В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат:

1) данные по оргштатной структуре предприятия;

2) информация о принятых технологиях деятельности;

3) стратегические цели и перспективы развития;

4) результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

5) предложения сотрудников по усовершенствованию бизнес-процессов предприятия;

6) нормативно-справочная документация;

7) опыт системных аналитиков в части наличия типовых решений.

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

Построение моделей деятельности предприятия

На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

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

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

Переход от модели "как есть" к модели "как должно быть" осуществляется следующими двумя способами.

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

2) Радикальное изменение технологий и переосмысление бизнес-процессов ("жесткий" реинжиниринг).

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

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

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

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

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

Данный этап является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований. На этом этапе определяются:

1) архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

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

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

4) состав людей и работ, имеющих отношение к системе;

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

Системный проект строится на основе модели "как должно быть" и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, ER - модель), информационную модель, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).

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

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

1) описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

2) уменьшить затраты на разработку и внедрение системы;

3) оценить разработку по времени и результатам;

4) достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);

5) улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру интегрированной базы данных, выполнить функциональную декомпозицию типовых модулей.

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

Разработка предложений по автоматизации предприятия

На основании системного проекта осуществляется:

1) составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

2) анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору такой системы;

3) совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

4) разработка требовании к техническим средствам;

5) разработка требований к программным средствам;

6) разработка предложений по этапам и срокам автоматизации.

Разработка технического проекта

На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Этот этап разделяется на два подэтапа:

1) проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функции и технических требовании к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;

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

При этом происходит расширение системного проекта:

1) за счет его уточнения;

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

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

Разработка и тестирование

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

Внедрение системы в эксплуатацию.

Основные задачи этапа эксплуатации и сопровождения:

1) обеспечение устойчивости работы системы и сохранности информации - администрирование;

2) своевременная модернизация и ремонт отдельных элементов - техническая поддержка;

3) адаптация возможностей эксплуатируемой системы к текущим потребностям бизнеса предприятия - развитие системы.

Исследовательская часть

2.1 Описание модели системы «Администратор отеля»

АИС «Администратор отеля»

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

Ввод личных данных

Хранение информации

Поиск свободных номеров

Просмотр данных

Составление договора

Администратор

Редактирование таблиц

просмотр

Кассир

Выдача чека

Просмотр прайс листа

Пользователь

Просмотр прайс листа

Получение информации

 

Рисунок 3 –Инфологическая модель «Администратор отеля»

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

Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД.

Термин «модель данных» был введен американским математиком Коддом в 1970 г. при обосновании реляционной модели данных. Это понятие соответствует такому смысловому аспекту термина «модель», который понимается как средство, инструмент для моделирования.

В этом широком смысле любая система машинных команд, любой язык программирования, любая СУБД как инструмент для моделирования информации о предметной области, является моделью данных, так как предоставляет свои средства для описания, организации данных и их обработки.

В ГОСТе понятие модели данных для СУБД определяется как «совокупность правил порождения структур данных в базах данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательности их изменения».

Таким образом, в понятие «модель данных» входят три составляющие:

1) средства для организации данных;

2) операции для обработки, манипулирования данными;

3) ограничения, обеспечивающие целостность данных.

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

Инструментальные средства логического уровня наиболее типизируются несмотря на то, что каждая СУБД представляет собой оригинальную модель данных. Поэтому «моделью данных» в узком смысле называют тип модели данных логического уровня.

Исторически основными классическими моделями данных в этом узком смысле были иерархическая, сетевая и реляционная модели данных.

В настоящее время развиваются и постреляционные подходы.

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных.

Постановка задачи

Разработать в архитектуре “клиент - сервер” информационную систему, предназначенную для гостиницы, БД информационной системы, содержащую сведения о номерах гостиницы: категория, количество мест, стоимость проживания за сутки.

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