72
Модель жизненного цикла — это структура, определяющая
последовательность взаимосвязи процессов и выполнения, задач и действий,
выполняемых на протяжении всего жизненного цикла. Модель жизненного цикла
зависит от специфики условий и информационной системы, в которых последняя
создается и функционирует.
К настоящему времени наибольшее распространение получили следующие
основные модели жизненного цикла:
1. Задачная модель;
2. Каскадная модель (или системная) (70-85 г.г.);
3. Спиральная модель (настоящее время).
Задачная модель: при разработке программной системы "снизу-вверх" от
отдельных задач ко всей системе (задачная модель) единый поход к разработке
неизбежно потеряется, возникают проблемы при информационной стыковке
отдельных компонентов. Как правило, по мере увеличения количества задач
трудности возрастают, приходится постоянно изменять уже существующие
программные средства и структуры данных. Скорость развития системы
замедляется, что тормозит и развитие самой фирмы. Однако в некоторых случаях
такая технология может оказаться актуальной:
- Очень срочно (надо чтобы хоть как-то заданные задачи решались;
потом все сделать заново)
- Адаптация заказчика и эксперимент (не ясные алгоритмы
программы, решения нащупываются методом проб и ошибок).
Общий вывод: достаточно большую и эффективную информационную систему
таким способом создать не предоставляется возможны.
Каскадная модель: в ранних, не очень больших по объему однородных
информационных систем каждое приложение представляло собой единое целое.
Для разработки такого типа приложений применялся каскадная модель. Его
основным свойство является разбиение всей разработки на этапы, причем переход
с одного этапа на следующий происходит только после того, как будет полностью
73
завершена работа над текущем. Каждый этап окончательно завершается
выпуском полного комплекта документации по программному обеспечению,
необходимо для того, чтобы разработка могла быть продолжена другой командой
программистов.
Положительные стороны применения каскадного подхода заключаются в
следующем:
- на каждом завершающем этапе формируется законченный набор
проектной документации, согласованности и отвечающий
критериям полноты;
- выполняемые в полной последовательности этапы работ
позволяют планировать сроки завершения всех работ и
соответствующие затраты.
Каскадная модель хорошо зарекомендовала себя при построении
информационных систем, для которых в самом начале разработки можно
достаточно точно и полно сформулировать все требования к проекту, с тем, чтобы
предоставить программисту свободу реализовать их как можно лучше с
технической точки зрения. В эту категорию попадают системы реального
времени, сложные расчетные системы и другие подобные задачи. Однако в
процессе использования этого подхода в нем обнаружился ряд его недостатков,
вызванных прежде всего тем, что реальный процесс разработки систем никогда
полностью не укладывался в такую жесткую схему. В процессе создания
приложения постоянно возникала потребность в возврате к предыдущим этапам
и уточнение или пересмотр ранее принятых решений.
Основным недостатком каскадной модели является существенное
запаздывание с получением результатов проекта. Согласование результатов с
пользователями производится только в точках, планируемых после завершения
каждого этапа работы, требования к информационным системам "заморожены" в
виде технического задания на все время ее создания. Таким образом, пользователи
могут внести свои замечания только после того, как работа над системой будет
полностью завершена. В случае неточного (неполного) изложения требований
74
или их изменения в течение длительного периода создания программного
приложения, пользователи получают программу, которая не удовлетворяет их по
потребностям. Модели (как информационные, так и функциональные)
автоматизируемого объекта могут устареть одновременно с их утверждением.
Сущность системного подхода к разработке Информационных систем
заключается в ее декомпозиции (разбиении) на автоматизируемые функции:
система разбивается на функциональные подсистемы, которые в свою очередь
делятся на подфункции, подразделяемые на задачи и так далее. Процесс
разбиения продолжается вплоть до конкретных процедур. При этом
автоматизируемая система сохраняет целое представление, в котором все
составляющие компоненты взаимосвязаны. Таким образом, данная модель
основным достоинством имеет системность и понимание разработки, а основные
недостатки - медленно и дорого.
Спиральная модель: Для преодоления большинства проблем
вышеупомянутых систем проблем была предложена спиральная модель
жизненного цикла делающая уклон на начальные этапы жизненного цикла:
проектирование и анализ. На этих этапах реализуемость технических решений
проверяется путем создания прототипов. Каждый виток спирали соответствует
созданию фрагмента кода или версии программного обеспечения, на нем
уточняется цель и характеристики проекта, определяют его качество и
планирования работы следующего витка спирали. Таким образом, углубляются и
последовательно определяются детали проекта и в результате выбирается
обоснованный вариант, который доводится до реализации проекта. Разработка
итерациями отображает объективно существующий спиральный цикл создания
программы. Неполное завершение работ на каждом этапе разработки позволяет
переходить на следующий этап, не дожидаясь полноценного завершения работы
на текущем. При итеративном способе разработки недостающую работу можно
будет выполнить на следующей этапе. Главная же задача спиральной модели –
это как можно быстрее показать пользователям системы работоспособный
программный продукт, тем самым, активизируя процесс дополнения и уточнения
требований. Основная проблема спирального цикла - определение момента
перехода на следующий этап. Для ее решения необходимо вводить временные
75
ограничения на каждый из этапов жизненного цикла. Переход осуществляется в
соответствии с планом разработки, даже если не вся запланированная работа
сделана. План составляется на основе статистических данных, полученных в
предыдущих проектах, и из личного опыта разработчиков.
Наиболее оптимально использовать спиральную модель, так как в ней были
учтены все недостатки задачной и каскадной модели. В рамках доработки уже
существующей Информационных систем частенько возникают новые замечания,
от пользователей, которые можно реализовать на новом витке спиральное модели.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Стандарт MSF даёт некоторую гарантию уменьшения рисков, так как весь проект
разделён на части(этапы), на каждом этапе есть роль, за которым закреплены
цели, которые должны быть достигнуты и всё же на каждом этапе есть риски:
В этапе выработки концепции могут возникнуть следующие риски:
- Недостаточный анализ сроков проекта и бюджета
Для минимизации такого вида риска нужно более детально прорабатывать задачи
и цель проекта, ставить больше контрольных точек.
- Неправильно подобранный проектная команда разработчиков, seo-
специалистов и т.д. может повлечь полное отсутствие командной работы
Данный риск минимизируется более внимательным подбором специалистов в
проектную команду, и тестирование не только профессиональных навыков
сотрудников, но и личностных качеств.
На этапе планирования проекта могут возникнуть следующие риски:
- Неправильно или не совсем корректное сформированное архитектурное
выбранного решения
Возможность появления этого риска зависит от компетенции руководителя
команды, который принимает решение о выборе разрабатываемого архитектуры
решения.
На этапе разработки возможны следующие риски:
76
- Неправильное написание технического задания и как в итоге
неправильное программирование архитектуры и увеличение сроков сдачи
проекта.
Уменьшение этого риска служит более чёткое и подробное написание
технического задания, для его понимания программисту
- Риск технический (на всех этапах) – это связано с возможным отказом
какого-либо оборудования (сервера) или веб приложения (ОС, СУБД,
Веб-сервера и т.д.).
Для предотвращения риска необходимо привлечь квалифицированных и
профессиональных с опытом работы специалистов, для быстрого
реагирование в случаи чрезвычайных факторов (сбоев, отказ
оборудование) а также слежение за своевременный автоматизированный
запуск резервного копирования информации;
- Риск персонала (на этапе внедрения в эксплуатацию приложения и в этапе
эксплуатации и сопровождения) связана с зависимостью от сотрудника,
найм на работу непрофессиональных программистов для дальнейшей
доработки проекта, и непонимание между программистами.
Для минимизации риска передачи дел для доработки ПО или дополнительным
наймом сотрудников необходимо держать резерв специалистов для замены либо
воспользоваться аутсорсинг (хотя этот вариант не всегда плюс так как бывает, что
фирмы-аутсорсинг присылают не профессионалов что в итоге, введет еще к
большим денежным расходом), также необходимо обеспечить коммуникацию
между сотрудниками, и документирование хода работы сотрудников.
На этапе тестирования могут возникнуть следующие риски:
- Незаконченное тестирования на проверку наличия ошибок в программе.
Частая ситуация, когда программный продукт будет протестирован не до конца в
итоге после внедрения приложении в эксплуатацию вылезает ряд довольно
банальных и не приятных ошибок для пользователей данного продукта.
Решение данной проблемы это повторного тестирования на следующей
обработки данных разработки программы.
77
В этапе внедрения ПО возникают следующие риски:
- Риск о неправильном принятие решения о законченности части проекта.
Данный риск ведет за собой возникновение проблем о незаконченности решения
и возможность появление противоречий с другими частями разрабатываемого
программного продукта
Устраняется путем доработки при следующей организации обработки данных.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Существует несколько вариантов реализации информационной безопасности.
Защита от внутренних угроз. Подразумевает разграничение прав пользователей:
Таблица № 7
Разграничение прав доступа на сайте
Группа
пользователей
Просмотр
объявлений
Добавление/удаление
объявлений
Создание/удаление
поста на форуме
Добавление/удаление
информации на сайте
Гость
Полный
доступ
Нет доступа
Нет доступа
Нет доступа
Пользователь
Полный
доступ
Ограничен(может
удалять только своё
объявление)
Ограничен(может
удалять только
свой пост)
Нет доступа
Модератор
Полный
Полный доступ
Полный доступ
Ограничен(может
добавлять/удалять
или дополнять только
новостные)
78
Продолжение таблицы № 7
Противовирусная защита от внешних угроз реализуется по следующими
параметрами:
Во-первых, все серверные системы в компании Авто.Ру Холдинг не имеют
установленных сторонних средств удаленного администрирования, таких как
Radmin, Dame Ware,Team Viewer. Доступ организован через Remote desktop
protocol, на необходимый сервер, в том числе и веб сервер сайта и СУБД В
компании Авто.Ру Холдинг используются все возможные методы защиты
информации такие как Kaspersky Endpoint Security, Использование шифрования
данных против SQL-инъекций используются антиснифферов против создание
скрытов файлов или ключей реестров взломщиком (Например, PromiScan или
AntiSniff) и т.д. Также каждый день на серверах создается бэкап базы данных и
всего сервера в целом в случаи сбоя, атаки и не своевременное сохранение
программного кода или наоборот случайная порча кода(человеческих фактор или
защита от дурака) делается каждодневное автоматическое резервное копирование
программой Acronis для восстановление утраченных данных из копии.
Используются антишпионские программы таких производителей как Kaspersky,
однако нет универсального одного метода против всех видов сетевых атак,
который сможет обеспечить полную информационную безопасность, а
сочетание всех методов безопасности позволяет реализовать максимальную
безопасность на сервере.
Группа
пользователей
Просмотр
объявлений
Добавление/удаление
объявлений
Создание/удаление
поста на форуме
Добавление/удаление
информации на сайте
Системный
Администратор
Полный
доступ
Полный доступ
Полный доступ
Полный(добавляет
функционал или
удаляет)
Программист
Полный
доступ
Полный доступ
Полный доступ
Полный(добавляет
функционал или
удаляет)
79
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Рисунок 17 – Информационная модель и её описание
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации
При автомобильной реализации проекта автоматизации для формирования
входного оперативного документа используются данные из первичного
документа пример - Справочник Автомобиля
- Марка
- Модель
- Кузов
- Тип двигателя(бензин/Дизель)
- Объем двигателя
80
- Разгон автомобиля
- Коробка передачи(механика/автомат)
- Рекомендации по эксплуатации автомобиля
- Автоматизированный поиск всех необходимых комплектующих для
автомобиля.
Структура файлов БД нормативно-справочной информации в таблицах
Таблица № 8
Таблица Автомобилей и их технических характеристик в БД
Марка
Модель
Кузов
Тип
Двигателя
Объем
двигателя
Разгон
автомобиля
Коробка
передачи
Toyota
Prado
150
Внедорожник
Дизель
2.4 л.с.
10 с.
Автомат
Ауди
Q7
Внедорожник
Бензин
2.5 л.с.
7.8 с.
Автомат
Mitsubishi
Outlander
Внедорожник
Бензин
1.8 л.с.
9.5
Автомат
Таблица № 9
Таблица Рекомендаций по каждому автомобилю в БД
Модель
ТО(км)
Замена
ГРМ
Замена
свечей
Замена
Масла
АКПП
Замена
тормозной
жидкости
Замена
Тормозных
дисков
Замена
тормозных
колодок
Prado 150
10 тыс.
60тыс.
40 тыс.
40 тыс.
70 тыс.
70 тыс.
20 тыс.
Q7
10 тыс.
50 тыс.
40 тыс
50 тыс.
80 тыс.
80 тыс.
15-20 тыс.
Outlander
7-8тыс.
60 тыс.
40 тыс
40 тыс.
60 тыс.
60 тыс.
15-20 тыс.
Все данные заносятся в веб приложение с помощью разработанных форм. С
помощью этих форм удобно вносить информацию. Так она запоминает вбитые
предыдущие данные в случаи если необходимо их использовать вновь
2.2.4 Характеристика результатной информации
В Данном этапе описаны данные полученные после поиска и запроса к БД
необходимой информации. Результат получение информации через
информационный сайт каталог автомобилей «Технические характеристики и
81
автомобиля». Выходной документ для пользователя «Технические
характеристики и автомобиля» содержит следующую информацию:
- Марка - Тойота
- Модель - Prado 150
- Кузов - Внедорожник
- Тип двигателя - бензин
- Объем двигателя - 2.4 л.с.
- Разгон автомобиля -10 с.
- Коробка передачи - Автомат
- ТО(км) - 10 тыс. Подойдут любые запчасти
- Замена ГРМ - 60 тыс. Рекомедовано Kashiyama
- Замена свечей - 40 тыс. Рекомендовано Koyo
- Замена Масла АКПП 40 тыс. Рекомендовано Масло Мобил
- Замена тормозной жидкости - 70 тыс. Рекомендовано тормозная жидкость
FELIX
- Замена Тормозных дисков - 70 тыс. Рекомендовано диски Sakura
- Замена тормозных колодок - 20 тыс. Рекомендовано колодки Kayaba
2.3.1. Общие положения (дерево функций и сценарий диалога)
Рисунок 18 - Фрагмента дерева функций