vit_r: default (Default)
[personal profile] vit_r
Интересно, какого фига требование "В сучае ошибки система восстанавливает своё состояние" заносится в раздел "Нефункциональные"?..

Короче, требования разделяются на функциональные, нефункциональные и "фиг знает как". Я б на английском написал, но у меня для последнего термина только варианты, образованные от известного слова на f.. придумываются.

Видимо, это от чтения примеров описания системы в глубоком немецком пассивном залоге. Хуже сегодня были только рекомендации немецкого министерства науки, где в трёх абзацах нудно объяснялось, что такое "документ".
(deleted comment)

Date: 2010-08-31 08:54 pm (UTC)
From: [identity profile] vit-r.livejournal.com
И со срамом и спрочими идолами в полном порядке. Наставили себе болванчиков и молятся, не понимая сути.
(deleted comment)

Date: 2010-08-31 09:04 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Он выглядит как настоящий жулик :-)

Не, честное слово, я читал перовисточники, откуда они свои серебряные пули напёрли. Мне это не интересно.

Да и клиенты вменяемые, на agile не пойдут.
(deleted comment)

Date: 2010-08-31 10:55 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Как можно в одном предложении объединять модель и методологию?

Водопад - это просто модель выделения бюджета. Там всегда присутствуют обратные циклы. Впрочем, как и в любой спирали присутствуют линейные процессы.
(deleted comment)

Date: 2010-08-31 11:01 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Вменяемые клиенты на третьем уровне по Кокбурну. То есть у них своя методология, заточенная под их задачи и условия.

Первая книжка по психологии программирования была у Вайнберга. Ну и много чего ещё за 20 лет издано.

Date: 2010-09-01 06:34 pm (UTC)
From: [identity profile] bon-voyage.livejournal.com
Не могу пройти мимо.

Все требования подразделаются на
- функциональные,
- нефункциональные (иногда называют требованиями качества)
и
- граничные условия (а не "фиг знает как". )
Примеры граничных условий:
- Продукт должен выйти на австрийский рынок 1 апреля 2011 года.
- Система дожна поддерживать работу с MS SQL Server 2005 и более новыми версиями продукта.

Кроме того, существуют и немного другие классификации требований:
Например по CMMI SEI 2006
http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm
или по SPICE ISO/IEC 15504

http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm

Date: 2010-09-01 06:38 pm (UTC)
From: [identity profile] vit-r.livejournal.com
"граничные условия" - Ну и перевод.
Имеется ввиду Business Сonstraints или что-то ещё более интересное?

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

Date: 2010-09-02 05:33 pm (UTC)
From: [identity profile] russian-sla.livejournal.com
То, что присутствует в CMMI, как правило не изобретения авторов модели, а примеры или трактовки, взятые из других моделей и методологий. Т.е. никаких "инженерных" классификаций там не изобретали.

Date: 2010-09-02 05:41 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Я б сказал, что все модели управления по сути дела начинаются с "возьмём готовые требования". Для agile вариант просто "возьмём заказчика, в голове которого готовые требования"

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

Date: 2010-09-02 10:35 pm (UTC)
From: [identity profile] bon-voyage.livejournal.com
Мил человек, я такого не писал. Я написал, "Кроме того, существуют и немного другие классификации требований". Я не писал ни о каких изобретениях, я писал о том, что такие классификации там (CMMI SEI 2006) существуют.
Для того, чтобы в этом убедиться можно прочитать весь документ (см. страницу по моей ссылке), а можно просто посмотреть в словарь в конце документа. Там даны определения таких терминов как customer requirement, nontechnical requirement, product requirements, technical requirement. Имеенно это я и имел в виду когда писал "существуют и немного другие классификации требований"

Date: 2010-09-02 10:40 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Достаточно странное желание объяснять специалисту по RE тонкости спецификаций, а специалисту по CMMI что же именно SEI пишет в своих бумагах :-D

Date: 2010-09-02 11:32 pm (UTC)
From: [identity profile] bon-voyage.livejournal.com
Ты знаешь, я наверно воздержусь пока от комментариев в твоём журнале. Я знаю, что ты сейчас спецификацию пишешь и хотел тебе помочь, потому что тебе это нужно для работы. Я так понял твой постинг.
"Короче, требования разделяются на функциональные, нефункциональные и "фиг знает как". Я б на английском написал, но у меня для последнего термина только варианты, образованные от известного слова на f.. придумываются."
А классификацию я дал для того, чтобы ты вспомнил нужный термин.

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

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

"Интересно, какого фига требование "В сучае ошибки система восстанавливает своё состояние" заносится в раздел "Нефункциональные"?.."

За сим и раскланиваюсь.

Date: 2010-09-03 05:19 am (UTC)
From: [identity profile] vit-r.livejournal.com
Понятно.

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

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

Date: 2010-09-03 05:53 am (UTC)
From: [identity profile] russian-sla.livejournal.com
"Там даны определения таких терминов как"

Совершенно верно - это определения терминов_модели, а не классификация требований! Эти термины используются в практиках модели и даны в Глоссарии именно для того, чтобы пользователи модели понимали - о чем речь в практиках. Т.е., например, определение customer requirements говорит о том, что это такое с точки зрения практик модели, а не что это такое как элемент какой-либо классификации. Есть определенная разница. Не знаю - удалось ли объяснить одним абзацем. :)

Date: 2010-09-03 05:58 am (UTC)
From: [identity profile] vit-r.livejournal.com
В принципе, большой бардак из-за того, что нет маппинга. У разных клиентов один и тот же термин может быть как заголовком раздела спецификации, так и значением аттрибта в таблице отдельного требования. В зависимости от того, какие книжки они любят.

Date: 2010-09-03 06:15 am (UTC)
From: [identity profile] russian-sla.livejournal.com
Можно ли это унифицировать, если действительно такое разнообразие стандартов, моделей, методологий? По-моему, очень сложно (только на каком-то очень верхнем концептуальном уровне, а про это литературы хватает).
На мой взгляд самому исполнителю важно для себя иметь какую-то однозначную трактовку (классификацию) и всякий раз мэпить на неё то, что дает заказчик. Заказчика за (редким исключением) не перевоспитаешь и если он использует "гостовские" термины, значит он и будет на них опираться.

Date: 2010-09-03 06:26 am (UTC)
From: [identity profile] vit-r.livejournal.com
Если люди не очень упёртые, то они рано или поздно переходят на что-то сходное с Volere. Да и качество спецификаций можно померить и перейти к более эффективным.

Унификация не нужна, нужна таблица соответствий. А то каждый новый профессор изобретает собственный вариант велосипеда. Таблицы я видел, но их делали студенты для своих внутренних учебно-докторантских нужд.

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

Date: 2010-09-03 07:52 am (UTC)
From: [identity profile] bon-voyage.livejournal.com
Имменно через определения и дана классификация с точки зрения практик модели.
Пример, дана классификация требований на
- nontechnical requirement,
- technical requirement
Требование попадает в одну из вышеуказанных групп, классов и пр. Таким образом и дана классификация в рамках, деление на группы, классы,
И когда инженер или управленец занимается подготовкой предприятия к сертификации по CMMI ему приходиться пользоваться в том числе и этим делением на группы, этой классификацией. Как только мы начинаем писать документы согласно той или иной методике, эта классификация становиться явной, так как она предусмотврена в большинстве случаев в структуре документа.

Ещё одн пример, когда в математике даются определения, например, рациональных и иррациональных чисел, то выполняется их определённая классификация. Конечно, мы говорим потом о множестве рациональных чисел, а не о классе рац. чисел, однако именно через определения выполнено разделение объектов на два множества, то есть выполнена классификация.

Date: 2010-09-03 08:01 am (UTC)
From: [identity profile] russian-sla.livejournal.com
Хорошо, хорошо... :) Согласен, что это тоже в некотором роде классификация. :)

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

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

Date: 2010-09-03 04:41 pm (UTC)
From: [identity profile] vit-r.livejournal.com
мы говорим потом о множестве рациональных чисел, а не о классе рац. чисел

Ну сам же написал. :-( Не надо путать множества с классами. Тем более, когда множества ортогональны.

Date: 2010-09-04 08:59 am (UTC)
From: [identity profile] bon-voyage.livejournal.com
Любой класс является множеством, обратное утверждение неверно.

http://www.5min.com/Video/Learn-about-Classification-of-Real-Numbers-286301229

Date: 2010-09-04 09:31 am (UTC)
From: [identity profile] vit-r.livejournal.com
обратное утверждение неверно

О чём я уже устал повторять.

Date: 2010-09-01 06:43 pm (UTC)
From: (Anonymous)
есть такое немецкое слово Randbedingung - они так Constrains перевели.
Да, делить можно по разному, но есть более менее "стандартная" классификация и терминология применимая к тому или иному методу.
ЗЫ!! Я такой умный потому что сейчас к сертификации готовлюсь.

Date: 2010-09-01 06:49 pm (UTC)
From: [identity profile] vit-r.livejournal.com
"Бизнес-ограничения"
Граница - она между чем-то и чем-то.

Да, не стоит путать "умный" с "начитанный" ;-)

Date: 2010-09-01 06:49 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Да, восстановление по ошибки к ним ни коим боком не относится

Date: 2010-09-02 11:25 am (UTC)
From: [identity profile] artsg.livejournal.com
1. Можно разделить функции системы на явные и неявные. Явные - то, что приносит пользу заказчику. Неявные - авторизация, аутентификация, действия администратора. В такой классификации то, что система восстанавливается после сбоев, относится к функциональным требованиям.

2. Можно зайти с другой стороны, перечислить все критерии качества, по которым заказчик оценивает систему:
- функциональность,
- быстродействие,
- отказоустойчивость,
- переносимость,
- защищенность,
- масштабируемость.

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

Date: 2010-09-02 04:53 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Ага. С помощью философского камня после сбоев восстанавливается.

В принципе то, что называется Disaster-Recovery Plan вполне себе функциональное описание. В нефункциональной части может стоять, что он должен быть в наличии. Но это немного в сторону от обсуждаемого вопроса.

Profile

vit_r: default (Default)
vit_r

February 2026

S M T W T F S
12 34 567
8 91011121314
15161718192021
22232425262728

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 10th, 2026 02:38 pm
Powered by Dreamwidth Studios