Відмінності між версіями «Вимоги у Хмарі»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Новая страница: «Ценность Требований (здесь и далее по тексту -- ''Лектио'') -- это часть урока Суть Требов…»)
 
 
(Не показані 27 проміжних версій 4 користувачів)
Рядок 1: Рядок 1:
[[Ценность Требований]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Требований]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Вимоги у Хмарі]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Требований|Суть Вимог]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''
  
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[Типы Требований]].
+
Предшественник этого ''Лектио'' -- [[Свойства Требований]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Рядок 9: Рядок 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Ценность Требований</strong></p><p>Требования могут быть классифицированы по большому количеству признаков. Систематизации могут принимать во внимание разницу в объектах применения, векторах действия, спепенях доработки, стадиях жизни в проекте, источниках требований, а также разницу в категориях лиц, которые получат выгоду от реализации требований.</p><p>По объекту применения, требования разделяются на требования к продукту и требования к проекту его разработки.</p><ol typ="a"><li>Требования к продукту представляют собою описи будущего изделия и создаются в результате бизнес-анализа. Далее, эти требования подразделяются на функциональные, нефункциональные и переходные.</li><li>Требования к проекту могут включать требования по срокам, стоимости и другим факторам, влияющим на процесс разработки. Далее, требования к проекту могут быть отнесены к требованиям к разработке и требованиям к приёмке.</li></ol><p>По вектору действия, требования делятся на дозволения и ограничения. Ограничения суживают возможности продукта или его изготовителей, в то время как дозволения, наоборот, расширяют. "Сделать что-то" -- это пример дозволения. Сделать это определённым, определённым образом, к определённому сроку или в рамках определённого бюджета -- это примеры ограничений.</p><p>По степени своей доработки, требования могут быть отнесены к необнаруженным, найденным, находящимся в работе и разработанным для утверждения.</p><p>По стадии жизни в проекте, требования классифицируются как заявленные, утверждённые, задействованные в производстве и реализованные.</p><p>По своему источнику, требования могут быть сгрупированны как требования заинтересованных сторон, обязательства исполняющего предприятия, законодательство и указания уполномоченных органов. Каждая группа может далее иметь несколько подгрупп. Особенно это касается заинтересованных сторон. Например, вес требований куратора продукта и вес требований его ребёнка существенно различается.</p><p>По разнице в категориях тех лиц, которые получат выгоду от реализации требований, последние могут быть причислены к бизнес-требованиям, требованиям пользователей, требованиям разработчиков и социальным требованиям.</p><p>Единых классификаций не существует и те, которые перечислены выше, даны для демонстрации их многообразия.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, требования нужны, чтобы:</p>
+
:<p><strong>Вимоги в Хмарі</strong></p><p>Спочатку розробники Брацької Хмари створюють загальний опис майбутнього виробу. Цей опис робиться на вікі-сторінці Брацької Правки, назва якої відповідає назві виробу, який належить розробити. Цій сторінці надається категорія "Опис виробу для розробки".</p><p>Загальні описи представляють бачення виробу, але вони рідко бувають ясними або конкретними для реалізації розробниками. Якщо описи нечітко описуватимуть, що майбутній виріб повинен виконувати, і як його функції перевірятимуться, загальні описи також не потрібні для найму підрядників.</p><p>Щоб загальні описи стали зручними для розробників, загальні описи розбивають на власні історії (user story). Кожна історія є однією функцією або характеристикою і написана з точки зору кінцевого користувача. Значна кількість історій міститься в одну пропозицію. Наприклад, "координатору інформаційних проєктів потрібен формат історій користувача, щоб писати завдання для розробників." Для розробників ці історії вказують на те, що потрібно розробити.</p><p>Докладніші технічні завдання (ТЗ) вказують на інше, що необхідно знати розробникам. Ці ТЗ включають існуючі правила і норми, спосіб передачі розробниками своїх робіт і так далі.</p><p>Брацька Техрада встановлює загальні вимоги до розробок для Брацької Хмари.</p><p>Всі вимоги без винятку створюються в Брацькій Правці та відкриті для широкої публіки.</p><p>Політика повної прозорості служить двом цілям. По-перше, таким чином розробники вимог можуть отримати більше пропозицій та доповнень. По-друге, навіть майбутні розробники можуть бачити весь процес розробки 24 години на добу 7 днів на тиждень.</p><p>Наявність багатьох документів та їх версій може створити плутанину. Деякі документи та їх версії можуть бути суперечливими. Концепція єдиного джерела істини (single source of truth або SSOT) спрямовано вирішення цієї проблеми. Вимоги лише розробляються на Брацькій Правці, але їх затверджені версії публікуються на Брацькій Вебці.</p><p><i>А тепер, придумайте, будь ласка, питання для завершення цього лектіо.</i></p>
  
===Варианты===
+
===Варіанти===
:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
+
:Відповідь у формі есе не потребує варіантів.
  
:Следующее лектио -- '''[[Разработки Требований]]'''
+
:Следующее лектио -- '''[[Что Бизнес-Анализ Есть]]'''
  
 
===Термины===
 
===Термины===
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[SSOT]], [[Технические задания]], [[Пользовательские истории]], [[Брацка Правка]], [[Брацка Вебка]]
  
 
==Экзамен==
 
==Экзамен==

Поточна версія на 13:39, 27 листопада 2022

Вимоги у Хмарі (тут і далі по тексту -- Лектіо) -- це частина уроку Суть Вимог. У Брацькій Школі, уроки діляться на так звані лектіо, кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу Вибір Професії


Материалы

Предшественник этого Лектио -- Свойства Требований.

Иллюстрации

Текст (HTML)

Вимоги в Хмарі

Спочатку розробники Брацької Хмари створюють загальний опис майбутнього виробу. Цей опис робиться на вікі-сторінці Брацької Правки, назва якої відповідає назві виробу, який належить розробити. Цій сторінці надається категорія "Опис виробу для розробки".

Загальні описи представляють бачення виробу, але вони рідко бувають ясними або конкретними для реалізації розробниками. Якщо описи нечітко описуватимуть, що майбутній виріб повинен виконувати, і як його функції перевірятимуться, загальні описи також не потрібні для найму підрядників.

Щоб загальні описи стали зручними для розробників, загальні описи розбивають на власні історії (user story). Кожна історія є однією функцією або характеристикою і написана з точки зору кінцевого користувача. Значна кількість історій міститься в одну пропозицію. Наприклад, "координатору інформаційних проєктів потрібен формат історій користувача, щоб писати завдання для розробників." Для розробників ці історії вказують на те, що потрібно розробити.

Докладніші технічні завдання (ТЗ) вказують на інше, що необхідно знати розробникам. Ці ТЗ включають існуючі правила і норми, спосіб передачі розробниками своїх робіт і так далі.

Брацька Техрада встановлює загальні вимоги до розробок для Брацької Хмари.

Всі вимоги без винятку створюються в Брацькій Правці та відкриті для широкої публіки.

Політика повної прозорості служить двом цілям. По-перше, таким чином розробники вимог можуть отримати більше пропозицій та доповнень. По-друге, навіть майбутні розробники можуть бачити весь процес розробки 24 години на добу 7 днів на тиждень.

Наявність багатьох документів та їх версій може створити плутанину. Деякі документи та їх версії можуть бути суперечливими. Концепція єдиного джерела істини (single source of truth або SSOT) спрямовано вирішення цієї проблеми. Вимоги лише розробляються на Брацькій Правці, але їх затверджені версії публікуються на Брацькій Вебці.

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

Варіанти

Відповідь у формі есе не потребує варіантів.
Следующее лектио -- Что Бизнес-Анализ Есть

Термины

Требования, SSOT, Технические задания, Пользовательские истории, Брацка Правка, Брацка Вебка

Экзамен

Определения

Вопросы экзамена