59
• Модель не предотвращает возникновение итераций между фазами,
часто встречающиеся в процессе создания ПО, т.к. сама модель разрабатывается
согласно обычному циклу аппаратного инжиниринга;
• Модель не показывает главное свойство создания ПО, направленное
на решение задач. Отдельные фазы жестко связаны с конкретными действиями,
что входит в разрез с реальной работой персонала или коллективов;
• Модель создает ошибочное впечатление о работе над проектом.
Понятие типа "25% выполнено" не имеет никакого смысла и не может являться
показателем для менеджера проекта.
Ввиду недостатков каскадной модели ее использование ограничено
ситуациями, в которых требования и их реализация максимально четко
прописаны и понятны.
Каскадная модель замечательно функционирует при ее использовании в
циклах разработки ПО, в которых применяется неизменяемое определение
продукта и четко понятны технические методики.
V-образная модель создается для поддержки работающей над проектом
команды в планировании с реализацией дальнейшей возможности проверки
системы. В этой модели главное значение придается действиям, направленным
на подтверждение и проверку продукта. Она отражает, что проверка продукта
обсуждается, конкретизируется и планируется еще на ранних стадиях ЖЦ
разработки. План приемки продукта заказчиком пишется на этапе планирования,
а само испытание системы - на фазах разработки и анализа проекта и т.д. Такой
процесс создания планов испытания выделен пунктирной линией между
прямоугольниками V-образной модели
В процессе применения V-образной модели при создании проекта, для
которого она оптимально подходит, реализуется несколько преимуществ:
• Модель придает особое значение придается планированию,
направленному на подтверждения и проверки создаваемого ПО еще на
начальных стадиях его разработки. Этап модульного тестирования подтверждает
правильность детализированного проектирования. Этапы внедрения и проверки
описывают архитектурное проектирование или проектирование на высоком
60
уровне. Этап проверки системы подтверждает правильность выполнения этапа
требований к продукту и его параметров;
• Модель предусматривает аттестацию и подтверждение всех
внешних и внутренних полученных данных, а не только исходного ПО;
• V-образной модель выполняет определение требований перед
началом разработки проекта системы, а само проектирование ПО проходит перед
созданием компонентов;
• Модель определяет продукты, полученные в результате процесса
разработки, и все полученные данные подвергаются тестированию;
В процессе применения V-образной модели в работе над проектом, для
которого она не совсем подходит и недостаточно приемлема, проявляются ее
недостатки:
• Этой модели непросто справиться с параллельными событиями;
• В ней не учитываются итерации между фазами;
• В ней нет внесенных требований динамических изменений на
разных этапах ЖЦ;
• Проверка требований в ЖЦ реализуется слишком поздно, поэтому
невозможно внести корректировки, не повлияв при этом на сроки выполнения
проекта;
• Модель не включает действия, направленные на анализ рисков.
Как и каскадная модель, V-образная модель также лучше срабатывает
тогда, когда вся информация о требованиях заранее известна.
Общераспространенная модификация V-образной модели, направленная на
преодоление ее недостатков, включает в себя внесение итерационных циклов для
разрешения изменения в требованиях за рамками фазы анализа.
Применение модели эффективно тогда, когда доступными являются
данные о методе разработки решения и технология, а персонал обладает всеми
умениями и опытом в работе с используемой технологией.
Отличительной чертой RAD становится короткое время перехода от
выявления требований до разработки полной системы. Метод базируется на
совокупности итераций эволюционной системы или прототипов, критический
61
анализ которых утверждается у заказчика. Во время такого анализа составляются
требования к продукту.
Создание каждого внедренного продукта ограничивается четко
выделенным периодом времени, который обычно составляет 60 дней и носит
название «временной блок».
Инкрементная разработка включает в себя процесс частичного создания
всей системы и неторопливого наращивания функциональных возможностей.
Подобный подход дает возможность минимизировать затраты, понесенные до
момента достижения уровня установленной производительности. При помощи
такой модели убыстряется процесс разработки действующей системы. Этому
способствует используемый принцип сочетания из стандартных блоков, который
позволяет обеспечить контроль над процессом внедрения указанных требований.
Спиральная модель включает в себя положительные стороны каскадной
модели. При этом она также включает анализ рисков, может управлять ими, а
также имеет процессы поддержки и менеджмента. В ней также предусмотрено
создание программного продукта при помощи метода прототипирования или
быстрой разработки приложений с применением языков программирования и
средств разработки 4 поколения и выше.
В качестве стратегии внедрения ИС в ООО «КОНСАЛТ ДЕВЕЛОП». был
выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться
в применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также
определить и спланировать организационные и технические мероприятия на
этапе промышленного внедрения. Пилотный проект позволяет уменьшить
затраты и ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
Таким образом, каскадный метод более всего подходит к конкретной
разработке, следовательно, используем стандарт ISO/IEC 12207.
62
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
задачи учета продаж и поступлений для ООО «КОНСАЛТ ДЕВЕЛОП».. Риском
является возможность появления обстоятельств, обусловливающих
неуверенность или невозможность получения ожидаемых результатов от
реализации поставленной цели, нанесение материального ущерба, опасность
валютных потерь и др. Существуют следующие типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом взаимозаменяемых
на сотрудников, не менее соответствующих данным характеристикам (таблица
2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства
и документации
Формирование требований
Разработка требований к
Дефекты исходных
63
ПО
требований заказчика
Проектирование
Планирование работ
Дефекты,
обусловленные
реальной сложностью
проекта
Проектирование
архитектуры системы
Ошибки планирования
и системного
проектирования
программного средства
Детальное
проектирование ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты
и ошибки компонентов
и документов
программного средства
Тестирование
Тестирование ПО
Программные и
алгоритмические
ошибки программного
средства и
документации
Ввод в действие
Разработка документации
Дефекты и ошибки
обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
На этапе эксплуатации допускаются риски, связанные с:
1) Злоумышленными, активными воздействиями заинтересованных лиц.
Чтобы защитится от внешних угроз, нужно использовать средства поддержания
защиты программ и данных (проверка пользователей, безопасность ЛВС
методом установки межсетевых экранов, использование антивирусов);
2) Случайными проявлениями внешней среды, дефектами системы или
неверными действиями пользователей. Главными причинами таких ситуаций
становятся некорректные исходные данные, поломки и отказы аппаратуры,
ошибки и недоработки в программах и задачах, проявляющиеся в процессе их
выполнения в рамках своего назначения. При аналогичных воздействиях
внешняя, функциональная способность систем не разрушается на 100%, но уже
нельзя полностью выполнить заданные функций и требований к качеству данных
для потребителей.
64
Для минимизации рисков, связанных с ошибками системы, важно
проводить подробное тестирование на предоставленных приближенных к
реальности примерах. Для минимизации рисков, которые связаны с неверными
действиями пользователей, нужно найти защиту от использования ошибочных
действий по порче и удалению данных.
На стадии доработки могут возникнуть следующие риски:
• увеличение нагрузки на персонал;- несогласованность действий
персонала исполнителя и сотрудников предметных областей;
• трудности с обучением персонала заказчика из-за нежелания
работать с новой системой;
• отсутствие поддержки внедрения ИС со стороны отдельных
ключевых участников проекта;
• неучастие руководителей в проекте.
Для минимизации указанных рисков необходимо принимать следующие
меры:
• проведение обучения персонала работы с системой;
• доведение до персонала смысла внедрения автоматизированной
системы;
• активное вовлечение высшего руководства в проект, активное
взаимодействие с ним в ходе проекта и своевременное принятие решений,
необходимых для нормальной реализации проекта.
65
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
При эксплуатации разработанной информационной системы для
обеспечения её безопасности от внешних и внутренних угроз используется
комплекс мер по защите информации. В этот комплекс прежде всего входят
средства, позволяющие ограничить доступ пользователей к различным модулям
системы.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователей
Модуль
«Справочники»
Модуль
«Поступление
Модуль
«Отчеты»
Модуль
«Продажи»
Пользователь
Чтение
Чтение/Добавлен
ие
Чтение
Нет
Менеджер
Чтение
Чтение/Добавлен
ие/Изменение
Чтение
Чтение
Администрато
р
Полный
Полный
Полный
Полный
Физически разграничение прав доступа осуществляется ограничением
прав доступа к серверу..
Защита от внешних угроз осуществляется путем применения следующих
способов:
• использованием программно-аппаратных комплексов защиты от
несанкционированного доступа;
• разработкой и соблюдение политик безопасности;
• использованием антивирусных средств;
• физической защитой помещений с наиболее ценной информацией.
В качестве программно-аппаратного комплекса используется Crypton Lock.
Модуль санкционированного доступа Crypton Lock для Windows
позволяет:
• хранить пароль в защищенной памяти брелока РУТОКЕН для шины
USB;
66
• обеспечить вход в систему только зарегистрированных
пользователей по предъявлении брелока;
• блокировать систему на время отсутствия оператора на рабочем
месте.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель включает в себя четыре области:
• Область выходной информации
• Область справочников системы
• Область обработки информации
• Область входной информации
На модели приведены следующие входные документы:
• Информация о контрагентах
• информация о группе товара
• информация о типе упаковки
• информация о товаре
• информация о договорах
• информация о приходе товара
На модели приведены следующие результатные документы:
• отчет «Статистика продаж»;
• отчет «Статистика прихода»;
• накладная;
• прайс-лист;
• счет на оплату.
Схематически информационная модель приведена на рисунке 2.1.
ИС
Сотрудник
Учет типов
пользоват
елей
Учет
должносте
й
Учет
поставщик
ов
Учет
продаж
Учет
товаров
Учет
договоров
Учет
пользоват
елей
Учет
клиентов
Учет типов
товара
Учет
поступлен
ия
Учет типов
упаковки
Статистика
продаж
Статистика
прихода
Накладная
Статистик
а продаж
Статистик
а прихода
Накладная
Сотрудник
Счет на
оплату
Счет на
оплату
Прайс-
лист
Прайс-
лист
Спр Тип
пользователя
Спр* Тип
пользователя
Спр Клиент
Спр* Клиент
Спр Договор
Спр* Договор
Спр Склад
Спр* Склад
Спр Тип товара
Спр* Тип товара
Спр Тип
упаковки
Спр* Тип
упаковки
Спр Должность
Спр* Должность
Спр Сотрудник
Спр* Сотрудник
Спр Поставщик
Спр* Поставщик
Спр Товар
Спр* Товар
Т Приход
Т* Приход
Т Продажа
Т* Продажа
Т Список
прихода
Т* Список
прихода
Рисунок 2.1 Информационная модель системы учета продаж и поступлений ООО «КОНСАЛТ ДЕВЕЛОП».
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В качестве входных документов в ИС используются следующие
документы:
• Сведения о контрагентах (покупателях и поставщиках);
• Заказ покупателя;
• Список товаров с указанием стоимости и единицы измерения;
• План продаж.
Учет контрагентов производится с помощью экранной формы, макет
которой представлен на Рисунке 2.2.
Рисунок 2.2 Макет экранной формы добавления данных в справочник
Контрагенты
Документ Заказ Покупателя содержит следующие реквизиты:
• Дата
• Номер
• Организация
• Контрагент