Презентация на тему по теме Жизненный цикл программного обеспечения. Постановка задачи (МДК Технология разработки программного обеспечения

процесс выявления, формулирования, анализа, документирования и верификации требований, подлежащих

выполнению в продукте (ПО).
Основной задачей разработки требований является создание базовой версии требований к продукту в оговоренные сроки.

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

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

в разработке ПО.
Во время постановки задачи четко формулируется назначение

разрабатываемого ПО и определяется список основных требований к нему.
В основе этапа постановки задачи лежит согласование требований между заказчиком и разработчиком.
Каждое требование представляет собой описание необходимого или желаемого свойства программного обеспечения.

Требование – это условие, которому должно удовлетворять ПО, или свойство, которым оно должно обладать.

Постановка задачи должна быть точной и подробной

программного обеспечения, которые должны быть надлежащим образом представлены в

нём для решения конкретных практических задач (по SWEBOK -Software Engineering Body of Knowledge).
Понятие “требование” (на основе стандарта IEEE Standard Glossary of Software Engineering Terminology, 1990):
Условия или возможности, необходимые пользователю для решения задач или достижения целей.
Условия или возможности, которыми должна обладать система или компоненты системы для обеспечения условий контракта, стандартов, спецификаций или  др. регулирующими документам.
Документированное представление, условий или возможностей, перечисленных в предыдущих пунктах.

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

напрямую или косвенно с приложением (подкласс заказчиков).
Аналитики требований, которые пишут требования и передают их разработчикам.
Разработчики, которые создают, разворачивают и поддерживают продукт.
Тестировщики, которые определяют соответствие поведения программного обеспечения желаемому.

руководства пользователей, тренировочных материалов и справочной системы.
Менеджер проекта,

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

между
Разработчиком и Заказчиком о том, что
должно делать ПО;
ограничение функциональности

ПО;
создание базиса для планирования разработки проекта;
определение пользовательского интерфейса;
составление Спецификации требований (Технического задания).

и интересов заказчика:
достижение соглашения между заказчиком и разработчиком

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

прототипы, обычно определяются по аналогии, с учетом характеристик и

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

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

будут выполнятся разрабатываемым ПО);
эксплуатационные требования (требования пользователей, определяют особенности

работы ПО).

пользователей
Системные требования
Функциональ-ные требования
Документ об образе и границах

проекта

Документ о вариантах использования

Спецификация требований к продукту

Функциональные

Нефункциональные

промышленные стандарты,
вычислительные алгоритмы.
Бизнес-правила не являются

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

пользователям позволит решить система.
Представление требований:
варианты использования,

сценарии.
таблицы «событие – отклик».
Системные требования обозначают высокоуровневые требования к продуктам, которые содержат многие подсистемы(IEEE, 1998с).
Система - программное обеспечение или подсистемы программного обеспечения и оборудования. Люди – часть системы, поэтому определенные функции системы могут распространяться и на людей.

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

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

и структуры продукта (возможности выбора архитектуры).
Функциональные требования определяют функциональность

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

документирование, проверка

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

задачи и цели проекта, в рамках которых определяются все

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

должен четко определять, что представляет собой продукт как в

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

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

подразделять по признакам:
по частоте использования продукта;
по опыту в предметной

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

на основе признаков формируются классы пользователей

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

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

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

потенциальных пользователей и дискуссии с ними;
документы, где описан

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

разработка

Контролируемая пользователем
разработка

Независимая от пользователя
разработка

и точное описание функций и ограничений разрабатываемого ПО.
функциональные требования

функциональная спецификация
Эксплуатационные требования

спецификация качества

содержать всю существенную информацию.
Требование точности – спецификация должна однозначно

восприниматься как заказчиком, так и разработчиком.

Спецификация должна описывать:

Функциональность. Что должно выполнять ПО? Все требования,

перечисляемые в этом разделе, должны быть точно сформулированы и одинаково пониматься заказчиком и исполнителем.
Внешние интерфейсы. Как ПО взаимодействует с пользователями, оборудованием и другими системами?
Атрибуты ввода и вывода. Определяют вводимые и выводимые данные.
Ограничения на функциональность.
Производительность. Скорость, надежность, время ответа, время восстановления и т. д.
Прочие нефункциональные требования.

поставщиками о том, что программное обеспечение должно делать.
Уменьшить усилия

на разработку.
Обеспечить основание для оценки затрат и календарного плана.
Обеспечить основу для испытаний (validation) и проверок.
Облегчить передачу ПО новым пользователям или установку на новые машины.
Служить основанием для улучшения.

спецификации-
http://russian.joelonsoftware.com/PainlessSpecs/1.html
Джоель

Спольски - основатель Fog Джоель Спольски - основатель Fog
Creek Software, небольшой компании
по разработке программного
обеспечения, расположенной в Нью-
Йорке. Окончил Йельский Университет,
работал программистом и
управляющим в Microsoft, Viacom и Juno.

IEEE 830
1. Введение    1.1  Назначение    1.2  Соглашения, принятые в документах   

1.3  Предполагаемая аудитория и рекомендации по чтению    1.4  Границы проекта     1.5  Ссылки

IEEE 830
2. Общее описание    2.1  Общий взгляд на продукт    2.2 

Особенности продукта    2.3  Классы и характеристики пользователей    2.4  Операционная среда    2.5  Ограничения дизайна и реализации    2.6  Документация для пользователей    2.7  Предположения и зависимости

IEEE 830
3. Функции системы    3.x       Функция системы X    3.x.1   Описание и

приоритеты    3.x.2      Последовательности "воздействие - реакция"    3.x.3      Функциональные требования
4. Требования к внешнему интерфейсу    4.1  Интерфейсы пользователя    4.2  Интерфейсы оборудования    4.3  Интерфейсы ПО    4.4  Интерфейсы передачи информации