Бизнес-информатика. Введение в специальность

Заказчики

Разработчики

Пользовательское

Составление

описание

Создание

Сопровождение

требований

и планирование

Рис. 1.3 – Модель быстрой разработки приложений

RAD-моде ь включает

фазы:

•

сос авление

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

ляется с использованием так называемого метода совместного плани

рования

(планирование работ по созданию ПП и состав-

ление

ПП

выполняются

одновременно),

который

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

(будущего функционала);

• пользовательское описание (проектирование ПП, выполняемое при

непосредственном

заказчика, ри этом работающая над про-

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

инструментальные

•

ре ства, обеспечивающие сб

рмации);

создание (детальное проектировани ,

инфотестирование ПП

его п ставка заказчику за

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

Достоинства RAD-мод ли состоят в следующем:

•

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

кра ить время ЖЦ разработ и;

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

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

ческ м потребностям и надёжность программного продукта в эксплу-

атации;

• основное внимание переносится с разработки документации на созда-

•

ние кода;

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

В топовтоже ремя RAD-модели

и недостатки:

цессе разработ

•

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

ки, то это может негативно сказаться на качестве программного про-

•

укта;

кадры: разрабо чики и

для работы нужны

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

ми средствами;

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

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

• для реализации модели требуются разработчики и заказчики, котор

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

•

ограничений;

омощью моде

команды, разрабатывающие коммерческие проекты с

ли RAD, могут «затянуть» разраб тку программного

продукта до та-

к й степени, что его поставка

конечному

пользователю будет под

•

большим вопросом;

что работа над проектом никогда не будет з верше

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

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

явления замкнутого цикла.

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

хорошо поддающихся моделированию, когда

к ПП хорошо извест-

1.4 Проектная деятельность ИТ-компании

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

рамках проектной деятельности ИТ-компании. Определим проектную деятель

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

-

лекса

работ с целью

качественного программного

родукта

течение заданного периода

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

потребляемых

ходе реализации проекта

ресурсах. Основные участники про-

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

Куратор проекта

Заказчик

Об печиваетИнициирует

Продукт проекта

ресу сами,

результаИмеетом

поддерживает

Проект

Отчитывается

Утверждает

Отчитывается

Планирует, контролирует,

Работает над

Создает

Назначает,

обеспечивает реализацию

делегирует

Базовый план

Выполняют

полномочия

Разрабатывает

Руководит

работы

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

согласно

проекта

Команда проекта

Рис. 1.4 – Модель проектной деятельности

которое является

Заказчик проекта – физическое или юридическое

владельцем результата проекта; рук

– лицо, осуществляющее

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

кта –

лицо, ответственное за

проекта есурсами и осуществляющее

д-

министративную, финансовуюобеспечениеную

поддержку

проекта; команда

проекта –

совокупность лиц, групп

орга изаций, объединенных во временную органи-

зационную структуру для выполнения работ проекта.

Цели проектной деятельности команды проекта следует определя ь с

четом правила «железного треугольника» (рис. 1.5) [8]. Ни один из углов тре-

гольника не

ожет быть изменен без изменения других: например, чтобы

уменьшить

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

Остановимся далее на описан содержания стандарта PMBOK [8]. Стан

дарт PMBOK был разработан Институтом управления проектами (Project Man-

agement I stitute – PMI) в 2000 г. Последняя версия – The Guide to the PMBOK

5th Edition

– вышла в начале 2013 г. Стандарт, первоначально принятый в каче-

стве Национального стандарта Америки (ANS) Американским национальным

институтом

(ANSI), в настоящее время нашел шир кое применен е

во многих странахстандартов

сферах

деятельности. Руководство содержит

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

неджмента, формали

струк урированные таки

образом, чтобы их

можно было использоватьзованныебольшинстве проектов независимо от их конкрет-

ного применения.

В стандарте PMBOK 5th Edition описаны пять групп управленческих

роцессов, соответствующих этапам

цикла проекта: инициация,

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

авершение.

Документ содержит описание десяти обла тей

знаний,

которые исполь-

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

этапов жизненного цикла проекта: управление интеграцией

оекта, управле

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

ние стоимо

тью проекта, управление качеством проекта, у

авление

человеческими ре-

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

проекта, управление закупками проекта, управление заинтересованными сторо-

нами проекта.

приведен пример распределен я

процессов

управления

В таблице 1.1

проектом по областям знаний и этапам жизненного цикла.

Таблица 1.1 –

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

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

Область

Инициация

Планирование

Исполне-

Мониторингуправле-

Завер-

знаний

ние

шение

1. Управле

1.1. Разра-

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

1.4. Руко-

1.5.

ние

-

1.7. За-

ние инте-

ботка Уста-

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

водство

е

рингМонитокон-

ытие

грацией

ва

-

.

проектом

управле

троль работ

проекта

проекта

1.2. Раз

исполнени-

проекта.

боткапроектаед-

ем проекта

1.6. Общее

варительнос держания

изменениями

го описания-

управление

проекта

Область

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

знаний

Инициация

Планирование

Исполне-

Мониторингуправле-

Завер-

2. Управ

2.1. Планирование

ние

ние

шение

2.4. Под-

л

со-

содержания про-

твержде е

д

ржанием

екта.

содержания.

проекта

2.2. Определение

2.5. Управле

содержания.

содержа-

2.3. Создание

нием

иерархической

структуры работ

3. Управ-

(ИСР)

3.6. Управле-

3.1. Определение

лен е сро-

состава работ.

расписа-

ками про-

3.2. Определение

нием

екта

взаимосвязей.

3.3. Оценка ресур-

сов работ.

3.4. Оценка дли-

тельности.

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

4. Управ-

расписания

4.3. Управле-

4.1. Стоимостная

ление сто-

оценка.

ние стоимо-

имостью

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

стью

проекта

5. Управ

бюджета расходов

5.3. Процесс

5.1. Планирование

л ние ка-

качества

контроля ка-

проекта

качества

чества

ч ством

6.1. Планирование

6. Управ

6.2. Набор

6.4. Управле-

ение че-

человеческих ре-

команды

ние

ловече-

сурсов

проекта.

проекта

скими

6.3. Разви-

ресурс ми

тие коман-

проекта

ды проекта

Область

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

знаний

Инициация

Планирование

Исполне-

Мониторингуправле-

Завер-

7. Управ-

7.1. Планирование

ние

ние

шение

7.2. Распро-

7.4. Управле-

ление ком-

коммуникаций

странение

ние участни-

муникаци-

информа-

ками проекта

ями

ции.

проекта

7.3. Отчет-

8. Управ-

8.1. П а рование

н сть по ис-

8.6.

-

полнению

лен е рис-

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

ри

гМонитоуправ-

ками про-

ками.

ление риска-

екта

8.2. Идентифика-

ми

ция рисков.

8.3. Качественный

анализ рисков.

8.4. Количествен-

ный анализ рис-

ков.

8.5. Планирование

еагирования на

риски

·····························································

Контрольные вопросы по главе 1

·····························································

1. Приведите определение программного продукта. Перечислите свой-

ства ПП как объекта интеллектуальной собствен

сти.

2 Моделирование бизнес-процессов предметной области

2.1 Структурный подход к построению моделей бизнес-процессов

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

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

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

В свою очередь под бизнес-процессом понима тся:

•

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

ности, преобразующих

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

для клиента;

деятельности организа-

• множество внутренних упорядоченных вид

ции по преобразованию исходных

ресурсов

в готовую продукцию

(услугу).

бизнес-процессов должно тать выделение

Первым шагом по

ос овных продуктов (услуг)выявлениювыстраивание процессов в соответствии с жиз-

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

·····························································

цес

Жизненный цикл – строго упорядоченная совокупность п о

, описывающих

преобразование исходных ре-

сурсов в конечные продуктыэволюционноеуслуги.

·····························································

На рисунке 2.1 представлен пример обобщенной модели жизненного цик-

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

программного продукта представлены ранее на рисунке 1.1.

Контроль

Закупка

Транспор-

Хранение сырья в

сырья

тировка

системе снабжения

качества сырья

Производство

Контроль

ачества

Хранение продукта

продукции

продукции

в системе сбыта

Упаковка

Транспортировка

Реализация

Рис. 2.1 – Модель жизненного цикла создания материального продукта

Основным инструментом анализа и совершенствования бизнес-процессов

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

является моделирование. Модель бизнес-процесса – это

образ реаль

бенн стях.

Анализ модели существующих бизнес-проц ссов дает представле-

ние о

том, каким образом происходит

преобразование

входных ресурсов в

продукцию (услуги) и позволяет дать оценку эффективности функционирова-

ния бизнеса. Такая модель получила название «Как есть». С вершенств

(реинжиниринг) бизнес-процессов

«Как есть»

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

нового

позволяют смоделировать

представле илиботом, как должен

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

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

·····························································

Для измерения эффективности бизнес-процессов, планирова-

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

ключевые показатели результативности (метрики) – измеримые

х рактеристики (атрибуты),

которым

можно

определять,

насколько эффективно

выполняется процесс.

·····························································

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

бизнес-проце сов разраб тки ПП это – время, стоимость

каче тво.

Для

моделей бизнес-процесс в

используются, как правило,

структурныепостроенияобъектно-ориентированные подходы [4] (рис. 2.2).

Методологии моделирования бизнеса

Структурные

Объектно-

ориентированные

IDEF0

IDEF1X

IDEF3

DFD

OMT

Booch

OOSE

UML

Рис.

2.2 – Классификация

методологий

моделирования бизнеса

зиция

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

бизнеса лежит декомпо-

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

подсистемысистемыт. д. Базовые принципы структурного подхода: