48
инструментарий технологии программирования (инструментальные
средства для разработки ПО).
Системное ПО направлено:
на создание операционной среды функционирования других
программ;
обеспечение надежной и эффективной работы самого компьютера и
вычислительной сети;
проведение диагностики и профилактики аппаратуры компьютера и
вычислительных сетей;
выполнение вспомогательных технологических процессов
(копирование, архивация, восстановление файлов программ и БД и т. п.).
Системное ПО (System Software) — совокупность программ и
программных комплексов для обеспечения работы компьютера и
вычислительных сетей.
Прикладное ПО служит программным инструментарием решения
функциональных задач и является самым многочисленным классом ПО. В
данный класс входят программные продукты, выполняющие обработку
информации различных предметных областей. Таким образом, прикладное
ПО — комплекс взаимосвязанных программ для решения задач
определенного класса предметной области.
Инструментарий технологии программирования обеспечивает процесс
разработки программ и включает специализированное ПО, которое является
инструментальным средством разработки. ПО данного класса поддерживает
все технологические этапы процесса проектирования, программирования,
отладки и тестирования создаваемых программ. Пользователями данного ПО
являются системные и прикладные программисты.
Для разрабатываемого программного приложения характерны
следующие требования к операционной системе, которые приведены в
таблице 10.
49
Таблица 5.
Требования программного обеспечения.
Тонкий клиент и толстый клиент
Операционная система
Примечание
Microsoft Windows
Windows 10
Со всеми установленными обновлениями
Windows 8.1
Windows 8
Windows 7
Windows
Server 2016
(x64)
Windows
Server 2012
R2 (x64-bit)
Windows
Server 2012
(x64)
Windows
Server 2008
R2 (x64)
Windows
Server 2008
Windows
Server 2003
Windows Vista
Исходя из таблицы 10 при использовании программного продукта
выбор операционной системы не повлияет на работоспособность и
функционал системы, так как разработка конфигурации видеться на
платформе 1С, которая адаптирована под многие операционные системы.
Для реализации проекта была выбрана система Windows 10,
поскольку она является наиболее популярной операционной системой на
сегодняшний день. Она обеспечивает стабильность работы, интуитивный
интерфейс, целостность данных, а также не менее важным показателем
является обновление операционной системы, так как это будет отражаться на
дальнейшей работе предприятия
50
1.4.3 Обоснование проектных решений по техническому
обеспечению
Техническое обеспечение – представляет собой взаимосвязанный
технический комплекс для сбора, передачи, предоставления, хранения и
обработки информации.
Рассмотрим структуру технического обеспечения информациоееых
систем автоматизации (табл.11).
Таблица 11.
Структура технического обеспечения.
№
п/п
Группа технического
обеспечения
Наименование технического обеспечения
1
Базовое
1) Микропроцессор.
2) Постоянная ("вшитая") память – ПЗУ.
3) Оперативная ("адресуемая пользователем")
память – ОЗУ.
4) Регистровая память (аппаратная кэш-
память).
5) Видеопамять (часто интегрируется в блоке
микропроцессора).
6) Блок питания (энергетический блок).
Периферийное
1) Устройства ввода (клавиатура, мышь,
трекбол, сканер, дигитайзер, джойстик и
др.).
2) Устройства вывода (дисплей, принтер,
плоттер и др.).
3) Устройства (накопители) внешней памяти
(дискета, СD, оптический накопитель и
др.).
4) Устройства согласования других устройств
и сетевые [u3](модем и др.).
Специализированное
устройства, используемые для решения
уникальных проблем
При выборе персонального компьютера необходимо руководствоваться
следующими критериями: надежность, производительность, стоимость,
простота эксплуатации, возможность модернизации в процессе
использования. К наиболее важным критериям при приобретении
технических средств являются:
тактовая частота процессора;
51
количество ядер;
объем оперативной памяти и её производительность;
скорость записи и чтения жесткого диска;
диагональ монитора и его разрешение.
В зависимости от технических средств находится возможность
использования конкретного программного обеспечения, определяющая
качество функционирования применяемой информационной системы
автоматизации работы предприятия.
Для стабильной работы предприятие обеспечено бесперебойными
блоками питания. В настоящее время ООО «Алькор» имеет в распоряжении
современные компьютеры и многофункциональное устройство, на которых
работают генеральный директор и мастер. При этом многофункциональное
устройство выполняет функции копирования и печати документов, а также
их сканирования. Это позволяет сделать вывод о том, что технические
средства подходят по всем требованиям.
Следовательно, дополнительных вложений и затрат при внедрении
системы не потребуется.
52
ГЛАВА 2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Цель: выбрать определенный стандарт и модель жизненного цикла для
разработки и внедрения программного продукта., а также указать ключевых
участников, требования к выходной информации и получаемый результат.
Жизненный цикл системы — это стадии процесса, охватывающие
различные состояния системы, начиная с момента возникновения
необходимости в такой системе и заканчивая её полным выводом из
эксплуатации. Под термином «жизненный цикл системы» обычно понимают
эволюцию новой системы в виде нескольких ступеней, включающих такие
важные стадии, как концепция, разработка, производство, эксплуатация и
окончательное выведение из эксплуатации.
На сегодняшний день проекты по разработке программного
обеспечения (ПО) нуждаются в грамотном управлении требованиями, потому
что с помощью четко сформулированных требований от заказчика можно
получить наглядное представление о выпускаемом продукте, т. е. от
полноценного сбора требований зависит качественное описание предметной
области и предложенные технические решения.
Управление требованиями к ПО – это процесс, который включает
идентификацию, выявление потребностей, документирование концепции,
анализ требований, отслеживание ошибок, изменение требований.
Основными этапами выработки требований являются:
- подготовка требований – это документирование жизненного цикла
(ЖЦ) требований при разработке ПО;
- управление требованиями – это базовая версия управления
требованиями, которая подразумевает собой набор функциональных
требований, которые разработчики выполнят в определенной итерации
программы.
53
Основная причина, по которой проваливаются проекты, связана с
управлением требований от заказчика, прежде всего это неполнота
требований, которая в свою очередь влияет на результат работы, на
тестирование программы и, как результат, приводит к дополнительным
затратам со стороны заказчика.
Этапы управления требованиями включают в себя:
документирование проекта: описание концепции проекта, цели,
способов решения, функциональных требований заказчика, составление
технического задания;
контроль над статусом требований;
изменение требований по результатам тестирования ПО на стороне
заказчика.
Шаблон состава требований содержит информацию о дате создания,
номере версии ПО, авторе требований (аналитик), заказчике требований,
техническом задании (далее – ТЗ).
Требования от заказчика собираются с помощью интервью
посредством задавания вопросов по требованиям. Также необходимо
детальное изучение цепочки бизнес-процессов и понимание того, в чем
заключается ожидаемый заказчиком результат. Следует провести мозговой
штурм с разработчиками ПО и получить информацию о возможности
реализации нескольких вариантов, сроках выполнения разработки. Далее
производится окончательное согласование требований с заказчиком. От
данного этапа зависит рентабельность проекта в целом, и тогда можно
сделать вывод, будет ли он успешным.
Ниже приведена более детальная характеристика происходящих
бизнес-процессов (табл. 12).
Таблица 12.
54
Характеристика бизнес-процессов ЖЦ ПО.
№
Входные значения
Функция
Выходные
значения
1
Требования
заказчика
Анализ. Аналитик собирает данные
у заказчика
Сбор требований
2
Сбор требований
Проектирование ПО. На основе
полученного сбора требований
аналитик формирует техническое
задание
Техническое
задание
3
Техническое
задание
Кодирование. Аналитик передает
ТЗ на разработку ПО программисту
Готовая
программа
4
Готовая
программа
Тестирование. Программист пишет
программный код и производит
первоначальную внутреннюю
проверку выходных данных ПО,
далее отдает ПО на тестирование
тестировщику
Результат
тестирования
5
Результат
тестирования
Внедрение. Сотрудники отдела
внедрения получают ПО для
внедрения на стороне заказчика
Отчет о внедрении
программы
6
Отчет о внедрении
программы
Тестирование на стороне
заказчика. После этапа внедрения
ПО у заказчика пользователи также
тестируют полученную программу
Отчет о
тестировании на
стороне заказчика
В связи с тем, что в настоящее время всё больше различных областей
жизни человека цифровизируются, и программное обеспечение,
используемое в этих областях, очень сложное, необходимо задумываться, как
более эффективно выстроить процесс разработки. Существует несколько
моделей жизненного цикла, каждая из которых определяет различную
методологию создания систем, тем не менее все без исключения модели
жизненного цикла включают в себя пять этапов и связей между ними с
детальным описанием действий, моделей и результатов каждого этапа.
Процесс разработки может включать в себя несколько этапов жизненного
цикла ПО и регламентируется ГОСТ 34 и ГОСТ 19. Приведем названия и
краткое содержание каждого этапа в соответствии с ГОСТ 19.102-77.
1. Техническое задание:
постановка задачи;
выбор критериев эффективности;
проведение предварительных научно-исследовательских
55
работ (НИР);
разработка ТЗ.
2. Эскизный проект:
структура входных и выходных данных;
уточнение методов решения;
общий алгоритм;
разработка документации эскизного проекта.
3. Технический проект:
уточнение структуры входных и выходных данных;
разработка алгоритмов;
формы данных;
семантика и синтаксис языка;
структура программы;
конфигурация технических средств;
план работ.
4. Рабочий проект:
программирование и отладка;
разработка документов;
подготовка и проведение испытаний;
корректировка программы и документов по итогам испытаний.
5. Внедрение:
передача программы и документов для сопровождения;
оформление акта;
передача в Фонд алгоритмов и программ (ФАП).
В минимальный набор входит: техническое задание, эскизный проект,
технический проект, рабочий проект, внедрение. Также разработка ПО
происходит по различным моделям и методологиям. Основными из этих
моделей являются:
1. Каскадная модель (Водопад/waterfall).
56
2. V-модель.
3. Инкрементная модель (IncrementalModel).
4. Итерационная модель (IterativeModel).
5. Спиральная модель(SpiralModel).
Рассмотрим эти модели подробнее.
Каскадная модель (рис.8) является самой первой моделью разработки
ПО.
Рисунок 2. Каскадная модель.
В ней разработка выполняется последовательно.
Сначала анализ, далее проектирование, после разработка и
тестирование, в конце – выпуск. Каждый этап проходит только один раз, при
этом нельзя менять последовательность действий и приступать к следующей
фазе до завершения выполнения предыдущей.
Преимуществами данной модели являются:
1) сроки разработки чётко фиксируются и должны быть выполнены в
срок;
2) надежность при решении определенных задач;
57
3) Стоимость разработки фиксированная, и если произошли какие-
либо задержки, их никто оплачивать не буде.т
К недостаткам данной модели относятся:
1) Необходимо заранее знать все требования и параметры
создаваемого ПО. После начала разработки их изменять нельзя;
2) если возникают непредвиденные проблемы, то срок выпуска ПО
может быть нарушен;
3) при длительной работе возникает сложность в работе из-за
изменений требований к системе
Сегодня такая модель разработки ещё используется, но редко. В
нынешних условиях рынка не каждый может себе позволить долго ждать,
пока весь продукт будет завершён, при этом не имея возможности изменения
требования. В основном эта модель используется в небольших проектах, где
все требования заранее определены.
V–модель (рис.9) является модификацией каскадной модели, с большей
ориентацией на тестирование, которое можно выполнять после каждого
этапа разработки, в остальном это та же каскадная модель.
Рисунок 9. V-образная модель проектирования.