Особенности работы с требованиями при доработке продукта для заказчика
•Download as PPTX, PDF•
2 likes•1,681 views
Доклад Андрея Колесникова на конференции Analyst Days-4, 17-18 апреля 2015 г., Минск www.analystdays.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Особенности работы с требованиями при доработке продукта для заказчика
Similar to Особенности работы с требованиями при доработке продукта для заказчика (20)
More from SQALab
More from SQALab (20)
Особенности работы с требованиями при доработке продукта для заказчика
- 1. Особенности работы с требованиями при доработке продукта для заказчика Андрей Колесников Иншуранс Солюшенс akalesnikau@eisgroup.com
- 2. Когда тема актуальна • Укомпанииестьпродукт • Нужны разные решения для заказчиков в разных странах
- 3. Категории продуктов • Рассчитанныенамассовогопотребителя • Нишевые/отраслевые, ориентированные на конкретную аудиторию или отрасль
- 4. Отраслевой продукт • Пониманиепредметнойобласти • Ориентация на глобальный рынок • Учет особенностей для отдельных стран и регионов
- 5. EIS Suite 3rd Party Interface Billing Interface Claims Interface Commission Interface Self-Service Portal Interface Reinsurance Interface Analytics Interface 3rd Party Mgmt Accounts & CRM Correspondence Management Sub-Ledger Reporting & Compliance Tasks & Decisions Document Generation Configuration & Scheduling Security Process & Task Mgmt Business Activity Monitoring Content Management Business Rules Common Services Data & Sys Integration Interaction Channels Operations Management Correspondence Personal Service Self-Service Mail Fax eMail Chat Phone Agent IVR SMS Web New Business Policy Servicing Claims Financials Claim Processing Business Processes & Core Functions New Business Rating Policy Servicing Adjudicaton & Settlement Claim Financials FNOL Claim Processing Product Management Under- Writing POLICYCORE CLAIMCORE Payment Processes Payment Management Invoice & Collection Bill Plan Management BILLINGCORE PRODUCT FACTORY Distribution ManagementSales and Customer Service DISTRIBUTIONCORE
- 6. Основные характеристики • Ориентированность на предметную область и её процессы • Реализация ядра системы и основных процессов или их частей в продукте • Настройки отдельных характеристик или структуры данных без изменения исходного кода • Быстрое конфигурирование или небольшая доработка для заказчика • Заказчик может оптимизировать процессы или приспособить под уже реализованные
- 7. Стратегия Созданиецелостногорешениясвозможностью настройкииконфигурации: • Поддержка общей «базовой» версии • Создание нескольких предварительно настроенных «региональных» версий • Настройка продукта для заказчика
- 8. Этапы готовности продукта • Разработка • Конфигурирование/настройка • Наполнение
- 9. Возможности настройки • Пользовательскийинтерфейс • Структураданных • Процессы/жизненныйциклобработкисущностей • Элементы поведения: действия пользователя/ события и реакция системы
- 10. Цикл настройки продукта ПродуктОсновные свойства продукта Структура продукта и блоки данных Пользовательские рабочие области Конфигурация правил для продукта и отдельных элементов Развертывание и управление
- 13. Базовый продукт до и после расширения • Ядросистемыи основныепроцессы • Платформадля администрирования • Модульнастройки продукта • Доменнаямодельи структураданных • Расширениеструктуры данных •Адаптацияпроцессовпод региональныетребования • Типоваяинтеграциясо смежнымисистемами
- 14. Продукт для заказчика • Окончательнаянастройка • Доработканекоторыхособенностей • Интеграциясоспецифическимисистемамизаказчика
- 15. Доработка EIS Suite Возможностинастройки Конфигурация •Доступна бизнес- пользователям •Предоставляет UI •Не требует изменения программного кода Параметризация •Изменения табличных параметров •Программирование бизнес логики Код •Язык программирования •Технически опытная аудитория Настройка расчета страховой премии Модуль настройки страховых продуктов Глубокие изменения Поверхностные изменения Настраиваемые модули Администрирование приложения
- 16. Доработки которых не избежать • Интеграция • Изменениепроцессовпотребованиямрегулятора • Изменениеструктурыданныхиинтерфейса
- 17. Работа с требованиями Этапсбораианализатребованийбазовойчасти продукта: • Начинаетсязадолгодостартапроектадлязаказчика • Осуществляетсяитерационно • Продолжаетсяскольугоднодолго • Нерешенныепроблемыпроявляютсянаэтапе работысзаказчиком
- 18. Задачи аналитика: несколько приближений • Определениепорядкавеличинобъемаработ(order ofmagnitude):обеспечиваетвысокоуровневуюоценку сконкретнымипредположениями • Определениерамокиобъемаработ(scopestudy): болееточнаяоценкадляполученияспискавсех изменений(delta) • Детальнаяоценкадельты(deltacapture): определениедеталейдлякаждогоизменения
- 19. Определение порядка величин объема работ • Получение начальной информации от заказчика • Проработка вопросов по определению порядка величин объема работ • Информирование заказчика о полученной оценке
- 20. Планирование программы проектов • Понимание полного масштаба работ • Определение приоритетов бизнеса • Идентификация логических сегментов и их зависимостей • Определение порядка выполнения работ • Определение длительности и этапов работ Se
- 21. Параллельная работа Конфигурация билинга Конфигурация страховых исков Настройка Конфигурация страховых полисов Конфигурация расчета страховой премии Разработка и реализация интерфейсов Создание документов Конвертация существующих данных Текущая структура и подход позволяют проведение параллельной работы по ряду доменов: Страховые полисы Билинг Интерфейсы Конвертация
- 22. Оценка объема работ • Запрос дополнительной детальной информации у заказчика • Проведение совместной оценки объема задач с заказчиком • Анализ результатов, точная оценка объема работ для заказчика • Определение дельты между существующей и требуемой функциональностью
- 23. Детальная оценка дельты • Организация семинаров по обсуждению и утверждению детальной реализации • Оценка результатов. Выбор критериев и модели оценки • Согласование и оценка результатов с заказчиком • Возможное изменение объема или требований по согласованию с заказчиком
- 24. Определение места реализации требований • Базовая версия – функциональность, которая полезна любому заказчику • Предварительно настроенная версия – функциональность, которая полезна группе клиентов целевого региона, страны, направления в отрасли • Остальное – решение, создаваемое для заказчика
- 25. База знаний Накопление и использование уже наработанных и проверенных моделей, шаблонов и инструкций : • Быстрая и качественная оценка • Согласованный подход на всех проектах • Внедрение лучших практик для активностей
- 27. Зависимости и влияние • Процесс бизнес-анализа при создании базового продукта • Процесс бизнес-анализа при создании предварительно настроенных версий • Изменения базовой и предварительно настроенных версий • Использование единого подхода и единой системы управления требованиями
- 29. Что нужно для процесса создания продукта ? • Хорошо построенный процесс анализа и управления требованиями • Процесс поддержки требований для повторного использования • Распределенная реализация отдельных модулей и функций • Накопленная база знаний
- 30. Спасибо за внимание Андрей Колесников Иншуранс Солюшенс akalesnikau@eisgroup.com
Editor's Notes
- Кто я такой О чем мы сегодня поговорим об особенностях работы в компании, когда вы не просто разрабатываете продукт, а еще и пытаетесь дорабатывать его в для конкретных заказчиков
- 2м Применимость доклада: (из тезисов на слайде) Цель: Ождания – Ральность, если использовать стандартный подход Глоссарий ? продукт/система/решение Модуль/функциональный блок/функция Всегда, когда разрабатывается под заказчика - это тоже самое, что шить эксклюзивный костюм. Позволить себе эксклюзивный костюм могут очень немногие. На Западе конкуренция позволяет создавать нишевые решения - это эксклюзивные решения, а все остальные носят то, что сшито или слеплено на фабрике. Так вот аутсорсинг – это то, что заказывается на Западе у нас, у индусов, в Китае, или создание новых продуктов, или эксклюзивные решения. Нишевые игроки (Niche Players) предлагают жизнеспособные решения, которые отвечают основным требованиям покупателей. Нишевые игроки могут быть ориентированы на небольшие сегменты рынка и часто демонстрируют на них более высокую эффективность, чем лидеры аутсорсинга или универсальных решений. Покупатели отдают предпочтение вендорам этого типа, когда стабильность и фокусировка на нескольких важных функциях и особенностях программного продукта важнее, чем долгосрочные и грандиозные планы развития производителя. http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%9A%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82_Gartner
- 1м Начнем с того что определим, какие бывают продукты. Программные продукты можно классифицировать по различным признакам. Мы будем использовать признак классификации программных продуктов, указывающий на аудиторию, их использующую. раcчитанные на массового потребителя (игры, развлечения, социальные сети, мессенджеры и т.п.) нишевые продукты, ориентированных на конкретную целевую аудиторию и решающих конкретные потребности этой аудитории К нишевым продуктам относятся и отраслевые продукты: http://www.softwareandstartups.com/predprinimatelstvo/ocenka-perspektivnosti-nishevogo-rynka/ http://www.softwareandstartups.com/predprinimatelstvo/6-preimushestv-nishevogo-rinka/
- 2м30 Потребности и проблемы отрасли или аудитории можно выявить и создать под них продукт, который будет востребован. Но при этом важно понимать, что основой успеха при создании нишевого продукта является не один только маркетинг. Основой успеха в данном случае является четкое понимание предметной области продукта, а также понимание ЦА и ее потребностей. Необходимо быть специалистами в разработке, в маркетинге, нужно быть еще и специалистами в той области, для которой создается решение. При этом стратегически неверно делать конечный, рассчитанный на локального пользователя. Следует ориентироваться на глобальный рынок, а это накладывает определенные сложности — сохранение базовой версии и необходимость поддерживать и постоянно обновлять несколько региональных версий продукта. В то же время, практически ни одно из универсальных программных решений не способно подстроиться под требования компаний, поэтому основная задача - делать гибкие нишевые продукты, которые совмещают в себе необходимый функционал и возможность быстрого и качественного расширения или изменения продукта и его конфигурации. … оказывается неэффективной для систем, требующих глубокой индивидуальной адаптации под каждого заказчика …
- http://www.eisgroup.com/benefits/about-eis-suite.html http://isicad.ru/ru/articles.php?article_num=17432 САПР , PDM – есть разделение по отраслям, например автомобилестроение, судостроение, самолетостроение, оружейная отрасль, космос и CAD/CAM (Системы автоматизированного проектирования и производства) PDM (Управление данными по продукту) ENOVIA – dassault system EIS Suite http://www.nestor.minsk.by/sr/2007/03/sr70302.html Insurance (niche software solutions in insurance, нишевое программное обеспечение в страховании): http://www.trianz.com/industries/insurance.php http://oneshield.com/about/news http://www.guidewire.com/news-and-events/press-releases/2013/guideone-insurance-deploys-guidewire-solution-for-claims-management/ продукты, нацеленные на нишевые рынки процессов проектирования – подбора материалов – производства. Например, Agile Software сфокусировала усилия на необходимости быстрых изменений конструкции и получает большое количество заказов от крупных компаний, предлагая программное обеспечение, позволяющее связывать цепочки инженерно-технических работ и цепочки поставок. Далее следует Trend Micro, предлагающая программные продукты для систем безопасности, предвидевшая приход эры Интернета, давно вышедшая на рынок систем безопасности и ставшая главным поставщиком в Японии
- 2м Ориентированность на предметную область и процессы + ядро системы и основных процессов или их частей в продукте- Если мы говорим о страховании, то это поддержка создания и ведения страховых полисов, а также работа со страховыми исками, расчет страховой премии, проведение аудита премии. А также билинг и поддержка работы с клиентом (CRM) возможность для заказчика оптимизировать свои процессы или приспособить процессы под реализованные в системе (например, если какие-то действия могут быть изменены, добавлены или удалены без уменьшения ценности самого процесса) Value: Provides insurers with a comprehensive set of end-to-end solutions for legacy core system replacement ….faster Enables Customers and SIs to implement solution consistently and easily Consistent best practices - накапливать и применять лучшие практики Lowers implementation risk profile Enables rapid time to market using “DeltaBase” methodologies & artifacts Reliably manages changes in response to market demands
- 1м 45с При построении стратегии нужно помнить о том , что основные возможности как и проблемы ,преимущества и недостатки системы, предоставляемой заказчику и настраиваемой для него, закладываются еще на этапе проектирования решения. Особенности работы аналитика – разные на каждом из этапов: 1й этап – это чистая продуктовая разработка. Решается что будет делаться, каким способом и где (на 1м или 2м). Реализация ядра, основных функциональных модулей ,процессов и концептуальных решений и внутреннего межмодульного взаимодействия (потоки данных, событие-реакция, логическая модель данных), реализация возможности конфигурирования пользовательского интерфейса правил доступа и валидации по событиям, 2й этап – изучение потребностей и особенностей регионального рынка, требований регулятора, расширение базовых процессов и реализация специфических процессов или продуктов или функций (например генерации документов или их шаблонов), реализация типовых функции, используя те же подходы, что и в базовой версии. Страховой продукт – конфигурируемая сущность, на базе которой создаются экземпляры полисов, исков 3этап – изучение процесса работы конкретного заказчика ,сбор требований, определение возможности конфигурирования и необходимости доработки, изучение возможности адаптации продукта под процесс компании с минимальными доработками. В общем получается, что нужно не только пытаться применять весь арсенал бизнес-аналитических задач, но еще и иметь свою стратегию планирования бизнес анализа затрагивающую все фазы от начала создания продукта до доставки заказчику финальной версии.
- 1м 10с Процесс cсоздания продукта для каждой из версий должен включать как непосредственно разработку функционала, несущего ценность заказчику, так и механизм быстрой настройки отдельных блоков пользователем. Возможность конфигурирования отдельных функций и свойств должна предоставляться для обеспечения хорошей поддерживаемости системы и быстрой реакции на изменения в реальном процессе работы. Наиболее востребованным является расширенная возможность администрирования приложения и возможность конфигурирования рабочих сущностей (полис, иски, премия). При работе с требованиями аналитику нужно четко специфицировать подход к реализации требований исходя из необходимости в поддерживаемости отдельных модулей и процессов. При это нужно провести предварительное конфигурирование используя параметры по умолчанию. ТБД … Кроме этого продукт нужно наполнить хотя бы для возможности демонстрации: наполнить справочники реальной информацией, создать примеры реальных сущностей предметной настроить пользователей и их привилегии, сформировать рабочее пространства и интерфейс продукта, а также необходимые правила валидации для возможности ознакомления пользователями на реальном примере. ТБД…….
- 2м Пользовательский интерфейс Структура данных Процессы работы/жизненный цикл обработки сущностей Элементы поведения: действия пользователя/ события и реакция системы на них !!!! Сказать, что такое сущности !!!! Если с разработкой всё понятно , то требуемые возможности конфигурирования стоит рассмотреть отдельно. По-существу это тоже модификация ПО для его соответствия специфическим требованиям заказчика, но есть существенное отличие от разработки. Программное обеспечение можно назвать конфигурируемым, если его можно настроить через стандартные интерфейсы без программирования дополнительных функций и/или без изменения исходного кода программы. Если требования к системе нельзя удовлетворить без программирования или изменения исходного кода, то программное обеспечение принято называть адаптируемым. http://www.osp.ru/os/2008/06/5343884/ Возможности конфигурирования определяются рыночным спросом— если спрос на определенную возможность продукта достаточно высок, производители будут такую возможность разрабатывать для своих решений, и она очень быстро получит распространение на рынке как «стандартная» функция; а если требование не пользуется массовым спросом, то соответствующие функции разрабатываются таким образом, чтобы их можно было поддерживать с помощью дополнительных изменений и настроек, что потребует от пользователя дополнительных расходов. Для настройки предлагаются следующие возможности: Подбор готовых модулей и компонентов. Этот способ предусматривает выбор одного или нескольких компонентов из набора модульных решений, каждое из которых реализует определенную функциональность так, чтобы сформировать общее решение, «наилучшим образом» отвечающее требованиям клиента. Настройка пользовательского интерфейса, прав доступа и бизнес-логики.Большинство корпоративных ITSM-решений включают в себя инструментальные средства конфигурации пользовательского интерфейса, права доступа и логики,— это позволяет достигнуть гибкости, необходимой для удовлетворения требований клиента без программирования скриптов, дополнительного кода и глубоких технических знаний. Такой подход предусматривает моделирование последовательности заданий и бизнес-логики, создание и изменение форм пользовательского интерфейса, поддержку прав доступа и «придание» продукту определенного внешнего вида. Модификация структуры метаданных. В этом случае структура готовой базы данных меняется таким образом, чтобы она лучше соответствовала требованиям, предъявляемым к данным в конкретной организации: добавление новых таблиц, изменение типов данных, установка атрибутов данных.
- Если говорить про процесс сбора требований, связанный с циклом настройки продукта, то нельзя не отметить, что здесь от аналитика требуются применение навыков и знаний в моделировании и прототипировании. Первым шагом на базе которого будут определяться остальные шаги, является выбор заказчиком свойств/компонент программного продукта. Затем для каждого компонента определяются с набором предоставляемых функциональных возможностей и структурой данных. После этого можно рассматривать пользовательские рабочие области и размещение на них блоков и элементов структуры данных, а так же других элементов, предоставляющих пользовательские возможности. Когда макет UI создан, то можно переходить к опеределению и конфигурированию условий, правил поведения, доступности и валидации как для отдельных элементов, так и для свойств продукта. стратегия-> набор возможностей -> структура -> компоновка -> поверхность (Джесси Джеймс Гарретт)
- Одной из самых ценных возможностей является внесение изменений «на лету» и применения на работающем приложении авторизованным пользователем. В решении EIS Suite такая возможность реализована с помощью так называемой «фабрики продуктов», которая позволяет менять свойства и логику настраиваемых сущностей, таких как Полис или Иск и их элементов. (на рисунке модуль и среда настройки продукта)
- Говоря о настройке продукта, также стоит упомянуть о возможности настройки процесса работы. Системой предоставляется возможность визуальной настройки таких процессов. BPM конструктор для настройки процессов
- Естественно, сама работа над продуктом для заказчика начинается еще задолго до заключения контракта и начала выявления требований. Продукт нужно максимально адаптировать к условиям, на котором работает группа потенциальных заказчиков. …. Материал на слайде …. - Расширение структуры данных - Адаптация процессов под региональные требования - Типовая интеграция со смежными системами согласно отраслевым стандартам страны или региона Есть отраслевые системы хранения и обмена информацией, если возможна типовая интеграция с ними, то она реализуется
- См слайд
- В продукте EIS Suite, который мы рассматриваем как пример, применяется несколько способов такого изменения (при доработке для заказчика): Изменение программного кода Параметризация Конфигурация Бизнес аналитик совместно с архитектором должны проверить способ реализации требований, возможно ли использование конфигурации или хотя бы параметризации. Бизнес аналитик должен рассмотреть несколько альтернативных вариантов при доработке решения для заказчика, которые совместили бы в себе: Реализацию продукта для заказчика, который максимально отвечал его требованиям Минимальное количество изменений продукта, по возможности как можно более поверхностных
- Нетиповая интеграция Интеграция Изменения процесса по требованиям регулятора в стране Изменения структуры данных и интерфейса. Зависят от бизнес процессов в стране -> отрасли -> компании Как к видите для доработки продукта для заказчика и так потребуется потратить много времени и усилий. Представьте если к этому добавятся проблемы с базовой версией продукта или с коммуникациями требований со стороны команды аналитиков базового продукта.
- С точки зрения процесса бизнес-анализа ничего особенного не добавляется, этап сбора и анализа большинства требований для базовой части продукта начинается задолго до начала проекта для заказчика При неправильном подходе к бизнес-анализу во время реализации базовой части: На этапе работы с заказчиком появляются проблемы Проблемы схожи с теми, которые есть при реализации второй фазы проекта, если отсутствовал зрелый процесс на первой Успешный процесс работы с заказчиком напрямую зависит от того, как создавался и поддерживается сам продукт. Каков подход к бизнес-анализу, насколько зрелым является процесс как бизнес-анализа ,так и разработки ПО с самого начала. Нерешенные проблемы проявляются на этапе работы с заказчиком Примеры возможных проблем: - невозможность повторного использования требований а иногда и отсутствие документированных требований, это ведет к таким проблемам, как потеря контроля над изменениями, правильного нахождения зависимостей и влияния... - невозможность повторного использования и трассировки приводит к тому ,что нельзя четко обозначить дельту изменений и точно определить влияние изменений в базе на версию заказчика.
- Поскольку во многих случаях заказчику требуется большинство модулей продукта (системы/решения), а сам продукт достаточно большой и может покрывать большинство основных процессов отрасли , работа по определению требований должна производиться в несколько итераций. На самом первом и начальном этапе нужно определить порядок величин объема работ, т.е. какие основные функциональные модули/блоки решения будут доставляться и насколько сильно они подвергнутся изменению. На следующем – определить, какие изменения пользовательских возможностей и функций нужны в каждом блоке и определение недостающих возможностей решения. На последнем – детальная оценка дельты изменении и определение деталей для каждого изменения. Например сколько аттрибутов , точные названия ,правила валидации для каждого.
- Определение порядка величин начинается с получения информации от заказчика: устных коммуникация на встречах, письменных коммуникаций, анализа документов ,предоставляемых заказчиком: процессных активов, шаблонов и примеров договоров, примеров работы представителей реального бизнеса. Начальная информация прорабатывается: проводится начальный анализ, уточнения и необходимая детализация, встречи, выезд на место работы заказчика. В заключении полученный результат предоставляется заказчику. Заказчик, рассматривая порядок величин и возможные затраты, принимает принципиальное решение, работать ли над проектом дальше или нет.
- После решения заказчика о продолжении проекта с согласованным порядком величин требуется переходить к следующей итерации – определении границ (рамок) и объема работ. Перед началом нужен небольшой процесс планирования. Поскольку зная порядок величин объема работ можно понять их масштаб, то нужно определить что из поставляемого является самым приоритетным для бизнеса и нужно ли вести работу над разными модулями одновременно , выделить независимые логические или системные компоненты, а также определить все зависимости и влияния на уровне функциональных блоков. После этого можно выстроить предварительный план выполнения работ по бизнес анализу, этапы, задачи и их длительность. На базе этой информации проектный менеджер (или программный) могут выстраивать свой план.
- Для ускорения доставки продукта заказчику, над выделенными компонентами (частями) имеет смысл проводить параллельную работу. Части, над которыми в продукте/решении можно работать параллельно, обычно выделяются архитектурно на этапе создания продукта. И работу с требованиями можно проводить, за исключением наверно, только определения интерфейсов взаимодействия, на этом этапе можно проводить параллельно. http://dic.academic.ru/dic.nsf/ruwiki/810626 Биллинг (англ. billing — составление счёта) — в некоторых видах бизнеса, в частности в телекоммуникациях — автоматизированная система учёта предоставленных услуг, их тарификации и выставления счетов для оплаты.
- Только после этого (распараллеливания) стоит приступать к более детальному сбору требований для оценки объема работ, а также совместной оценки с заказчиком. На этом шаге как нельзя к месту будут глубокие знания аналитика о возможностях базового продукта для качественного анализа и быстрой обратной связи заказчику по оценке объема недостающих возможностей изменений (дельты между существующей и требуемой функциональностью). На данном этапе аналитик активно взаимодействует с архитектором ( для оценки тех возможности реализации и ограничений) и проектным менеджером (для оценки проектных, ресурсных или финансовых ограничений). Таким образом у всех заинтересованных лиц формируется общее понимание поставляемого решения в виде объема требований/работ, высокоуровневой доменной модели или логической модели данных, процесса обмена данными между модулями и приблизительного плана работ. Пример: дополнительные страхуемые, в авто полисе могут все водить машину, кто имеет на это право после 25, а может быть конкретный список выбранных лиц.
- 1м 40с После того как архитектор и проектный менеджер помогли дать оценку запрашиваемым изменениям, а заказчик утвердил окончательный вариант объема доработок, можно приступать к детальной проработке и описанию требований. На этом этапе прорабатывается детальная структура данных , UI, интерфейсы, детали и условия последовательности действий в бизнес-процессах и в процессе взаимодействия пользователя с продуктом. Выбор критериев и модели оценки зависит от вида работ по изменениям. Не последнюю роль в этом играет накопленный опыт и модели сформированные на базе результатов предыдущих проектов. (последовательность работ производится на основе приоритетов бизнеса) В любом случае при детальной проработке требований возможно несколько итераций согласования с заказчиком, так как более детальная оценка может показать необходимость увеличения объема работ в сравнении с запланированным. Также на этом этапе возможно начало доработки и настройки отдельных частей продукта или функциональных модулей сразу после детального описания и утверждения части требований. Это позволяет заказчику ознакомиться с некоторыми результатами до завершения общей разработки и до начала доработки отдельных частей. Такой подход делает более гибким управление возможными изменениями по просьбе заказчика, а также ускоряет процесс внедрения решения. Заказчик фактически может начинать ознакомление и тестовое использование уже доработанной и настроенной функциональности на базовой версии. http://en.wikipedia.org/wiki/Joint_application_design
- 1м 30с Когда все требования заказчика собраны – это еще не повод начинать доработку именно версии заказчика. Нужно определить, насколько запрошенная функциональность востребована в отрасли. Исходя из этих знаний принимается решение о размещении. Возможно её реализацию стоит осуществить в региональной (предварительно настроенной) версии или даже базовом продукте. Есть системы обмена информацией в отрасли, если возможна типовая интеграция с ними, то она реализуется в региональной версии, от которой потом с троится версия для заказчика. Если у заказчика есть особенные требования, тогда возможен вариант как расширения функциональности в финальной версии для заказчика. Если требования по интеграции уникальны ,то реализовывать, естественно лучше в специфической версии для конкретного заказчика. Неправильный выбор места может повлиять как на позиционирование продукта в целом на рынке (отсутствие/наличие новой возможности в целом продукте), так и на дальнейшую поддержку версии заказчика. Разработка продукта не стоит на месте и при любых улучшениях базового продукта нужно будет либо обеспечивать совместимость с версиями заказчиков либо тратить силы на интеграцию новых базовых версий с кастомным кодом.
- Базовая версия – не единственная сущность , которая нуждается в постоянной поддержке и пополнении. В непрерывном пополнении нуждается также и база знаний, без которой трудно обеспечивать общий доступ к детальным знаниям о продукте для разного круга заинтересованных лиц от бизнес-пользователей до разработчиков. Накопление и использование уже наработанных и проверенных моделей, шаблонов и инструкций всеми ЗЛ дает: Возможности быстрой и качественной оценки Обеспечения согласованного подхода на всех проектах Внедрение лучших практик во все проектные активности База знаний необходима для того, чтобы иметь возможность предоставлять накопленные знания как команде , так и заказчику.
- EIS University provides a comprehensive suite of training, videos, documentation, assessments, and certifications that compliment the Exigen Suite. EIS Университет предоставляет полный набор учебных, видео, документы, оценок и сертификаты, которые дополняют продукт.
- Итак , где и при каких обстоятельствах нужно учитывать особенности работы при доработке продукта : … текст слайда…
- Наша компания использует систему управления требованиями Blueprint. Этот инструмент используется как средство поддержки и автоматизации процесса работы с требованиями как на протяжении всего жизненного цикла разработки программного продукта, так и при доработке для заказчика. Поддержка таких возможностей как версионирование, трассировка требований, визуальное моделирование, прототипирование и общение между участниками работы (рецензирование, утверждение) существенно облегчает как общий процесс бизнес-анализа, так и быстрое выделение дельты, требуемой для доработки продукта.
- Распределенная реализация отдельных модулей и функций – что где делать, где общие требования, а где специфические.