Лабораторная работа бизнес требования

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

Задачи лабораторной работы

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

«Требование» можно определить, как:

• Условие или возможность, необходимая пользователю для решения проблемы или достижения цели.
• Условие или возможность, необходимая для обеспечения системой или компонентом системы соответствия контракту, стандарту, спецификации или другому формализованному документу.
• Документ, описывающий возможности системы и/или спецификация функций системы.

• Бизнес-требования (описывают пожелания пользователей с точки зрения задач бизнеса, описывают критерии успешности проекта с точки зрения спонсоров проекта, являются требованиями высшего уровня, остальные требования подчинены им);
• Требования пользователей (отражают пожелания непосредственных пользователей системы);
• Системные требования (высокоуровневые требования к продукту как к системе, которая состоит из множества подсистем, в том числе ПО и оборудования)

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

Основные этапы разработки требований.

Учимся понимать бизнес-требования / Кирилл Белявский

• первичный сбор требований;
• разработка и анализ требований;
• управление изменениями требований.

Первичный сбор требований.

• Сбор требований следует начинать с бизнес требований, так как все остальные виды требований подчинены им.
• Основной задачей этапа сбора бизнес требований является выработка образа продукта (образ продукта описывает, что сейчас представляет собой продукт и каким он станет впоследствии, образ продукта подразумевает определение долгосрочных перспектив развития проекта, в то время как границы проекта могут быть определены для конкретной итерации).
• Границы проекта показывают, к какой области долгосрочного образа продукта направлен текущий проект.

Разработка и анализ требований.

Лабораторная работа № 1. Создание бизнес-плана интернет проекта

Ознакомление с методикой разработки бизнес-планов и приобретение практических навыков составления бизнес-планов небольших интернет проектов.

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

Цели бизнес-планирования

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

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

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

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

Бизнес-планирование для внутренних целей компании

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

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

При составлении бизнес-плана для принятия решений внутри компании необходимо учитывать ряд особенностей:

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

— время на подготовку бизнес-плана, разрабатываемого для внутренних целей, как правило, сильно ограничено. Поэтому в таких бизнес-планах можно сосредоточиться в основном на количественной (расчетной) информации, касающейся маркетинговых и финансовых показателей, особенно, если подобные бизнес-планы уже представлялись ранее лицам, принимающим решения;

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

— внутренние бизнес-планы могут использоваться для анализа «план-факт». Бизнес-планы прошлых периодов при сопоставлении их с фактическими результатами позволяют компании сделать выводы о том, какие стратегии были наиболее эффективными. Кроме того, сравнение различных параметров бизнес-плана с фактическими результатами позволяет компании выявить сильные и слабые элементы в своей структуре (от подразделений до конкретных исполнителей).

Структура бизнес-плана интернет проекта:

1.1. Наименование проекта

1.2. Цель проекта

1.3. Участники проекта

1.4. Основная информация о проекте

1.5. Реализация проекта

15.1 Подробней об участниках проекта

1.5.2 Работы и их стоимости

1.5.3 Схема финансирования

1.5.4 Жизненный цикл проекта и результаты

1.5.5 Текущее состояние проекта

1.5.6 Договоренности и поддержка

1.6 Рыночная ориентация проекта (маркетинговое исследование)

1.7 Экономическое обоснование

1.7.1 Расчет прибыли

1.7.2 Экономические показатели эффективности

1.8 Оценка рисков и мероприятия по их ограничению

Разделы бизнес-плана

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

практика 2. Лабораторная работа 2 Разработка требований

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма

Скачать 39.99 Kb.

Лабораторная работа №2 Разработка требований

1. Изучить теоретические сведения.
2. Выполнить практическое задание по лабораторной работе.
3. Оформить отчёт и ответить на контрольные вопросы.

Теоретические сведения

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

• Позволяют понять, что и с соблюдением каких условий система должна делать.
• Предоставляют возможность оценить масштаб изменений и управлять изменениями.
• Являются основой для формирования плана проекта (в том числе плана тестирования).
• Помогают предотвращать или разрешать конфликтные ситуации.
• Упрощают расстановку приоритетов в наборе задач.
• Позволяют объективно оценить степень прогресса в разработке проекта.

В иерархии требований существует три уровня: уровень бизнес-требований, уровень пользовательских требований, уровень продуктных требований (функциональные и нефункциональные требования).

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

Пользовательские требования описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы, и по своей сути представляют собой недетализированные функциональные требования. Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объёма работ, стоимости проекта, времени разработки. Пользовательские требования оформляются в виде вариантов использования (Use Cases), пользовательских историй (User Stories), пользовательских сценариев (User Scenarios).

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

Выявление и описание требований: Use Case.

Вариант использования (Use Case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица. Действующим лицом может быть человек, другая система ПО или аппаратное устройство, взаимодействующее с системой для достижения некой цели.

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

• уникальный идентификатор;
• имя, кратко описывающее задачи пользователи в формате «глагол + объект», например «разместить заказ»;
• краткое текстовое описание на естественном языке;
• список предварительных условий, которые должны быть удовлетворены до начала разработки варианта использования;
• выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования;
• пронумерованный список действий, иллюстрирующий

название или идентификатор или импортируя его структуру из соответствующего графического средства.

Система выполняет запрос, предлагая контейнер с химикатом со склада или позволяя создать запрос

1. Сотрудник указывает требуемый химикат.
2. Система перечисляет контейнеры с необходимым химикатом, имеющиеся на складе.
3. Сотрудник может просмотреть историю любого контейнера.
4. Сотрудник выбирает определенный контейнер или просит отправить запрос поставщику (см. 4.1).
5. Сотрудник вводит остальную информацию, чтобы завершить запрос.
6. Система сохраняет запрос и отправляет его на склад химикатов.

Пример варианта использования приведен в таблице 2.1. Таблица 2.1 – Пример варианта использования

Окончание таблицы 2.1

1. Сотрудник ищет химикат по каталогам поставщика (см. 4.1.E1).
2. Система отображает список поставщиков, где также указаны размеры, класс и цена контейнеров.
3. Сотрудник выбирает поставщика, размер, класс и количество контейнеров.
4. Сотрудник вводит остальную информацию, необходимую для запроса.
5. Система сохраняет запрос и перенаправляет его поставщику.

1. Система отображает сообщение «У поставщиков нет такого химиката».
2. Система предлагает сотруднику запросить другой химикат или выйти из программы.

4а. Система заново начинает нормальное направление варианта использования.

3б. Сотрудник решает выйти из системы.

Существует несколько сценариев варианта использования (см. таблицу 2.1). Один сценарий считается нормальным направлением развития (normal course)

варианта использования, его также называют основным направлением, главным успешным сценарием и благоприятным путем. Нормальное направление для варианта использования «Запрос химиката» — запрос химиката, который есть на складе.

Другие допустимые сценарии из варианта использования, называются альтернативными направлениями (alternative courses) или вторичными сценариями (secondary scenarios). Они также могут привести к успешному выполнению задания и удовлетворяют выходным условиям варианта использования. Однако они представляют вариации решения задачи или диалоговой последовательности, необходимой для выполнения задачи. В определенной точке принятия решений в диалоговой последовательности нормальное направление может перейти в альтернативное, а затем вернуться обратно в нормальное.

Условия, препятствующие успешному завершению задания, называются исключениями (exceptions). Если в процессе сбора информации не указано, как обрабатывать исключение, то возможны два пути: 1) разработчики предложат лучший по их мнению способ обработки исключений; 2) при генерации пользователем неверного условия произойдет сбой системы, так как никто не предусмотрел такой ситуации. Иногда исключения рассматриваются как тип альтернативного направления, однако эти понятия следует разделять. Не обязательно реализовывать каждое альтернативное направление, которое определяют для варианта использования; кроме того, можно отложить его реализацию до следующего выпуска. Однако необходимо реализовать исключения, из-за которых завершение сценариев может оказаться неуспешным.

Расширение (extend) и включение (include).

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

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

Иногда же несколько вариантов использования имеют общие наборы этапов. Чтобы избежать повторения этих этапов в каждом варианте использования, можно определить отдельный вариант использования и указать, что он включен (include) в другие варианты использования как подвариант.

Пример: Если покупатель совершает покупку товара, то он обязательно должен его оплатить. Нет случая, когда покупатель просто за что-то платит (т.е. оплата товара не является отдельной независимой деятельностью покупателя), но при этом процесс оплаты сам по себе достаточно сложный, включающий различные шаги и альтернативные варианты (оплата различными способами). Поэтому логично его выделить в отдельный вариант использования, при этом включить в вариант использования «Покупка товара». Такая связь будет означать,

что при выполнении варианта использования «Купить товар» обязательно будет задействован и вариант использования «Оплатить товар».

Определение вариантов использования.

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

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

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

-страница с лекциями( возможность скачать);

-страница с практиками( возможность скачать);

— страница тестирования ( пройти тестирование, получить результат, отправить результат);

-Аутентификация (*-ФИ -№Группы –логин –пароль)

1. Определить действующие лица и сформулировать наиболее вероятные варианты использования подлежащего разработке программного продукта.
2. Полностью описать три варианта использования подлежащего разработке программного продукта.
3. Для каждого варианта использования указать уникальный идентификатор; имя в формате «глагол + объект»; краткое текстовое описание; предварительные условия; выходные условия; пронумерованный список действий нормального направления развития.
4. Для каждого варианта использования при необходимости указать пронумерованный список действий альтернативного направления (направлений) развития.
5. Для каждого варианта использования при необходимости указать исключения.
6. Оформить отчет и защитить лабораторную работу.

1. Цель работы.
2. Описание вариантов использования подлежащего разработке программного продукта.
3. Выводы по работе.

1. Что такое требование?
2. Какие значения имеют требования на проекте?
3. Какие существуют этапы работы над требованиями?
4. Кто выполняет работу с требованиями?
5. Какие существуют уровни требований?
6. Что такое вариант использования?
7. Для чего нужен вариант использования?
8. Какие элементы входят в состав описания варианта использования?
9. Что такое основной сценарий варианта использования?
10. Что такое альтернативный сценарий варианта использования?
11. Что описывают в исключениях варианта использования?
12. В чем отличие альтернативного сценария от исключения в описании варианта использования?
13. Какие существуют преимущества у вариантов использования как одного из способов описания требований?

Источник: topuch.com