|
|
Фонд оценочных средств профессионального модуля
Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения ее в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечет за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.
Во время процесса аттестации должны быть выполнены различные типы проверок требований.
Проверка правильности требований. Пользователь может считать, что система необходима для выполнения некоторых определенных функций. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций. Системы предназначены для разных пользователей с различными потребностями, и поэтому набор требований будет представлять собой некоторый компромисс между требованиями пользователей системы.
Проверка на непротиворечивость. Спецификация требований не должна содержать противоречий. Это означает, что в требованиях не должно быть противоречащих друг другу ограничений или различных описаний одной и той же системной функции.
Проверка на полноту. Спецификация требований должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.
Проверка на выполнимость. На основе знания существующих технологий требования должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы.
Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности.
Обзор требований. Требования системно анализируются рецензентами.
Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.
Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.
Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.
Пользовательские и системные требования
На основании полученных моделей строятся пользовательские требования, т.е. как было сказано в начале описание на естественном языке функции, выполняемых системой, и ограничений, накладываемых на неё.
Пользовательские требования должны описывать внешнее поведение системы, основные функции и сервисы предоставляемые системой, её нефункциональные свойства. Необходимо выделить опорные точки зрения и сгруппировать требования в соответствии с ними. Пользовательские требования можно оформить как простым перечислением, так и используя нотацию вариантов использования.
Далее составляются системные требования. Они включат в себя:
Требования к архитектуре системы. Например, число и размещение хранилищ и серверов приложений.
Требования к параметрам оборудования. Например, частота процессоров серверов и клиентов, объём хранилищ, размер оперативной и видео памяти, пропускная способность канала и т.д.
Требования к параметрам системы. Например, время отклика на действие пользователя, максимальный размер передаваемого файла, максимальная скорость передачи данных, максимальное число одновременно работающих пользователей и т.д.
Требования к программному интерфейсу.
Требования к структуре системы. Например, Масштабируемость, распределённость, модульность, открытость.
масштабируемость – возможность распространения системы на большое количество машин, не приводящая к потере работоспособности и эффективности, при этом способность системы наращивать свою мощность должна определяться только мощностью соответствующего аппаратного обеспечения.
распределенность - система должна поддерживать распределённое хранение данных.
модульность - система должна состоять из отдельных модулей, интегрированных между собой.
открытость - наличие открытых интерфейсов для возможной доработки и интеграции с другими системами.
Требования по взаимодействию и интеграции с другими системами. Например, использование общей базы данных, возможность получения данных из баз данных определённых систем и т.д.
4. Порядок выполнения работы
Изучить предлагаемый теоретический материал.
Построить опорные точки зрения на основании метода VORD для формирования и анализа требований. Результатом должны явиться две диаграммы: диаграмма идентификации точек зрения и диаграмма иерархии точек зрения.
Составить информационную модель будущей системы, включающую в себя описание основных объектов системы и взаимодействия между ними. На основании полученной информационной модели и диаграмм идентификации точек зрения, диаграмма иерархии точек зрения сформировать требования пользователя и системные требования.
Провести аттестацию требований, указать какие типы проверок выбрали.
На основании описания системы (лабораторная работа № 1), информационной модели, пользовательских и системных требований составить техническое задание на создание программного обеспечения.
Построить отчёт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов.
5. Содержание отчета
В отчете следует указать:
Цель работы
Введение
Программно-аппаратные средства, используемые при выполнении работы.
Основная часть (описание самой работы), выполненная согласно требованиям к результатам выполнения лабораторного практикума (п.2).
Заключение (выводы)
Список используемой литературы
Практическая работа №2
Проектирование программной системы
Цель работы: познакомить студентов с методом проектирования системы путем СЯС-карт.
Теоретическая часть.
Основы иМТ-проектирования
Важным этапом создания программного обеспечения является проектирование. На этом шаге закладывается архитектура системы.
Одним из способов проектирования является метод СЯС-карточек. Этот метод проектирования является составляющей иМЬ-проектирования.
Шаг первый. Для первоначального понимания структуры программы строится диаграмма вариантов использования: выявляются акторы (люди или системы, между которыми происходит взаимодействие), прецеденты системы (действия, выполняемые системой для реализации общения акторов).
Пример «Банкомат».
Диаграмма вариантов использования для примера «Банкомат» приведена на рис. Л8.1.
О
А
Банк
Рис. Л8.1. Диаграмма вариантов использования «Банкомат»
На самом деле прецедентов может быть очень много. Допустим: проверить пароль, контролировать транзакции передачи данных, выдать информацию на экран и т. д.
Эта диаграмма дает понять, что будет делать система, как она будет функционировать. Диаграмма использования бывает также очень полезна для общения с заказчиком — она позволяет показать наиболее значимые действия системы и проверить, правильно ли вы поняли заказчика и значимость отдельных функций для него.
Шаг второй. На этом этапе выявляют классы, которые необходимо будет создать в программе для реализации системы. В случае банкомата это: клиент, банк, служба безопасности банка, сам банкомат и т. д.
Придумать можно много (таймер, счетчик купюр, карточка и т. д.).
Далее оформляются СЯС-карты. Это листки бумаги 10 х 15. Они разделены на три части и выглядят следующим образом — рис. Л8.2.
На примере того же банкомата — рис. Л8.3.
Рис. Л8.2. Оформление СЯС-карты
Клиент
|
1. Вставляет карточку в банкомат.
2. Вводит пароль.
3. Указывает тип операции (снять деньги, просмотреть остаток).
4. Вводит сумму.
5. Получает деньги.
6. Вынимает карточку
|
Банкомат
|
а
Банкомат
|
1. Отображает информацию для клиента.
|
Клиент
|
2. Передает информацию в банк.
|
Банк
|
3. Отсчитывает купюры.
|
Служба безопасности банка
|
4. Распечатывает счет
|
|
б
Служба безопасности банка
|
1. Проверяет пароль.
|
Банк
|
2. Проверяет подлинность карточки.
|
Банкомат
|
3. Идентифицирует клиента.
|
|
4. Следит за правильностью транзакций
|
|
операций с деньгами
|
|
в
Банк
|
1. Проверяет возможность выдачи средств.
2. Сообщает о наличии денег.
3. Выдает информацию об остатке.
4. Хранит информацию о счете клиента
|
Банкомат
Служба безопасности банка
|
г
Рис. Л8.3. Примеры С11С-карт
Шаг третий. Для проверки достаточности или избыточности придуманных классов, а также корректности их взаимодействия строится диаграмма взаимодействия (рис. Л8.4).
Рис. Л8.4. Диаграмма взаимодействия
Метод СЯС-карточек позволяет провести также инсценировку работы системы. Для этого достаточно раздать карточки с классами участникам проекта. После этого начать ролевую игру. Первый участник встает и читает действие, совершаемое его классом. Другие участники, исходя из своих карточек, сообщают об ответной реакции других классов. Если в какой-то момент реакции не последует, то это признак несовершенства проекта системы. Такая игра может подсказать и об избыточности проекта.
Порядок выполнения работы
1. В соответствии с вариантом задания, предложенным преподавателем, определить действующих лиц (акторов) системы.
2. Определить варианты использования системы и описать их в краткой или полной форме (см. разд. 3.6.2).
3. Построить диаграмму вариантов использования системы (использовать MS Office или MS Visio).
4. Определить классы проектируемой системы.
5. Создать CRC-карты для всех классов системы (использовать MS Office или MS Visio).
6. Построить диаграмму взаимодействия (использовать MS Office или MS Visio).
7. Сдать и защитить работу.
Защита отчета по лабораторной работе
Отчет по лабораторной работе должен состоять из:
1. Постановки задачи.
2. Описания действующих лиц и прецедентов системы.
3. Диаграммы прецедентов.
4. СЯС-карты.
5. Диаграммы взаимодействия.
Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя.
Контрольные вопросы
1. Охарактеризуйте проектирование ПО при объектном подходе.
2. В нем заключается моделирование предметной области при проектировании ПО?
3. Язык иМ1_. Его назначение, преимущества и недостатки.
4. Опишите варианты использования ПО.
5. Перечислите диаграммы в языке иМ1_.
6. Приведите пример диаграммы прецедентов.
7. Приведите пример диаграммы взаимодействия.
8. В чем состоит назначение и использование СРС-карт?
Варианты заданий
1. Заказ билетов в аэропорту.
2. Электронный магазин.
3. Отправка sms.
4. Система охраны частного дома.
5. Система безопасности тюрьмы.
6. Система безопасности полета самолета.
Практическая работа №3
Техническое задание
Цель работы: Ознакомиться с процедурой разработки технического задания на создание программного продукта (ПП) с применением ГОСТ 19.102-77 «Стадии разработки программ и программной документации» и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
Основные теоретические сведения
Техническое задание — это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
Техническое задание представляет собой документ, в котором
сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приемо-сдаточных испытаний.
В разработке технического задания участвуют как представители заказчика, так и представители исполнителя.
В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследова-тельских работ, предпроектных исследований, научного прогнозирования и т.п.
При разработке технического задания (ТЗ) необходимо решить следующие задачи:
установить общую цель создания АИС;
установить общие требования к проектируемой системе;
разработать и обосновать требования, предъявляемые к информационному, математическому, программному, техническому и технологическому обеспечению;
определить состав подсистем и функциональных задач;
разработать и обосновать требования, предъявляемые к подсистемам;
определить этапы создания системы и сроки их выполнения;
провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения;
определить состав исполнителей.
В Российской Федерации действует ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», также на техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам устанавливает общие требования к оформлению программных документов. Программный документ должен состоять из следующих частей:
Титульной;
Информационной;
Основной.
Титульная часть оформляется согласно ГОСТ 19.104-78 ЕСПД. Основные надписи.
Информационная часть должна состоять из аннотации и содержания. В аннотации приводят сведения о назначении документа и краткое изложение основной части.
Содержание включает перечень записей о структурных элементах основной части документа.
Состав и структура основной части программного документа устанавливается стандартами ЕСПД на соответствующие документы.
Основная часть технического задания должна содержать следующие
разделы:
|
|
|
Скачать 6.85 Mb.