производительности
О пределяет компром иссы , относящ иеся к удобству использования
и п отребительским качествам п родукта
О пределяет требования к систем е пом ощ и и её содерж ание
Разрабаты вает учебны е м атериалы и осущ ествляет обучение
пользователей
У правлен ие
выпуском
П редставляет интересы отделов поставки и обслуж ивания продукта
О рганизует снабж ение проектной группы
О рганизует внедрение продукта
В ы рабаты вает ком пром и ссы в управляем ости и удобстве
сопровож дения продукта
О рганизует сопровож дение и инфраструктуру поставки
О рганизует логистическое обеспечение проектной группы
6. Управление выпуском (release management).
Состав ролей может широко варьироваться в разных организациях и
проектных командах. Чаще всего роли распределяются среди различных
подразделений одной организации (при матричной структуре команды),
но иногда часть их отводится внешним по отношению к организации
консультантам и партнерам. Ключевым моментом является четкое
определение работников, ответственных за каждый ролевой кластер, их
функций, ответственности и ожидаемого вклада в конечный результат. В
таблице 2.3 представлены функции каждого ролевого кластера.
Шесть ролевых кластеров в модели определяют направления
деятельности и цели. Модель не требует назначения отдельного сотрудника
на каждый ролевой кластер. В различных проектах численность и состав
команды может быть разный. Обычно, выделение как минимум одного
человека на каждый ролевой кластер обеспечивает полноценное внимание к
интересам каждой из ролей. Но в небольших проектах часто приходиться
объединять роли.
При этом должны соблюдаться два принципа. Во-первых, роль
команды разработчиков не может быть объединена ни с какой другой ролью.
Второй принцип - это избежание сочетания ролей, имеющих
предопределенные конфликты интересов. Стандарт MSF рекомендует
следующие сочетания ролей (рис. 2.5).
74
Управление
продуктом
Управление
программой
Тестирование
У д о в л етвор е н и е
потребите л я
Управление
выпуском
Управление
продуктом
- -
+ +
+
Управление
программой
- -
+ +
+
- - - - -
Тестирование
+
+
-
+ +
У д о вл е тв о р ени е
потребите л я
+
+
-
+
+
Управление
выпуском
+
+
______
I
______
1
+
+ !
+ Допустимо ± Нежелательно - Нельзя
Рисунок 2.5 - Объединение ролей в проектных командах
Руководители проекта должны создавать отношения сотрудничества
между участниками проекта, добиваться общего видения проблем и путей их
разрешения. Члены команд в свою очередь должны объединять усилия для
достижения общих целей, избегать конфликтов, помогать и поддерживать
друг друга. Надежная внутренняя среда проекта - залог успеха любого
проекта.
2.2.3 Средства коллективной работы над проектом автоматизации
После создания команды и распределения ролей между членами команды
необходимо определится с средствами коллективной разработки (СКР), которые вы
будете использовать. Неправильный выбор может повлечь за собой как огромные
потери времени на освоение и настройку СКР, так и необоснованно высокие
затраты на приобретение программ, у которых вы не будете использовать все
имеющиеся возможности.
Для выбора СКР предлагается Вам использовать обзор, представленный в
таблице 2.2 и 2.3. Вышеприведенный обзор включает всего три средства
коллективной разработки, хотя всего таких программ, конечно, гораздо больше. В
таблице 2.4 приведена таблица возможностей некоторых коммерческих СКР, а в
таблице 2.5 - некоммерческих. К сожалению, все имеющиеся средства перечислить
невозможно.
Таблица 2.4
75
Коммерческие средства разработки
Н азвание
програм мы
VC
C nf Brn Shr
N et FS Srv cm d G U I
jc
Bc B t
Price
Perforce
+ + +
-
+
- S
+
-
+
- -
$500
G P-V ersion
+
-
+ + + +
S -
+
-
P
+
$325
M K S Source
Integrity P .E
+ + +
?p
+ +
S
+ + + +
?-
$599
Code C o-op 2.0
+ +
- -
*
+
W -
+
- - -
$150
CS-RCS
+
-
+
-?
+ +
S -
+
- - -
$75
PV C S V ersion
M anager
+ +
S
+
~$620
StarTeam
+ + +
+?
+ +
S
?-
+ +
-
+
~$650
V E R SIO N S 2.0
+ + +
-?
-
+
S -
+
- - -
~$220
TLIB 5.5
+ + +
- -
+
S
+
=
- - -
$225
V isual SourceSafe
6.0
+ + + +
*
+
S
+ +
$549
Таблица 2.5
Некоммерческие средства разработки
Н азвание
програм мы
VC
C n f B rn Shr
N et FS Srv Cm d G U I Jc B c B t Lic
R evision C ontrol
System (R CS)
+ + +
S
+
G N U
C oncurrent V ersions
System (C V S) 1.10
+ + + + + +
S
+
*
G N U
CSSC (free version
o f SCCS)
+ + +
S
+
G N U
Proj. Rev. C ontrol
System (PRCS)
+ + + + +
S
+
G N U
A egis (by P eter
M iller) 3.12
+ + +
*
+
B
+ +
G N U
Условные обозначения
VC - поддержка контроля версий;
76
Cnf - автоматизация разрешения конфликтов;
Bm - поддержка ветвления версий;
Shr - возможность использования одного файла в нескольких проектах;
Net - доступ к БД проекта по сети (TCP/IP);
FS - доступ к БД проекта с использованием файловой системы;
Srv - серверный ли тип этой СКР (S - серверный, W - бессерверный, B -
работа в обоих режимах);
Cmd - наличие интерфейса командной строки;
GUI - наличие графического интерфейса;
jc - автоматизация управления распределением обязанностей;
bc - контроль и ускорение сборки проекта;
bt - встроенная система поиска ошибок;
Lic - условия распространения (для некоммерческих средств).
+ имеется
- отсутствует
= имеется в большинстве поставок
* поддерживается внешними средствами
~ не удалось получить точных сведений
p находится в зачаточном состоянии
Как видно из таблицы, цена за одно рабочее место пропорциональна
количеству плюсиков . С другой стороны, практика показывает, что поставщики
относительно дорогого ПО предлагают достаточно качественную техническую
поддержку. Это поможет тем, кто впервые связался с СКР, сэкономить
значительное количество времени. М ногие разработчики все же делают выбор в
пользу недорогих СКР.
Следующим вопросом является выбор между работой в командной строке и
графическим интерфейсом. Любое пожелание на этот счет можно оспорить. Если
большая часть разработчиков в вашем коллективе может быстро набирать команды
СКР на клавиатуре, то системы вроде Perforce или CVS - это для вас. Большинству
все же удобнее работать с графическим интерфейсом. Тут, правда, есть одна
тонкость: большая часть средств коллективной разработки имеет графический
77
интерфейс только в версиях для операционной системы Windows. Практически все
коммерческие СКР обладают этой особенностью.
Некоммерческие СКР, разработка которых годами велась под U N IX W , не
имеют графического интерфейса. Тем не менее, благодарные пользователи
понаписали множество внешних утилит, предоставляющих возможность
производить часть операций все же не в командной строке, а с использованием
графического интерфейса. Чемпионом по количеству таких утилит - около 5 -
является CVS (что свидетельствует о популярности). Стоит отметить W inCVS
(Win32, M acOS) и JCVS (Java).
2.3 Информационное обеспечение задачи
2.3.1 Информационная модель и её описание
Графическое представление информационной модели отражено на рис.
2.6.
78
79
2.3.2 Характеристика нормативно-справочной, входной и
оперативной информации
Сущность "Договор". Данная сущность предназначена для хранения
информации о документах, а также текстов самих договоров, составляемых в
лизинговой компании. С ее помощью работник, наделенный
соответствующими полномочиями, может в любой момент просмотреть
интересующий его документ, проверить его на исполнение и запросить отчет.
Изменения в данную сущность вносятся автоматически при добавлении
нового договора либо редактирования уже существующего, если данный
сотрудник имеет соответствующие права доступа. Также по данной
сущности можно составлять разнообразные отчеты, в зависимости от их
целевого назначения.
Сущность "Договор" обладает следующими атрибутами:
■ полное наименование договора;
■ краткое наименование (вводится для более удобного и быстрого
поиска данного конкретного договора);
■ юридический номер договора (уникальный номер договора, который
закрепляется за ним юридически, в соответствии с законом; является
первичным ключом);
■ примечания (сотрудники компании могут оставлять необходимые им
пометки по конкретному договору);
■ дата (дата подписания договора);
■ состояние (отмечается исполнен ли договор в данный момент);
■ порядковый номер сделки (невидимая пользователю информация,
необходимая для связи с сущностью "Сделка");
■ ИНН контрагента (идентификационный налоговый номер фирмы;
невидимая пользователю информация, необходимая для связи с сущностью
"Контрагент").
Сущность "Личность". В этой сущности находится информация о
людях, с которыми когда-либо контактировала лизинговая компания. данная
80
сущность является одной из наиболее важных в системе, поскольку все
документы составляются и подписываются конкретными людьми, с
которыми всегда необходимо иметь возможность связаться.
Сущность "Личность" обладает следующими атрибутами:
■ фамилия, имя, отчество личности;
■ дата рождения;
■ номер пенсионного свидетельства (уникальный номер,
присваиваемый в пенсионном фонде единожды; является первичным
ключом);
■ прописка (адрес, по которому официально прописана личность);
■ фактический адрес (адрес фактического проживания);
■ электронная почта;
■ рабочий телефон;
■ домашний телефон.
Сущность "Контрагент". В данной сущности расположена информация
о юридических лицах, с которыми лизинговая компания имеет деловые
отношения. С помощью данных, хранящихся в этой сущности, сотрудники
организации имеют возможность без каких-либо затруднений в любое время
получить информацию о каждой, интересующей их компании, с которой
лизинговая фирма имеет дело. Это позволит избежать не желательных сделок
с ранее не устроившими юридическими лицами.
Сущность "Контрагент" обладает следующими атрибутами:
■ полное наименование (юридически закрепленное полное название
фирмы);
■ дата регистрация (дата регистрации фирмы);
■ ОПФ (организационно правовая форма компании);
■ ЕГРЮЛ (единый государственный регистр юридических лиц);
■ ИНН (уникальный идентификационный налоговый номер; является
первичным ключом);
■ юридический адрес (адрес, на котором официально зарегистрирована
81
данная фирма);
■ почтовый адрес;
■ электронная почта;
■ телефон.
Сущность "Заявка". Здесь хранится информация о заявках, подаваемых
различными юридическими лицами в лизинговую компанию на
предоставление услуг. Эти данные необходимы работникам для того, чтобы
иметь возможность проследить в чем нуждаются клиенты лизинговой фирмы
и на какие условия они согласны ради получения необходимого им
имущества.
Сущность "Заявка" обладает следующими атрибутами:
■ номер заявки (уникальный номер заявки; является первичным
ключом);
■ дата (дата заполнения);
■ аванс (аванс, который согласен выплатить контрагент);
■ срок (срок реализации);
■ статус (принята ли заявка к исполнению);
■ стоимость оборудования (стоимость запрашиваемого имущества);
■ общая сумма (сумма за предоставляемое имущество и услуги
лизингодателя);
■ тип (работник лизинговой компании сам вписывает к какому типу
относится контрагент, например, постоянный или первичный);
■ комментарий (пользователь системы может оставить какие-либо
заметки по конкретной заявке);
■ наименование имущества (какое именно имущество необходимо
клиенту);
■ номер сделки (номер сделки, которая заключается при
положительном рассмотрении заявки);
■ ИНН контрагента (идентификационный налоговый номер
юридического лица, невидимая пользователю информация, которая
82
необходима для связи с сущностью "Контрагент").
Сущность "Сделка". В этой сущности размещается информация о
сделках, вытекающих из принятых и одобренных заявок и на основании
которых заключаются договоры. Находящиеся здесь данные необходимы для
последующего подписания договоров.
Сущность "Сделка" обладает следующими атрибутами:
■ порядковый номер (номер, присваиваемый сделке при внесении ее в
систему; является первичным ключом);
■ наименование (название заключаемой сделки);
■ дата начала (дата, с которой сделка начинает осуществляться);
■ дата окончания (дата, на которую назначено завершение сделки);
■ тип сделки (сотрудники компании сами присваивают сделки
конкретный тип: лизинг, сублизинг, возвратный лизинг);
■ статус (здесь фиксируется на каком этапе находится исполнение
сделки);
■ общая сумма (сумма, на которую заключается сделка);
■ стоимость имущества (стоимость необходимого клиенту имущества);
■ примечание (вносятся необходимые по сделке комментарии);
■ номер заявки (номер заявки, в которой содержалось прошение
клиента на предоставление указанного в сделке имущества; невидимая
пользователю информация, необходимая для связи с сущностью "Заявка").
Сущность "Связующая таблица". Данная сущность используется как
связующая таблица между сущностями "Контрагент" и "Личность" и
избавляет от нежелательной связи многие ко многим. С помощью этих
данных можно в любой момент определить связь конкретного человека с
конкретной фирмой и наоборот. Поскольку в одном контрагенте может быть
задействовано более одного человека и одна личность может состоять в
различных контрагентах, данная сущность имеет очень большое значение в
системе. Сущность "Связующая таблица" обладает следующими атрибутами:
■ номер пенсионного свидетельства (невидимая пользователю
83