Файл: Методические рекомендации по написанию магистерской диссертации для направления Прикладная информатика.doc

Процесс бизнес моделирования рассматривается как работа над проектом по созданию ПО на начальной фазе проекта. Моделирование бизнес - процессов включает их выявление и классификацию, уточнение связей между бизнес - процессами, описание реализации бизнес - процессов, определение ролей и их обязанностей внутри бизнес - процесса.

Различные методологии, используемые в сфере ИТ, предлагают свои принципы формирования команды ИТ проекта и распределения ролей между членами команды. Например, методология Microsoft Solutions Framework (MSF) предлагает модель проектной группы, состоящую из шести ролевых кластеров [1, С. 13-15]:

1. 
   Управление продуктом (product management),
   
2. 
   Управление программой (program management),
   
3. 
   Разработка (development),
   
4. 
   Тестирование (test),
   
5. 
   Удовлетворение потребителя (user experience)
   
6. 
   Управление выпуском (release management).
   

Состав ролей может широко варьироваться в разных организациях и проектных командах. Чаще всего роли распределяются среди различных подразделений одной организации (при матричной структуре команды), но иногда часть их отводится внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат. В таблице 1 представлены функции каждого ролевого кластера.

Таблица 1

Функции ролевых кластеров

Ролевой кластер	Функции
Управление продуктом	Выступает в роли представителя заказчика Формирует общее видение/рамки проекта Организует работу с требованиями заказчика Развивает сферы применения в бизнесе Формирует ожидания заказчика Определяет компромиссы между параметрами «возможности продукта- время – ресурсы» Организует маркетинг, PR Разрабатывает, поддерживает и исполняет план коммуникаций
Управление программой	Управляет процессом разработки с целью получения готового продукта в отведенные сроки Формулирует спецификацию продукта и разрабатывает его архитектуру Регулирует взаимоотношения и коммуникацию внутри проектной группы Следит за временным графиком проекта и готовит отчетность о его состоянии Проводит в жизнь важные компромиссные решения Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта Организует управление рисками
Разработка	Определяет детали физического дизайна Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна Разрабатывает или контролирует разработку элементов Подготавливает продукт к внедрению Консультирует команду по технологическим вопросам
Тестирование	Обеспечивает обнаружение всех дефектов Разрабатывает стратегию и планы тестирования Осуществляет тестирование
Удовлетворение потребителя	Представляет интересы потребителя в команде Организует работу с требованиями пользователя Проектирует и разрабатывает системы поддержки производительности Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта Определяет требования к системе помощи и её содержание Разрабатывает учебные материалы и осуществляет обучение пользователей
Управление выпуском	Представляет интересы отделов поставки и обслуживания продукта Организует снабжение проектной группы Организует внедрение продукта Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта Организует сопровождение и инфраструктуру поставки Организует логистическое обеспечение проектной группы

---

Шесть ролевых кластеров в модели определяют направления деятельности и цели. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. В различных проектах численность и состав команды может быть разный. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей. Но в небольших проектах часто приходиться объединять роли.

При этом должны соблюдаться два принципа [1, С. 35-36]. Во-первых, роль команды разработчиков не может быть объединена ни с какой другой ролью. Второй принцип – это избежание сочетания ролей, имеющих предопределенные конфликты интересов. Стандарт MSF рекомендует следующие сочетания ролей (рис. 3).

---

Рисунок 3. Объединение ролей в проектных командах.
Руководители проекта должны создавать отношения сотрудничества между участниками проекта, добиваться общего видения проблем и путей их разрешения. Члены команд в свою очередь должны объединять усилия для достижения общих целей, избегать конфликтов, помогать и поддерживать друг друга. Надежная внутренняя среда проекта - залог успеха любого проекта.

Рекомендуемая литература по данному разделу:

1. 
   Microsoft Solutions Framework, Модель процессов MSF, вер.3.1 (Отдел MSF, Microsoft ) - White Paper.- 2002.
   
2. 
   Р. Денис Гиббс. Управление проектами с помощью IBM Rational Unified Process. Практические уроки. Пер.с англ. – М.: КУДИЦ-ПРЕСС. – 2007. – 304 с
   
3. 
   Алексеева Т.В. Организация взаимоотношений участников ИТ - проекта. // «Бизнес команда и ее лидер», № 6.- М.: ООО «Интерсоциоинформ».- 2008.- 8 стр.
   

3. 
   Средства коллективной работы над проектом автоматизации
   

После создания команды и распределения ролей между членами команды необходимо определится с средствами коллективной разработки (СКР), которые вы будете использовать. Неправильный выбор может повлечь за собой как огромные потери времени на освоение и настройку СКР, так и необоснованно высокие затраты на приобретение программ, у которых вы не будете использовать все имеющиеся возможности.

Для выбора СКР предлагается Вам использовать обзор, представленный в таблице 1 и 2. Вышеприведенный обзор включает всего три средства коллективной разработки, хотя всего таких программ, конечно, гораздо больше. В таблице 1 приведена таблица возможностей некоторых коммерческих СКР, а в таблице 2 - некоммерческих. К сожалению, все имеющиеся средства перечислить невозможно. Достаточно полный список ссылок на сайты производителей СКР можно найти по адресу http://www.cs.colorado.edu/users/andre/configuration_management.html

Таблица 1 Коммерческие средства разработки

Название программы

VC

Cnf

Brn

Shr

Net

FS

Srv

cmd

GUI

jc

Bc

Bt

Price

Perforce

+

+

+

-

+

-

S

+

-

+

-

-

$500

GP-Version

+

-

+

+

+

+

S

-

+

-

P

+

$325

MKS Source Integrity P.E

+

+

+

?p

+

+

S

+

+

+

+

?-

$599

Code Co-op 2.0

+

+

-

-

*

+

W

-

+

-

-

-

$150

CS-RCS

+

-

+

-?

+

+

S

-

+

-

-

-

$75

PVCS Version Manager

+

-

-

-

-

+

S

=

+

-

-

-

$620

StarTeam

+

+

+

+?

+

+

S

?-

+

+

-

+

$650

VERSIONS 2.0

+

+

+

-?

-

+

S

-

+

-

-

-

$220

TLIB 5.5

+

+

+

-

-

+

S

+

=

-

-

-

$225

Visual SourceSafe 6.0

+

+

+

+

*

+

S

+

+

-

-

-

$549

---

Таблица 2 Некоммерческие средства разработки

Название программы

VC

Cnf

Brn

Shr

Net

FS

Srv

Cmd

GUI

Jc

Bc

Bt

Lic

Revision Control System (RCS)

+

-

+

-

-

+

S

+

-

-

-

-

GNU

Concurrent Versions System (CVS) 1.10

+

+

+

+

+

+

S

+

*

-

-

-

GNU

CSSC (free version of SCCS)

+

-

+

-

-

+

S

+

-

-

-

-

GNU

Proj. Rev. Control System (PRCS)

+

+

+

+

-

+

S

+

-

-

-

-

GNU

Aegis (by Peter Miller) 3.12

+

+

+

-

*

+

B

+

-

-

+

-

GNU

Условные обозначения

VC – поддержка контроля версий;

Cnf – автоматизация разрешения конфликтов;

Brn – поддержка ветвления версий;

Shr – возможность использования одного файла в нескольких проектах;

Net – доступ к БД проекта по сети (TCP/IP);

FS - доступ к БД проекта с использованием файловой системы;

Srv – серверный ли тип этой СКР (S - серверный, W - бессерверный, B - работа в обоих режимах);

Cmd – наличие интерфейса командной строки;

GUI – наличие графического интерфейса;

jc - автоматизация управления распределением обязанностей;

---

bc - контроль и ускорение сборки проекта;

bt - встроенная система поиска ошибок;

Lic – условия распространения (для некоммерческих средств).

+ имеется

- отсутствует

= имеется в большинстве поставок

* поддерживается внешними средствами

не удалось получить точных сведений

p находится в зачаточном состоянии

Как видно из таблицы 1, цена за одно рабочее место пропорциональна количеству "плюсиков". С другой стороны, практика показывает, что поставщики относительно дорогого ПО предлагают достаточно качественную техническую поддержку. Это поможет тем, кто впервые связался с СКР, сэкономить значительное количество времени. Многие разработчики все же делают выбор в пользу недорогих СКР.

Следующим вопросом является выбор между работой в командной строке и графическим интерфейсом. Любое пожелание на этот счет можно оспорить. Если большая часть разработчиков в вашем коллективе может быстро набирать команды СКР на клавиатуре, то системы вроде Perforce или CVS - это для вас. Большинству все же удобнее работать с графическим интерфейсом. Тут, правда, есть одна тонкость: большая часть средств коллективной разработки имеет графический интерфейс только в версиях для операционной системы Windows. Практически все коммерческие СКР обладают этой особенностью.

Некоммерческие СКР, разработка которых годами велась под UNIX'ом, не имеют графического интерфейса. Тем не менее, благодарные пользователи понаписали множество внешних утилит, предоставляющих возможность производить часть операций все же не в командной строке, а с использованием графического интерфейса. Чемпионом по количеству таких утилит - около 5 - является CVS (что свидетельствует о популярности). Стоит отметить WinCVS (Win32, MacOS) и JCVS (Java).
2.3 Информационное обеспечение задачи

2.3.1 Информационная модель и её описание

Методика разработки информационной моделипредполагает моделирование нового варианта организации информационной системы предметной области («КАК ДОЛЖНО БЫТЬ»), а именно:

0. 
   полного состава информации, необходимой для решения комплекса задач данного АРМа;
   
1. 
   отражение этой информации на всех типах носителей;
   
2. 
   отражение процесса преобразования информации, начиная от получения первичной переменной и условно-постоянной информации, загрузки ее в файлы с и заканчивая получением файлов с результатной информацией и выдачей ее пользователю;
   
3. 
   состава исходных первичных документов и распределение их по задачам;
   
4. 
   источники и способы получения первичной информации;
   
5. 
   состава файлов с первичной, условно-постоянной, промежуточной и результатной информацией;
   
6. 
   информационную потребность для каждой задачи комплекса;
   
7. 
   адресатов выдачи и получения результатной информации.
   

---