751

Системный Анализ и Требования / Re: IEEE-STD-830-1998

« : 15 Марта 2007, 00:02:22 »

Э ... вот если честно встречал я перевод стандарта IEEE 830, мне как-то прислали. Я правда так и не удосужился посмотреть его ...

752

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

« : 14 Марта 2007, 23:54:29 »

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

Т.н. "Best practices" в области RDM в какой-то степени призывают давать ответы на эти вопросы. Например, даже в интсрументарии управления требованиями (в том же CaliberRM) есть predefined атриибут source, в котором обычно указывается источник требования -- либо stakeholder, либо некие праврвые акты и т.п. Кроме этого, если формулируются бизнес требования (и в частности бизнес-цели), то приводиться трассировка например пользовательских требований на бизнес-требования, тем самым показывая удовлетворению каких бизнес-требований (в общем случае) служит конкретное пользовательское требование и далее на функциональные требования.
Упущены или нет какие-то требования ... это вопрос можно интерпретировать двояко (в чем его прелесть :-)). С одной стороны это "не упщена ли какя-нить точка зрения на систему или некая характиристика, общая вообще для всех информационных систем". Для того, чтобы не упустить какие-то аспекты в такой постановке вопроса, следует придерживаться некой классификации требований. Классификация по сути дает различные взгляды на то, что из себя должна предствалять система. Некая классификация как правило ложится в основу стандартов на документацию требований, как структура разделов документов или набора документов. Другая интрепретация -- "а не упустили ли мы конткретное потребительское свойство системы", ну например, факт, что все кнопки должны быть зеленого цвета. Тут гарантий нет, и именно поэтому вся надежда на опыт аналитика и основательность заказчика.
Всегда стоит отдавать себе отчет, что требования это все-таки область с достаточно высокой энтропией, которая компенсирукется в т.ч. и за счет компетенций конкретных личностей.

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

Да, есть такие методоики. Они не дают 100% гарантии, как например использование генетического алгоритма не дает гарантии достижения абсолютного min. А дает good enough решение. Но с другой стороны, лучше иметь хоть какие-то методики, чем вообще никаких.

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

Такой риск он всегда остается. Но рулит принцип Парето, если нам удалось выявить те самые 20% которые обеспечивают удовлетворение 80% потребностей -- честь нам и хвала, и это можно считать заслуженным успехом. Ведь усложнять просто, а упрощать сложно.
Связь целей пользователя и "интересов заказчика" неплохо подает тот же Коберн, и вводит соотсветствующий слов в описание юзкейса. И он незря говорит что нужно помнить про защиту интересов стейкхолдеров в каждом юзкейсе. Другой вопрос что на практике не всегда удается "защитить интересы" ибо ИХ ПРОСТО МОГУТ НЕ ОСОЗНАВАТЬ или просто их не хотят по какой-то причине озвучивать (например политической).

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

Это может оказать влияние на требования supportability или на требование что некий усредненный пользователь должен затратить на освоение системы не более какого-то времени (usability)

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

Явно может повлиять на то же supportability наличие или отсутствие документации ... а если не дай бог эксплуатирующая организация/подразделение имеет SLA с бизнес-заказчиком? То уж точно потребуют схему БД и т.п. ...

753

Варианты Использования (Use Case) / Misuse Cases

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

Презентация Ian Alexander на тему "негативной" точки зрения при использовании юзкейсов. Может кому-то покажется интересной и полезной :-).
http://easyweb.easynet.co.uk/~iany/consultancy/misuse_cases.ppt

754

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

« : 13 Марта 2007, 22:21:32 »

тоже думаю быть :-).

755

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

« : 10 Марта 2007, 00:32:28 »

Это был мой пост

756

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

« : 09 Марта 2007, 16:32:38 »

Про одновременное использование UML и IDEF. могу рассказать. Мы так делаем. Просто по тому, что если надо описать процесс движения документов и информации. На одну диаграмму IDEF помещается 6 процессов и пара-тройка десятков ресурсов и связи. Если испольнителей (механизмов) под 10 и 20 документов, то при попытке нарисовать то же самое в UML с использованием диаграммы анализа или activity она становится абсолютно нечитаемой.

10 исполнителей и 20 документов... Речь идет о том, что видимо 20 типов документов у каждого из которых свой маршрут/ЖЦ/workflow или еще что.
Почему не подходит метод, который рекомендует та же Золотухина использовать для activity диаграмм со сложным процессом (см. тут http://www.interface.ru/fset.asp?Url=/misc/uml1.htm)?

757

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

« : 09 Марта 2007, 12:17:13 »

http://sql.ru/forum/actualthread.aspx?tid=404641&hl=%ef%f0%ee%e5%ea%f2%e8%f0%ee%e2%f9%e8%ea
Вот очень-очень похожая вакансия. Может, даже та же самая.
Юрий! Я не претендую на всеобщее знание, но могу рассказать, как это бывает.

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

Я говорил не про то что плохо делать в Visio UML или IDEF, а полхо когда эти нотации используют "в стиле Visio", т.е. например, пытаются диаграммой вариантов использования показать последовательность действий (грубый пример, но думаю разъясняет о чем я речь веду).
Никто не говорит, что плохо использовать нотации ... вопрос в том, что если используются одновременно и IDEF и UML, то возникеют вопрос ПОЧЕМУ (или "зачем"), и чем не угодила одна из них (при отсутствии контрактных ограничений)?

[quot]
Спецификация для разработчиков... Вы знаете, смотря кто разработчики и смотря что имеется ввиду под спецификацией. Может это просто список вариантов использования или функций - выжимки из ТЗ.
[/quot]

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

758

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

« : 09 Марта 2007, 11:58:31 »

Эд, мне кажеться что есть некоторый замкнутый круг. Именно разорвать его я всегда пытаюсь работая с конкретной организацией и ее проектами как консультант. Это означает, что я не просто даю советы, а внедряю эти рекомендации в практику организации -- т.е. моя работа не заканчивается просто созданием документов (естественно если заказчика инетерсует именно практический результат).  Ты поставил вопрос как достаточно общий, можно столь же общё дать на него ответ .. но этот ответ будет ни чем иным как теми же фразами, которые можно и так прочесть в книгах, а значит скорее всего, это не много добавит ценности (IMHO) людям, которые работают на конкретных проектах, и которых есть конкретные вопросы. Отсюда и получается, что add value рекомендация может быть в контексте конкретного проекта и его ограничений.
А для того чтобы показать спектр частных решений, нужно их сформулировать. Я по мере возможности даю комментарии в разделе форума где приводятся конкретные решения.

759

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

« : 08 Марта 2007, 16:53:56 »

Участникам форума - Юрию и Сергею в первую очередь - есть вполне очевидное направление:
А. описание (краткое ясное без слюней) методик и методологий проектирования (RUP, EUP, Agile анд аверз)

Оно есть в самих методологиях, зачем это пережовывать? Другой вопрос как это применять ... тут уже it depends от конкретной ситуации.

B. более детальное описание, рекомендации по этапам и позициям процесса.
1. когда и зачем делаем бизнес-анализ

Когда делается? Ответ простой ... когда в этом есть необходимость. Зачем? Если нам нужно а) реинженирить бизнес б) автоматизировать бизнес о котором мы мало что знаем ...

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

Вопрос "фисолофический" :-) ... не понятно например, как бизнес-требование "увеличить количество обработанных заявок в среднем на 10% по сравнению <с др. периодом/до автоматизации  и т.п.>" может появиться на уровне требований к системе? Только если по незнанию его туда затащить в раздел нефункциональных требований искренне веря, что это и есть требование к производительноси системы :-).
Есть стандартный набор методов извлечения требований ... IMHO самый распространенный это изучение регалментирующих документов и интервьюирование ... об этом тоже уже написано у того же Вигерса.

3. всегда ли требуются требования к системе? какие системы нуждаются в анализе требований, а какие нет.

Чтобы слепить горшок нужно хотябы предствить себе какой он будет по емкости, по габаритам и т.п. ... требования нужны всегда, я ТАК думаю :-).

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

it depends ... зависит от конкретного проекта и его окружения. ... универсального ответа я не знаю .... (хотя вру, "it depends" тянет на универсальный ответ :-))

5. когда и почему можно вообще обойтись без понимания структуры классов, как накладывать результаты моделирования на конкретные системы программирования (скажем Дельфи, где все объекты так или иначе наследники TObject)

Зависит от целей ... в процедурном программировании например нет вообще классов.

6. какую пользу дают диаграммы состояний - как они практически трансформируются в практическое решение?

дают например в случае систем документооборота ... сотстояния конкретного типа документа и т.п.

9 Что такое трассировка требований, как ее правильно проводит, как она проявляется на практике.

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

10. Есть ли четкие теоретические основы практики моделирования - или они основаны на наблюдении и эмпирическом опыте?

Посмотри например сайт Scott Ambler ... и его книги про agile ... там думаю подчерпнешь много не эту тему :-).

а посты нужно уже в другие ветки переносить ... т.к. явно не про работу.

760

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

« : 07 Марта 2007, 23:07:17 »

Не RUP-ом единым ... никто не говорит, что нужно адаптировать именно RUP. И на самом деле я не являюсь таким уж ярым адептом RUP :-). Да, я на самом деле имею предствление о том что такое RUP. Но я имею предстваление и о других методологиях и стандартах. И естественно я не стану рекомендовать адаптировать RUP, в случае, если заказчику нужно просто создавать документацию требований :-) и управлять изменениями. Да, можно рекомендовать некоторые практики которые описаны в т.ч. и  в RUP. Кроме этого, кто сказал что RUP не масштабируется на команду из 3 человек???
Второй момент, если в компании действительно поставлен процесс, и проекты большие .. то такое объявление врядли появиться. Но возможна и другая ситуация ... контора маленькая, и нужен универсальный солдат, который будет ВСЕ это делать. Но позвольте, если проект маленький ... НА КОЙ ТАКАЯ ФОРМАЛИЗАЦИЯ? Это не оправдано в таких проектах (имеется ввиду например проектирование визуальных форм на UML) и документация -- "спецификация для разработчиков". Да, можно еще одно предположение в оправдание такой формализации сделать, что разработчики на аутсорсинге или удаленно работают. Но это врядли.
Более реальна ситуация (опять-таки это только мое предположение "сидящего в кресле с Хэнесси и сигарой умника") когда действительно используется весь этот зоопарк (IDEF, UML) или людям совершенно бЭз разницы на чем будут "нарисованы бизнес-процессы", т.е. обчный бардак :-), когда просто заказчику пудрят мозги, типа "смотрите какие мы крутые картинки рисуем".
Я насмотрелся на такое .. видел я типа ТЗ, с картинками на UML ... только value от них небольшое. Просто как обычно удовлетворение амбиций начинающих изучать UML и пихающих его куда ни попадя, т.к. нет достаточно четкого предстваления о том как методически правильно его использовать (сам через это прошел ;-) в свое время).

761

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

« : 07 Марта 2007, 11:25:51 »

Да уж, торкнуло, реально ... просто я вчера несколько злой был. Приехал в одну контору (правда опоздал на встречу на 30 минут, каюсь -- пробки мать их ... еще не разу в этом году 2 часа не добирался автобусом до ВДНХ самое долгое было 1,20) а там  народ вопрошает меня про возможности одного инструментального средства для RDM. Я у них спрашиваю, расскажите хотябы как вы работаете, как и для чего хотите использовать. Они в ответ ... мы вот о CMMI думаем, об уровне 2 (!!!!). Я им поясняю -- типа отлично ребята, но я не продаю лицензии на инструментарий, а мои деньги -- это сервисы вокруг него, процессы, тренинги ... Вот и говорю, расскажите как вы работаете и для чего собираетесь инструмент пользовать ... чтоб я мог подсказать какие-то моменты.
На что получаю интересный, но контрпродуктивный ответ "типа рассказывай, а мы если что спросим" и фраза, которая меня УБИЛА напрочь ... "мы вам тут расскажем, а вы пойдете и будете это применять в других компаниях". Я даже растерялся что ответить, чтобы не обидеть людей ... ведь ЕСЛИ РЕЧЬ ИДЕТ ТОЛЬКО О ВЫХОДЕ НА 2 уровень CMMI, ТО КОМУ ИНТЕРЕСНЫ ТАКИЕ ПРОЦЕССЫ (а точнее их отсутствие), когда половина контор стремится на 3-й прыгнуть? Другой вопрос если бы они на CMMI 5 метили с 3 или 4, я бы не обиделся :-).
Результат общения был предсказуем ... одна леди, которая как раз и говорила что типа рассказывай а мы спросим, заявила что она ничего не поняла. Напрасно я вещал им про то что такое вообще требования и в чем отличие использования иструментария от документно-центричного подхода :-). Что и логично ... Ну неужели настолько все плохо с процессами в конторе, что боятся другим поведать как они работают, даже В ОБЩЕМ ВИДЕ ... ? Хотя нужно отдать должное одному из участников встречи -- который похоже был в теме инструментария и процессов. Он единственный задавал вопросы грамотно ...

762

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

« : 07 Марта 2007, 00:17:39 »

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

Требования: Знание UML, IDEF0, DFD, IDEF3. Умение правильно создавать UseCases.
Умение работать с Rational Rose, ERWin, BPWin, Visio.

На самом деле достаточно сложно быть одинково компетентным и в IDEF и в UML, но более интересно другое ..неужели это все действительно используется, и притом профессионально а не "в стиле Visio"? Кроме этого, зачем использовать разные нотации, проще все на одном языке делать.

Втрой момент, умение ПРАВИЛЬНО создавать UC. Что есть "правильно"? UC это текстовые спецификации имеется ввиду или таки диаграммы UML? Если текстовые спеки, то это работа роли Аналитик, а использование IDEF0, IDEF3 -- это вчистую бизнес-процессы, т.е. грубо тянет на роль бизнес-аналитик.

Знание систем контроля версий и учета замечаний.

Конечно вопрос в каком объеме ... и КАКИХ систем ... ClearCase конфигурить -- это одно, а SourceSafe - другое ... И issue trackers, они тоже разные бывают. Может конечно сформулировано требование к skills некорректно ... а требуется всего лишь опыт пользовательской работы с таким инструментарием (опять-таки, с каким?). Но если конфигурить и еще и процесс имплементировать на них, то это имеем другую роль -- Менеджера конфигураций.

Знание теории СУБД.
Опыт работы с Oracle и Delphi.

Хм ... писать на таком RAD как Delphi (интересно, а он лицензионный? ... я уж про BPWin, ErWin и Rose и спрашивать боюсь :-)) и активно использовать UML ... хотел бы я взглянуть как это происходит, а то есть сомнения ...

Обязанности: Проведение обследования
Выявление требований

О! это точно вам нужен не проектировщик, а Аналитик ... не всякий проектировщик может выявлять требования и быть хорошим коммуникатором.

Описание бизнес-процессов

Хм, я бы это поставил перед выявлением требований ... хотя еще вопрос что принято понимать под БП в этой компании.

Первичная модель БД

Чесслово не понимаю что это ... я всегда думал что есть логическая и физическая модели БД .. ну век живи ... Но это уже ближе к Проектировщику!

Первичная разбивка на модули
Первичное определение прогр.интерфейсов модулей

О .. тут уже попахивает программной архитектурой :-)

Дизайн визуальных форм

Чесслово приходится догадываться что имеется ввиду! Юзабилити? Хочется верить что это именно так, ибо сложно себе предстваить что вы ДЕЙСТВИТЕЛЬНО в UML расписываете ВИЗУАЛЬНЫЕ ФОРМЫ ... это достаточно трудоемко и толку от этого немного. Особенно если они меняются часто .. поддерживать их актуальность в UML еще та работка.

Написание техпроекта по стандартам фирмы

Ох уж эти "стандарты фирмы" ... помесь RUP и ГОСТ :-) ... коктейль молотова.

Написание первичной прграммы тестирования

О ... а это уже роль Тест-инженера!

Составление спецификаций для программистов
Участие в рассмотрении замечаний и в их назначении.

Уфф ... просто какой-то универсальный солдат нужен! .. толкьо что его еще и код писать не заставляют. И всего-то за 2000 баксов ... такие деньги обычно аналитику, который ТЗ пишет и не береться проектировать софт ... а вы хотите чтобы и швец, и жнец ...
Общий вывод, если это сообщение не написано только HR-ом .. то встает вопрос об уровне зрелости процессов такой компании и вообще компетенции в области процессов программной инженерии ...
Ребята, я серьезно ... давайте я вам процессы поставлю, чесслово возьму вполовину меньше сумму, чем беру обычно .. ! И тогда вы сможете писать осознанно какие специалисты и с какой экспертизой вам ДЕЙСТВИТЕЛЬНО нужны.

763

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 05 Марта 2007, 19:12:20 »

Если нет контрактных ограничений на формат документации требований, то я предпочитаю для нового проекта сначала написать Vision, где явно сформулировать какие бизнес-проблемы будут решены этим проектом (суть бизнес-требования), описать стейкхолдеров и софрмулировать основные фичи системы. При "идеальном" проекте, провязываются фичи с бизнес-требованиями. Рисуем контекстную диаграмму, чтобы определить опять-таки общие границы. И озвучиваем предположения которые делаем, вместе с ограничениями и обещаниями (по срокам, например)
Далее -- юзкейсы (если они применимы). Степень детализации зависит от конкретного проекта. Когда очень поверхностно, просто чтобы зафиксировать concept of operations, но тогда в SRS делаем более детальную проработку на уровне функциональных требований. А когда и достаточно детально, тогда имеет смысл использовать Supplementary Spec. а не SRS. А иногда, если и так все понятно ;-), ограничиваемся только юзкейсами. Повторюсь, что зависит от конкретного проекта.

764

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 05 Марта 2007, 18:59:11 »

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

765

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 05 Марта 2007, 14:08:59 »

Самым "сложным" случаем с т.з. процесса документирования требований будет такой, когда есть заказчик который трубует документацию требований в определенном формате (например по ГОСТ 34.602) а у компании-разработчика свои стаднарты (например те же UC и иже с ним). В этом случае нужно формировать документацию требований по ГОСТ из тех требований, которые создаются самими аналитиками компании-разработчика. Тут вариантов 2 либо делать требования в классическом иерархическом виде, что маппится 1 в 1 на ТЗ по ГОСТ, либо впихывать в ТЗ по ГОСТ (или в разные наборы документов по ГОСТ) юзкейсы и иже с ним. При всем при этом крайне желательно пользоваться каким-либо инструментарием и поддерживать синхронизацию изменений в обоих артефактах. Идеальный случай, когда требования ведуться в неком репозитории и документация создается автоматически.
Что касается использования юзкейсов -- то формально говоря, это пользовательские требования (по тому же Вигерсу). С другой стороны, в них содержится и собственно информация о том, какая функциональность должна быть в системе. Но формально говоря, (с т.з. формального определения из глоссария IEEE что есть требование) это <> функциональным требования. Т.е. UC это контейнер для функц. требований по большому счету. Да, можно описать достаточно подробно юзкейсы с дополнительными слотами, где учесть и некоторые нефункциональные требования, которые "привязаны" к данному UC. И для целого ряда систем этого будет достаточно для проектирования системы. Но следует помнить и тот факт, что не всегда удается описать юзкейсами всю нужную ФУНКЦИОАЛЬНОСТЬ системы. И это одна из причин почему их относят таки к ПОЛЬЗОВАТЕЛЬСКИМ требованиям. И даже если взглянуть на RUP, то там в Supplementary Spec. есть отдельные слоты для описания ФУНКЦИОНАЛЬНЫХ требований, которые не были охвачены юзкейсамы.