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

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

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

Есть идея описать сценарии работы с имеющейся системой.
1) Актерами я планирую сделать имеющееся ПО (есть три группы приложений с GUI, каждая из групп ПО подразумевает определенную категорию задач в системе).
2) Т.к. сразу все описывать тяжело, то хочу сначала обрезать набор прецедентов, зафиксировав требования, касающиеся работы в рамках только этих прецедентов, а затем этот рабочий набор "наращивать", расширяя набор операций до полного.
3) Т.к. профессионально программистом не работал, то есть желание не расписывать самостоятельно классы и методы (может быть потом привлечь к этому ответственных за код людей), а с одной стороны показать сценарии работы ("создать объект", "удалить объект", "изменить статус объекта"), а с другой - показать изменения, которые происходят на уровне баз данных, передачи информации в служебные программы и т.п.
4) Не понятно, как выписывать наборы ограничений. То есть вот есть у нас операция по редактированию объекта, при этом есть ряд ограничений типа "если параметр1=1, то {если дата1 больше текущей, то задать дата2=текущей, иначе задать дата 2=дата1} иначе не изменять дату2".
Так вот как записывать такие ограничения, чтобы это было читаемым, обсуждаемым, редактируемым?

Можете ли сказать - жизнеспособны желания 1-3, что-то можно посоветовать по 4) ?

На мой взгляд все это нежизнесопособно.
1. Этим должен заниматься человек уже глубоко знающий систему, а вряд ли ему это позволят
2. Это займет такое колоссальное количество времени, что как в задаче про бегуна и черепаху, пока вы делаете модель, в системе еще наменяют кучу всего
3. Но делать надо, никуда не денешься. Исходники на чем написаны?

По поводу 4, посмотрите книгу А.Коберна "Современные методы описания функциональных требований к системе".

По поводу 4, посмотрите книгу А.Коберна "Современные методы описания функциональных требований к системе".

Это детали. Имхо, нужно сначала договорится о главном. А писать ограничения можно: русским языком в предикативной форме - как требования описываются, с помощью OCL - это расширение UML и специально для этого предназначено, с помощью графических диаграмм в случае сложных ограничений, с помощью псевдокода, с помощью языка на котором создана система, да еще с помощью языка z И т.п.

Galogen,
1. Я около года тестировал эту систему, поэтому как раз с тем, что описал в 2) знаком хорошо.
2. Есть возможность сдерживать изменения в системе некоторое время.
3. C# на Visual Studio 2008.

Станкевичус Йонас, спасибо за ссылку.

1. Я около года тестировал эту систему, поэтому как раз с тем, что описал в 2) знаком хорошо.

Имел ввиду "с тем, что описал в 3)"

3. C# на Visual Studio 2008.

Попробуйте из кода методом обратного инжиниринга извлечь все-что можно: чаще всего диаграмму классов, можно также построить сценарии - диаграммы последовательностей (Enterprise architect умеет вроде бы)

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

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

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

Исходя из этого, ИМХО, имеет смысл строить не функциональную модель системы в виде юз-кейсов, а модель дефектов - распределение дефектов по модулям программы.

В этом случае, Вы узнаете:

1) какие модули спроектированы и реализованы хуже всего - в них будет много багов;
2) какие ошибки характерны для Вашей системы в целом и её отдельных модулей - возможно, причина в нечётких требованиях или плохой обратной связи с пользователями во время проектирования.

Как результат, Вы сможете повысить эффективность сопровождения программы.

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