Файл: Методические указания по выполнению практических работ по профессиональному модулю.doc

Отчет состоять из следующих структурных элементов:

1. 
   титульный лист;
   
2. 
   текстовая часть;
   

Текстовая часть отчета должна включать пункты:

• 
  условие задачи;
  
• 
  порядок выполнения
  
• 
  полученные результаты.
  

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

Шаблон таблицы для представления результатов

Тест (значения для входных данных)	Ожидаемый результат (значения для выходных данных)	Фактический результат (полученные значения выходных данных)	Результат тестирования (успешно/неуспешно)

Контрольные вопросы:

1. 
   Что такое тестирование ПС?
   
2. 
   Чем тестирование отличается от отладки ПС?
   
3. 
   Для чего проводится функциональное тестирование?
   
4. 
   Что такое комплексное тестирование?
   
5. 
   Каковы правила тестирования программы «как черного ящика»?
   
6. 
   Как проводится тестирования программы по принципу «белого ящика»?
   
7. 
   Что такое модульное тестирование?
   
8. 
   Как осуществляется сборка программы при модульно тестировании?
   

Практическая работа №13 «Сравнение результатов тестирования с требованиями технического задания и/или спецификацией».
Тема 2.1 Основные методы обеспечения качества функционирования

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

Материально-техническое обеспечение: Компьютер, операционная система Windows 7
Краткие теоретические сведения:

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

Техническое задание позволяет:

---

• 
  исполнителю — понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы;
  
• 
  заказчику — осознать, что именно ему нужно;
  
• 
  обеим сторонам — представить готовый продукт;
  
• 
  исполнителю — спланировать выполнение проекта и работать по намеченному плану;
  
• 
  заказчику — требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;
  
• 
  исполнителю — отказаться от выполнения работ, не указанных в ТЗ;
  
• 
  заказчику и исполнителю — выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний);
  
• 
  избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний).
  

В зависимости от ожиданий заказчика существует три альтернативы для выбора шаблона Технического задания. Если заказчик требует оформления документации в соответствии с государственным стандартом, выбор делается в сторону стандарта ГОСТ 34.602-89. Подготовка Технического задания по ГОСТ 34.602-89 требует значительных временных затрат.

Если поставлены сжатые сроки подготовки ТЗ и заказчик не требует оформления документации в соответствии с государственным стандартом, то можно использовать шаблон технического задания по стандарту IEEE Std 830. Стандарт IEEE Std 830 предполагает, что детальные требования могут быть обширными и не существует оптимальной структуры для всех систем. По этой причине, стандартом рекомендуется обеспечивать такое структурирование детальных требований, которое делает их оптимальными для понимания. Стандартом рекомендуются различные способы структурирования детальных требований для различных классов систем.

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

1. 
   Изучить теоретический материал.
   
2. 
   Выполнить предлагаемые задания.
   
3. 
   Ответить на контрольные вопросы и предоставить в тетради в виде отчета. Отчет должен включать:
   

• 
  номер, наименование практической работы и тему;
  
• 
  ответы на контрольные вопросы;
  
• 
  выводы.
  

4. 
   Выполненную работу и отчет по проделанной работе предъявить преподавателю.
   

Задания для выполнения практической работы:

1. 
   Составить подробное описание информационной системы.
   
2. 
   На основании описания системы провести анализ осуществимости. В ходе анализа ответить на вопросы:
   

---

• 
  Что произойдет с организацией, если система не будет введена в эксплуатацию?
  
• 
   Какие текущие проблемы существуют в организации и как новая система поможет их решить?
  
• 
  Каким образом система будет способствовать целям бизнеса?
  
• 
  Требует ли разработка системы технологии, которая до этого не использовалась в организации?
  

Результатом анализа должно явиться заключение о возможности реализации проекта.

1. 
    Заполнить разделы плана:
   

• 
   Введение
  
• 
  Организация выполнения проекта
  
• 
   Анализ рисков
  

Разделы должны содержать рекомендации относительно разработки системы, базовые предложения по объёму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению.

4. 
   Составить отчет о проделанной работе.
   

Содержание отчета

Каждый студент составляет индивидуальный отчет по лабораторной работе.

В отчете следует указать:

1. 
   Цель работы
   
2. 
   Постановка задачи (в краткой форме)
   
3. 
   Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом
   
4. 
   План проекта (ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов)
   
5. 
   Анализ рисков
   
6. 
   Анализ осуществимости:
   

1. 
   Характеристика основных элементов объекта проектирования.
   

1.1.    Цели и задачи объекта

1.2.    Организационная структура объекта (словесное и графическое описание)

1.3.    Основные функции объекта (словесное и графическое описание)

1.4.    Основные бизнес-процессы объекта (словесное описание)

b) Характеристика обеспечивающих элементов объекта проектирования.

2.1.    Информационное обеспечение объекта

2.2.    Документационное и методическое обеспечение объекта

2.3.    Техническое обеспечение объекта

2.4.    Кадровое обеспечение объекта

с) Технико-экономическое обоснование проекта

d) Книга бизнес-процессов предприятия (графическое представление)

7. 
   Предварительный список актеров (на базе предыдущих отчетов)
   
8. 
   Общая спецификация требований к информационной системе (на основе анализа деятельности предприятия)
   
9. 
   Предварительный глоссарий
   
10. 
    Заключение (выводы)
    
11. 
    Список используемой литературы
    

---

Контрольные вопросы:

1. 
   Что такое требования к системе. Способы сбора требований.
   
2. 
   Основные методы описания требований к системе.
   
3. 
   Основные инструменты визуализации требований.
   
4. 
   Смысл и назначение технико-экономического обоснования
   
5. 
   Определение бизнес-процесса.
   

Практическая работа №14 «Анализ рисков»
Тема 2.1 Основные методы обеспечения качества функционирования

Цель работы: «Изучение методологии управления проектами. Получение навыков по применению данных методологий для планирования проекта»

Материально-техническое обеспечение: Компьютер, операционная система Windows 7
Краткие теоретические сведения:

Основные понятия

Проблемы управления программными проектами впервые проявились в 60-х — начале 70-х годов. Руководители программных проектов выполняют такую же работу, что и руководители технических проектов. Вместе с тем процесс разработки ПО существенно отличается от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами. Ниже приведён краткий список этих отличий.

1. 
   Программный продукт нематериален. Менеджер технического проек­та видит результаты выполнения своего проекта. Если реализация проекта отстает от графика, это также видно воочию. В противоположность этому программное обеспечение нематериально. Его нельзя увидеть или потрогать. Менеджер программного проекта не видит процесс "роста" разрабатываемого ПО. Он может полагаться только на документацию, кото­рая фиксирует процесс разработки программного продукта.
   
2. 
   Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программно­го продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты занимаются только несколько последних лет. Поэтому пока нельзя точно предсказать, на каком этапе процесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту.
   
3. 
   Большие программные проекты - это часто "одноразовые" проекты. Большие программные проекты, как правило, значительно отличаются от проектов, реализованных ранее. Поэтому, чтобы уменьшить неопределенность в планировании проекта, ру­ководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические изменения в компьютерной технике и коммуникационном оборудовании обесценивают предыдущий опыт. Знания и навыки, накоп­ленные опытом, могут не востребоваться в новом проекте.
   

---

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

 Планирование проекта

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

Кроме разработки плана проекта, на менеджера ложится обязанность разработки других видов планов. Эти виды планов кратко описаны в табл. 1.

---