Сергей Титков

с 2022
4 подписчика
0 подписок

И для начала нужно знать соотношение между 98 и 50 перцентилями.
Меньше 5.6 это хорошо, больше значит у вас толстый хвост и как следствие в любой момент прилет черный лебедь

Excel умеет считать перцентили, по выборке с LT достаточно запросить данные на 30, 50, 75, 98 перцентили.

Вот вы начинаете понимать суть!
В частности что если широко толковать вещи, то получиться очень не точное обобщающее описание.

Тогда вообще не понятно зачем вы поместили упоминание Ройса в раздел про водопад.
Он писал про итерационно инкрементные подходы. Статья об этом же! А вы его запихнули в первый раздел.
И только на основании картинки...
Полностью при этом игнорировав смысл стать


Вы взяли старый стандарт, сейчас действует от 2015 года.

Вы писали:
Agile нам говорит же: «Работающий продукт важнее исчерпывающей документации»?

Верно, чуть ниже:
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

Вы писали: А в стандарте же описано очень много требований к документации?

Верно просто создатели стандарта чуть больше сфокусировались на правой части.

Последняя попытка.

Перевод из статьи Ройса, что описывает рисунок 2

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

Это просто его мысль! Как не стоит организовывать процесс!
Еще раз мысль! Ни модель, ни методология - просто мысль!

А вы изо всех сил приписывает Ройсу то что он не писал.

Это другие люди отличились! Это они ввели понятия водопад и каскадную модель, а не он.

Ройс должен быть там где говориться о инкрементно итеративные модели.

Вы очень напоминаете людей из этого ролика: https://vimeo.com/18951935?embedded=true&source=vimeo_logo&owner=5781173


Вы пишите:
Что до QC и QA, с вашим стремлением понимать терминологию неправильно. То есть термин «quality control», есть термин «quality management». Термин «control» не является синонимом термину «management». Термин «контролировать» не является синонимом термина «управлять».
Скажем прямо. К терминам вы подходите очень небрежно. Любите невнимательно читать и додумывать за автора. Отсюда очень, очень и очень много ошибок.


А в ГОСТе и ИСО написано другое, и я придерживаюсь их.


P.S. Кстати спасибо за статью: https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf
я о ней не знал. И похоже именно эти двое и ввели документально термин водопад.

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

P.S. Документ я прочел.

P.S.S. Вот эти два человека и виноваты во всей вакханалии с водопадом... Наверно.

Я ответил выше, но повторюсь развернуто, немного издалека.
Вопрос в понятийности. Покажу на примерах.
Ваш текст:
В 1970 году Уинстон Уокер Ройс описал модель разработки, как поток последовательно проходящих фаз анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Такая модель получила название каскадной модели разработки (Waterfall). Сделал он это, чтобы показать её недостатки по сравнению с итеративной разработкой.


В статье Ройс не описывал каскадную модель и не вводил это понятие. Он просто сказал, смотрите, если у вас простая программа - то будет как на рисунке 1. А если у вас будет посложнее, то будет больше этапов. И он просто привел ряд этапов при разработке ПО. Та самая картинка 2. И написал, что такой подход очень рискованный! И объяснил почему. Все. Основной мессадж был про итеративность и почему это снижает риски.

Это моя точка зрения - не придумывать того что написано у автора между строк текста.
Ройс описал каскадную модель в своей статье? - Нет. Он описал подходы снижения рисков и почему не стоит думать о разработке как о последовательных этапах
Ройс где нибдуь использовал слово - водопад. Нет. Термин ввел не он. А кто же ввел? Вот это в статье вы не описали.

А если начать натягивать сову на глобус - думать широко и за автора, то можно начать говорить и про водопад и про модель и про MVP. Все есть в стаье, даже DevOps...


Второй пример, вы пишите: Например, на каскадной модели можно просто и наглядно расписать основы работы QC-специалиста (quality control) и неправильно расписать основы работы QA-инженера (quality assurance). Первый работает над тем, чтобы находить ошибки в реализации программного обеспечения, а второй работает над тем, чтобы не происходило ошибок в реализации программного обеспечения.


Вы максимально все РАСШИРЕЛИ. И в целом, при некой уровне абстарции, да вы написали верно.
Но если подходить к терминам чуть более строго то выше написанное оно ошибочное.
Почему.
Если говорить про каскадную модель, то там описаны действия - работа или активности. Как я писал QC это про управление качеством. То есть проверка того что, мы делаем соответсвует критериям. Верификация и валидация. И эти активности находятся в каждом этапе каскадной модели :) Далее QA(quality assurance) - это обеспечение качества. То есть делать так, что бы вы разрабатывали продукт согласно критериям качества которые ВЫ определили. И качество это вообще может быть не про отсутвие ошибок. Вот если вы ЯВНО указали атрибут качества - бездефектность и определили для него критерии, то только тогда специалист по обеспечению качества займется процессом доставке ценности заказчику и изменит его таким образом, что бы количество дефектов было равно или ниже заданных критериев.

Вот как то так.

Стандарты пишутся по определенным правилам.
И в частности у стандартов есть глоссарий, в котором описываются термины.
Итак в стандарте DOD-STD-2167A от 1988 введен термин водопад? Если да то где?
В документе введено понятие каскадная модель? Да? Где.

Примеры:
- Термин SCRUM был явно введен и описан.
- Пример из вашего текста: Например, на каскадной модели можно просто и наглядно расписать основы работы QC-специалиста (quality control)
Это пример ошибочного использования термина. QC(quality control) - на русский переводится как управление качеством(ГОСТ Р ИСО 9000-2015)

Итого термин водопад не описан в введен в стандрате: DOD-STD-2167A
Наиболее раннее его упоминание это статья: https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf).

Так что мимо.
Если натягивать сову на глобус то можно сказать что Ройс описал скрам

Стоп.
Либо DOD-STD-2167 от 1985
Либо DOD-STD-2167A от 1988

Берем DOD-STD-2167A от 1988
Текст стандарта: http://everyspec.com/DoD/DoD-STD/DOD-STD-2167A_8470/

В определениях нет водопада как и в тексте стандарта.

А самое смешное, что его и сейчас нет. Waterfall это колективное бессознательное.
Если бы было, то был бы документ описывающий ее:)
Типа скрам гайда или аджайл манифеста

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

И в статье нет слов про каскадную модель ни про водопад.

> Каскадная модель разработки (Waterfall / Водопад)> В 1970 году Уинстон Уокер Ройс описал модель разработки....

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