57
каждого этапа работ, требования к информационным системам "заморожены" в
виде технического задания на все время ее создания. Таким образом, пользователи
могут внести свои замечания только после того, как работа над системой будет
полностью завершена. В случае неточного изложения требований или их
изменения в течение длительного периода создания программного обеспечения,
пользователи получают систему, не удовлетворяющую их потребностям. Модели
(как функциональные, так и информационные) автоматизируемого объекта могут
устареть одновременно с их утверждением. Сущность системного подхода к
разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые
функции: система разбивается на функциональные подсистемы, которые в свою
очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс
разбиения продолжается вплоть до конкретных процедур. При этом
автоматизируемая система сохраняет целостное представление, в котором все
составляющие компоненты взаимоувязаны. Таким образом, данная модель
основным достоинством имеет системность разработки, а основные недостатки -
медленно и дорого.
Спиральная модель: Для преодоления перечисленных проблем была
предложена спиральная модель жизненного цикла (рис. 3), делающая упор на
начальные этапы жизненного цикла: анализ и проектирование. На этих этапах
реализуемость технических решений проверяется путем создания прототипов.
Каждый виток спирали соответствует созданию фрагмента или версии
программного обеспечения, на нем уточняются цели и характеристики
проекта, определяется его качество и планируются работы следующего витка
спирали. Таким образом, углубляются и последовательно конкретизируются
детали проекта и в результате выбирается обоснованный вариант, который
доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный
цикл создания системы. Неполное завершение работ на каждом этапе позволяет
переходить на следующий этап, не дожидаясь полного завершения
работы на текущем. При итеративном способе разработки недостающую работу
можно будет выполнить на следующей итерации. Главная же задача - как можно
58
быстрее показать пользователям системы работоспособный продукт, тем самым,
активизируя процесс уточнения и дополнения требований [10, стр. 72] .
Основная проблема спирального цикла - определение момента перехода
на следующий этап. Для ее решения необходимо ввести временные ограничения
на каждый из этапов жизненного цикла. Переход осуществляется в соответствии
с планом, даже если не вся запланированная работа закончена. План составляется
на основе статистических данных, полученных в предыдущих проектах, и
личного опыта разработчиков. На рисунке 2.3 представлено графическое
изображение спиральной модели жизненного цикла ИС.
Рис. 2.3 Спиральная модель ЖЦ ИС
Наиболее оптимальным вариантом является спиральная модель, так как в
ней были учтены все недостатки каскадной и задачной модели. В рамках
доработки уже существующей ИС частенько возникают новые замечания от
пользователей которые можно реализовать на новом витке спиральное модели.
Для реализации модуля, автоматизирующего работу по учету труда и
заработной платы на частном унитарном предприятии «Тимурспец» выбрана
стратегия жизненного цикла программного обеспечения – каскадная модель. В
каскадной модели планирование тестирования и испытаний производится на
ранних стадиях разработки программного средства, упрощена оценка
промежуточных результатов разработки, облегчен процесс управления и
контроля за ходом разработки.
59
В соответствии с СТБ ИСО/МЭК 12207–2003 все модели жизненного
цикла программного обеспечения содержат процессы: основные,
вспомогательные, организационные [4].
К основным процессам жизненного цикла программного обеспечения
относятся:
• анализ;
• проектирование;
• реализация;
• внедрение;
• сопровождение.
Цель этапа «Анализ» - формирование технического задания. Этап
разбивается на подэтапы, задачи которых: определений требований к ИС,
определение функций ИС и стратегий автоматизации, обоснование проектных
решений по техническому, информационному и программному обеспечению.
Результативная информация - это документация по техническому заданию.
Информация для анализа берется из интернета и отдела планирования.
Цель этапа «Проектирование» - разработка проекта автоматизации и
разработка информационного обеспечения задачи. Разработка проекта
автоматизации включает в себя разработку плана-графика, архитектуры проекта,
анализ рисков, а также оценку стоимости проекта. Разработка информационного
обеспечения задачи включает в себя разработку информационного модели,
классификаторов и прототипов экранных форм. Результативная информация - это
проектная документация.
Цель этапа «Реализация» - разработка программного обеспечения ИС.
Этап включает в себя подготовку к разработке ПО и разработку ПО.
Результативная информация - это документация по ПО.
Цель этапа «Внедрение» включает в себя установку элементов ПО ИС и
технического обеспечения, а также их тестирование и устранение выявленных
ошибок. Этап разбивается на два подэтапа: создание среду функционирования ИС
и тестирование ИС.
60
Цель этапа «Сопровождение» - мониторинг и доработка программного и
технического обеспечения ИС в процессе эксплуатации, а также работа с
пользователями [4].
К вспомогательным процессам цикла программного обеспечения
относятся:
1. Документирование
2. Управление конфигурацией
3. Обеспечение качества
4. Верификация
5. Аттестация
6. Совместный анализ
7. Аудит
8. Решения проблем
К организационным процессам жизненного цикла программного
обеспечения относятся
1. Управление
2. Создание инфраструктуры
3. Процесс усовершенствования
4. Процесс обучения
Процесс разработки состоит следующих этапов, выполняемых
разработчиком. Описание каждого этапа применительно к разрабатываемому
модулю, автоматизирующего процесс ведения документации и отчетности на
частном унитарном предприятии «Тимурспец», отражено в таблице 2.1.
Таблица 2.1
Описание этапов жизненного цикла разрабатываемого модуля
Наименование
этапа
Описание этапа
1
2
Подготовка
процесса
разработки
Выбрана модель жизненного цикла программного
средства. Приняты решения о применяемых методах,
инструментальных средства разработки и языках
программирования.
61
Продолжение таблицы 2.1
1
2
Анализ требований
к системе
Определены общая, техническая и программная
архитектуры проекта. Проанализировано назначение
программного средства и, на основании выполненного
анализа, уточнены требования к нему. Также на данном
этапе оговорены планы сборки и квалификационных
испытаний системы.
Проектирование
программных
средств
Требования к программному средству преобразованы в
его архитектуру, осуществлено детальное
проектирование программного средства. Произведено
распределение технических требований к компонентам
между программными модулями.
Программирование
и тестирование
программных
средств
Осуществляется кодирование и тестирование
программных модулей, а также оценка полученных
результатов
Сборка и
квалификационные
испытания
программных
средств
Осуществлена сборка программных модулей,
технической конфигурации, и ручных операций в
единую подсистему. Проведено тестирование и оценка
качества собранной подсистемы с моделируемыми
исходными данными.
Ввод в действие и
обеспечение
приемки
программных
средств
Разработанный проект введен в действие в среде
эксплуатации, проведено заказчиком приемочных
испытаний с целью проверки пользователем
соответствия системы исходным требованиям.
Эксплуатация и
сопровождение
определяются недоработки и согласованность работы
всех компонентов. При выявлении недоработок
определяются перечень указаний для исправлений
разработчиком
62
Разработка модуля автоматизации процесса ведения документации и
отчетности на частном унитарном предприятии «Тимурспец» предполагает
первоначальный анализ существующих решений на предприятии и выборе
стратегий внедрения.
Существуют следующие основные стратегии внедрения системы:
1. Параллельная стратегия - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
2. «Скачок». Эта стратегия привлекательна, но не рекомендуется.
3. «Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проекта» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня.
4. «Узкое место» - это малая часть производственного процесса. При
использовании похода «узкое место» план внедрения выполняется только для
«узкого места» и для людей, работающих в нем. Точность данных повышается
только для изделий в этом "узком месте"; переподготовка - только для людей,
работающих в нем; анализ эффекта затрат делается только для него и т.д. [19, стр.
72].
Для реализации модуля по автоматизации процесса ведения
документации и отчетности на частном унитарном предприятии «Тимурспец»
наиболее подходящей стратегией внедрения является стратегия параллельного
внедрения. Разрабатываемое программное средство является дополнением к уже
существующему на частном унитарном предприятии «Тимурспец»
информационному обеспечению и входит в состав большого функционального
блока, выполняемого бухгалтером, реализуемого не только при помощи
компьютерной техники.
63
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Разработка модуля по автоматизации процесса ведения документации и
отчетности на частном унитарном предприятии «Тимурспец» может быть связана
с возможными рисками, возникающими на различных этапах жизненного цикла.
Основные риски, возникающие на этапах жизненного цикла
программного обеспечения:
• выявление и анализ требований;
• проектирование программного обеспечения;
• программирование;
• тестирование программного обеспечения.
Выявление и анализ требований. Выявление и анализ требований играют
важную роль в успехе проекта разработки программного обеспечения, так как
большая часть ошибок происходит на ранних стадиях разработки.
Это связано с природой разработки программного обеспечения: выполняемая
работа базируется на ранее выполненной. Например, проектирование
выполняется на основе требований, программирование реализуется на основе
модели проектирования, а тестирование производится на основе написанного
текста программы.
Первый вариант двусмысленности заключается в том, что пользователь
может интерпретировать одно и то же требование по-разному.
Второй вариант состоит в том, что у нескольких читателей возникает
разное понимание того, что означает требование.
Проектирование. Риски, возникающие на этапе проектирования, играют
важную роль в процессе разработки программного обеспечения и требуют
особого внимания, так как основные технические вопросы решаются именно на
этом этапе.
1. Сложность архитектуры программного обеспечения
Архитекторы программного обеспечения не всегда придерживаются
правила «Не порождайте сущностей сверх необходимого». Но ведь именно
простота, понятность и единая концептуальная целостность обеспечивают
эффективную реализацию системы.
64
2. Неудобный пользовательский интерфейс
Разработка пользовательского интерфейса является частью любого
проекта, связанного с созданием программного обеспечения. Интерфейс
пользователя является точкой взаимодействия человека и программы, зачастую
имеющей сложную функциональность. Именно через интерфейс пользователь
судит о программе в целом; более того, часто решение об использовании
программного обеспечения пользователь принимает по тому, насколько ему
удобен и понятен пользовательский интерфейс. Следовательно, от того насколько
удобным будет разработанный интерфейс пользователя будет зависеть и успех
продукта.
3. Неправильная структура базы данных
При разработке программного обеспечения проектирование базы данных
требует особого внимания и ответственности, так как стоимость допущенных на
этом этапе ошибок особенно велика. Проблемы, которые могут произойти на
этапе проектирования базы данных:
• некорректность схемы базы данных по отношению к предметной
области;
• несоответствие аппаратным ограничениям;
• сложность и неудобная работа с базой данных;
• невозможность к поддержке и сопровождению.
4. Неоптимальный выбор структур данных. Структуры данных влияют на
эффективность алгоритмов и, следовательно, на производительность
программного обеспечения.
5. Неоптимальный выбор языка программирования. При разработке
программного обеспечения имеется огромный выбор языков программирования,
в лабиринтах которых можно легко заблудиться. Для того чтобы выбор языка
программирования оказал благоприятное влияние на реализацию системы,
необходимо учитывать следующие факторы:
• целевая платформа;
• гибкость языка;
• время реализации;
• производительность;
65
• сопровождение программного обеспечения;
• предметная область разрабатываемой системы;
• необходимость в использовании библиотек;
• опыт разработчиков.
Программирование. Основные риски на этапе программирования описаны
ниже.
1. Изобретение «велосипеда». Написание кода без использования
возможностей языка и существующих библиотек.
2. Нечитаемый код. Последствие данного риска – трудность в изменении
и сопровождении программного обеспечения.
3. Создание программных закладок. Программная закладка – это
внесенные в программное обеспечение функциональные объекты, которые при
определенных условиях (входных данных) инициируют выполнение не
описанных в документации функций, позволяющих осуществлять
несанкционированные воздействия на информацию.
На этапе разработки программистам достаточно легко внедрить в код системы
программную закладку. В настоящее время известно 30 публичных случаев
обнаружения программных закладок. В большинстве случаев закладки успешно
использовались злоумышленниками и были обнаружены уже после активации.
4. Нерегулярное резервное копирование кода. Последствие данного риска
достаточно масштабно.
Тестирование. На этапе тестирования возможны следующие риски:
• неэффективный выбор методов тестирования;
• требования не ранжированы по приоритетам;
• не используются протоколы тестирования [9. стр. 46].
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Предприятие ЧУП «Тимурспец» как и большинство современных
предприятий не может обойтись без создания надежной системы защиты
информации. Такая система защиты информации включает в себя не только
организационно-правовые, но и технические средства обеспечения
66
информационной безопасности. Мероприятия по защите информации являются
составной частью управленческой, производственной и коммерческой
деятельности предприятия ЧУП «Тимурспец».
Отделы ЧУП «Тимурспец» оснащены техническими средствами.
Характеристики технической архитектуры предприятия ЧУП «Тимурспец»
отражены на рисунке 1.2. При работе с техническими средствами возникают
угрозы, которые возникают в виду случайных, преднамеренных или естественных
событий. При возникновении угрозы увеличивается шанс получения ущерба
программному или аппаратному обеспечению предприятия ЧУП «Тимурспец».
В результате автоматизации процесса ведения документации и отчётности
в ЧУП «Тимурспец» предполагается защита информации как от угроз,
обусловленных преднамеренными, так и случайными действиями. Так для
сохранения конфиденциальности, защиты от угрозы вывода системы из строя,
нарушения доступности информации, сбоях и отказа работы аппаратного
обеспечения, на предприятии ЧУП «Тимурспец» организованы следующие меры
безопасности:
• Нормативно-правовые акты предприятия
• Должностные инструкции
• Антивирусные средства
• Настройка компьютерных систем и сетей в соответствии с
требованиями безопасности
• Защита от сбоев сети (источники бесперебойного питания)
В результате автоматизации процесса ведения документации и отчётности
в ЧУП «Тимурспец» предполагается защита информации также от внутренних
угроз, а именно защита информации в процессе использования разрабатываемой
подсистемы. В рамках организации информационной безопасности при
использовании программы планируется разграничить доступ к данным паролями.
Разграничение прав пользователей представлено в таблице 2.2.