53
данных при аварийном отключении электропитания персональный компьютер
должен быть оборудован блоком бесперебойного питания.
Источник бесперебойного питания подбирается исходя из мощности,
потребляемой компьютером, а также исходя из требуемого времени работы
компьютера от ИБП. Наиболее характерными значениями являются 600-800 Вт
и 5-10 минут. Под эти параметры подходит ИБП APC Smart-UPS 750VA,
характеристики которого приведены в таблице 10.
Таблица 10 – Технические характеристики ИБП APC Smart-UPS
750VA
Характеристика
Значение
Максимальная выходная мощность
500 Ватт / 750 ВА
Максимальное задаваемое значение мощности
500 Ватт / 750 ВА
Номинальное выходное напряжение
230V
Номинальное входное напряжение
230V
Входная частота )
50/60 Hz +/- 3 Hz (auto
sensing
Тип входного соединения
IEC-320-C14 inlet
Диапазон входного напряжения при работе от сети
160 - 285В
Диапазон регулировки входного напряжения при
работе от сети
151 - 302В
Типовая продолжительность работы в автономном
режиме под половинной нагрузкой
16.4 Минуты (250 Ватт)
Типовая продолжительность работы в автономном
режиме под полной нагрузкой
4.8 Минуты (500 Ватт)
В данном виде информационная система будет готова к внедрению
автоматизированной системы учета заявок клиентов.
54
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Методология проектирования ИС включает в себя описание процесса
создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
отождествляя его с некоторой последовательностью стадий и исполняемых на
них процессов. Для каждой стадии выявляется состав и последовательность
производимых работ, итоговые результаты, методы и средства, нужные для
реализации работ, ответственность и роль участников и т.д. Подобное
формальное описание ЖЦ ИС дает возможность спланировать и подготовить
процесс совместной разработки и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий, случающихся
с системой с момента ее внедрения и до окончания использования.
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из эксплуатации. Модель жизненного цикла представлена некой
структурой, которая содержит процессы, действия и задачи, реализуемые в ходе
создания, работы и сопровождения ПО в течение всей жизни системы, от
выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
Каскадная модель включает в себя последовательную реализацию
всех этапов проекта в заранее определенном порядке. Начало следующего этапа
говорит о полном завершении работ на предыдущем этапе.
Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее взаимовлияние
итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на
весь срок разработки.
55
Спиральная модель. На любом витке спирали выполняется
генерация очередной версии продукта, корректируются требования проекта,
выражается его качество и планируются работы уже следующего витка. Особое
внимание при этом обращается на начальные этапы разработки - анализ и
проектирование, где возможность создания тех или иных технических решений
обосновывается и проверяется благодаря построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с большой
точностью и полнотой составить все требования к системе. Главным
недостатком такого подхода является то, что основной процесс разработки
системы не может полностью уложится в такие жесткие рамки, постоянно есть
потребность в возврате к уже завершенным этапам для уточнения или изменения
ранее принятых решений. В итоге реальный процесс разработки ИС становится
соответствующим поэтапной модели с периодичным контролем.
Все стадии создания системы предусматривают выполнение некоторого
объема работ, представляемых в виде процессов ЖЦ. Процесс выражается как
совокупность объединенных действий, изменяющих входные данные в
выходные. Описание любого процесса состоит из перечня решаемых задач,
исходных данных и итоговых результатов.
Есть целый ряд стандартов, определяющих ЖЦ ПО, а в отдельных случаях
и процессы разработки.
Среди самых известных стандартов выделяют следующие:
ГОСТ 34.601-90 - распространяется на АИС и указывает в себе
стадии и этапы их создания. Также в нем имеется описание содержания работ на
всех этапах. Стадии и этапы работы, отраженные в стандарте, зачастую
соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:1995 - стандарт на процессы и реализацию
жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не имеет
описания стадий, фаз и этапов.
56
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 12207 не содержит подробное
57
описание работ на разных стадиях и этапах разработки АС. Стандарт CDM
рассчитан на использование в проектах с применением Oracle технологий,
который в данном проекте не используются. Стандарт MSF, как было ранее
сказано, в большей степени ориентирован на разработку бизнес-приложений.
Первый этап включает исследование проблемной области, подготовку
требований заказчика. Итогом данного этапа считается ТЗ, утвержденное с
каждой заинтересованной стороной.
В рамках второго этапа, исходя из ТЗ, создаются требуемые проектные
решения. По итогу получается готовый комплект проектный документов [42].
Третий этап включает создание проекта, к примеру: подготовка ПО исходя
из решений по проекту завершенного этапа. Методы создания тут не так важны.
Итогом реализованного этапа выступает полноценное и готовое ПО.
Четвертый этап включает проверку созданного ПО на соответствие всем
указанным в ТЗ требованиям заказчика. Реальная эксплуатация может показать
скрытые или неявные ошибки и проблемы, которые всплывают лишь в процессе
реальной работы АИС.
Пятый этап – это сдача всего проекта, и тут основным является процесс
представления продукта заказчику так, чтобы он понял, что все реализовано на
100%.
Основные плюсы каскадной модели:
Каждый этап включает совокупность документов по проекту,
которые отвечают требованиям полноценности и законченности. На итоговых
этапах создается инструкция для пользователя, описывающая все включенные
стандартами виды обеспечения АИС (ПО, ИО, ТО и т. д.);
Очередность реализации этапов работ помогает лучше
распланировать сроки окончания и возможные затраты.
Минусы каскадной модели:
Есть задержки в рамках выявления контрольных результатов;
58
Недоработки и нюансы на любом из этапов становятся известны,
зачастую, на следующих этапах работ, что ведет к неизбежному возврату;
Трудности параллельного ведения всей деятельности.
ЖЦ итерационной модели разделен на итерации, любая из которых
становится проектом в миниатюре, поскольку имеет все этапы создания ПО
(подготовка требований, выделение спецификаций, реализацию, проверку и
внедрение). Но в границе единой итерации готовиться не весь проект, а лишь
отдельная его версия (часть).
Задача любой такой итерации – получить версию ПО, которая состоит из
обновленных возможностей, созданных в рамках имеющихся итераций, и
функциональности всех пройденных итераций. Итогом конечной итерации
становится требуемая функциональность разработки. Сроки и затраты, которые
нужны для реализации итоговой версии, зачастую изначально не
устанавливаются, поскольку не отражается совокупный объем работ и
требования готовятся по ходу реализации [4].
Позитивные нюансы итерационной модели заключаются в том, что
корректировки между этапами дают меньшую трудоемкость реализации в
отличии от каскадной модели.
Негативными факторами итерационной модели можно назвать:
Длительность прохождения каждого этапа равно длительности всей
разработки;
Множество итераций часто ведет к не состыковкам в процессе
внедрения проектных решений и изготовления документации;
Сложность архитектуры;
Трудности использования документов по проекту в процессе
установки и использования считаются причинами переделки системы с нуля [5].
Спиральная модель, как и итерационная, имеет похожий процесс
реализации АИС. Но в данном случае очень важно выполнение стартовых этапов
59
– изучения и проектирования, где проводится обоснование и проверка
применимости технических решений методом создания прототипа.
Каждая итерация – это конечный цикл реализации, ведущий к выпуску
некой версии продукта, обновляемого от итерации к итерации, чтобы по итогу
стать конечной системой, как показано на рис. 4.
Преимущества спиральной модели ЖЦ:
Активное изучение рисков, ведущее к минимизации и раннему
выявлению сложных рисков;
Деление объемных работ в рамках реализации проекта на
относительно малые части;
Последовательная реализации базовых функций с максимальным
уровнем риска, что поможет при желании стазу завершить работы над проектом
на начальной стадии и уменьшить расходы;
Актуальность гибкого проектирования, основанная на
преимуществах каскадной модели при параллельной реализации итераций;
Использование сильных сторон инкрементной модели (передача
инкрементов, минимизация графика работ, повышение стабильности ресурсов
при росте системы);
Частая связь с пользователем на стартовых этапах модели, что
помогает создать требуемый продукт хорошего качества;
Возможность оценивания системы пользователем на стартовых
этапах, благодаря использованию ЖЦ реализации оперативного
прототипирования;
Участие пользователей в процессах планирования, изучения рисков,
разработки, внедрении, оценивании;
Улучшение административного контроля процессами материальных
и денежных затрат, контроль кадров и графика работ, что обычно реализуется
проведением анализа по итогу любой итерации;
60
Повышение результативности благодаря использованию
подходящих для повторного использования итогов;
Повышение возможности угадывания поведения системы из-за
уточнения описанных ранее целей;
Выполнение оценки общих затрат, что ведет к их коллективной
минимизации.
Негативные моменты спиральной модели ЖЦ:
Высокая стоимость модели из-за сторонних затрат времени на
планирование, определение целей, составление анализа рисков и построение
прототипа при выполнении цикла по спирали;
Большая стоимость модели для проектов, имеющих минимальные
риски или малые размеры;
Сложность модельной структуры, ведущая к усложнению ее
использования заказчиками, разработчиками и менеджерами;
Требование специализированных знаний для проведения оценки
рисков;
Изменение сроков завершения работ над проектом из-за пожеланий
заказчика изменять любую созданную версию;
Четкая поставка работ между разработчиками;
Сложность определения параметров для выполнения процесса
реализации на дальнейшей итерации;
Применение лишь мощных средств и методов прототипирования.
Для разработки системы автоматизации обработки и учета заявок клиентов
выбираем каскадную модель жизненного цикла в соответствии с ГОСТ 34.601-
90.
61
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект создания ИС взаимоотношений с клиентами, как и все остальные
проекты по созданию ПО, включает множество неопределенных моментов,
которые могут повлечь за собой риски срыва реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо значительно
уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Можно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот
косвенные риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений,
точно ли проведена оценка затрат и т.п.);
Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
62
Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что
случится, если ключевые поставщики в силах будут выполнить свои
обязательства и т.п.);
2) Технические риски:
Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 11).