Доклад на тему

«Постановка задачи и спецификация программы. V-модель жизненного цикла. Модель быстрого прототипирования. Agile-методологии»

Москва, 2022 г.

1 Постановка задачи и спецификация программы

(2 слайд).

Если коротко, то основные этапы разработки требований — это:

1. 
   Зачем нам что-то делать?
   
2. 
   Что мы будем делать?
   
3. 
   Как мы это сделаем
   
4. 
   Когда мы это сделаем? 
   

Если вы когда-либо просили что-то сделать — значит вы создавали требования. Они могли быть в форме устного пожелания, письма, технического задания, таски или чего угодно.

(3 слайд).

В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь.
1.1 Цель.

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

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

Цель достигается разными путями.

Например, можно воспользоваться методом “Пяти почему” или любым другим. (4 слайд).

Название метода – 5 Почему (Five Whys) происходит от количества задаваемых вопросов. Для того чтобы найти причину несоответствия необходимо последовательно задавать один и тот же вопрос – «Почему это произошло?», и искать ответ на этот вопрос. Число пять выбрано исходя из того, что такого количества обычно достаточно для выявления сути и источника проблемы. Но, несмотря на то что метод называется 5 почему для поиска причин каждого конкретного несоответствия может задаваться как меньшее, так и большее количество вопросов.
1.2 Зачем нам что-то делать?

(5 слайд).

И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели. Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.

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

---

1.3 Как мы это сделаем?

(6 слайд)

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

Этот этап — дело техники. И если мы успешно прошли предыдущие два — будет гораздо проще.

Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса или аналогичному. Если для вас какой-то тип требований сейчас не актуален, тогда не описываем. Но важно не забыть и проверять себя.

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

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

Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
1.4 Документирование

(7 слайд)

В ваших требованиях скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно все документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Слабый уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии.

В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).

Далее можно уже распределять по спринтам/этапам разработки и внедрения. Необходимо повторять данные в рамках каждой итерации.

Конечно, проблемы будут всегда. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.

---

2 V-модель 

(8 слайд)

V-модель — это тип модели, в которой процесс выполняется последовательно в V-образной форме. Модель основана на объединении фазы тестирования с каждой соответствующей стадией разработки. Разработка каждого шага напрямую связана с этапом тестирования. Следующая фаза начинается только после завершения предыдущей. Каждый этап разработки, напрямую связан с тестированием этого этапа.
2.1 Принципы V-модели:

(9 слайд)

• 
  От большого к малому: в V-модели тестирование выполняется в иерархической перспективе, например, требования, определенные командой проекта, создают этапы проекта высокого уровня и детального проектирования. По мере того, как каждый из этих этапов завершается, требования, которые определяются, становятся все более и более уточненными и подробными.
  
• 
  Целостность данных / процессов: этот принцип гласит, что успешное проектирование любого проекта требует интеграции и согласованности как данных, так и процессов. Элементы процесса должны быть идентифицированы для каждого требования.
  
• 
  Масштабируемость: этот принцип гласит, что концепция V-Model обладает гибкостью, позволяющей приспособить любой ИТ-проект независимо от его размера, сложности или продолжительности.
  
• 
  Перекрестные ссылки: прямая корреляция между требованиями и соответствующей деятельностью по тестированию называется перекрестными ссылками.
  
• 
  Материальная документация: этот принцип гласит, что каждый проект должен создавать документ. Эта документация требуется и применяется как группой разработки проекта, так и группой поддержки. Документация используется для поддержки приложения, когда оно становится доступным в производственной среде.
  

2.2 Этап проектирования V-модели:

(10 слайд)

• 
  Анализ требований — этап включает общение с заказчиком с целью выделить его требования и ожидания от проекта. Другое название этого этапа — сбор требований.
  
• 
  Проектирование системы — этап включает проектирование системы и настройку оборудования и коммуникаций для разработки продукта.
  
• 
  Архитектурный дизайн — системный дизайн, разбивка на модули, выполняющие различные функции. Передача данных и связь между внутренними модулями и с другими системами.
  
• 
  Разработка модулей- система разбивает на небольшие модули. Определяется детальный дизайн модулей, также известный как Low-Level Design (LLD).
  

---

2.3 Этапы тестирования V-модели:

(11 слайд)

• 
  Модульное тестирование — модульного тестирования разрабатываются на этапе проектирования модуля. Эти планы модульного тестирования выполняются для устранения ошибок на уровне кода или модуля.
  
• 
  Интеграционное тестирование — после завершения модульного тестирования выполняется интеграционное тестирование. При интеграционном тестировании модули интегрируются, и система тестируется. Интеграционное тестирование выполняется на этапе проектирования архитектуры. Этот тест проверяет связь модулей между собой.
  
• 
  Системное тестирование — тестирование тестирует все приложение с его функциональностью, взаимозависимостью и связью. Оно проверяет функциональные и нефункциональные требования разработанного приложения.
  
• 
  Приемочное пользовательское тестирование (UAT – User Acceptance Testing) – тестирование, которое проводится конечными пользователями системы с целью принятия решения о внедрении.
  

2.4 Преимущества V-образной модели

(12 слайд).

• 
  В модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки;
  
• 
  В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;
  
• 
  В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО – перед разработкой компонентов;
  
• 
  Модель определяет продукты, которые должны быть получены в результате про­цесса разработки;
  
• 
  Благодаря модели менеджеры проекта может отслеживать ход процесса разработ­ки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой;
  
• 
  Модель проста в использовании.
  

2.5 Недостатки V-образной модели

(13 слайд)

• 
  С ее помощью непросто справиться с параллельными событиями;
  
• 
  В ней не учтены итерации между фазами;
  
• 
  В модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла;
  
• 
  Тестирование требований в жизненном цикле происходит слишком поздно, вслед­ствие чего невозможно внести изменения, не повлияв при этом на график выпол­нения проекта;
  
• 
  В модель не входят действия, направленные на анализ рисков.
  

2.6 Область применения

---

V-образной модели

(14 слайд).

• 
  V-образная модель лучше всего срабатывает тогда, когда вся информация о требованиях доступна заранее.
  
• 
  Использование модели эффективно в том случае, когда доступными являются ин­формация о методе реализации решения и технология, а персонал владеет необходи­мыми умениями и опытом в работе с данной технологией.
  
• 
  V-образная модель – это отличный выбор для систем, в которых требуется высокая надежность.
  

3 Модель быстрого прототипирование

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

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

На данный момент времени одной из самых обещающих среди технологических попыток, сосредоточенных на сущности, а не на трудностях решения проблемы разработки ПО, является разработка методов и средств для ускоренного прототипирования систем как составляющей итеративной спецификации требовании
3.1 Этапы прототипирования

(16 слайд)

• 
  Планирование проекта— результат: документ, описывающий в общих чертах примерные графики и результативные данные.
  
• 
  Быстрый анализ: предварительные опросы пользователей используются для разработки умышленно неполной высокоуровневой модели системы на уровне документации. Результат: документ, содержащий частичную спецификацию требований, который используется для построения исходного прототипа, создаваемого на последующих трех этапах.
  
• 
  Дизайнер конструирует модель (используя для этого инструментальные средства), то есть частичное представление системы, которое включает в себя только те базовые свойства, которые необходимы для удовлетворения требований заказчика.
  
• 
  Затем начинается итерационный цикл быстрого прототипирования.
  
  • 
    Разработчик проекта демонстрирует прототип, а пользователь оценивает его функционирование.
    
  • 
    После этого определяются проблемы, над устранением которых совместно работают пользователь и дизайнер.
    
  • 
    Этот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отображает поставленные к ней требования.
    
  • 
    Создание базы данных представляет собой первую из этих двух фаз.
    
  • 
    После создания исходной базы данных можно начать разработку меню, после чего следует разработка функций, то есть создается рабочая модель.
    
• 
  Затем модель демонстрируют пользователю с целью получения предложений по ее усовершенствованию, которые объединяются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной.
  
• 
  Затем получают официальное одобрение пользователем функциональных возможностей прототипа. После этого создается документ предварительного проекта системы.
  
• 
  Основным компонентом является фаза итерации прототипа, на протяжении которого при использовании сценариев, предоставленных рабочей моделью, пользователь может разыграть роли и потребовать, чтобы последовательное уточнение моделипродолжалось до тех пор, пока не будут удовлетворены все функциональных требования.
  
• 
  Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование.Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой, которая заменяет собой частичную систему, полученную в итерационном цикле прототипирования.
  
• 
  При разработке производственной версии программы, может понадобиться:
  
  • 
    более высокий уровень функциональных возможностей,
    
  • 
    различные системные ресурсы,
    
  • 
    необходимых для обеспечения полной рабочей нагрузки,
    
  • 
    ограничения во времени.
    
  • 
    После этого следуют тестирование в предельных режимах, определение измерительных критериев и настройка, а затем, как обычно, функциональное сопровождение.
    
  • 
    Заключительная фаза представляет собой функционирование и сопровождение, которые отображают действия, направленные на перемещение системы в стадию производственного процесса.
    

---

Смотрите также файлы

• Сабаты таырыбы лагер поэмасындаы Аан бейнесі.docx

• Практическая работа 2.docx

• Ю. Власов вспоминает в 1959 году на Варшавском чемпионате по тяжелой атлетике в борьбе за золотую медаль я столкнулся с американцем Джимом Бредфордом и едва не проиграл. Он буквально подавил меня в первом ж.docx

• Основными признаками понятия "измерение" не являются Необходимость проведения эксперимента.docx

• Ответ 1 Правоотношения между работником и работодателем относятся к трудовым отношения. Определение есть в ст.docx