|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Ухов В.И., Мандрик А.В., Ковцова И.О.Стр 1 из 4Следующая ⇒
Ухов В.И., Мандрик А.В., Ковцова И.О. Подготовка курсовых работ по дисциплине «Технология разработки программного обеспечения». Методическое пособие. – Протвино: филиал «Протвино» Международного университета природы, общества и человека «Дубна»; 2013. – с.43.
Методическое пособие предназначено для студентов очного и заочного отделений направления " Информатика и вычислительная техника". В пособии рассматриваются правила выполнения, определяются требования к содержанию, структуре и оформлению курсовых работ, выполняемых на кафедре Информационных технологий. Выполнение требований настоящего методического пособия обязательно для всех преподавателей кафедры, ведущих руководство курсовыми работами, и для всех студентов, выполняющих курсовые работы.
Рекомендовано к изданию учебно-методическим советом филиала «Протвино» университета «Дубна» в качестве методического пособия к выполнению курсовых работ по дисциплине «Технология разработки программного обеспечения».
@ В.И. Ухов, А.В. Мандрик, И.О. Ковцова @ Международный университет природы, общества и человека «Дубна», ISBN филиал «Протвино», 2013 СОДЕРЖАНИЕ Введение...................................................................................................................................................................................... 4 1 Общие требования к курсовой работе.......................................................................................................... 4 2 Организация учебного проекта.......................................................................................................................... 6 3 Программные технологии управления проектами...................................................................... 35 4 Рекомендации по выполнению курсовой работы......................................................................... 36 Библиографический список................................................................................................................................... 41 Приложения............................................................................................................................................................................ 43
Введение Целью преподавания дисциплины «Технология разработки программного обеспечения» является освоение студентами теоретических основ, принципов и современных методов разработки программного обеспечения в соответствии с российскими и международными стандартами и практикой. А также получение компетенций и практических навыков по проектированию, документированию, тестированию, внедрению, сопровождению и модернизации программных продуктов и систем. Работая над утвержденным курсовым заданием, студенты осваивают методы организации работ в коллективе, способы планирования, контроля и проведения аудита проекта. Главная задача курса состоит в развитии у студентов понимания процесса разработки программного обеспечения, то есть студент должен иметь представление о существующих технологиях разработки ПО, о моделях процесса разработки, о стандартах и методологиях построения моделей предметных областей с целью их использования в процессе анализа требований к программному обеспечению. Основной акцент при изучении дисциплины делается на практической части, позволяющей выработать у студентов, как навыки самостоятельной работы, так и навыки работы в команде. Итоговой работой при изучении курса «Технология разработки программного обеспечения» является курсовая работа – проект, который предполагает разработку небольшой завершенной программной системы или продукта. Работа над проектом ведётся сформированной группой студентов. Данная дисциплина изучается студентами на последнем, выпускном курсе и предусматривает знакомство с основными технологиями создания программного обеспечения, изучавшимися ранее. В первую очередь студенты должны владеть навыками: программирования и отладки; проектирования и создания СУБД; создания распределенных программных систем; разработки дружественных человеко-машинных интерфейсов. Реализуемый проект обязательно должен опираться на современные информационные технологии. Выполнение курсовой работы преследует следующие цели: – научить студентов применять знания на практике в различных областях, выявить исследовательские навыки, способность адаптироваться к новым ситуациям; – получение студентами навыков к анализу и синтезу полученной информации; – получение навыков формирования команды, работы в команде, а также социально-личностных, общекультурных и профессиональных компетенций; – получение навыков постановки задачи, умение понять поставленную задачу, грамотно произвести декомпозицию работ; – умение грамотно пользоваться языком предметной области; – определение общих форм, закономерностей, инструментальных средств для данной дисциплины; – развить творческие способности студентов, помочь найти своё место в проекте; – развитие целеустремлённости, ответственности, инициативности и умения решать возникающие проблемы и принимать решения; Курсовая работа является завершающим этапом изучения дисциплины “Технология разработки программного обеспечения ”, в ходе, которого осуществляется обучение применению полученных знаний и умений при решении комплексных задач, связанных с профессиональной деятельностью будущих специалистов, хорошо подготовленных для производственно-технологической, организационно-управленческой, проектной и научно-исследовательской деятельности. Учебно-методические рекомендации предназначены для студентов очного и заочного отделений направления " Информатика и вычислительная техника". 1 Общие требования к курсовой работе Правила выбора темы для курсовой работы Темы курсовых работ разрабатываются преподавателем и утверждаются заведующим кафедрой в течение первого месяца семестра, в котором выполняются курсовые работы. Затем темы выдаются студентам. Каждая группа в течение семестра должна полностью выполнить один проект. В рамках данной дисциплины студенты могут предлагать темы курсовых работ самостоятельно. Проект, выбранный группой, должен удовлетворять ряду требований. Во-первых, объем работ по проекту должен быть таким, чтобы выполняющая его группа могла выполнить его в течение семестра. Вторым требованием к проекту, являются технологические ограничения. Предлагаемый студентами проект должен опираться на современные программные технологии. Для успешной реализации проекта, выбранные технологии должны быть известны студентам и доступны для использования на практических занятиях. У студентов должна быть возможность получить расширенные консультации по их использованию от преподавателей кафедры. Так же допускается привлечение в качестве консультантов специалистов сторонних организаций, занимающихся данной предметной сферой, соответствующей теме курсовой работы. Третьим требованием к проекту, является его иннавационность и креативность. Для того чтобы студенты получили глубокие навыки работы в группе, выполняемая работа должна их увлекать и доставлять радость. Выполняемый проект должен быть интересен, выбравшей его команде. Еще одним желательным требованием к проекту, является его практическая польза. Как и для большинства учебных задач, данное требование не является обязательным. Приступая к выполнению курсовой работы, студенты выполняют декомпозицию работ по проекту. Каждый участник получает индивидуальное задание в рамках проекта, которое согласуется с преподавателем. Руководителем курсовой работы является преподаватель, ведущий семинарские занятия. Преподаватель оказывает помощь по вопросам содержания и последовательности выполнения работы, консультации по проекту, а также осуществляет контроль своевременности и качества выполняемых работ. Организация учебного проекта Инструментальные средства Настоятельное рекомендуется использование в проектах следующих классов инструментальных средств. 1. Электронная почта. 2. Централизованное хранение файлов (возможно, система управления версиями). 3. Представление данных о ходе проекта в виде web-ресурса. 4. Инструментальные средства разработки ПО. – Редакторы (текстовые, графические, моделей) и другие средства документирования, включая web-средства. – Компиляторы, отладчики, редакторы связей, менеджеры сборки и конфигурации. – Стандартные библиотеки и оболочки разработки ПО. – Системы тестирования и статического анализа кода. Возможно предоставление и других средств, в зависимости от специфики проекта. Поощряется самостоятельное нахождение, изучение и использование студентами специализированных инструментальных средств (в рамках существующего законодательства РФ). Выбор модели ЖЦ ПО Жизненный цикл программного обеспечения — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Модель жизненного цикла программного обеспечения — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создаётся и функционирует. Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились основные модели ЖЦ. Каждая такая модель представляет процесс создания ПО в каком-то своем " разрезе", используя только определенную часть всей информации о процессе. Перечисленные ниже модели разработки представляют обобщенные модели, основанные на архитектурном подходе. В этом случае можно увидеть всю структуру процесса создания ПО, абстрагируясь от частных деталей отдельных составляющих его этапов. Эти обобщенные модели не содержат точного описания всех стадий процесса создания ПО. Напротив, они являются полезными абстракциями, помогающими " приложить" различные подходы и технологии к процессу разработки. Кроме того, очевидно, что процесс создания больших систем не является единым, а состоит из множества различных процессов, ведущих к созданию отдельных частей большой системы. Первой во времени появления и самой распространённой явилась каскадная модель (водопад). Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы этого процесса. Последовательность фаз водопадной модели: анализ требований, проектирование, реализация, интеграция. Каскадная модель характеризуется следующими основными особенностями: – последовательным выполнением этапов проекта в строгом фиксированном порядке; – началом последующего этапа только после завершения предыдущего; – отсутствием обратных связей между этапами; – получением результата только в конце разработки. Каскадная модель хорошо функционирует при её применении в циклах разработки программного продукта, в которых используется неизменяемое определение продукта и вполне понятные технические методики. Модели данного типа на протяжении всего времени их существования используются при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков. В случае спиральной модели последовательность анализ требований — проектирование, реализация — тестирование выполняется больше одного раза. Для этого может быть несколько причин. Основная причина обычно связана с необходимостью предупреждения рисков. Другой причиной может быть необходимость предоставить заказчику частичную версию проекта для получения отзывов и пожеланий. Если разрабатываемая программа достаточно сложна, необходимо выполнять промежуточные интеграции, не откладывая эту фазу на самый конец, как это предписывает водопадная модель. Общая же идея спирального процесса заключается в том, чтобы на каждой итерации строить очередную версию программы, используя в качестве основы её предыдущую версию. В этом случае процесс приобретает спиралевидный характер. Основной особенностью итерационной модели ЖЦ ПО, или так называемой поэтапной модели с промежуточным контролем является наличие обратных связей между этапами, вследствие этого появляется возможность проведения контроля и корректировок на каждой стадии разработки. В эволюционной модели разработки ПО последовательно перемежаются этапы формирования требований, разработки ПО и его аттестации. «Быстрая» частичная реализация системы создаётся перед этапом определения требований или на его протяжении. Конечные пользователи системы используют ускоренный прототип, а затем путём обратной связи сообщают о своём достижении команде, работающей над проектом, для дальнейшего уточнения требований к системе. Процесс уточнения продолжается до тех пор, пока пользователь не получит то, что ему требуется. После завершения процесса определения требований путём разработки ускоренных прототипов, получают детальный проект системы, а ускоренный прототип регулируется при использовании кода или внешних утилит, в результате чего получают конечный рабочий продукт. Инкрементальная модель жизненного цикла. Инкрементная разработка представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей или эффективности. Этот подход позволяет уменьшить затраты, понесенные до момента достижения уровня исходной производительности. С помощью этой модели ускоряется процесс создания функционирующей системы. Этому способствует применяемый принцип компоновки из стандартных блоков, благодаря которому обеспечивается контроль над процессом разработки изменяющихся требований. Инкрементная модель описывает процесс, при выполнении которого первостепенное внимание уделяется системным требованиям, а затем их реализации в группах разработчиков. Как правило, со временем инкременты уменьшаются и реализуют каждый раз меньшее количество требований. Каждая последующая версия системы добавляет к предыдущей определённые функциональные возможности до тех пор, пока не будут реализованы все запланированные возможности. В этом случае можно уменьшить затраты, контролировать влияние изменяющихся требований и ускорить создание функциональной системы благодаря использованию метода компоновки из стандартных блоков. Предполагается, что на ранних этапах жизненного цикла выполняется конструирование системы в целом. На этих этапах определяются относящиеся к ним инкременты и функции. Каждый инкремент затем проходит через остальные фазы жизненного цикла: кодирование, тестирование и поставку. Модель формальной разработки систем. Основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые программы. Проверка соответствия спецификации и системных компонентов также выполняется математическими методами. Модель разработки ПО на основе ранее созданных компонентов. Предполагает, что отдельные составные части программной системы уже существуют, т.е. созданы ранее. В этом случае технологический процесс создания ПО основное внимание уделяет интеграции отдельных компонентов в общее целое, а не их созданию. Использование готовых системных компонентов практикуется повсеместно. Данный метод получил распространение, поскольку сборка систем из готовых или ранее использованных компонентов значительно ускоряет разработку ПО. Выбор приемлемой модели жизненного цикла разработки ПО может осуществляться в ходе следующего процесса. 1. анализ отличительных категорий проекта, помещенных в таблицах ниже; 2. ответьте на вопросы, приведённые для каждой категории, обведя кружочком слова «да» или «нет»; 3. Расположите по степени важности категории или вопросы, относящиеся к каждой категории, относительно выбранного проекта; 4. воспользуйтесь упорядоченными категориями для разрешения противоречий, возникающих при сравнении моделей, если общие полученные показатели сходны или одинаковы. Таблица 2 – Выбор модели жизненного цикла на основе характеристик требований
Таблица 3 – Выбор модели жизненного цикла на основе характеристик участников команды разработчиков
Таблица 4 – Выбор модели жизненного цикла на основе характеристик коллектива пользователей
Таблица 5 – Выбор модели жизненного цикла но основе характеристик типа проектов и рисков
Методические рекомендации В рамках ранее созданных проектных групп необходимо выбрать наиболее подходящую для вашей группы модель разработки программного обеспечения. Для обеспечения квалифицированного выбора участникам группы необходимо изучить предложенные модели, их преимущества и недостатки. При осуществлении выбора стоит ответить на вопросы, в значительной степени обуславливающие выбор. Каковы основные характеристики требований к проекту (сформулированы ли требования в полном объёме, насколько они изменяемы и т.д.)? Каков состав проектной группы и какова компетенция участников (все ли члены команды владеют предметной областью? Все ли знакомы с предполагаемым инструментарием и т.д.)? Какие ограничения на модель возлагает выбранный тип проекта? Сделанный группой выбор следует обосновать. Также по результатам реализации проекта требуется рассмотреть моменты отклонения этапов процесса от эталонных этапов модели. 2.5 Анализ требований и определение спецификаций ПО Определение корректных требований — это, наверное, самый ответственный этап программного проекта. Очень важно, чтобы формат проекта соответствовал требованиям к ПО, собранным командой разработчиков, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Можно выделить следующие виды требований к программным продуктам: – Бизнес-требованиясодержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы. В этом документе объясняется, почему организации нужна такая система, т.е. описаны цели, которые организация намерена достичь с ее помощью. – Бизнес-правила включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. – Требования пользователей основываются на целях и задачах, которые пользователям позволит решать будущая система. К способам представления этого вида требований относятся варианты использования, сценарии, прецеденты, таблицы " событие-отклик" и т.п. – Функциональные требования - это перечень функций или сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.п., так же указывается, что система не должна делать, т.е. накладываются ограничения поведение системы. Спецификация функциональных требований включает в себя описание функций, которые не должны быть противоречивыми и взаимоисключающими. – Нефункциональные требования связаны с такими интеграционными свойствами системы, как надежность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения, накладываемые на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе. Нефункциональные требования можно разделить на две большие категории, соответствующие поведенческим и структурным аспектам приложения. Первая категория содержит атрибуты, имеющие значение при исполнении приложения, то есть в режиме его работы. Вторая категория определяет атрибуты, относящиеся к аспектам проектирования приложения. Атрибуты качества при исполнении приложения: – Доступность - требования ко времени непрерывной работы приложения, например, 24x7, минимальное время простоя и т.п. – Надежность - поведение приложения при наступлении нештатных ситуаций, например, автоматический перезапуск, восстановление работы, дублирование важных данных, резервирование логики. – Требования к долговременному хранению результатов работы приложения, например, использование базы данных, требования ко времени продолжительности хранения данных. – Масштабируемость - требования к горизонтальному или вертикальному масштабированию приложения. – Требования к удобству использования приложения с точки зрения использования, поддержки. – Требования к безопасности работы или использования приложения, связанные с разграничением доступа, работой с приватными данным, снижения подверженности рискам от внешних атак. – Требования к конфигурируемости работы приложения, взаимодействия и расположения компонентов. – Требования к производительности решения, количество одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, скорости и пропускной способности каналов связи. – Описание ограничений, накладываемых на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи. Атрибуты качества при проектировании приложения: – Требования к повторному использованию реализации или компонентов приложения, а также реализация приложения с возможностью повторного его использования для различных задач. – Требования к расширяемости приложения в связи с появлением новых функциональных требований. – Требования к портируемости (переносимости) приложения на различные платформы. – Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия. – Требования к различным аспектам поддержки приложения, таким как дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе – Требования к разделению приложения на модули. – Требования к возможности автоматического и ручного тестирования приложения, наличие необходимого инструментария. – Требования к возможности и простоте локализации приложения, перечень языков, на которые предполагается локализация приложения. – Особые требования к совместимости между версиями приложений, между различными приложениями и внешними подсистемами. – Так же можно привести следующую классификацию нефункциональных требований: системные требования и ограничения, требования качества, внешние системы и интерфейсы. Процесс формирования и анализа требований проходит через ряд этапов: 1. Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система. 2. Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области. 3. Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований. 4. Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода. 5. Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. 6. Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость. Когда группа разработчиков начинает анализировать требования, заказчик обычно всё ещё формирует концепции того, что он хочет и что ему нужно. Это аналогично этапу уточнения требований при взаимодействии архитектора и клиента. Например, клиент может захотеть дом с четырьмя спальнями и большой гостиной. Но при уточнении требований клиент вынужден полагаться на архитектора, который должен помочь клиенту понять, чего последний хочет (например, просторную гостиную, в которой можно разместить 10 человек). Нужды заказчика несколько труднее определить, чем его желания. Например, заказчик может захотеть, чтобы музыкальное приложение позволяло компьютерным новичкам гарантированно записывать музыку, но ему также может быть нужна периодическая функция автосохранения для избегания потери работы. Являются ли последняя характеристика требованием, или это часть проектирования? Это зависит от соглашения между разработчиком и заказчиком. Если заказчик, осознав смысл автосохранения, принимает решения, что он действительно хочет иметь такую функцию, автосохранение становится требованием. Большая часть анализа требований является коммуникационной деятельностью, тщательно организованной для получения наилучших результатов. Выделяют следующие методы выявления требований: – интервью, опросы, анкетирование; – мозговой штурм, семинар; – наблюдение за производственной деятельностью; – анализ нормативной документации; – анализ моделей деятельности; – анализ конкурентных продуктов; – анализ статистики использования предыдущих версий системы; Рассмотрим один из способов проведения опроса заказчика Перед интервью: 1. Перечислите и расставьте приоритеты в списке интервьюируемых. 2. Спланируйте интервью с фиксированным временем начала и конца; – должны присутствовать как минимум два члена команды разработчиков; – приготовьтесь записывать видео или аудио файлы. Во время интервью: 1. Сконцентрируйтесь на слушании: – не будьте пассивны: исследуйте сами и побуждайте собеседника; – настаивайте на понимании желаний и изучении нужд; – обсудите варианты использования, а также потоки данных и диаграмм переходов состояний; – делайте подробные заметки;
После интервью: 1. составить черновик требований; 2. связаться с заказчиком для получения его замечаний по документу; Все важные для системы требования документируются в спецификации требований к программному обеспечению. Методические рекомендации В рамках сформированных проектных групп необходимо провести анализ предметной области и наиболее полно и точно сформулировать требования к разрабатываемому программному обеспечению. Требования целесообразно разделить на два основных подмножества: требования пользователей и требования разработчиков. Результатом этапа должна являться спецификация на ПО, составленная в следующем формате: 1. Введение 1.1 Цель (Цель документа в целом, а не цель ПО) 1.2 Область применения (Какие аспекты программы этот документ должен охватить) 1.3 Определения, термины и сокращения 1.4. Ссылки (исходные документы) 1.5 Обзор 2. Общее описание 2.1 Перспективы продукта 2.1.1 Концепции операций 2.1.2 Концепции пользовательского интерфейса 2.1.3 Аппаратные интерфейсы 2.1.4 Программные интерфейсы 2.1.5 Коммуникационные интерфейсы 2.1.6 Ограничения по памяти 2.1.7 Операции 2.1.8 Требования по адаптации 2.2 Функции продукта 2.3 Пользовательские характеристики (покажите, какие люди будут типичными пользователями программы) 2.4 Ограничения (все условия, которые могут ограничить возможности разработчика. Могут исходить из разных источников) 2.5 Предположения и зависимости (могут быть сделаны любые допущения) 2.6 Распределение требований 3 Детальные требования 3.1 Требования к внешнему интерфейсу 3.2 Детальные требования 3.3 Требования к производительности 3.4 Ограничения проектирования 3.5 Атрибуты программной среды 3.5.1 Надёжность 3.5.2 Доступность 3.5.3 Защита 3.5.4 Поддержка 3.6 Дополнительные требования 4 Дополнительная информация 4.1 Оглавление и индекс 4.2 Приложение Планирование проекта Планирование - это непрерывный процесс определения наилучшего способа действий для достижения поставленных целей с учетом складывающейся обстановки. От качества планирования во многом зависит результат всего начинания. Большой успех складывается из маленьких достижений, которые особенно важны в начале проекта и позволяют придать ему необходимый импульс и создать нужный настрой у его участников. Частые срывы и изменения плана будут играть отрицательную роль. И наоборот, достижение промежуточных целей позволяет почувствовать уверенность в своих силах и поверить в успех всего проекта. Планирование определяется как ответ на вопросы: – Что должно быть сделано? – Кто сделает? – Как они это сделают? – Как долго будут это делать? И т.д. План проекта - это единый, последовательный и согласованный документ, включающий результаты планирования всех функций управления проектом и являющийся основой для выполнения и контроля проекта. Под планом проекта должна стоять подпись всех членов команды. Наиболее часто используемый для планирования проекта метод – декомпозиция работ. Декомпозиция работ – процесс разделения, разбивки сложной задачи на несколько более простых. Основная причина неудачи проекта – что-то забытое, декомпозиция работ помогает избежать этой проблемы, поскольку её основная цель – охватить все задачи. Календарный план – это план, в котором объёмы работы разбиты по срокам. Календарный план призван обеспечить осуществление проекта в рамках намеченного времени. Обычный календарный план представляется в виде таблицы со следующей структурой: Таблица 6 – Календарный план Популярное:
|
Последнее изменение этой страницы: 2017-03-11; Просмотров: 712; Нарушение авторского права страницы