Номинальное выходное напряжение
230V
Номинальное входное напряжение
230V
Входная частота )
50/60 Hz +/- 3 Hz (auto sensing
Тип входного соединения
IEC-320-C14 inlet
Диапазон входного напряжения при
работе от сети
160 - 285В
Диапазон регулировки входного
напряжения при работе от сети
151 - 302В
Типовая продолжительность работы в
автономном режиме под половинной
нагрузкой
16.4 Минуты (250 Ватт)
Типовая продолжительность работы в
автономном режиме под полной
нагрузкой
4.8 Минуты (500 Ватт)
В данном виде информационная система будет готова к внедрению ИС
учета ремонта компьютерного оборудования.
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Процессы жизненного цикла проекта автоматизации
Методология проектирования информационных систем описывает
процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
представляя его как некоторую последовательность стадий и выполняемых на
них процессов. Для каждого этапа определяются состав и последовательность
выполняемых работ, получаемые результаты, методы и средства, необходимые
для выполнения работ, роли и ответственность участников и т.д. Такое
формальное описание ЖЦ ИС позволяет спланировать и организовать процесс
коллективной разработки и обеспечить управление этим процессом.
Жизненный цикл ИС можно представить как ряд событий, происходящих
с системой в процессе ее создания и использования.
Жизненный цикл ИС можно представить как ряд событий, происходящих
с системой в процессе ее создания и использования. Модель жизненного цикла
отражает различные состояния системы, начиная с момента возникновения
необходимости в данной ИС и заканчивая моментом ее полного выхода из
употребления. Модель жизненного цикла - структура, содержащая процессы,
действия и задачи, которые осуществляются в ходе разработки,
функционирования и сопровождения программного продукта в течение всей
жизни системы, от определения требований до завершения ее использования.
В настоящее время известны и используются следующие модели
жизненного цикла:
Каскадная модель (Рис. 2.1) предусматривает последовательное
выполнение всех этапов проекта в строго фиксированном порядке. Переход на
следующий этап означает полное завершение работ на предыдущем этапе.
Поэтапная модель с промежуточным контролем (Рис. 2.2).
Разработка ИС ведется итерациями с циклами обратной связи между этапами.
Межэтапные корректировки позволяют учитывать реально существующее
взаимовлияние результатов разработки на различных этапах; время жизни
каждого из этапов растягивается на весь период разработки.
Спиральная модель (Рис. 2.3). На каждом цикле выполняется
создание очередной версии продукта, уточняются требования проекта,
определяется его качество и планируются работы следующего цикла. Особое
внимание уделяется начальным этапам разработки - анализу и проектированию,
где реализуемость тех или иных технических решений проверяется и
обосновывается посредством создания прототипов (макетирования).
Разработка требований
Проектирование
Реализация
Тестирование
Ввод в действие
Рис. 2.1 Каскадная модель ЖЦ ИС
Разработка требований
Проектирование
Реализация
Тестирование
Ввод в действие
Рис. 2.2 Поэтапная модель с промежуточным контролем
Проектирование
Реализация
Тестирование
Версия 1
Версия 2
Версия 3
Разработка
требований
Ввод в действие
прототипов системы
Рис. 2.3 Спиральная модель ЖЦ ИС
В ранних проектах достаточно простых ИС каждое приложение
представляло собой единый, функционально и информационно независимый
блок. Для разработки такого типа приложений эффективным оказался каскадный
способ. Каждый этап завершался после полного выполнения и документального
оформления всех предусмотренных работ.
Каскадный подход неплохо зарекомендовал себя при создании
относительно простых ИС, когда в самом начале проекта можно очень точно и
емко сформулировать нужные требования к системе. Главным недостатком
такого подходя можно назвать то, что процесс реального создания системы не
может полностью уложится в такую жесткую схему, постоянно есть потребность
в возвращении к предыдущим этапам и просмотре или изменении ранее
принятых решений. В итоге реальный процесс разработки ИС оказывается
похож на поэтапную модель с промежуточным контролем.
Выделяют следующие положительные стороны использования каскадного
подхода:
• Каждый этап включает в себя законченный набор проектной
документации, отвечающий критериям согласованности и полноты;
• Реализуемые в логической последовательности работы дают
возможность планировать сроки завершения всех работ и подсчитывать затраты.
Цикличная модель ЖЦ создавалась для преодоления вышеперечисленных
проблем. На этапах анализа и проектирования степень создания технических
решений и удовлетворенность потребностей заказчика оценивалась методикой
создания прототипов. Каждый цикл характеризовал создание работоспособного
фрагмента или версии программы. Такой подход позволял уточнить требования,
цели и параметры проекта, оценить качество разработки, выделить работы
следующего цикла. Таким образом, углубляются и оговариваются детали
проекта, и в результате применяется обоснованный вариант, удовлетворяющий
всем требованиям заказчика, который затем уже доводится до финальной
реализации.
Но и такая схема не дает возможности оперативно учитывать
возникающие доработки и изменения требований к системе. Согласование
параметров разработки с пользователями делается только в отдельных точках,
планируемых после завершения некоторого объема работ, а общие требования к
ИС отражены в техническом задании на все время ее создания. Поэтому
пользователи часто получают систему, которая не полностью удовлетворяет их
реальным потребностям.
Итеративная разработка показывает объективно существующий цикл
разработки сложных систем. Она дает возможность переходить на следующий
этап, не дожидаясь окончательного завершения работы на текущем этапе и
решить главную задачу – оперативное и быстрее представить пользователям
работоспособный продукт, тем самым, заранее начиная процесс уточнения
корректировки требований.
Главная проблема спирального цикла в определении момента перехода на
другой этап. Для ее решения внедряются временные ограничения на все этапы
жизненного цикла, и переход производится в соответствии с планом, даже если
работы по прошлому этапу еще не завершены. Планирование производится на
базе статистических сведений, полученных при подготовке других проектов, а
также из личного опыта разработчиков.
Распространены несколько стандартов, описывающих жизненный цикл
информационной системы:
ГОСТ 34.601-90 – стандарт распространяется на
автоматизированные системы, используемые в различных видах деятельности
(исследование, проектирование, управление и т.п.), включая их сочетания,
создаваемые в организациях. Стандарт устанавливает стадии и этапы создания
автоматизированной системы.
ISO 12207 – стандарт применяется при приобретении систем,
программных продуктов и оказании соответствующих услуг (внедрение,
сопровождение). А также при поставке, разработке, эксплуатации и
сопровождении программных продуктов и программных компонентов
программно-аппаратных средств как в самой организации, так и вне нее.
ISO 15288 – стандарт обеспечивает общие основы процессов,
составляющих жизненной цикл систем, созданных человеком. Этот жизненный
цикл охватывает концепции идей вплоть до снятия системы с эксплуатации. Он
обеспечивает процессы для приобретения и поставки системы.
RUP (Rational Unified Process – рациональный унифицированный
процесс) – это методология разработки программного обеспечения, созданная и
распространяемая корпорацией Rational Software (www.rational.com). Она
описывает упорядоченный подход к распределению задач и обязанностей в
организации-разработчике [12].
XP (eXtreme Programming) – методология содержит совершенно
иные базовые принципы, нежели RUP. Основными чертами являются
определение точных кратковременных планов (как правило, недельных),
постоянное перепланирование, тесное общение с заказчиком. Эта методология
больше подходит для полуисследовательских и инновационных проектов [13].
MSF (Microsoft Solutions Framework – методология создания
программных решений) – В модели процессов приводится общее описание
организации работ над проектом по разработке и внедрению ИТ-решений.
Предлагаемая схема достаточно гибка и может применяться к самым разным
проектам в области информационных технологий. В версии 3.1 концепция была
расширена и теперь охватывает практически весь цикл создания решений –
начиная с их обсуждения и заканчивая внедрением [11].
COBIT (Control Objectives for Information and Related Technology –
цели контроля для информационных и смежных технологий) – основная идея
стандарта COBIT выражается следующим образом: все ресурсы
информационной системы должны управляться набором естественно
сгруппированных процессов для обеспечения компании необходимой и
надежной информацией [14].
Oracle CDM (Custom Development Method – методика разработки
ИС под заказ) – позволяет стандартизировать процесс создания приложений.
CDM охватывает полный жизненный цикл разработки приложений, описывая
последовательность и взаимную зависимость задач, решаемых в процессе
разработки.
1 Для разработки системы управленческого учета будем использовать
стандарт ГОСТ Р 12207-2010, как наиболее подходящий для данного случая.
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть
до приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается
с подписания договора на поставку системы, продолжается определением
процедур и ресурсов, необходимых для обеспечения выполнения проекта. И
заканчивается поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс
включает в себя работы по анализу требований, проектированию,
программированию, сборке, тестированию и вводу в действия программного
продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе
его использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
Для рассматриваемого в данном дипломном проекте наиболее подходит
спиральная модель жизненного цикла информационной системы, так как:
Разработка имеет небольшой объем;
Требования к системе формализованы;
Изменения функциональности не планируются.
В качестве стратегии внедрения ИС был выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также
определить и спланировать организационные и технические мероприятия на
этапе промышленного внедрения. Пилотный проект позволяет уменьшить
затраты и ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Любой сложный проект, а особенно проект разработки программного
обеспечения, содержит в себе много неопределенных моментов, которые влекут
за собой риски реализации проекта.
Управление рисками заключается в их раннем выявлении и разработке
мер либо полностью предотвращающих их возникновение, либо
минимизирующих их последствия.
В настоящее время существует три общепринятых стратегии управления
рисками:
Избегание рисков – проект реорганизуется таким образом, чтобы
исключить возможность возникновения рисков;
Делегирование рисков – проект реорганизуется таким образом,
чтобы переложить риски на третью сторону (заказчика, банки, вендора и т.п.);
Принятие рисков – риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае наступления
рисков.
Различают две основные категории рисков – прямые и опосредованные.
На прямые риски проектная команда может каким-то образом повлиять, а
опосредованные риски команда контролировать не может в принципе.
Риски можно разделить на отдельные основные виды.
Ресурсные риски:
• Организация (делала ли организация ранее проекты такого
масштаба, есть ли формальный процесс создания ПО и т.п.);
• Инвестиции (достаточно ли денежных средств для развития
проекта, указана ли стоимость проекта или она еще находится в процессе
обсуждения, верно ли проведена оценка затрат и т.п.);