Разработка заказного ПО для торговца пластиковыми карточками

Разработка заказного ПО для торговца пластиковыми карточками

Исследовательский проект

Участники:

Galogen

Gevorg

Greesha

G3

Star Teem

Имя	Дата	Причина изменения	Версия
Galogen	14.12.07	Предложено	V0

Содержание

1. Введение. 3

1.1. Цель проекта. 3

1.2. Границы проекта. 3

1.3. Источники данных. 3

2. Постановка задачи. 3

2.1. Исходные данные. 3

2.2. Проблематика. 3

2.3. Роли у Заказчика. 3

2.4. Предъявленные требования. 4

3. Ход проекта. 5

3.1. Роли у Разработчика. 5

3.2. Предполагаемый инструментарий. 5

3.3. Глоссарий. 5

3.3.1. Скретч-карта. 5

3.3.2. БАР-код. 6

3.3.3. Код-EAN.. 6

3.4. Некоторые обсуждения предъявленных требований. 6

3.5. Предложения по процессу. 10

1.  Введение

1.1.  Цель проекта

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

1.2.  Границы проекта

Проект выполняется как учебный

1.3.  Источники данных

Информация от Gevorg и обсуждения на форуме

2.  Постановка задачи

2.1.  Исходные данные

Крупнооптовая закупка скрэтч-карт от крупного провайдера услуг в Столице и мелкооптовая ПЕРЕпродажа мелким реализаторам карточек из провинциальных городов.

Финансовые потоки между Провайдером и Фирмой просты и прозрачны, уже автоматизированы в бухгалтерском ПО.

Между Фирмой и реализаторами существуют 2 вида денежных потоков:

Ü  БНР(безналичный расчет), тоже автоматизированный в бухгалтерском ПО и

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

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

2.2.  Проблематика

Управленческий учёт отсутствует, сведение отчёта по какому-либо из Реализаторов всегда проблема, решение которой не обходится без скандала.

2.3.  Роли у Заказчика

Ü  ТОП. Хозяин бизнеса, Раздражителен, скандален, даже временами хамлив. Скрывает особенности своих бизнес-процессов, поскольку имеет с ними ряд серъёзных проблем. Реально - под видом разработки и внедрения заказного ПО хочет провести реинжиринг своего бизнеса.

Ü  Финансовый директор. имеет только громкое название. На самом деле, главная его обязанность - ездить по провинциальным городам и "трусить должников".

Ü  Бухгалтер. Добросовестно сводит баланс по безналичным расчётам и отбивается всеми способами от попыток нагрузить её учётом движения наличных средств и карточек. Разрабатываемую систему рассматривает как инструмент агрессии в свою сторону.

Ü  Менеджеры. По совместительству - кладовщики-учётчики карт и налички. Ведут реальный учёт вручную, издёрганы скандалами при сведении отчётов по должникам. Ждут-не-дождутся наведения порядка и автоматизации в своей работе.

Ü  Финансовый и бизнес-аналитик. Появляется намного позже. Занимается построением полноценного управленческого учёта на основе уже реализованной в нашем ПО функциональности и своих дополнительных хотелок. Одна из них - возможность принимать от Провайдера и учитывать номера использованных скретч-карт. Счастливая находка для эффективного обнаружения фактов задержки Реализаторами средств от уже проданных карт.

2.4.  Предъявленные требования

Требование №1.  Система должна обеспечивать учёт скрэтч-карт.

Требование №2.  Система должна поддерживать интеграцию с Клиент-Банком.

Требование №3.  Необходимо использование БАР-кодов для номеров скретч-карт.

Требование №4.  Необходимо использование БАР-кодов для секретных кодов скретч-карт.

Требование №5.  Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.

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

Требование №7.  Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.

Требование №8.  Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.

Требование №9.  Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

Требование №10.  Система должна обеспечивать отчётность о текущем состоянии счёта компании.

Требование №11.  Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.

Требование №12.  Необходима интеграция с внешними системами считывания бар-кодов.

Требование №13.  Необходима интеграция с переносной системой считывания бар-кодов компании Х.

Требование №14.  Система должна обеспечивать отчётность об истории прихода денег на счёт компании.

Требование №15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

3.  Ход проекта

3.1.  Роли у Разработчика

Ü  - Менеджер требований(RM). В полном смысле должен быть "держателем" самих требований и работы с ними. Пребывает в полной уверенности, что 80% работы с требованиями не несут в себе проблем касательно их сути, Требования либо уже понятны, либо работа с ними требует только поверхностного понимания сути при большой важности глубокого понимания контекста в проекте. Из оставшихся 20% надеется часть спихнуть на энергичного и начитанного (а главное - низкооплачиваемого) помощника, а что останется из уж совсем трудного - пригласит (на сэкономленные средства) стороннего эксперта-аналитика. Ленивый прагматик до мозка костей.

Ü  - Младший менеджер требований(jRM). Имеет большой теоретический багаж, опыт работы c CASE-средствами, энергичен и работоспособен. При недостатке опыта в работе с требованиями и отсутствии "груза ответственности за конечный результат", активно и добросовестно берётся за любую посильную черновую работу.

Ü  - Сеньёр эксперт по требованиям(SRX). Прекрасно знает предметную область вообще, на высоком уровне понимает и формулирует требования по сути. Требует от остальных такого же высокого уровня понимания, если не находит - тут же берётся дотягивать. Находится вне организационного контекста нашего (стендового) проекта, многие трудности и провалы не то что не хочет воспринимать, но даже и не догадывается об их существовании. Имеет опыт по своим прошлым и текущим проектам, которым охотно делится (за соответствующую немалую плату). За конечный результат проекта (стендового) не отвечает вообще, отвечает за высокий профессионализм и точность своих консультаций по выделенным вопросам.

3.2.  Предполагаемый инструментарий

RaQuest

Enterprise Architect

MS Word

MS Excel

Forum http://www. *****/forum/

3.3.  Глоссарий

3.3.1.  Скретч-карта

Скретч-карта (scratch card) - карта (с кодом или кодовым словом) оплаты (сотовой/фиксированной/IP-телефонии и др. типов) связи, на которых секретный PIN-код хранится под слоем стираемого вещества (на подобие лотерейных билетов).

скретч-карта - это карточка с секретным кодом, скрытым под защитным слоем. Клиент приобретает эту карту, стирает защитный слой и каким-то образом использует секретный код для доступа к какой-либо услуге.

3.3.2.  БАР-код

Штрихкод (БАР-код)— это последовательность черных и белых полос, представляющая некоторую информацию в виде, удобном для считывания техническими средствами.

3.3.3.  Код-EAN

Код EAN-13 с точки зрения кодировки товара условно можно разделить на 5 зон:

-  Префикс национальной организации GS1(3 цифры);

-  Регистрационный номер производителя товара(4-6 цифр);

-  Код товара (3-5 цифр);

-  Контрольное число (1 цифра);

-  Дополнительное поле (необязательное штрихкодовое поле, иногда там ставится знак «>», «индикатор свободной зоны»).

3.4.  Некоторые обсуждения предъявленных требований

Материалы с форума:

http://www. *****/forum/index. php? topic=487.msg5578#msg5578

Greesha

Вопрос: что такое "регистрация"? Ещё вопрос: что такое "учёт"? Предполагается ли учёт статуса карт - "загружена"/"продана"/"активирована"/... Самый Главный Вопрос: "За что ему деньги плОтят?" Как связан cash flow со статусами карт? (Всю последнюю неделю стоим на ушах, из-за того что заказчик поменял схему расчётов с провайдером, применив способ, изначально никем не предусмотренный, огрёб из-за этого серьёзные финансовые претензии и попытался свалить их на нас). Клиент-Банк - это вообще отдельная тема со своими требованиями, которые по сложности могут превысить основной функционал. В общем, начинать надо, как написано в букварях, с составления глоссария и выявления бизнес-схем, используемых заказчиком.

http://www. *****/forum/index. php? topic=487.msg5580#msg5580

Gevorg

Цитата: Galogen от Ноября 13, 2007, 05:15:34 pm Т. е. мы имеем некий массив требований в каком-то виде. интересно в каком? И уже управляем им, ничего, не прибавляя, но возможно убавляя. И как это процесс представляется? Чем мы в данном контексте управляем? Версией? Статусом? Текстом требования? Появление новых требований в этой схеме тоже возможно. Вот приблизительный возможный сценарий: Для начала роли персон андер дискашшинз: - Менджер требований (RM): центральная фигура, в фокусе нашего внимания, - Дизайнер требований (RD): некий Умный и Всезнающий Дядя (УВД), способный закрыть любую дыру в проблемах с требованиями. Как работает - неизвестно, Что делает - не понятно, но проблему решает любую. - Представитель Заказчика (CR): некая совсем уж обобщённая роль для любых действий, предполагаемых от Заказчика. 1. (CR): Звонит на фирму, просит выслушать его очередную хотелку. 2. (RM): - Принимает звонок, - регистрирует новое требование во внутренней системе управления Требованиями (СУТ). - Признаётся, что ничего не понимает в словах (CR)-а, - договаривается с ним и - регистрирует в СУТ задачу для (RD): провести интервью и извлечь требование: "Поди туда, ЗНАЮ, куда, - возьми то, НЕ_ЗНАЮ, что. 3. (RD): - Проводит интервью, - уж неизвестно как изощряется, но - приносит формулировку нового требования, - его классификацию и связи с другими. 4. (RM): - регистрирует выполнение задачи (RD)-мом, - Регистрирует принесённые результаты в СУТ, - обнаруживает, что (RD) забыл определить список заинтересованных лиц, - ПЫТАЕТ оного по данному вопросу. 5. (RD): - отделывается выбором заинтересованных лиц из списка уже имеющихся в СУТ, - отбивается, чтобы не решать задачу формулировки их интересов по данному требованию. 6. (RM): - регистрирует заинтересованных лиц, фиксирует напоминалку, что список заинтересованных лиц не проверен на полноту, - регистрирует напоминалку, что список интересов по требованию не определён,

http://www. *****/forum/index. php? topic=487.msg5587#msg5587
Gevorg	Цитата: greesha от Ноября 13, 2007, 05:26:50 pm В общем, начинать надо, как написано в букварях, с составления глоссария и выявления бизнес-схем, используемых заказчиком. Ага, я тоже раньше так думал J На самом деле - требования рождаются ЗАДОЛГО до того, как появляется возможность подружить их в цельной картине глоссария и бизнес-процессов! И первое дело – не помирить этот зоопарк, а распихать его насельников по соответствующим клеткам и террариумам, чтоб служащим не страшно (и вообще – возможно) было свою работу исполнять и звери между собой потасовку не учинили.
http://www. *****/forum/index. php? topic=487.msg5607#msg5607
Gevorg	Цитата: Galogen от Ноября 13, 2007, 08:17:35 pm Неясное требование. Что же должна делать система? Отлавливать карты с разрешенным диапазоном кодов, но какие-то бракованные? :-) ОК, я, типа, ТОП от Заказчика, Вы - обескураженный Аналитик: ну чё непАнатнАга? : сидит девка, заносит в систему приход новой пачки карт: клац штрих-сканнером спереди - номер первой карточки, клац сззади - номер последней, пАсьмАтрела - на пачке написана бракованная карточка, которую выкинули, вбила её номер пальцами. Всё: все карточки из пачки шоб в системе были, а бракованной - шоб не было.
http://www. *****/forum/index. php? topic=487.msg5614#msg5614
Gevorg	Вопрос: что такое "регистрация"? Эдуард, берите в коллекцию! Возникла задача менеджмента требований: - уточнить термин «регистрация» - внести необходимые правки в описание требований: 6,8,9, содержащих эти требования, возможно,- - провести ревизию описаний остальных требований на предмет использования синонимов. Решением этих подзадач может быть: - добавлен термин Регистрация в глоссарий - все соответствующие слова с корнем «Регистр» снабжены кликабельной ссылкой на строку глоссария, - внесено примечание, что прорверка на наличие синонимов не выполнялась (нет эксперта). Цитата: greesha от Ноября 13, 2007, 05:26:50 pm Ещё вопрос: что такое «учёт»? Предполагается ли учёт статуса карт – «загружена»/»продана»/»активирована»/… Эдуард, ещё находка: Появилось новое требование. По нему задача: зарегистрить в СУТ. Результатом должно быть что-то в роде: Требование №: 15. Описание: В учёте отслеживать статус карт: «загружена»/»продана»/»активирована»/… Автор: greesha (роль в проекте: сторонний консультант), Статус: предложено, Связь: подтребование(составная часть) от тр1. Важность для Заказчика: 100% Ответственность: Galogen (роль в проекте: регистратор изменений в требованиях)
http://www. *****/forum/index. php? topic=487.msg5615#msg5615
Greesha	Как сторонний консультант, прошу для начала разъяснить бизнес-логику. Прежде всего прошу ответа на такие вопросы. 1. Чем занимается Компания-закзачик: - производством скретч-карт - предоставлением услуг, оплачиваемых с помощью скретч-карт - распространением скретч-карт как основным бизнесом - перепродажей скретч-карт в дополнение к основному бизнесу - утилизаций использованных скретч-карт - распространением ворованных и поддельных карт - другое 2. Как "поступление средств" на счёт компании связано с учётом карт (ответ на предыдущий вопрос может содержать ответ на этот вопрос. Но может и не содержать, особенно учитывая загадочное требование "на основании телефонного звонка от финансового директора"). 3. Для чего используются скретч-карты (оплата мобильной связи, оплата междугородной связи, доступ в интернет, web-деньги, другое...) Предполагается обработка карт только одного типа или разных типов? 4. Существуют ли разные номиналы скретч-карт и зависит ли обработка от номиналов? Какие вообще атрибуты есть у карт, кроме серийного номер, и как они влияют на обработку (предельная дата активации, срок действия, ссылки на других провайдеров или лоялти-программы и т. п.)? 5. Предполагаемый объём базы данных - сколько ориентировочно карт может быть учтено и в течение какого периода?
http://www. *****/forum/index. php? topic=487.msg5617#msg5617
Galogen	Да - а что такое срэтч-карта (простите за наивность)
http://www. *****/forum/index. php? topic=487.msg5650#msg5650
Galogen	Вопросы по требованиям: 003 Необходимо использование БАР-кодов для номеров скретч-карт 1. Что такое БАР-код 004 Необходимо использование БАР-кодов для секретных кодов скретч-карт 2. Каким образом считывается секретный код, т. е. как определяется считывание именно секретного кода, а не номера карточки 006 Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров 013 Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат 3. в пояснении было написано, что регистратор вводит вручную номер бракованной карты - неясность с БАР-кодом и использованием оборудования для его ввода 002 Система должна поддерживать интеграцию с Клиент-Банком 4. Да все-таки, что такое Клиент-Банк, название реального банка с которым сотрудничает корпорация или один из многих банков-клиентом 008 Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка 5. Предлагется переформулировка - Система должна регистрировать приход средств на счёт компании на основании информации из банка 6. Уточнить что такое информация из банка (квитанция, переданная каким-либо образом, автоподтверждение ИС банка) 009 Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора 7. Чем отличается регистрация по звонку финдиректора, когда она происходит, чем отличается от требования 008. Вопрос коррелирует и к требованию 015 8. Переформулировка: Система должна регистрировать приход средств на счёт компании на основании телефонного звонка финансового директора 9. Чем отличаются кроме формулировки требования 005 и 011
http://www. *****/forum/index. php? topic=487.msg5659#msg5659
Gevorg	Gevorg(в роли ПМ проекта по сбору метод-материала для студенотов) to Galogen(в роли учредителя проекта): вот ещё пример студентам: ошибка в менеджменте требований: RM(Gevorg) НЕ замечает общую КОНЦЕПТУАЛЬНУЮ проблему, пытается подменить её частной задачей трассировки и решить её с помощью РаКвест. А проблема в том, что RM(Gevorg) до сих пор ещё не вооружён КОНЦЕПТУАЛЬНОЙ_МОДЕЛЬЮ и регламентом процесса по управлению требованиями. Он не просто не в состоянии "разложить по полочкам" очень быстро накопившийся материал, у него нет САМИХ полочек, у него даже нет ещё отчётливого понимания, какими они должны быть. Отсюда и робкий вопрос подчинённому вместо уверенного отдавания распоряжения, отсюда и судорожные попытки "закрыть дыру" своими средствами. Правильные действия в этом случае - идти "наверх", не к подчинённому, а руководству: /ProcessRequirementBoss(Galogen): RM(Gevorg) to / Проект разработки ПО уже давно стартонул, работы по сбору и анализу требований уже ведутся полным ходом, самИх требований ещё совсем мало, а по ним уже накопилась куча материала, ещё немного - и работа над сбором и анализом требований превратится в хаотический и безрезультатный процесс. В работе над требованиями полный произвол и неопределённость: - кто за что отвечает, - кто что и как делает, - что и в каком виде подаётся в качестве исходного материала, что является результатом и как его оформлять на каждом из шагов? Срочно нужно всё упорядочивать: - рисовать диаграммы моделей процесса управления требованиями в нашем случае, - писать по ним инструкции и регламент и - ставить этот процесс на рельсы. Иначе - утонем в, на самом деле, умных дебатах о "физической сути" каждого из требований.

3.5.  Предложения по процессу

В первую очередь нужно описать свою концептуальную наработку:

Разнесение понятий элемента модели и требования на каждом из уровней.

Поясню это по ходу изложения своей классификации наших требований по уровням.

Итак, требование

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

Какую проблему должно закрывать его удовлетворение?

Ü  Карт много, менеджеры не справляются с учётом.

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

Ü  Текстовое описание бизнеса у Заказчика (не случайно его отсутствие так возмущало Greesh-у).

Какие элементы этой модели связываем с Требованием1 вообще и с его Проблемой в частности?

Ü  Строчки из описания бизнеса:

o  Ведётся учёт скрэтч-карт.

o  На д. м. оборот: 10тыс карт в месяц, планируется – 200тыс.(привязываем к проблеме)

o  Скрэтч-карта имеет номер и БАР-код этого номера.

Какой набор решений предлагается для удовлетворения требования?

Ü  Строчки из документа, описывающего модель взаимодействия пользователей с системой:

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

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

·  пользователь может вводить номера изъятых из диапазона карточек,

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

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

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

Например – квадратик, изображающий карточку с атрибутом “БАР-код номера”. На уровне модели взаимодействия пользователя с системой - это могут быть строчки сценария из ВИ или строки примитивного списка тезисов.

И ещё один момент. До сих пор я старался использовать только сведения, собранные в тексте самих требований, без учёта общей картины бизнеса, изложенной позже по запросу Greesh-ы и других участников форума.

Это ни в коем случае не в пику Greesh-е, а в прояснение сути кажущегося противостояния наших позиций.

Ü  С одной стороны, пробелы и противоречия в представлениях о бизнесе Заказчика - неизбежное явление на всех стадиях разработки.

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

И самое страшное не то, что Разработчику приходится это делать за свой счёт, а то, что этим он вторгается в “чужую парафию”, становится эдаким агрессором-обличителем по отношению к Заказчику, который и от себя-то скрывает дыры в своём бизнесе, а тем более – будет всячески саботировать обнародование их в документах от Разработчика.

Ü  с другой стороны, - требования не могут “болтаться” в воздухе, они обязательно должны опираться на модели соответствующих уровней (уровень проблемы и уровень решений по ней). На начальных этапах сбора и анализа требований не следует ожидать, что такие модели будут цельными, согласованными, полными, - приходится довольствоваться тем, что объективно есть на текущий момент и выжимать из него всё, что можно.

3.6.  Новые требования

Требование №16.  Описание: В учёте отслеживать статус карт: «загружена»/»продана»/»активирована»/…

Автор: greesha (роль в проекте: сторонний консультант),

Статус: предложено,

Связь: подтребование(составная часть) от требования №1.

Важность для Заказчика: 100%

Ответственность: Galogen (роль в проекте: регистратор изменений в требованиях)