42
Рисунок 7 – Декомпозиция процесса учета выдачи ИТ-активов
Характеристика процесса формирования отчетов приведена на Рисунке
8.
43
Рисунок 8 – Декомпозиция процесса формирования отчетов
В результате деятельности лиц формируются следующие документы:
Накладная на выдачу ИТ-активов со склада;
Накладная на получение ИТ-активов со склада;
Журнал актов списания ИТ-активов;
Журнал движения ИТ-активов.
2.2 Выбор стандарта разработки информационной системы и
описание ее функциональности
Жизненный цикл программного обеспечения (ПО) определяет период
времени, наступающий с момента принятия решения о важности разработки
44
ПО и оканчивающийся в момент его фактического изъятия из пользования.
Этот цикл — процесс создания и эволюции ПО.
Понятие ЖЦ ПО пришло тогда, когда разработчики осознали важность
перехода от единоличных кустарных методов разработки программ к
технологичному промышленному их созданию. И зачастую в подобных
ситуациях многие пытаются перенести в свою сферу опыт их других
направлений производства. Таким образом было перенято понятие ЖЦ.
Главные этапы ЖЦ ПО:
Исследование требований,
Построение макета,
Программирование,
Отладка и исправление ошибок,
Внедрение и использование.
Нюансом разработки ПО становится принятие решений на первичных
этапах с их реализацией на заключительных этапах. Ошибки в требованиях к
ПО могут привести не только к потерям в процессе создания и использования,
но и к полному провалу проекта. Корректировка и изменения в спецификациях
ПО зачастую влечет за собой повторение всех следующих этапов построения
модели и реализации ПО.
Сам ЖЦ ПО является непрерывным процессом, начинающимся в
момент принятия решения о важности его создания и оканчивающимся в
момент его окончательного выведения из эксплуатации.
Главный нормативный документ, контролирующий ЖЦ ПО –
международный стандарт ISO/IEC 12207 (ISO, International Organization of
Standardization – Общемировая компания по стандартизации, IEC, International
Electrotechnical Commission – Международная коллегия по электротехнике).
Он отражает структуру ЖЦ, включающую в себя процессы, действия и задачи,
реализуемые за время разработки ПО.
45
Исходя их этого стандарта, структура ЖЦ ПО основана на 3 группах
процессов:
Рисунок 9 - Структура ЖЦ ПО
Любой такой процесс определяется некоторыми задачами и методами их
решения, начальными данными, приобретенными на предыдущем этапе, и
результатами. Итогами анализа, у примеру, становятся функциональные и
информационные модели, а также соответствующие им диаграммы. ЖЦ ПО
носит итерационный характер: итоги прошедшего этапа влекут изменения в
проектных решениях, основанных на более ранних этапах.
ЖЦ информационных продуктов и услуг является базой для ЖЦ
информационных технологий и, конечно, самих ИС. Следовательно, всё
вышесказанное можно отнести и к ИС.
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО.
Модель жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач в
46
рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и трудности
проекта и конкретных условий, в которых система развивается и работает.
Сегодня наибольшее распространение получили три базовые модели
ЖЦ:
Задачная модель;
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор
этапов, работ и операций в порядке их реализации и взаимосвязях,
определяющих ведение работ от составления технического задания до
финальных испытаний ряда версий и завершения эксплуатации ПС или ИС.
Подобные стандарты состоят из правил описания начальной информации,
методики выполнения операций, осуществляют контроль технологических
процессов и правил представления их результатов. Еще они определяют
содержание технологических и эксплуатационных документов на комплексы
ПО. Они выражают организационную структуру коллектива, поддерживают
распределение и планирование заданий, реализуют контроль над этапами
разработки комплекса ПС.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, включающий в себя большинство автоматизированных
систем (АС) и ПС, где ПС – малая часть всего плана работ. Международный
стандарт ISO/IEC 12207 показывает стратегию и общий порядок в разработке
и использовании ПО, он охватывает ЖЦ ПО от зарождения идей до окончания
цикла. Определение стандарта: система — это совокупность одного или более
процессов, аппаратных средств, ПО, оборудования и людей для реализации
возможности удовлетворения конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и
47
покупатель (клиент). Применяется в разных случаях, даже когда обе стороны
внутри одной компании. В отличии от CDM, стандарт ISO состоит из более
крупных обобщенных процессов: «покупка», «доставка», «создание» и т.п.
Любой процесс разделен на набор действий, а каждое действие — на
совокупность задач. Важно одно отличие ISO: любой процесс, действие или
задача определяется и реализуется другим процессом по мере необходимости,
причем нет ранее заданных последовательностей (конечно, в рамках
сохранения логики связей по начальным сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в
случае необходимости вызывает другой или его часть. Стандарт отражает
архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также указывает
список необходимых работ и подробно описывает содержание каждой из них.
Архитектура ЖЦ ПС в стандарте основывается на 3 основных компонентах:
Покупка или поставка,
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но
не углубляется в детали реализации или выполнения услуги и задачи,
включенных в процессы. Стандарт не указывает конкретную модель ЖЦ или
метод создания ПО, но показывает, что стороны участники использования
стандарта несут ответственность за выбор модели ЖЦ для проекта ПО, за
подгонку процессов и задач стандарта к этой модели, за обоснованный выбор
и использование методов создания ПО, за реализацию действий и задач,
уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от
заказчика, на выполнение автоматизированной системы. На этом этапе
48
заключается договор, корректируются его условия и требования. Участники
этапа – ответственный от лица заказчика, который контролирует и уточняет
направления для разработчиков. А так же менеджер проекта от лица
разработчиков. Он принимает от заказчика требования, подписывает договор,
и согласует начальные установки и задачи для работы. На этом этапе заказчик
должен предоставить развернутое техническое задание (ТЗ), менеджер
утверждает его, уточняются некоторые детали задания и согласовываются
средние сроки выполнения разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика, и в
договоренные сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки
ПС на вышеперечисленные этапы, следит за их выполнением, контролирует
ход выполнения за каждым разработчиком. При необходимости сам участвует
в разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в
зависимости от квалификации и опыта, определяет степень универсальности
49
взаимодействия отдельных частей ПС, разрешает коллизии и спорные
моменты.
Разработчики принимают план работ, поле деятельности и конкретные
задачи для выполнения. Определяют для себя методы решения своих задач,
согласовывают пути взаимодействия с программными частями других
разработчиков, спецификации функций, протоколов передачи данных, и др.
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность работы
всех компонентов. При выявлении недоработок определяются перечень
указаний для исправлений разработчиками.
Есть несколько вариантов внедрения системы
Стратегия “Параллельное использование” – предполагает параллельно
выполнять старые и новые технология решения задачи, затем сравнить итоги.
Если итоги согласуются длительное время, то происходит переход на новую
технологию.
Преимущества:
• Малый риск ошибок в рамках новой технологии;
• Контроль внедрения ИС реализуется независимо от классического
планирования компании.
Недостатки:
• Нагрузка персонала в 2 раза больше;
• Большие мощности серверов;
• Постоянная сверка итогов работы двух технологий.
Стратегия “Скачек” – когда старая технология работает до какого-то
момента, а потом сразу делается переход на новую технологию, и по факту
внедрения применяется только новая технология.
Преимущества:
• Очень короткое время переходного периода;
50
• Отсутствие двойных затрат на деятельность компании;
• Обновленные процессы оптимальные из-за отсутствия
переходного периода.
Недостатки:
• Повышенный риск несоблюдения уровня качества ИС
требованиям компании;
• Повышенные требования к процессу планирования перехода на
обновленную технологию.
Стратегия “Пилотный проект” – является тактикой скачка, применяемой
к лимитированному числу процессов, областью использования становится
малый участок.
Преимущества:
• Малый риск выбора ложного решения, которое не приведет к
простою компании;
• Доступность корректировки технологии в рамках внедрения ИС
на участке;
• Нет двойных затрат сразу на 2 технологии.
Недостатки:
• Трудность объединения с информационными потоками,
составленными по старой и новой технологии;
• Важность установки старой и новой ИС сразу.
Стратегия “Узкое место” – является автоматизацией малой части
производства, выбираемой по параметрам эффективности, приводящей к
увеличению качества реализации процессов на конкретном участке.
Преимущества:
• По факту автоматизации узкого места есть возможность закончить
автоматизацию;
• Малые требования к уровню планирования работ установки.
51
Недостатки:
• Полный цикл планирования по каждому из узких мест;
• Независимость автоматизации узких мест приводит к созданию
избыточного множества решений.
По итогу, в условиях минимального бюджета и начальной стадии
автоматизации будет правильно использовать стратегию «Узкое место».
Введение ИС складского учета ИТ-активов обеспечит уменьшение
управленческих и накладных расходов, обеспечит автоматизированный
безошибочный учет всех ИТ-активов организации, их распределение и
перемещение, даст возможность формирования достоверной и полной
информации обо всех проводимых с материальными ценностями операциях.
Систему необходимо реализовать как многопользовательскую.
Одновременно с системой могут работать несколько человек, причем
разграничение прав доступа должно быть настроено таким образом, что
пользователь может работать только в рамках дозволенных ему полномочий.
Разрабатываемая система должна позволять выполнять следующие
функции:
1. Регистрация ИТ-активов по приходным накладным.
2. Инвентаризация ИТ-активов и ввод их в эксплуатацию.
3. Учет выдачи ценностей со склада.
4. Учет наличия ИТ-активов на складе.
5. Формирование документов, соответствующих описанным выше
хозяйственным операциям, а именно: приходной накладной, договора на
продажу, накладной, отчета по наличию, отчета по перемещению за период.
Создаваемая система должна соответствовать следующим критериям:
• Масштабируемость. Начало использования системы в компании
изначально возможно на одном рабочем месте с последующим увеличением
рабочих мест по мере необходимости без потерь уже занесённых в БД данных;