Федеральное государственное бюджетное образовательное учреждение

высшего образования

«ПЕРМСКИЙ ГОСУДАРСТВЕННЫЙ ГУМАНИТАРНО-ПЕДАГОГИЧЕСКИЙ

УНИВЕРСИТЕТ»

ФАКУЛЬТЕТ ИНФОРМАТИКИ И ЭКОНОМИКИ

Кафедра информатики и ВТ

Выпускная квалификационная работа

РАЗРАБОТКА МЕТОДИЧЕСКОГО ОБЕСПЕЧЕНИЯ ДИСЦИЛИНЫ

«УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ

СИСТЕМ»

Работу выполнила:

Студентка 1241 группы

направления подготовки

44.03.01 Педагогические образование,

профиль «Информатика и ИКТ»

Курапова Мария Владимировна

________________

(подпись)

«Допущена к защите в ГАК»

Зав. кафедрой информатики и ВТ,

канд. пед. наук, доцент

Шестаков А.П.

__________________

(подпись)

«___»______________20__г.

Руководитель:

кандидат тех. наук. доцент

Клигман Татьяна Ивановна

________________

(подпись)

ПЕРМЬ

2016

2

ОГЛАВЛЕНИЕ

ОГЛАВЛЕНИЕ ...................................................................................................... 2

ВВЕДЕНИЕ ............................................................................................................. 3

ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ЖИЗНЕННЫМ

ЦИКЛОМ ИС ......................................................................................................... 6

1.1 Дисциплина «Управление жизненным циклом информационных

систем» ................................................................................................................. 6

1.2 Информационные системы ..................................................................... 10

1.3 Жизненный цикл информационной системы ...................................... 13

1.4 Управление проектом ............................................................................... 15

ГЛАВА II. РАЗРАБОТКА ПРОЕКТА СОДЕРЖАНИЯ ДИСЦИПЛИНЫ

................................................................................................................................. 19

2.1 Теоретическое обеспечение ...................................................................... 19

Раздел 1. Жизненный цикл информационной системы ....................... 19

Раздел 2. Общие сведения об управлении проектами .......................... 34

Раздел 3. Модели разработки ..................................................................... 55

2.1 Методические рекомендации по организации..................................... 64

изучения дисциплины ..................................................................................... 64

ЗАКЛЮЧЕНИЕ ................................................................................................... 71

БИБЛИОГРАФИЧЕСКИЙ СПИСОК ............................................................ 72

ПРИЛОЖЕНИЕ 1 .............................................................................................. 77

ПРИЛОЖЕНИЕ 2 .............................................................................................. 86

3

ВВЕДЕНИЕ

Использование информационных систем становится неотъемлемой

составляющей деловой деятельности современного человека,

функционирования преуспевающих организаций.

На факультете информатики и экономики ПГГПУ в образовательной

программе бакалавриата по направлению «Бизнес-информатика» (профиль

«Архитектура предприятия») студентами изучаются дисциплины

«Управление жизненным циклом информационных систем» и «Управление

разработкой информационных систем».

В соответствии с ФГОС ВПО по направлению подготовки Бизнес-

информатики, область профессиональной деятельности бакалавров

включает:

— проектирование архитектуры предприятия;

— стратегическое планирование развития информационных

систем (ИС) и информационно-коммуникационных технологий (ИКТ)

управления предприятием;

— организацию процессов жизненного цикла ИС и ИКТ

управления предприятием;

— аналитическую поддержку процессов принятия решений для

управления предприятием.

Объектами профессиональной деятельности бакалавров являются:

— архитектура предприятия;

— методы и инструменты создания и развития электронных

предприятий и их компонент;

— ИС и ИКТ управления бизнесом;

— методы и инструменты управления жизненным циклом ИС и

ИКТ;

— инновации и инновационные процессы в сфере ИКТ.

Одна из дисциплин, которая изучается в рамках этого направления –

«Управление жизненным циклом информационных систем». Дисциплина

4

преподается второй год, еще не устоялась, и нет понимания того, что

должно быть изучено в рамках курса. Следовательно, методическое

обеспечение полностью не разработано.

В данной работе предложен проект содержания дисциплины

«Управление жизненным циклом информационных систем».

Объектом исследования является процесс обучения информационным

системам в ПГГПУ.

Предмет исследования – методическое обеспечение дисциплины

"Управление жизненным циклом информационных систем".

Цель: Разработка проекта содержания дисциплины "Управление

жизненным циклом информационных систем".

Задачи исследования:

1) исследовать предметную область и определить место дисциплины в

учебном плане;

2) проанализировать литературу и подобные учебные курсы в

предметной области информационных систем;

3) разработать теоретический материал дисциплины;

4) разработать практические задания для закрепления теории, включая

промежуточные тесты и темы рефератов;

5) подобрать методические рекомендации по изучению дисциплины

для преподавателей и студентов;

6) реализовать в системе электронной поддержки образовательных

курсов ПГГПУ – Moodle, для дальнейшего использования преподавателями

и студентами.

Выпускная квалификационная работа состоит из введения, трех глав,

заключения, списка литературы и приложения.

Во введении формулируются актуальность темы, объект и предмет

исследования, цель и задачи, дается краткая характеристика каждой

структурной части работы.

5

В первой главе описывается место дисциплины «Управление

жизненным циклом информационных систем» в учебном плане ПГГПУ

направления: 080500 – «Бизнес-информатика» профиль подготовки

«Архитектура предприятия», содержание и структура учебной дисциплины,

а так же результаты ее освоения. Приведены основные понятия управления

жизненным циклом ИС.

Во второй главе описывается пакет учебно-методического

обеспечения дисциплины, туда входят тексты лекций по трем разделам и

вопросы к ним. Даны методические рекомендации по изучению дисциплины.

В заключении перечисляются результаты и формулируются выводы

выпускной квалификационной работы.

В приложении приводится проект рабочей программы дисциплины, а

так же промежуточные тесты к каждому из трех разделов содержания

дисциплины.

6

ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ЖИЗНЕННЫМ

ЦИКЛОМ ИС

1.1 Дисциплина «Управление жизненным циклом информационных

систем»

Курс "Управление жизненным циклом информационных систем"

преподается студентам Пермского государственного гуманитарно-

педагогического университета, очной формы обучения, направления: 080500

– «Бизнес-информатика» профиль подготовки «Архитектура предприятия».

Направление появилось в 2012 году. Осваивается дисциплина на 3 курсе 5

семестра.

Перечень дисциплин, усвоение которых студентами необходимо

для изучения дисциплины «Управление жизненным циклом ИС»:

— Базы данных (3 семестр);

— Проектирование информационных систем (5 семестр);

— Архитектура предприятия (5 семестр);

— Информационные системы управления производственной

компанией (5 семестр);

— Стандартизация, сертификация и управление качеством

программного обеспечения (5 семестр).

Изучение дисциплины «Управление жизненным циклом ИС»

дает основу для изучения последующих курсов профиля «Архитектура

предприятия»:

— Управление разработкой ИС (6 семестр);

— Инструментальные средства проектирования информационных

систем (6 семестр);

— Сбор, анализ и управление требованиями к

автоматизированным информационным системам (6 семестр);

— Корпоративные информационные системы (7 семестр);

— Электронный бизнес (8 семестр).

Цель дисциплины - получение студентами знаний по организации

7

управления информационными системами на всех этапах ее жизненного

цикла.

Задачи дисциплины:

— обобщение, систематизация и углубление знаний студентов в

области информационных систем и технологий;

— рассмотрение и анализ особенностей управления ИС на

различных этапах их жизненного цикла; стратегий внедрения и проблем

эксплуатации и сопровождения ИС;

— выработка практических навыков выбора способа

автоматизации конкретного предприятия, в частности выбора

информационной системы для конкретных применений на основании

анализа общих свойств, функциональных возможностей и особых

требований.

Всего на изучения дисциплины отводится 108 часов, включая

лекции, практические и семинарские занятия, самостоятельную работу.

В процессе изучения дисциплины формируются следующие

компетенции:

Компетенция Вклад дисциплины в формирование компетенции

ПК-9 Использовать современные стандарты и методики, разрабатывать

регламенты для организации управления процессами жизненного

цикла ИТ-инфраструктуры предприятий.

ПК-3 Выбирать рациональные ИС и ИКТ-решения для управления

бизнесом.

ПК-14 Выполнять технико-экономическое обоснование проектов по

совершенствованию и регламентацию бизнес-процессов и ИТ-

инфраструктуры предприятия.

В результате изучения дисциплины "Управление жизненным циклом

информационных систем" студенты смогут применить полученные

теоретические и практические знания при прохождении научно-

8

исследовательской практики и подготовке отчета по практике, а также при

написании выпускной квалификационной работы.

Также в результате изучения дисциплины студент:

1. Должен знать:

- этапы жизненного цикла информационной системы;

- основные модели жизненного цикла информационной системы;

- риски, сопровождающие жизненный цикл информационной

системы;

2. Должен уметь:

- планировать этапы жизненного цикла информационной системы;

- определять необходимые ресурсы для обеспечения жизненного

цикла информационной системы;

- организовывать управление и управлять эксплуатацией и

сопровождением ИС.

3. Должен владеть:

- навыками планирования жизненного цикла информационной

системы.

Преподавание дисциплины «Управление жизненным циклом ИС»

предусматривает следующие формы организации учебного процесса:

лекции, практические занятия, самостоятельная работа студентов,

консультации, написание реферата. Результаты освоения дисциплины

достигаются путем чтения студентам лекций, проведения с ними

практических занятий, использования в процессе обучения компьютерной

техники и мультимедийной аппаратуры, организации самостоятельной

внеаудиторной работы студентов.

На практических занятиях следует привлекать студентов к разбору и

сравнительному анализу предлагаемых вариантов решения задачи.

Большее внимание уделить вариативным программам изучения данной

9

дисциплины, составленным с учетом жизненных запросов студентов, их

интересов и творческих склонностей. Целесообразно также использовать

для связи со студентами возможности компьютерных сетей (электронная

почта и др.).

«В рамках изучения дисциплины, для студентов проводится экскурсия

в международную компанию «Прогноз». Компания разрабатывает системы

бизнес-аналитики и визуализации данных для предприятий,

ориентированных на повышение эффективности управление и внедрения

информационных технологий.

Всего компанией реализовано множество проектов в 70 странах мира.

В большинстве из них использована собственная программная платформа

компании – Prognoz. Prognoz позволяет создавать гибкие,

многофункциональные и высокопроизводительные информационные

системы.

Актуальность систем бизнес-аналитики, поддержки принятия

решений очень высока. Внедрение таких систем позволяет организации

сокращать расходы, находить потенциальные источники роста, принимать

взвешенные управленческие решения.

В рамках занятий в компании «Прогноз», студенты знакомятся со

структурой предприятия и заданиями, которые решает каждое

подразделение.

На предприятии функционирует отдел по организации научной

деятельности и взаимодействию с учебными заведениями. Связь с

действующей компанией, поддерживающей все этапы жизненного цикла ИС,

позволяет студентам получить более полное представление об изучаемом

предмете.

Компания поддерживает несколько образовательных проектов для

студентов ВУЗов:

— Академия Prognoz – трехмесячный бесплатный

образовательный курс; отбор по конкурсу резюме и тестированию;

10

обучение Java, Java Script, базы данных, Web-разработка;

— Практика – деятельность соответствует учебным планам ВУЗа,

осуществляется по предварительной договоренности с руководителем

практики. Один из трех практикантов традиционно остается работать в

Прогнозе;

— Стажировка (это уже работа) – длительность от одного до трех

месяцев;

— Проект Prognoz BI University. Цель проекта – вовлечение

студентов в научно-исследовательскую работу.

Получить поддержку IT-компании в подготовке бакалавров

направления «Бизнес-информатика» (профиль – «Архитектура

предприятия») очень важно. Студенты не только получают новые знания,

но и более полное представление о том, чем они будут заниматься в рамках

своей профессиональной деятельности» [11].

Итогом изучения дисциплины является сдача зачета. При

выставлении зачета, учитывается посещаемость занятий, активность на

лекциях, результаты промежуточных тестирований в системе «Moodle»,

качество выполнения лабораторных работ. Кроме того, учитывается

выполнение задания преподавателя в качестве реферата.

1.2 Информационные системы

«Информация – это совокупность фактов, явлений, событий,

представляющих интерес, подлежащих регистрации и обработке.

Система – это объект, способный осуществлять хранение, обработку и

передачу информации.

Информационная система – это совокупность:

1) Функциональных процессов и связанных с ними информационных,

специфичных в конкретной области;

11

2) Средств, способов и методов, направленных на создание, сбор,

хранение, анализ, обработку и передачу информации, существенно

зависящих от специфики предметной области;

3) Совокупность процессов по управлению решением функциональных

задач, а так же информационными, материальными и денежными

потоками предметной области» [8].

«Информационная система (ИС) – взаимосвязанная совокупность

средств, методов и персонала, используемых для хранения, обработки и

выдачи информации в интересах достижения поставленной цели» [24].

Современные информационные технологии предоставляют широкий

набор способов реализации ИС, выбор которых осуществляется на основе

требований со стороны предполагаемых пользователей, которые, как

правило, изменяются в процессе разработки.

«База данных – это ядро информационной системы, состоит из

совокупности данных, которые имеют следующие свойства:

1) Интегрированность, направленная на решение общих задач одной

предметной области;

2) Модельность, структурированность отражающие некоторую часть

реального мира;

3) Незавиимость описания данных от прикладных программ» [8].

«Инофрмационный процесс – процесс создания, сбора, обработки,

накопления, хранения, поиска, распространения и потребления информации.

Информационный ресурс – это отдельные документы и отдельные

массивы документов в информационных системах (библиотеках, архивах,

фондах, банках данных, других видов информационных систем)» [9].

«В целом информационные системы определяются следующими

свойствами:

12

1) Любая информационная система может быть подвергнута анализу,

построена и управляема на основе общих принципов построения

систем;

2) Информационная система является динамичной и развивающейся;

3) При построении информационной системы необходим использовать

системный подход;

4) Выходной продукцией информационной системы является

информация, на основе которой принимаются решения;

5) Информационную систему следует воспринимать как человеко-

машинную систему обработки информации» [24].

Этапы развития информационных систем:

Период

времени

Концепция

использования

информации

Вид информационных

систем

Цель использования

1950-1960

годы

Бумажный поток

расчетных документов

Электроме-ханические

бухгалтерские машины

Упрощение

процедуры обработки

счетов и расчета

зарплаты

1960-1970

годы

Помощь в подготовке

отчетов

Управленческие

информационные

системы для

производственной

информации

Ускорение процесса

подготовки

отчетности

1970-1980

годы

Управленческий

контроль процессов

Системы поддержки

принятия решений

Выработка

рациональных

решений

С 1980 года

по н.в.

Информация –

стратегический ресурс,

обеспечивающий

конкурентное

преимущество

Стратегические

информационные

системы. Автоматизиро-

ванные офисы

Выживание и

процветание

организации

13

1.3 Жизненный цикл информационной системы

Одним из базовых понятий методологии проектирования ИС является

понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО

ИС – это непрерывный процесс, начинающийся с момента принятия решения

о необходимости создания ИС и заканчивающийся в момент полного ее

изъятия из эксплуатации. Иначе ЖЦ ПО ИС можно представить как ряд

событий, происходящих с системой в процессе ее создания и использования.

Основным нормативным документом, регламентирующим ЖЦ ИС,

является международный стандарт ISO/IEC 12207 (ISO – International

Organization of Standardization – Международная организация по

стандартизации, IEC – International Electrotechnical Comission –

Международная комиссия по электротехнике). Он определяет структуру ЖЦ,

содержащую процессы, действия и задачи, которые должны быть выполнены

во время создания ИС. Вданном стандарте процесс определяется как

совокупность взаимосвязанных действий, преобразующий некоторые

входные данные в выходные [23] .

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех

группах процессов:

– основные процессы ЖЦ ПО (приобретение ПО заказчиком, поставка

программного продукта поставщиком заказчику, разработка (создание ПО),

эксплуатация ПО пользователем, сопровождение службой сопровождения);

– вспомогательные процессы, обеспечивающие выполнение основных

процессов (документирование, управление конфигурацией (учет версий),

обеспечение качества, верификация (определение соответствия

требованиям), аттестация (удостоверение правильности), совместная оценка

(соответствие характеристик ПО исходным требованиям), аудит (процессы

ревизии), решение проблем (устранение дефектов и ошибок));

14

– организационные процессы (управление проектами, создание

инфраструктуры проекта (выбор аппаратных и программных средств,

технологии, стандартов, т.д.), определение, оценка и улучшение

(корректировка) самого ЖЦ, обучение пользователя).

Стандарт ИСО 12207 пригоден для любых моделей жизненного цикла,

методологий и технологий разработки ИС без конкретизации методов их

реализации, действий и задач каждого из этапов жизненного цикла, но с

описанием структуры этих процессов.

Модель ЖЦ ИС – комбинация последовательности этапов жизненного

цикла и переходов между ними, необходимых для гарантированного

достижения поставленной для реализации проекта цели.

Фазы жизненного цикла информационной системы фиксированы для

различных отраслей человеческой деятельности:

‒ Замысел (планирование проекта).

‒ Анализ и постановка задачи.

‒ Проектирование.

‒ Разработка.

‒ Развертывание и внедрение.

‒ Эксплуатация.

‒ Поддержка.

‒ Утилизация.

15

1.4 Управление проектом

Общепринятые методики управления проектами, стандарты и

ключевые термины содержатся в руководстве по управлению проектами

«Project Management Body of Knowledge» (PMBOK), которое, по существу,

является сводом профессиональных знаний по управлению проектами. Само

понятие «проект» широко используется в повседневной жизни. В теории

управления проектами этот термин является ключевым, и в руководстве

PMBOK приведено следующее определение: «проект – это временное

предприятие, предназначенное для создания уникальных продуктов, услуг

или результатов».

При этом, термин «временное» означает, что у любого проекта есть

четкое начало и четкое завершение. Завершение наступает, когда достигнуты

цели проекта; или осознано, что цели проекта не будут или не могут быть

достигнуты; или исчезла необходимость в проекте, и он прекращается.

Проекты могут различаться своими целями, масштабом,

протяженностью во времени, сферой деятельности и т.д. Но у всех проектов

обязательно определена конкретная цель, и она является уникальной;

выделены ресурсы и существуют временные рамки для достижения цели.

Отличие проекта от повседневной операционной деятельности состоит

в наличии у проекта уникальной цели и временных ограничений.

Повседневные операции выполняются постоянно, имеют повторяющийся

характер, в то время как проекты являются временными и уникальными.

Конечные цели проекта и операционной деятельности отличаются

коренным образом. Задача проекта - достижение поставленной цели, после

чего проект завершается. Операционная деятельность, напротив, обычно

служит для обеспечения нормального течения бизнеса. Проект отличается

тем, что он завершается после выполнения поставленных конкретных задач,

в то время как операции получают новые цели и продолжают выполняться.

16

Проекты являются средством организации операций, которые не могут

быть проведены в рамках обычной деятельности организации. Таким

образом, проекты часто используются в качестве средства выполнения

стратегического плана организации.

Под управлением проектом понимается деятельность, направленная на

эффективное достижение целей проекта в установленные сроки, в рамках

утвержденного бюджета, с заданным качеством.

Управление проектами - это приложение знаний, навыков,

инструментов и методов к операциям проекта для удовлетворения

требований, предъявляемых к проекту. Управление проектами выполняется с

помощью применения и интеграции процессов управления проектами:

инициации, планирования, исполнения, мониторинга и управления,

завершения.

В управление проектом входит:

Определение требований;

Установка четких и достижимых целей;

Уравновешивание противоречащих требований по

качеству, содержанию времени и стоимости;

Коррекция характеристик, планов и подхода в соответствии

с мнением и ожиданиями различных участников проекта.

Итак, управление проектом состоит в планировании, организации и

управлении задачами и ресурсами для достижения цели проекта и контроле

стратегии реализации проекта.

План проекта представляет собой модель, описывающую реальный

проект в терминах задач, ресурсов, сроков, затрат. Что означают эти

термины?

«Задача (task) – деятельность, осуществляемая в рамках проекта, для

достижения определенного результата. Задачи являются основными блоками,

из которых строится любой проект, они представляют работу, которую

нужно выполнить для достижения поставленной цели. Во всем проекте набор

17

задач характеризуется их логической последовательностью, а каждая задача -

длительностью и требованиями к ресурсам.

Ресурсы – исполнители, оборудование и материалы, необходимые для

выполнения задачи.

Назначения – связь конкретной задачи с ресурсами, выделенными для

ее выполнения.

Суммарная задача (фаза, summary task) – состоит из нескольких задач.

Результат фазы обобщает (суммирует) результаты задач, входящих в нее.

Суммарная задача может содержать в себе как задачи, так и другие

суммарные задачи.

Веха (milestone) – задача, достижение результата которой особенно

важно для проекта. Вехой может быть завершающая задача фазы. Как

правило, веха используется для обозначения окончания основных этапов

проекта.

Трудозатраты (work) – для задач: объем работ (в единицах рабочего

времени) необходимый ресурсу (исполнителю) для выполнения задачи.

Длительность задачи (duration) – время, которое запланировано для

работы над задачей» [19].

Такие важные параметры проекта как содержание проекта, время и

стоимость связаны между собой. Изменение значения одного из этих

параметров вызывает изменение значений двух других. Например, при

увеличении объема работ увеличивается стоимость и (или)

длительность. Тройку «объем работ, время, стоимость» называют «тройным

ограничением» или «проектным треугольником». Это одна из простых

моделей, показывающая взаимозависимость характеристик проекта.

Этап Артефакты

Инициация - Концепция

Планирование - Требования к системе

- План управления

Реализация - Рабочее описание

18

- Отчет о состоянии

- Документы проекта

- Исходные коды

Завершение - Протоколы и приемо-сдаточные испытания

- Итоговый отчет

- Архив проекта

19

ГЛАВА II. РАЗРАБОТКА ПРОЕКТА СОДЕРЖАНИЯ

ДИСЦИПЛИНЫ

2.1 Теоретическое обеспечение

Раздел 1. Жизненный цикл информационной системы

Тема 1. Структура жизненного цикла ИС

«Жизненный цикл информационной системы – непрерывный процесс,

началом которого становится момент принятия решения о необходимости

системы, а завершением – ее изъятие из эксплуатации» [6]. Этапы создания

системы до момента ввода в эксплуатацию могут рассматриваться как

самостоятельные проекты, каждый из которых имеет конкретный результат и

ограничения.

А так как процесс создания и конфигурирования для различных

информационных систем включает в себя один набор этапов, то можно

говорить о моделях жизненного цикла. «Модель ЖЦ ИС – комбинация

последовательности этапов жизненного цикла и переходов между ними,

необходимых для гарантированного достижения поставленной для

реализации проекта цели» [6].

Сами фазы жизненного цикла фиксированы и для различных отраслей

человеческой деятельности, по сути, одинаковы:

‒ Замысел (планирование проекта).

‒ Анализ и постановка задачи.

‒ Проектирование.

‒ Разработка.

‒ Развертывание и внедрение.

‒ Эксплуатация.

20

‒ Поддержка.

‒ Утилизация.

Можно говорить о том, что средняя продолжительность подобного

цикла составляет порядка 15 лет, однако следует учитывать, что в

зависимости от огромного числа различных факторов, обусловленных

спецификой предприятия, отрасли, самой информационной системы сроки

физического и морального старения техники и ПО будут значительно

отличаться. А значит, еще при проектировании ИС необходимо четко

представлять себе возможности ее дальнейшей модернизации, в том числе

факторы, которые могут вызвать эту необходимость.

Важно понимать, что переход на новые программные решения – это не

утилизация старой и проектирование новой системы. Измениться может

практически все: форматы данных, работающий с системой персонал,

поддерживающая инфраструктура. Остается только информация, и именно

она является связующим звеном, позволяющим говорить о работе с одной и

той же информационной системой.

Порядка трети ИС прекращают свое существование еще на этапе

проектирования, причиной чего часто становится несоответствие методов

управления проектами (в том числе, анализа) сложности самого проекта,

которая постоянно возрастает в условиях рыночной экономики, где число

стейкхолдеров постоянно увеличивается, ограничения по срокам и стоимости

возрастают, появляются новые конкурирующие компании и продукты. Не

всегда уровень выбираемых компаниями технологий анализа /

проектирования систем, как и методик управления проектом внедрения

соответствует специфике бизнеса и возрастающим требованиям к

автоматизации процессов.

Рассмотрим подробней каждый этап жизненного цикла ИС.

Планирование проекта

21

Обследование проводится в обязательном порядке на самом первом

этапе для сбора информации о целях и задачах компании в целом и

внедряемой системы в частности, а также получению данных об основных

бизнес-процессах и покрывающем их ландшафте информационных систем

(для определения в нем места внедряемого решения). Важно верно

определить:

‒ Организационный объем проекта (затрагиваемые реализацией

проекта подразделения).

‒ Наличие зависимостей от других проектов.

ПРИМЕР

Если в этот же период внедряются другие системы и в обоих проектах

задействованы одни и те же специалисты ИТ-департамента, одно

оборудование, если они оба требуют незапланированных в исходном

бюджете дополнительных расходов.

‒ Планируемые финансовые, инфраструктурные и человеческие

ресурсы, бюджет проекта (включая необходимые закупки – например,

лицензии от поставщика ПО – и планируемые затраты при необходимости

оплаты услуг подрядчика по сопровождению, по обслуживанию серверов и

т.д.). Принято различать две категории обследования: ‒ Экспресс-

обследование, имеющее своим результатом:

Краткое описание текущей бизнес-модели предприятия;

Коммерческое предложение со сформулированными проблемами, а

также ориентировочными сроками и бюджетом работ по дальнейшему

информационному обследованию и непосредственно внедрению системы.

‒ Информационное обследование, по результатам проведения которого

должны быть подготовлены:

Полное описание текущей бизнес-модели предприятия заказчика;

Утвержденный план работ по разработке и внедрению (включая

состав группы внедрения с обеих сторон).

22

Также по результатам информационного обследования со стороны

заказчика должны быть приняты все организационные меры для обеспечения

реализации проекта. В частности, это относится к внутренним приказам и

документам предприятия заказчика (для назначения ответственных за

предоставление информации и взаимодействие с проектной командой в

рамках внедрения).

Анализ и постановка задачи

Анализ требований является первой фазой разработки ПО, на которой

требования заказчика уточняются, формализуются и документируются.

Фактически на этом этапе даётся ответ на вопрос: «Что должна делать

будущая система?». Именно здесь лежит ключ к успеху всего проекта. В

практике создания больших систем ПО известно немало примеров неудачной

реализации проекта именно из-за неполноты и нечёткости определения

системных требований.

‒ Список требований к разрабатываемой системе должен включать:

совокупность условий, при которых предполагается эксплуатировать

будущую систему (аппаратные и программные ресурсы, предоставляемые

системе; внешние условия её функционирования; состав людей и работ,

имеющих к ней отношение);

‒ Описание выполняемых системой функций;

‒ Ограничения в процессе разработки (директивные сроки завершения

отдельных этапов, имеющиеся ресурсы, организационные процедуры и

мероприятия, обеспечивающие защиту информации).

Целью анализа является преобразование общих, неясных знаний о

требованиях к будущей системе в точные (по возможности) определения. На

этом этапе определяются:

‒ архитектура системы, её функции, внешние условия, распределение

функций между аппаратурой и ПО;

‒ интерфейсы и распределение функций между человеком и системой;

23

‒ требования к программным и информационным компонентам ПО,

необходимые аппаратные ресурсы, требования к БД, физические

характеристики компонентов ПО, их интерфейсы.

Проектирование

Проектирование включает в себя два основных аспекта: техническое и

рабочее проектирование. В первом случае проводится описание технических

деталей (к примеру, модели данных и интерфейса), а также моделирование

ситуаций, в которых система будет использоваться – для дальнейшей

разработки сценариев использования системы и ее тестирования на их

основе. При рабочем же проектировании могут составляться блок-схемы и

алгоритмы для программных модулей. В целом же техническое

проектирование ИТ-системы предполагает детальную подготовку к этапу

настройки / развертывания модулей системы, для чего необходимо решить

несколько задач:

‒ Сформировать список модулей и функций системы, необходимых для

поддержки определенных на этапе анализе автоматизируемых бизнес-

процессов.

‒ Сформировать список справочников систем (будущей и если

применимо, текущей) для дальнейшего переноса и обновления данных.

‒ Определить примерный сценарий работы системы по категориям

пользователей для формирования необходимого набора диалогов и процедур

проектируемой системы (включая реакции на все возможные и даже очень

маловероятные действия со стороны пользователя).

‒ Определить элементы интерфейса пользователей (в случае гибкого

или разрабатываемого «с нуля» решения) для достижения удобства работы с

системой.

‒ Сформировать список отчетов / панелей мониторинга (включая их

формы и обязательные для реализации элементы). Эти отчеты в дальнейшем

будут использоваться как для учетных целей, так и для целей мониторинга

24

системы ее администратором (в части формирования и сбора статистики по

нагрузке на ее отдельные модули, свободных ресурсах, активности

пользователей и т.п.). ‒ Определить перечень настроек функциональных

компонентов системы в соответствии со выделенными на предыдущем этапе

требованиями.

‒ Определить необходимость, возможности и пути интеграции с

существующими и планируемыми к реализации системами на предприятии

заказчика, чтобы своевременно предусмотреть технические средства для

интеграции.

На этапе детального проектирования важно крайне четко определить

все функциональные возможности системы и определить ее место в общей

программной архитектуре предприятия.

ПРИМЕР

Если предполагается, что система взаимодействия с клиентами CRM

будет получать данные из личных кабинетов клиентов на портале компании,

необходимо предусмотреть подобную интеграцию. Если в компании уже

внедрена и работает ERP-система, CRM должна получать и предоставлять ей

данные.

С организационной перспективы к этому моменту важна подготовка

иерархической структуры работ / базового календарного плана / дорожной

карты, которые бы позволили управлять проектом на протяжении всей его

реализации.

Разработка

Разработка информационной системы включает в себя все работы по

созданию информационного программного обеспечения и его компонентов в

соответствии с заданными требованиями. Разработка информационного

программного обеспечения также включает:

‒ оформление проектной и эксплуатационной документации;

25

‒ подготовку материалов, необходимых для тестирования

разработанных программных продуктов;

‒ разработку материалов, необходимых для обучения персонала.

Развертывание и внедрение

Этап развертывания системы является одним из наиболее важных с

точки зрения распределения ответственности за работы между заказчиком и

подрядчиком. Исполнитель выполняет основную задачу – инсталляцию

модуля на рабочий сервер с перенесением на него итоговую конфигурацию с

тестового сервера. Однако при верном последовательном обучении и

вовлечении специалистов заказчика в процесс создания / внедрения системы

остальные операции могут быть осуществлены ими:

‒ Предшествующее работам обеспечение охвата всех

автоматизируемых рабочих мест пользователей функционирующей

локальной вычислительной сети.

‒ Настройка рабочего сервера.

‒ Определение перечня / количества рабочих мест, которые

необходимо развернуть для опытно-промышленной эксплуатации.

‒ Развертывание рабочих мест пользователей с определением прав

доступа.

‒ Подготовка наиболее актуальной информации по каждому модулю

для ввода в систему (включая подготовку, дополнение и выверку

справочников, которые могли потерять актуальность за время между

тестовой эксплуатацией и развертыванием системы).

‒ Организация поддержания данных системы в актуальном состоянии

(в том числе при интеграции с другими системами).

Целью данного этапа является подготовка модуля системы к опытно-

промышленной эксплуатации – подготовка конечных пользователей, ввод

начальных данных, подготовка приказов по предприятию заказчика о пере-

даче модуля системы в опытно-промышленную эксплуатацию.

26

Среди основных работ этапа:

‒ Обеспечить безусловное выполнение условий готовности модулей

системы к сдаче в опытно-промышленную эксплуатацию (закрепленных в

отдельном документе).

‒ Ввести и выверить начальные данные (например, начальные остатки)

по каждому модулю для ввода информации в систему.

‒ Отработать на рабочих местах пользователей модуля системы

практические действия пользователей в параллельном режиме с

имеющимися приложениями.

‒ Разработать, согласовать с подрядчиком и утвердить регламент

взаимодействия подразделений заказчика, участвующих в опытно-

промышленной эксплуатации модуля системы.

‒ Осуществить интеграцию модуля с другими модулями или внешними

системами, внедренными ранее.

‒ Подготовить и издать приказ по предприятию заказчика о передаче

модуля системы в опытно-промышленную эксплуатацию, который должен

содержать:

наименование модуля системы, проходящего опытно-промышленную

эксплуатацию;

наименование компании-исполнителя;

сроки проведения опытно-промышленной эксплуатации;

список должностных лиц со стороны заказчика и исполнителя,

ответственных за проведение опытно-промышленной эксплуатации модуля;

перечень подразделений предприятия заказчика, участвующих в

проведении опытно-промышленной эксплуатации;

порядок и сроки перевода персонала заказчика на работу в условиях

функционирования модуля системы.

К моменту опытно-промышленной эксплуатации уже должны быть

проведены следующие работы:

27

‒ Модули системы успешно перенесены и функционируют на рабочем

сервере и автоматизированных рабочих местах пользователей (с разделением

прав доступа).

‒ Подготовлены, дополнены и введены недостающие справочники по

каждому модулю системы, проведена выверка введенных в систему

недостающих справочников.

‒ Заказчиком утверждены итоговые документы.

Эксплуатация

Этап эксплуатации системы является наиболее ожидаемым для бизнес-

заказчиков, которые только сейчас начинают получать ожидаемый возврат

инвестиций и видеть реальный результат внедрения. Однако это и самый

опасный этап, так как полученный результат может не соответствовать

первоначальным ожиданиям и представлениям, как о функциональности, так

и даже о внешнем виде / интерфейсе системы. Технические специалисты и

подрядчик фокусируются на решении задач бесперебойной работы,

обслуживания баз данных, а в случае необходимости – на донастройке

системы (что означает одновременное наступление стадии модернизации,

продолжающееся параллельно с эксплуатацией). Но бизнес-заказчик и

спонсор системы, как и все участники процесса сбора требований часто

имеют собственное представление о целевом состоянии системы, именно

поэтому критически важно с самого начала вовлекать в проект специалистов,

переводящих пожелания бизнеса в плоскость разработчиков (данная роль в

английской терминологии получила название IT/Business Relationship

Manager).

Стадия сопровождения, приводящая к изменениям к системе в

процессе эксплуатации (по окончании приемки работ) охватывает несколько

аспектов:

‒ Устранение замечаний, не затрагивающее изменение ТЗ.

28

‒ Обновления (по сути – новые версии системы), выпускаемые при

накоплении критического объема доработок.

‒ Увеличение производительности системы.

Важно отметить, что на сегодняшний день основной задачей компании-

подрядчика является не просто настройка системы, но и передача

накопленных и базирующихся на опыте множества проекта знаний и методик

работы с внедренным программным решением. По окончании проекта

специалисты компании-заказчика должны быть способны самостоятельно

осуществлять полноценную поддержку и развитие системы. В первую

очередь, это относится к развитию уже созданных модулей,

совершенствованию функциональности, реализации новых задач для новых

категорий пользователей, формирование аналитических отчетов и панелей

мониторинга. Разумеется, часто заказчик принимает решение о продолжении

сотрудничества с подрядчиком, внедрявшим систему, в части ее

сопровождения. Это относится и к базовым функциям (построению

дополнительных типов отчеты или изменению параметров настроек), и к

технологической и методической поддержке.

Сопровождение эксплуатации

В условиях промышленной эксплуатации в течение определенного

договором времени после сдачи модуля системы со стороны исполнителя-

подрядчика проводится наблюдение за его функционированием и по мере

необходимости оказание помощи специалистам заказчика по устранению

замечаний. Предприятие-подрядчик включается в работу только при

необходимости значительных доработок либо если таковое определено

заключенным контрактом на поддержку. Это объясняется тем, что ключевая

необходимая для успешной и бесперебойной работы системы

функциональность и программно-аппаратная база уже была сформирована на

предыдущих этапах и специалисты заказчика уже в состоянии осуществлять

29

стандартную техническую поддержку на своем предприятии самостоятельно.

Именно в это время устраняются основные возникающие замечания / ошибки

/ неточности первоначальных расчетов нагрузки на систему.

Техническая поддержка системы начинается после приема в

промышленную эксплуатацию и может продолжаться до снятия с

эксплуатации и утилизации системы. Как правило, варианты осуществляемой

поддержки варьируются по процентам от стоимости приобретенного ПО, в

зависимости от набора оказываемых услуг, а объем и периодичность

выполнения работ на данном этапе определяются отдельным договором.

В качестве поддержки могут предоставляться следующие услуги в раз-

личных комбинациях в зависимости от прописанных в договоре условий:

‒ Консультирование по «горячей линии» (телефон, e-mail, skype) по

определенному в договоре графику.

‒ Консультирование по вопросам программно-аппаратной платформы

системы.

‒ Создание новых учетных записей пользователей системы.

‒ Настройка форм отчетов и панелей мониторинга для определенных

групп пользователей заказчика.

‒ Диагностика и устранение неисправностей (с учетом гарантии на

сами программные решения).

‒ Уведомление о выпуске обновлений и их загрузка через Интернет.

‒ Замена ключей электронной защиты, переустановка ПО в случае

необходимости (например, при замене компьютерной базы заказчика).

‒ и др.

Утилизация

Не существует системы, которая бы использовалась всегда – а значит,

необходимо предусмотреть условия, при которых понадобится отказаться от

системы и вывести ее из эксплуатации. Эта деятельность, в свою очередь,

также является проектом, ключевая цель которого – снятие системы (или ее

30

отдельных модулей) с эксплуатации, что чаще всего проводится уже после

внедрения новой системы.

Вопросы

1. Что понимают под ЖЦИС?

2. Перечислите этапы ЖЦ ПО.

3. Поясните стадию проектирования?

4. Что включает в себя разработка информационного программного

обеспечения?

Тема 2. Модели жизненного цикла ИС

Модель ЖЦ ИС – комбинация последовательности этапов жизненного

цикла и переходов между ними, необходимых для гарантированного

достижения поставленной для реализации проекта цели.

Каскадная модель

Каскадная модель жизненного цикла, также называемая моделью

«водопада» (waterfall), была разработана еще в 80-х годах, и на протяжении

многих лет она считалась стандартом для разработки ПО. Данная модель

характеризуется тем, что этапы строго последовательны и переход между

ними невозвратный. Это означает, что в рамках каскадной модели переход к

следующему этапу (например, от проектирования и сбора требований к раз-

работке и развертыванию) может произойти только по завершении

предыдущего этапа. Модель «водопада» была применена одной из первых и

одно из ее основных достоинств в возможности планирования сроков и

стоимости каждого этапа – однако, на практике разработка системы почти

никогда не проходит строго в соответствии с жесткой заранее продуманной

схемой. В частности, это касается сбора требований, так как реально при

старте проекта требования бывают определены только частично и в

31

дальнейшем уточняются, изменяются и дополняются. К тому же, если

изначально требования были определены неточно, высока вероятность того,

что система не будет удовлетворять потребностям заказчика.

Каскадная модель с промежуточным контролем

В качестве одной из вариаций каскадной модели для того, чтобы

предусмотреть возможность возвращения к предыдущим этапам для

внесения определенных изменений и пересмотра отдельных вопросов, была

создана каскадная модель с промежуточным контролем.

Она предполагает увеличенное время, отведенное на разработку, за

счет проведения промежуточных корректировок между фазами жизненного

цикла. В свою очередь, это снижает риски получения некачественного

продукта на выходе и повышает надежность системы в целом. Важно

отметить, что согласование результатов в двух описанных моделях

происходит только по окончании внедрения – а значит, повышается

32

вероятность получения программного продукта, который морально устареет

либо не будет востребован рынком. Еще больше увеличивают риски

возможные неточности в исходном техническом задании. В итоге можно

говорить о проблеме определенной задержки в получении результата,

которая не может быть решена в «каскадном» варианте разработки и

внедрения системы.

Итеративная (инкрементная, эволюционная) модель

Модель предполагает разбиение жизненного цикла проекта на

последовательность итераций, каждая из которых напоминает «мини-

проект», включая все процессы разработки в применении к созданию

меньших фрагментов функциональности, по сравнению с проектом в целом.

Цель каждой итерации – получение работающей версии программной

системы, включающей функциональность, определённую интегрированным

содержанием всех предыдущих и текущей итерации.

Результат финальной итерации содержит всю требуемую

функциональность продукта.

Таким образом, с завершением каждой итерации продукт получает

приращение – инкремент – к его возможностям, которые, следовательно,

развиваются эволюционно.

Спиральная модель

Фазы жизненного цикла данной модели непоследовательны, то есть

допустимо (но не обязательно!) начало работ над следующим этапом до

33

завершения предыдущего. Таким образом, суть спиральной модели состоит в

возможности прохождения всех этапов жизненного цикла системы в

несколько итераций, каждый раз создавая новый прототип и проверяя

актуальность требований, по которым он создавался, внося технические

доработки в интерфейс и функциональность. Подобная гибкость позволяет

использовать модель на предприятиях любого масштаба.

Прототип крайне важен в ситуациях, когда требуется разъяснить и

уточнить требования, выбрать концептуальное решение или даже в целом

определить целесообразность реализации проекта. При этом сам прототип

может либо моделировать исключительно пользовательский интерфейс, либо

архитектурную сторону системы (логика обработки и хранения данных).

Это означает, что процесс создания системы и само управление

проектом будет более гибким и управляемым, с совершенствованием

системы на каждом «витке спирали», то есть при выпуске каждой версии.

Уменьшаются риски (в том числе, финансовые) для заказчика и спонсора

системы, которые могут отказаться от проекта еще на этапе показа первого

прототипа в случае абсолютного его несоответствия ожиданиям и

потребностям (либо в случае изменения рыночной ситуации).

34

Как правило, подобная модель применяется при разработке нетиповых

систем, предоставляя возможность оперативно создать прототип

программного продукта для проверки его работоспособности с

пользователями и соответственно, быстрого получения комментариев и

замечаний к системе.

Вопросы

1. Перечислите модели ЖЦ.

2. Что предполагает каскадная модель?

3. Что представляет собой поэтапная модель с промежуточным

контролем?

4. Поясните суть спиральной модели.

Тест 1 (приложение 2).

Раздел 2. Общие сведения об управлении проектами

Тема 3. Управление проектами

Общепринятые методики управления проектами, стандарты и

ключевые термины содержатся в руководстве по управлению проектами

«Project Management Body of Knowledge» (PMBOK), которое, по существу,

является сводом профессиональных знаний по управлению проектами. Само

понятие «проект» широко используется в повседневной жизни. В теории

управления проектами этот термин является ключевым, и в руководстве

PMBOK приведено следующее определение: «проект – это временное

предприятие, предназначенное для создания уникальных продуктов, услуг

или результатов».

При этом, термин «временное» означает, что у любого проекта есть

четкое начало и четкое завершение. Завершение наступает, когда достигнуты

35

цели проекта; или осознано, что цели проекта не будут или не могут быть

достигнуты; или исчезла необходимость в проекте, и он прекращается.

Проекты могут различаться своими целями, масштабом,

протяженностью во времени, сферой деятельности и т.д.

Отличие проекта от повседневной операционной деятельности состоит

в наличии у проекта уникальной цели и временных ограничений.

Повседневные операции выполняются постоянно, имеют повторяющийся

характер, в то время как проекты являются временными и уникальными.

Конечные цели проекта и операционной деятельности отличаются

коренным образом. Задача проекта - достижение поставленной цели, после

чего проект завершается. Операционная деятельность, напротив, обычно

служит для обеспечения нормального течения бизнеса. Проект отличается

тем, что он завершается после выполнения поставленных конкретных задач,

в то время как операции получают новые цели и продолжают выполняться.

Проекты являются средством организации операций, которые не могут

быть проведены в рамках обычной деятельности организации. Таким

образом, проекты часто используются в качестве средства выполнения

стратегического плана организации.

Под управлением проектом понимается деятельность, направленная на

эффективное достижение целей проекта в установленные сроки, в рамках

утвержденного бюджета, с заданным качеством.

Управление проектами - это приложение знаний, навыков,

инструментов и методов к операциям проекта для удовлетворения

требований, предъявляемых к проекту. Управление проектами выполняется с

помощью применения и интеграции процессов управления проектами:

инициации, планирования, исполнения, мониторинга и управления,

завершения.

В управление проектом входит:

Определение требований

Установка четких и достижимых целей

36

Уравновешивание противоречащих требований по

качеству, содержанию времени и стоимости

Коррекция характеристик, планов и подхода в соответствии

с мнением и ожиданиями различных участников проекта.

Итак, управление проектом состоит в планировании, организации и

управлении задачами и ресурсами для достижения цели проекта и контроле

стратегии реализации проекта.

Основы планирования

Составляющие проектного плана

План проекта представляет собой модель, описывающую реальный

проект в терминах задач, ресурсов, сроков, затрат. Что означают эти

термины?

«Задача (task) – деятельность, осуществляемая в рамках проекта, для

достижения определенного результата. Задачи являются основными блоками,

из которых строится любой проект, они представляют работу, которую

нужно выполнить для достижения поставленной цели. Во всем проекте набор

задач характеризуется их логической последовательностью, а каждая задача -

длительностью и требованиями к ресурсам.

Ресурсы – исполнители, оборудование и материалы, необходимые для

выполнения задачи.

Назначения – связь конкретной задачи с ресурсами, выделенными для

ее выполнения.

Проект, как правило, содержит большое количество задач, поэтому

весь набор задач необходимо представить в виде укрупненных групп,

логически связанных между собой. Так формируются суммарные задачи

(фазы)

Суммарная задача (фаза, summary task) – состоит из нескольких задач.

Результат фазы обобщает (суммирует) результаты задач, входящих в нее.

37

Суммарная задача может содержать в себе как задачи, так и другие

суммарные задачи.

Веха (milestone) – задача, достижение результата которой особенно

важно для проекта. Вехой может быть завершающая задача фазы. Как

правило, веха используется для обозначения окончания основных этапов

проекта.

Трудозатраты (work) – для задач: объем работ (в единицах рабочего

времени) необходимый ресурсу (исполнителю) для выполнения задачи.

Длительность задачи (duration) – время, которое запланировано для

работы над задачей» [19].

Трудозатраты отличаются от длительности задачи. Ресурсу может

потребоваться 24 часа на выполнение задачи, а длительность задачи - 8

часов. Это означает, что на выполнение данной задачи необходимо назначить

не менее трех исполнителей. После установления списка задач проекта,

длительностей задач, необходимо указать, как задачи взаимосвязаны друг с

другом, их логическую зависимость.

«Зависимости и связи – определяют логику связи одной задачи с

другой, показывая, как одна задача влияет на другую. Например, задача №2

начинается только когда закончится задача №1, или задача №1 и задача №2

начинаются обязательно в одно время» [19].

Создание назначений, т.е. назначение ресурсов на задачи, помогает

решить ряд проблем планирования:

Определить конкретных сотрудников, ответственных за

выполнение задачи, этапа и т.д.

Контролировать объем работы, произведенной

сотрудниками или оборудованием, назначенными на задачу, или

контролировать объем материалов, использованных для выполнения

задачи.

Составлять более гибкое расписание задач.

38

Перераспределять ресурсы для оптимизации загрузки

персонала (сотрудников) и оборудования.

Произвести расчет времени, необходимого для выполнения

задач, стоимость использования ресурсов для выполнения задач, для

выполнения всего проекта.

Проектный треугольник

Проект существует для достижения определенного конкретного

результата в рамках временных и бюджетных ограничений. Какое влияние

оказывают ограничения на планирование проекта? Временные ограничения

могут затрагивать дату начала проекта или дату его окончания, могут

существовать временные ограничения на выполнение отдельных задач или

привязка задач к конкретным датам; ограничения влияют на выделяемые для

проекта ресурсы, на затраты; ограничением являются требования к уровню

качества.

«Такие важные параметры проекта как содержание проекта, время и

стоимость связаны между собой. Изменение значения одного из этих

параметров вызывает изменение значений двух других. Например, при

увеличении объема работ увеличивается стоимость и (или)

длительность. Тройку «объем работ, время, стоимость» называют «тройным

ограничением» или «проектным треугольником»» [19]. Это одна из простых

моделей, показывающая взаимозависимость характеристик проекта.

Тройное ограничение приходится учитывать при согласовании

разнообразных требований проекта. Качество исполнения проекта зависит от

уравновешивания этих трех факторов. Проекты с высоким качеством

организации дают требуемый продукт, услугу или результат,

соответствующие содержанию проекта, во время и в пределах

установленного бюджета. Взаимоотношения между этими факторами таково,

что, если один из этих факторов изменится, то с большой долей вероятности

будет затронут как минимум еще один фактор.

39

Вопросы

1. Что такое проект?

2. Основные критерии, по которым проект отличается от повседневных

операций?

3. Как называется работа, осуществляемая в рамках проекта для

достижения определенного результата?

4. Что такое фаза или суммарная задача?

5. Может ли фаза состоять из задач?

6. Может ли фаза включать в себя другую фазу?

7. Как называется задача, в результате выполнения которой достигаются

промежуточные цели?

8. Что такое ресурсы?

Тема 4. Общие этапы по разработке ПО

Каждая информационная система имеет собственный жизненный цикл,

в который проект разработки очередного релиза входит как одна из стадий.

Аналогично, каждый проект разработки ПО имеет свой собственный

жизненный цикл, состоящий из четырех фаз.

Этап Артефакты

Инициация - Концепция

Планирование - Требования к системе

- План управления

Реализация - Рабочее описание

- Отчет о состоянии

- Документы проекта

- Исходные коды

Завершение - Протоколы и приемо-сдаточные испытания

40

- Итоговый отчет

- Архив проекта

1. Инициация проекта

Этап инициации во многом определяет успешность проекта:

недостаточное внимание именно к этой фазе проекта неизбежно приводит к

существенным проблемам при планировании, реализации и завершении

проекта.

В ходе процесса инициации уточняются первоначальное описание

содержания, планируемые ресурсы, документируются исходные допущения

и ограничения.

Для каждого проекта должна быть сформулирована Концепция. Если

проект небольшой, то для изложения концепции достаточно несколько

абзацев.

Концепция проекта разрабатывается на основе анализа потребностей

бизнеса. Цель данного документа – подтверждение и согласование единого

видения целей, задач и результатов всеми участниками проекта. Концепция

проекта используется для принятия решений в ходе всего проекта, а также на

фазе приемки – для подтверждения результата.

Как правило, концепция проекта содержит следующие разделы:

1) Название проекта;

2) Цели проекта;

3) Результаты проекта;

4) Допущения и ограничения;

5) Ключевые участники и заинтересованные стороны;

6) Ресурсы проекта;

7) Сроки;

8) Риски;

9) Критерии приемки;

10) Обоснование целесообразности проекта.

41

Цели проекта

Цели проекта должны отвечать на вопрос «зачем» данный проект

нужен. Цели проекта должны описывать бизнес-потребности и задачи,

которые решаются в результате исполнения проекта.

Цели должны быть значимыми (направленными на достижение

стратегических целей компании), конкретными (специфичными для данного

проекта), измеримыми (т.е. иметь проверяемые количественные оценки),

реальными (достижимыми).

Результаты проекта

Результаты проекта отвечают на вопрос, что должно быть получено

после его завершения. Результаты проекта должны определять:

− какие конкретно преимущества получит заказчик в результате

проекта;

− что именно будет произведено по окончании проекта (т.е. какие

продукт или услуга);

− краткое описание продукта или услуги.

Допущения и ограничения

В разработке ПО часто приходится формулировать риски в виде

допущений, тем самым перекладывая часть ответственности на заказчика.

Например, оценивая проект разработки и внедрения по схеме с

фиксированной ценой, компания-разработчик должна записать в допущения

предположение о том, что стоимость лицензий на стороннее ПО до

завершения проекта не изменится.

Ограничения накладывают ряд дополнительных условий на

деятельность команды.

В этом разделе также уместно сформулировать те требования к

системе, которые могут ожидаться заказчиком по умолчанию, но не

включаются в рамки данного проекта.

Ключевые участники и заинтересованные стороны

42

Одна из задач фазы инициации проекта это выявить и описать всех его

участников. К участникам проекта относятся все заинтересованные стороны,

лица и организации, например заказчики, спонсоры, исполняющая

организация, которые активно участвуют в проекте или чьи интересы могут

быть затронуты при исполнении или завершении проекта.

Ресурсы

«Для оценки стоимости реализации проекта по созданию ИС требуется

определить и оценить различные типы ресурсов, необходимых для его

выполнения:

− людские ресурсы и требования к квалификации персонала;

− оборудование, услуги, расходные материалы, лицензии на ПО,

критические компьютерные ресурсы;

− бюджет проекта, включающего план расходов и, при необходимости,

план предполагаемых доходов проекта с разбивкой по статьям и

фазам/этапам проекта» [1].

Специфика программного проекта заключается в том, что людские

ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как

правило, незначительны, по сравнению с этим расходами.

Для программного проекта необходимо определить срок его

завершения, а также необходимо разбить проект на этапы – контрольные

точки, в которых происходит переоценка проекта на основе реально

достигнутых показателей.

Контрольная точка – важный момент или событие в расписании

проекта, отмечающее достижение заданного результата и/или начало /

завершение определенного объема работы. Каждая контрольная точка

характеризуется датой и объективными критериями ее достижения.

Риски

На этапе инициализации необходимо определить перечень рисков. Под

риском следует понимать неопределенное событие или условие, наступление

которого отрицательно или положительно сказывается на целях проекта. На

43

начальном этапе, когда нет необходимых данных для проведения детального

анализа, часто ограничиваются качественной оценкой общего уровня рисков:

низкий, средний, высокий.

Управлению рисками проекта будет посвящена отдельная лекция.

Критерии приемки

Критерии приемки должны определять числовые значения

характеристик системы, которые должны быть продемонстрированы по

результатам приемосдаточных испытаний или опытной эксплуатации и

однозначно свидетельствовать о достижении целей проекта.

Обоснование целесообразности проекта

Этот раздел концепции должен содержать краткое технико-

экономическое обоснование проекта:

− для кого предназначены результаты проекта (конечные

пользователи);

− описание текущей ситуации «AS-IS» и перечень существующих у

заказчика проблем бизнеса;

− описание будущей модели «TO-BE», с помощью которой

показывается каким образом результаты проекта решают данные проблемы;

− оценка экономического эффекта (или насколько значимо для

заказчика решение данных проблем).

2. Планирование проекта

Уточнение содержания и состава работ

Согласно теории систем, наиболее эффективным способом решения

сложной задачи является анализ и декомпозиция задачи на более простые

подзадачи, которые, в свою очередь, могут быть разделены на функции и так

далее. При этом деление осуществляется с соблюдением иерархии. Таким

образом, формируется некоторая иерархическая структура или дерево, в

корне которого находится проект, а на листьях элементарные задачи или

44

работы, которые надо выполнить, чтобы завершить проект в условиях

заданных ограничений.

Основой для разработки иерархическй структуры работ (ИСР) служит

концепция проекта, которая определяет продукты проекта и их основные

характеристики. ИСР обеспечивает выявление всех работ, необходимых для

достижения целей проекта. ИСР должна включать все промежуточные и

конечные продукты.

Выполнять декомпозицию работ проекта можно по-разному. При

составлении базового плана работ не стоит стремиться максимально

детализировать все работы. ИСР не должна содержать слишком много

уровней, достаточно 3-5.

Должна быть установлена персональная ответственность за все части

проекта (подпроекты и пакеты работ). Для каждого пакета работ должен

быть четко определен результат на выходе. Работы и оценки проекта должны

быть согласованы с ключевыми участниками команды, руководством

компании-исполнителя и, при необходимости, с заказчиком. В результате

согласования члены команды принимают на себя обязательства по

реализации проекта, а руководство принимает на себя обязательства по

обеспечению проекта необходимыми ресурсами.

Планирование управления содержанием

Сразу, как только удалось стабилизировать и согласовать ИСР,

необходимо разработать план управления содержанием проекта. Для этого

следует:

− определить источники запросов на изменение;

− установить порядок анализа, оценки и утверждения/отклонения

изменения содержания;

− определить порядок документирования изменений содержания;

− определить порядок информирования об изменении содержания.

Первая задача, которую необходимо решить при анализе запроса на

изменения – выявить объекты изменений: требования, архитектура,

45

структуры данных, исходные коды, сценарии тестирования,

пользовательская документация, прочее. Затем требуется спроектировать и

детально описать изменения во всех выявленных объектах. И наконец,

следует оценить затраты на внесение изменений, тестирование изменений и

регрессионное тестирование продукта и их влияние на сроки проекта.

Планирование организационной структуры

Организационная структура это согласованное и утвержденное

распределение ролей, обязанностей и целей деятельности ключевых

участников проекта. Она в обязательном порядке должна включать в себя

систему рабочих взаимоотношений между рабочими группами проекта,

систему отчетности, оценки хода выполнения проекта и систему принятия

решений.

Поскольку проект представляет собой «живой» организм, то и

организационная структура может динамично меняться в ходе проекта.

Планирование управления конфигурациями

Конфигурационное управление один из важных процессов

производства программного обеспечения.

План проекта должен включать в себя работы по обеспечению единого

хранилища всей проектной документации и разрабатываемого программного

кода, обеспечению сохранности и восстановление проектной информации

после сбоя, работы по настройке рабочих станций и серверов, используемых

участниками проектной команды. Кроме этого в плане должны содержаться

работы, необходимые для организации сборки промежуточных выпусков

системы, а также ее конечного варианта.

Планирование управления качеством

Обеспечение качества еще одна из базовых областей знаний в

программной инженерии. При планировании этой работы необходимо

понимать, что продукт проекта не должен обладать наивысшим возможным

качеством, которое недостижимо за конечное время. Необходимое качество

продукта определяется требованиями к нему.

46

Основная задача обеспечения качества это не поиск ошибок в готовом

продукте (выходной контроль) а их предупреждение в процессе

производства.

План управления качеством должен включать в себя следующие

работы:

− объективную проверку соответствия программных продуктов и

технологических операций применяемым стандартам, процедурам и

требованиям;

− определение отклонений по качеству, выявление их причин,

применение мер по их устранению, а также контроль исполнения принятых

мер и их эффективности;

− представление высшему руководству независимой информации о

несоответствиях, не устраняемых на уровне проекта.

Помимо перечисленных разделов план проекта должен включать еще:

− план управления рисками;

− оценку трудоемкости и сроков работ.

Базовое расписание проекта

После определения трудоемкости работ необходимо составить

расписание работ проекта, т.е. определить график выполнения работ и общие

сроки реализации проекта

Базовое расписание – это утвержденный план-график с указанными

временными фазами проекта, контрольными точками и элементами

иерархической структуры работ.

Для наглядного представления базового расписания часто используют

диаграмму Гантта. В этой диаграмме плановые операции или элементы

иерархической структуры работ перечислены с левой стороны, даты

отображаются сверху, а длительность операций показана горизонтальными

полосками от даты начала до даты завершения.

Для проекта следует определить критический пусть проекта (Critical

path) – самая длинная цепочка работ в проекте. Увеличение длительности

47

любой работы в этой цепочки приводит к увеличению длительности всего

проекта.

3. Реализация проекта

Рабочее планирование

Для управления проектом требуется осуществлять стратегическое и

оперативное планирование. Базовое расписание, составленное на этапе

планирования проекта, служит ориентиром для мониторинга состояния дел

на макроуровне. Для оперативного управления проектом используется

рабочий план.

Элементарная работа, как правило, представляет собой отдельное

функциональное требование к программному продукту или запрос на

изменение, над которым последовательно работают: бизнес-аналитик,

проектировщик, разработчик, тестировщик и документалист. Трудоемкость

элементарной работы каждого из исполнителей должна быть от 4 до 20

чел.*час. Если трудоемкость задачи не укладывается в эти пределы, следует

провести декомпозицию работы.

Для рабочего планирования целесообразно использовать систему

управления задачами, поскольку она позволяет задавать последовательность

переходов задачи от исполнителя к исполнителю, управлять приоритетами

работ и адекватно отслеживать их статус: анализ, проектирование,

кодирование, тестирование, документирование. Работа должна считаться

законченной только тогда, когда реализация требования протестирована и

документирована.

Принципы количественного управления

Для осуществления эффективного управления необходимо, чтобы на

проекте были определены количественные ключевые показатели. Для

каждого измеримого показателя должны быть определены его плановые

48

значения. Для каждого планового значения должны быть определены три

области критичности отклонений:

− допустимые отклонения – предполагается, что никаких управляющих

воздействий не требуется;

− критичные отклонения – требуется тщательный анализ причин

отклонения и при необходимости применение корректирующих действий;

− недопустимые отклонения – требуется срочный анализ причин

отклонения и обязательное применение корректирующих действий.

Измерения необходимо производить регулярно. Цель – выявить

причины наступивших или возможных критичных и недопустимых

отклонений. Результатом анализа должны стать планирование

корректирующих действий по компенсации недопустимых отклонений, их

реализация и мониторинг результативности применения этих

корректирующих действий.

Измерения по проекту необходимо выполнять регулярно, не реже

одного раза в 1-2 недели.

Все измерения необходимо сохранять в репозитарии проекта.

Измерения, накопленные в ходе проекте, являются наиболее достоверной

основой при детальной оценке и планировании работ на следующих

итерациях проекта.

4. Завершение проекта

Главная цель этой фазы – проверить и передать заказчику результат

проекта. Для этого необходимо выполнить приемо-сдаточные работы в

соответствии с процедурой приемки.

Результаты проекта должны быть переданы во внедрение или

сопровождение, или должным образом законсервированы для дальнейшего

использования. Не должно оставаться «зависших» работ по проекту.

49

Важная задача, которая должна быть решена на данной фазе, это

реализация обратной связи по проекту с целью сохранения результатов,

знаний и опыта, полученных в проекте для более эффективного и

качественного выполнения аналогичных проектов в будущем. Необходимо

архивировать все результаты, документировать опыт, уроки по проекту и

предложения по улучшению технологии выполнения работ и управления

проектами.

Все проекты и в особенности провальные проекты должны завершаться

итоговым отчетом. Итоговый отчет должен содержать следующую

информацию:

1) Итоги проекта:

− достижение целей проекта;

− дополнительные полезные результаты;

− фактические сроки;

− фактические расходы;

− обоснование отклонения от целей;

− отклонения результатов от требований;

2) Уроки проекта:

− проблемы проекта и способы их решения;

− материалы программные компоненты для последующего

использования;

− предложения по изменению технологий или стандартов компании.

Вопросы

1. Перечислите артефакты этапа реализации.

2. Суть этапа инициации.

3. Что должны определять результаты проекта.

4. Перечислите ресурсы, необходимые для выполнения проекта.

5. Дайте определение понятию «контрольная точка».

6. Что такое «базовое расписание»?

50

Тема 5. Управление рисками

Неопределенности, влияющие на проект могут грозить ему

отрицательными последствиями, вплоть до полного провала, или

положительными. Неопределенности первого вида принято называть

рисками проекта, а второго – благоприятными возможностями.

Классификация рисков:

− Риски проекта влияющие на его ход

технологические риски

кадровые риски

риски требований

коммерческие риски

управленческие риски

производственные риски

− Риски продукта, влияющие на результат проекта

технические риски

эксплуатационные риски

правовые и общественные риски

− Бизнес-риски

контрактные риски

инвестиционные риски

сбытовые риски

конъюнктурные риски

Планирование управления рисками включает следующие виды работ:

1. План управления рисками

2. Идентификация рисков

3. Анализ рисков

4. Планирование реагирования на риски

51

5. Мониторинг и контроль рисков

План управления рисками

«− определение подходов, инструментов и источников данных,

которые могут использоваться для управления рисками в данном проекте;

− распределение ролей и ответственности сотрудников;

− выделение ресурсов и оценка стоимости мероприятий, необходимых

для управления рисками;

− определение сроков и частоты выполнения процесса управления

рисками на протяжении всего жизненного цикла проекта, а так же

определение операций по управлению рисками, которые необходимо

включить в расписание проекта;

− идентификация и категоризация рисков с нужной степенью

детализации;

− общие подходы для определения уровней вероятности шкалы

воздействия и близости рисков на проект» [20].

Пример шкалы воздействия рисков

Вес Значение Критерий

1 Маловероятно Наступление события весьма

сомнительно

2 Возможно Шансы равны

3 Очень вероятно Шансы наступления весьма велики

Пример шкалы оценки близости риска

Вес Значение Критерий

1 Очень нескоро Срок менее полугода

2 Не очень скоро Срок менее месяца

3 Очень скоро Срок менее недели

52

Идентификация рисков

Под идентификацией рисков следует понимать деятельность по

выявлению рисков, способных повлиять на проект, и документальное

оформление их характеристик.

Пример – Список рисков проекта создания ИС

Причина Условия Последствия Ущерб

Текучесть

кадров

Частая смена участников

команды

Низкая

производительность

при вводе новых

участников в проект

Задержки в сроках

сдачи готового

продукта и

дополнительные

трудозатраты

Недостаток

квалифици-

рованных

кадров

Архитектура и код

низкого качества

Большое число

ошибок. Большие

затраты на их

исправление

Задержки в сроках

сдачи готового

продукта и

дополнительные

трудозатраты

Требования не

ясны

Отсутствие описания

сценариев

использования системы

Задержка начала

разработки

прикладного ПО.

Большой объем

переработок

Задержки в сроках

сдачи готового

продукта и

дополнительные

трудозатраты

Анализ рисков (1)

Качественный анализ рисков включает:

‒ определение вероятности реализации рисков;

‒ определение тяжести последствий реализации рисков;

‒ определение близости наступления риска;

‒ определение ранга риска по матрице «вероятность ‒ последствия»;

‒ оценка качества использованной информации.

Ранг риска и матрица вероятностей и последствий

53

Матрица рангов главных рисков проекта создания ИС

Причина Вероятность Воздействие Ранг

Текучесть кадров Очень вероятно Катострофическое 9

Недостаток квалифици-

рованных кадров

Очень вероятно Критичное 6

Требования не ясны Возможно Критичное 4

Анализ рисков (2)

Качественный анализ рисков: Пример карточки с описанием риска

Номер: R-101 Категория: Технологический

Причина: Недостаток квалифицированных

кадров

Симптомы: Разработчики будут

использовать новую платформу

Последствия: Низкая производительность

разработки

Воздействие: Увеличение сроков и

трудоемкости разработки

Вероятность: Очень вероятно Степень воздействия: Критичная

Близость: Очень скоро Ранг: 6

Исходные данные: «Содержание проекта», «План обеспечения ресурсами», Протоколы

совещаний №21 от 03.03.2016, №33 от 05.03.2016.

Методы количественного анализа рисков:

‒ анализ чувствительности, помогает определить, какие риски

обладают наибольшим потенциальным влиянием на проект;

‒ анализ дерева решений, используется для анализа последствия

возможных решений;

54

‒ моделирование и имиация, строится модель для определения

последствий от воздействия подробно описанных неопределенностей на

результаты проекта в целом.

Планирование реагирования на риски

‒ Стратегии предотвращения или обхода рисков: направлены на

снижение вероятности риска или полное избавление от него.

‒ Стратегии минимизации ущерба.

‒ Планирование реакции на возникающие проблемы.

Мониторинг и контроль рисков

‒ пересмотр рисков, должен проводится регулярно

‒ аудит рисков, предполагет:

изучение и предоставление в документальном виде результатов

оценки эффективности мероприятий по реагированию на риски;

изучение основных причин их возникновения;

иценку эффективности процесса управления рисками;

‒ анализ отклонений и трендов.

Риск всегда является неотъемлемой частью любого сложного и

ответственного процесса. Более того, совершение рискованных действий

необходимо для прогресса, а ошибки, как известно, являются основой

приобретения опыта. Несмотря на то, что некоторые риски в ходе реализации

проекта внедрения системы неизбежны, это не означает, что попытки

определить их и управлять ими вредят творческой работе.

Вопросы

1. Дайте определение «риска».

2. Какие виды работ включает в себя планирование управления

рисками?

55

3. Приведите пример шкалы оценки близости риска.

4. Перечислите методы количественного анализа рисков.

Тест 2 (приложение 2).

Раздел 3. Модели разработки

Тема 6. Модели процесса разработки программного продукта

Microsoft Solution Framework ( MSF)

«ИТ-решение – скоординированная поставка набора элементов (таких

как программно-технические средства, документация, обучение,

сопровождение и внешние коммуникации), необходимых для

удовлетворения некоторой бизнес потребности конкретного заказчика» [6].

Именно ИТ-решения (а не просто программные продукты,

поставляемые в виде дистрибутивов) являются основным продуктом и

результатом процесса разработки и внедрения по MSF (несмотря на то, что

аналогичная философия лежит в основе многих методологий, все равно

термин «программный продукт» является очень распространенным).

Базируемость на вехах (основных и вспомогательных) и артефактах как

результатах их достижения.

ПРИМЕР

На схеме концепции MSF основными вехами являются

‒ «Концепция проекта утверждена».

‒ «Разработка завершена».

В то же время, промежуточными вехами между ними могут быть:

‒ «Верификация технологий осуществлена».

‒ «Базовая версия функциональной спецификации создана».

‒ «Базовая версия сводного плана создана».

56

В целом, важным преимуществом MSF является ее практическая

направленность и простота. Для MSF очень важно взаимодействие внутри

проектной команды, и, несмотря на то, что минимальное число ее участников

официально в методологии ограничено всего тремя, выделяются шесть

основных ролей внутри команды, и связь между участником и ролью имеет

тип «многие-ко-многим». Среди шести упомянутых кластеров:

‒ управление программой (архитектурным решением);

‒ разработка (программной и технической архитектуры);

‒ тестирование (планирование, разработка, отчетность);

‒ управление релизами;

‒ управление требованиями заказчика (в части интерфейса решения, а

также, конечно, обучения и технической поддержки);

‒ управление продуктом (по сути, управление требованиями бизнес-

заказчика и бизнес-приоритетами).

Именно на этих областях концентрируется методология, каждый из

кластеров отвечает за достижение определенной цели, однако за итоговый

результат отвечает вся команда.

Для более крупных проектов с большими командами внедрения могут

дополнительно создаваться группы направлений и функциональные груп-пы,

причем MSF даже предлагает таблицу совместимости ролей: какие из них

57

допустимо, нежелательно или совсем нельзя совмещать. Допустимо

совмещать, например:

‒ Управление продуктом, Тестирование, Управление требованиями

заказчика.

‒ Управление релизами и Тестирование.

Однако возложение ответственности по Управлению проектом и

Управлению продуктом на одного человека может привести к конфликту

интересов, так как менеджер проекта должен контролировать основные

процессы в области стоимости, сроков, взаимодействия команды, рисков и

т.д., а не определять приоритеты бизнеса. Есть и роль, которую вообще не

рекомендуется совмещать с другими – роль Разработчика, что сделано

исходя из предположения, что его активности являются наиболее

критичными в проекте, и любое наделение разработчиков дополнительными

обязанностями приведет к срыву план-графика проекта.

Данное распределение становится более понятным, если рассмотреть

значение каждой роли и основные активности:

Таким образом, в отличие от многих других корпоративных

методологий, определенные в MSF этапы / вехи, состав проектной группы,

ролевая модель и другие элементы подходят не только для решений

58

Microsoft. А значит, MSF представляет собой более гибкий и универсальный

подход для внедрения других систем / программных продуктов.

Agile

«В переводе с английского Agile означает «гибкий» – именно поэтому

такое название получила методология разработки, которая не содержит

четких инструкций и «лучших практик», однако представляет собой сборник

основных принципов и ценностей в предметной области разработки ПО. К

тому же, сам процесс гибкой разработки является адаптивным по отношению

к постоянно изменяющимся условиям, что достигается разработкой за

короткие итерации, после каждой из которых происходит пересмотр

требований и в случае необходимости – изменение практик коммуникаций и

работы команды. Тем временем, есть еще несколько не менее важных и

требующих рассмотрения идей Agile:

‒ Приоритет взаимодействия людей над процессами и традиционными

инструментами управления.

‒ Приоритет получения работающего продукта над исчерпывающей

всеобъемлющей документацией.

‒ Приоритет сотрудничества с потребителями (заказчиком) над

формальными вопросами контрактов.

‒ Приоритет быстрого реагирования на изменения над неотступным

следованием плану» [18].

Исходя из этих ценностей, среди команд, использующих Agile-

методологию, почти не встречается одинаковых практик документирования

или координации, так как «гибкая методология» предполагает

самоорганизацию, самостоятельное определение объема, содержания и

ограничений каждого элемента управления разработкой. Со времени своего

появления в 1990-х Agile-практики получили свое распространение во

множестве компаний, в то время как первоначально они позиционировались

для управления ИТ-проектами.

59

В качестве одного из важнейших элементов Agile-подхода к разработке

выступают пользовательские истории (user stories). Это описанные одним

или несколькими предложениями основные аспекты функциональности

системы, необходимые для выполнения пользователем своей работы. В

достаточно сжатом виде, они должны отвечать на вопросы: «Кто?», «Что?» и

«Почему?» и могут создаваться как менеджером проекта по результатам

обследования как один из форматов фиксирования требований, так и

разработчиками для выражения нефункциональных требований (например, к

безопасности, производительности, качеству решения).

В то же время, agile почти не ограничивает команду проекта: так, если

необходим больший уровень детализации технического задания /

спецификаций / другой документации – можно его написать, если

необходимы дополнительные приемочные критерии – можно их составить,

если нужны прототипы – можно их сформировать или в виде макетов

(мокапов, mockups), или в виде блок-схем, или в виде реальной модели

прототипа. Уровень детализации и формализации всегда зависит от

специфики системы и проектной команды, от их компетенций и опыта

реализации подобных проектов.

Вопросы

1. Назовите определения ИТ-решения.

2. Перечислите шесть основных ролей внутри проектной команды

MSF.

3. Перечислите значения роли «управление проектами» в модели

проектной группы MSF.

60

Тема 7. Модель быстрой разработки приложений RAD

«В 1980-х годах XX века в ответ на ограничивающий характер

формальных методов, как каскадная модель, компания IBM предложила

метод быстрой разработки приложений (Rapid Application Development). Эта

модель основана на «трех китах»:

1. Участие пользователя в процессе разработки.

2. Широкое применение CASE-средств и реинжениринга.

3. Временные блоки» [6].

Благодаря методу RAD, пользователь задействован на всех фазах

жизненного цикла разработки проекта – не только при определении

требований, но и при проектировании, разработке, тестировании, а так же

конечной поставке программного продукта. Активное участие пользователя

возможно, благодаря использованию современных CASE-средств, наглядно

демонстрирующих продукт на всех стадиях его разработки. Это, например,

Visual C++, Visual Basic, SAS и др.

Для RAD характерно короткое время перехода от определения

требований до создания полной системы. Метод основывается на

последовательности итераций прототипов, критический анализ которых

обсуждается с заказчиком, при этом формируются требования к продукту.

Разработка каждого интегрированного продукта ограничивается четко

определенным периодом времени, который, как правило, составляет 60 дней

и называется временным блоком.

Участие конечного пользователя в этой модели является решающим.

Это возможно потому, что место программирования и тестирования в данной

модели занимают планирование и конструирование.

61

На этапе планирования требований сбор требований выполняется при

использовании рабочего метода, называемого совместным планированием

требований, который представляет собой структурный анализ и обсуждение

имеющихся коммерческих задач.

Совместное проектирование используется с целью привлечения

пользователей. Команда разработчиков использует в качестве прототипа

любые готовые модули из базы готовых программных компонентов.

Прототип обеспечивает возможность пользователям составить свое видение

ИС. Пользователи составляют пользовательское описание системы.

Фаза конструирования («до полного завершения») – эта фаза

объединяет в себе детализированное проектирование, построение ИС и ее

тестирование, а так же постановку программного продукта заказчику за

определенное время. Особенность этого этапа, которая нашла отражение в

его названии – то, что новая ИС строится не путем создания нового кода, а

путем конструирования ИС из уже готовых модулей. При этом учитываются,

какие модули отобраны, и структура ИС строится в соответствии с их

функциональными возможностями. Если некоторые программные продукты

недоступны, то для них пишется новый код. Для убыстрения этого процесса

используются генераторы кода.

62

Перевод на новую систему эксплуатации – эта фаза включает

проведение пользователями приемочных испытаний, установку системы и

обучение пользователей.

Преимущества модели RAD

«Если модель RAD применима для проекта, то проявляются

преимущества:

– время цикла разработки для всего проекта можно сократить

благодаря использованию мощных CASE-средств;

– требуется меньше специалистов, поскольку команда разработчиков

осведомлена в предметной области;

– можно изначально ознакомиться с продуктом;

– благодаря сокращенному времени цикла и усовершенствованной

технологии, а так же меньшему количеству задействованных в процессе

разработчиков, уменьшаются затраты;

– благодаря принципу временного блока, уменьшаются затраты и риск,

связанный с соблюдением графика;

– привлечение заказчика на постоянной основе сводит до минимума

риск того, что он не будет удовлетворен разработанным продуктом и

гарантирует, что система будет соответствовать коммерческим

потребностям;

– в состав каждого временного блока входят анализ, проектирование и

внедрение (фазы отделены от действий);

– в модели повторно используются компоненты уже существующих

программ.

Недостатки модели RAD

Чтобы применение модели дало положительный эффект, а именно

быструю и недорогую разработку проекта, нужно непременное соблюдение

следующих факторов:

– пользователи должны иметь возможность принимать участие в

процессе разработки на протяжении всего жизненного цикла;

63

– разработчики должны быть высококвалифицированными и уметь

пользоваться выбранными CASE-средствами;

– как разработчики, так и заказчики должны быть готовы к быстрому

выполнению действий ввиду жестких временных ограничений, чему должна

способствовать система материальной заинтересованности» [6].

Область применения модели RAD

Кроме вышеперечисленных факторов, руководитель проекта, выбирая

модель RAD, должен проверить наличие приведенных ниже условий-причин:

– проект должен быть основан на использовании компонентных

объектов;

– требования в достаточной мере хорошо известны;

– сроки разработки проекта сокращены (60 дней и менее);

– в проекте можно обеспечить функциональные возможности

последовательно;

– пригодные к повторному использованию части можно получить из

автоматических хранилищ программных продуктов;

– проект небольшой по размеру;

– проект не требует достижения высокой производительности,

невысока степень технических рисков.

Вопросы

4. Назовите «три кита», на которых основана модель RAD.

5. Для чего используется совместное проектирование?

6. Что включает в себя фаза конструирования?

7. Какой максимальный срок составляет временной блок?

Тест 3 (приложение 2).

64

2.1 Методические рекомендации по организации

изучения дисциплины

Методические указания для студентов

Основной формой обучения в системе высшего образования является

лекция. Запись лекций в тетрадь должна быть избирательной, полностью

следует записывать только определения. Рекомендуется применять

сокращение слов, что ускоряет запись. Вопросы, возникающие в ходе

лекции, рекомендуется записывать на поля и после лекции обратиться к

преподавателю за разъяснением.

Приветствуется активная работа с конспектами: по окончании лекции

рекомендуется перечитывать конспект и вносить изменения и дополнения на

полях.

Конспекты лекций следует использовать при подготовке к семинарам,

зачету в рамках выполнения самостоятельной работы и домашних заданий.

Методические рекомендации по организации самостоятельной

работы студента

Самостоятельная работа студентов в рамках изучения дисциплины

«Управление жизненным циклом ИС» определяется общим графиком

учебной работы, и предусматривает посещение семинаров и выполнение

заданий.

При организации самостоятельной работы по дисциплине «Управление

жизненным циклом ИС» студент должен:

1. Внимательно изучить материалы, характеризующие курс и тематику

самостоятельного изучения, что изложено в учебно-методическом комплексе

по дисциплине. Это позволит четко представить как круг изучаемых тем, так

и глубину их постижения.

65

2. Составить подборку литературы, достаточную для изучения

предлагаемых тем. Основные и дополнительные списки литературы

представлены в программе дисциплины. Они носят рекомендательный

характер, а это значит, что всегда есть книги, которые не могут быть

включены в этот список. Следует иметь в виду, что следует использовать

разные виды литературы: учебники и учебные пособия, сборники научных

статей, монографии, первичные источники, публикации в журналах,

справочники - энциклопедии, словари и др.

3. Основное содержание той или иной проблемы следует уяснить,

изучая учебную литературу.

4. Подавляющее большинство проблем, носят не только теоретический

характер, но и выходят на жизнь. Это предполагает, что студенты должны

знать не только категории и понятия, но и уметь использовать их в качестве

инструмента для анализа социальных проблем. Другими словами, студент

должен прилагать собственные интеллектуальные усилия, а не просто

механически запоминать понятия и положения.

Методические рекомендации для преподавателя

Семинарские занятия дают студенту возможность сформировать

детальное представление проблем предмета «Управление жизненным циклом

ИС» и закрепить изученный материал. Качественная подготовка к

семинарскому занятию подразумевает готовность студента к необходимости

структурированного рассмотрения материала.

Подготовку к семинарскому занятию следует начинать с повторения

пройденной ранее темы. Для лучшего усвоения материала рекомендуется

дать возможность студенту самостоятельно подготовить практический

материал с примерами.

Изучение курса «Управление жизненным циклом ИС»

предусматривает использование различных форм самостоятельной работы,

66

выводя студентов к завершению изучения учебной дисциплины на ее

высший уровень.

Лекционный курс по дисциплине построен с целью формирования у

студентов ориентировочной основы для последующего усвоения материала

методом самостоятельной работы. Содержание дисциплины отвечает

следующим дидактическим требованиям:

– изложение материала от простого к сложному, от известного к

неизвестному;

– логичность, четкость и ясность в изложении материала;

– возможность проблемного изложения, дискуссии, диалога с целью

активизации деятельности студента;

– тесная связь теоретических положений и выводов с практикой и

будущей профессиональной деятельностью студентов.

Практические занятия курса проводятся по узловым и наиболее

важным темам, разделам учебной программы. Они построены как на

материале одной лекции, так и на содержании нескольких лекций.

При подготовке к семинарам предусмотрено при необходимости

проведение консультаций для студентов. На подготовку к занятию студентам

выдается несколько дней, рекомендации о последовательности изучения

литературы (учебники, учебные пособия, конспекты лекций, статьи,

справочники, информационные сборники, статистические данные и др.) При

подготовке к занятию возможно использование набора наглядных пособий и

специального оборудования.

Используемые критерии оценки ответов:

– полнота и конкретность ответа;

– последовательность и логика изложения;

– связь теоретических положений с практикой;

– обоснованность и доказательность излагаемых положений;

– наличие качественных и количественных показателей;

67

– наличие иллюстраций к ответам в виде рабочих тетрадей, с

выполненными таблицами и схемами;

– уровень культуры речи;

– использование наглядных пособий и т.д.

В конце занятия дается оценка всего практического занятия, где

обращается особое внимание на следующие аспекты:

– качество подготовки;

– результаты выполненной работы;

– степень усвоения знаний;

– активность;

– положительные стороны в работе студентов;

– ценные и конструктивные предложения;

– недостатки в работе студентов и пути их устранения.

Форма контроля работы студентов преподавателем дисциплины

Руководство работой студентов со стороны преподавателя

осуществляется в следующих формах:

– требование вести конспекты, обучение конспектированию;

– контроль за выполнением: просмотр конспектов – по ходу лекции,

после лекции, на семинарских занятиях;

– использование приемов управления вниманием: контрольные

вопросы, риторические вопросы, варьирование интонацией, другие

ораторские приемы;

– использование приемов закрепления: повторение основных

положений и выводов с использованием различных формулировок, вопросы

к аудитории на проверку внимания;

– проведение тестовых самостоятельных работ по вопросам

предыдущих лекций, относительно изученного раздела.

68

Форма проверки знаний студентов (степени овладения компетенциями)

по результатам работы на семинарах включает контроль непосредственного

участия студента в работе на семинаре (присутствие), выполнение заданий.

Общая картина успеваемости студента складывается из посещаемости

и сдачи всех заданий, что при полном выполнении дает право на допуск к

зачету.

Виды и формы организации самостоятельной работы студентов

Виды самостоятельной работы Руководство преподавателю

1. Конспектирование Выборочная проверка

2. Участие в работе на семинарах Проверка знаний

3. Практические занятия: в

соответствии с инструкциями и

методическими указаниями

Составление алгоритма действий,

показателей уровня достижения результата

Методические указания к написанию реферата

Реферат представляет собой краткое изложение (обзор) основных

научных концепций и взглядов по тому или иному вопросу. Реферат не

предполагает независимую научно-исследовательскую тему и не требует

определения позиции автора или его оценки материала. Задача реферата -

краткое изложение основных точек зрения, существующих в современной

науке. Реферат может быть обзором дополнительной информации из

наиболее важных (известных, популярных, признанных) научных

монографий и научных статей по некоторой общей для всех них тематике.

Он также может быть кратким изложением существенных дискуссий,

круглых столов и конференций по конкретной теме.

Студент имеет право выбрать любую тему из предложенных

преподавателем для написания реферата.

69

Подбор литературы по теме реферата осуществляется студентов

самостоятельно. Преподаватель лишь помогает ему определить основные

направления работы, указывает наиболее важные научные источники,

которые следует использовать при ее написании, разъясняет, где их можно

найти. При подборе литературы рекомендуется использовать фонды научных

библиотек, электронных каталогов и сети Интернет.

План написания реферата составляется студентом самостоятельно, и

согласовывается с преподавателем. Содержание реферата должно

соответствовать теме и плану.

В ходе выполнения работы студент по мере необходимости может

обращаться за консультацией к преподавателю.

Работа студента по написанию реферата включает:

1. обдуманный выбор темы;

2. самостоятельный подбор списка литературы;

3.консультация у преподавателя по списку литературы и плану

реферата;

4. аналитическое чтение и конспектирование основных источников;

5. составление реферата на основе сделанных конспектов;

6. оформление текста реферата.

Реферат должен включать следующие основные разделы:

Титульный лист. На титульном листе указывается название

университета, факультета, кафедры, тема реферата, фамилия, имя, отчество и

номер группы автора работы и год выполнения.

Содержание. Включает порядок расположения основных частей с

указанием страниц, на которых соответствующий раздел начинается.

Введение. Во введении обосновывается выбор темы, оценивается

актуальность выбранной проблемы, указывается необходимость дальнейшего

изучения заявленной темы и определяются границы ее рассмотрения.

70

Основная часть. В основной части, состоящей примерно из 3-4

подпунктов, излагаются основные положения, идеи, взгляды, концепции,

теории по существу выбранной темы. В ходе изложения следует делать

ссылки на источники (статьи, книги, брошюры), из которых берется то или

иное положение или цитата. Цитаты приводятся в кавычках и с обязательной

ссылкой на источник с указанием страницы.

Заключение (или выводы). В заключении (на 0,25-0,5 страницы)

подводятся итоги, обобщаются основные теоретические положения и

делаются выводы, а так же указываются трудные проблемы и нерешенные

вопросы.

Список литературы. В список литературы вносятся реально

использованные источники. Оформляется в соответствии с утвержденными

библиографическими требованиями.

Приложения. Приводятся используемые в работе документы, таблицы,

графики, схемы и др. (аналитические табличные и графические материалы

могут быть приведены также в основной части).

Объем реферата – 15-20 стандартных машинописных страниц или 25-

30 рукописных. Реферат сдается в срок, установленный преподавателем по

данной дисциплине. В конце реферата ставится подпись студента и дата.

Реферат является формой отчета студента по изучаемому курсу.

Выполненный и оформленный реферат сдается на проверку преподавателю,

оценка выставляется в ходе публичной защиты и учитывается при аттестации

студента.

71

ЗАКЛЮЧЕНИЕ

Дисциплина появилась недавно, введена в процесс подготовки

бакалавров направления: 080500 – «Бизнес-информатика», профиль

подготовки «Архитектура предприятия»

В ходе выполнения исследования с целью создания методического

обеспечения дисциплины «Управление жизненным циклом информационных

систем» были получены следующие результаты:

1) на основе анализа литературы по теме исследования был отобран

и структурирован материал по теоретическим основам управления

жизненным циклом информационных систем;

2) рассмотрены аналогичные учебные курсы для выяснения

структуры дисциплины;

3) определено содержание курса, составлен проект рабочей

программы дисциплины;

4) систематизирован теоретический материал по информационным

системам, необходимый для изучения дисциплины;

5) разработаны материалы практических и семинарских занятий,

промежуточные тесты;

6) составлены методические рекомендации для студентов и

преподавателей;

7) подготовленное методическое обеспечение к курсу было

размещено на сайте ПГГПУ в системе электронной поддержки

образовательных курсов http://moodle.pspu.ru.

Материалы ВКР могут быть использованы преподавателями и

студентами в поддержку курса «Управление жизненным циклом

информационных систем» для направления: 080500 – «Бизнес-информатика»

профиль подготовки «Архитектура предприятия».

72

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Абрамов Г.В. Проектирование информационных систем : учеб.

пособие / Г.В. Абрамов, И.Е. Медведкова, Л.А. Коробова. – Воронеж : Изд-во

Воронежского гос. ун-та инженерных технологий, 2012. – 172 с. ; то же

[Электронный ресурс]. – URL : http://biblioclub.ru/index.php?page=book&id=

141626 (дата посещения 15.03.2016).

2. Бакланова О.Е. Информационные системы : учеб.-метод. комплекс

/ О.Е. Бакланова. – М. : Изд-во Евразийского открытого ин-та, 2008. – 290 с. ;

то же [Электронный ресурс]. – URL: http://biblioclub.ru/

index.php?page=book&id=90542 (дата посещения 27.05.2016).

3. Берг Д.Б. Модели жизненного цикла : учебное пособие /

Д.Б. Берг, Е.А. Ульянова, П.В. Добряк ; Министерство образования и науки

Российской Федерации, Уральский федеральный ун-т имени первого

Президента России Б. Н. Ельцина. - Екатеринбург : Изд-во Уральского ун-та,

2014. - 78 с. : ил., табл. - Библиогр. в кн. - ISBN 978-5-7996-1311-2;

[Электронный ресурс]. – URL:

http://biblioclub.ru/index.php?page=book&id=275652 (дата посещения

15.03.2016).

4. Грекул В.И. Управление внедрением информационных систем :

учебник / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - М. : Интернет-

Университет Информационных Технологий, 2008. - 224 с.

5. Грекул В.И. Проектирование информационных систем /

В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - М. : Интернет-Университет

Информационных Технологий, 2005. - 304 с. - (Основы информационных

технологий). - ISBN 5-9556-0033-7 ; [Электронный ресурс]. – URL:

73

http://biblioclub.ru/index.php?page=book&id=233071 (дата посещения

27.05.2016).

6. Зараменских Е.П. Управление жизненным циклом

информационных систем: моно- графия / Е.П. Зараменских. – Новосибирск:

Издательство ЦРНС, 2014. – 270 с.

7. Золотов С.Ю. Проектирование информационных систем :

учебное пособие / С.Ю. Золотов ; Министерство образования и науки

Российской Федерации, ТУСУР. - Томск : Эль Контент, 2013. - 88 с. : табл.,

схем. - ISBN 978-5-4332-0083-8 ; [Электронный ресурс]. – URL:

http://biblioclub.ru/index.php?page=book&id=208706 (дата посещения

04.04.2016).

8. Жданов С.А. Информационные системы : учебник / С.А. Жданов,

М.Л. Соболева, А.С. Алфимова. - М. : Прометей, 2015. - 302 с.

9. Избачков Ю.С. Информационные системы: Учебник для вузов. 2-

е изд./ Избачков Ю. С, Петров В. Н.; СПб : Питер, 2006. - 656 с.

10. История информационных систем [Электронный ресурс] /

Мастерская Dr.dimdim. – URL: http://www.info-

system.ru/is/history/is_history_is.html (дата посещения 20.03.2016).

11. Клигман Т.И. Профессиональная подготовка бакалавров

направления Бизнес-информатика / Т.И. Клигман, М.В. Казак // Экономика

знаний в глобальном информационном обществе : материалы Третьей

Российской научно-практической конференции с международным участием

(г. Пермь, 21-22 апреля 2015 г.). – Пермь, 2015. – С 145-146.

12. Курс: Проектирование информационных систем [Электронный

ресурс] / НОУ ИНТУИТ. – URL:

http://www.intuit.ru/studies/courses/2195/55/info (дата посещения 03.05.2016).

13. Лекция: Анализ и моделирование функциональной области

внедрения ИС [Электронный ресурс]. – НОУ ИНТУИТ. – URL :

http://www.intuit.ru/studies/courses/2195/55/lecture/1624 (дата посещения

14.04.2016).

74

14. Лекция: Жизненный цикл информационной системы

[Электронный ресурс]. – Сайт В.В. Анисимова – URL:

https://sites.google.com/site/anisimovkhv/learning/pris/lecture/tema2 (дата

посещения 03.05.2016).

15. Лекция: Жизненный цикл программного обеспечения ИС:

[Электронный ресурс]. – НОУ ИНТУИТ – URL :

http://www.intuit.ru/studies/professional_skill_improvements/1901/courses/55/lect

ure/1620?page=2 (дата посещения 04.04.2016).

16. Лекция: Основные понятия технологии проектирования

информационных систем (ИС) [Электронный ресурс]. – НОУ ИНТУИТ. –

URL: http://www.intuit.ru/studies/courses/2195/55/lecture/1618 (дата посещения

15.03.2016).

17. Лекция: Организация разработки ИС [Электронный ресурс]. –

НОУ ИНТУИТ. – URL:

http://www.intuit.ru/studies/courses/2195/55/lecture/1622 (дата посещения

14.04.2016).

18. Лекция: Методологии моделирования предметной области

[Электронный ресурс]. – НОУ ИНТУИТ. – URL:

http://www.intuit.ru/studies/courses/2195/55/lecture/1628 (дата посещения

14.04.2016).

19. Лекция 2. Управление проектами с использованием MS Project

[Электронный ресурс]. – MyLektsii.ru. – URL: http://mylektsii.ru/1-58697.html

(дата посещения 30.05.2016).

20. Лекция: Управление рисками проекта [Электронный ресурс]. –

НОУ ИНТУИТ. – URL:

http://www.intuit.ru/studies/courses/2196/267/lecture/6806?page=6 (дата

посещения 20.03.2016).

21. Лекция: Методологии внедрения [Электронный ресурс]. – НОУ

ИНТУИТ. – URL: http://www.intuit.ru/studies/courses/1177/247/lecture/ (дата

посещения 15.03.2016).

75

22. Методологии и технологии проектирования ИС [Электронный

ресурс] / Interface-Internet a software company. – URL:

http://www.interface.ru/LOGWORKS/caset/glava1/glava1_3_1.htm (дата

посещения 20.03.2016).

23. Милехина О.В. Информационные системы: теоретические

предпосылки к построению : учебное пособие / О.В. Милехина,

Е.Я. Захарова, В.А. Титова ; Министерство образования и науки Российской

Федерации, НГТУ. - 2-е изд. - Новосибирск : НГТУ, 2014. - 283 с.

24. Персианов, В.В. Информационные системы : учебно-

методическое пособие / В.В. Персианов, Е.И. Логвинова. - М. ; Берлин :

Директ-Медиа, 2016. - 191 с. : ил. - Библиогр. в кн. - ISBN 978-5-4475-6209-0;

[Электронный ресурс]. –

URL: http://biblioclub.ru/index.php?page=book&id=434744 (дата посещения

21.03.2016).

25. Проектирование информационных систем. Часть 1. Этапы

разработки проекта: стратегия и анализ [Электронный ресурс] / Учебный

центр Interface.ru. – URL: http://www.interface.ru/home.asp?artId=2805 (дата

посещения 21.03.2016).

26. Проектирование информационных систем. Часть 2. Этапы

разработки проекта: определение стратегии тестирования и проектирование

[Электронный ресурс] / Учебный центр Interface.ru. – URL:

http://www.interface.ru/fset.asp?Url=/case/proekt_inf_sis2.htm (дата посещения

14.04.2016).

27. Семакин И.Г. Информационные системы и модели [Электронный

ресурс]: методическое пособие/ Семакин И.Г., Хеннер Е.К. – Электрон.

текстовые данные. – М.: БИНОМ. Лаборатория знаний, 2012. – 71 c. – URL:

http://www.iprbookshop.ru/6473. – ЭБС «IPRbooks»

28. Совершенствование методологии проектирования

информационных систем [Электронный ресурс] / Мастерская Dr.dimdim. –

76

URL: http://www.info-system.ru/is/article/article_perfect_design_is.html (дата

посещения 15.03.2016).

29. Структура и классификация автоматизированных

информационных систем [Электронный ресурс] / Дистанционное обучение. –

URL: http:// do.rksi.ru/library/courses/opais/tema1_3.dbk (дата посещения

04.04.2016).

30. Суркова Н.Е. Проектирование информационных систем

[Электронный ресурс]: методические указания к курсовому проекту/ Суркова

Н.Е. – Электрон. текстовые данные. – М.: Российский новый ун-т, 2010. – 60

c. – URL: http://www.iprbookshop.ru/21303.— ЭБС «IPRbooks» (дата

посещения 16.03.2016).

77

ПРИЛОЖЕНИЕ 1

Проект рабочей программы

Дисциплина "Управление жизненным циклом информационных

систем" преподается студентам Пермского государственного гуманитарно-

педагогического университета, очной формы обучения, направления:

080500.62 – «Бизнес-информатика» профиль подготовки «Архитектура

предприятия». Направление появилось в 2012 году. Осваивается дисциплина

на 3 курсе 5 семестра.

Перечень дисциплин, усвоение которых студентами необходимо

для изучения дисциплины «Управление жизненным циклом ИС»:

— Базы данных (3 семестр);

— Проектирование информационных систем (5 семестр);

— Архитектура предприятия (5 семестр);

— Информационные системы управления производственной

компанией (5 семестр);

— Стандартизация, сертификация и управление качеством

программного обеспечения (5 семестр).

Изучение дисциплины «Управление жизненным циклом ИС»

дает основу для изучения последующих курсов профиля «Архитектура

предприятия»:

— Управление разработкой ИС (6 семестр);

— Инструментальные средства проектирования информационных

систем (6 семестр);

— Сбор, анализ и управление требованиями к

автоматизированным информационным системам (6 семестр);

— Корпоративные информационные системы (7 семестр);

— Электронный бизнес (8 семестр).

Цель дисциплины – получение студентами знаний по организации

78

управления информационными системами на всех этапах ее жизненного

цикла.

Задачи дисциплины:

— обобщение, систематизация и углубление знаний студентов в

области информационных систем и технологий;

— рассмотрение и анализ особенностей управления ИС на

различных этапах их жизненного цикла; стратегий внедрения и проблем

эксплуатации и сопровождения ИС;

— выработка практических навыков выбора способа

автоматизации конкретного предприятия, в частности выбора

информационной системы для конкретных применений на основании

анализа общих свойств, функциональных возможностей и особых

требований.

В результате освоения дисциплины "Управление жизненным циклом

информационных систем" студенты смогут применить полученные

теоретические и практические знания при прохождении научно-

исследовательской практики и подготовке отчета по практике, а также при

написании выпускной квалификационной работы.

В результате освоения дисциплины формируются следующие

компетенции:

Компетенция Вклад дисциплины в формирование компетенции

ПК-9 Использовать современные стандарты и методики, разрабатывать

регламенты для организации управления процессами жизненного

цикла ИТ-инфраструктуры предприятий.

ПК-3 Выбирать рациональные ИС и ИКТ-решения для управления

бизнесом.

ПК-14 Выполнять технико-экономическое обоснование проектов по

совершенствованию и регламентацию бизнес-процессов и ИТ-

инфраструктуры предприятия.

79

В результате освоения дисциплины студент:

2. Должен знать:

- этапы жизненного цикла информационной системы;

- основные модели жизненного цикла информационной системы;

- риски, сопровождающие жизненный цикл информационной

системы;

2. Должен уметь:

- планировать этапы жизненного цикла информационной системы;

- определять необходимые ресурсы для обеспечения жизненного

цикла информационной системы;

- организовывать управление и управлять эксплуатацией и

сопровождением ИС.

3. Должен владеть:

- навыками планирования жизненного цикла информационной

системы;

Объем дисциплины и виды учебной работы

Вид учебной работы Формы обучения

Очная Заочная

Общая трудоемкость: (часы) 108

Номер семестра 7

Аудиторные занятия (всего):

В том числе:

42

Лекции (Л) 16

Семинарские (СЗ ) и практические (ПЗ)

занятия

26

Лабораторные работы (ЛР) -

Самостоятельная работа (СРС) (всего) 66

Форма промежуточной аттестации зачет

80

Распределение часов по видам и темам учебной работы

№

п/п

Раздел/тема Всего

час.

Виды учебной работы (в часах)

Аудиторная работа Самостоят.

работа Лек. Сем./пр. Лаб.

Раздел 1. Жизненный

цикл

информационной

системы

1. Структура

жизненного цикла ИС

6 4 2 9

2. Модели жизненного

цикла ИС

8 2 6 14

Раздел 2. Общие

сведения об

управлении

проектами

3. Управление

проектами

4 2 4 10

4. Общие этапы по

разработке ПО

6 2 4 12

5. Управление рисками 4 2 2

Раздел 3. Модели

разработки

6. Модели процесса

разработки

программного

продукта

4 2 4 12

7. Модель быстрой

разработки

приложений RAD

4 2 4 9

81

Итого 42 16 26 66

Содержание дисциплины Наименование раздела

дисциплины

Содержание

Раздел 1. Жизненный цикл

информационной системы

Тема 1. Понятие жизненного цикла информационной

системы. Основные этапы жизненного цикла

информационной системы.

Практическая работа:

Посещение компании «Прогноз»

Тема 2. Каскадная модель жизненного цикла

информационных систем. Каскадная модель с

промежуточным контролем. Итеративная модель.

Спиральная модель жизненного цикла информационных

систем.

Практическая работа:

Разработка проекта информационной системы

Раздел 2. Общие сведения об

управлении проектами

Тема 3. Теоретические основы управления проектами,

основные понятия теории управления проектами,

определение термина «проект».

Практическая работа:

Управление проектами в среде OpenProj.

Тема 4. Инициация проекта, планирование, реализация,

завершение.

Практическая работа:

Управление проектами в среде OpenProj.

Тема 5. Обзор типичных рисков проекта. Планирование

управления рисками. План управления рисками. Анализ

рисков. Мониторинг и контроль рисков

Практическая работа:

Управление проектами в среде OpenProj.

Раздел 3. Модели разработки Тема 6. MSF, Agile Development Methods, DSDM

Практическая работа:

Разработка проекта информационной системы

Тема 7. Преимущества, недостатки, области применения

модели быстрой разработки RAD

Практическая работа:

Разработка проекта информационной системы

Практическая работа «Посещение компании «Прогноз»»

Одно из практических занятий проводится на базе международной

компании «Прогноз». Компания разрабатывает системы бизнес-аналитики и

визуализации данных для предприятий, ориентированных на повышение

эффективности управление и внедрения информационных технологий.

В рамках занятия, студенты знакомятся со структурой предприятия и

заданиями, которые решает каждое подразделение. А так же проходят

82

тестирования по различным областям знаний и уровням сложности, на

соревновательной основе с выявлением лучшего в группе.

Практическая работа «Разработка проекта

информационной системы»

Коллективная разработка проекта информационной системы, в

соответствии с некоторой предметной областью (например: ИС «Торговое

предприятие»).

Предлагается разработать проект из трех модулей системы: «Склад»,

«Продажи», «Управление предприятием». Проект каждого модуля выполняет

отдельная группа студентов (2-3 человека), в каждой группе выбирается

руководитель проекта (по решению студентов, состоящих в группе).

По окончанию работ, каждая группа защищает проект своего модуля,

затем все модули объединяются в общий проект.

Практическая работа «АС Аспирантура» в среде OpenProj

В данной лабораторной работе с использованием программного

продукта Serena OpenProj 1.4 будет создан проект по проектированию,

разработке и внедрению АС «Аспирантура», предназначенной для

автоматизации деятельности отдела аспирантуры и докторантуры высшего

учебного заведения. Проект будет состоять из следующих этапов:

1. разработка заявки на создание АС «Аспирантура»;

2. разработка концепции АС «Аспирантура»;

3. разработка технического задания на АС «Аспирантура»;

4. разработка эскизного проекта на АС «Аспирантура»;

5. разработка технического проекта на АС «Аспирантура»;

6. разработка рабочей документации на АС «Аспирантура»;

7. ввод в действие АС «Аспирантура».

Участники проекта: отдел аспирантуры и докторантуры, отдел

анализа информации, отдел разработки, отдел защиты информации.

83

Содержание семинарских занятий

Наименован

ие раздела

дисциплины

/тема

Тема семинарского

занятия

Вопросы для

обсуждения

Учебно-методическое

обеспечение

Раздел 1:

Тема 1

Стандарты ЖЦ ИС 1.ГОСТ 34.601-90

2.ISO/IEC 12207:2008

3.ISO/IEC 15288

1. Берг, Д.Б. Модели

жизненного цикла : учебное

пособие / Д.Б. Берг,

Е.А. Ульянова, П.В. Добряк ;

Министерство образования и

науки Российской

Федерации, Уральский

федеральный университет

имени первого Президента

России Б. Н. Ельцина. -

Екатеринбург : Издательство

Уральского университета,

2014. - 78 с. : ил., табл. -

Библиогр. в кн. - ISBN 978-

5-7996-1311-2 ; То же

[Электронный ресурс]. -

URL: http://biblioclub.ru/inde

x.php?page=book&id=275652

Раздел 1:

Тема 2

Обзор моделей

жизненного цикла,

достоинства и

недостатки

1.Каскадная модель

2.Итеративная модель

3.Спиральная модель

4. V-model

5. Dual Vee Model

1. Абрамов, Г.В.

Проектирование

информационных систем :

учебное пособие /

Г.В. Абрамов,

И.Е. Медведкова,

Л.А. Коробова. - Воронеж :

Воронежский

государственный

университет инженерных

технологий, 2012. - 172 с. :

ил.,табл., схем. - ISBN 978-5-

89448-953-7 ; То же

[Электронный ресурс]. -

URL:http://biblioclub.ru/index

.php?page=book&id=141626

Раздел 3:

Тема 6

Модели разработки

ПО

1.SCRUM

2.XP

3.Oracle

4.SAP

1. Долженко, А.И.

Технологии командной

разработки программного

обеспечения

информационных систем /

А.И. Долженко. - 2-е изд.,

исправ. - М. : Национальный

Открытый Университет

«ИНТУИТ», 2016. - 301 с. :

84

схем., ил. - Библиогр. в кн. ;

То же [Электронный

ресурс]. -

URL: http://biblioclub.ru/inde

x.php?page=book&id=428801

2. Абрамов, Г.В.

Проектирование

информационных систем :

учебное пособие /

Г.В. Абрамов,

И.Е. Медведкова,

Л.А. Коробова. - Воронеж :

Воронежский

государственный

университет инженерных

технологий, 2012. - 172 с. :

ил.,табл., схем. - ISBN 978-5-

89448-953-7 ; То же

[Электронный ресурс]. -

URL:http://biblioclub.ru/index

.php?page=book&id=141626

Темы рефератов

1. CASE-технологии проектирования информационных систем.

Характеристика CASE-средств.

2. Методологии и технологии проектирования ИС.

3. Особенности методологии RAD.

4. Объектно-ориентированный подход.

5. Стандарты и методики разработки информационных систем. Создание

структуры модели программного обеспечения.

6. Этапы проектирования баз данных.

7. Язык UML.

8. V-образная модель жизненного цикла ИС.

9. Ресурсы жизненного цикла ИС.

10. Затраты, возникающие в течение жизненного цикла ИС.

85

Материально-техническое обеспечение дисциплины

Специализированный компьютерный класс (ауд. А101, А102, А104,

А105к, А106, А116), подключенный к сети Интернет и к локальной сети

университета (Student…), обеспечивающей доступ к программному

обеспечению для проведения практических занятий.

Итогом изучения дисциплины является сдача зачета, при этом

учитывается посещаемость занятий, активность на лекциях, результаты

промежуточных тестирований в системе «Moodle», качество выполнения

лабораторных работ. В качестве самостоятельной работы, предлагается

написание реферата.

86

ПРИЛОЖЕНИЕ 2

Промежуточные контрольные тесты

Тест к разделу 1 «Жизненный цикл информационной системы»

1. Жизненный цикл информационной системы – … процесс,

началом которого становится момент принятия решения о

необходимости системы, а завершением – ее изъятие из эксплуатации.

(впишите слово)

Непрерывный

2. Расположите фазы жизненного цикла по порядку их реализации.

1) Эксплуатация

2) Разработка

3) Утилизация

4) Анализ и постановка задачи

5) Развертывание и внедрение

6) Замысел

7) Поддержка

8) Проектирование

6, 4, 8, 2, 5, 1, 7, 3.

3. По результатам проведения информационного обследования,

должны быть подготовлены:

(выберите один или несколько вариантов ответа)

1) Полное описание текущей бизнес-модели предприятия заказчика

2) Краткое описание текущей бизнес-модели предприятия

3) Коммерческое предложение со сформулированными проблемами, а

также ориентировочными сроками и бюджетом работ по дальнейшему

информационному обследованию и непосредственно внедрению системы.

4) Утвержденный план работ по разработке и внедрению (включая

состав группы внедрения с обеих сторон).

5) Утвержденный план работ по дальнейшему информационному

обследованию и непосредственно внедрению системы.

1,4

87

4. Решаемый вопрос на фазе анализа и постановки задачи.

(выберите один вариант ответа)

1) «Как должна работать будущая система?»

2) «Что должна делать будущая система?»

3) «Кто будет заниматься разработкой ИС?»

4) «Каков порядок действий при разработке ИС?»

2

5. Аспекты стадии сопровождения, приводящие к изменениям в

системе в процессе эксплуатации.

(выберите несколько вариантов ответа)

1) Обеспечение безусловного выполнения условий готовности модулей

системы к сдаче в опытно-промышленную эксплуатацию.

2) Увеличение производительности системы.

3) Устранение замечаний, не затрагивающее изменение ТЗ.

4) Подготовка и издание приказа по предприятию заказчика о передаче

модуля системы в эксплуатацию.

5) Обновления (по сути – новые версии системы), выпускаемые при

накоплении критического объема доработок.

2, 3, 5

6. … предполагает переход на следующий этап после полного

окончания работ по предыдущему этапу и характеризуется четким

разделением данных и процессов их разработки внедрения созданной ИС

и обучении пользователей.

(выберите один вариант ответа)

1) Каскадная модель.

2) Спиральная модель.

3) Икрементная модель.

4) Итеративная модель.

1

88

7. … предполагает увеличенное время, отведенное на разработку,

за счет проведения промежуточных корректировок между фазами

жизненного цикла.

(выберите один вариант ответа)

1) Каскадная модель.

2) Каскадная модель с промежуточным контролем

3) Итеративная модель.

4) Спиральная модель.

2

8. Фазы жизненного цикла данной модели непоследовательны, то

есть допустимо (но не обязательно!) начало работ над следующим этапом

до завершения предыдущего.

(выберите один вариант ответа)

1) Каскадная модель.

2) Спиральная модель.

3) Итеративная модель.

4) Каскадная модель с промежуточным контролем.

2

9. (выберите один вариант ответа)

1) Каскадная модель.

2) Спиральная модель.

3) Итеративная модель.

4) Каскадная модель с промежуточным контролем.

3

10. Жизненный цикл информационной системы – … процесс,

началом которого становится момент принятия решения о

необходимости системы, а завершением – ее изъятие из эксплуатации.

89

(впишите слово)

Непрерывный

11. Жизненный цикл ИС регламентирует стандарт ISO/IEC 12207.

IEC – это...

(выберите один вариант ответа)

1) Международная организация по стандартизации.

2) Международная комиссия по электротехнике.

3) Международная организация по информационным системам.

4) Международная организация по программному обеспечению.

2

12. Согласно стандарту, структура жизненного цикла ИС состоит

из процессов …

(выберите один вариант ответа)

1) Основных и вспомогательных процессов жизненного цикла и

организационных процессов.

2) Разработки и внедрения.

3) Программирования и отладки.

4) Создания и использования ИС.

1

13. Согласно ISO 12207, объединение одного или нескольких

процессов, аппаратных средств, программного обеспечения,

оборудования и людей для удовлетворения определённым потребностям

или целям это …

(выберите один вариант ответа)

1) вычислительный центр

2) информационная система

3) полнофункциональный программно-аппаратный комплекс

4) система

4

90

Тест к разделу 2 «Общие сведения об управлении проектами»

1. Общепринятые методики управления проектами, стандарты и

ключевые термины содержатся в руководстве по управлению

проектами…

(выберите один вариант ответа)

1) PMBOK

2) MPBOK

3) BOKPM

4) PMKOB

1

2. Проект – это … предприятие, предназначенное для создания

уникальных продуктов, услуг или результатов.

(впишите слово)

Временное

3. Установите соответствие:

1) Задача

2) Ресурсы

3) Назначения

4) Веха

А) Исполнители, оборудование и материалы, необходимые для

выполнения задачи.

Б) Связь конкретной задачи с ресурсами, выделенными для ее

выполнения.

В) Деятельность, осуществляемая в рамках проекта, для достижения

определенного результата

Г) Задача, достижение результата которой особенно важно для проекта,

используется для обозначения окончания основных этапов проекта.

1-В, 2-А, 3-Б, 4-Г

4. Проектным треугольником называют…

(выберите один вариант ответа)

91

1) объем работ, время, стоимость

2) объем работ, трудозатраты, стоимость

3) ресурсы, время, трудозатраты

4) объем работ, задачи, стоимость

1

5. Перечислите артефакты этапа реализации.

(выберите несколько вариантов ответа)

1) Рабочее описание

2) Отчет о состоянии

3) Итоговый отчет

4) Документы проекта

5) Исходные коды

6) План управления

1, 2, 4, 5

6. Перечислите артефакты этапа завершения.

(выберите несколько вариантов ответа)

1) Рабочее описание

2) Протоколы и приемо-сдаточные испытания

3) Архив проекта

4) Документы проекта

5) Итоговый отчет

2, 3, 5

7. К бизнес-рискам относятся…

(выберите несколько вариантов ответа)

1) Контрактные риски.

2) Сбытовые риски

3) Управленческие риски

4) Инвестиционные риски

5) Эксплуатационные риски

1, 2, 4

92

8. Выберите бюджетную форму из ниже перечисленных, которая не

существует.

(выберите один вариант ответа)

1) Бюджет доходов и расходов

2) Бюджет движения денежных средств

3) Прогнозный баланс

4) Бюджет затрат

4

9. Член команды управления проектом, лично отвечающий за все

результаты проекта.

(выберите один вариант ответа)

1) Заказчик проекта

2) Куратор проекта

3) Руководитель проекта

4) Инициатор проекта

3

10. Участники проекта, задействованные в его реализации.

(выберите один вариант ответа)

1) Команда проекта

2) Потребители продукта проекта

3) Команда управления проектом

4) Заказчики проекта

1

11. Управление риском проекта это…

(выберите один вариант ответа)

1) Системное применение политики, процедур и методов управления к

задачам определения ситуации, идентификации, анализа, оценки,

обработки, мониторинга риска и обмена информацией, для

обеспечения снижения потерь и увеличения рентабельности.

2) Системное применение политики, процедур и методов управления

целями проекта, анализа, оценки, обработки, мониторинга

информацией, для обеспечения снижения потерь и увеличения

рентабельности.

93

3) Системное применение политики, процедур и методов управления

командой проекта и обмена информацией, для обеспечения

снижения потерь и увеличения рентабельности.

4) Системное применение политики, процедур и методов управления к

задачам определения ситуации, мониторинга риска и обмена

информацией, для обеспечения снижения потерь.

1

94

Тест к разделу 3 «Модели разработки»

1. Словосочетание – быстрая разработка приложений сокращённо

записывается как…

(выберите один вариант ответа)

1) RAD

2) CAD

3) MAD

4) HAD

1

2. Методология быстрой разработки приложений используется для

разработки …

(выберите один вариант ответа)

1) типовых ИС

2) небольших ИС

3) приложений, в которых интерфейс пользователя является вторичным

4) систем, от которых зависит безопасность людей

2

3. Активности роли управление продуктом в модели проектной

группы MSF.

(выберите несколько вариантов ответа)

1) Приоритеты бизнеса

2) Эргономика

3) Маркетинг

4) Представление интересов заказчика

5) Планирование продукта

1, 3, 4, 5

4. Методология Agile является…

(выберите один вариант ответа)

1) гибкой методологией

2) методологией быстрой разработки приложений

95

3) быстрой методологией

4) скорой методологией

1

5. Благодаря методу RAD, … задействован на всех фазах

жизненного цикла разработки проекта – не только при определении

требований, но и при проектировании, разработке, тестировании, а так

же конечной поставке программного продукта.

(впишите слово)

Пользователь

6. Фаза, объединяющая в себе детализированное проектирование,

построение ИС и ее тестирование, а так же постановку программного

продукта заказчику за определенное время.

(выберите один вариант ответа)

1) Планирование требований

2) Совместное проектирование

3) Конструирование

4) Перевод на новую ИС

3

7. Недостатки модели RAD

(выберите несколько вариантов ответа)

1) Пользователи должны иметь возможность принимать участие в

процессе разработки на протяжении всего жизненного цикла;

2) Разработчики должны быть высококвалифицированными и уметь

пользоваться выбранными CASE-средствами;

3) В модели повторно используются компоненты уже существующих

программ;

4) Благодаря принципу временного блока, уменьшаются затраты и

риск, связанный с соблюдением графика;

5) Как разработчики, так и заказчики должны быть готовы к быстрому

выполнению действий ввиду жестких временных ограничений, чему

должна способствовать система материальной заинтересованности.

1, 2, 5

96

8. Назовите «три кита», на которых основана модель RAD.

(выберите несколько вариантов ответа)

1) Участие пользователя в процессе разработки;

2) Короткое время перехода от определения требований до создания

полной системы;

3) Широкое применение CASE-средств и реинжениринга;

4) Временные блоки;

5) Использование готовых программных компонентов.

1, 3, 4