47
Рисунок 2.5 – Agile модель
Agile-модель может использоваться с любым типом проекта, но ей
необходимо значительная степень взаимодействия с клиентом и
интерактивность. Позволяет создавать наиболее качественное
программное обеспечение, что повышает удовлетворенность клиента.
Преимущества и недостатки моделей представлены в таблице 2.1.
Таблица №2.1
Преимущества и недостатки моделей жизненного цикла АИС
Наименование
Достоинства
Недостатки
Agile-модель
Уменьшается время,
необходимое для
использования некоторых
функций системы.
Постоянная связь с
представителем клиента не
оставляет места для
догадок.
Конечным
результатом является
высококачественное
программное обеспечение в
наименее возможное время
Документация
выполняется на более
поздних этапах.
Уменьшается
удобство использования
компонентов.
Требует
специальных навыков для
команды.
48
Продолжение таблицы №2.1
Итеративная и
инкрементальная модель
Производит бизнес-
ценность на раннем этапе
жизненного цикла
разработки.
Позволяет использовать
ограниченные ресурсы
посредством правильного
определения развития
проекта.
Может вмещать
запросы на изменение
между приращениями.
Больше внимания
уделяется потребительской
ценности, чем линейным
подходам.
Возможно раннее
обнаружение проблем и
изменений в проекте
Требуется большой
объем документация.
Выполняет
определенный набор
процессов.
Требуется большее
привлечения клиентов к
разработке, чем в линейных
подходах.
Разделение функций
и свойств может быть
проблематичным.
Интеграция между
итерациями может быть
проблемой, если она не
учитывается при разработке
и планировании проекта.
Спиральная модель
Оценки (оценки
бюджета, временных
параметров и т.д.)
становятся более
реалистичными по мере
выполнения работы,
поскольку важные
проблемы обнаруживаются
ранее.
Раннее вовлечение
разработчиков в проект.
Управление рисками
и развитие системы
происходит поэтапно.
Высокая стоимость и
время для достижения
конечного продукта.
Требуются
специальные навыки для
оценки рисков и
допущений.
Модель V-образной формы
Простота и удобство
в использовании
Каждая фаза имеет
конкретные результаты.
Более высокий шанс
успеха по сравнению с
моделью водопада в связи с
разработкой планов
испытаний на раннем этапе
в течение жизненного
цикла.
Хорошо работает,
когда требования четко
определены.
Проверка продукта
на ранних этапах
разработки продукта.
Очень негибкая, как
и модель водопада.
Программное
обеспечение
разрабатывается на этапе
внедрения, поэтому не
появляются ранние
прототипы программного
обеспечения.
Модель не
обеспечивает четкого пути
для решения проблем,
обнаруженных на этапах
тестирования.
Достаточно дорогая и
требует подробного плана.
49
Продолжение таблицы №2.1
Модель водопада
Легко объяснить
пользователям.
Этапы и действия
четко определены.
Помогает
спланировать и определить
временные рамки проекта.
Проверка на каждом
этапе обеспечивает раннее
обнаружение ошибок.
Каждая фаза имеет
конкретные результаты
Предполагается, что
требования системы
должны оставаться
неизменными.
Очень сложно
вернуться на любой этап
после его завершения.
Небольшая гибкость
и настраиваемость делают
проект сложным и
дорогостоящим.
Проанализировав данные модели, было принято решение
использовать для разработки модель водопада, поскольку в данном
проекте четко определены требования к информационной системе, и в то
же время модель водопада является наиболее простой из всех
представленных.
Внедрение информационной системы учета рабочего времени состоит из
представленных ниже этапов [30].
Обследование.
С учетом специфики предметной области рекомендуется технология
стандартного внедрения системы. Задачами внедрения ИС являются:
организация автоматизированного учета рабочего времени;
повышение эффективности работы компании.
Разработка модели данных.
На данном этапе создается ER-модель базы данных, в которой отражаются
все сущности БД и взаимосвязь между ними.
Установка и настройка модуля.
На данном этапе выполняется комплекс работ по приобретению
необходимого для разработки программного обеспечения и СУБД.
Разработка программного обеспечения.
На данном этапе создается и тестируется программное обеспечение.
50
Обучение пользователей.
Обучение пользователей ИС проводится без отрыва от производственного
процесса. Обучение должно проводиться на территории предприятия путем
практического применения внедряемой программы под наблюдением
специалиста из отдела сопровождения.
Ввод в эксплуатацию и сопровождение.
На данном этапе происходит отказ от использования старого
программного средства и переход к новому формату. Этот этап длится на
протяжении всего периода эксплуатации программы.
Проектирование АИС – это набор этапов, направленных на
реализацию АИС.
Проектирование АИС согласно ГОСТ 34.601-90 можно разбить на
следующие этапы:
1) Формирование требования к АИС – данный этап является
подготовительным. Во время него проводится обследование предприятия и
проводится обоснование разработки. Определяется как пользователи
должны взаимодействовать с АИС и какие результаты (отчеты) они
получают;
2) Разработка концепции АИС – на данном этапе проводится выбор
концепции АИС на основе анализа объекта автоматизации, необходимых
отчетов, требований пользователей;
3) Разработка технического задания – на данном этапе
разрабатывается и утверждается техническое задание на разработку;
4) Разработка эскизного проекта – на данном этапе производится
предварительная разработка системы или ее компонентов. Составляется
документация на АИС;
5) Разработка рабочей документации – производится разработка
рабочей документации на АИС, кодирование и отладка программ;
6) Ввод АИС в действие – подготовка системы к развертыванию и
ввод ее в эксплуатацию. Этап включает проведение приемочных
испытаний и обучение персонала;
51
7) Сопровождение – обновление системы, гарантийные и
послегарантийные работы.
К базовым технологиям АИС относятся:
объектно-ориентированный подход;
функционально-модульный или структурный подход.
Объектно-ориентированный подход – это подход, который
подразумевает создание программных объектов, которые описывают
сущности реального мира. Недостатком данного метода является
необходимость навыков работы с объектно-ориентированным
программированием и относительная сложность разработки. К
преимуществам метода можно отнести расширяемость программного
обеспечение и высокую безопасность ПО.
Структурный (функционально-модульный) подход –
программирование, основанное на функциях. Данный подход может
применяться при разработке небольших программ, характеризуется
невысокой сложностью разработки. Недостатком метода является низкая
расширяемость систем.
Основные варианты перехода на АИС для упрощения процесса
продаж:
1) Покупка готового продукта
Достоинством метода является отсутствие необходимости
разработки ПО, отсутствие необходимости содержать штат
программистов.
Недостатком является необходимость затрат на покупку ПО и
необходимость дальнейшей настройки системы.
2) Разработка системы на заказ
Достоинством метода является отсутствие необходимости настройки
и изменения приобретенного программного обеспечения, отсутствие
необходимости содержать штат программистов.
52
Недостатком является необходимость затрат на оплату
программного обеспечения.
3) Покупка и модификация
Достоинством метода является разработка системы, в точности
удовлетворяющей потребности компании и возможность дальнейшей
доработки ПО.
Недостатком метода является необходимость наличия штата
разработчиков ПО.
Сравнение существующих технологий проектирования представлено
в таблице 2.2.
Таблица №2.2
Описание классов технологий проектирования
Класс технологии
проектирования
Степень
автоматизации
Степень
типизации
Степень адаптивности
Каноническое
проектирование
Ручное
проектирование
Оригинальное
проектирование
Реконструкция
Индустриальное
автоматизированное
проектирование
Компьютерное
проектирование
Оригинальное
проектирование
Реструктуризация модели
(генерация ИС)
Индустриальное
типовое
проектирование
Компьютерное
проектирование
Типовое
сборочное
проектирование
Параметризация и
реструктуризация модели
(конфигурация ИС)
В выпускной квалификационной работе целесообразно использовать
объектно-ориентированный подход, что позволит легко расширять и при
необходимости видоизменять систему.
Рассмотрим средства проектирования информационных систем.
1) Стандарт IDEFX. Для того, чтобы разработать семантические
модели данных, используют такой язык моделирования как Integration
DEFinition for information modeling (IDEF1X). Данный стандарт является
частью семейства языков моделирования IDEF и используется для
создания графической информационной модели. [10]
53
Создание компьютерных баз данных, управление интеграцией
информационных систем, построение семантических моделей данных –
все это входит в задачи IDEF1X.
Метод моделирования данных используется для моделирования
данных стандартным, согласованным и предсказуемым образом, чтобы
управлять им как ресурсом. Он может использоваться в проектах,
требующих стандартных средств определения и анализа ресурсов, данных
в организации. Такие проекты подразумевают включение метода
моделирования данных в методологию, управление данными в качестве
ресурса, интеграцию информационных систем или разработку
компьютерных баз данных.
Основными целями стандарта IDEF1X являются [11]:
Средства для полного понимания и анализа ресурсов, данных
организации;
Общие средства представления сложных данных;
Метод представления общего вида данных, необходимых для
запуска предприятия;
Средства для определения независимого от приложения
представления данных, которые могут быть проверены пользователями и
преобразованы в физический дизайн базы данных;
Метод получения комплексного определения данных из
существующих ресурсов данных.
Основной целью IDEF1X является поддержка интеграции. Подход к
интеграции фокусируется на захвате, управлении и использовании единого
семантического определения ресурса данных, называемого
«концептуальной схемой».
«Концептуальная схема» предоставляет единое интегрированное
определение данных внутри предприятия, которое не склоняется к какому-
либо одному приложению данных и не зависит от способа физического
хранения данных или доступа к ним.
54
Основная цель этой концептуальной схемы заключается в
согласованном определении значений и взаимосвязей между данными,
которые могут использоваться для интеграции, совместного использования
и управления целостностью данных.
Концептуальная схема должна иметь три важных характеристики:
[12]
Согласованность с инфраструктурой бизнеса и истинность во
всех сферах ее применения;
Расширяемость, означающая, что новые данные могут быть
определены без изменения ранее определенных данных;
Возможность преобразования как в требуемые
пользовательские представления, так и в различные структуры хранения
данных.
2) Трехкомпонентный подход в программной инженерии – это
подход к построению информационных систем и систем управления
информацией, который продвигает концептуальную модель как ключ к
достижению интеграции данных.
Схема – это модель, обычно изображаемая диаграммой и иногда
сопровождаемая описанием языка [11].
В этом подходе используются три схемы:
Внешняя схема для представлений пользователей;
Концептуальная схема объединяет внешние схемы;
Внутренняя схема, определяющая структуры физического
хранения.
В центре концептуальная схема определяет онтологию понятий, как
пользователи думают о них и говорят о них. Физическая схема описывает
внутренние форматы данных, хранящихся в базе данных, а внешняя схема
определяет представление данных, представленных прикладным
программам.
55
Процесс моделирования можно разделить на пять этапов разработки
модели [11]:
Нулевая фаза – начало проекта, среди целей этого этапа отмечают:
Определение проекта;
Исходный материал;
Авторские конвенции – основополагающая декларация
конвенций (факультативных методов), с помощью которой автор выбирает
модель и управляет ею.
Первый этап – определение сущности. Цель этапа определения
сущности состоит в том, чтобы определить сущности, относящиеся к
моделируемой проблемной области;
Второй этап – определение взаимосвязей. Цель этапа определения
взаимосвязей заключается в выявлении и определении основных
взаимосвязей между сущностями. На данном этапе моделирования
некоторые отношения могут быть неспецифическими и потребуют
дополнительного уточнения на последующих этапах. Главными
результатами второго этапа являются:
Матрица отношений;
Диаграммы уровня сущности;
Третий этап – ключевые определения. Цели ключевого этапа
определения:
Уточнение неспецифических связей из второго этапа;
Определение ключевых атрибутов для каждой сущности;
Миграция первичных ключей для установки внешних ключей;
3) Стандарт Data Flow Diagram (DFD) – диаграмма потока данных
(DFD) графическое представление «потока» данных через
информационную систему. DFD часто используется в качестве
предварительного шага для создания обзора системы, не вдаваясь в
большие детали, которые могут быть позже разработаны. DFDs также
56
может использоваться для визуализации обработки данных
(структурированный дизайн).
DFD показывает, какая информация будет вводиться и выводиться из
системы, как данные будут продвигаться через систему и где будут
храниться данные. Он не показывает информацию о времени процесса или
о том, будут ли процессы работать последовательно или параллельно, в
отличие от традиционной структурированной блок-схемы, которая
фокусируется на потоке управления, или диаграммы рабочего процесса
действия UML, которая представляет, как потоки управления, так и потоки
данных как единую модель.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На этапе обследования существует риск превышения установленных
сроков проекта, так как большая часть времени уходит на изучение
документации и процессов организации рабочего времени на предприятии. Не
всегда есть возможность получить необходимую информацию в срок, так как
сотрудники предприятия не всегда могут выделить время на анкетирование или
интервьюирование.
На этапе разработки модели данных и выбора программного обеспечения
для разработки основным риском является возникновение недопонимания
между сотрудниками предприятия-заказчика и исполнителем.
На этапе приобретения, установки и настройки ПО также основным
риском является протяженность по срокам, что негативно сказывается на
производительности предприятия. Кроме того, при возникновении
непредвиденных ситуаций могут возникнуть дополнительные расходы на их
устранение.
На этапе внедрения присутствует риск конфликта с уже имеющимися на
предприятии программами.
На этапе ввода в эксплуатацию и сопровождения большой риск связан с
сознательными и по неосторожности ошибками пользователей системы.