Фонд оценочных средств профессионального модуля

• Название: Фонд оценочных средств профессионального модуля
• Дата: 10.02.2022
• Размер: 6.85 Mb.
• Имя файла: phpyoZamf_FOS-03.docx
• Тип: Протокол; #357630
• страница: 2 из 16

результаты освоения ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

Результатом освоения программы профессионального модуля является овладение обучающимися видом деятельности (ВД) Разработка и администрирование баз данных, в том числе профессиональными (ПК) и общими (ОК) компетенциями:

Код	Наименование результата обучения
ПК 3.1	Анализировать проектную и техническую документацию на уровне взаимодействия компонент программного обеспечения.
ПК 3.2	Выполнять интеграцию модулей в программную систему.
ПК 3.3	Выполнять отладку программного продукта с использованием специализированных программных средств.
ПК 3.4	Осуществлять разработку тестовых наборов и тестовых сценариев.
ПК 3.5	Производить инспектирование компонент программного продукта на предмет соответствия стандартам кодирования.
ПК 3.6	Разрабатывать технологическую документацию.
ОК 1	Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.
ОК 2	Организовывать собственную деятельность, определять методы и способы выполнения профессиональных задач, оценивать их эффективность и качество.
ОК 3	Решать проблемы, оценивать риски и принимать решения в нестандартных ситуациях.
ОК 4	Осуществлять поиск, анализ и оценку информации, необходимой для постановки и решения профессиональных задач, профессионального и личностного развития.
ОК 5	Использовать информационно-коммуникационные технологии для совершенствования профессиональной деятельности.
ОК 6	Работать в коллективе и команде, обеспечивать ее сплочение, эффективно общаться с коллегами, руководством, потребителями.
ОК 7	Ставить цели, мотивировать деятельность подчиненных, организовывать и контролировать их работу с принятием на себя ответственности за результат выполнения заданий.
ОК 8	Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.

Формы оценки: Экзамен

Методы оценки: Экспертная оценка по предложенным критериям.

Требования к процедуре оценки

Помещение:учебная аудитория

Норма времени: 6 часов.
Требования к кадровому обеспечению оценки

Оценщик (эксперт):

Ассистент (организатор)

Собеседник

Критерии оценки знаний обучающихся при сдаче промежуточной аттестации:

Экзаменационный билет содержит два теоретических вопроса и практическое задание. .

Критерии выставления оценок:

– оценка «отлично», если обучающийся обладает глубокими и прочными знаниями программного материала; при ответе на все вопросы продемонстрировал исчерпывающее, последовательное и логически стройное изложение; правильно сформулировал понятия и закономерности по вопросам; использовал примеры из дополнительной литературы и практики; сделал вывод по излагаемому материалу;

– оценка «хорошо», если обучающийся обладает достаточно полным знанием программного материала; его ответ представляет грамотное изложение учебного материала по существу; отсутствуют существенные неточности в формулировании понятий; правильно применены теоретические положения, подтвержденные примерами; сделан вывод; два вопроса освещены полностью или один вопрос освещён полностью, а два других доводятся до логического завершения при наводящих вопросах преподавателя;

– оценка «удовлетворительно», если обучающийся имеет общие знания основного материала без усвоения некоторых существенных положений; формулирует основные понятия с некоторой неточностью; затрудняется в приведении примеров, подтверждающих теоретические положения; один вопрос разобран полностью, два начаты, но не завершены до конца; три вопроса начаты и при помощи наводящих вопросов доводятся до конца;

– оценка «неудовлетворительно», если обучающийся не знает значительную часть программного материала; допустил существенные ошибки в процессе изложения; не умеет выделить главное и сделать вывод; приводит ошибочные определения; ни один вопрос не рассмотрен до конца, наводящие вопросы не помогают.
Перечень практических (лабораторных) работ

по МДК 03.01 Технология разработки программного обеспечения

№ работы	Название работы	Объём часов	Страница
	(в соответствии с рабочей	на
	программой)	выполнение
		работы
1.	Разработка и анализ требований к программной системе
		2
2.	Проектирование программной системы	2
3.	Техническое задание	2
4.	Анализ выбранного стиля программирования	2
5.	Разработка проекта программного обеспечения	2
6.	Разработка структурного алгоритма	2
7.	Разработка ПП с использованием объектно – ориентированного программирования	2
8.	Разработка справочной системы	2
9.	Тестирование методом «белого ящика»	2
10.	Тестирование методом «черного ящика»	2
11.	Способы анализа граничных решений	2
12.	Способы диаграмм причин - следствий	2
13.	Нисходящее тестирование интеграции	2
14.	Восходящее тестирование интеграции	2
15.	Анализ предметной области	2

Практическая работа №1

Разработка и анализ требований к программной системе

1.     Цель работы:

Составить и проанализировать требования к информационной системе, оформить техническое задание на разработку программного обеспечения.


2.      Методические указания

Лабораторная работа направлена на ознакомление с процессом разработки требований к информационной системе и составления технического задания на разработку программного обеспечения, получение навыков по использованию основных методов формирования и анализа требований.

Требования к результатам выполнения лабораторного практикума: 

1. 
   
   наличие диаграммы идентификации точек зрения и диаграммы иерархии точек зрения; 
   
2. 
   
   наличие пользовательских требований, четко описывающих будущий функционал системы; 
   
3. 
   
   наличие системных требований, включающих требования к структуре, программному интерфейсу, технологиям разработки, общие требования к системе (надежность, масштабируемость, распределённость, модульность, безопасность, открытость, удобство пользования и т.д.); 
   
4. 
   
   наличие составленного технического задания. 
   

3.     Теоретические сведения 

Общие сведения о требованиях к информационным системам

Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно чётко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований.

Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реализации требований пользователя. 

Разработка требований

Разработка требований — это процесс, включающий мероприятия, необходимые для созда­ния и утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований:

• 
  
  анализ технической осуществимости создания системы, 
  
• 
  
  формирование и анализ требований, 
  
• 
  
  специфицирование требований и создание соответствующей документации, 
  
• 
  
  аттестация этих требований. 
  

На рис. 1 показаны взаимосвязи между этими этапами и результаты, сопровождающие каждый этап процесса разработки системных требований. 

 

Рис. 1. Процесс разработки требований

Но поскольку в процессе разработки системы в силу разнообразных причин требова­ния могут меняться, управление требованиями, т.е. процесс управления изменениями системных требований, является необходимой составной частью деятельности по их раз­работке.

Формирование и анализ требований

Следующим этапом процесса разработки требований является формирование (определение) и анализ требований.

Обобщенная модель процесса формирования и анализа требований показана на рис. 2. Каждая организация использует собственный вариант этой модели, зависящий от “местных факторов”: опыта работы коллектива разработчиков, типа разрабатываемой системы, используемых стандартов и т.д.

  

Рис. 2. Процесс формирования и анализа требований

Процесс формирования и анализа требований проходит через ряд этапов.

1. 
   
   Анализ предметной области. Аналитики должны изучить предметную область, где бу­дет эксплуатироваться система. 
   
2. 
   
   Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области. 
   
3. 
   
   Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований. 
   
4. 
   
   Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе оп­ределяются и разрешаются противоречия различного рода. 
   
5. 
   
   Назначение приоритетов. В любом наборе требований одни из них будут более важ­ны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. 
   
6. 
   
   Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость. 
   

Процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому. Цикл начинается с анализа предметной облас­ти и заканчивается проверкой требований. Понимание требований предметной области увеличивается в каждом цикле процесса формирования требований.

Рассмотрим три основных подхода к формированию требований: метод, основанный на множестве опорных точек зрения, сценарии и этнографический метод.


Опорные точки зрения

Подход с использованием различных опорных точек зрения к разработке требова­ний признает различные (опорные) точки зрения на проблему и использует их в качестве основы построения и организации как процесса формирования требований, так и не­посредственно самих требований.

Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом. 

1. 
   
   Как источник информации о системных данных. В этом случае на основе опорных то­чек зрения строится модель создания и использования данных в системе. В процес­се формирования требований отбираются все такие точки зрения ( и на их основе определяются данные), которые будут созданы или использованы при работе систе­мы, а также способы обработки этих данных. 
   
2. 
   
   Как структура представлений. В этом случае точки зрения рассматриваются как особая часть модели системы. Например, на основе различных точек зрения могут разрабатываться модели "сущность-связь", модели конечного авто­мата и т.д. 
   
3. 
   
   Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зре­ния помогают определить данные, необходимые для выполнения системных сер­висов или их управления. 
   

Наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анали­за требований. Основные этапы метода VORD показаны на рис. 3.: 

1. 
   
   Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения. 
   
2. 
   
   Структурирование точек зрения — создание иерархии сгруппированных точек зре­ния. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня. 
   
3. 
   
   Документирование опорных точек зрения, которое заключается в точном описании идентифицированных точек зрения и сервисов. 
   
4. 
   
   Отображение системы точек зрения, которая показывает системные объекты, оп­ределенные на основе информации, заключенной в опорных точках зрения. 
   

   

Рис. 3. Метод VORD 
Пример. Рассмотрим использование метода VORD на первых трех шагах анализа требований для системы системы поддержки заказа и учета товаров в бакалейной лавке. В бакалейной лавке для каждого товара фиксируется место хранения (определенная полка), количество товара и его поставщик. Система поддержки заказа и учета товаров должна обеспечивать добавление информации о новом товаре, изменение или удаление информации об имеющемся товаре, хранение (добавление, изменение и удаление) информации о поставщиках, включающей в себя название фирмы, ее адрес и телефон. При помощи системы составляются заказы поставщикам. Каждый заказ может содержать несколько позиций, в каждой позиции указываются наименование товара и его количество в заказе. Система по требованию пользователя формирует и выдает на печать следующую справочную информацию: 

• 
  
  список всех товаров; 
  
• 
  
  список товаров, имеющихся в наличии; 
  
• 
  
  список товаров, количество которых необходимо пополнить; 
  
• 
  
  список товаров, поставляемых данным поставщиком. 
  

Первым шагом в формировании требований является идентификация опорных точек зрения. Во всех методах формирования требований, основанных на использовании точек зрения, начальная идентификация является наиболее трудной задачей. Один из подходов к идентификации точек зрения — метод "мозговой атаки", когда определяются потенци­альные системные сервисы и организации, взаимодействующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения. Эти точки зрения представляются в виде диаграммы, состоящей из ряда круговых областей, отображающих возможные точки зрения (рис. 4). Во время "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрения, системные сервисы, входные данные, нефункциональные требования, управляющие события и исключительные ситуации.

Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рис. 4 показаны в виде темных круговых областей) и сервисов (показаны в виде затененных областей). Сервисы должны соответствовать опорным точкам зрения. Но могут быть сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе "мозговой атаки" некоторые опорные точки зрения не были идентифицированы.

Рис. 4. Диаграмма идентификации точек зрения 
В таблице 1 показано распределение сервисов для некоторых идентифицированных на рис. 4 точек зрения. Один и тот же сервис может быть соотнесен с несколькими точками зрения.

Таблица 1 - Сервисы, соотнесенные с точками зрения

клиент	покупатель	постоянный покупатель	товар	поставщик	продавец	администратор
Проверка наличия товара	Занесение в список постоянных клиентов	Получение скидки	Прием товара	Занесение в базу данных (название, адрес, телефон и т.д.)	Продажа товара	Доступ к базе данных
Покупка товара		Получение информацию о новых поступлениях	Занесение в базу данных (данные о поставщике, кол-ве, месте хранения и.д.)		Печать чека	Проверка статистики
Получение чека			Назначение цены		Доступ к каталогу	Переопределение цены
Заказ товара			Переопределение цены		Проверка наличия товара	Оформление заказа поставщику
Занесение покупателя и суммы покупки в базу данных			«Покупаемый» или «непокупаемый» товар		Оформление заказа покупателю	Печать заказа

 

Информация, извлеченная из точек зрения, используется для заполнения форм шаб­лонов точек зрения и организации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследо­вания. Сервисы, данные и управляющая информация наследуются подмножеством точек зрения. На рис. 5 показана часть иерархии точек зрения для системы поддержки заказа и учета товаров.