Добрый день уважаемые коллеги,

Исходная ситуация: мы - разработчики ПО на 1С:8.х.
Задача: повысить качество взаимопонимания с заказчиком, с программистами и качество продукта путем ввода понятной для всех документации.
Особенности: взаимодействие с заказчиками складывается таким образом, что внедрение идет последовательно и разработка единого видения ИС/отчета об обследовании проблемотично. Например: месяц пишем подсистему CRM, потом месяц подсистему "Управление инструментами" и т.д. Разработать общее ТЗ/документ требований и общую модель системы не возможно.

Вопрос: Раскажите, как такие работы оформляются у вас? Поделитесь опытом..

Пока выбрал для себя следующий подход:

1. Концепция (формируется на каждый этап работ): бизнес-требования, требования пользователей, use-case модель, информационная модель разрабатываемой подсистемы (в случае с 1С - вещь понятная даже для неподготовленного пользователя, взял диаграмму классов из UML)
2. ТЗ (по одному этапу может быть много ТЗ, содержащие различные доработки) - документ содержит описание экранных форм документов, доработок к существующим объектам конфигурации и т.д.
3. План итерации - план работ на неделю с целью определить что из первоначального ТЗ в данный момент реализуем.

Здравствуйте.

Особенности: взаимодействие с заказчиками складывается таким образом, что внедрение идет последовательно и разработка единого видения ИС/отчета об обследовании проблемотично.

В чем заключается проблематичность? Заказчик несовсем понимает перспективы развития ИС у себя на предприятии, нет денег, использует поэтапное внедрение? Подходит к процесс информатизации не глобально? Но потом задним умом понимает это и принимает неосознано, а поезд ушел как говорится?
Или заказчик таков, что полагает, что разработчик сам должен все знать и нечего заказчика мучить?

Например: месяц пишем подсистему CRM, потом месяц подсистему "Управление инструментами" и т.д. Разработать общее ТЗ/документ требований и общую модель системы не возможно.

А что понимать под общим ТЗ? Если нет понимания чего в общем делаем, а есть, как я понимаю, поэтапное внедрение функциональных подсистем, просто на одной платформе и разработчки тоже один?
Также интересно узнать, что Вы вкладываете в понятие общая модель системы и невозможность ее создания?

Вопрос: Раскажите, как такие работы оформляются у вас? Поделитесь опытом..

К сожалению у нас тоже с этим есть проблемы. Правда ситуация отличается тем. что не заказчки определяет видение системы, а разработчик предлагает собственное и горячо убеждает, делясь соственным опытом.

В общем формировали бизнес-процессы в BPMN - вполне понимаемые стороной заказчика, устраивали презентации и собрания.

Что касается стороны аналитик-разработчик, то тут проще - это внутренний мир и способ представления избирается привычный удобный. По своей схеме - по-моему - это нечто из советских времен, называемые постановками задачи: входная информация, выходная информация, предложения по экранным формам. Почти информационное обеспечение в внемашинным ИО и внутримашинным ИО .

Правда такой способ может идеологически и верен, так как каких-то сверх кардинальных изменений не производится - платформа одна, внутренний рефакторинг, улучшение процесса разработки. Если же возникает потребность в новом функционале, то он проверяется на соответствие имеющемуся. Система сверхгибкая, сделать можно все, правда вопрос - какой ценой:)

Здравствуйте.
В чем заключается проблематичность? Заказчик несовсем понимает перспективы развития ИС у себя на предприятии, нет денег, использует поэтапное внедрение? Подходит к процесс информатизации не глобально? Но потом задним умом понимает это и принимает неосознано, а поезд ушел как говорится?
Или заказчик таков, что полагает, что разработчик сам должен все знать и нечего заказчика мучить?

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

А что понимать под общим ТЗ? Если нет понимания чего в общем делаем, а есть, как я понимаю, поэтапное внедрение функциональных подсистем, просто на одной платформе и разработчки тоже один?
Также интересно узнать, что Вы вкладываете в понятие общая модель системы и невозможность ее создания?

Понимание есть. Но вся информация уже есть у нас в головах. Такая ситуация пока всех устраивает.

Задача - сделать максимально простую документацию, но достаточную для всех сторон Мне интересно каким образом документируются небольшие проекты в случае штатных разработчиков? Не пишется же отчет об обследовании, ведь работники сами прекрасно представляют организацию.. Как мне кажется: Надо просто задокументировать цели, пользовательские пожелания и задачи.

Задача - сделать максимально простую документацию, но достаточную для всех сторон Мне интересно каким образом документируются небольшие проекты в случае штатных разработчиков? Не пишется же отчет об обследовании, ведь работники сами прекрасно представляют организацию.. Как мне кажется: Надо просто задокументировать цели, пользовательские пожелания и задачи.

Как учат нас the best practices в основе видение или концепция. Это и бизнес-план, и артефакт, призванный как раз дать всем ясное представление о том, что нужно делать, каковы стратегические и тактические цели, кто заитересован в проекте и какие общие нужды имеет.

Такми образом можно набросать Видение и спецификацию дополнительных средств.

Видение может быть отрисовано через фичи, контекстные диаграммы, поясняющие BPMN или другие диаграммы, планы проекта.

По сути Вы и сами все написали

Как учат нас the best practices в основе видение или концепция. Это и бизнес-план, и артефакт, призванный как раз дать всем ясное представление о том, что нужно делать, каковы стратегические и тактические цели, кто заитересован в проекте и какие общие нужды имеет.

Такми образом можно набросать Видение и спецификацию дополнительных средств.

Видение может быть отрисовано через фичи, контекстные диаграммы, поясняющие BPMN или другие диаграммы, планы проекта.

По сути Вы и сами все написали

Нет предела совершенству. Интересно, как подобные задачи другие решали. Не я ж один такой одинЭснег, кто задумался над проблемой документирования собственной работы.

Интересно, как подобные задачи другие решали.

Ага Мои слова вас уже притомили

Не я ж один такой одинЭснег, кто задумался над проблемой документирования собственной работы.

А вы поищите темы на форуме, я и другие подобные темы поднимали.

Да с одной стороны есть инструмент со своими ограничениями, возможностями, +  и  -

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

Предполагается, что 1С обладает набором базовых понятий предметной области, из которых может быть составлено гибкое многообразие реальных задач.

Таким образом можно исходить из возможностей 1С, ее модели или совокупностей моделей. Найти разницу между тем, что есть, и чего бы хотелось. Если разница такова, что она может быть реализована базовой настройкой и программирования конфигурации - путь один, если нет по всей видимости используются всякие способы интеграции с внешними приложением, АПИ и т.п., которые позволяют найти решение на стороне, но интегрировать его с 1С.

Тогда надо иметь внятный документ базовых моделей 1С

Модель чего хотелось бы

Модель разницы

А?

Если Вы автоматизируете ВСЕ предприятие, и оно достаточно сложное, то в первую очередь надо подумать об Архитектуре Предприятия, а потом уже о разработке конкретного проекта. Вот например как RUP соотносится с ToGAF:
http://www.ibm.com/developerworks/ru/library/temnenco/index.html

Т.е. у Вас должна быть четкая стратегия развития с явными целями, потом декомпозиция их на проекты и БП в них. Параллельно нужно продумать Архитектуру Приложений, Информации и Технологий.

Потом берем конкретный проект и пишем для него Концепцию, включая (или нет) БП и БО. Потом описываем ПТ, например, в виде ВИ, и НеФТ. Для вашего случая должно хватить.

Второй вопрос - это изменения требований. Если Вам нужно поддерживать целостность Целей, БП, БО, ПТ и НеФТ, то нужна уже некая тулза. Для начала можно рассмотреть системы от Sparx или просто Wiki + некий моделлер. Причем нужно еще четко прописать политику изменений, т.е. от анализа запросов с верхнего уровня до ПТ и НеФТ.

А ну да, еще же есть УП, но это отдельная тема ...