2.4 Разработка проекта автоматизации
Методология проектирования ИС включает в себя описание процесса создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, отождествляя его с некоторой последовательностью стадий и исполняемых на них процессов. Для каждой стадии выявляется состав и последовательность производимых работ, итоговые результаты, методы и средства, нужные для реализации работ, ответственность и роль участников и т.д. Подобное формальное описание ЖЦ ИС дает возможность спланировать и подготовить процесс совместной разработки и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий, случающихся с системой с момента ее внедрения и до окончания использования.
Модель ЖЦ отражает различные состояния системы, от момента возникновения необходимости в данной ИС и до момента ее окончательного вывода из эксплуатации. Модель жизненного цикла представлена некой структурой, которая содержит процессы, действия и задачи, реализуемые в ходе создания, работы и сопровождения ПО в течение всей жизни системы, от выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
- Каскадная модель включает в себя последовательную реализацию всех этапов проекта в заранее определенном порядке. Начало следующего этапа говорит о полном завершении работ на предыдущем этапе.
- Поэтапная модель с периодичным контролем. Создание ИС реализовано в виде итераций с циклами обратной связи между этапами. Межэтапные проверки позволяют учесть реально существующее взаимовлияние итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на весь срок разработки.
- Спиральная модель. На любом витке спирали выполняется генерация очередной версии продукта, корректируются требования проекта, выражается его качество и планируются работы уже следующего витка. Особое внимание при этом обращается на начальные этапы разработки — анализ и проектирование, где возможность создания тех или иных технических решений обосновывается и проверяется благодаря построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания относительно простых ИС, когда в самом начале разработки можно с большой точностью и полнотой составить все требования к системе. Главным недостатком такого подхода является то, что основной процесс разработки системы не может полностью уложится в такие жесткие рамки, постоянно есть потребность в возврате к уже завершенным этапам для уточнения или изменения ранее принятых решений. В итоге реальный процесс разработки ИС становится соответствующим поэтапной модели с периодичным контролем.
Для разработки документооборота материально-технического оборудования выбираем каскадную модель.
Все стадии создания системы предусматривают выполнение некоторого объема работ, представляемых в виде процессов ЖЦ. Процесс выражается как совокупность объединенных действий, изменяющих входные данные в выходные. Описание любого процесса состоит из перечня решаемых задач, исходных данных и итоговых результатов.
Есть целый ряд стандартов, определяющих ЖЦ ПО, а в отдельных случаях и процессы разработки.
Среди самых известных стандартов выделяют следующие:
- ГОСТ 34.601-90 — распространяется на АИС и указывает в себе стадии и этапы их создания. Также в нем имеется описание содержания работ на всех этапах. Стадии и этапы работы, отраженные в стандарте, зачастую соответствуют каскадной модели жизненного цикла.
- ISO/IEC 12207:1995 — стандарт на процессы и реализацию жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не имеет описания стадий, фаз и этапов.
- Custom Development Method по созданию прикладных ИС — технологический материал, углублённый до уровня заготовок проектных документов, которые рассчитаны на применение в проектах совместно с Oracle. Используется CDM для типовой модели ЖЦ (имеются все работы/задачи и этапы), а также для случаев «быстрой разработки» (Fast Track) или «облегченного подхода», которые будут оптимальны в малых проектах.
- Rational Unified Process (RUP) включает в себя итеративную модель разработки, имеющую четыре фазы: старт, анализ, создание и использование. Все эти фазы могут быть разделены на этапы (итерации), по итогу которых имеется версия для внутреннего или внешнего использования. Реализация четырех основных фазы считается циклом разработки, и любой такой цикл завершается созданием версии системы. В случае, если работа над проектом не прекращается и после этого, полученный продукт продолжает оптимизироваться и снова проходит те же фазы. Суть реализации в рамках RUP — это разработка и сопровождение моделей на базе UML.
- Microsoft Solution Framework (MSF) похож на RUP, так же имеет четыре фазы: исследование, построение, создание, стабилизация, является итерационным, включает в себя применение объектно-ориентированного моделирования. MSF в отличии от RUP в сильнее ориентирован на создание бизнес-приложений.
- Extreme Programming (XP). Экстремальное программирование (самая молодая среди остальных методологий) было реализовано в 1996 году. В основе методологии лежит командная работа, четкая коммуникация между исполнителем и заказчиком в течение всего срока проекта, а сама разработка реализуется методом последовательной доработки прототипов.
- Стандарт ISO/IEC серии 15288.
В связи с небольшим объемом разрабатываемой автоматизированной системы и ее характером необходимо использовать именно стандарт ISO/IEC серии 15288.
Задача внедрения информационной системы включает в себя создание (адаптацию) и запуск в продуктивную эксплуатацию элементов информационной системы. Так как разработка информационной системы будет осуществляться своими силами, то и внедрение будет происходить без привлечения посторонних специалистов.
Этап внедрения планируется разбить на следующие подэтапы:
- Предпроектное обследование. В ходе обследования выявляются основные информационные потоки на предприятии и сверяется база основной нормативно-справочной документации. Главным требованием в данном случае является наличие всех необходимых для функционирования корпоративных информационных систем справочников и классификаторов и соответствие принципових организации требованиям системы. В ходе выполнения этапа обязательно должны быть проанализированы на полноту корпоративные стандарты учета и отчетности. На данном этапе также производится диагностирование проблем, которые могут возникнуть при внедрении, разрабатывается и согласовывается настройка справочников и классификаторов системы в соответствии с сформулированными требованиями. При необходимости, принимаются решения об изменении существующих практик учета или функциональных моделей. По результатам этапа формируется подписываемый всеми участниками проекта внедрения документ, который описывает все выявленные проблемы и намечает пути их ликвидации.
- Построение информационно-функциональной модели деятельности предприятия, описание и оптимизация процессов, подвергающихся автоматизации. Моделирование должно проводиться хорошо обученными сотрудниками рассматриваемого предприятия с привлечением высококвалифицированных консультантов и с привязкой созданной модели к стандартам бизнеса и к будущей системе.
- Адаптация ИС на предприятии. В ходе этапа производится настройка системы тестирование отдельных модулей и функций группой внедрения. На данном этапе также очень важно наличие корпоративных стандартов, так как именно они являются основой настроек системы.
- Опытная эксплуатация информационной системы. Осуществляется для тестирования полного соответствия функциональности, полученной в результате настройки системы, требованиям предприятия. На этом этапе сохраняется двойной ввод данных в старую и новую системы. В ходе опытной эксплуатации: генерируются стандартные отчеты (с помощью ИС и обычными способами) и производится верификация данных; система постепенно вводится в эксплуатацию, по отдельным участкам учета; документируются инструкции по ведению рабочих мест и корректируются должностные инструкции участников учетного процесса. В отдельных подразделениях предприятия в систему вводятся фактические данные (в ограниченном объеме) и последовательно тестируются бизнес-функции путем моделирования реальных ситуаций деятельности предприятия (в условиях, максимально приближенных к действительности). Отрабатывается взаимная работа подразделений на основе тестовых пилотных примеров. Конечные пользователи (сотрудники отдела ИТ) обучаются работе с настроенной системой непосредственно на своих рабочих местах. После обучения конечных пользователей отрабатывается интегрированный пилотный пример и полностью моделируется деятельность предприятия. На основе результатов выполнения пилотного примера руководством предприятия принимается решение о переводе ИС в промышленную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное использование информационной системы для выполнения ею тех функций, для которых она предназначена.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две группы: плановые и неплановые.
К плановым работам будут относится такие работы, как:
- инсталляция программного обеспечения;
- базовая настройка и проверка работоспособности компонентов устанавливаемой системы;
- устранение недостатков в конфигурации системы;
- проверка надежности работы системы;
- окончательная донастройка.
Данные работы будут проводиться той же группой, что и на ранних этапах. В состав этой группы входят сотрудники технического отдела — технические специалисты и системные администраторы. Модель процессов MSF учитывает частые изменения проектных требований. Она основывается на том, что создание решения включает в себя короткие циклы, создающие поступательные движения от простейших версий решения к его итоговому виду.
В модели MSF есть 5 фаз ЖЦ: создание концепции, построение плана, разработка, тестирование, внедрение.
Этап создания концепции состоит из заложения одной из фундаментальных основ успеха проекта – сбор и сплочение проектной группы на базе выработки единого видения. Проектная группа должна четко понимать, что она хочет сделать для заказчика и выразить цель таким образом, чтобы 100% мотивировать и заказчика, и проектную команду. В таком случае в роли заказчика выступает сам разработчик. Создание высокоуровневого взгляда на цели и варианты проекта расценивается как ранняя стадия планирования. Она готовит почву для процессов разработки детальных планов, которые осуществятся непосредственно во время фазы планирования.
Главными задачами этапа создания концепции становится сборка ядра проектной группы и подготовка документа с описанием рамок проекта и общими требованиями. Составление видения проекта и специфицирование его рамок не является одним и тем же, хотя для успеха проекта важны оба компонента. Видение – это неограниченное представление о том, каким хотелось бы видеть решение. Рамки же задают понятные границы того, что из предложенного этим видением будет возможно реализовать в условиях уже созданных проектных ограничений.
За время проведения этапа подготовки концепции реализуется определение и анализ бизнес требований. Подробнее эти требования уже анализируются во время этапа планирования.
Веха «Концепция утверждена» – в ней проектная группа составляет соглашение об общих задачах проекта, доступных в решении функциональности и конкретных временных рамках.
Итоги:
- Базовое описание и рамки проекта;
- Составление структуры проекта.
Этап планирования включает в себя основную работу по составлению планов проекта. Он подразумевает составление проектной группой функциональной спецификации, создание дизайнов, доработку рабочих планов, оценку затрат на проект и срока доработки разных составляющих проекта.
В начале этапа планирования проектная группа изучает и документирует проектные требования. Они делятся на 4 общих категории: бизнес-требования, потребительские требования, требования по использованию и системные требования, касающиеся решения в целом. В рамках проектирования решения и разработки его функциональной спецификации важно следить за соответствием между указанными требованиями и проектируемой функциональностью. Это соответствие не так важно и будет взаимно-однозначным. Оно является одним из способов отслеживания корректности дизайна и его полноты для достижения поставленных перед решением целей.
Процесс проектирования можно назвать систематическим способом продвижения от абстрактных задач к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей, описывающих различные типы пользователей (включая персонал сопровождения) и их должностные обязанности. Значительная часть этой работы реализуется во время фазы подготовки концепции. Затем составляется набор сценариев применения, в каждом из которых прогоняется выполнение какой-либо операции конкретным типом пользователя. В итоге каждый сценарий использования разделяется на последовательность специфических действий, называемых примерами использования, необходимыми для выполнения пользователем с целью реализации операции.
Есть 3 уровня процесса проектирования: логический дизайн, концептуальный дизайн и физический дизайн. Работа над логическим дизайном начинается через определенный промежуток времени после начала работы над концептуальным дизайном, а создание физического дизайна начинается через некоторый промежуток времени после начала работы над логическим.
Результаты процесса проектирования описываются в функциональной спецификации. Функциональные спецификации представляют вид и поведение каждой компоненты решения. Также для всех составляющих имеется их архитектура и дизайн.
Функциональная спецификация используется для множества целей. Главные из них – это:
- Команды разработчикам о том, что они должны будут реализовать;
- База для оценки объема работы;
- Полноценное соглашение с заказчиком о том, что нужно делать;
- Оптимизация деятельности всей проектной команды.
Как только разработана базовая версия функциональной спецификации, начинается детальное планирование. Руководитель проектной группы готовит план и участвует в командных сессиях планирования. Примеры планов состоят из плана внедрения, плана тестирования, плана использования, плана мер безопасности, плана обучения.
Далее проектная группа совместно оценивает планы и находит взаимозависимости между ними. Все планы синхронизируются и выражаются в виде сводного плана проекта.
Члены проектной группы, входящие в разные ролевые кластеры, подсчитывают нужное для выполнения запланированных задач время и готовят календарный график сдачи результатов. Далее идет синхронизация календарных графиков с последующим их внедрением в сводный календарный график проекта.
Веха «Планы проекта утверждены» отражает соглашение между проектной группой. Промежуточные вехи этапа планирования успешно пройдены, подготовленные календарные графики реалистичны, все роли распределены и ответственности в команде указаны должным образом. Функциональные спецификации, сводный план и сводный календарный график проекта становятся основой для принятия альтернативных решений в будущем.
Утвержденные планы, таблицы, графики и т.д. составляют начальную версию проекта. Она состоит из всех соглашений, принятых на основе общего мнения с учетом 3 плановых показателей проекта: ресурсы, время и функциональность решения. После создания и утверждения базовой версии проекта, проектная группа начинает ее разрабатывать.
Изменения в исходной базовой версии проекта строго отслеживаются. Это не означает, что все принятые во время этапа планирования решения неизменны – в ходе этапа разработки проектная группа должна изучить и формально утвердить или опровергнуть все предлагаемые корректировки базовой версии.
Итоги:
- Описание функционала;
- График и план выполнения проекта.
Этап разработки включает в себя создание проектной группой компонент решения (документацию и программный код). Но часть этой работы может продолжаться также на этапе тестирования, если такая необходимость имеется. Данный этап также включает в себя создание инфраструктуры.
Активность проектной команды на этом этапе не ограничена составлением кода – все ролевые кластеры участвуют в разработке и тестировании решения.
Веха «Разработка завершена» становится итогом всего этапа разработки. К моменту ее наступления разработка всех компонентов завершена, и решение готово к тестированию и стабилизации. Компания может оценить решение и определить все оставшиеся проблемы и нерешенные вопросы, которые важно уладить до выпуска решения.
Итоги:
- Готовый исходный код приложений;
- Скрипты конфигурации и инсталляции;
- Окончательная доработка функционала;
- Обоснование решения;
- Сценарии и описание тестов.
Этап тестирования подразумевает проведение проверки разработанного решения. При этом внимание приковано к его работе в реалистичной модели производственной среды. Проектная группа занята нахождением и устранением ошибок, а также подготовкой решения к выпуску.
После того, как появляется версия, достаточно стабильная для того, чтобы быть кандидатом для выпуска, производится первоначальное внедрение решения.
Этап тестирования завершается вехой «Готовность решения утверждена». В состоянии, которые имеется к данному моменту, решение может полноценно внедряться в производственную среду. Также к моменту наступления этой вехи проектная группа заканчивает разрешение всех существенных проблем и реализует внедрение решения. Ответственность за постоянное управление и поддержку решения теперь лежит на команде сопровождения.
Итоги:
- Готовый продукт;
- Готовая документация;
- Обоснование решения;
- Итоги всех тестов;
- Код работающего приложения;
- Проектная документация;
- Результаты пройденного этапа.
Этап внедрения включает в себя внедрение решения проектной группой, тестирование внедренного решения, передачу работы персоналу поддержки и сопровождения. По итогам внедрения проектная группа анализирует итоги работы и удовлетворенность заказчика.
В момент этого этапа по ходу переноса компонент решения из среды тестирования в производственную среду также идут работы по тестированию всего комплекса.
Веха «Внедрение завершено» является окончанием этапа внедрения. К этому времени решение уже дает заказчику некоторую бизнес-отдачу, а проектная группа заканчивает свою деятельность.
Решение разрабатывается стабильным и четко удовлетворяющим выработанным критериям успешности. Стабильность решения показывает также готовность систем его использования и обслуживания.
Итоги:
- ИС эксплуатации и поддержки;
- Процессы и процедуры;
- Журналы протоколов, базы знаний и отчеты;
- Версии проектных документов, массивы информации и программный код, созданный во время проекта;
- Отчет об окончании проекта;
- Итоговые версии всех проектных документов;
- Уровень удовлетворенности заказчика и потребителей;
- Описание других шагов.
В процессе использования персонал компании должен четко следовать всем инструкциям, которые относятся к созданной ИС. В случае проблем или вопросов, персонал обращается в службу поддержки. Эта служба проанализирует конкретную ситуацию, и примет меры для возобновления работы.
2.5 Ожидаемые риски и их описание
В процессе ЖЦ создаваемой ИС не избежать разного рода рисков.
Выделим главные риски, характерные для каждого этапа ЖЦ нашей ИС и обозначим меры их минимизации.
Этап подготовки концепции – есть риск сознания концепции, которую в дальнейшем будет почти невозможно реализовать. В подготовке концепции должны быть описаны главные функции разрабатываемой ИС. Главное выделить основу, и в дальнейшем развивать разработанную систему.
Для предотвращения реализации рисков на этапе подготовки концепции, важно четко понимать свои возможности. Для предотвращения переоценки собственных сил, изначально нужно создать общую концепцию, в которой уже будут заложены только базовые функции системы. И по мере углубления в эту разработку можно увеличивать дополнительные функции.
Этап планирования имеет риск неверного планирования, создание очень оптимистичных планов проекта, где компания не сможет уложится, вследствие чего придется увеличивать время разработки, что может привести к удорожанию проекта в целом. К этапу планирования нужно отнестись очень важно, отслеживать каждый шаг и анализировать реалистичность результатов.
Для минимизации риска на этапе планирования нужно во время планирования заложить в график поправки на некоторые задержки в выполнении тех или иных действий. Так нужно постараться создать гибкий график, который бы не корректировался из-за задержки или опережения.
Этап разработки содержит риск того, что разработка некоторого модуля будет связана с большими трудностями, а отдельная функция будет мешать продвижению разработки. На данном этапе нужно вовремя выявить проблемный модуль или функцию и по возможности упростить ее, заменить другой или удалить полностью из проекта.
Чтобы предотвратить риск разработки сложного модуля, принимается несколько решений: либо разбивать данный модуль на несколько и решать указанные задачи по отдельности, либо упрощать сложный модуль, если это является единственным вариантом преодоления риска.
Этап тестирования имеет риск выявления большого количества ошибок в программном коде, что повлечёт большие затраты на доработку и устранение всех выявленных ошибок. Нельзя предсказать, какой количество ошибок будет найдено и как много времени будет нужно на их устранение.
Для минимизации рисков на этапе тестирования необходимо данному этапу отвести максимально возможное время, выделенное на создание системы, поскольку в зависимости от того, как качественно будет реализован продукт, зависит, примет ли заказчик данную разработку или нет.
Этап внедрения может быть очень длительным, если заказчик каким-то образом будет не доволен созданным продуктом, а также сам персонал автоматизируемой компании может отрицательно относиться к внедрению нового ПО.
Для минимизации рисков на данном этапе важно произвести качественное обучение персонала еще до начала внедрения, подготовить службу сопровождения и поддержки, понять, какие проблемы имеют место быть в процессе внедрения и быть готовым к их решению. Постоянно отвечать на вопросы персонала по поводу возникающих у него проблем, открыть горячую линию для решения возможных проблем.
3 ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ
3.1 Характеристика входной и выходной информации
3.1.1 Характеристика нормативно-справочной и входной оперативной информации
Входной информацией для разрабатываемой информационной системы являются данные сотрудников, об отделах и должностях, сведения о типах средств измерения, сведения об операциях и их статусах. Эти данные поступают как в цифровом, так и в печатном виде.
В систему вносятся следующие данные о пользователях:
- Фамилия
- Имя
- Отчество
- Дата рождения
- Логин
- Пароль
- Должность
- Тип пользователя
Для обеспечения работы системы предусмотрены справочники, приведенные в таблице 3.1.
Таблица 3.1 Перечень используемых справочников
| название справочника | ответственный за ведение | средний объём справочника в записях | среднюю частоту актуализации | средний объем актуализации, % |
| Статусы операций | Администратор | 45 | 1 раз в месяц | 10 |
| Тип средства измерения | Администратор | 150 | 1 раз в год | 10 |
| Тип пользователя | Администратор | 250 | 1 раз в год | 10 |
| Тип операции | Администратор | 5 | 1 раз в год | 10 |
| Статусы | Администратор | 45 | 1 раз в месяц | 10 |
| Средства измерения | Администратор | 45 | 1 раз в месяц | 10 |
| Отдел | Администратор | 45 | 1 раз в месяц | 10 |
| Должности | Администратор | 45 | 1 раз в месяц | 10 |
| Сотрудники | Администратор | 45 | 1 раз в месяц | 10 |
| Оборудование | Администратор | 45 | 1 раз в месяц | 10 |
Все документы могут поступать как бумажной, так и в электронной формах.
Состав справочников приведен ниже.
- Справочник Оборудование:
- Тип_СИ
- Заводской_номер
- Дата_начала_использования
- Примечание
- Отдел
- Справочник Сотрудники:
- Фамилия
- Имя
- Отчество
- Дата_рождения
- Логин
- Пароль
- Должность
- Тип_пользователя
- Справочник Должности:
- Название
- Справочник Отдел:
- Название
- Справочник Средства измерения:
- Номер_госреестра
- Название
- Изготовитель
- Справочник Статусы
- Название
- Справочник Тип операции
- Название
- Справочник Тип пользователя
- Название
- Справочник Тип средства измерения
- Название
- Справочник Статусы операций:
- Операция
- Статус
- Дата
Оперативная информация учитывается в таблице Операции со следующим реквизитным составом:
- Оборудование
- Дата_завершения
- Тип_операции
- Сотрудник
- Описание
3.1.2 Характеристика результатной информации
В качестве выходных данных в разработанной ИС формируются следующие документы:
- Список средств измерения;
- Список сотрудников;
- Список оборудования;
- Отчет по выполненным поверкам за период.
- Отчет по выполненным калибровкам за период.
- Отчет по выполнению графика поверок;
- Отчет по выполнению графика калибровок;
- Список средств измерения со сроками проведения калибровок и поверок.
Список средств измерения содержит код, номер и название средства измерения, список сотрудников – ФИО, должность сотрудника, его логин для доступа в систему. Список оборудования содержит такие реквизиты, как код, модель, заводской номер, название, дату начала использования.
Остальные отчеты формируются за период.
В системе учтены две основные операции – калибровка и поверка средств измерения. Именно по эти операциям формируются отчеты.
Отчет по выполненным поверкам за период содержит следующие реквизиты:
- № п/п
- Дата поступления
- Дата выполнения
- Тип СИ (модель)
- Наименование СИ Заводской номер
- Принадлежит отделу
- Ответственный за выполнение работы
Отчет по выполненным калибровкам за период содержит следующие реквизиты:
- № п/п
- Дата поступления
- Дата выполнения
- Тип СИ (модель)
- Наименование СИ Заводской номер
- Принадлежит отделу
- Ответственный за выполнение работы
Отчет по выполнению графика поверок характеризует степень выполнения запланированных операций по поверке СИ.
Отчет по выполнению графика калибровок характеризует степень выполнения запланированных операций по калибровке СИ.
Список средств измерения со сроками проведения калибровок и поверок содержит следующие реквизиты:
- № п/п СИ
- Тип СИ (Модель)
- Заводской номер
- Дата поступления
- Срок (до)
- Тип операции
3.2 Программное обеспечение задачи (комплекса задач, ИП)
3.2.1 Общие положения (дерево функций и сценарий диалога)
Основная функции разрабатываемой информационной системы, сложна и требуют иерархического представления. Для более наглядного представления функции системы необходимо декомпозировать на составляющие его функции.
Представим основную функцию системы в дерева функций.
На рисунке 3.1. представлено дерево функций системы.
Первый уровень представляет основную функцию разрабатываемой системы – учёт информации о производимых операциях со средствами измерения. В ходе выполнения этой функции пользователь вводит данные о средстве измерения, необходимой операции, ее результате после выполнения, ответственном лице.
Второй уровень системы представляет функцию получения вышеперечисленных и показанных на схеме отчетов. Кроме получения отчетов в виде экранной формы, присутствует возможность экспорта отчетов в форматы pdf, xls, opendoc.
Служебные функции содержат функции настройки доступа к ИС, а также авторизационных данных, работу со справочниками – добавление и редактирование данных.
Сценарии диалога системы для пользователя приведен на рисунке 3.2.
