117
конечный результат. Для того чтобы итоговый продукт максимально
удовлетворял потребностям заказчика, а они, как мы выяснили, могут изменяться
в процессе их реализации, необходимо на протяжении всего проекта
поддерживать тесный и продуктивный диалог с потребителем конечного
продукта. К этому тезису мы будем постоянно возвращаться в процессе
изложения материала, поскольку он является ключевым. Исходя из
вышесказанного, очень важно, чтобы оба домена проекта: «область проблем» и
«область решения», изменялись синхронно и зависели друг от друга. Поэтому, с
самого начала в проекте, неплохо иметь «диспут площадку» с информацией,
доступной для понимания всех участников. Площадка должна выступать как бы
«витриной» проекта и может быть, как виртуальной (например: WEB портал), так
и реальной (например: комната со стендом), размещающей ключевую
информацию о содержании, текущем состоянии и ближайших планах
проекта. Постоянное взаимное общение представителей каждой из точек зрения,
помогает эффективно бороться с проблемами неверных предположений
сторонами:
Проблема описанная заказчиком, может оказаться не той, в решении
которой у него есть реальная нужда.
Решение, описанное разработчиками, может отличаться от того, что
они а самом деле создают.
На рисунке 23 изображена модель взаимодействия команды проекта в
процессе формирования и использования контента проекта («области проблем» и
«области решений»).
На этапе подготовки ландшафта проекта, начинают формировать списки
заинтересованных сторон. Важно не упустить никого, из тех — кого как-то
касается процесс и(или) результат создания нового продукта. Заинтересованными
лицами проекта могут быть не только будущие пользователи системы и команда
проекта, но и различные должностные лица заказчика, инвесторы, эксперты по
эргономики, чиновники стандартизирующих и регулирующих органов и т.п. Этот
список может пополняться и уточняться в течении всего проекта, по мере
формирования и уточнения требований.
118
Рисунок 23 Модель процесса взаимодействия команды проекта
Оформлять список удобно в виде таблиц (таблица 8,9,10), в которых
помимо наименования заинтересованного лица, необходимо уточнить его цели,
классифицировать его компетенцию и роль в проекте. Ниже приведен пример
использования таблиц, для формирования списка Заинтересованных лиц проекта:
Ландшафт – «система способов репрезентации, структурирования и
символизирования окружающей среды проекта»
Таблица 8
Ответственные за анализ требований
Роль
ФИО ответственного
лица
Заинтересованная сторона
Руководитель RAG
Плужникова Е.В.
Руководитель проекта,
разработчик
119
Таблица 9
Роли и обязанности процесса управления требованиями
Роль/Группа
Перечень лиц
Основные обязанности
Бизнес -
Аналитик
Вострецова К.И.
Отвечает за моделирование бизнес-
прецедентов, определяет рамки, в
которых производится бизнес-
моделирование
Системный –
аналитик
Березов М.К.
Отвечает за внесение запросов на
изменения в базу данных запросов на
изменения от имени пользователей и
заказчиков. Разрабатывает дизайн,
создает прототип интерфейса
пользователя.
Аналитическая
группа
Разработка и поддержка процесса
управления требованиями в проекте
Группа
тестирования
Верификация и валидация продукта
Группа
анализа
требований
Анализ и внутреннее утверждение
требований, валидация требований
Таблица 10
Перечень лиц, которые являются источниками информации для проекта
ФИО
Организация
Должность
Заинтересованная
сторона
Ромашков П.К
Организация 1
Технолог
Заказчик
Болотникова М.Е.
Организация 1
Бухгалтер
Заказчик
Плужникова Е.В.
Руководитель
проекта
Исполнитель
Еще один целесообразный шаг для формирования ландшафта проекта, это
публикация на его «витрине» — словаря (глоссария), который послужит команде
инструментом достижения консенсуса в толковании объектов и явлений
предметной области. Это позволит заказчикам и разработчикам общаться на
диспутах на «одном языке». Опыт показывает, что использование глоссария
экономит массу времени, а главное нервов, так как часто заказчики и исполнители
тратят их на споры «каждый о своем», возникающие только из-за разницы в
понимании одного и того же термина. Например, использованное в заголовке
слово «Ландшафт» может трактоваться, в зависимости от области применения,
120
очень по-разному. Но в контексте нашего проекта добавим в Глоссарий такое
определение:
Глоссарий может пополняться в течение всего жизненного цикла проекта,
поэтому и мы, по ходу развития нашего проекта в публикации, будем определять
термины, которые могут вызвать различное толкование.
Как видно из этой главы, в ней делается особый упор, на активное
взаимодействие аналитика со всеми заинтересованными лицами проекта, а
точнее, на постоянное эмоциональное вовлечение их в разработку требований.
1. Постоянно нужно напоминать, что аналитик создает требования «не
искусства ради», а как промежуточный продукт, используемый в цепочке
разработки Программного Обеспечения. Привлекать к его формированию как
можно большее количество заинтересованных лиц. Даже зная ответы, нужно
задавать вопросы.
2. Задавать вопросы так, чтобы они могли дать на них нужный вам ответ,
при этом люди будут воспринимать это решение как свое. Как видно из рисунка
3.1 по одну сторону требований у нас
3. Заказчик, по другую команда реализации целевого продукта. Поэтому,
когда говорится о вовлечении заинтересованных лиц, имеется ввиду не только
Заказчика, но и архитекторов, проектных менеджеров, Тимлидов.
2.2.3 Средства коллективной работы над проектом автоматизации
С точки зрения коллективной работы, каждый проект-это набор каталогов
и файлов различных типов, которые:
а) на компьютерах участников проекта разработки в выбранном ими месте
(некоторые групповые программы, однако, не требуют локального хранения
файлов, не находящихся на редактировании от разработчика);
Б) В базе данных соответствующей программы сливаются версии (обычно
на сервере).
Следует отметить, что доступ к файлам баз данных осуществляется с
помощью инструментов, доступных в файловой системе и сети с помощью
программного обеспечения-сервера баз данных, многие системы обеспечивают
121
обе эти возможности. Работа с общей базой данных подразумевает постоянно
работающий сервер баз данных, а также удовлетворительную скорость сетевого
подключения с ним к компьютеру разработки.
Если скорость сети плохая (или она обычно не всегда работает), и нет
никакого способа, чтобы содержать постоянно работающий сервер, проект базы
данных создается на каждом компьютере разработчика. Совместной работы
поддерживает репозитории личности путем отправки сообщения об изменениях в
репозитории Контента с одного пользователя на всех его коллег. Плата за
использование такого подхода представляет собой неполный контент,
соответствующий проектной базе данных на компьютерах программистов,но это
обычно не мешает эффективной разработке. Более того, с увеличением числа
разработчиков объем данных, которыми они должны делиться, резко
увеличивается. Для более крупной команды программистов было бы
экономически целесообразно выделить сервер.
Для начала работы с проектором необходимо создать его базу данных-это
делает его администратор проекта. Кроме того, все участники проекта получают
с помощью инструментов из вашей системы контроля версий с сервера
необходимые файлы на локальном диске, по мере необходимости – как правило,
они могут получить любую из предыдущих версий, и описание этих изменений.
Если программа groupware не основана на использовании Центральной базы
данных на сервере, то исходный набор файлов разработчиков проекта получает от
администратора, а затем работает с локальной базой данных.
В процессе работы программист должен регулярно проверять (TFR), какие
изменения были внесены в исходный код его коллег. Для внесения изменений в
файлы необходимо отправить их обратно на сервер (или другим разработчикам
для обновления локальных баз данных). Схема СКР показана на рис. 24 .
Инструмент отчетности
Чтобы проиллюстрировать методы работы RCDS в статье класса ниже
приведен сравнительный обзор программного обеспечения, в котором наиболее
полно отражены детали работы данного типа. Будет подробно описано.
1) архитектура сервера InterBase реализует несколько поколений записей
(Mga-Multi-Generational Architecture). MGA предоставляет уникальные
122
возможности использования версий, что приводит к высокой степени
доступности данных для пользователей, работающих с транзакциями, и
пользователей, использующих приложение поддержки принятия решений..
2) Майкрософт (ВСС) 6.0. Программа основана на использовании
графического интерфейса, хотя некоторые действия пользователя могут
выполняться из командной строки. VSS 6.0 работает только под Windows 95 / NT,
хотя предыдущая (до приобретения прав на разработку этого продукта
Корпорацией Майкрософт) версия хорошо работала под MacOS и UNIX. ВСС
является коммерческим продуктом (msdn.microsoft.com/ssafe). Около $ 550 за
копию.
3) Code CO-OP (COOP) (кооператив) – система совместной разработки
одноранговой Тип, ориентированный на обмен данными с использованием
электронной почты. Довольно новая программа, которая была основана
исключительно на использовании графического интерфейса. $ 150 за номер
(www.relisoft.com).
InterBase-это основанная на использовании централизованной базы данных
проекта, сервер базы данных SQL, СУБД InterBase от Borland сочетает в себе
простоту использования, низкую стоимость обслуживания и питания
корпоративных систем. Борланд гарантирует, что InterBase сочетает в себе
мощный, проверенный архитектуры с современными технологиями,
необходимыми для успешного применения систем.
UNIX-версия, которая, как и большинство других фондов для
коллективного развития (также появилась недавно, как Code Co-op), находится на
VSS, и CVS. Их интерфейс командной строки такой же, как и для версии Windows,
но графический интерфейс отсутствует. Однако из соображений безопасности я
рекомендую разместить базу данных проекта на сервере UNIX.
Критерии сравнения обсуждаемых инструментов
Несмотря на общую концепцию, лежащую в основе функционирования
всех СКР, различия в деталях реализации процесса коллективного развития с
использованием этих средств могут существенно повлиять на легкость и
эффективность использования этих средств.
123
Рисунок 24 Общая схема работы с СКР, основанной на использовании
централизованной БД
Наиболее важными являются следующие параметры:
- способы хранения версий файлов в базе данных;
- способы доставки новых версий файлов другим программистам;
- способы обработки изменений в один и тот же текстовый файл
одновременно различными разработчиками.
- способы работы с другими типами файлов;
- доступность и удобство визуальной работы с файлами и группами файлов
проекта, включая просмотр, редактирование и объединение конфликтующих
изменений;
- доступность и реализация использования командной строки для тех же
целей;
- интеграция с другим программным обеспечением для разработчиков
текстовых редакторов, расширяемость;
контроль доступа к файлам проекта;
- способов и средств распространения данных
(GNU, freeware, shareware или через торговую сеть) и во многих случаях очень
важно.
124
Практически все средства коллективной работы хранят файлы в базе
данных в виде последовательности изменений – от новой версии файла к старой,
- а не каждую версию каждого файла целиком. Это значительно уменьшает размер
базы данных.
Если один из этапов разработки проекта удаляется из файла,
соответствующего этому файлу, запись в базе данных не удаляется (т. е. просто
файл помечается как удаленный от этой версии). При нормальных
обстоятельствах необходимость использования таких функциональных
«возможностей» отсутствует.
2.3 Информационное обеспечение задачи
2.3.1 Информационная модель и её описание
В данном пункте приведён условный пример части информационной
модели задачи по регистрации новой заявки (рисунок 25).
Рисунок 25 - Информационная модель
Область 1 отображает процесс конфигурирования ИС в части ввода
125
пользователей ИС, которые необходимы в рамках задачи для того, чтобы можно
было зафиксировать информацию о действиях пользователя по регистрации
клиентов и заявок. Форма «Сотрудники» предполагает выполнение следующих
видов операций:
редактирование таблицы «сотрудник»;
редактирование «справочника отдел»
редактирование «бригад».
При этом, в ИС предполагается, что каждый пользователь может иметь
строго одну роль, что отображено входящей связью «Т Сотрудник».
Область 2 отображает то, что из базы ИС в рамках моделируемой задачи
используются три справочника и две таблицы. (Под справочником мы понимаем
обычную таблицу, которая содержит условно-постоянную информацию).
Область 3 отображает собственно процесс регистрации заявки.
Предполагается, что регистрация будет состоять из следующих этапов:
сначала делается запись (либо производится обновление записи) в
справочнике клиентов. Под клиентом понимается ФИО и какие-либо его данные
(например, паспортные данные).
затем делается запись, отражающая факт регистрации заявки. В рамках
задачи предполагается два варианта его совершения:
например, установка какого-либо оборудования Спр «Услуги»;
подключение «Тарифа».
в любом случае заявка может производится только менеджерами, что
отражается связью со справочником «Спр Сотрудники».
Область 4 отображает то, что моделируема ИС предоставляет на выходе:
клиент получает результатный документ, содержащий параметры
составленной заявки и являющийся его подтверждением.
Из справочника «Спр «Клиенты» используем текстовое
наименование клиента;
Из справочника «Спр «Сотрудник» получаем текстовое
наименование оператора-получателя
Из таблицы «Т «Усуги»« остальные реквизиты платежа.
клиент (в случае, если у него есть подключённые тарифы) может
126
получить выписку по нему:
«Спр «Бригда»« - определяет бригаду которая будет осуществлять
подключение услуги и тарифа
«Т «Заявка»« - собственно операции
2.3.2. Характеристика нормативно-справочной, входной и
оперативной информации
Входной информацией для таблицы «Клиент», является документ
удостоверяющий личность. Справочная входная информация являются
следующие таблицы: «Регион» - для определения действия выбранного тарифа в
рамках региона проживания клиента, «Тариф» - предполагает выбор более
оптимального клиенту тарифа, а также «Услуги» - определяет исходя из тарифа,
например, необходимого оборудования. Пример экранной формы представлен на
рисунке 26.
В приложении присутствуют справочники, это «Тарифы», «Услуги»,
«Регион» (Рисунок 26)
Рисунок 26 – Справочники
Справочник «Тариф», отображает всю необходимую информацию о