Методические указания по проведению практических работ по пм 02
 Скачать 451.5 Kb.
|
|
УПРАВЛЕНИЕ ОБРАЗОВАНИЯ И НАУКИ ЛИПЕЦКОЙ ОБЛАСТИ ГОАПОУ «Липецкий металлургический колледж» 
для специальности (группы специальностей):
Липецк-2017 Методические указания по проведению практических работ по МДК 02.01 Технология разработки программного обеспечения. Составитель: Ильичева А. А.,преподаватель общепрофессиональных дисциплин и профессиональных модулей
Методические указания по проведению практических работ предназначены для студентов ГОАПОУ «Липецкий металлургический колледж» специальности 09.02.07 Информационные системы и программирование для подготовки к лабораторным работам с целью освоения практических умений и навыков и профессиональных компетенций. Методические указания по проведению практических работ составлены в соответствии с рабочей программой по ПМ 02 Осуществление интеграции программных модулей. Введение Методические указания по проведению практических работ разработаны согласно рабочей программы по профессиональному модулю ПМ 02 Осуществление интеграции программных модулей и требованиям к умениям и знаниям Федерального государственного образовательного стандарта среднего профессионального образования (далее – ФГОС СПО) по специальности 09.02.07 Информационные системы и программирование. Практические работы направлены на освоение следующих умений, знаний согласно ФГОС СПО. В результате освоения МДК 02.01 Технология разработки программного обеспечения обучающийся должен: уметь: использовать выбранную систему контроля версий; использовать методы для получения кода с заданной функциональностью и степенью качества; знать: модели процесса разработки программного обеспечения; основные принципы процесса разработки программного обеспечения; основные подходы к интегрированию программных модулей; основы верификации и аттестации программного обеспечения. Указания к выполнению практических работ по МДК 02.01 Технология разработки программного обеспечения для студентов специальности 09.02.07 Информационные системы и программирование: - к выполнению практических работ необходимо приготовиться до начала занятия. Кроме описания работы в данном учебном пособии, используйте рекомендованную литературу и конспект лекций; - к выполнению работ допускаются только подготовленные студенты; - при проведении практических работ необходимо быть предельно внимательными; - если работа не сдана вовремя (до выполнения следующей работы) по неуважительной причине, оценка за практическую работу снижается; - практические работы следует проводить по мере прохождения студентами теоретического материала. Практические работы рекомендуется выполнять в следующей последовательности: - вводная беседа, во время которой кратко напоминаются теоретические вопросы по теме работы, разъясняется сущность, цель, методика выполнения работы; - самостоятельное выполнение необходимых расчетов; - обработка результатов расчетов, оформление отчета; - защита практической работы в форме собеседования по методике проведения и результатам проделанной работы. Практическая работа 1 Анализ предметной областиЦель: Изучить, описать и проанализировать предметную область, в которой будет создаваться информационная база. Выделяются следующие шаги работы над проектом (системой):1. Описание предметной области, под которой понимается та часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения некоторой задачи. Следовательно, разработчикам необходимо выделить основные объекты (компоненты), участвующие в функционировании системы, определить их наиболее существенные характеристики, взаимосвязи в рамках решаемой задачи, а также определить основные информационные потоки в системе. При этом отдельные компоненты выбираются таким образом, чтобы при последующей разработке их было удобно представить в форме классов и объектов. В этом случае немаловажное значение приобретает и сам язык представления информации о концептуальной схеме предметной области. Сложность предметной области определяет количество объектов и связей между ними, поэтому описание должно включать в себя базовые термины и определения, сопровождаться различными примерами, в нем могут приводиться различного рода классификации, поясняющие различные свойства описываемых объектов. Если в системе используются математические модели, то они также должны быть описаны с учетом специфики применения. 2. Обзор существующих систем-аналогов – неотъемлемая часть описания предметной области, которая позволяет разработчику определить основные концепции, необходимые для реализации в системе. Описание должно приводиться с указанием отличительных особенностей разработанных систем, с перечислением их достоинств и недостатков, в отчете обязательно приводятся экранные формы этих систем. 3. Результатом последнего этапа является диаграмма объектов предметной области и краткое описание их свойств и функций. При построении данной диаграммы нужно помнить о том, что в данном случае объект – это «конкретная материализация абстракции», а не экземпляр класса. Диаграмма объектов представляет статическую составляющую взаимодействующих между собой объектов, она должна включить в себя только те объекты предметной области, которые потом преобразуются в диаграмму классов. Связи между объектами показывают отношения между ними, при необходимости в диаграмме можно привести и атрибуты (свойства) объектов. Диаграммы объектов не позволяют полностью описать объектную структуру системы, поэтому при их использовании нужно сосредоточиться на изображении интересующих вас наборов конкретных объектов. Для сбора, хранения, поиска и выдачи информации о предметной области и ее объектов настоящее время в информационных системах широко используются базы данных. Анализ предметной области начинается с выделения сущностей и определения их свойств или атрибутов. Видимые сущности представляют собой объекты предметной области, которые может распознать человек. Поддерживаемые сущности или абстрактные сущности разрабатываются для физической поддержки общей логической модели. Содержание работы: Провести анализ предметной области в соответствии с выданным заданием. Защитить практическую работу. Практическая работа 2 Разработка и оформление технического заданияЦель работы: Ознакомление с процедурой разработки технического задания на создание программного продукта с применением ГОСТ 19.102-77 «Стадии разработки программ и программной документации». Техническое задание На данной стадии выполняются следующие работы: Обоснование необходимости разработки программ: - постановка задачи; - сбор исходных материалов; - выбор и обоснование критериев эффективности и качества; - обоснование необходимости проведения научно-исследовательских работ. 2. Выполнение научно-исследовательских работ: - определение структуры входных и выходных данных; - предварительный выбор методов решения задач; - обоснование целесообразности применения ранее разработанных программ; - определение требований к техническим средствам; - обоснование принципиальной возможности решения поставленных задач. 3. Разработка и утверждение технического задания: - определение требований к программе; - разработка технико-экономического обоснования разработки программы; - определение стадий, этапов и сроков разработки программы и документации на нее; - выбор языков программирования; - определение необходимости проведения научно-исследовательской работы на последующих стадиях. Результатом выполнения данной лабораторной работы является правильно оформленное техническое задание. Практическая работа 3Построение архитектуры программного средстваЦель работы: Реализация начальных этапов процесса разработки программного средства в соответствии с ГОСТ Р ИСО/МЭК 12207. При возникновении потребностей в заказе, приобретении, разработке, эксплуатации и сопровождении программ перед всеми сторонами, вовлеченными в жизненный цикл программного средства (ПС), возникает целый ряд вопросов, связанных с определением и детальным структурированием жизненного цикла (ЖЦ) ПС, с организационными и техническими правами и обязанностями сторон, с управлением ЖЦ и контролем за его реализацией. Одним из действенных инструментов для решения данных вопросов является использование унифицированных подходов, закрепленных в современных международных и российских стандартах. Понятия «жизненный цикл системы» или «жизненный цикл программного средства» часто появляются в статьях и звучат в разговорах разработчиков, по крайней мере, руководителей проектов и подразделений. Всем понятно, что относятся они к тому, что и в какой последовательности должно делаться при создании и эксплуатации систем. Но прежде чем две организации или два специалиста договорятся о том, что конкретно входит или не входит в ЖЦ, проходит значительное время. А позже вполне может обнаружиться, что эти двое (две «стороны») все-таки по-разному понимают, какие работы будут входить в ЖЦ, а какие - нет, какие проверки будут планироваться, когда и т. д. Естественно, общие принципы организации работ описаны давно, но что делать сторонам в конкретном проекте — это каждый раз приходится решать заново. В стандартах, регламентирующих жизненный цикл программных средств, обобщаются опыт и результаты исследований множества специалистов и рекомендуются наиболее эффективные современные методы и процессы создания и развития комплексов программ. В результате таких обобщений оттачиваются технологические процессы и приемы разработки, а также методическая база для их автоматизации. ЖЦ ПС в стандартах представляет собой набор этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующих ведение работ от подготовки технического задания до завершения испытаний ряда версий и окончания эксплуатации ПС или информационной системы (ИС). Стандарты включают правила описания исходной информации, способов и методов выполнения операций, устанавливают правила контроля технологических процессов, требования к оформлению их результатов, а также регламентируют содержание технологических и эксплуатационных документов на комплексы программ. Они определяют организационную структуру коллектива, обеспечивают распределение и планирование заданий, а также, контроль за ходом создания ПС. Для того чтобы привнести порядок и понимание, общие для любых сторон, участвующих в ЖЦ систем и ПС, давно разрабатывались стандарты различных уровней утверждения - национальные и международные. В России основы построения и использования профилей стандартов ЖЦ ПС заложены принятием в качестве базового стандарта ГОСТ Р ИСО/МЭК 12207. Данный документ введен в действие с 1 июля 2000 г., тесно взаимоувязан с рядом стандартов, принятых ранее, и с некоторыми стандартами, разрабатываемыми в данное время на основе прямого применения стандартов ИСО. Актуальность стандарта ГОСТ Р ИСО/МЭК 12207 для современных условий настолько высока, что принятие в ISO его исходного, международного варианта вскоре вызвало самую положительную оценку российских экспертов. Был дан ряд рекомендаций по его использованию в реальных условиях. В данном стандарте программное обеспечение (ПО) или программный продукт определяется как набор компьютерных программ, процедур исвязанной с ними документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. В соответствии с ГОСТ Р ИСО/МЭК 12207 все процессы ЖЦ ПО разделены на три группы: 1) Основные процессы: −приобретение; −поставка; −разработка; −эксплуатация; −сопровождение. 2) Вспомогательные процессы: −документирование; −управление конфигурацией; −обеспечение качества; −верификация; −аттестация; −совместная оценка; −аудит; −разрешение проблем. 3) Организационные процессы: −управление; −усовершенствование; −создание инфраструктуры; −обучение. Процесс разработки предусматривает действия и задачи, выполняемые разработчиком, и включает следующие действия: А) Подготовительная работа, которая начинается с выбора модели ЖЦ ПО, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ. Б) Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т.д. Требования к системе оцениваются исходя из критериев реализуемости и возможности проверки при тестировании. Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО: −функциональных возможностей, включая характеристики производительности и среды функционирования компонента; −внешних интерфейсов; −спецификаций надежности и безопасности; −эргономических требований; −требований к используемым данным; −требований к установке и приемке; −требований к пользовательской документации; −требований к эксплуатации и сопровождению. Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании. В) Проектирование архитектуры системы на высоком уровне заключается в определении компонентов ее оборудования, ПО и операций, выполняемых эксплуатирующим систему персоналом. Архитектура системы должна соответствовать требованиям, предъявляемым к системе, а также принятым проектным стандартам и методам. Проектирование архитектуры ПО включает следующие задачи: − трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав ее компонентов; − разработку и документирование программных интерфейсов ПО и баз данных; − разработку предварительной версии пользовательской документации; − разработку и документирование предварительных требований к тестам и планам интеграции ПО. Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам. Г) Детальное проектирование ПО включает следующие задачи: − описание компонентов и интерфейсов между ними на более низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования; − разработку и документирование детального проекта базы данных; − обновление (при необходимости) пользовательской документации; Д) Кодирование и тестирование ПО охватывает задачи: − разработку и документирование каждого компонента ПО и базы данных, а также совокупности тестовых процедур и данных для их тестирования; − тестирование каждого компонента ПО и базы данных на соответствие предъявляемых к ним требованиям. Результаты тестирования компонентов должны быть документированы; − обновление (при необходимости) пользовательской документации; − обновление плана интеграции ПО. Е) Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирование агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Ж) Квалификационное тестирование - это набор критериев и условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации. Квалификационное тестирование ПО проводится разработчиком, в присутствии заказчика (по возможности), для демонстрации того, что ПО удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации. Квалификационное тестирование выполняется для каждого компонента ПО по всем разделам требований при широком варьировании тестов. З) Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПО и баз данных. И) Приемка ПО предусматривает оценку результатов квалификационного тестирования ПО и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Задание: разработать проект архитектуры программного средства в соответствии с ГОСТ Р ИСО/МЭК 12207. Алгоритм выполнения работы. С целью реализации начальных этапов разработки ПС в соответствии с техническим заданием: −выполнить подготовительную работу; −провести анализ требований к ПС; −выполнить проектирование архитектуры ПС на высоком уровне. Практическая работа 4Работа в системе контроля версийЦель работы: получение первоначальных навыков использования систем контроля версий исходного кода программ и первоначальных навыков организации коллективной разработки программного обеспечения. Software Configuration Management или Конфигурационное управление подразумевает под собой комплекс методов, направленных на то, чтобы систематизировать изменения, вносимые разработчиками в программный продукт в процессе его разработки и сопровождения, сохранить целостность системы после изменений, предотвратить нежелательные и непредсказуемые эффекты, а также сделать процесс внесения изменений более формальным. К процедурам можно отнести создание резервных копий, контроль исходного кода, требований проекта, документации и т. д. Степень формальности выполнения данных процедур зависит от размеров проекта, и при правильной ее оценке данная концепция может быть очень полезна. Конфигурационное управление требует выполнения множества трудоемких рутинных операций. На практике, в большинстве случаев, для конфигурационного управления применяются специальные системы контроля версий исходного кода программ. В качестве примера рассмотрим информационную систему Subversion. Это бесплатная система управления версиями с открытым исходным кодом. Subversion позволяет управлять файлами и каталогами, а так же сделанными в них изменениями во времени. Это позволяет восстановить более ранние версии данных, предоставляет возможность изучить историю всех изменений. Задание: Создать тестовый проект на любом знакомом языке программирования и отработать навыки использования хранилища на локальном компьютере. |