45
одновременно работать с одними и теми же данными. Можно предоставить
общий доступ к книге Excel нескольким пользователям, но лучше, чтобы
пользователи изменяли данные в Excel в разное время.
Если нужно подключиться к различным источникам данных и
изменять данные непосредственно в этих источниках, следует выбрать
приложение Access. В Excel можно просматривать внешние данные, но
изменить их невозможно.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение - совокупность технических средств,
специализированных для работы информационной системы, а кроме того
надлежащая документация на эти средства и технологические процессы.
Совокупность технических средств составляют:
компьютеры;
устройства сбора, накопления, обработки, передачи и вывода
информации - жесткие диски, устройства хранения данных, сканеры,
принтеры, факсимильные аппараты;
устройства передачи данных и линий связи - модемы;
эксплуатационные материалы - бумага, CD (DVD) - диски и т.п.
В нашем случае главными компонентами технического обеспечения
будут:
автоматизированные рабочие места персонала организации
Сеть интернет и локальная вычислительная сеть, которая может
состоять из сетевых устройств (маршрутизаторов, коммутаторов и т.д.), и
соединяющего их кабеля.
В качестве АРМ необходимо использовать персональные компьютеры
со следующей минимальной конфигурацией:
Частота процессора 2,8 ГЦ и выше
46
Оперативная память объемом 1024Mb или выше
·Жесткий диск 200,0 Gb или выше.
Привод DVD.
Монитор 17" или выше
ИБП APC Back-CS500VA, аналогичный или лучше.
Такая конфигурация даст возможность реализовать работу в
разрабатываемой системе со значительной степенью надежности. Размер
оперативной памяти и жесткого диска - стандартны в настоящее время для
офисных компьютеров. Кроме указанных элементов еще необходима сетевая
карта для возможности подключения к локальной сети школы, но в данный
момент найти материнскую плату без встроенной сетевой картой очень
сложно найти. Такие элементы, как картридер и привод DVD±RW, не
являются обязательными. Их отсутствие даже положительно влияет на
сохранность конфиденциальной информации. ИБП в условиях
необходимости снижения рисков повреждения техники от возможных
перерывов в энергоснабжении - необходимый элемент.
Комплекс технических средств локальной компьютерной сети
предусматривает:
персональные компьютеры для рабочих мест пользователей;
комплект сетевого оборудования;
комплект кабельной продукции;
устройства введения и вывод - сканер и принтер;
коммуникационное устройство - сетевой адаптер.
47
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла системы - структура, содержащая процессы,
действия и задачи, которые осуществляются в ходе разработки,
функционирования и сопровождения программного продукта в течение всей
жизни системы, от определения требований до завершения ее использования.
Имеется несколько моделей и стандартов, в какой-то степени
регламентирующих жизненный цикл систем, значительная часть из них
принадлежит к системам заказному ПО (автоматизированным системам АС,
и др.) и помимо непосредственно ЖЦ регламентируют кроме того и
процессы разработки.
Кроме того, вопросы жизненного цикла проекта рассматриваются и
описываются в методологиях управления проектом. Учитывая высокую
потребность индустрии программного обеспечения и автоматизации в
методах эффективного управления, в последние десятилетия разработаны и
внедрены многие подходы управления проектом, в том числе:
Классический проектный менеджмент;
Agile (включая Scrum);
Lean (Kanban);
Six Sigma;
PRINCE2;
Метод критической цепи.
Рассмотрим методы описания жизненного цикла систем.
48
Custom Development Method (и, технология Oracle) по разработке
прикладных информационных систем под заказ – определенная методология,
конкретизированный вплоть до степени заготовок проектных документов,
предназначенных на применение в проектах с применением Oracle. Степень
адаптивности CDM ограничивается 3-мя моделями ЖЦ разработки:
"классическая" (учтены все без исключения работы/задачи и этапы),
"быстрая разработка" (Fast Track), "упрощенный подход", предлагаемый в
случае небольших проектов и возможности ускоренно прототипировать
приложения.
Rational Unified Process (RUP) предлагает итеративную модель
разработки систем, включающую четыре фазы: начало, исследование,
построение и внедрение. Прохождение через четыре ключевые фазы
именуется циклом разработки, при этом каждый цикл заканчивается
генерацией версии системы (или её описания).
Microsoft Solution Framework (MSF) аналогична с RUP, точно так же
содержит четыре фазы: исследование, проектирование, разработка,
стабилизация, является итерационной, подразумевает применение объектно-
ориентированного моделирования. MSF в сопоставлении с RUP в большей
части начелена на разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование
счиатется наиболее новейшим из числа рассматриваемых методологий,
сложилась в 1996 году. В основе методологии командная деятельность,
результативная связь между заказчиком и исполнителем на протяжении всего
проекта по созданию ИС, а создание проводится с использованием
поочередно дорабатываемых прототипов.
Главными аспектами для выбора стандарта ЖЦ будут:
актуальность и современность применяемых методов
контролирования разработки
разработка в итерационном режиме с возможностью
осуществлять контроль риски
49
и исполнения самого проекта на некоторых контрольных точках,
отсутствие добавочных требований по моделированию процесса разработки
и внедрения.
Отметим из представления подходов выше, итерационными из них
считаются 4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, потому что основной целью его
использования “является проведения аудита и стратегического планирования
ИС и IT инфраструктуры в целом”.
Стандарт XP тоже не подходит, так как он не содержит полноценных
этапов ЖЦ, таких как выработка концепции, планирование, разработка,
стабилизация, внедрение.
Таким образом, можно выбрать между Rup и MSF. Эти два стандарта
считаются достаточно разработанными и поддерживающими всё технологии
продуктивной разработки и контролирования их исполнения.
Ключевые характерные особенности MSF, RUP и XP объединены в
таблицу 2.1. Согласно этой таблицы по ней возможно судить, что Rational
Unified Process считается хорошо сбалансированным решением для средних
по размерам коллективов разработчиков, работающих с применением
продуктов и технологий компании Rational.
Extreme Programming хорошо подойдет для проектных групп
небольшого размера и для малых систем с зачастую модифицируемыми
требованиями. Основная трудность XP - сопровождение. В случае текучки
сотрудников в коллективе разработчиков существенная доля проектных
данных может быть утрачена из-за почти отсутствующей документации. В
таблице 2.1 показаны ключевые характеристики Жизненного цикла ИС
Таблица 2.1 - Технологии MSF, RUP и XP
Технология
Лучший
размер
команды
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
50
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних
размеров.
Рассматриваемая в работе ИС автоматизации поддержки считается
небольшой, и к ней возможно применение подхода MSF. Помимо этого
важным преимуществом MSF считается итерационная модель одновременно
с уточняющими вехами (аналог каскадной модели). То есть, в реализация
MSF предпринята попытка совместить каскадную и итерационную модель
разработки и внедрения ПО.
По описанным выше преимуществам, был выбран стандарт MSF как
наиболее гибкий и удобный для реализации ИС.
Одним из преимуществ данного стандарта считается возможность
управлять сразу и проектом разработки приложения, и внедрением
инфраструктуры.
Учет преимуществ Каскадной модели (Agile) важен в методологии
жизненного цикла по следующим причинам.
51
Дело в том, что не все проекты создания систем могут быть
структурированы таким образом, чтобы быть реализованными по
классическому проектному подходу. Это связано с неопределенностями,
которые не могут быть устранены (прояснены) в ходе периода планирования
и проектирования. В таком случае, в проекте необходимо предусматривать
наличие в будущем отдельных маленьких «подпроектов», в которых будет
производиться «дополнительное планирование».
Таким образом, инициация и верхнеуровневое планирование
проводятся для всего проекта, а последующие этапы: разработка,
тестирование и прочие проводятся для каждого мини-проекта отдельно. Это
позволяет передавать результаты этих мини-проектов, так называемые,
инкременты, быстрее, а приступая к новому подпроекту (итарации) в него
можно внести изменения без больших затрат и влияния на остальные части
проекта.
Идея каскадной (итеративной) разработки не нова. Своё нынешнее
название семейство гибких методологий получило в 2001 с публикации
Манифеста Agile (Agile Manifesto), закрепившем основные ценности и
принципы гибкой разработки программного обеспечения, в основе которых –
командная работа и адаптация, даже «любовь» к изменениям.
Самое главное достоинство Agile – его гибкость и адаптивность. Он
может подстроиться под практически любые условия и процессы
организации. Именно это обуславливает его нынешнюю популярность и то,
сколько систем для различных областей было создано на его основе.
Один из принципов Agile: «Реакция на изменения важнее следования
плану». Именно быстрая и относительно безболезненная реакция на
изменения является причиной тому, что многие крупные компании стремятся
сделать свои процессы более гибкими. Кроме того, Agile отлично подходит
для проектов с «открытым концом» — например, запуску сервиса или блога.
Эффективная предметная область Agile – разработка новых,
52
инновационных продуктов. В проектах по разработке таких продуктов
высока доля неопределённости, а информация о продукте раскрывается по
ходу проекта. В таких условиях реализовывать проект по «водопаду»
становится невозможно– нет информации для планирования.
Хотя в последние годы довольно часто говорится о том, что
классический водопадный подход устарел, его позиции достаточно сильны.
Большим плюсом данного подхода является то, что он требует от Заказчика и
руководства компании определить, что же они хотят получить, уже на
первом этапе проекта. Раннее включение привносит определённую
стабильность в работу проекта, а планирование позволяет упорядочить
реализацию проекта. Кроме того, этот подход подразумевает мониторинг
показателей и тестирование, что совершенно необходимо для реальных
проектов различного масштаба.
Потенциально, классический подход позволяет избежать стрессов
ввиду наличия запасного времени на каждом этапе, заложенного на случай
каких-либо осложнений и реализации рисков. Кроме того, с правильно
проведённым этапом планирования, руководитель проектов всегда знает,
какими ресурсами он обладает. Даже если эта оценка не всегда точная.
Методология MSF следует подходам классического менеджмента, с
элементами каскадного.
5 этапов традиционного менеджмента:
Этап 1. Инициация. Руководитель проекта и команда определяют
требования к проекту. На данном этапе часто проводятся совещания и
«мозговые штурмы», на которых определяется что же должен представлять
из себя продукт проекта. Такой этап обязательно должен быть проведен в
Школе.
Этап 2. Планирование. На данном этапе команда решает, как она будет
достигать цели, поставленной на предыдущем этапе. На данном этапе
53
команда уточняет и детализует цели и результаты проекта, а также состав
работ по нему. На основании данной информации команда формирует
календарный план и бюджет, оценивает риски и выявляет заинтересованные
стороны.
Этап 3. Разработка (доработка). Данная стадия реализуется не для всех
проектов — как правило она является частью фазы планирования. В фазе
разработки, характерной для технологических проектов, определяется
конфигурация будущего проекта и/или продукта и технические способы его
достижения. Например в ИТ-проектах на данном этапе выбирается язык
программирования.
Этап 4. Реализация и тестирование. На этой фазе происходит
собственно основная работа по проекту – написание кода, возведение здания
и тому подобное. Следуя разработанным планам начинает создаваться
содержание проекта, определённое ранее, проводится контроль по
выбранным метрикам. Во второй части данной фазы происходит
тестирование продукта, он проверяется на соответствие требованиям
Заказчика и заинтересованных сторон. В части тестирования выявляются и
исправляются недостатки продукта.
Этап 5. Мониторинг и завершение проекта. В зависимости от проекта
данная фаза может состоять из простой передачи Заказчику результатов
проекта или же из длительного процесса взаимодействия с клиентами по
улучшению проекта и повышению их удовлетворённости, и поддержке
результатов проекта. Последнее относится к проектам в области клиентского
сервиса и программного обеспечения.
Благодаря тому, что классический проектный менеджмент строго
привязан ко времени исполнения задач, как правило, заранее определённому
на этапе планирования, для реализации проектов в рамках данного подхода
отлично подходят инструменты календарно-сетевого планирования. Самым
54
распространённым инструментом календарно-сетевого планирования
является уже упомянутая ранее диаграмма Гантта.
Можно сделать предположение, что в рамках данного небольшого
проекта построения информационной системы можно предусмотреть все
неясные и неопределенные вопросы на начальных этапах (планирования и
проектирования), поэтому нет необходимости выбирать исключительно из
числа гибких методологий жизненного цикла.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В фазе формирования концепции имеют все шансы возникнуть
последующие риски:
Недальновидный анализ сроков проекта и его бюджета
Для ликвидации подобного рода рисков необходимо более подробно
изучать задачи и цели проекта, установить больше контрольных точек.
Неправильно выбранный проектный состав исполнителей
способен спровоцировать полное отсутствие командной работы
Данный риск снижается более кропотливым выбором профессионалов
в проектную группу.
На фазе планирования возможно появление следующих рисков:
Неправильно либо не совсем верно сформирована структура
выбираемого решения
Возможность возникновения данного риска находится в зависимости
от компетенции управляющего проектом, на котором лежит принятие
решение о выборе архитектуры разрабатываемого решения
В фазе разработки вероятны последующие риски:
Неправильное понимание технического задания, и как результат
некорректное программирование архитектуры и сдвиг сроков.
Минимизацией этого риска является более точное написание
технического задания, понятного программисту и интегратору