76
спецификации, отвечающей всем требованиям заказчика. Также следует
обратить внимание и на другие факторы, которые могут затруднять процесс
разработки. К ним относятся дедлайны, установленные заказчиком, а также
бюджетные ограничения.
Обратите внимание: Чем больше информации об информационной системе
вы соберете, тем меньше времени потратите на исправление ошибок,
доработку проекта, пересмотры бюджета, обсуждения и решение других
вопросов.
Видение информационной системы.
Важной задачей является создание подробного документа видения (или
образа) информационной системы, который включает краткое описание
проекта, бизнес-цели, а также критерии успеха ИС, факторы бизнес-рисков и
описание конечного пользовател.
Готовый документ необходимо передать на утверждение заказчику, чтобы
убедиться в том, что все поставленные требования были учтены, а также
чтобы проинформировать его о любых рисках, которые могут возникнуть
после релиза ИС.
Сбор требований.
После того, как все основные вопросы решены, рекомендуется провести
дополнительные обсуждения и интерактивные семинары со всеми
заинтересованными сторонами. Это поможет выявить какие-либо
неочевидные моменты, которые в дальнейшем могут стать причиной
внесения изменений в интерфейс информационной системы или
необходимости переписывания паттернов кода. Данный этап может также
включать заполнение анкет, рассмотрение кейсов, мозговой штурм и т.д.
Многие информационные системы заходят в тупик из-за дополнительных
требований, которые всплывают на стадии реализации. Поэтому очень важно
понимать начальные бизнес-цели и главную идею будущей информационной
системы.
2. Проектирование информационной системы
77
Следующим этапом жизненного цикла ИС является создание документа,
описывающего масштабы и границы проекта. Данный документ включает в
себя мокапы или скетчи интерфейса будущей информационной системы, а
также подробную спецификацию требований. Необходимо отметить, что в
некоторых случаях документ видения (образа) проекта и документ о
масштабах и границах проекта могут быть представлены как единый
документ “Об образе и границах информационной системы”.
Масштабы и границы.
В документе, описывающем масштабы и границы информационной системы,
должны быть перечислены основные функции создаваемой информационной
системы. Они определяются на основании документа видения проекта, и
безусловно, с учетом указанных временных рамок и установленного
бюджета.
Кроме того, в данный документ входят мокапы или скетчи, созданные на
основе документа видения проекта, а также собранных требований.
Можно нарисовать скетч пользовательского интерфейса от руки либо
использовать для этого программы создания мокапов, и затем согласовать
его с заказчиком. Ниже представлен список полезных программ для создания
мокапов, иногда используется на практике:
https://invisionapp.com/
https://webflow.com/
https://moqups.com/
В процессе обсуждения проекта, у заказчика может появляться все больше
новых идей относительно его реализации. Поэтому рекомендуется дать ему
время на обдумывание своего проекта и требований к нему, а затем повторно
собраться и обсудить детали проекта, чтобы ничего не упустить из вида.
На этом этапе также поднимается вопрос о послепродажном обслуживании
продукта. Необходимо уведомить заказчика о том, каким образом будет
78
осуществляться техническая поддержка после завершения этапа
тестирования и последующего релиза продукта.
Стоит обратить внимание на то, что документ видения проекта и документ о
масштабах и границах проекта должны быть созданы до подписания
контракта.
Спецификация требований информационной системы.
Спецификация требований информационной системы (SRS) описывает
требования, которым должно отвечать создаваемой информационной
системе. Она должна быть логичной, последовательной, доступной и полной.
Требования могут выражаться в разных формах, например, в виде
традиционных утверждений долженствования (н-р, “Система Staff Manager
должна поддерживать следующие браузеры: Google Chrome, Apple Safari,
Mozilla Firefox, Opera, IE 8+”) или в виде пользовательских историй
(например, “поскольку я являюсь менеджером, мне необходим доступ к
персональной информации всех сотрудников”).
Существует большое количество шаблонов спецификаций. Выбор
определенного шаблона зависит от специфики проекта. В большинстве
случаев, спецификация включает в себя описание продукта, классы
пользователей, функциональные и нефункциональные требования к
разрабатываемой информационной системе. Иногда в шаблон также входит
прототип. Главное — сделать спецификацию понятной, лаконичной и
полезной для разработчиков.
Для создания прототипа необходимо выяснить следующее:
способ получения и обработки входящих данных для создания
необходимых данных на выходе;
форма, в которой должны быть представлены выходные данные.
Мокапы (или прототипы) передаются UI/UX-дизайнерам, которые
превращают их в красочные шаблоны.
3. Разработка информационной системы
79
Необходимо отметить, что разработка информационной системы может
также включать в себя создание интерактивного прототипа, который, в
сущности, является основой будущего проекта. Такой прототип помогает
определить архитектуру системы в целом. На данном этапе пишется мало
кода: например, код кнопок и простых форм, чтобы дать заказчику общее
представление о том, как будет работать конечный продукт. Поэтому я
иногда включаю создание прототипа в этап разработки веб-сайта.
Как только интерактивный прототип и дизайн приложения готов и утвержден
заказчиком, начинается разработка стандартов приложения (конвенции
наименований, способа документирования кода, инструкций для конечного
пользователя и т.д.). После этого можно смело переходить к следующему
этапу жизненного цикла, а именно, к разработке информационной системы.
Разработка ИС может быть разделена на небольшие части, или юниты, и
каждый юнит разрабатывается и тестируется разработчиками для проверки
его функциональности (модульное тестирование).
4. Тестирование информационной системы
После завершения этапа разработки продукт должен пройти тщательное
тестирование, чтобы убедиться в том, что он соответствует поставленным
требованиям. На этапе приемочного тестирования необходимо, чтобы
заказчик попытался применить продукт локально точно таким же образом,
как он собирается использовать его после релиза. Когда будут исправлены
основные ошибки, информационную систему можно внедрять. Для
исправления незначительных ошибок может использоваться простая система
отслеживания, что позволит исправлять любые недоработки уже на этапе
сопровождения ИС.
5. Техническая поддержка информационной системы
После того, как продукт был протестирован и развернут на сервере
заказчика, начинается следующая фаза жизненного цикла разработки
информационной системы, которая называется сопровождением или
80
технической поддержкой ИС. В целом, сопровождение подразумевает под
собой исправление мелких багов, которые обнаруживаются на этом этапе.
Тем не менее, вполне возможно, что будет необходимо вносить некоторые
изменения в созданную информационную систему, несмотря на все усилия,
приложенные разработчиком на предыдущих этапах. Заказчик может решить
внести изменения в функциональность разработанного продукта.
Следовательно, придется собирать, описывать и обсуждать новые требования
с заказчиком, чтобы внести в продукт необходимые изменения. В данном
случае, предстоит работа с новым каскадным проектом, и все
вышеописанные шаги придется повторять с начала.
Были рассмотрены ключевые этапы разработки, необходимы для создания
качественной информационной системы. Для того, чтобы текущий проект
был успешным, необходимо обсудить все требования к будущей
информационной системе с непосредственным заказчиком, а также подробно
задокументировать всю работу, которая должна быть проведена на каждом
этапе разработки.
Каскадную модель в обязательном порядке используют при создании систем
жизнеобеспечения, используемых в военном деле, космических разработках
и медицине, например, при разработке программного обеспечения для
контроля полетов, систем подушек безопасности и т.д. Она также может
применяться при разработке небольших и несложных проектов. Однако, если
на одном из начальных этапов будет допущена ошибка, существует
вероятность того, что она будет обнаружена лишь на этапе разработке или
тестирования. Поэтому рекомендуется применять данную модель только в
том случае, если все требования предельно понятны и не будут меняться с
течением времени.
81
Рис. Этапы создания веб-сайта студии корпусной мебели «ВК Мебель»
Вывод: для реализации информационной системы была определена
каскадная модель, является самая оптимальной по необходимым
требованиям. Выбраны следующие стандарты жизненного цикла
информационной системы ГОСТ 19.201-78, ГОСТ 34.602-89, ГОСТ 34.601-
90, ГОСТ 34.201-89, РД 50-34.698-90. Существует несколько стратегий
внедрения системы, для реализации текущего проекта необходим выбор
стратегии "Пилотный проект". Это тактика "скачка", но применяемая к
ограниченному числу процессов. Область применения стратегии - небольшой
участок деятельности. Это часто используемая стратегия сегодня, она
снижает финансовые риски и наиболее надежна.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Основные риски web-проектов. Риск — это всегда неопределенность, чем
больше размер проекта, тем выше степень его неопределённости.
Риски веб-проекта можно классифицировать следующим образом:
1. Технические риски. Разработка любого ИТ-проекта осуществляется с
помощью специфического оборудования: ПК, серверов, иного
оборудования. Отказ оборудования, его поломка или ошибки монтажа
могут оказать влияние на сроки осуществления проекта, частично
приостановить работу над проектом, до восстановления неисправности.
82
2. Риски оценки сроков. Для большинства веб-проектов (особенно в
проектах по разработке и внедрению веб-ориентированного
программного обеспечения) характерны ошибки в определение сроков
необходимых для реализации проекта. Часто это связанно с
недостаточностью проработки плана проекта, что приводит к
появлению «забытых работ» и смещению сроков.
3. Интеграционные риски. Многие веб-проекты обмениваются данными с
другими информационными системами. Риск возникновения
различных проблем, в процессе интеграции разработанного веб-
проекта, особенно для крупных компаний, всегда высок, так как новое
ИТ-решение должно стать частью уже существующей
инфраструктуры. Например, необходимость интеграции нового сайта
магазина в бухгалтерскую систему компании. Такие обмены, как
правило, требуют внесения изменений как минимум в одну из систем,
часто — в обе. Организационно и технически этот вопрос лежит на
границе ответственности сторон проекта, часто из-за его решения
затягивается или перекладывается с одной стороны на другую.
4. Риски непринятия продукта пользователями. Большинство
разрабатываемых веб-продуктов являются не корпоративными
решениями, а проектами, ориентированными на пользователей сети —
конечных потребителей продукта. Любой новый сервис — это, в
первую очередь, изменение технологии работы. Эти изменения могут
быть не приняты пользователями веб-продукта. Пользователь
интернета не захочет читать справки вашего сервиса, все должно быть
интуитивно понятно.
5. Технологические риски. Это риски, связанные с выбором технологии и
поставщика. Каждый год в сфере интернета происходят
революционные изменения, появляются кардинально новые
разработки, меняющие вектор развития. Необходимо оценить
успешность технологий на рынке, ее актуальность на протяжении
83
жизненного цикла ИТ-проекта, доступность необходимого аппаратного
и программного обеспечения, его качество, частоту модернизации.
6. Риски несоблюдения технологии. Использование для реализации
проекта новых, не опробованных технологий может привести к
затруднениям в реализации проекта. Для предотвращения возможных
проблем в график проекта необходимо закладывать время на изучение
новой технологии сотрудниками.
7. Неопределенность требований заказчика. Заказчик, как правило,
осознает только цель, которую хочет достичь, инвестируя в данный
проект, но не имеет представление о процессе и способах реализации
проекта. Заказчик и разработчик говорят на разных языках, и одна из
основополагающих задач правильно понять требования заказчика. На
этапе инициации проекта и подготовке технического задания,
необходимо четко определить все спецификации продукта и каким
образом они должны быть реализованы. Кроме того, во время
реализации веб-проекта заказчик может внести изменения в
спецификации. Частое изменение требований приводит к нарушению
графика проекта и увеличению его стоимости.
8. Коммерческие риски. Это риски, обусловленные неблагоприятными
изменениями в экономике предприятия заказчика, или веб-студии,
разрабатывающей проект, или в экономике страны. Наиболее
распространенным видом экономического риска, который содержит в
себе частные риски, является изменение конъюнктуры рынка,
несбалансированная ликвидность, изменения уровня управления и др.
9. Отсутствие рабочего взаимодействия с заказчиком. Отсутствие
взаимодействия с заказчиком может привести к разнообразным
проблемам. На ранней стадии работы заказчик может уйти, не получая
отдачу. На завершающих стадиях проекта приводит к выявлению
новых требований. Эти требования могут возникнуть при подготовке и
84
проведении приемных испытаний продукта. Данная ситуация способна
оказать серьезное влияние на сроки реализации проекта.
Этапы работы с рисками. Каждая методология разработки ИТ-проекта
предлагает свои способы управления рисками. Модель управления рисками
методологии MSF включает в себя шесть этапов:
1. Выявление рисков. Важно определить риски веб-проекта, еще на
начальных фазах разработки, выявить их источники (внешние условия
выполнения проекта, процессы, технологии) и условия возникновения
рисков.
2. Анализ рисков. Все выявленные риски подразделяются на важные (с
высокой вероятностью реализации) и малозначимые. Для главных или
приоритетных рисков проекта проводится количественная анализ,
который позволяет определить: вероятность наступления риска,
величину ущерба от его реализации, ожидаемую величину риска.
3. Планирование рисков. Разрабатывается детальный план управления
главными рисками ИТ-проекта.
4. Мониторинг рисков. Наблюдение за выполнением работ по
предотвращению рисков веб-проекта, информирование проектной
группы о планах реагирования в случае реализации рисков.
5. Контроль рисков. Вследствие реализации рисков оперативно вносятся
изменения в план проекта.
6. Извлечение уроков. Усвоение полученного опыта, формирование
информационной базы о рисках, совершенствование процессов
управления рисками.
Необходимо осуществлять управление рисками на всех этапах работы.
Мониторинг рисков также необходим. Мониторинг рисков — это процесс
отслеживания уже идентифицированных и поиск еще не выявленных рисков,
а также оценки эффективности исполнения операций реагирования на риски.
Мониторинг рисков включает в себя процедуры аудита и пересмотра рисков.
85
Необходимо регулярно осуществлять пересмотр рисков. Совещания команд,
осуществляющих разработку веб-проекта, должны включать в себя
обсуждение процедур управления рисками. Аудит рисков обеспечивает
оценку эффективности мероприятий по управлению рисками.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Угрозы
Способов взлома сайта на самом деле не так уж много. Их можно разделить
на три группы.
Взломщик может захватить контроль над самим веб-сервером, на котором
расположен сайт. Если последний размещен на условиях хостинга (т.е. на
одном веб-сервере находится сразу множество сайтов), то при таком способе
взлома угрозе подвергаются все ресурсы, расположенные на этом хостинге.
Однако вероятность подобного взлома невысока — компании,
предоставляющие подобные услуги, обычно хорошо заботятся о
безопасности своих ресурсов.
Злоумышленник может узнать у владельца сайта или его администратора
авторизационные данные для доступа к сайту (логин и пароль к FTP-
аккаунту или к управляющей панели) и воспользоваться ими для изменения
сайта или похищения с него информации. При этом никакие системы
безопасности самого ресурса не смогут ему воспрепятствовать: для них
действия взломщика будут абсолютно законными, так как выполняются
после легального прохождения авторизации. Получить логины и пароли для
работы с сайтом взломщик может как с помощью социальной инженерии
(попросту каким-либо образом выведав их у администраторов), так и с
помощью атаки на те компьютеры, где эти данные могут быть сохранены
(последнее зачастую выполняется посредством троянских программ) или
перехвата передаваемых данных.