надо. Методические указания к выполнению лабораторных работ по курсу «. Методические указания к выполнению лабораторных работ по курсу инструментальные средства информационных систем Для студентов бакалавриата
 Скачать 1.81 Mb.
|
|
темам Проблемы, которые приходится решать специалистам в про- цессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая про- граммная система инновационная. В частности, трудно чѐтко описать те действия, которые должна выполнять система. Описание функцио- нальных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирова- ния, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований. Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко ограничений, накладываемых на неѐ. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реа- лизации требований пользователя. Разработка требований Разработка требований — это процесс, включающий меро- приятия, необходимые для создания и утверждения документа, со- держащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований: 1. анализ технической осуществимости создания системы, 2. формирование и анализ требований, 3. специфицирование требований и создание соответствующей документации, 4. аттестация этих требований. На рис. 2.1 показаны взаимосвязи между этими этапами и ре- зультаты, сопровождающие каждый этап процесса разработки сис- темных требований. Рис. 2.1. Процесс разработки требований Но поскольку в процессе разработки системы в силу разнооб- разных причин требования могут меняться, управление требованиями, т.е. процесс управления изменениями системных требований, является необходимой составной частью деятельности по их разработке. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Формирование и анализ требований Следующим этапом процесса разработки требований является формирование (определение) и анализ требований. Обобщенная модель процесса формирования и анализа требо- ваний показана на рис. 2.2. Каждая организация использует собствен- ный вариант этой модели, зависящий от ―местных факторов‖: опыта работы коллектива разработчиков, типа разрабатываемой системы, используемых стандартов и т.д. Рис. 2.2. Процесс формирования и анализа требований Процесс формирования и анализа требований проходит через ряд этапов. 1. Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система. 2. Сбор требований. Это процесс взаимодействия с лицами, фор- мирующими требования. Во время этого процесса продолжа- ется анализ предметной области. 3. Классификация требований. На этом этапе бесформенный на- бор требований преобразуется в логически связанные группы требований. 4. Разрешение противоречий. Без сомнения, требования много- численных лиц, занятых в процессе формирования требова- ний, будут противоречивыми. На этом этапе определяются и разрешаются противоречия различного рода. 5. Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. 6. Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому. Цикл начинается с анали- за предметной области и заканчивается проверкой требований. Пони- мание требований предметной области увеличивается в каждом цикле процесса формирования требований. Рассмотрим три основных подхода к формированию требова- ний: метод, основанный на множестве опорных точек зрения, сцена- рии и этнографический метод. Опорные точки зрения Подход с использованием различных опорных точек зрения к разработке требований признает различные (опорные) точки зрения на проблему и использует их в качестве основы построения и организа- ции как процесса формирования требований, так и непосредственно самих требований. Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом. 1. Как источник информации о системных данных. В этом случае на основе опорных точек зрения строится модель создания и использования данных в системе. В процессе формирования требований отбираются все такие точки зрения ( и на их осно- ве определяются данные), которые будут созданы или исполь- зованы при работе системы, а также способы обработки этих данных. 2. Как структура представлений. В этом случае точки зрения рас- сматриваются как особая часть модели системы. Например, на основе различных точек зрения могут разрабатываться модели "сущность-связь", модели конечного автомата и т.д. 3. Как получатели системных сервисов. В этом случае точки зре- ния являются внешними (относительно системы) получателя- ми системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления. Наиболее эффективным подходом к анализу таких систем яв- ляется использование внешних опорных точек зрения. На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рис. 2.3.: 1. Идентификация точек зрения, получающих системные серви- сы, и идентификация сервисов, соответствующих каждой точ- ке зрения. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 2. Структурирование точек зрения — создание иерархии сгруп- пированных точек зрения. Общесистемные сервисы предос- тавляются более высоким уровням иерархии и наследуются точками зрения низшего уровня. 3. Документирование опорных точек зрения, которое заключает- ся в точном описании идентифицированных точек зрения и сервисов. 4. Отображение системы точек зрения, которая показывает сис- темные объекты, определенные на основе информации, заклю- ченной в опорных точках зрения. Рис. 2.3. Метод VORD Пример. Рассмотрим использование метода VORD на первых трех шагах анализа требований для системы системы поддержки зака- за и учета товаров в бакалейной лавке. В бакалейной лавке для каждо- го товара фиксируется место хранения (определенная полка), количе- ство товара и его поставщик. Система поддержки заказа и учета това- ров должна обеспечивать добавление информации о новом товаре, изменение или удаление информации об имеющемся товаре, хранение (добавление, изменение и удаление) информации о поставщиках, включающей в себя название фирмы, ее адрес и телефон. При помощи системы составляются заказы поставщикам. Каждый заказ может со- держать несколько позиций, в каждой позиции указываются наимено- вание товара и его количество в заказе. Система по требованию поль- зователя формирует и выдает на печать следующую справочную ин- формацию: список всех товаров; список товаров, имеющихся в наличии; список товаров, количество которых необходимо пополнить; список товаров, поставляемых данным поставщиком. Первым шагом в формировании требований является иденти- фикация опорных точек зрения. Во всех методах формирования тре- бований, основанных на использовании точек зрения, начальная иден- тификация является наиболее трудной задачей. Один из подходов к идентификации точек зрения — метод "мозговой атаки", когда опре- деляются потенциальные системные сервисы и организации, взаимо- действующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Эти точки зрения представляются в виде диаграммы, состоящей из ряда круговых областей, отображающих возможные точки зрения (рис. 2.4). Во время "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрения, системные сервисы, входные данные, нефункциональные требования, управляющие события и ис- ключительные ситуации. Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рис. 4 показаны в виде тем- ных круговых областей) и сервисов (показаны в виде затененных об- ластей). Сервисы должны соответствовать опорным точкам зрения. Но могут быть сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе "мозговой атаки" некоторые опор- ные точки зрения не были идентифицированы. Рис. 2.4. Диаграмма идентификации точек зрения В таблице 2.1 показано распределение сервисов для некоторых идентифицированных на рис. 2.4 точек зрения. Один и тот же сервис может быть соотнесен с несколькими точками зрения. Таблица 2.1 - Сервисы, соотнесенные с точками зрения клиент поку- патель посто ян- ный поку- па- тель товар постав- щик продавец админист- ратор Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Информация, извлеченная из точек зрения, используется для заполнения форм шаблонов точек зрения и организации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследования. Сер- висы, данные и управляющая информация наследуются подмножест- вом точек зрения. На рис. 5 показана часть иерархии точек зрения для системы поддержки заказа и учета товаров. Проверка наличия товара Занесе- ние в список посто- янных клиен- тов Полу- чение скид- ки Прием товара Занесе- ние в базу данных (назва- ние, адрес, телефон и т.д.) Продажа товара Доступ к базе дан- ных Покупка товара Полу- чение инфор ма- цию о новых по- ступ- лени- ях Занесение в базу данных (данные о поставщике, кол-ве, месте хранения и.д.) Печать чека Проверка статистики Получе- ние чека Назначение цены Доступ к каталогу Переопре- деление цены Заказ товара Переопреде- ление цены Проверка наличия товара Оформле- ние заказа поставщи- ку Занесе- ние по- купателя и суммы покупки в базу данных «Покупае- мый» или «непокупае- мый» товар Оформ- ление заказа покупа- телю Печать заказа Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 5. Иерархия точек зрения Аттестация требований Аттестация должна продемонстрировать, что требования дей- ствительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требо- ваний могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения ее в эксплуатацию. Стоимость внесения в систему измене- ний, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечет за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование. Во время процесса аттестации должны быть выполнены раз- личные типы проверок требований. 1. Проверка правильности требований. Пользователь может счи- тать, что система необходима для выполнения некоторых оп- ределенных функций. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополни- тельных или новых функций. Системы предназначены для разных пользователей с различными потребностями, и поэто- му набор требований будет представлять собой некоторый компромисс между требованиями пользователей системы. 2. Проверка на непротиворечивость. Спецификация требований не должна содержать противоречий. Это означает, что в тре- бованиях не должно быть противоречащих друг другу ограни- чений или различных описаний одной и той же системной функции. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 3. Проверка на полноту. Спецификация требований должна со- держать требования, которые определяют все системные функции и ограничения, налагаемые на систему. 4. Проверка на выполнимость. На основе знания существующих технологий требования должны быть проверены на возмож- ность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы. Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности. 1. Обзор требований. Требования системно анализируются ре- цензентами. 2. Прототипирование. На этом этапе прототип системы демонст- рируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям. 3. Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестиро- вать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить про- блемы в спецификации. Если такие тесты сложно или невоз- можно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть. 4. Автоматизированный анализ непротиворечивости. Если тре- бования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необ- ходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований го- товит отчет обо всех обнаруженных противоречиях. Пользовательские и системные требования На основании полученных моделей строятся пользовательские требования, т.е. как было сказано в начале описание на естественном языке функции, выполняемых системой, и ограничений, накладывае- мых на неѐ. Пользовательские требования должны описывать внешнее по- ведение системы, основные функции и сервисы предоставляемые сис- темой, еѐ нефункциональные свойства. Необходимо выделить опор- ные точки зрения и сгруппировать требования в соответствии с ними. Пользовательские требования можно оформить как простым перечис- лением, так и используя нотацию вариантов использования. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Далее составляются системные требования. Они включат в се- бя: 1. Требования к архитектуре системы. Например, число и разме- щение хранилищ и серверов приложений. 2. Требования к параметрам оборудования. Например, частота процессоров серверов и клиентов, объѐм хранилищ, размер оперативной и видео памяти, пропускная способность канала и т.д. 3. Требования к параметрам системы. Например, время отклика на действие пользователя, максимальный размер передаваемо- го файла, максимальная скорость передачи данных, макси- мальное число одновременно работающих пользователей и т.д. 4. Требования к программному интерфейсу. 5. Требования к структуре системы. Например, Масштабируе- мость, распределѐнность, модульность, открытость. масштабируемость – возможность распространения системы на большое количество машин, не приводящая к потере рабо- тоспособности и эффективности, при этом способность систе- мы наращивать свою мощность должна определяться только мощностью соответствующего аппаратного обеспечения. распределенность - система должна поддерживать распреде- лѐнное хранение данных. модульность - система должна состоять из отдельных модулей, интегрированных между собой. открытость - наличие открытых интерфейсов для возможной доработки и интеграции с другими системами. 6. Требования по взаимодействию и интеграции с другими сис- темами. Например, использование общей базы данных, воз- можность получения данных из баз данных определѐнных сис- тем и т.д. Порядок выполнения работы 1. Изучить предлагаемый теоретический материал. 2. Построить опорные точки зрения на основании метода VORD для формирования и анализа требований. Результатом должны явиться две диаграммы: диаграмма идентификации точек зре- ния и диаграмма иерархии точек зрения. 3. Составить информационную модель будущей системы, вклю- чающую в себя описание основных объектов системы и взаи- модействия между ними. На основании полученной информа- ционной модели и диаграмм идентификации точек зрения, Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко диаграмма иерархии точек зрения сформировать требования пользователя и системные требования. 4. Провести аттестацию требований, указать какие типы прове- рок выбрали. 5. На основании описания системы (Лабораторная работа №1), информационной модели, пользовательских и системных тре- бований составить техническое задание на создание про- граммного обеспечения (пример см. Приложение А). ТЗ долж- но содержать основные разделы, описанные в ГОСТ 34.602-89. 6. Построить отчѐт, включающий все полученные уровни моде- ли, описание функциональных блоков, потоков данных, хра- нилищ и внешних объектов. Содержание отчета В отчете следует указать: 1. Цель работы 2. Введение 3. Программно-аппаратные средства, используемые при выпол- нении работы. 4. Основная часть (описание самой работы), выполненная со- гласно требованиям к результатам выполнения лабораторного практикума. 5. Заключение (выводы) 6. Список используемой литературы Литература 1. Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом ―Вильямс‖, 2002. – 624 с. 2. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.:Питер, 2002. – 496 с. 3. Константайн Л., Локвуд Л. Разработка программного обеспе- чения. – СПб.:Питер, 2004. – 592 с. 4. Иванова Г.С. Технология программирования: Учебник для ву- зов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с. 5. ГОСТ 34.602-89 Техническое задание на создание автомати- зированной системы 6. ГОСТ 19.201-78 Техническое задание. Требования к содержа- нию и оформлению |