ППК л2 2011

1,144 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,144
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ППК л2 2011

  1. 1. Проектирование программных комплексов<br />Лекция 2<br />Спецификация требований.<br />ssau.ppk@gmail.com<br />
  2. 2. Самостоятельная работа № 1<br />Тема.<br />Современные проблемы разработки ПО(личный взгляд)<br />Объем 3-4 страницы, время выполнения – 2недели<br />до 23:59 , 3марта 2011 г.<br />файл назвать: СР1-№гр-ФамилияИО-MMDD.doc (docx, pdf, rtf)дата отправления файла<br />например: СР1-678-КуприяновАВ-0228.doc <br />все буквы русские, без пробелов,разделитель тире.<br />Тема письма совпадает с названием файла.<br />Письма с неверным заголовком попадут в спам и оцениваться не будут.<br />Описать существующие возможности и технологии. Привести пример. Обратить внимание на описание достоинств и недостатков. Выделить основные проблемы и трудности. Отразить личный взгляд на развитие.<br />2/36<br />
  3. 3. Самостоятельная работа № 1<br />Требования:<br />Введение – о чем пойдет речь, обосновать свой выбор.<br />Актуальность – описываемые технологии используются в настоящее время, проблемы также актуальны, подтвердить ссылками на источники.<br />Источники – не менее 3х (не считая википедии), в тексте присутствуют ссылки на каждый источник.<br />Заключение – о чем шла речь, выводы.<br />Релевантность – содержание соответствует теме самостоятельной работы.<br />Самостоятельность – отражено личное мнение автора.<br />Оформление – текст форматирован, выравнивание, расстановка переносов, рисунки и таблицы.<br />Содержание – общая оценка качества работы.<br />Бонус – уникальность содержания, особенности оформления.<br />Штраф – мало текста, отсутствие самостоятельности.<br />3/36<br />
  4. 4. Внешнее описание ПС<br />Разработка ПС начинается с этапа формулирования требований к ПС, на котором, исходя из довольно смутных пожеланий заказчика, должен быть получен документ, достаточно точно определяющий задачи разработчиков ПС.<br /> Этот документ называется внешнее описание ПС (в литературе его часто называют спецификацией требований –Software Requirements Specification SSS)<br />4/36<br />
  5. 5. Разработка внешнего описания<br />Внешнее описание ПС играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. <br />Оно должно содержать всю информацию, которую необходимо знать пользователю для применения ПС.<br />Внешнее описание ПС является исходным документом для трех параллельно протекающих процессов: <br />разработка текстов программ, входящих в ПС, <br />разработка документации по применению ПС <br />разработка существенной части комплекта тестов для тестирования ПС. <br />Ошибки и неточности во внешнем описании трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три параллельных процесса.<br />5/36<br />
  6. 6. Определение требований<br />является исходным документом разработки ПС – заданием, выражающим в абстрактной форме потребности пользователя. <br />определяет замысел ПС<br />характеризует условия использования ПС. <br />Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. <br />Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, математически). <br />6/36<br />
  7. 7. Понимание требований<br />Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования. <br />Одной из важных задач при определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. <br />Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними. <br />7/36<br />
  8. 8. Способы определения требований<br /> управляемый пользователем, <br /> контролируемый пользователем, <br /> независимый от пользователя.<br />8/36<br />
  9. 9. Компоненты внешнего описания<br />Две самостоятельные части внешнего описания ПС.<br />Функциональная спецификация ПС – описание поведения ПС и определение функций, которые должна выполнять ПС. ФС определяет допустимые фрагменты программ, реализующих декларированные функции. <br />Спецификация качества ПС – формулировка требований к качеству ПС, так, чтобы разработчику были ясны цели которые он должен стремиться достигнуть при разработке этого ПС. СК в отличие от функциональной спецификации, реализуется неформализованно и играет роль тех ориентиров, которые в значительной степени определяют выбор подходящих альтернатив при реализации функций ПС, а также определяет стиль всех документов и программ разрабатываемого ПС. Тем самым, спецификация качества играет решающую роль в обеспечении требуемого качества ПС. <br />9/36<br />
  10. 10. Необходимость внешнего описания<br />Внешнее описание определяет, что должно делать ПС и какими внешними свойствами оно должно обладать. <br />Оно не отвечает на вопрос, как должно быть устроено это ПС и как обеспечить требуемые его внешние свойства. <br />Оно должно достаточно точно и полно определять задачи, которые должны решить разработчики требуемого ПС.<br />Оно должно быть понято представителем пользователем - на его основании заказчиком достаточно часто принимается окончательное решение на заключение договора на разработку ПС. <br />Внешнее описание играет большую роль в обеспечении требуемого качества ПС, так как спецификация качества ставит для разработчиков ПС конкретные ориентиры, управляющие выбором приемлемых решений при реализации специфицированных функций. <br />10/36<br />
  11. 11. Контроль внешнего описания<br />Разработка внешнего описания обязательно должна завершаться проведением тщательного и разнообразного контроля правильности внешнего описания. Целью этого процесса является найти как можно больше ошибок, сделанных на этом этапе. <br />Можно выделить следующие методы контроля, применяемые на этом этапе: <br />статический просмотр, <br />смежный контроль, <br />пользовательский контроль, <br />ручная имитация.<br />11/36<br />
  12. 12. Функциональная спецификация<br />Функциональная спецификация состоит из трех частей: <br />описание внешней информационной среды, к которой должны применяться программы разрабатываемой ПС; <br />определение функций ПС, определенных на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС); <br />описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы;<br />12/36<br />
  13. 13. Спецификация требований<br />«Спецификация Требований к ПО» SoftwareRequirementsSpecification (SRS) описывает поведение системы и ее функционал используя функциональные требования. <br />Документация SRS дополнительно должна содержать нефункциональные требования, или требования к качеству сервиса.<br />13/36<br />
  14. 14. Спецификация требований<br />Функциональные требования определяют, какие функции система должна реализовывать и предоставлять пользователям или внешним системам.<br /> Функциональные требования обычно представляют в виде вариантов использования (Use Case). <br />могут определять требования как к внешнему функционалу (видимому пользователям и внешним системам)<br />так и к внутреннему функционалу (внутренние сервисы системы, например, аудит изменений, журнал событий и т.п.)<br />14/36<br />
  15. 15. Спецификация требований<br />Нефункциональные требования, или требования к качеству, определяют ограничения, накладываемые на функциональные требования к системе, или условия, в которых система должна будет функционировать. <br />Примеры нефункциональных требований: пропускная способность сети, производительность системы, доступность, условия лицензирования и т.п.<br />15/36<br />
  16. 16. Структура спецификации<br />Название документа и его версия; <br />Название проекта и код; <br />История Изменения Документа: <br /> дата, автор, краткое описание изменения, измененные разделы; <br />Список Согласования: <br /> ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены); <br />Оглавление; <br />Перечень Рисунков; <br />Перечень Таблиц; <br />16/36<br />
  17. 17. Структура спецификации<br />Введение: <br /> краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации; <br />Функциональные Требования:<br />Нефункциональные Требования:<br />Предположения и Ограничения: <br /> результаты уточнения деталей реализации требований, которые по явным причинам не были указаны ранее, должны быть указаны в этом разделе; <br />Открытые Вопросы: <br /> все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты; <br />Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).<br />17/36<br />
  18. 18. Структура спецификации<br />Функциональные Требования:<br />1) Код и название требования;<br />2) Описание;<br />3) Входные/Выходные Данные;<br />4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;<br />5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;<br />6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Зависимости Требований». В этом случае данную секцию можно опустить; <br />Нефункциональные Требования:<br />1) Код и название требования;<br />2) Описание; <br />18/36<br />
  19. 19. Описание требований<br />Каждое требование должно: <br />быть четко выражено;<br />быть легко доступно; <br />быть пронумеровано;<br />сопровождаться подтверждающими тестами;<br />предусматриваться проектом;<br />быть учтено кодом;<br />быть протестировано отдельно;<br />быть протестировано вкупе с другими требованиями;<br />быть подтверждено тестированием после того, как выполнена сборка приложения.<br />19/36<br />
  20. 20. Язык описания требований<br />При написании требований существенном образом позволяет облегчить последующее понимание требований и их классификацию следование некоторым рекомендациям:<br />использование четкого и ясного языка и согласованных терминов (словарь данных и т.п.)<br />применение в тексте слова «должен» (должна, должно), как ключевого слова, обозначающего наличие требования. <br />для характеристики приоритета требований употребление отличающихся ключевых слов, например - «должно», «рекомендуется» и «возможно».<br />использование варианты языка соответствующих «уровню» документа с требованиями, поскольку существует принципиальное отличие между пользовательскими требованиями, которые относятся к проблемной области, и системными требованиями, которые относятся к области решений.<br />20/36<br />
  21. 21. Описание пользовательских требований<br />С –требования в основном описывают возможности (услуги), необходимые пользователям (т.е. потребности пользователей), или ограничения, связанные с этими возможностями или потребностями. <br />Требование, описывающее такую потребность, должно описывать только одну потребность, необходимую или для одного пользователя, или группы из нескольких однотипных пользователей.<br />Образец:<br /> <Тип пользователя> должен иметь возможность <описание возможности><br />Если существуют определенные требования к производительности или ограничения, связанные только с одним конкретным требованием, то, в этом случае, текст требования может быть дополнен:<br /><Тип пользователя> должен иметь возможность <описание возможности> с <показатель производительности> от <момент отсчета>, находясь в <условия эксплуатации><br />Пример: <br />Оператор должен иметь возможность произвести выстрел в течение 3 секунд с момента обнаружения цели радаром, находясь в сложных морских условиях<br />21/36<br />
  22. 22. Описание требований - ограничений<br />Обычно ограничения в пользовательских требованиях упоминаются или как минимально приемлемые параметры производительности, заявляемые заказчиком, или являются следствием необходимости взаимодействия создаваемой системы с окружением (сюда же, что характерно, относятся правовые и социальные системы). <br />Требование типа ограничение обычно выражается в следующей форме:<br /><Тип пользователя> не должен попадать под действие <соответствующее ограничение><br />Пример из реальной жизни:<br />Водитель скорой помощи не должен подпадать под действие законодательства, предусматривающего ответственность за нарушение правил дорожного движения.<br />22/36<br />
  23. 23. Описание системных требований<br /> Конкретная формулировка зависит также от типа ограничения или показателя производительности, которые связаны с этим требованием.<br />Образец:<br /><Система> должна <выполняемая функция> не менее чем <количество> <объект> функционируя в <условия эксплуатации>.<br />Пример:<br /> Телекоммуникационная система должна обеспечивать телефонную связь не менее чем с 10 абонентами, функционируя в условиях отсутствия внешнего источника электропитания<br />Приведем другой образец, описывающий периодическое ограничение:<br /><Система> должна <выполняемая функция> <объект> каждые <показатель производительности> <единица измерения><br />Пример:<br />Кофе-машина должна производить горячий напиток каждые 10 секунд.<br />23/36<br />
  24. 24. Шаблоны требований<br />Использование шаблонов, как это показано на примерах, является хорошим способом стандартизации языка, применяемого для разработки требований. <br />Чтобы иметь возможность писать стандартным способом требования различных типов, необходимо просто собрать определенный набор таких шаблонов. <br />В процессе применения этого набора на практике, он может уточняться, расширяться и корректироваться с тем, чтобы получить более полный набор шаблонов, который в дальнейшем может даже использоваться и в других проектах.<br />Таким образом, процесс создания требований с помощью шаблонов может быть разбит на два этапа:<br />выбор наиболее подходящего шаблона из общего набора шаблонов;<br />подстановка конкретных данных для заполнения пустующих полей в шаблоне.<br />24/36<br />
  25. 25. Примеры шаблонов<br />25/36<br />
  26. 26. Критерии написания требований<br /> Независимо от языковых аспектов написания требований, существуют четкие критерии, которым должна удовлетворять формулировка каждого требования.<br />Атомарность: каждое утверждение (формулировка требования) должно представлять собой один элемент иерархии, пригодный для установки связей с ним;<br />Уникальность: каждое требование должно иметь собственный уникальный идентификатор;<br />Выполнимость: требование должны быть технически реализуемо в установленные сроки, в рамках выделенного бюджета;<br />Ясность: требование должно быть понятно сформулировано (исключать неоднозначное толкование);<br />Точность: требование должно быть точным и лаконичным;<br />Проверяемость: должна существовать возможность проверки реализации каждого конкретного требования;<br />Абстрактность: формулировка не должна навязывать определенные технические решения, характерные для более низких уровней требований (спецификаций).<br />26/36<br />
  27. 27. Критерии написания требований<br />Дополнительно можно привести критерии, применимые к набору требований:<br />Полнота: все необходимые требования зафиксированы;<br />Непротиворечивость: не существует требований, противоречащих друг другу;<br />Отсутствие избыточности: каждое требование сформулировано только один раз (нет повторов);<br />Модульность: требования, близкие друг другу по смыслу, содержаться в одном разделе;<br />Структурированность: наличие ясной и четкой структуры документа с требованиями;<br />Удовлетворенность: достигнут требуемый уровень покрытия требований связями типа «удовлетворяется (посредством)»<br />Тестируемость: достигнут требуемый уровень покрытия требований тестами.<br />27/36<br />
  28. 28. Нефункциональные требований<br />Производительность:<br /> ♦ скорость;<br /> ♦ пропускная способность (трафик);<br /> ♦ использование памяти (оперативная память, жесткий диск).<br />Надежность и доступность.<br />Обработка ошибок.<br />Интерфейсные требования.<br /> Как программа взаимодействует с пользователем и с другими программами.<br />Ограничения:<br /> ♦ точность;<br /> ♦ ограничения на инструменты и язык;<br /> ♦ ограничения проектирования;<br /> ♦ стандарты, которые должны быть использованы;<br /> ♦ платформы, которые должны быть использованы.<br />28/36<br />
  29. 29. Спецификация качества<br />Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством.<br />Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. <br />Не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их высшей возможной степени, поскольку повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения и снижения качества этого ПС по другим его свойствам. <br />Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование. <br />Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. <br />29/36<br />
  30. 30. Критерии качества<br />В настоящее время критериями качества ПС принято считать: <br />Функциональность – это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС. <br />Надежность – это способность ПС безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью <br />Легкость применения – это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя. <br />Эффективность – это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов. <br />Сопровождаемость – это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей. <br />Мобильность – это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую. <br />30/36<br />
  31. 31. Примитивы качества<br /> Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС, однозначно интерпретируемых разработчиками – примитивы качества ПС. <br />Завершенность – свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций. <br />Точность – мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования. <br />Автономность – свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения. <br />Устойчивость – свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных. <br />Защищенность – свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя. <br />31/36<br />
  32. 32. Примитивы качества<br />Информативность – свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений , существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования. <br />Понятность – свойство, характеризующее степень в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации.<br />Расширяемость – свойство, характеризующее способность ПС к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент. <br />Модульность – свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.<br />Эффективность – мера, характеризующая способность ПС выполнять возложенные на него функции при определенных ограничениях. <br />Независимость от устройств – свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении <br />32/36<br />
  33. 33. Снова о понятии «правильной» программы<br />Альтернативой «правильного» ПС является надежное ПС. <br />Надежное ПС не исключает наличия в ней ошибок – важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. <br />Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. И фактически мы можем разрабатывать лишь надежные, а не правильные ПС. <br />Разрабатываемая ПС может обладать различной степенью надежности.<br />Для характеристики степени надежности можно использовать:<br />вероятность работы ПС без отказа в течении определенного периода времени. <br />последствия каждого отказа. <br />вред для пользователя, поскольку одни ошибки в ПС могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. <br />33/36<br />
  34. 34. Проверка требований<br /> Требования, полученные от пользователей, <br /> могут дублироваться или противоречить друг другу. <br /> могут быть неясными, нереальными или могут остаться невыясненными. <br />Согласование и проверка обоснованности требований осуществляется параллельно с выявлением требований и не могут быть отделены от процесса подготовки документа описания требований. <br />Требования, перечисленные в черновом варианте документа, обсуждаются и при необходимости модифицируются. Побочные требования удаляются. Вновь выявленные требования добавляются.<br />Для проверки обоснованности требований (requirementsvalidation) необходима более полная версия документа, в котором все требования четко идентифицированы и классифицированы. Участники проекта изучают документ и проводят совещания по их формальному пересмотру. <br />34/36<br />
  35. 35. Матрица зависимости требований<br /> Матрица зависимостей требований (requirementsdependencymatrix) или матрица взаимодействия (interactionmatrix требований). <br />В столбце и строке заголовка перечислены упорядоченные идентификаторы требований.<br />Верхняя правая часть матрицы (над диагональю включительно) не используется. <br />Оставшиеся ячейки указывают на то, перекрываются ли два любых требования, противоречат друг другу или независимы друг от друга (пустые ячейки). <br />Противоречивые требования необходимо обсудить с заказчиками и при возможности переформулировать для смягчения противоречий (фиксацию противоречия, видимую для последующей разработки, необходимо сохранить). <br />Перекрывающиеся требования также должны быть сформулированы заново, чтобы исключить совпадения.<br />Матрица зависимости требований представляет собой простой, но эффективный метод обнаружения противоречий перекрытий, когда количество требований относительно невелико. В противном случае описанный метод все же можно применить, если удается сгруппировать требования по категориям, а затем сравнить их отдельно в пределах каждой категории.<br />35/36<br />
  36. 36. Связанность и согласованность требований<br /> При работе с большими наборами требований достаточно трудно идентифицировать те требования, которые могут противоречить друг другу. <br />Необходимо иметь возможность классифицировать, фильтровать и сортировать требования с тем, чтобы иметь возможность получать относительно небольшую выборку требований, относящихся к одной теме, для последующего анализа.<br />Для поддержания такой возможности требования должны иметь первичную и вторичную классификацию. <br />Обычно каждое требование имеет единственную первичную классификацию (например, его месторасположение в контексте документа) и множественное количество вторичных классифицирующих свойств, использующих возможности атрибутов и связей.<br /> Эта техника существенным образом помогает находить все связанные между собой по смыслу требования с помощью фильтрации и сортировки по ключевым словам и используя признаки основной и дополнительных классификаций.<br /> Например, вначале, чтобы сузить поле возможного поиска, вы строите выборку всех требований, относящихся к безопасности. А затем уже, среди отобранных, вы анализируете схожие требования на предмет наличия конфликтов между ними.<br />36/36<br />

×