Привествую.

Есть задача - есть ряд документов и экранных форм. Надо увязать их между собой попутно выделив некий обобщающие принципы (модули, подсистемы, АРМы и т.д.), удалив дублирование функциональности, определив то, что надо еще доделать.
Хотелось бы это сделать с использованием некоего уже существующего ПО. Вроде бы это относится к Функционально-структурному анализу (но не уверен).
Может кто что посоветует? Направит в нужную сторону?

PS. Только сильно не пинайте. Я пока еще сам не могу четко сформулировать, что мне надо. Но пытаюсь.

Серж Alex MarmuzevichЕсть задача - есть ряд документов и экранных форм. Надо увязать их между собой попутно выделив некий обобщающие принципы (модули, подсистемы, АРМы и т.д.), удалив дублирование функциональности, определив то, что надо еще доделать.

Можно описать как с помощью структурных методологий, так и объектных. Дело вкуса.
Из структурных лучшим образом подойдет DFD (рисуется в BPWin'е).
Что такое DFD надо читать на citforum.ru - там всегда было много вводных хороших статей (автор Вендров, если не забыл).
BPWin лучше всего найти версии 3.5.х. Версия 4.х была ужасно корявая. О последующих не знаю.
BPWin знаю. Работал (кстати, автор скорее Верников или Маклаков :) ) И глючность оценил в полной мере :)
Но я там не нашел возможности рассматривать модель с разных точек зрения (разве что наваять ее заново). + у DFD есть небольшая проблема с декомпозицией (ее там вроде бы нет вообще), что не позволяет строить большие модели (на 1000 - 10000 сущностей)

shelsoft"Я пока еще сам не могу четко сформулировать, что мне надо"

А шо собственно надо ?
- Реинжиринг своей системы
- Реинжиринг чужой системы
- Построение новой системы на основе чужой системы
- Построение новой системы с нуля

Первый и последний случай я так понимаю отметаем ...
В прочих - начинаем с модели предметной области. В этом случае что документы, что формы (все относится к категории документы). И еще есть пожелания (требования) заказчика

Модель более высокий уровень абстрации, помогает выделить и понять процессы.
А вот потом снова переходим к документам и формам накладывая их на модель и
"выделив некий обобщающие принципы (модули, подсистемы, АРМы и т.д.), удалив дублирование функциональности, определяем то, что надо еще доделать"

Для первого шага подойдет ручка, бумажка, любой гипертекстовый редактор с рисовалкой (будет очень много исправлений и текста)

Для второго шага (в т.ч. итоговое документирование модели) любой DFD редакьор







Надо вообще реинжиниринг как чужой так и своей системы. Одна из задач - сверить систему с ТЗ, найти пробелы. Обычно ручной и бумажкой это и делаю. Достало.
Со вторым шагом все очень даже понятно, тут и вопросов нет.
А вот чем поможет гипертекстовый редактор - не понятно. Потом по HTML сделать выборку по перекрестным ссылкам? Типа описать что-то в WiKi и сформировать разные представления?
Идея интересная. Надо будет посмотреть

Майевтик Alex MarmuzevichПривествую.

Есть задача - есть ряд документов и экранных форм. Надо увязать их между собой попутно выделив некий обобщающие принципы (модули, подсистемы, АРМы и т.д.), удалив дублирование функциональности, определив то, что надо еще доделать.
Пишите точнее - что значит - "есть ряд документов и форм"? Система-то сама есть? Контакт с авторами есть? Исходный код системы есть?
1. Система есть.
2. Контакты с авторами есть
3. Исходные коды есть
4. Описание системы есть (что сделано)
5. Есть описание того, что требуется.
Одна из простейших задач - определить, что сделано лишнее, что не сделано.

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

Для удобства давайте разделим все описания системы на внешнее (Бизнес-архитектура, Информационная архитектура - архитектуры анализа и проектирования) и внутреннее (Техническая архитектура, Технологическая архитектура - архитектуры проектирования и реализации).

Бизнес-архитектура описывается в терминах ролей пользователей, их потребностей, задач, сценариев и регламентов работы (User Role, Tasks, Goals, Needs, Scenario, Business-script, Business use-case). Потребности и задачи группируются в соответствии с кластерами предметной области, скажем, Управление Заказами, Управление Поставками, Взаимодействие с клиентами, эти кластеры назовём Бизнес-модули .

Информционная архитектура описывает структуру данных (аналитическая, инфологическая модель), использумых при работе с системой, информационные потоки (DFD), а также пользовательские сценарии (User story, Use-case), навигационную модель системы и интерфейсы для работы в системы.

Техническая архитектура описывается в терминах узлов, слоёв, уровней, пакетов, компонентнов, программных модулей, программных функций, сообщений, вызовов, классов. Можно всё это соотнести с некоторыми Техническими модулями , скажем Подсистемы орагнизации интерфейса с пользователем, Подсистема интеграции с внешними системами, Подсистема логики приложения, Подсистема бизнес-логики, Подсистема доступа к данным, Подсистема бизнес-правил, Подсистема хранения данных.

Технологическую архитектуру (конфигурация оборудования и сетей) особо трогать нужды нет, т.к. она мало меняется от проекта к проекту и мало значима. Но в каждом конкретном проекте решать вам.

Подробнее см. Модель Захмана.

Меня терзают смутные сомнение, что это не совсем то, что надо, но гляну.
Майевтик
Так вот я понимаю так, что если вы выступаете в роли аналитика, но не архитектора, то вас интересует Бизнес-архитектура и Информационная архитектура. Вообще говоря Бизнес-архитектура должна прослеживаться уже в ТЗ - т.к. обычно там аналитик приводит группировку функциональных свойств системы по Зонам предметной области. Если этого нет, значит модель Бизнес-архитектуры и Информационной архитектуры вам придётся воссоздавать, начиная с бизнес-целей, заинтересованных лиц, описания предметной области, выявления задач пользователей и самое главное - сделать трассировку всего между собой. Это всё, если вы хотите получить достаточно полное и корректное описание системы с целью её дальнейшего развития.

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

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

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

Майевтик

Хотелось бы это сделать с использованием некоего уже существующего ПО. Вроде бы это относится к Функционально-структурному анализу (но не уверен).
Может кто что посоветует? Направит в нужную сторону?ПО вторично. Сначала надо сформулировать задачу, потом понять методы её решения, затем выбрать походящий, а потом уже говорить о ПО. В общем и целом я бы действительно смотрел в сторону гипертекстовых решений, потому как: "текст" - нет ничего проще чем текст, "гипер" - обеспечение трассируемости + вставил бы несколько неформальных диаграмм взаимосвязей частей системы.

Попытаюсь привести пример того, что я хочу.

Запись Подсистема Модуль Функция
1 П1 М1 Ф1
2 П1 М2 Ф1
3 П2 М2 Ф2
4 П2 М3 Ф3
5 П2 М4 Ф2
6 П3 М4 Ф4
Точка зрения - Подсистема.
К подсистеме П1 относятся модули М1, М2 и функция Ф1
Видим, что структура системы некорректная, т.к. в рамках одной подсистемы 2 разных модуля содержат одну функцию. Решение - убить модуль М2 или создать версию функции Ф1.1

Точка зрения - Функция
К функции Ф1 относятся модули М1, М2, подсистема П1

В рамках подсистемы П2.
Точка зрения - Модуль
К модулю М2 относится функция Ф2


Может это как-то что-нибудь прояснит

PS. Я сам пока плаваю в задаче. Я уже понял, какие данные анализируются. Примерно понял алгоритмы анализа. Но не понял, что это такое :)

UseCase - вещь конечно очень хорошая и правильная, но не декомпозируется?
Больше 8-12 UsaCase на диаграмме - и ничего не разобрать.
BpWin (IDEF) с функциями декомпозиции - гораздо более эффективная (с моей точки зрения вещь).
НО.
Декомпозировав диаграмму я не могу собрать другую диаграмму с рамках одной и той же модели но с другой точки зрения. И это бесит.
Делать другую модель конечно очень интересно. Но если у нас формируется 10-12 точек зрения, в которых используются общие элементы, мягко говоря затруднительно будет изменять логику нижнего уровня (нижний уровень декомпозиции) сразу для нескольких моделей.