1

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

« : 22 Мая 2013, 16:51:26 »

И ментальные модели, сформировавшиеся у людей, привыкших или обученных разрабатывать "автоматизированные системы", приводят к их осознанному или неосознанному сопротивлению

Во-во, мой мозг сейчас активно сопротивляется 

Давайте заново, а то я запутался... Итак, говорим о классификации требований. Есть модель Вигерса, есть ГОСТ 34.602. Вигерс хорошо рассказывает, какие требования бывают и как их добыть, ГОСТ говорит, как должно быть оформлено ТЗ. Очевидно, что Вигерс на ГОСТ просто так не ложится, но иногда надо (например, госконтракт). Выше я предложил одну из схем, по всей видимости неудачно, но все же. Далее две точки зрения: 1. ГОСТ умер, 2. ГОСТ жив. Основные тезисы первой точки зрения (поправьте, если неправильно понял):
1. ГОСТ не определяет порядок разработки требований.
2. ГОСТ не определяет модель требований.
3. ГОСТ ничего не знает про требования пользователей, юзкейсы, ДВИ и т.д.
4. ГОСТ не предлагает широкий выбор моделей жизненного цикла АС.
5. ГОСТ говорит только о функциональных требованиях.

Тезисы второй точки зрения (ГОСТ жив):
1. ГОСТ предусматривает отдельную стадию для формирования требований к разрабатываемой АС. Как именно это будет происходить дается на откуп специалистам.
2. Какая-то модель требований в ГОСТ все же заложена, структура ТЗ об этом недвусмысленно намекает. Отдельно про модель нигде не говорится, потому как в то время отсутствовала необходимость (или осознание необходимости) управлять этими требованиями. Написали ТЗ и все, вперед делать. И стоит отметить, делали-то на совесть, до сих пор все работает! Еще один момент: ГОСТ предусматривает изменение/дополнение ТЗ (путем разработки доп.ТЗ, ЧТЗ), чем вам не итерационный подход? при этом нигде не говорится, сколько должна длиться одна итерация, может 10 лет, а может месяц. На этапе разработки доп.ТЗ проводится анализ требований (а как без этого), но каким способом - на усмотрение специалиста.
3. Есть три уровня требований: бизнес, пользовательские и функциональные + нефункциональные требования. Система строится по требованиям низкого уровня (функциональным требованиям) + нефункциональным требованиям, остальные 2 уровня требований нужны чтобы получить (и обосновать) этот 3-й уровень. Да, в ГОСТе нет такого деления, но что мешает его использовать? Функциональные требования в ТЗ по ГОСТ нужно как-то обосновывать, почему бы это не сделать при помощи ВИ? я не встретил явного запрета.
4. ГОСТ предлагает перечень стадий и этапов разработки АС, при этом ГОСТ 34.601 гласит: "Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ". Таким образом, путем варьирования предложенных стадий и этапов можно реализовать практически любую модель жизненного цикла и ГОСТ это разрешает. Главное с заказчиком потом все это согласовать 
5. ГОСТ явно не проводит деление требований на группы (классификацию), но нефункциональные требования он не обходит стороной. Так в ТЗ есть такие разделы, как Показатели назначения, Требования надежности, безопасности и т.д. Как их родить он не говорит, но его ли это задача?

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

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

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

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

Вобщем, не убедили вы меня 

2

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

« : 22 Мая 2013, 14:39:59 »

Ага, а АС состоит из "персонала и комплекса средств автоматизации его деятельности и реализует информационную технологию выполнения установленных функций."

Проблема в том, что на это определение никто не обращает внимания, а оно определяет границу применимости модели, заложенной в ГОСТе

Извините, не понял, к чему это вы? Мне всегда казалось, что это одно из самых правильных определений в сфере ИТ 

Является ли посетитель интернет-магазина "персоналом системы"?

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

Если мы будем разрабатывать этот магазин по ГОСТу, то получим в результате "АРМ покупателя". С кнопками, отчётами, языками ввода-вывода данных, инструкцией по эксплуатации и т. п.

А вот тут что посадите, то и вырастет. Хотите получить АРМ, будет у вас АРМ. А хотите получить распределенную информационную систему с архитектурой "клиент-сервер" - формулируйте соответствующие требования. Опять же, что значит выражение "разрабатывать систему по ГОСТу"? Насколько я знаю, нет отдельных ГОСТов на интернет-магазины, системы складского учета и т.д. Есть ГОСТы на документы, есть ГОСТ на стадии разработки и т.д.

3

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

« : 22 Мая 2013, 13:53:34 »

Стойкое мнение есть именно потому, что для АС есть ГОСТ, который легко изучать и преподавать.

АС (автоматизированные системы) есть одна из двух разновидностей информационных систем. Т.е. по классификации ИС делятся на автоматизированные и автоматические. Поскольку множеством автоматических систем можно пренебречь, то получается, что ИС=АС.

4

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

« : 22 Мая 2013, 11:16:16 »

Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют На самом деле, очень интересно посмотреть.

Давайте может тему создадим в примерах? я бы с удовольствие поупражнялся, но хочу предупредить заранее, что я далеко не аксакал   

у нас студенты, а их кто-то учит (не я правда) делают ВИ в ходе техно-рабочего проекта.

типичная ситуация для проекта, в котором 1-я стадия - это ТЗ, никакого обследования, никакого вникания в предметную область... Написали общих фраз и начали проектировать  Конечно, ничего другого не остается, как разрабатывать ВИ в ходе технического проекта.

Вопрос, а зачем так делать? Имхо получается какая-то лишняя работа

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

5

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

« : 22 Мая 2013, 10:59:32 »

Это просто Ваша интерпретация ГОСТ, поэтому Вы конечно же можете быть несогласны с моей интерпретацией, это нормально.

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

Можно посмотреть РД 50-34.698-90, где описана структура отчета, который выпускается на данной стадии, там как-то не очень про требования пользователя богато сказано - порождает еще больше вопросов....

Есть в этом отчете раздел Раздел "Функции и задачи создаваемой АС", который содержит.
•   1) обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения,
•   2) требования к характеристикам реализации функций и задач в соответствии с действующими нормативно-техническими документами, определяющими общие технические требования к АС конкретного вида;
•   3) дополнительные требования к АС в целом и ее частям, учитывающие специфику создаваемой АС.
Что вам мешает обосновать этот перечень функций путем использования вариантов использования Системы? ГОСТ не определяет методику формирования требований, он оставляет это на откуп аналитику, а там уже кому как нравится. Хочешь используй это, хочешь это... И это правильно.

Более того, в ГОСТ вообще НИГДЕ не определено, что понимается под "требованиями пользователя", если мне не изменяет память... Я, например, с таким же успехом могу интерпретировать это таким образом, что под требованиями пользователя в ГОСТ понимается тот набор features, которые должны быть в создаваемой системе. А строго говоря features - это не пользовательские требования по Вигерсу ... Тут полет фантазии у нас ничем не ограничен :-).

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

Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602

ИМХО это проблема тех.писателей, а не ГОСТа

Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ...

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

6

О Сайте и Форуме / Re: Рубрика: Люди

« : 21 Мая 2013, 16:33:38 »

А если я:
1. не провожу никакой связи между своей фамилией и уважением или неуважением к кому-либо или чему-либо
2. не уважаю свою родню
3. ношу не свою фамилию

тогда какое отношение ко мне имеет все сказанное вами? )

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

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

7

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

« : 21 Мая 2013, 16:12:10 »

Оформлением ТЗ по ГОСТу должны заниматься опытные техписы-крючкотворы, которым нужно платить высокую зарплату и отправлять на хорошую пенсию досрочно из-за вредности их работы

Ура!!! у меня будет хорошая пенсия!!! а проездной на метро дадут бесплатно? 

На самом деле не пойму, чем же вам так ГОСТы не нравятся... Они прекрасно справляются со своей задачей. Вот не встречал я в жизни доку лучше, чем гостовская (конечно, при условии, что тех.писатель толковый). Другое дело нормоконтроль - вот это правда беда... но отнюдь не ГОСТов. 

8

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

« : 21 Мая 2013, 15:13:28 »

А это финальный слайд моего выступления на РИТ++. Смиритесь.

Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение 

9

О Сайте и Форуме / Re: Рубрика: Люди

« : 21 Мая 2013, 15:03:19 »

Возражу 
Фамилия - это наследственное родовое имя (Wikipedia), имя вашей семьи. Конечно оно важнее, чем ваше собственное имя, и должно идти первым в знак уважения к своей родне. То же самое про отчество - это имя вашего отца и (ИМХО) его надо указывать обязательно, опять же в знак уважения к своему родителю. По мне схема Фамилия-Имя-Отчество вполне нормальна.
Однако существует у людей такой "недуг" как фамильярность - неуместная развязность, чрезмерная непринуждённость в общении с кем-либо (Викисловарь), и распространен этот недуг весьма широко. Может быть поэтому иногда обращение, начинающееся с фамилии режет слух... Но какое отношение это имеет к значению слова Фамилия?

10

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

« : 21 Мая 2013, 10:08:12 »

Ой, а можно примерчик?

Эдуард, чувствую, раскритикуете вы мой пример    К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.

а в ГОСТ 34 ее как таковой - нет

Юрий, не совсем с вами согласен. Если брать весь комплекс стандартов 34-й серии, то разработка ТЗ - это третья стадия создания Системы. При этом "ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС»" (п. 1.5 ГОСТ 34.602). В свою очередь на первой стадии есть этап 1.2. "Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов? Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации. 2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).   

11

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

« : 20 Мая 2013, 17:57:06 »

Кроме этого, мне кажется будет несколько диковато смотреться "ТЗ по ГОСТ с юзкейсами" ... хотя, "в природе встречается" - это когда очень хочется писать юзкейсы, а нужно сдавать по ГОСТ 34 :-) ....

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

12

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

« : 20 Мая 2013, 15:18:55 »

Пользовательские требования (по их определению) не ложатся на "Требования к структуре и функционированию системы", т.к. они не про систему и ее структуру (суть архитектуру)

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

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

Вы правы, не совсем, и только в ряде случаев.

В целом, не вполне корректный IMHO мэппинг

С другой стороны, если написать ТЗ по данной схеме, вряд ли какой Заказчик будет против  Документ получится достаточно последовательным и логичным. А что еще надо для работы?

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

можно попробовать...

13

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

« : 20 Мая 2013, 11:21:57 »

Хотелось бы подробнее узнать, о том, какие именно группы требований в какие именно разделы ТЗ по ГОСТ 34 ложатся, можете привести схему маппинга?

Как вариант:
Бизнес-требования -> Раздел 2 "НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ (РАЗВИТИЯ) СИСТЕМЫ"
Требования пользователей -> Раздел 4.1.1. "Требования к структуре и функционированию системы"
Бизнес-правила -> Разделы 4.1.4 - 4.1.14 (4.1.4   Требования к надежности, 4.1.5   Требования безопасности, 4.1.6   Требования к эргономике и технической эстетике, 4.1.7   Требования к транспортабельности для подвижных АС, 4.1.8   Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы, 4.1.9   Требования к защите информации от несанкционированного доступа, 4.1.10   Требования по сохранности информации при авариях, 4.1.11   Требования к защите от влияния внешних воздействий, 4.1.12   Требования к патентной чистоте, 4.1.13   Требования по стандартизации и унификации, 4.1.14   Дополнительные требования) в зависимости от содержания требований
Атрибуты качества -> Раздел 4.1.3"Показатели назначения"
Системные требования -> Раздел 4.3"Требования к видам обеспечения"
Функциональные требования -> Раздел 4.2 "Требования к функциям (задачам), выполняемым системой"
Внешний интерфейс -> Разделы 4.3.3   "Требования к лингвистическому обеспечению" и 4.3.4   "Требования к программному обеспечению"
Ограничения -> Раздел 4.1.14"Дополнительные требования"

А в чем именно состоят затруднения применения на практике данной схемы?

На предложенной схеме выделены 3 группы: "Бизнес-требования", "Пользовательские требования" и "Системные требования", при этом граница между функциональными и нефункциональными требованиями очень размыта (непонятно, где она должна проходить). Что дает такая схема? Какие плюсы от ее использования? 

14

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 18 Мая 2013, 21:05:51 »

Я понял, мне не удастся Вас переубедить быстро

На каком слове акцент? 

Ну как и Вам меня

такой задачи не стояло

Так что если все-таки хочется, давайте откроем тему или возможно такая тема уже есть?

похожая тема есть: http://www.uml2.ru/forum/index.php?topic=5365.msg35217#msg35217
можно развить тему

15

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

« : 18 Мая 2013, 20:57:46 »

У Вигерса удобно то, что все группы требований ложатся в какой-то один раздел ТЗ (если по ГОСТ 34.602). Также они упорядочены по времени сбора данных требований. А предложенную схему/классификацию/модель лично я применить на практике затрудняюсь.