57
Скорость печати: 16 страниц в минуту (А4)/9 страниц в минуту (А3)
Разрешение: 600х600 dpi
Габариты (ШхВхГ): 595 x 528 x 532 мм
Вес: 33 кг
Скорость печати в формате A4: 16 страниц в минуту
Скорость печати в формате A3: 9 страниц в минуту.
Для обеспечения сохранности данных при аварийном отключении
электропитания персональный компьютер должен быть оборудован блоком
бесперебойного питания. Рекомендуется использовать следующую модель - Smart-
UPS 1000 VA USB & Serial:
Максимальная выходная мощность - 670 Ватт / 1000 ВА
Максимальное задаваемое значение мощности - 670 Ватт / 1000 ВА
Номинальное выходное напряжение - 230V
Искажения формы выходного напряжения - Less than 5% at full load
Выходная частота (синхронизированная с электросетью) - 47 —
53 Hz for 50 Hz nominal,57 — 63 Hz for 60 Hz nominal
Пик-фактор - up to 5 : 1
Тип формы напряжения - Sine wave
Выходные соединения - (8) IEC 320 C13 , (2) IEC Jumpers
Данное устройство позволяет обеспечит ь бесперебойную работу 8
устройств (компьютеров, МФУ и т. д.).
Компьютеры организации, приобретать не придется, поскольку на данный
момент они уже присутствуют в организации и отвечают предъявленным
требованиям.
58
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл программного обеспечения (ПО) определяет период
времени, наступающий с момента принятия решения о важности разработки ПО и
оканчивающийся в момент его фактического изъятия из пользования. Этот цикл —
процесс создания и эволюции ПО.
Понятие ЖЦ ПО пришло тогда, когда разработчики осознали важность
перехода от единоличных кустарных методов разработки программ к
технологичному промышленному их созданию. И зачастую в подобных ситуациях
многие пытаются перенести в свою сферу опыт их других направлений
производства. Таким образом было перенято понятие ЖЦ.
Главные этапы ЖЦ ПО:
Исследование требований,
Построение макета,
Программирование,
Отладка и исправление ошибок,
Внедрение и использование.
Нюансом разработки ПО становится принятие решений на первичных этапах
с их реализацией на заключительных этапах. Ошибки в требованиях к ПО могут
привести не только к потерям в процессе создания и использования, но и к
полному провалу проекта. Корректировка и изменения в спецификациях ПО
зачастую влечет за собой повторение всех следующих этапов построения модели и
реализации ПО.
Сам ЖЦ ПО является непрерывным процессом, начинающимся в момент
принятия решения о важности его создания и оканчивающимся в момент его
окончательного выведения из эксплуатации.
Главный нормативный документ, контролирующий ЖЦ ПО –
международный стандарт ISO/IEC 12207 (ISO, International Organization of
Standardization – Общемировая компания по стандартизации, IEC, International
59
Electrotechnical Commission – Международная коллегия по электротехнике). Он
отражает структуру ЖЦ, включающую в себя процессы, действия и задачи,
реализуемые за время разработки ПО.
Исходя их этого стандарта, структура ЖЦ ПО основана на 3 группах
процессов:
Рисунок 2.1 Процессы ЖЦ ПО
Любой такой процесс определяется некоторыми задачами и методами их
решения, начальными данными, приобретенными на предыдущем этапе, и
результатами. Итогами анализа, у примеру, становятся функциональные и
информационные модели, а также соответствующие им диаграммы. ЖЦ ПО носит
итерационный характер: итоги прошедшего этапа влекут изменения в проектных
решениях, основанных на более ранних этапах.
ЖЦ информационных продуктов и услуг является базой для ЖЦ
информационных технологий и, конечно, самих ИС. Следовательно, всѐ
вышесказанное можно отнести и к ИС.
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО.
Модель жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач в
рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и трудности
проекта и конкретных условий, в которых система развивается и работает.
60
Сегодня наибольшее распространение получили три базовые модели ЖЦ:
Задачная модель;
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор этапов,
работ и операций в порядке их реализации и взаимосвязях, определяющих ведение
работ от составления технического задания до финальных испытаний ряда версий
и завершения эксплуатации ПС или ИС. Подобные стандарты состоят из правил
описания начальной информации, методики выполнения операций, осуществляют
контроль технологических процессов и правил представления их результатов. Еще
они определяют содержание технологических и эксплуатационных документов на
комплексы ПО. Они выражают организационную структуру коллектива,
поддерживают распределение и планирование заданий, реализуют контроль над
этапами разработки комплекса ПС.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, включающий в себя большинство автоматизированных систем
(АС) и ПС, где ПС – малая часть всего плана работ. Международный стандарт
ISO/IEC 12207 показывает стратегию и общий порядок в разработке и
использовании ПО, он охватывает ЖЦ ПО от зарождения идей до окончания цикла.
Определение стандарта: система — это совокупность одного или более процессов,
аппаратных средств, ПО, оборудования и людей для реализации возможности
удовлетворения конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и покупатель
(клиент). Применяется в разных случаях, даже когда обе стороны внутри одной
компании. В отличии от CDM, стандарт ISO состоит из более крупных
обобщенных процессов: «покупка», «доставка», «создание» и т.п. Любой процесс
разделен на набор действий, а каждое действие — на совокупность задач. Важно
одно отличие ISO: любой процесс, действие или задача определяется и реализуется
другим процессом по мере необходимости, причем нет ранее заданных
61
последовательностей (конечно, в рамках сохранения логики связей по начальным
сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в случае
необходимости вызывает другой или его часть. Стандарт отражает архитектуру,
процессы, разделы и подразделы ЖЦ ПС, а также указывает список необходимых
работ и подробно описывает содержание каждой из них. Архитектура ЖЦ ПС в
стандарте основывается на 3 основных компонентах:
Покупка или поставка,
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но не
углубляется в детали реализации или выполнения услуги и задачи, включенных в
процессы. Стандарт не указывает конкретную модель ЖЦ или метод создания ПО,
но показывает, что стороны участники использования стандарта несут
ответственность за выбор модели ЖЦ для проекта ПО, за подгонку процессов и
задач стандарта к этой модели, за обоснованный выбор и использование методов
создания ПО, за реализацию действий и задач, уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от заказчика,
на выполнение автоматизированной системы. На этом этапе заключается договор,
корректируются его условия и требования. Участники этапа – ответственный от
лица заказчика, который контролирует и уточняет направления для разработчиков.
А так же менеджер проекта от лица разработчиков. Он принимает от заказчика
требования, подписывает договор, и согласует начальные установки и задачи для
работы. На этом этапе заказчик должен предоставить развернутое техническое
задание (ТЗ), менеджер утверждает его, уточняются некоторые детали задания и
согласовываются средние сроки выполнения разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика, и в
договоренные сроки:
62
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки ПС на
вышеперечисленные этапы, следит за их выполнением, контролирует ход
выполнения за каждым разработчиком. При необходимости сам участвует в
разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в зависимости от
квалификации и опыта, определяет степень универсальности взаимодействия
отдельных частей ПС, разрешает коллизии и спорные моменты.
Разработчики принимают план работ, поле деятельности и конкретные
задачи для выполнения. Определяют для себя методы решения своих задач,
согласовывают пути взаимодействия с программными частями других
разработчиков, спецификации функций, протоколов передачи данных, и др.
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность работы
всех компонентов. При выявлении недоработок определяются перечень указаний
для исправлений разработчиками.
Существуют следующие основные стратегии внедрения системы:
1) Стратегия ―Параллельное использование‖. Параллельное использование -
параллельно исполняются новая и старая технология решения задачи, их
результаты сравнивают. Если результаты согласуются продолжительное время, то
осуществляется переход на более соверешенную технологию.
63
Плюсы:
- минимальный риск возникновения ошибок в виде новых технологий;
- управления внедрением ИС может осуществлять в стороне от обычного
операционного планирования компании.
Минусы:
- удвоенная загрузка персонала;
- потребности в удвоенных мощностях серверов;
- нужда в постоянной сверки результатов работы двух технологий.
2) Стратегия ―Скачек‖. Скачек – не новая технология которая работает до
определенного момента, затем осуществляется внедрение новой технологии, а
после внедрения применяется только новая технология
Плюсы:
- меньше времени длительности переходного периода;
- нет двойных затрат на деятельность компании;
- новые процессы являются наиболее оптимальными в виду отсутствия
переходного периода.
Минусы:
- высокие риски несоответствия качества ИС требованиям компании;
- высокие требования к процессу проектирования перехода на другую
технологию;
3) Стратегия ―Пилотный проект‖. Пилотный проект - тактика скачка которая
применяется к определенному числу процессов, границы применения обычно
являются небольшые участоки.
Плюсы:
- минимальный риск выбора плохого решения, которое не приводит к
длительному простою всего предприятия;
- возможность изменения планируемой технологии в процессе внедрения
ИС на участке;
- отсутствие 2х затрат на реализацию технологии.
Минусы:
64
- сложность интеграции информационных потоков формируемых по старой
и новой технологии;
- необходимость управления старой и новой ИС одновременно.
4) Стратегия ―Узкое место‖. Узкое место - автоматизация малой части
производственного процесса, который обычно выбирается по критериям, их
эффективности приводящих к повышению качества реализации процессов только в
определенном узком месте.
Плюсы:
- после автоматизации каждого узкого места имеется возможность прервать
автоматизацию;
- минимальные требования к уровню планирования работ внедрения.
Минусы:
- выполнение полного цикла планирования на каждом из узких мест - ввиду
возможности прерывания автоматизации процесс может, не закончится некогда;
- независимость автоматизации узких мест может привести к формированию
избыточного множества программно аппаратных решений.
Таким образом, в условиях ограниченного бюджета и начальной стадии
автоматизации логичным будет выбрать стратегию внедрения «Узкое место».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
задачи разработки ИС управления персоналом. Риском является возможность
появления обстоятельств, обусловливающих неуверенность или невозможность
получения ожидаемых результатов от реализации поставленной цели, нанесение
материального ущерба, опасность валютных потерь и др. Существуют следующие
типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
65
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих большой
опыт работы в соответствующей области и при этом взаимозаменяемых на
сотрудников, не менее соответствующих данным характеристикам (таблица 2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных дефектов и ошибок
программного средства и
документации
Формирование
требований
Разработка требований
к ПО
Дефекты исходных требований
заказчика
Проектирование
Планирование работ
Дефекты, обусловленные реальной
сложностью проекта
Проектирование
архитектуры системы
Ошибки планирования и системного
проектирования программного
средства
Детальное
проектирование ПО
Системные и алгоритмические
дефекты и ошибки проекта
Реализация
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов
программного средства
Тестирование
Тестирование ПО
Программные и алгоритмические
ошибки программного средства и
документации
Ввод в действие
Разработка
документации
Дефекты и ошибки обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
66
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
программ и данных (авторизации пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов системы
или ошибочных действий пользователей. Основными источниками отказовых
ситуаций могут быть некорректные исходные требования, сбои и отказы в
аппаратуре, дефекты или ошибки в программах и данных функциональных задач,
проявляющиеся при их исполнении в соответствии с назначением. При таких
воздействиях внешняя, функциональная работоспособность систем может
разрушаться не полностью, однако невозможно полноценное выполнение заданных
функций и требований к качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
На стадии доработки могут возникнуть следующие риски:
• увеличение нагрузки на персонал - несогласованность действий
персонала исполнителя и сотрудников предметных областей;
• трудности с обучением персонала заказчика из-за нежелания работать
с новой системой;
• отсутствие поддержки внедрения ИС со стороны отдельных ключевых
участников проекта;
• неучастие руководителей в проекте.
Для минимизации указанных рисков необходимо принимать следующие
меры:
• проведение обучения персонала работы с системой;
• доведение до персонала смысла внедрения автоматизированной
системы;