Сравнение различных подходов к формированию функ. требований к ИС(Прочитано 12360 раз)
Здравствуйте, сообщество!

У меня возник вопрос. В данный момент я заканчиваю бакалавриат, и тема моего диплома: "Сравнение подходов к формированию функциональных требований к ИС с использованием нотаций ARIS EPC и BPMN 2.0"

Собственно, в чем вопрос. Чем больше я читаю по теме, тем больше возникает ощущение, что я сравниваю совершенно разные вещи. Как я успел узнать, использование ЕРС - это "канонический подход", где на основе модели пишется SRS, а на его основе разработчики пишут код. В свою очередь, BPMN 2.0 - формат новой волны, где все модели могут быть напрямую конвертированы в исполняемый BPEL, и , как мне видится, САМИ МОДЕЛИ уже являются описанием требований, так как язык намного более формализован, нежели ЕРС.

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

Заранее спасибо!



Честно говоря, я вообще не понимаю, как с помощью нотаций можно формировать требования.

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



Вышеперечисленные нотации более ассоциированы с описанием бизнес- и иных процессов, которые как известно никакого отношения к требованиям, тем более функциональным, не имеют (достаточно взглянуть на определение что есть ТРЕБОВАНИЕ). Следовательно, утверждение, что "САМИ МОДЕЛИ уже являются описанием требований" - в данном контексте не верно. Более корректно вашу работу следовало бы назвать сравнением подходов к описанию бизнес-процессов, или бизнес-, информационной и системной архитектуры предприятия (в терминах TOGAF, например).

Утверждение - что модели бизнес-процессов это и есть требования возможно только в среде консультантов ERP систем, которые интерпретируют очень вольно термин "требование", и тем более функциональное требование. Но у них свой мир, и свой специфический "язык" с "перевернутой" с т.з. специалистов в области программной инженерии (см. SWEBOK) терминологией.

"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



А что, бакалаврский диплом в одиночку пишут теперь, без научного руководителя?



А что, бакалаврский диплом в одиночку пишут теперь, без научного руководителя?
Денис, я могу подозревать тут несколько ситуаций:
1. Руководитель обязательно есть, но он полностью передоверил выбор и формулировку темы своему студенту. Более того, руководитель может быть очень далек от интересов студента :)
2. Руководитель сам сформулировал эту тему студенту и, возможно, сам заблуждается в понимании  применения данных нотаций
3. Руководитель вообще не ориентируется в теме студента. К сожалению это встречается постоянно. Когда компетентность руководителя как говорится ниже плинтуса.
4. Студент заочник , см пункт 1.



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

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

Особенно понравилась формулировка "прошу разъяснить какие-либо вещи".



спасибо за комментарии! я решил несколько изменить тематику, теперь буду касаться больше аспекта моделирования.



Мне всегда казалось, что обучение - это процесс познания и эксперимента через самостоятельную и групповую работу под руководством наставника и без.
Почему нас просят выполнять работу студента или преподавателя, который за это получает зарплату - я не понимаю.
Я с тобой полностью согласен!



Еще раз к вам обращаюсь, дорогая аудитория!

А если, допустим, несколько перефразировать тему? Скажем, сравнение того, как та или иная нотация влияет/помогает в формировании функциональных требований?

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



Почему в названии должны обязательно фигурировать требования? Вы ведь сравниваете две нотации/методологии используемых преимущественно для моделирования БП. Т.е. до требований в вашем контексте 2 шага - сначала БП, потом на их основе - требования. А для разработки требований - фиолетово, в какой нотации были описаны БП, по большому счету.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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




 

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