Дипломная работа: Автоматизация контроля технического состояния оборудования интернет-провайдера ООО "Зенком"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
65
необходимость создания тех или иных технических решений заранее обосновывается
и проверяется методом создания прототипов и макетов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда изначально можно очень точно и полно указать все
требования к системе. Главным недостатком подобного подхода становится то, что
реальный процесс разработки системы не сможет полностью уложится в такую
сложную схему, поскольку всегда будет потребность в возврате к уже завершенным
этапам для уточнения или пересмотра ранее определенных решений. Поэтому
реальный процесс разработки ИС соответствует поэтапной модели с поэтапным
контролем. Но такие недостатки не могут играть основную роль при проектировании
системы контроля технического состояния оборудования, поэтому смело
останавливаемся на нем.
Любая из стадий разработки системы включает в себя реализацию некоторого
объема работ, которые отображаются в виде процессов ЖЦ. Процесс описывается в
виде совокупности взаимосвязанных действий, изменяющих исходные данные в
выходные. Описание каждого отдельного процесса состоит из перечня решаемых
задач, заданных данных и результатов.
Есть целый ряд стандартов, определяющих ЖЦ ПО, а иногда даже и процессы
разработки.
Среди наиболее известных стандартов можно выделить:
ГОСТ 34.601-90 - распространяется на АИС и отражает в себе стадии и
этапы их создания. Также в нем есть описание содержания работ на всех этапах.
Стадии и этапы работы, показанные в стандарте, зачастую соответствуют каскадной
модели ЖЦ.
ISO/IEC 12207:1995 - стандарт на процессы и реализацию ЖЦ.
Используется во всех видах заказного ПО. Стандарт не включает в себя описания
стадий, фаз и этапов.
Custom Development Method по разработке прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных документов,
рассчитанных на применение в проектах совместно с Oracle. Применяется CDM для
типовой модели ЖЦ (имеются все работы/задачи и этапы), а также в проектах с
66
"быстрой разработкой" (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. Для создаваемой системы актуален следующий перечень стадий
реализации проекта
Формирование концепции
Разработка
Реализация
Эксплуатация
Поддержка
Снятие с эксплуатации
Задача внедрения информационной системы включает в себя создание
(адаптацию) и запуск в продуктивную эксплуатацию элементов информационной
67
системы. Так как разработка информационной системы будет осуществляться своими
силами, то и внедрение будет происходить без привлечения посторонних
специалистов.
В качестве стратегии внедрения выбираем стратегию Скачек.
Этап внедрения планируется разбить на следующие подэтапы:
1. Предпроектное обследование. В ходе обследования выявляются основные
информационные потоки на предприятии и сверяется база основной нормативно
справочной документации. Главным требованием в данном случае является наличие
всех необходимых для функционирования корпоративных информационных систем
справочников и классификаторов и соответствие принципових организации
требованиям системы. В ходе выполнения этапа обязательно должны быть
проанализированы на полноту корпоративные стандарты учета и отчетности. На
данном этапе также производится диагностирование проблем, которые могут
возникнуть при внедрении, разрабатывается и согласовывается настройка
справочников и классификаторов системы в соответствии с сформулированными
требованиями. При необходимости, принимаются решения об изменении
существующих практик учета или функциональных моделей. По результатам этапа
формируется подписываемый всеми участниками проекта внедрения документ,
который описывает все выявленные проблемы и намечает пути их ликвидации.
2. Построение информационно—функциональной модели деятельности
предприятия, описание и оптимизация процессов, подвергающихся автоматизации.
Моделирование должно проводиться хорошо обученными сотрудниками
рассматриваемого предприятия с привлечением высококвалифицированных
консультантов и с привязкой созданной модели к стандартам бизнеса и к будущей
системе.
3. Адаптация ИС на предприятии. В ходе этапа производится настройка системы
тестирование отдельных модулей и функций группой внедрения. На данном этапе
также очень важно наличие корпоративных стандартов, так как именно они являются
основой настроек системы.
4. Опытная эксплуатация информационной системы. Осуществляется для
тестирования полного соответствия функциональности, полученной в результате
настройки системы, требованиям предприятия. На этом этапе сохраняется двойной
68
ввод данных в старую и новую системы. В ходе опытной эксплуатации: генерируются
стандартные отчеты помощью ИС и обычными способами) и производится
верификация данных; система постепенно вводится в эксплуатацию, по отдельным
участкам учета; документируются инструкции по ведению рабочих мест и
корректируются должностные инструкции участников учетного процесса. В
отдельных подразделениях предприятия в систему вводятся фактические данные
ограниченном объеме) и последовательно тестируются бизнес—функции путем
моделирования реальных ситуаций деятельности предприятия условиях,
максимально приближенных к действительности). Отрабатывается взаимная работа
подразделений на основе тестовых пилотных примеров. Конечные пользователи
(сотрудники отдела ИТ) обучаются работе с настроенной системой непосредственно
на своих рабочих местах. После обучения конечных пользователей отрабатывается
интегрированный пилотный пример и полностью моделируется деятельность
предприятия. На основе результатов выполнения пилотного примера руководством
предприятия принимается решение о переводе ИС в промышленную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное использование
информационной системы для выполнения ею тех функций, для которых она
предназначена.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две группы:
плановые и неплановые.
К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
окончательная донастройка.
Данные работы будут выполнять специалисты сектора программирования.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
69
Проект создания ИС, как и все остальные проекты по созданию ПО, включает
множество неопределенных моментов, которые могут повлечь за собой риски срыва
реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер, которые
позволят либо 100% предотвратить их возникновение, либо значительно уменьшат
последствия.
Сегодня существует три общепринятых стратегии управления рисками:
Избегание рисков проект строится так, чтобы исключить возможность
появления любого риска;
Делегирование рисков проект строится так, чтобы передать все риски
третьей стороне (инвесторам, банкам, заказчикам и т.п.);
Принятие рисков риски считаются неизбежной составляющей проекта,
реализуется постоянный мониторинг симптомов их проявления, часто дорабатывается
план действий в случае возникновения рисков.
Модно рассмотреть две базовые категории рисков прямые и косвенные. На
прямые риски проектная команда еще как-то можно повлиять, а вот косвенные риски
нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений, точно ли
проведена оценка затрат и т.п.);
Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что случится, если
ключевые поставщики в силах будут выполнить свои обязательства и т.п.);
2) Технические риски:
Источник: https://baza.diplomsite.ru/previewfile/14204