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