2116

Системный Анализ и Требования / Источники требований, полнота требований, взаимосвязь с целями

« : 14 Марта 2007, 00:55:28 »

Часто встречаю ТЗ как некий структурированный список требований.

Когда вижу список, всегда возникают вопросы:
А) откуда взялось данное требование?
Б) Насколько оно обосновано?
В) Достижению какой цели оно служит?
Г) А вдруг какие-то требования упущены?

Да, есть ряд методик по выявлению требований, основная из которых - куча мала - мозговой штурм - понакидаем мнения разных людей разных компетенций, thousand lemmings cannot be wrong, collaboration rules и всё такое. Потом этот поток сознания отсортируем по кучам, выявим дубликаты, разрешим противоречия - типа получим что-то более менее целостное и внушительное. Но - devil's in details - не всегда есть возможность привлечь многих людей и самое главное - заданные мной вопросы остались без ответа!

Есть другой хороший подход - сценарии использования, пользовательские истории и т.д. - Они позволяют компактно свернуть требования и связать их по целям в единые цепочки. Это клёво. За это честь и хвала Якобсону с Коберном. НО. Остаются нефункциональные требования, про которые Якобсон что-то неуверенно мямлит в Use-cases Patterns. Остаётся риск того, что какие-то use-case'ы будут невыявлены. Остаётся вопрос о взаимосвязи целей Пользователя с Целями Заказчика.

"Система должна иметь пользовательскую документацию" - это нужно или нет? Чьё это требование, чьи целям служит? Каким именно? Где они обозначены?

"Система должна иметь документацию по внутреннему устройству" - это чьё? Кто сказал? Почему это решается чьим-то волюнтаристским решением, а не исходя из целесообразности (соответствия конкретной цели, которая иначе не будет достигнута)?

Отдельно стоит рассказать про проблемы ГОСТ 34.602 и главное - как их преодолевать. Но об этом позже.

А пока - как выстроить полный, взаимосвязанный набор требований нужной степени детальности, не ограничивая реализацию и не оставляя провалов в связи с целями системы? Как обеспечить целостное видение системы, а не набор утверждений, висящих в воздухе?

NB: в дополнение - мой полугодичной давности пост "Типовые ошибки ТЗ".

2117

Бизнес-анализ и Целеполагание / Re: Пошаговый перевод избранных мест из BABOK

« : 14 Марта 2007, 00:28:38 »

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

Цель блаародная. Ссылка не туда.

По организации процесса перевода мне думается надо бы:
а) убедиться во вменяемости и полезности материала
б) связаться с ЗЫИИБОЙ на тему прав и их взгляда на такую деятельность
в) организовать перевод на базе wiki-системы  с параллельным формированием словаря, желательно с возможностью генерации PDF/OpenDocument.
г) найти спонсора, чтобы работалось веселее

Если у bas'а хостинг совсем каюк, могу поставить wiki у себя.

2118

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 00:19:10 »

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

Требований к чему? Ну опишем мы существующий процесс разлива борща на всю палату как Б-П - где тут требования?

А вот самое интересное мы упускаем: это зарождение, выявление проблемы, анализ самой постановки задачи, проблемный анализ.

Где мы упускаем, когда? Для чего заявлена тема "Целеполагание"? Кто первый полез в моделирование системы, вместо того чтобы сначала получше понять саму проблему?

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

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

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

Ещё проблема в том, что, как говорит Boatman, "цели постулируются, а не выводится" - имхо, это порочная практика. Опыт говорит, что если мы возьмём сформулированную заказчиком цель проекта как есть, например "интеграция 1С с Аутлуком", мы очень часто можем придти к ситуации а) смены требований и/или провала проекта б) по причине несоответсвтия заявленной цели действительной (но плохо осознаваемой в момент "постулирования").

2119

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 00:07:32 »

Однако бизнес-анализ сам по себе в нашем случае не нужен.

В каком-таком "нашем" случае? Есть документ, озаглавленный просто и незатейливо - "Руководство к Своду знаний по Бизнес-анализу". Никакого контекста, предметного уклона в IT нигде в реквизитах документа не указано. Открываем уже раздел 1.4.3 - с места в карьер - определение видов требований - пункт 2 - "Требования пользователей". Какие-такие пользователи в бизнесе??? ) Какое к чёрту "прототипирование"?

Его потребность важна в преломлении будущего ИТ-проекта. В этом случае основной результат любого бизнес-анализа - формирование требований.

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

Если бы ЗЫИБА ясно сказали, что они пишут про Бизнес-анализ с целью выявления требований для по улучшению деятельности бизнеса посредством реорганизации и автоматизации, или хотя бы Business Analysis in IT, я бы понял, а в такой обобщённой формулировке, как сейчас, я вот этого крена от БА в Требования не понимаю.

Что такое "Бизнес-анализ" в вульгарном понимании, основанном на анализе самого термина?

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

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

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

В случае создания нового бизнеса БА используется для:
* Возможно, разработки модели бизнеса (хотя я это называю бизнес-проектированием, new business development)
* Анализа целесообразности нового бизнеса со всех сторон, прежде всего в терминах экономической выгоды (ROI, маржа). Тут же полезны имитационные моделирования и проч .и проч.

То, что всё это так или иначе может быть в ряде случаев связано с требованиями (К устройству будущего бизнеса и соответствующей инфраструктуры) - понятно. Но почему требования проходят красной нитью по всему БАБОКу - мне НЕ понятно. Финансовый анализ мне кажется терминологически гораздо ближе у БА (имхо, входит в него), чем какие-то там требования

Почему на обложке изображена логическая модель данных, в маленькой процессной части сказано про SSADM, ER, IDEF, UML, BPMN, а про ARIS'овские нотации ни слова?

Точнее, гипотеза о том, почему Бизнес-анализ подаётся под таким соусом, у меня есть - это разные близкие к IT люди пытаются так заработать место под семантическим солнцем, достаточно справедливо полагая, что в будущем весь бизнес будет построен на системах, а потому можно подсунуть под красивый термин "БА" свой многолетний опыт работы с требованиями и софтом - смотри коорд. совет: Амблер, Леффингвелл и т.д.

Вобщем, пока у меня очень много вопросов, которые надо разрешать.

2120

Вакансии / Re: Системный аналитик

« : 13 Марта 2007, 22:18:24 »

Спрашивается вопрос - а чем эта вакансия отличается от десятков других?

Типа МСК, ага?

2121

Конференции Семинары и Тренинги / Семинар AgileRussia: Применимость agile-методик в in-house-разработке

« : 13 Марта 2007, 09:49:24 »

В пятницу, 16-го марта пройдёт очередной семинар AgileRussia. Тема встречи - разбор case'а - "Применимость agile-методик в in-house-разработке".

Ситуация:
* много разных проектов
* много разных технологий
* небольшой коллектив разработчиков

Я буду представлять интересы такого коллектива, эксперты по Agile - предлагать методики и обсуждать их применимость.

Подробности и записываться здесь - http://agilerussia.ru/index.php?option=com_content&task=view&id=32&Itemid=27

2122

Системный Анализ и Требования / Образцы ТЗ по ГОСТу

« : 10 Марта 2007, 17:46:34 »

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

Немногие знают, что в рамках движения к открытости и прозрачности Электронного Государства, в 2005-2006 годах Министерство Экономического Развития и Торговли РФ создало на своём сайте раздел и выложило в нём проектную документацию по множеству проектов разработки информационных систем, создаваемых по программе "Электронная Россия":

http://aisup.economy.gov.ru/pubportal/

Эта документация создавалась на деньги налогоплательщиков и поэтому принадлежит всем гражданам страны. В ней зачастую воплощены опыт и знания многих коммерческих разработчиков.

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

Если ГОСТ для чего и создавался - то именно для такого рода проектов.

Ряд документов успешно использует UML и ARIS.

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

Таким образом будут решены следующие задачи:
1. Извлечены знания - типовые и просто удачные решения.
2. Получены образцы "эталонных" документов.
3. Получен материал для обсуждения.

Я предлагаю начать с ТЗ, как наиболее массовой и проблематичной темы.

2123

Книги, статьи и ресурсы / Re: Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд

« : 09 Марта 2007, 09:57:38 »

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

Что такое "Разработка приложения"?

Под анализом же здесь понимается процедура формирования решения. Т.е. решение синтезируется на основании анализа, а анализ преполагает детальное рассмотрение.

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

Вообще не стоит путать понятие дейтельности, артефактов с собственно с моделью.

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

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

....
Выделяются, обнаруживаются, понимаются, детализируются, то есть АНАЛИЗИРУЮТСЯ внешние события, нетипичные сценарии, исключительные ситуации, произовдится структуризация взаимодейстивия (что очень правильно, ибо на стади анализа предметной области такая структуризация будет только вредить и усложнять понимание, а на стадии анализа приложения - это уже внутреняя работа разработчика). Синтез никогда не происходит без анализа. Заметь у автора везде указывается: проверка того-то по тому-то, а проверка разве не есть анализ?

Прежде чем анализировать события, надо построить модель будущей системы, а потом уже анализировать.

Кроме того анализируется как раз НЕЧТО существующее, т.е. некоторое умозрительное представление

В момент описания будущей системы, умозрительного, достаточно хорошего представления системы ещё не существует.

2124

О Сайте и Форуме / Re: Переместить темы с книгами в раздел обучение

« : 09 Марта 2007, 00:39:27 »

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

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

Я начинал и продолжаю ратовать за разделение контента. Divide et empera. По поводу "не все только к Проектированию" - я уже объяснял, когда предлагал реструктуризацию файлового хранилища, что Объект помещается в категорию, к которой он наиболее Близок. Вот будет обсуждение Вигерса, Коберна, Лефингвелла, Якобсона, Овергаарда и т.д. - положим темы в форум "Требования", иначе получим в "Обучении" мешанину литературы.

2125

Книги, статьи и ресурсы / Re: Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд

« : 09 Марта 2007, 00:14:27 »

На мой взгляд авторы книги довольно четко проводят границу между анализом ПрОб и анализом приложения.

Да, эти виды деятельности в книге разделены, но обрати пожалуйста внимание, что я говорил не про ВИДЫ ДЕЯТЕЛЬНОСТИ, а про МОДЕЛИ.

В частности, в начале главы 13 "Анализ приложения" можно прочитать:

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

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

Вообще у меня есть серьёзные сомнения насчёт уместности термина "Анализ Приложения", о чём в принципе немного упоминают и авторы. Анализировать, на мой взгляд, можно только нечто существующее, как-то - Предметную область, Требования, Систему. Если же системы нет, она только создаётся, то можно её только синтезировать, проектировать, конструировать, но не анализировать.

2126

Вакансии / Re: Ищется проетировщик 2000$ ~ 50-55 т.р.

« : 06 Марта 2007, 15:20:09 »

За знание теории СУБД нужно как минимум 5k платить )

2127

Книги, статьи и ресурсы / Re: Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд

« : 06 Марта 2007, 12:14:02 »

В книге довольно четко указывается, что это не руководство по UML 2.0. Для этого имеет смысл смотреть книгу "великолепной тройки" с соответствующим названием. Направленность на UML 2.0 проявляется в некоторых деталях использования его возможностей в диаграммах классов главным образом.

Эдуард, ты зря оправдываешься за авторов, они не виноваты. Я только сейчас понял, что в исходном английском названии слова UML 2.0 вообще нет! ) Это маркетинговый приём издательства Питер на волне web2.0 и прочей фигни для создания эффекта новизны и актуальности! Поэтому у меня и произошёл такой когнитивный сбой - типа люди называют это 2.0, а ничего про специфику новой версии и её плюсы и достижения не пишут.

Так что? Это недостаток или достоинство книги?

Наличие глав про проработку концепции - это несомненный плюс.

2128

Для всех / Re: Цена методологии

« : 05 Марта 2007, 20:49:20 »

Мыльный пузырь - это образно. Мне например понятно, что продается, что и попытался объяснить. Другое дело надо ли его покупать, я в этом плане имел в виду "мыльный пузырь"

Мне кажется тут уместа аналогия с моделью Open Source, когда продукт бесплатен, а покупается поддержка, т.к. без неё промышленно использовать продукт непросто.

2129

Для всех / Re: Цена методологии

« : 05 Марта 2007, 19:59:55 »

Хм, приятно осознавать, что есть еще компании (в отличие от майкрософт), которые хоть что-то бесплатно позволяют использовать со своими продуктами 

К слову о стереотипах и мифах: Полный список бесплатных программ для Windows, разработанных Microsoft (150 штук)

2130

Для всех / Re: Цена методологии

« : 05 Марта 2007, 19:58:04 »

Для меня это вообще странно. В самом примитивном представлении RUP - всего лишь набор правил и пожеланий. Если директор компании купил книжку и выучил RUP, а на следующий день приходит и говорит своим сотрудникам: мы будем делать так то и так то, потому что советует дядя Буч.

Для меня тоже страно, м.б. это еще один мыльный пузырь, который продется.
Хотя с другой стороны все твои сотрудники должны ознакомиться с рекомендациями РУП, а они как раз продаются в виде сайта, а так же потом Вы должны использовать шаблоны, которые тоже платные, т.к. содержаться в поставке РУП. А вообще надо license agreement почитать, там обычно четко "что да по чем" сказано.

Люди, вы чего?? ) Какой мыльный пузырь? Весь мир движется от экономики индустриализма к экономике знаний. В случае RUP'а как веб-сайта и методологии продаются не какие-то продукты, а знания и экспертиза. Только RUP сам по себе практически малополезен, т.к. ну допустим вы прочитали всё и всё поняли, но как вы добъётесь, чтобы ваш процесс разработки хоть в ключевых местах напоминал RUP? В это нужно вложить немало сил, в результате этой деяетельности вы рано или поздно выйдете на приближённых к IBM Rational, и станете более благосклонны к их продуктам. Нет у вас таких средств - ну и ладно, дилеры не пропадут. А если есть/появятся - то вот вы тёпленькие, знакомые с терминологией и понимающие что к чему - маркетинговая программа реализована Это же стратегия shareware - нет денег, так хотя бы попользуйтесь, подсядьте (увеличьте mind share наших продуктов, методологий и решений), как появятся - сами к нам придёте, или на крайний случай  посоветуте тем, у кого они есть. Её используют и Misrosoft и Oracle и проч.