Практическая №4. ПР №3. Практическая работа 3 Тема работы Систематизация и формализация требований, предъявляемых к программной системе Цель работы
 Скачать 38.05 Kb.
|
Практическая работа №3Тема работы: «Систематизация и формализация требований, предъявляемых к программной системе» Цель работы Научиться производить систематизацию и формализовать требования, предъявляемые к программной системе. Задание Произвести систематизацию и формализовать требования, предъявляемые к программной системе, индивидуальное задание, соответствует заданию из практической работы № 1. Оснащение работы Технические средства обучения: IBM – совместимый компьютер; Электронные средства обучения: MS Office, СМИ, сеть Интернет Основные теоретические сведения Управление требованиями — это процесс управления изменениями системных требований. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется на то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова. Определения свойств программного продукта осуществляется с помощью двух основных категорий – требований (необходимых свойств) и спецификаций (описания объекта, обладающего этими свойствами). При описании требований используются такие понятия, как качество, возможности или др. характеристики продукта (системы), предполагаемого его (ее) использования или среды. Существуют несколько типов требований: 1 Функциональные требования – определяют работу, которую должно выполнять программное приложение (например, "приложение будет вычислять стоимость портфеля акций пользователя"). С другой стороны, требование, такое как "приложение будет выполнять вычисление стоимости каждого портфеля акций менее чем за одну секунду" не является функциональным, поскольку оно не определяет конкретную работу. Вместо этого оно оценивает работу или работы (определяет некоторое утверждение о работе). 2 Нефункциональные требования 1) Производительность: – скорость; – пропускная способность (трафик); – использование памяти (оперативная память, жесткий диск). Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использование оперативной памяти, использование вспомогательных запоминающих устройств и т. д. Например: для любой балки Анализатор давления должен создать отчет типа 5 о давлении менее чем за минуту. Требования к производительности являются важной частью приложений, работающих в реальном времени, в которых действия должны уложиться в предопределенные временные рамки. Примерами приложений реального времени могут быть программы избежания столкновений, контроля полетов и антиблокировочной тормозной системы. 2) Надежность и доступность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Например: приложение, управляющее радарами аэропорта, должно давать не более двух ошибок в месяц. Доступность, близкая по смыслу надежности, оценивает степень, в которой приложение должно быть доступно пользователям. Например: приложение, управляющее радарами аэропорта, должно быть доступно на уровне один или два постоянно как на основном, так и па запасном компьютере. Оно может быть недоступно на одном из этих компьютеров на уровне один или два не более 2% времени в любой 30-дневный период. 3) Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой. В некоторых случаях обработка ошибок относится к действиям, которые должна предпринять программа, если она сама создала ошибку из-за дефекта в своей конструкции. Этот тип требований к ошибкам должен быть использован выборочно, поскольку основной целью является создание безошибочных программ, а не исправление ошибок с помощью бесконечного кода обработки ошибок. Например, нужно определить требования для прибора, который автоматически определяет дозы лекарств для внутривенного введения больному. Можно сделать предположение, что программа будет тщательно определена, разработана, реализована и проверена с тем, чтобы состав лекарств и дозы были корректными. Однако было бы правильно в таком случае определить независимую проверку состава и дозы лекарств перед его выпуском в кровь и соответствующим образом определить обработку ошибок. В итоге, проверка ошибок в самой программе уместна только для критичных частей программы. 4) Интерфейсные требования – поясняют, как программа взаимодействует с пользователем и с другими программами. Интерфейсные требования описывают формат, в котором программа общается с окружением. Например: Стоимость посылки статьи от адресата получателю должна постоянно показываться в текстовом окне "Цена". Формат, используемый для передачи сообщений "Ожидаемая статья" для взаимодействия с почтовыми кампаниями, будет представлять собой строку вида exp В первом примере показано требование пользователей программы. Второе предоставляет формат сообщения для обмена информацией с другими программами. Оба требования являются интерфейсными. 5) Ограничения: – точность; – ограничения на используемые инструменты и язык программирования; – ограничения проектирования; – стандарты, которые должны быть использованы; – платформы, которые должны быть использованы. Ограничения на проектирование или реализацию описывает границы или условия того, как приложение должно быть задумано и разработано. Эти требования не должны использоваться вместо процесса проектирования – они всего лишь определяют условия, наложенные на проект заказчиком, а также окружение или другие обстоятельства. Например, сюда можно отнести точность: вычисления оценки ДТП системой AEF должны быть выполнены с точностью до одного сантиметра. 3 Обратные требования – Обратные требования определяют, чего программа не будет делать. Существует бесконечное число обратных требований: выбираются только те, которые разъясняют возможное непонимание. Например: система AEF не обязательно должна анализировать данные ДТП. Спецификация требований - это спецификация для определенного программного изделия, программы или набора программ, которые выполняют определенные функции в специфической среде. Спецификация требований может составляться одним или более представителями поставщика, одним или более представителями заказчика, или обоими. Предпочтительнее участие обоих. Основными вопросами, которые должны рассматривать составитель (-ли) спецификации требований, являются следующие: Функциональные возможности. Каковы предполагаемые функции программного обеспечения? Внешние интерфейсы. Как программное обеспечение взаимодействуют с пользователями, аппаратными средствами системы, другими аппаратными средствами и другим программным обеспечением? Рабочие характеристики. Каково быстродействие, доступность, время отклика, время восстановления различных функций программного обеспечения и т.д.? Атрибуты. Каковы мобильность, правильность, удобство сопровождения, защищенность программного обеспечения и другие критерии? Проектные ограничения, налагаемые на реализацию изделия. Существуют ли требуемые стандарты на эффективном языке реализации, политика по сохранению целостности баз данных, ограничения ресурсов, операционная среда(-ы) и т.д.? Спецификация требований к ПО: а) Должна правильно определять все требования к программному обеспечению. Причиной существования какого-либо требования к программному обеспечению может являться характер решаемой задачи или особая характеристика проекта. б) Не должна описывать детали разработки или реализации. Они должны быть описаны на этапе разработки проекта. в) Не должна налагать дополнительные ограничения на программное обеспечение. Эти ограничения надлежащим образом определяются в других документах, таких как план обеспечения качества программных средств. Правильно составленная спецификация требований к ПО должна быть: а) Корректной; Спецификация требований к ПО является корректной, если, и только, если каждое требование, изложенное в ней, является требованием, которому должно удовлетворять программное обеспечение. Не существует какого-либо средства или процедуры, которое гарантирует корректность. Спецификация требований к ПО должна сравниваться с любой качественной применимой спецификацией, такой как спецификация требований к системе, с другой документацией проекта и с другими применимыми стандартами, и должна гарантировать согласованность. В качестве альтернативы заказчик или пользователь может определить, правильно ли спецификация требований к ПО отражает фактические потребности. б) Однозначной; Спецификация требований к ПО является однозначной, если и только, если каждое изложенное в ней требование может интерпретироваться только однозначно. Как минимум, для этого требуется, чтобы каждая характеристика конечного продукта была описана с использованием одного уникального термина. В тех случаях, когда термин, используемый в специфическом контексте, может иметь множественные значения, этот термин должен быть включен в глоссарий, в котором его значение описывается более конкретно. Спецификация требований к ПО должна быть однозначной как для тех, кто составляет ее, так и для тех, кто ее использует. Однако, эти группы часто не имеют одинаковую квалификацию и, следовательно, не имеют тенденции к описанию требований к программному обеспечению одним и тем же образом. Способы представления требований, которые улучшают спецификацию требований для разработчика, могут оказаться неэффективными в том, что они уменьшают их понимание пользователем, и наоборот. в) Полной; Спецификация требований к ПО является полной, если и только, если она включает следующие элементы: Все существенные требования, независимо от того, относятся ли они к функциональным возможностям, рабочим характеристикам, проектным ограничениям, атрибутам или внешним интерфейсам. В частности, должны быть подтверждены и обработаны любые внешние требования, налагаемые спецификацией системы. Определение откликов программного обеспечения на все классы входных данных, которые могут быть реализованы, во всех возможных ситуациях. Следует заметить, что важно определить отклики, как на допустимые, так и недопустимые входные значения. Полные обозначения и ссылки на все рисунки, таблицы и схемы в спецификации требований к ПО и определение всех терминов и единиц измерения. г) Непротиворечивой; Непротиворечивость обозначает внутреннюю непротиворечивость. Если спецификация требований к ПО не согласовывается с каким-то документом более высокого уровня, таким как, например, спецификации системных требований, то она является некорректной. д) Упорядоченной по ее значимости и/или устойчивости; Спецификация требований к ПО является упорядоченной по значимости и/или устойчивости, если каждое требование в ней имеет идентификатор, указывающий или значимость или устойчивость этого конкретного требования. Как правило, все требования, которые касаются программного изделия, не являются важными в равной степени. Некоторые требования могут быть необходимыми, особенно для приложений, критичных в течение жизненного цикла, в то время как другие могут быть желательными. Каждое требование в спецификации требований к ПО должно быть идентифицировано, чтобы сделать эти различия четкими и явными. Идентификация требований следующим образом помогает: 1) заказчикам более тщательно рассмотреть каждое требование, что часто позволяет разъяснить любые скрытые допущения, которые могут быть заключены в них. 2) разработчикам принять правильные проектные решения и приложить соответствующие усилия к различным составляющим программного изделия. е) Проверяемой; Спецификация требований к ПО является проверяемой, если и только, если каждое требование, изложенное в ней, может быть проверено. Требование являются проверяемым, если и только, если существует некий конечный эффективный процесс, используя который пользователь или машина могут убедиться, что программное изделие удовлетворяет этому требованию. В целом, любое неоднозначное требование не проверяемо. Непроверяемые требования включают формулировки типа "работает хорошо", "хороший интерфейс с пользователем" и "обычно должно происходить". Эти требования не могут быть проверены, так как невозможно определить термины "хороший", "хорошо" или "обычно". Утверждение о том, что "программа никогда не должна зацикливаться" является непроверяемым, так как тестирование этого свойства теоретически невозможно. Примером проверяемого утверждения является следующее: Выходные данные программы должны вырабатываться в пределах 20 секунд в течение 60 % временного интервала события; и должны вырабатываться в пределах 30 секунд в течение 100 % временного интервала события. Это утверждение может быть проверено, так как в нем используются конкретные термины и измеримые величины. Если нельзя изобрести метод, чтобы определить, отвечает ли программное обеспечение определенному требованию, то это требование следует исключить или пересмотреть. ж) Модифицируемой; Спецификация требований к ПО является модифицируемой, если и только, если ее структура и стиль таковы, что любые изменения требований могут быть выполнены легко, полностью и непротиворечивым образом при сохранении структуры и стиля. Как правило, модифицируемость требует, чтобы спецификация требований: 1) Имела связанную и легкую в использовании структуру с оглавлением, алфавитным указателем и явно выраженными перекрестными ссылками; 2) Не была избыточной (то есть, одно и то же требование не должно появляться в спецификации требований более чем в одном месте); 3) Выражала каждое требование раздельно, не смешивая его с другими требованиями. Избыточность сама по себе не является ошибкой, но она легко может привести к появлению ошибок. Иногда избыточность может помочь сделать спецификацию требований более читаемой, но тогда могут возникнуть проблемы при модификации избыточного документа. Например, требование может быть изменено только в одном из тех мест, где оно появляется. Тогда спецификация требований становится противоречивой. Каждый раз, когда избыточность необходима, спецификация требований должна включать явные перекрестные ссылки, чтобы сделать ее модифицируемой. з) Отслеживаемой. Спецификация требований к ПО является отслеживаемой, если четко прослеживается источник каждого из ее требований и если она облегчает обращение к каждому из требований при дальнейшей разработке или модернизации документации. Рекомендуются следующие два типа отслеживаемости: Обратная отслеживаемость (то есть, к предыдущим стадиям разработки). Зависит от каждого требования, которое в явном виде ссылается на его источник в более ранних документах. Прямая отслеживаемость (то есть, ко всем документы, порождаемым спецификацией требований. Зависит от каждого требования в спецификации требований, имеющего однозначно определенное имя или номер ссылки. Прямая отслеживаемость спецификации требований особенно важна, когда программное изделие вступает в стадию функционирования и сопровождения. По мере изменения кода и проектных документов необходимо иметь возможность определить полный набор требований, на которые могут повлиять эти изменения. Порядок выполнения работы Изучить основные сведения, содержащиеся в методических рекомендациях (пункт 4); Согласно сформированных требований и разработанной постановке задачи в практической работе №1, произвести систематизацию и формализовать требования, предъявляемые к программной системе. Пример спецификации требований к программному обеспечению1. ОПИСАНИЕ БИЗНЕС-ПРОЦЕССА В данном подразделе рассматривается спецификация требований к системе регистрации для учебного заведения, бизнес-модель которого описана в подразд. 3.3.2. Уточненная постановка задачи для системыПеред руководителем информационной службы университета ставится задача разработки автоматизированной системы регистрации студентов на дополнительные платные курсы. Система должна позволить студентам регистрироваться на курсы и просматривать свои табели успеваемости с персональных компьютеров, подключенных к локальной сети университета. Профессора должны иметь доступ к системе, чтобы указать курсы, которые они будут читать, и проставить оценки за курсы. Из-за недостатка средств университет не в состоянии заменить всю существующую систему. Остается функционировать в прежнем виде база данных, содержащая всю информацию о курсах (каталог курсов). Эта база данных поддерживается реляционной СУБД. Новая система будет работать с существующей БД в режиме доступа, без обновления. В начале каждого семестра студенты могут запросить каталог курсов, содержащий список курсов, предлагаемых в данном семестре. Информация о каждом курсе должна включать имя профессора, наименование кафедры и требования к предварительному уровню подготовки (прослушанным курсам). Новая система должна позволять студентам выбирать 4 курса в предстоящем семестре. В дополнение к этому, каждый студент может указать 2 альтернативных курса на тот случай, если какой-либо из выбранных им курсов окажется уже заполненным или отмененным. На каждый курс может записаться не более 10 и не менее 3 студентов (если менее 3, то курс будет отменен). В каждом семестре существует период времени, когда студенты могут изменить свои планы (добавить или отказаться от выбранных курсов). После того, как процесс регистрации некоторого студента завершен, система регистрации направляет информацию в расчетную систему, чтобы студент мог внести плату за семестр. Если курс окажется заполненным в процессе регистрации, студент должен быть извещен об этом до окончательного формирования его личного учебного плана. В конце семестра студенты должны иметь доступ к системе для просмотра своих электронных табелей успеваемости. Поскольку эта информация конфиденциальная, система должна обеспечивать ее защиту от несанкционированного доступа. Глоссарий проекта Термин Значение Курс Учебный курс, предлагаемый университетом Конкретный курс Конкретное чтение данного курса в конкретном семест- ре (один и тот же курс может вестись в нескольких парал- лельных сессиях). Каталог курса Полный каталог всех курсов, предлагаемых университетом Расчетная система Система обработки информации об оплате за курсы. Оценка Оценка, полученная студентом за конкретный курс. Профессор Преподаватель университета. Табель успеваемости Все оценки за все курсы, полученные студентом в данном семестре. Список курса Список всех студентов, записавшихся на конкретный курс. Студент Личность, проходящая обучение в университете. Учебный график Курсы, выбранные студентом в текущем семестре. 2. Начальная версия требований к создаваемой ИСОписание спецификацийФункциональные возможности: Система должна обеспечивать многопользовательский режим работы. Если конкретный курс оказывается заполненным в то время,, когда студент формирует свой учебный график, включающий данный курс, то система должна известить его об этом. Удобство использования: Пользовательский интерфейс должен быть Windows – совместным. Надежность. Система должна быть в работоспособном состоянии 24 часа в день 7 дней в неделю, время простоя – не более 10%. Производительность. Система должна поддерживать до 2000 одновременно работающих с центральной базой данных пользователей и до 500 пользователей, одновременно работающих с локальными серверами. Безопасность. Система не должна позволять студентам изменять любые учебные графики, кроме своих собственных, а также не должна позволять профессорам модифицировать конкретные курсы, выбранные другими профессорами. Только профессора имеют право ставить студентам оценки. Только регистратор может изменять любую информацию о студентах. Проектные ограничения. Система должна быть интегрирована с существующей системой каталога курсов, функционирующей на основе реляционной СУБД. Форма отчета о работе Практическая работа №3 Номер учебной группы ___________________________________________________________ Фамилия, инициалы обучающегося _________________________________________________ Дата выполнения работы ________________________________________________________ Тема работы: Систематизация и формализация требований, предъявляемых к программной системе Цель работы: Научиться производить систематизацию и формализовать требования, предъявляемые к программной системе Задание: Произвести систематизацию и формализовать требования, предъявляемые к программной системе и обсудить с преподавателем и учащимися группы сформированное требования. Индивидуальное задание ___________________________________________________________________________ Оснащение работы: Инструкция по выполнению практической работы №3, IBM – совместимый компьютер, MS Office, СМИ, сеть Интернет Результаты выполнения работы: ___________________________________________________________________________ ___________________________________________________________________________ Контрольные вопросы и задания 1. Что такое управление требованиями? 2. Какие типы требований существуют? 3. Что такое функциональные требования? 4. Что такое нефункциональные требования? 5. Что такое интерфейсные требования? 6. Что такое обратные требования? 7. Из каких этапов состояит процесс управления изменениями? Рекомендуемая литература Боэм, Б. У. Инженерное проектирование программного обеспечения/ Б. У. Боэм; пер. англ. М.:Радио и связь, 1985. Вендров, А.М. Проектирование программного обеспечения экономических информационных сетей: учеб. / А. М. Вендров. М.:Финансы и статистика, 2000. Липаев, В.В. Системное проектирование сложных программных средств для информационных систем/ В.В. Липаев. М.: СИНТЕГ, 1999. Марка, Д.А. Методология структурного анализа и проектирования/ Д. А. Марка, К. Мак Гоуэн. М. :МетаТехнология, 1993. Петров, В.Н. Информационные системы/ В.Н. Петров. СПб.:Питер, 2002 |