Внешнее описание программного средства

1. ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО СРЕДСТВА

Назначение и роль в обеспечении качества
программного средства. Определение требований к программному
средству.

2.

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

3.

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

4.

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

5.

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

6.

Исходным документом для разработки внешнего описания ПС является определение
требований к ПС.
Формирование этого документа представляет собой довольно длительный и
трудный итерационный процесс взаимодействия между заказчиком и разработчиком, с
которого и начинается этап разработки требований.
Трудности, возникающие в этом процессе, связаны с несколькими факторами:
1.
пользователи часто плохо представляют, что им на самом деле нужно от готового ПС
2.
применение пс в привычных сферах деятельности пользователей может потребовать
принципиального изменения всей технологии этой деятельности
3.
проблемы, которые необходимо отразить в определении требований, могут не
иметь определенной формулировки (сложность формализации задачи), что в итоге
приводит изменению понимания разработчиками этих проблем.
В связи с этим определению требований часто предшествует процесс системного
анализа, в котором выясняется, насколько целесообразно и реализуемо
"заказываемое" ПС, как повлияет такое ПС на деятельность пользователей и какими
особенностями оно должно обладать.
________________________________________________________________________
? Чем на данном этапе может помочь разработка упрощенной версии требуемого
ПС (прототипирование)

7.

Классификация требований
Важно понимать, что под требованиями — рассматривают описание функциональных возможностей и
ограничений системы.
В разработку требований включают процессы формирования, анализа, документирования и проверки
функциональных возможностей системы.
Для каждого требования важны следующие характеристики:
1.
Четкая выраженность и однозначность
2.
Полнота
3. Непротиворечивость.
Требования должны сопровождаться тестами, подтверждающими его выполнение.
Все возможные требования к ПО делятся на:
- функциональные
- нефункциональные.
Функциональные требования — это перечень сервисов, которые должна предоставлять ПС.
При этом должны быть описана реакция системы на входные данные, поведение системы в тех или иных
ситуациях и т.д.
Нефункциональные требования описывают характеристики системы и ее окружения, а не ее поведение.
Нефункциональные требования к системе тесно связаны с обеспечением качества ПО. Например,
нефункциональными являются требования к производительности системы, быстрому восстановлению после сбоев,
интерфейсу, надежности, доступности и т.д. Особенность нефункциональных требований состоит в том, что их
выполнение трудно проверить. В идеале нефункциональные требования должны иметь количественные показатели.

8.

При разработке и анализе требований можно выделить два основных уровня:
1.
Пользовательские
требования.
Должны
описывать
функциональные
и
нефункциональные системные требования естественным языком с использованием
простых таблиц, а также наглядных и понятных диаграмм. Эти требования должны
определять только внешнее поведение системы
2.
Системные требования. Содержат детализированное описание пользовательских
требований. Они включают в себя максимально полную спецификацию системы в целом.
Системные требования определяют, что должна делать система, не показывая при этом
механизмов реализации. В документе, содержащем требования к системе, желательно
отделять пользовательские требования от более детализированных системных
требований, поскольку понимание последних требует определенных профессиональных
знаний и навыков.
_________________________________________________________________________________
? Составьте для своего программного средства 2 перечня требований:
- Пользовательские
- Системные

9.

Различают четыре основных этапа процесса разработки требований:
1) анализ технической осуществимости создания системы
2)
формирование и анализ требований
3)
специфицирование требований и создание соответствующей документации
4) аттестация требований и процесс управления изменениями системных требований
I.
Анализ технической осуществимости создания системы.( В соответствии с ГОСТ Р
ИСО/МЭК 12207)
Производится анализ создаваемой системы и ее назначения. Для этого определяются
источники информации (менеджеры отделов, разработчики программного обеспечения,
технологи, конечные пользователи и т.д.), затем производится сбор и анализ информации о
будущей системе, определяются решаемые задачи и выбираются технологии реализации.
1)заказчик инициирует процесс заказа, описывая концепцию или потребность в заказе,
разработке или модернизации системы, программного продукта или программной услуги
2)заказчик определяет и анализирует требования к системе.

10.

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

11.

II.
Формирование и анализ требований.
В процессе принимают участие различные группы людей: пользователи, инженерыразработчики, бизнес-менеджеры, специалисты в предметной области.
В связи с этим сложно сформулировать общие требования, потому что каждая сторона
выражает свою точку зрения и интересы. К тому же многие участники процесса могут
выдвигать трудноосуществимые требования, так как не могут адекватно оценить стоимость их
реализации. На этом этапе команда разработчиков ПО совместно с заказчиком и конечными
пользователями системы определяют области применения, системные сервисы, режимы
работы системы и ее характеристики, аппаратные ограничения и т.д.
Поэтому процесс формирования и анализа требований является длительным проходит
через ряд этапов:
1. Анализ предметной области. Аналитики должны изучить предметную область и среду, в
которой будет эксплуатироваться система.
2. Сбор требований. Это процесс формирования требований, в котором участвуют все
заинтересованные лица. При этом продолжается анализ предметной области.
3. Классификация требований. На этом этапе весь набор требований преобразуется в
логически связанные группы.

12.

4. Разрешение противоречий. Требования лиц, занятых в процессе их формирования,
могут быть противоречивыми. На этом этапе определяются и разрешаются обнаруженные
противоречия.
5. Назначение приоритетов. На этом этапе требованиям назначаются приоритеты в
соответствии с важностью задач для бизнес- целей заказчика.
6. Проверка требований. На этом этапе определяется полнота, последовательность и
непротиворечивость требований.
К формированию и анализу требований не существует универсального подхода.
Существуют различные методики и подходы, облегчающие процесс формирования
требований.
1.
Метод, основанный на множестве опорных точек зрения.
При разработке требований выявляются общие интересы и точки зрения участников
процесса создания ПО. При таком подходе происходит идентификация опорных точек зрения
и соответствующих им сервисов. Один и тот же сервис может быть соотнесен с несколькими
точками зрения. Присутствие сервисов, которым не было сопоставлено ни одной опорной
точки зрения, означает, что на начальном этапе некоторые опорные точки зрения не были
идентифицированы. Такой подход позволяет эффективно выявлять противоречия в
требованиях, предложенных различными лицами. Далее происходит обобщение мнений,
связанных с каждой опорной точкой зрения, и разрешение возникших противоречий.

13.

2. Метод построения сценариев.
Как правило, воспринимать абстрактное описание системы гораздо сложнее, чем сценарий
взаимодействия с ней. В процессе обсуждения сценариев формулируются новые требования и
детализируются уже существующие. Обычно сценарий состоит из начального описания состояния
системы, описания нормального протекания событий, описания исключительных ситуаций и
способов их обработки, информации относительно других действий, которые можно
осуществлять во время выполнения сценария, а также описания состояния системы после
завершения сценария. В качестве способов описания сценариев может использоваться
диаграмма прецедентов (use case diagram) или неформальное описание сценариев на
естественном языке.
3.Этнографический метод.
Учет социальных и организационных требований при создании ПО часто имеет большое
значение для успеха системы на рынке. При использовании этнографического подхода
разработчики требований погружаются в среду, в которой будет эксплуатироваться создаваемое
ПО, с целью выявления неявных требований к системе, которые отражают реальные аспекты ее
эксплуатации, а не формальные умозрительные процессы. Этнографический подход позволяет
детализировать требования для критических систем, чего не всегда можно добиться другими
методами разработки требований.
______________________________________________________________________
?Определите положительные и отрицательные аспекты 3- х методов. Каким образом
можно минимизировать отрицательные стороны при использовании какого-либо метода