фейк!!!!!!!!!!!!!!. Реферат на тему Формирование требований к современному сложному программному продукту при его проектировании по дисциплине
 Скачать 276.06 Kb.
|
 МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИФедеральное государственное бюджетное образовательное учреждение высшего образования "МИРЭА - Российский технологический университет" РТУ МИРЭА  Институт информационных технологий Реферат на тему: «Формирование требований к современному сложному программному продукту при его проектировании» по дисциплине «Введение в профессиональную деятельность»
Москва 2021 Содержание ВВЕДЕНИЕ 3 ОСНОВНЫЕ ВИДЫ ТРЕБОВАНИЙ 4 Бизнес-требования 5 Бизнес-правила 6 Пользовательские требования 7 Атрибуты качества 7 Ограничения 8 Внешние интерфейсы 8 Системные требования 8 Функциональные требования 9 Характеристика 9 РАЗРАБОТКА ТЕХНИЧЕСКИХ УСЛОВИЙ 10 Выявление и сбор требований 10 Анализ 11 Документирование 12 Утверждение 12 ПРОБЛЕМЫ ФОРМИРОВАНИЯ ТРЕБОВАНИЙ 14 Недостаточное вовлечение пользователей 14 Небрежное планирование 14 «Разрастание» требований пользователей 15 Двусмысленные требования 16 Требования «бантики» 16 ЗАКЛЮЧЕНИЕ 16 СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ 18 ВведениеСтремительное развитие информационных технологий на сегодняшний день в условиях жесткой конкурентной борьбы, а также изменение потребностей заинтересованных сторон заставляет компании, специализирующиеся на разработке программных продуктов, максимально ответственно относиться к процессу разработки требований, так как недостаточная проработка на начальном этапе приводит к значительным затратам времени и бюджета. Что такое требование? Требование это такое свойство программного продукта, которое необходимо пользователю для решения проблемы при достижении определенной цели; Некое свойство программного продукта, которым она должна обладать, чтобы удовлетворить требования контракта, спецификации либо иной формальной документации. На этапе определения концепции продукции выявляются причины появления потребностей у заказчика, и затем выполняется сбор таких требований для модификации продукта. После того как стали известны основные варианты использования будущего продукта, определены его возможности, необходимо детализировать требования к продукту. Основная работа на этом этапе ведется с конечными пользователями продукта. Необходимо через общение с конечными пользователями выявить пользовательские истории к будущему продукту. Пользовательская история - это вариант использования будущего продукта в конкретной ситуации с целью достижения измеримого результата. Они могут содержать как сложные конструкции с ответвлениями, так и конкретные примеры. Для определения потребностей заказчика на весь срок разработки концепции проводится интенсивная работа с руководителем проекта, чтобы в дальнейшем у обоих сторон выявилось общее видение будущего продукта. Далее на основе изученных и уже систематизированных требований, команда аналитиков формирует документ концепцию. Документ концепция содержит детальную информацию о требованиях заказчика, возможностях продукта, границах проекта, ориентировочных сроках и бюджете. Затем разрабатывается макет будущего продукта. С завершением разработки концепции и макета заказчик принимает решение о целесообразности разработки и внедрения продукта, и если было вынесено положительное решение, то далее формируется устав проекта по разработке продукта. Основные виды требованийРассмотрим виды требований, пользуясь при этом классификацией Карла Вигерса.  На этой картинке Вигерс перечислил различные виды требований, которые стали уже, пожалуй, общепринятыми. Как видно из нее, Вигерс делил все требования на функциональные и нефункциональные. Чем они отличаются? С функциональными все просто: они описывают наблюдаемое поведение системы в различных обстоятельствах. Термин «нефункциональные» требования может ввести в заблуждение, так как может показаться в негативном ключе. Нефункциональные требования могут описывать не что система делает, а то, как хорошо она это делает. Они могут описывать важные характеристики или свойства системы. К ним относятся, например, доступность, легкость и простота использования, производительность и другие характеристики системы. Другие нефункциональные требования описывают среду, в которой работает система, например платформу, переносимость, совместимость и ограничения. Многие продукты в свою очередь должны подчиняться определенным правилам, требованиям регулирующих органов или требовать сертификации. Такими могут быть, например, требования по локализации для продуктов, в которых должны учитываться региональные стандарты, языки, законы, валюты, терминология, орфография и другие характеристики пользователей. Бизнес-требованияИтак, самый первый вид требований: бизнес-требования(businessrequirements). Что это такое, в целом? Бизнес-требования описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание- это бизнес-цели организации или клиента. Это описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы. Допустим, что авиакомпания хочет на 25% снизить затраты на сотрудников у стойки в аэропорту. В процессе достижения этой цели может возникнуть идея поставить терминал, который пассажиры будут использовать для самостоятельной регистрации в аэропорту. Как правило, бизнес-требования высказывают те, кто финансируют проект, покупатели системы, управляющий реальными пользователями, отдел маркетинга или ответственный за концепцию продукта. Пример: если мы разрабатываем сайт поиска авиабилетов , мы можем описать в бизнес-требованиях какие возможности он предоставляет. Допустим посетителю сайта он обеспечивает возможность подобрать оптимальный по цене маршрут, чтобы сэкономить деньги. Также позволяет сэкономить время планирования поездки, потому что поиск авиабилетов на разных сайтах разных авиакомпаний и их сравнение всегда требует большого количества времени. Поэтому многие пользуются подобными сервисами именно для того, чтобы сэкономить время. Авиакомпаниям дает возможность использовать дополнительный канал продаж авиабилетов. Владельцу сайта дополнительно может дать возможность продавать на сайте что то еще. Например, дополнительные услуги для путешественников- бронирование машин, заказ гостиниц, заказ такси и так далее. Вполне возможно включить такой перечень возможностей в Концепцию, и эти бизнес-требования будут определять образ нашего продукта в целом и влиять на его разработку. Бизнес-правилаСледующий вид - бизнес-правила(business rules), включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы. Что под ними понимается? Положения, определяющие или ограничивающие какие-либо стороны бизнеса. То есть это такие требования, принятые в практике бизнеса, либо в законодательстве, либо в отрасли, которые должны исполняться при реализации системы. За этим стоят документы, регламентирующие на уровне законов или отраслевых стандартов то, как должен работать продукт; Это законы: сейчас это становится более актуальным для интернет-проектов, так как выпускается все больше законов, регулирующих эту отрасль. По своей сути бизнес-правила сами по себе не являются требованиями к программным продуктам, потому как они находятся как бы за пределами любой системы программного продукта. Однако они часто налагают ограничениями эти самые системы, определяя таким образом, какими функциями она должна обладать, подчиняясь соответствующим правилам. Иногда, как в случае с корпоративными политиками безопасности, бизнес- правила становятся источником атрибутов качества, реализующихся в функциональности. Следовательно, можно отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил. Примером может служить закон о песональных данных, накладывающий требования по реализации определенных функций на сайте. То есть сайт интернет магазина должен учитывать требования закона при хранении и обработке персональных данных покупателей. Пользовательские требованияСледующий вид требований - пользовательские требования (userrequirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователей. Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой. Примером может быть регистрация на рейс с использованием веб-сайта или терминала в аэропорту. Будучи сформулированным в виде пользовательской истории, то же пользовательское требование может звучать так: "Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет". Важно помнить, что в большинстве проектов есть несколько классов пользователей, а также других участников, потребности которых тоже надо выявить. Некоторые люди используют более широкий термин «требования заинтересованных лиц» для обозначения того факта, что требования будут предоставляться различными заинтересованными лицами, отличными от прямых пользователей системы. Атрибуты качестваАтрибуты качества (quality attributes) еще называют параметрами качества, требованиями по уровню обслуживанию и т.п. Они представляют собой описание различных измерений характеристик продукта, которые важны для пользователей или для разработчиков и тех, кто будет обслуживать систему, таких как производительность, доступность и переносимость. Например, время загрузки и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надежность». Производительность - это время загрузки страницы, а надежность - это нагрузка на сайт. Сайт должен быть адаптирован для мобильных устройств. Это требование отражает атрибут «качества». ОграниченияСледующий вид - Ограничения (constraints) представляет собой наложение границ на возможности выбора разработчика при проектировании продукта, условия, которые модифицируют требование или набор требований, сужая выбор возможных решений. Например, сервер приложений сайта должен разрабатываться на языке Java, если, например, у заказчика есть множество специалистов этого языка. Или же сайт должен устанавливаться на определенную версию операционной системы. Внешние интерфейсыРечь идет о подключениях к другим программным системам, аппаратным устройствам и пользователям, а также коммуникационные интерфейсы. Если в эпоху первых машин это требование было не очень актуальным, то сейчас оно иногда замещает даже пользовательские требования. Сейчас появляются системы, разрабатывающиеся для взаимодействия машин друг с другом, поэтому внешние интерфейсы становятся все более важной частью требований. Самый простой пример- API (программный интерфейс приложения) социальных сетей. Системные требованияСистемные требования (system requirements) описывают требования к продукту, который содержит многие компоненты или подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди и процессы тоже часть системы, поэтому определенные системные функции могут распространяться и на людей. Хороший пример «системы»- рабочее место кассира в супермаркете. В нем есть сканер штрих- кода, интегрированный с весами, а также ручной сканер штрих-кода. У кассира есть клавиатура, монитор и выдвижной ящик-касса. Есть также устройство чтения кредитных карточек, принтеры для печати чека. Все эти устройства взаимодействуют под управлением программного обеспечения. Функциональные требованияФункциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований. Такое соотношение между тремя уровнями требований жизненно важно для успеха проекта. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна»: «У пассажира должна быть возможность распечатать посадочные талоны на все рейсы, на которые он зарегистрировался» или «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место». ХарактеристикаИ наконец, Характеристика (feature)- это набор логически связанных функциональных требований, которые представляют ценность для пользователя и удовлетворяют бизнес-цели. Желательные характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки веб-браузера, средства проверки орфографии, запись макрокоманды, автоматическое обновление определений вирусов в антивирусной программе. Характеристики могут охватывать множество пользовательских требований, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач. Итак, мы разобрали основные виды требований, которые могут быть предъявлены программному продукту, представленные в книге Карла Вигерса, но что же с ними делать? Ведь недостаточно просто знать каждый вид и что он затрагивает. Нужно знать как правильно сформировать эти требования к создаваемому продукту, знать что клиент имеет ввиду и в дальнейшем работать с этими требованиями. Разработка технических условий Как видно из иллюстрации, разработкой требований (формирование требований) называют разработкой технических условий. В нее входят такие пункты, как: Выявление, Анализ, Документирование, Утверждение. В эти составные части входят все действия, включающие сбор, оценку, документирование и утверждение требований для программного продукта. Рассмотрим основные действия в каждой из составных частей. Выявление и сбор требованийВыявление и сбор требований (elicitation) охватывает все действия, связанные с выявлением требованием, такие как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся: Определение классов ожидаемых пользователей продукта и других заинтересованных лиц. Понимание задач и целей, а также бизнес-целей, которым соответствуют эти задачи. Изучение среды, в которой будет использоваться новый продукт. Работа с отдельными людьми, которые представляют каждый класс пользователей, чтобы понять их потребности и ожидания в отношении качества. На что лучше ориентироваться: на использование или продукт? При сборе требований обычно используется подход, ориентированный на использование, или подход, ориентированный на продукт, хотя возможны и другие стратегии. В ориентированном на использование подходе упор делается на понимание и исследование задач пользователей, и на основе этой информации выводится необходимая функциональность системы. Ориентированный на продукт подход сфокусирован на определение функций, которые, как ожидается, приведут к успеху на рынке или успеху бизнес компании. В таких стратегиях есть риск реализовать функции, которые не будут активно использоваться, несмотря на то, что во время сбора требований они казались очень нужными. По словам Карла Вигерса: «рекомендуется сначала изучить бизнес-цели и цели пользователей, а затем на основе этой информации определить нужные функции и характеристики продукта». АнализАнализ требований (analyzing requirements) подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основной алгоритм: анализ информации, полученной от пользователей, чтобы отделить их задачи от функциональных и нефункциональных требований, бизнес-правил, предполагаемых решений и другой информации; разложение высокоуровневых требований до нужного уровня детализации; выведение функциональных требований из информации других требований; понимание относительной важности атрибутов качества; распределение требований по компонентам программного продукта, определенным в системной архитектуре; согласование приоритетов реализации; выявление пробелов в требованиях или излишних требований, не соответствующих заданным рамкам. ДокументированиеДокументирование требований предусматривает представление и хранение совокупного знания о требованиях постоянным и хорошо орагнизованным способом. К ключевому действию относится: преобразование собранных потребностей пользователей в письменные требования и диаграммы, пригодные для понимания, анализа и использования целевой аудиторией. УтверждениеУтверждение требований (requirements validation) должно подтвердить правильность имеющегося набора требований, которые позволяют разработчикам создать решение, удовлетворяющее бизнес-целям. Основной алгоритм: проверка задокументированных требований для устранения всех недостатков до принятия требований группой разработки; разработка приемочных тестов и критериев, которые должны подтвердить, что созданный на основе требований продукт будет отвечать потребностям заказчика и удовлетворять поставленным бизнес-целям. Итерация - ключевое условие успеха разработки. При планировании нужно предусмотреть не один цикл проверки требований для поступательного уточнения деталей высокоуровневых требований и подтверждения правильности пользователями. На это может уходить много времени, и подобная деятельность может быть не очень захватывающей, но все же это неизбежная процедура разрешения всех неясностей при определении новой программной системы. Однако стоит понимать, что невозможно создать идеальные требования. С практической точки зрения цель разработки требований - накопить общее понимание требований, достаточно хорошее для создание новой порции продукта, чтобы продолжить работу при разумном уровне риска. Основной риск заключается в наличии большого объема недоделок из-за того, что команда недостаточно глубоко разобралась с требованиями к очередному этапу работы перед началом проектирования и разработки. Итак, мы рассмотрели все варианты, входящие в «Разработку требований», но на рисунке также можем заметить, что в разработку технических условий также входит и «Управление требованиями». Что же относится к этой части? К действиям по управлению требованиями относятся: определение основной версии требований, моментальный снимок, который представляет согласованный, проверенный и одобренный набор функциональных и нефункциональных требований, обычно для конкретного выпуска продукта или итерации разработки; оценка влияния предлагаемый требований и внедрение одобренных изменений в проект управляемым образом; обновление планов проекта в соответствии с изменениями в требованиях; обсуждения новых обязательств, основанных на оцененном влиянии изменения требований; определение отношений и зависимостей, существующих между требованиями; отслеживание отдельных требований до их проектирования, исходного кода и тестов; отслеживание состояния требования и действий по изменению на протяжении всего проекта. Задача управления требованиями состоит в предугадывании и приспосабливании к ожидаемым реальным изменениям, чтобы снизить их разрушительное влияние на проект. Проблемы формирования требованийТеперь мы рассмотрели все алгоритмы формирования требований и управления ими. Какие же могут возникнуть проблемы? Недостаточное вовлечение пользователейК сожалению, разработчики не всегда придают значение вовлечения пользователей в процесс разработки, так как думают, что и сами знают, что нужно пользователям. Но в конечном итоге недовольными останутся конечные потребители, а разработчикам придется решать эти проблемы. Иногда связаться с людьми, которые будут пользоваться конечным продуктом, бывает непросто, а тестировщики и сами не знают, что нужно этим людям, так как сами тестировщики не будут иметь дело с этим продуктом в реальности. И из-за такой банальной ошибки как недостаточное вовлечение пользователей в производство ведет к обнаружению ошибок в требованиях на поздних стадиях проекта, соответственно к задержке выхода продукта в свет. Небрежное планирование«Я кое-что придумал для нового продукта. Когда вы сможете это сделать?» Неопределенные, плохо понятные требования могут вызвать слишком оптимистичные оценки. Неподготовленная оценка звучит как обязательство для слушателя. Наибольшие вклады в проект при плохо просчитанной смете составляют затраты на частые изменения требований, пропущенные требования, недостаточное взаимодействие с пользователями, недетализированную спецификацию требований и плохой анализ. Оценка трудоемкости и продолжительности проекта на основе требований означает, что мы должны знать об объеме своих требований и продуктивности команды разработчиков. Смягчить взаимоотношения пользователя и разработчика можно с помощью таблицы Дина Леффингуэлла:
«Разрастание» требований пользователейВ процессе разработки требования могут меняться из-за чего проект часто выходит за установленные рамки как по срокам, так и по бюджету. Чтобы управлять пределами возрастания требований, для начало следует уточнить бизнес-цели проекта, стратегическое видение, ограничения и критерии успеха. Оценить, как все предполагаемые новые характеристики или требования отразятся на этих параметрах. Требования будут изменяться и расти. Менеджер проекта должен предусмотреть "буферы планирования" на случай непредвиденных обстоятельств, чтобы первое же новое требование не привело к срыву графика. Объем итерации корректируется так, чтобы вписаться в заданный бюджет и длительность итерации. Двусмысленные требованияОдин из симптомов двусмысленности заключается в том, что пользователь может интерпретировать одно и то же положение по-разному. Другой симптом состоит в том, что у нескольких читателей требования возникает разное понимание того, что оно означает. Двусмысленность ведет к формированию различных ожиданий у заинтересованных лиц. Впоследствии некоторые из них удивляются результату, разработчики же тратят время впустую, занимаясь не теми задачами, а тестировщики готовятся к проверке не тех особенностей поведения системы. Один из способов избавиться от двусмысленности - пригласить различных представителей пользователей для официальной экспертизы требований. Требования «бантики»Под «бантиками» (gold plating) понимают отсутствующие в спецификации требований функции, добавленные разработчиками, потому что им кажется, что это понравится пользователям. Если избыточные возможности оказываются ненужными для клиентов, получается, что время, отведенное на реализацию, тратится впустую. Прежде чем просто вставлять новые функции, разработчики и бизнес-аналитики должны представить свои творческие идеи на суд заказчиков. Задача команды - четко соблюдать требования спецификации, а не действовать за спиной клиентов, без их одобрения. ЗаключениеТаким образом, современное программное обеспечение постоянно модифицируется под потребности заинтересованных лиц и зачастую не всегда функционал совпадает с требованиями заказчика. Поэтому описанный процесс формирования требований к программному продукту позволяет решить такие проблемы, как несоблюдение определенной последовательности выполнения этапов, вследствие чего появляется риск потери бюджета, времени и доверия клиентов. Для наглядного представления и согласования с заказчиком будущего продукта необходимо составление прототипов. И наконец, нужно помнить, что каждый процесс разработки требований программного продукта является уникальным. СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВКарл Вигерс: Разработка требований к программному обеспечению / Карл Вигерс, Джой Битти М.: Издательство «Русская редакция», 2014. 736 с. Леффингуэлл Дин: Принципы работы с требованиями к программному обеспечению. Унифицированный подход / Дин Леффингуэлл, Дон Уидриг М.: Издательский дом «Вильямс», 2002. 448 с. |