Форум Сообщества Аналитиков

×


Рекомендации по анализу(Прочитано 20861 раз)
Рекомендации по анализу : 08 Марта 2007, 13:32:33
Интересно, автор объявления как-то прокомментирует тут фантазии завсегдатаев форума?

Участникам форума - Юрию и Сергею в первую очередь - есть вполне очевидное направление:
А. описание (краткое ясное без слюней) методик и методологий проектирования (RUP, EUP, Agile анд аверз)
B. более детальное описание, рекомендации по этапам и позициям процесса.
1. когда и зачем делаем бизнес-анализ
2. чем отличаются бизнес-требования от требований пользователя требований к системе, когда одно и тоже описание требования может фигурировать на разных уровнях под разными типами, почему. Какие методики сбора требований существуют, чем они отличаются, как реализуются, когда их следует использовать и почему
3. всегда ли требуются требования к системе? какие системы нуждаются в анализе требований, а какие нет.
4. с чего следует начинать анализ предметной о области: сначала понять требования или сначала построить структуру Пр Об, почему в одних случаях можно начать сразу с диагарммы классов, а в другом лучше пройти этап сценарии ВИ, диаграмм взаимодействия, а потом диаграмм классов
5. когда и почему можно вообще обойтись без понимания структуры классов, как накладывать результаты моделирования на конкретные системы программирования (скажем Дельфи, где все объекты так или иначе наследники TObject)
6. какую пользу дают диаграммы состояний - как они практически трансформируются в практическое решение?
7. кому и когда и чем полезна та или иная диаграмма, что помимо единого понимания системы дают все эти диаграммы.
8 насколько каждая диаграмма полезна, каково ее реальное время жизни, т.е. какие диаграммы следует считать вспомогательными, а какие основными - скажем так системоописательными. Насколько вообще следует уделять внимания на документирование моделей.
9 Что такое трассировка требований, как ее правильно проводит, как она проявляется на практике.
10. Есть ли четкие теоретические основы практики моделирования - или они основаны на наблюдении и эмпирическом опыте?



Рекомендации по анализу Ответ #1 : 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 ... там думаю подчерпнешь много не эту тему :-).

а посты нужно уже в другие ветки переносить ... т.к. явно не про работу.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Рекомендации по анализу Ответ #2 : 09 Марта 2007, 09:29:59
Цитировать
а посты нужно уже в другие ветки переносить ... т.к. явно не про работу.
Юра, я не предполагал, что ответ будет в этом посте.

Спасибо за интерес к теме, но так просто тебе не отделаться:-))

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

Я понимаю It depends - такая сладкая формула. Понятно что нет общих универсальных решений, но есть спектр частных решений. Нет нужды приводить все возможные решения, но можно обсудить типичные. Умному достаточно!!!

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

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



Re: Рекомендации по анализу Ответ #3 : 09 Марта 2007, 11:58:31
Эд, мне кажеться что есть некоторый замкнутый круг. Именно разорвать его я всегда пытаюсь работая с конкретной организацией и ее проектами как консультант. Это означает, что я не просто даю советы, а внедряю эти рекомендации в практику организации -- т.е. моя работа не заканчивается просто созданием документов (естественно если заказчика инетерсует именно практический результат).  Ты поставил вопрос как достаточно общий, можно столь же общё дать на него ответ .. но этот ответ будет ни чем иным как теми же фразами, которые можно и так прочесть в книгах, а значит скорее всего, это не много добавит ценности (IMHO) людям, которые работают на конкретных проектах, и которых есть конкретные вопросы. Отсюда и получается, что add value рекомендация может быть в контексте конкретного проекта и его ограничений.
А для того чтобы показать спектр частных решений, нужно их сформулировать. Я по мере возможности даю комментарии в разделе форума где приводятся конкретные решения.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Рекомендации по анализу Ответ #4 : 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, ясное дело).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Рекомендации по анализу Ответ #5 : 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)?
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Рекомендации по анализу Ответ #6 : 09 Марта 2007, 21:39:37
Спасибо, коллеги, за живой интерес к дискуссии. Ставя ряд вопросов, я, конечно, что раз - и мы получем нечто емкое и понятное.
Ясно, что сейчас все определяется конкретикой решения задач. Давайте пытаться решать конкретные задачи. Это как при изучении чего-то нового, когда ничего или очень мало известно. Изучение идет эмпирическим путем, идет накопление фактического материала. Тот кто его накаплаивает, может сам далеко его не понимает, но вдруг находится ясная и свежая голова, зрящая прямо в корень, видящая суть.
Я в свое время, выполняя частные проекты, связанные с торговлей. , неожидано понял для себя, что решение задач поставленных передо мною может быть распространено и на другие задачи - явно с торговлей не связанных, но также имеющие общие функции учета прихода чего-то, расхода чего-то, утилизации и реализации. В результате удалось, используя схему, решения для торгового предприятия распространить на кадровые службы, библиотеку, документооборот официальной документации на кафедре.

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

Вот еще пример. У нас в вузе эксплуатируется система "Студент". БД реализования на mysql, приложение на Access. Исходная реализация предложена человеком далеким от программирования как такового в то время, скорее большим любителем. Однако не плохо. На смену ему пришел человек, который в прошлом был любителем basic. С большим воодушевлением он стал дорабатывать систему, адаптировать ее и совершенствовать. Сейчас во все деканат система вндерена и признана ректором эталоном и приказом объявлена единственно возможной.
В личной беседе я пытался узнать существует ли какая-то общая концепция, структура системы, и т.п. Оказалось нет. Я намекнул на некоторый риск такой системы - система авторская и поддерживается и развивается только при наличии автора.
Предложил услуги реинжиниринга, составления описания системы. Получил отказ - всем система нравится, она внедрена, переделки не требует, возможно требует дополнительного функционала.
В данном случае - очень показательно - инициирование процесса переработки должно идти сверху, а не снизу. Правило уяснилось, "нечего вперед батьки в пекло лезьти".

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

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



Re: Рекомендации по анализу Ответ #7 : 10 Марта 2007, 00:31:37
Можно сказать, что у каждого свой маршрут, но интересно именно переплетение маршрутов, составляющее единый процесс.
Можно нарисовать во многих пригодных нотациях. Но activity c 10ю свимлайнами +4 под типы ICOM необозрима - проверено практикой. Каждая нотация хорошо работает в своем случае.

Не совсем понятно почему отождествляется IDEF0 и activity диаграмма UML. Тогда уж IDEF3 нужно сравнивать. Да и я как-то с трудом себе предстваляю как на IDEF0 можно увидеть переплетение маршрутов ...



Re: Рекомендации по анализу Ответ #8 : 10 Марта 2007, 00:32:28
Это был мой пост
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Рекомендации по анализу Ответ #9 : 10 Марта 2007, 11:55:33
Не совсем понятно почему отождествляется IDEF0 и activity диаграмма UML. Тогда уж IDEF3 нужно сравнивать. Да и я как-то с трудом себе предстваляю как на IDEF0 можно увидеть переплетение маршрутов ...

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



Re: Рекомендации по анализу Ответ #10 : 10 Марта 2007, 17:04:47
Хочу опубликовать некоторый материал на тему системного анализа. Как я полагаю, системный анализ в нашем случае основа всех последующих рассуждений, а также понимания всего процесса реализации системы или ее части в целом.

Существуют множество различных определений системного анализа. Но так или иначе все они сводятся к одному: системный анализ - методология решения проблемы.
Вот что по этому поводу пишет в свойе книге "Системный анализв в управлении" Анфилатов и др.

"
В процессе создания информационных систем стремятся к наиболее полному и объективному представлению объекта автоматизации – описанию его внутренней структуры, объясняющей причинно-следственные (казуальные) законы функционирования и позволяющей предсказать, а, следовательно, управлять его поведением. Одним из условий автоматизации является представление объекта в виде сложной системы.
 
Существует несколько подходов к описанию сложных систем. Наиболее общим является теоретико-множественный подход, при котором система S представляет собой отношение S < X х Y, где Х и Y – это входные и выходные объекты. Предполагается, что задано семейство множеств Vi, где i е I (множество индексов) и система задается на Vi как некоторое собственное множество декартового произведения, все компоненты которого являются объектами системы. Такое определение ориентировано на исследование общих свойств системы и лежит в основе общей теории систем.

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

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

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

"

Этапы использования системного анализа и его структуру можно описать так

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

Основные задачи системного анализа могут быть представлены в виде трехуровневого дерева функций.
На этапе декомпозиции осуществляется:
1.   Определение и декомпозиция общей цели и основной функции для ограничения траекторий пространства состояний системы или области допустимых ситуаций. Декомпозиция проводится путём построения дерева целей и функций.
2.   Выделение системы из среды по критерию участия каждого рассматриваемого элемента в процессе, приводящем к результату (результат определяется целью).
3.      Описание воздействующих факторов
4.      Описание тенденции развития неопределенностей
5.      Описание системы как черный ящик
6.      Функциоанльная композиционная и структурная декомпозиция.

На этапе анализа осуществляется:
1.   Функционально-структурный анализ. Он включает уточнение состава и законов функционирования элементов, алгоритмов функционирования и взаимовлияния подсистем, разделение управляемых и неуправляемых характеристик, задание пространства состояний Z, задание параметрического пространства T, анализ целостности системы, формирование требований системы.
2.   Морфологический анализ заключается в анализе взаимосвязи компонентов.
3.   Генетический анализ – анализ предыстории, развития ситуации, тенденций, причин их вызывающих, прогнозирование.
4.   Анализ аналогов.
5.   Анализ эффективности включает выбор шкалы измерения, формирование показателей эффективности, критериев эффективности, оценивание и анализ полученных оценок.
6.   Формирование требований к создаваемой системе включает выбор критериев оценки и ограничений.

На этапе синтеза:
1.   Разработка модели – выбор математического аппарата, моделирование, оценка модели по критериям адекватности, простоты, соответствия и т. д.
2.   Синтез альтернативных структур системы, снимающих проблемы.
3.   Синтез параметров системы, снимающих проблемы.
4.   Оценивание вариантов синтезирования систем, обоснование схемы оценивания, реализация модели, проведение эксперимента, обработка результатов, анализ результатов и выбор наилучшего варианта. Оценка степени снятия проблемы проводится при завершении системного анализа.


"

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

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

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

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

Вопрос - можно ли рассматривать отдельную сторону такой системы независимо, если можно, то как это определить?

Пример из моей научной практики.
Хорошо известно, что газоразрядная плазма пониженного давления представляет пример сильно неравновесной системы.
Неравновесность в первую очередь обусловлена принципами передачи энергии между частицами. В электрических разрядах передача энергии от внешнего поля происходит посредством ускоренных электронов. Электроны передают свою энергию более тяжелым частицам (молекулам и атомам) в упругих, неупругих и сверхупругих столкновениях.
За счет этого, состояние плазмы не определяется тремя классическим величинами : температурой, давлением и объемом, а определяется особой величиной - приведенной напряженностью электического поля.
При моделировании и изучении такой системы принято разделять ее на подсистемы: подсистема электронного газа, подсистема диссипации колебательной энергии молекул, подсистема химической кинетики, подсистема температурного поля.
В реальной системе все эти подсистемы взаимосвязаны: одна влияет на другую - а мерой однозначного поведения часто выступает величина приведенной напряженности поля. При решении задачи моделирования принято решать так называемую самосогласованную задачу: т.е. решение представляет собой эволюцию системы от некоторых начальных условиях по заданным законам (которые порой и не известны) Кореектность моделирования проверяется опытным путем, на базе большого эмпирического материала и наблюдений.
Однако решение задачи самосогласования в общем - очень сложная задача, при этом обнаруживается, что влияние отдельных подсистем мало заметно при некоторых ограниченных условиях, что позволяет рассматривать общую задачу изолированно. Т.е. отдельно моделируется поведение электронного газа, отдельно колебательного континуума, отдельно химической кинетики с последующим синтезем решений.

В случае практики построения систем, мы часто имеем
А - имеющуюся ситуацию
Б - требуемое состояние
Общая цель - создать систему или разработать программу управления системой позволяющую перевести нас из состояния А в состояние Б.

Цель научного изыскания - определить возможность такого процесса или его невозможность

Цель инженерной практики - определить наименее затратный путь достижения ситуации Б.

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

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

PS. Кстати давно запущена, но никем неоткомментирована задача по деканату. Может есть желающие обратить на нее внимание и использовать в качестве примера?




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19