Petro123да ладно вам :)
Правда по сердине - низы должны хотеть, а верхи должны мочь (создавать условия). Иначе бывает революционная ситуация (К.Маркс т.2 )) )
Если bebop - "верхи", то должен сделать орг-мероприятия по устранению "бардака". Как говорит Комсомолка .
Плохо что "низы не хотят искать", как говорил аФФтар.
IMHO
Не верхи я. Я думал это и так понятно. Но начальство прислушается к рекомендации, которую я дам.
Если я дам рекомендацию типа: "Нанять консалтера", "Навести порядок в бардаке при помощи разумного формализма", "установить единый стандарт ИТ предприятия", то на первый раз, мне предложат поработать ещё и конкретизировать предложения На второй, если я предложу решения такого же уровня абстракции, думаю, задачу отдадут кому-то ещё.

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

Ещё раз. Необходимость "разумного формализма", "единого ИТ-стандарта предприятия" не обсуждается. Вы правы. Я полностью с вами согласен. Как ещё сказать, что я согласен?

Меня интересовала конкретная проблема и конкретные подходы к решению этой проблемы.
Подходов вырисовалось несколько, каждый со своими преимуществами и недостатками. Хотелось бы услышать ваше мнение. (Мне кажется вы сторонник метода 1. Я ошибаюсь ???)

1)Только бизнес-модель
Иметь 100% актуализированную модель бизнес-процессов предприятия (andbary). Не важно в каком виде ARIS, IDEF, текстовые регламенты итд. По этой модели программисты-полуаналитики пишут реализацию сами и "нарезают" задачи кодерам.
Если нужен формализм в отношениях с заказчиком то SRS пишется по бизнес-модели и по закрытии проекта архивируется\выкидывается. Актуальна только бизнес-модель.

+ Требования к ПО (SRS, юз-кейсы итд) отсутствую как выделенный слой документации. Соответственно не тратится труд на их актуализацию.
- Не совсем подходит к нашей ситуации. (У нас практически отсутсвуют программисты-полуаналитики). Кодер не может работать по описанию бизнес-процесса.
- Бизнес-модель никогда не бывает так детальна, как требования к ПО.
- Бизнес-модели заточены под описание бизнеса, а не требований к ПО, соответственно будет куча "нестыковок".
- Бизнес-модель преобразовывается в SRS "творчески" (неоднозначно). Если SRS надо делать часто, то на "творчество" будет расходоваться много усилий.

2)Только UML
Иметь 100% описанную реализацию системы (UML). Когда нужен формализм в отношениях с заказчиком, то SRS пишется по UML описанию системы и по закрытии проекта архивируется\выкидывается.
Актуальна только UML модель.

+ Требования к ПО (SRS, юз-кейсы итд) отсутствую как выделенный слой документации. Соответственно не тратится труд на их актуализацию.
+ UML модели "заточены" под описание ПО.
- При таком подходе аналитик, как правило, начинает заниматься дизайном
- Спецификации содержат много информации о бизнесе (профили стэйкхолдеров, их основные интересы, бизнес-цели проекта, его бэкграунд итд). Думаю будут сложности с описанием всего этого в виде UML.
- UML модель с детальностью "как у SRS" достаточно сложно сделать
- UML преобразовывается в SRS "творчески" (неоднозначно). Если SRS надо делать часто, то на "творчество" будет расходоваться много усилий.


3)Модель со ссылками на SRS
Аналогично варианту 1) или 2) но поддерживается отдельный "слой" документации "требования к ПО". Делаются ссылки от элемента модели к соответствующим спецификациям.

+ Можно делать менее детальные модели, оставляя мелкие подробности в спецификациях
+ Спецификации по проектам\проектикам пишутся как писались. Никаких доп.усилий. Они лежат в неком архиве, доступные по ссылке.
- Не слышал про практические примеры использования такого подхода. Можно потратить кучу сил и ничего не получить взамен.

4) Библиотечные технологии
Заводим Главный Рубрикатор, заводим Главный Список Ключевых Слов.
Продумываем поиск спецификаций (и в баг-трекере) по рубрикатору, поиск по ключевым словам.

+ Простые инструменты
- Не слышал про практические примеры использования такого подхода. Есть риск, что всё останется как есть (ничего невозможно найти).


5) Вики- технологии
Завести что-то вроде википедии про нашу систему. Сами SRS тоже держать под вики.

+ В духе времени
- Не слышал про практические примеры использования такого подхода. Есть риск, что всё останется как есть (ничего невозможно найти).
- Есть ещё больший риск - что сломаем старую схему документирования проектов и получим ещё худший бардак.


6) ГлавнаяСРС
Заводим главную СРС на систему (можно под Реквизитом, можно просто как вордовый файл). После каждого проекта\проектика\бага, который меняет систему актуализируем ГлавнуюSRS.
Когда делается новый проект SRS по нему разрабатывается на основе Главной SRS.
Постепенно ГлавнаяSRS описывает всю систему.

+ Судя по всему вариант вполне практический. Есть очевидцы (технолог) его использования.
+ Есть куча инструментов для работы с БольшойСРС
+ Существующая схема документирования проектов меняется незначительно
- Тратим силы на поддержание актуальности ГлавнойСРС

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

Petro123 автор-При таком подходе аналитик, как правило, начинает заниматься дизайном
фраза какая-то ненормальная.
IMHO
- аналитик пишет требования к разрабатываемой системе. Как можно их пистать, не видя "дизайн" в кавычках системы?

Требование - Оператор должен быстро выбрать город из списка городов.
Вы думаете тут нет дизайна?

Пользовательские интерфейсы обычно включаются в СРС.


А вообще в ieee830 есть даже специальный параграф про это:

4.7 Embedding design in the SRS
A requirement speciÞes an externally visible function or attribute of a system. A design describes a particular
subcomponent of a system and/or its interfaces with other subcomponents. The SRS writer(s) should
clearly distinguish between identifying required design constraints and projecting a specific design. Note
that every requirement in the SRS limits design alternatives. This does not mean, though, that every requirement
is design.

The SRS should specify what functions are to be performed on what data to produce what results at what
location for whom. The SRS should focus on the services to be performed. The SRS should not normally
specify design items such as the following:
a) Partitioning the software into modules;
b) Allocating functions to the modules;
c) Describing the how of information or control between modules;
d) Choosing data structures.

4.7.1 Necessary design requirements

In special cases some requirements may severely restrict the design. For example, security or safety requirements
may reflect directly into design such as the need to
a) Keep certain functions in separate modules;
b) Permit only limited communication between some areas of the program;
c) Check data integrity for critical variables.
Examples of valid design constraints are physical requirements, performance requirements, software development
standards, and software quality assurance standards.
Therefore, the requirements should be stated from a purely external viewpoint. When using models to illustrate
the requirements, remember that the model only indicates the external behavior, and does not specify a
design.

Petro123вот что бывает когда каждый делает только своё:

дискуссия уже была в этой степи

Я имел в виду то же самое, только плохо выразил свою мысль.

byur bebopЯ имел в виду то же самое, только плохо выразил свою мысль.

Возвращаясь к истокам проблемы ... насколько я понял есть система -- но нет документации требований в частности ... вносить изменения в такую систему становиться сложно, и тестировать тоже ... Кроме этого есть ворпос с инструментарием для управления требованиями, который бы поддерживал мультипроектность.
Документация с требованиями есть на доработки сделанные в последние 1.5 года (системе около 10 лет). Это около 20-30 относительно крупных проектов (от человеко-месяца) и больше 100 мелких доработок (документировались по упрощённой схеме).
Сама документация представляет из себя файлы MS Word выложенные в сети.

В контексте каждого конкретного проекта\проектика документация устраивает. Но повторно использовать требования, мягко говоря, сложно.

byurС тако проблемой сталкиваются многие. Я на своем веку видел следующие решения:
1. С какого-то момента начинали планировать релизы и писать в виде фич, что должно быть сделано в конкретном релизе, постепенно "раскручивая по спирали" собственно требования. Т.е. если фича "задевала что-то большое" -- то это большое тоже описывалось. Другой вопрос как -- это могут быть обычные сценарии юзкейсов (помним, что это ТЕКСТ а не UML диаграмма) -- которые раскручивались до outmost юзкейсов по Коберну. Если нет возможности писать полностью юзкейсы разных уровней -- то они просто выделялись. Альтернатива -- написание сценариев, но с их структуризацией сложнее и для большой системы -- проблема.
Требования под каждый конкретный проект пишутся. Но описания "чего-то большего" непонятно куда класть и соответственно очень трудно потом найти.

byur2. Открывали новый проект, с привелечением консультантов, которые помогали восстанавливать требования к системе, в связке со сценариями тестирования и изредка с восстановлением архитектуры -- если о ее наличии в системе могла идти речь :-). Делался сначала Vision на проект, с описанием основных фич, потом все аккуратно по фичам декомпозировалось на требования с определенным уровнем детализации. Т.е. от высокоуровневых к более детальным. В ходе обсуждения в этом форуме пришли к выводу, что нужна МатьВсехСРС (ГлавнаяСРС) (возможно под неким инструментом типа Реквизита или Калибера), которая должна постепенно "расти" по мере реализации новых проектов. По поводу позвать консультантов, чтобы сделать заготовку ГлавнойСРС - трудно сказать, сначала наверняка попробуем собственными силами.

byurЧто касается инструментария для требований -- присмотритесь к CaliberRM, возможно он подойтет в вашем случае -- в нем есть хорошая связь м/у проектами и механизмы повтороного использование требований из др. проектов, включая возможность изменения требования только в исходном проекте (и распространение изменения), так и возможность вести самостоятельную жизнь унаследованного требования ... это удобнее в нем сделано чем в ReqPro.Как таковую связь между проектами на данном этапе не очень понятно как использовать. Боюсь она может выродится в макаронные ссылки всего на всё, которые только ещё больше запутают ситуацию.
Главная СРС мне кажется более надёжный подход.

Возможно я не очень понятно объяснил. Главная СРС не отменяет подготовки требований к каждому проекту\проектику по нашей обычной процедуре.
После реализации проекта аналитик будет должен синхронизировать изменения внесённые его проектом с Главной СРС.

byur И второй момент, в каком виде требования будут предствалены в Главной СРС и с какой детальностью будут синхронизироваться?

Точно не знаю, пока никаких практических шагов ещё не предпринято.

Чисто теоретически, думаю что в главной СРС требования должны быть с такой же детальностью как и в СРС под конкретный проект. Иначе большая часть её ценности теряется.

analyst_

byur

А есть где-нибудь примеры System Requirements Specification.
Это что-то вроде Концепции системые\Vision? Или это что-то другое?
Есть ли на неё какой-нибудь стандарт (как ieee830 для Software Requirements Specification)?

tchingiz ПробегалМимо. Цель описания - составить документ "РУКОВОДСТВО РАЗРАБОТЧИКА" чтобы вновь пришедший в компанию разработчик смог приступить к проектированию прикладной системы использую данный конструктор.
Документ разрабатывается следующим образом... Были взяты ГОСТы 19-той серии... 503, 504, 505, 105, 402 и на основании них был составлен шаблон и документ "Руководство разработчика"...
(если интересно, могу выложить текст разделов )
http://users.iptelecom.net.ua/~agp1/ru/mlc.html
http://standards.narod.ru/gosts/index.htm
За ссылки спасибо.
Вместе с тем, мне кажется, что руководство разработчика\администратора\пользователя системы в этой ветке скорее оффтопик. Меня интересует проблема скорее со стороны аналитиков которым приходится писать много SRS.

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

analyst_
По RUP документ Vision отличается от SRS. Vision (Документ-концепцию) используется прежде всего для маркетинговых целей. В этом документе не перечисляются детальные требования к системе, типа .....
Я в курсе что такое vision. Я в курсе, что такое SRS ( Software Requirements Specification)
Я никогда не видел System (не Software!) Requirements Specification.
Это что-то близкое к Vision? Есть ли на неё какой-нибудь стандарт?

Майевтик[bebop]
Не очень внимательно читал весь тред, поэтому если что не так понял - подправьте.

Я так понял, вам нужно иметь описание системы как с точки зрения требований, так и с точки зрения решений, которые эти требования реализуют.

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

Сейчас в нашей компании есть определённое понимание как писать требования на отдельный проект\проектик по доработке ИС. Проблема в том, что система в целом остаётся неописанной. Найти что-то в документации по 30 большим проектам и 100 маленьким проектикам невозможно. Для каждого нового проекта требования приходится собирать практически заново.
Пример иллюстрирующий что у нас происходит сейчас по ссылке