сообщение устарело

А к чему вы их там готовите?

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

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

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

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

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

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

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

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

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

Понятно, что в коммерческом конкурентном сегменте такие интернет-магазины быстро и тихо загнутся, никем не замеченные. Но у нас же есть ещё гос. услуги и монополии! И вот там этот подход проявляет себя во всей красе - что на порталах государственных служб (госуслуги в первую очередь), что на сайтах РЖД и ПР.

сообщение устарело

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

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

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

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

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

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

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

Конечно является, ведь именно его деятельность (поиск и покупка товара) автоматизирует система. А вот тут что посадите, то и вырастет. Хотите получить АРМ, будет у вас АРМ. А хотите получить распределенную информационную систему с архитектурой "клиент-сервер" - формулируйте соответствующие требования.

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

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

Проектировщиков сбивает с толку то, что некоторые побочные виды деятельности покупателя действительно хорошо автоматизируются. Например, поиск товара, как здесь было сказано, а я бы к нему добавил ещё и сравнение товаров. Они очень хорошо ложатся на диаграмму юзкейсов, по ним наработан большой опыт разработки. Результат, например, такой: я (и не только я) с удовольствием использую прекрасный интернет-магазин mvideo.ru для поиска и сравнения товаров по характеристикам, а, совершив выбор, покупаю его в другом месте (иду, например, на яндекс.маркет и там выбираю уже по цене, или заезжаю в MediaMarkt по дороге домой, чтобы подержать товар в руках перед окончательным решением о покупке).

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

А в АС функциональная сторона по определению стоит на первом месте (реализует информационную технологию выполнения установленных функций). И ментальные модели, сформировавшиеся у людей, привыкших или обученных разрабатывать "автоматизированные системы", приводят к их осознанному или неосознанному сопротивлению. Что видно, например, на том же сайте РЖД: система отвергает попытки очеловечить интерфейс покупки билетов онлайн. Но им хорошо, они монополисты, и пока могут себе это позволить.


Но бог с ними, с интернет-магазинами. Осознание того, что нефункциональная сторона стала важнее функциональной, приходит и в энтерпрайз. Интерфейсы всех современых автоматизированных банковских систем, например, ужасны. Это бесконечные перекрывающиеся таблицы, формы из десятков элементов, огромное количество непонятных условных обозначений. И уже есть спрос на "АБС с человеческим лицом". И я думаю, что та компания-производитель АБС, которая первой решится на коренную переработку подхода к проектированию, совершит революцию в своём сегменте типа той, которую в массовом масштабе совершила Apple.

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

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

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

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

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

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

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

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

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

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

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

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

Требования пользователя по ГОСТ <> Пользовательским требованиям по Вигерсу. Это скорее всего как раз то, что, например, в RUP называют stakeholder requests и на это есть отдельный артефакт (и шаблон документа). По сути, это набор "хотелок", который может относиться как к бизнес-процессам или к информационной системе в целом, так и к деталям ее реализации. Разного уровня и разных точек зрения.

Насчет пользователя, который сразу выдает features - это запросто. Просто пользователь может не знать, что он формулирует то, что системные аналитики называют фичей :-).
Простой пример. Пользователь говорит "хочу чтобы программа оценивала шанс продать товары из нашего каталога по выбранному клиенту на основании истории покупок и <пр. данных> о клиенте". Это по ГОСТ "требование пользователя" - очевидно, да. Это есть фича? Однозначно да, при условии, если это будет ОТЛИЧИТЕЛЬНОЙ особенностью данной системы, по сравнению с тем что было раньше или от аналогичного ПО :-).

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

Тогда какое от такого стандарта value, если я могу его кастомизировать до неузнаваемости? Я из него SCRUM с итеративной моделью ЖЦ сделаю, и что это считать ГОСТом? Тут куда не кинь - проблема ... по ГОСТ как раз написать плохо ТЗ можно, и никто не сможет доказать, что ТЗ написано плохо. В отличие от тех же юзкейсов, где есть определённые методики их написания. Возможно наличие таких методик для ГОСТа упростило бы ситуацию.

Коллеги, все же решил продолжить:
Классификация требований. Часть 2. Бизнес требования.

Мне кажется, неправильно вы ГОСТ готовите...
Выношу на суждение статью:
"Классификация требований по ГОСТ 34.602-89" http://blog.shumoos.com/archives/288

Мне кажется, неправильно вы ГОСТ готовите...
Выношу на суждение статью:
"Классификация требований по ГОСТ 34.602-89" http://blog.shumoos.com/archives/288

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

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

Плохо. Думаю над этим.

Мне кажется, ты делаешь определенную ошибку, делая акцент на требования к ПО. Там не требования к ПО, а требования к системе. Все-таки это несколько разные вещи. Отсюда и диссонанс в восприятии ГОСТа.

Э-э-э... Ровно это я и написал. Что это требования к системе.