65
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор этапов,
работ и операций в порядке их реализации и взаимосвязях, определяющих
ведение работ от составления технического задания до финальных испытаний
ряда версий и завершения эксплуатации ПС или ИС. Подобные стандарты
состоят из правил описания начальной информации, методики выполнения
операций, осуществляют контроль технологических процессов и правил
представления их результатов. Еще они определяют содержание
технологических и эксплуатационных документов на комплексы ПО. Они
выражают организационную структуру коллектива, поддерживают
распределение и планирование заданий, реализуют контроль над этапами
разработки комплекса ПС.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, включающий в себя большинство автоматизированных
систем (АС) и ПС, где ПС – малая часть всего плана работ. Международный
стандарт ISO/IEC 12207 показывает стратегию и общий порядок в разработке и
использовании ПО, он охватывает ЖЦ ПО от зарождения идей до окончания
цикла. Определение стандарта: система — это совокупность одного или более
процессов, аппаратных средств, ПО, оборудования и людей для реализации
возможности удовлетворения конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и
покупатель (клиент). Применяется в разных случаях, даже когда обе стороны
внутри одной компании. В отличии от CDM, стандарт ISO состоит из более
крупных обобщенных процессов: «покупка», «доставка», «создание» и т.п.
Любой процесс разделен на набор действий, а каждое действие — на
совокупность задач. Важно одно отличие ISO: любой процесс, действие или
66
задача определяется и реализуется другим процессом по мере необходимости,
причем нет ранее заданных последовательностей (конечно, в рамках
сохранения логики связей по начальным сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в
случае необходимости вызывает другой или его часть. Стандарт отражает
архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также указывает
список необходимых работ и подробно описывает содержание каждой из них.
Архитектура ЖЦ ПС в стандарте основывается на 3 основных компонентах:
Покупка или поставка,
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но не
углубляется в детали реализации или выполнения услуги и задачи, включенных
в процессы. Стандарт не указывает конкретную модель ЖЦ или метод создания
ПО, но показывает, что стороны участники использования стандарта несут
ответственность за выбор модели ЖЦ для проекта ПО, за подгонку процессов и
задач стандарта к этой модели, за обоснованный выбор и использование
методов создания ПО, за реализацию действий и задач, уместных для проекта
ПО.
Покупка или поставка. Цель этапа – предложение разработчику от
заказчика, на выполнение автоматизированной системы. На этом этапе
заключается договор, корректируются его условия и требования. Участники
этапа – ответственный от лица заказчика, который контролирует и уточняет
направления для разработчиков. А так же менеджер проекта от лица
разработчиков. Он принимает от заказчика требования, подписывает договор, и
согласует начальные установки и задачи для работы. На этом этапе заказчик
67
должен предоставить развернутое техническое задание (ТЗ), менеджер
утверждает его, уточняются некоторые детали задания и согласовываются
средние сроки выполнения разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика, и в
договоренные сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки
ПС на вышеперечисленные этапы, следит за их выполнением, контролирует
ход выполнения за каждым разработчиком. При необходимости сам участвует в
разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в
зависимости от квалификации и опыта, определяет степень универсальности
взаимодействия отдельных частей ПС, разрешает коллизии и спорные
моменты.
Разработчики принимают план работ, поле деятельности и конкретные
задачи для выполнения. Определяют для себя методы решения своих задач,
68
согласовывают пути взаимодействия с программными частями других
разработчиков, спецификации функций, протоколов передачи данных, и др.
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность работы
всех компонентов. При выявлении недоработок определяются перечень
указаний для исправлений разработчиками.
Есть несколько вариантов внедрения системы
Стратегия “Параллельное использование” – предполагает параллельно
выполнять старые и новые технология решения задачи, затем сравнить итоги.
Если итоги согласуются длительное время, то происходит переход на новую
технологию.
Преимущества:
– Малый риск ошибок в рамках новой технологии;
– Контроль внедрения ИС реализуется независимо от классического
планирования компании.
Недостатки:
– Нагрузка персонала в 2 раза больше;
– Большие мощности серверов;
– Постоянная сверка итогов работы двух технологий.
Стратегия “Скачек” – когда старая технология работает до какого-то
момента, а потом сразу делается переход на новую технологию, и по факту
внедрения применяется только новая технология.
Преимущества:
– Очень короткое время переходного периода;
– Отсутствие двойных затрат на деятельность компании;
– Обновленные процессы оптимальные из-за отсутствия переходного
периода.
Недостатки:
69
– Повышенный риск несоблюдения уровня качества ИС требованиям
компании;
– Повышенные требования к процессу планирования перехода на
обновленную технологию.
Стратегия “Пилотный проект” – является тактикой скачка, применяемой
к лимитированному числу процессов, областью использования становится
малый участок.
Преимущества:
– Малый риск выбора ложного решения, которое не приведет к простою
компании;
– Доступность корректировки технологии в рамках внедрения ИС на
участке;
– Нет двойных затрат сразу на 2 технологии.
Недостатки:
– Трудность объединения с информационными потоками,
составленными по старой и новой технологии;
– Важность установки старой и новой ИС сразу.
Стратегия “Узкое место” – является автоматизацией малой части
производства, выбираемой по параметрам эффективности, приводящей к
увеличению качества реализации процессов на конкретном участке.
Преимущества:
– По факту автоматизации узкого места есть возможность закончить
автоматизацию;
– Малые требования к уровню планирования работ установки.
Недостатки:
– Полный цикл планирования по каждому из узких мест;
– Независимость автоматизации узких мест приводит к созданию
избыточного множества решений.
70
По итогу, в условиях минимального бюджета и начальной стадии
автоматизации будет правильно использовать стратегию «Узкое место».
Введение ИС инвентаризационного учета ИТ-активов обеспечит
уменьшение управленческих и накладных расходов, обеспечит
автоматизированный безошибочный учет всех ИТ-активов организации, их
распределение и перемещение, даст возможность формирования достоверной и
полной информации обо всех проводимых с материальными ценностями
операциях.
Систему необходимо реализовать как многопользовательскую.
Одновременно с системой могут работать несколько человек, причем
разграничение прав доступа должно быть настроено таким образом, что
пользователь может работать только в рамках дозволенных ему полномочий.
Разрабатываемая система должна позволять выполнять следующие
функции:
Регистрация ИТ-активов по приходным накладным.
Инвентаризация ИТ-активов и ввод их в эксплуатацию.
Учет выдачи ценностей со склада.
Учет наличия ИТ-активов на складе.
Формирование документов, соответствующих описанным выше
хозяйственным операциям, а именно: приходной накладной, договора на
продажу, накладной, отчета по наличию, отчета по перемещению за период.
Создаваемая система должна соответствовать следующим критериям:
– Масштабируемость. Начало использования системы в компании
изначально возможно на одном рабочем месте с последующим увеличением
рабочих мест по мере необходимости без потерь уже занесённых в БД данных;
– Корпоративность. Предоставление доступа пользователю к внутренним
функциям системы при наличии у него необходимых полномочий;
71
– Управляемость. В случае возникновения необходимости в изменении
деятельности учреждения перенастройка системы не должна приводить к
остановке в ее работе;
– Защищенность. Реализация разграниченного доступа к БД системы по
правам пользователей.
Созданная система должна работать стабильно и при возникновении
критических ошибок, даже тех, которые получаются по вине пользователя из-за
неверно введенных данных. Соответственно, секции ПО, в которых может
появится такая ошибка, должны быть устроены в программе особым образом.
При возникновении ошибки программа просто выдает предупреждение и
продолжает свою работу.
Программа должна поддерживать физическую и логическую целостность
БД. В случае удаления или изменения данных программа должна
контролировать ссылочную целостность данных в БД.
Задачей выпускной квалификационной работы является разработка ИС
инвентаризационного учета ИТ-активов.
2.3 Выбор средств разработки для системы инвентаризационного учета
Инструментарий современных реляционных систем управления базами
данных постоянно совершенствуется и развивается, появляются новые сервисы.
Сейчас реляционная модель данных становится базовой при построении
БД. Это получилось из-за того, что организация хранения данных в виде таблиц
логична для пользователя. Эта особенность приводит к множеству
реляционных СУБД. Их параметры значительно разнятся. Подбор самой
адекватной СУБД стал сложной задачей.
Опишем самые распространенные СУБД.
OracleDatabase
72
Объектно-реляционная СУБД. Самая первая версия стала коммерческой
СУБД, поддерживающей SQL-язык. Сейчас доступно 6 версий СУБД:
– EnterpriseEdition: Полноценная версия без ограничений. Эта
корпоративная редакция продукта нужна для крупных предприятий.
Пользователям даются опции, которые помогают архитектурно и
функционально оптимизировать сервер;
– StandardEdition: Есть ограничение по числу процессорных разъемов
(не более 4-х). Редакция нужна для применения в компании среднего размера
или в отделе крупной компании;
– StandardEditionOne: Есть ограничение по числу процессорных
разъемов (не более 2-х). Также нет поддержки кластеризации;
– PersonalEdition: Версия рассчитана на однопользовательский
режим;
– Lite: Версия используется в мобильных и встраиваемых
устройствах. Также часто применяемся в малый предприятиях;
– ExpressEdition (XE): Доступная СУБД. Используется 1 процессор,
есть ограничения по объему ОЗУ (1 Гб) и объему БД (11 Гб) [13].
Все эти 6 версий СУБД имеют идентичный исходный код и аналогичный
функционал, исключая отдельные узконаправленные методики конкретных
версий. Главная задача стандартной, персональной и мобильной версий -
понижение стоимости владения, легкость использования ПО.
OracleDatabase считается кроссплатформенным ПО. Это реализовано
благодаря тому, что около 80 % программного кода написано на языке Си. А
ядро сервера, которое имеет остальные 20 % кода, переделывается под
необходимую платформу, поскольку создано на машинно-зависимых языках
[14].
MicrosoftAccess
73
Реляционная СУБД, созданная Microsoft. Имеет встроенный
VisualBasicforApplications (VBA), позволяющий создавать приложения в Access
для работы с БД. Понимо VBA в приложении применяется язык
структурированных запросов SQL и макрокоманды [15].
MS Access считается файл-серверным СУБД, что уменьшает круг её
использования. В роли движка Бд стоит AccessDatabaseEngine или MicrosoftJet
4.0 в зависимости от ревизии СУБД [1]. MS Access может совмещаться с
внешними СУБД клиент-серверной архитектуры, например, с MySQL, Firebird,
Oracle и др. Устойчив к сбоям в электропитании благодаря автоматическому
резервированию после перехода к следующей записи. Программный комплекс
лучше всего применять после приобретения лицензии, хотя есть версии,
доступные открыто.
Проект MS Access сохранен в файле формата accdb, упрощая тем самым
его передачу и работу с программой. Различные конструкторы помогают
взаимодействовать с данной СУБД персоналу, которые имеют недостаточный
уровень знаний. Плюсом такой настольной СУБД становятся
русифицированный интерфейс и хорошая СЗИ.
MS SQL Server
Первая версия СУБД стала совместной работой фирм Sybase, Ashton-Tate
и Microsoft [16]. MS SQL Server принадлежит к СУБД клиент-серверной
архитектуры. Есть огромное число версий и обновлений. Финальные версии По
уже включают компонент ядра СУБД (DatabaseEngine); набор технологий для
репликации с БД, службы для работы с данными - предоставление отчетов,
анализ данных и т. п. [17].
Microsoft SQL ServerExpressEdition — это версия продукта,
уменьшенного по функционалу, но находящаяся в открытом доступе [18]. Эта
версия применима лишь в рамках малой компании в силу уменьшенных
74
возможностей по сравнению с MS SQL Server. Языком просмотра выступает
процедурное расширение языка SQL — Transact-SQL.
Microsoft SQL Server совместим с БД других форматов, к примеру: Oracle,
DB2, Sybase и MicrosoftAccess [19]. Эта СУБД имеет простой доступ
пользователей к анизучаемой информации, что реализовано методов
объединения с пакетом программ MicrosoftOffice. Также имеется возможность
шифровать БД, файлы журналов или файлы данных, тем самым реализуя
дополнительную защиту данных.
Sybase A daptive Server Enterprise
РеляционнаяСУБД, созданафирмой SAP [20]. Сначала была разработан
вместесMicrosoft SQL Server, и потому тоже применяет Transact- SQL как
базовый язык запросов. Является СУБД клиент-серверной архитектуры.
Используется в системах масштаба среднего или большого предприятий.
Определяется удобством использования и минимальной ценой для сегмента
рынка СУБД, поддерживающих большие БД. Применяется при необходимости
взаимодействия с большим числом пользователей, большими объемами данных
для очень важных объектов. Также данная СУБД не зависит от ПО других
производителей.
SAP SybaseAdaptiveServerEnterpriseClusterEdition — версия СУБД,
имеющая усиленную отказоустойчивость, обеспечиваемую благодаря
разбиению на кластеры и перевода пользователей с отказавшего узла кластера
на рабочий [21]. При сбое в процессе реализации транзакции операция
выполнится повторно по факту перехода на рабочий узел.
5ЛИНТЕР
СУБД нашего производства, созданная научно-производственным
предприятием РЕЛЭК (Реляционные экспертные системы). Считается
кроссплатформенным ПО, поддерживающим почти все ОС. Базовым
направлениями использования становятся гос. проекты, встроенные системы и