лабы тоип. !!! Лаб раб по _ТОИП Челябинск. Учебнометодическое пособие 1 оу во ЮжноУральский институт управления и экономики
 Скачать 2.3 Mb.
|
|
0 НОСОВА Л.С. ОСНОВЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ Учебно-методическое пособие 1 ОУ ВО «Южно-Уральский институт управления и экономики» НОСОВА Л.С. ОСНОВЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ Учебно-методическое пособие Челябинск 2015 2 ББК 32.973я73 УДК 004 Л 33 Автор: Носова Л.С. – кандидат педагогических наук, доцент кафедры информационных технологий и систем ЧОУ ВПО «Южно-Уральский институт управления и экономики». Рецензенты: Т.Н. Лебедева – кандидат педагогических наук, доцент ОУ ВО «Южно- Уральский институт управления и экономики»; О.А. Дмитриева – кандидат педагогических наук, доцент кафедры информатики, информационных технологий и методики обучения информатике ФГБОУ ВПО «Челябинский государственный университет»; А.Г. Кириченко – кандидат технических наук, доцент ФГБОУ ВПО «Челябинский государственный университет». Носова, Л.С. Основы программной инженерии: Учебно-методическое пособие / Л.С. Носова. – Челябинск: Полиграф-Мастер, 2015. – 79 с. Учебное пособие нацелено на формирование у обучающихся профессиональных компетенции по овладению области программной инженерии. Комплексная структура, предствляющая сочетание теоретической информации, методических рекомендаций и практических занятий, позволяет студентам освоить последовательность шагов по созданию информационных систем. Данное учебное пособие рекомендуется для самостоятельного изучения дисциплины «Основы программной инженерии», при подготовке к экзаменам и курсовой работе, а также в качестве методических рекомендаций для преподавателей. Учебное пособие предназначается для студентов, обучающихся по направлению 230400.62 «Информационные системы и технологии» при изучении дисциплины «Основы программной инженерии», всех форм обучения. ISBN © ОУ ВО «Южно-Уральский институт управления и экономики», 2015 © Носова Л.С., 2015 3 СОДЕРЖАНИЕ ВВЕДЕНИЕ .............................................................................................................. 4 Методические рекомендации ................................................................................. 6 Лабораторная работа №1 ........................................................................................ 9 Лабораторная работа №2 ...................................................................................... 16 Лабораторная работа №3 ...................................................................................... 21 Лабораторная работа №4 ...................................................................................... 34 Лабораторная работа №5 ...................................................................................... 40 Лабораторная работа №6 ...................................................................................... 42 Лабораторная работа №7-8................................................................................... 45 Лабораторная работа №8 ...................................................................................... 52 Лабораторная работа №9 ...................................................................................... 57 Лабораторная работа №14-16............................................................................... 65 ПРИЛОЖЕНИЕ ..................................................................................................... 75 СПИСОК ЛИТЕРАТУРЫ ..................................................................................... 78 4 ВВЕДЕНИЕ В настоящее время создание программных продуктов, с одной стороны, остается сложной задачей на стыке искусства, ремесла и логики, с другой стороны – многие процессы здесь автоматизированы и подкреплены соответствующими инструментами. Оставаясь прикладной областью, программная объединяет в себе множество практикоориентированных компонентов: тестирование программного обеспечения, программирование, проектирование и др. Основные слагаемые успеха инженеров программного обеспечения не являются секретом и лежат на поверхности: они придерживаться установленного плана, обеспечить качество продукта, не выходя при этом за рамки бюджета. Однако не все студенты в ходе освоения дисциплины учитывают, что помимо непосредственной разработки программных систем и их сопровождения, им необходимо анализировать требования заказчика, разрабатывать спецификации, реализовать сам проект, интегрировать его с другими, аттестовать и т.п. Данное учебное пособие составлено на основе многолетнего опыта преподавания дисциплины «Основы программной инженерии» в ОУ ВО «Южно-Уральский институт управления и экономики» в рамках подготовки по направлению бакалавриата 09.03.02 «Информационные системы и технологии». С другой стороны, оно может быть интересно и полезно и для студентов других направлений и специальностей, нуждающихся в практических рекомендациях по разработке программных продуктов, а также для коллег-преподавателей из сферы высшего и среднего профессионального образования. Учебное пособие нацелено на оказание помощь студентам в формировании их общекультурных и профессиональных компетенций в соответствии с федеральным государственным образовательным стандартом высшего образования: 09.03.02 «Информационные системы и технологии». Компетенции, формируемые в освоения дисциплины, представлены в таблице 1. 5 Таблица 1– Формируемые компетенции Код компетенции Наименование компетенции ПК-2 способность проводить техническое проектирование ПК-33 способность составлять инструкции по эксплуатации информационных систем 6 Методические рекомендации для преподавателей Дисциплина «Основы программной инженерии» осуществляет: − подготовку выпускников к проектно-технологической деятельности в области создания компонентов программных комплексов и баз данных, автоматизации технологических процессов с использованием современных инструментальных средств и технологий программирования; − подготовку выпускников к комплексным инженерным исследованиям для решения задач, связанных с разработкой программных средств, к работе по созданию программного обеспечения в проектных группах; − обучение методам командной работы. После изучения данной дисциплины выпускник должен решать следующие профессиональные задачи в соответствии с видами профессиональной деятельности. Проектно-конструкторская деятельность: − предпроектное обследование (инжиниринг) объекта проектирования, системный анализ предметной области, их взаимосвязей; − техническое проектирование (реинжиниринг); − рабочее проектирование; − выбор исходных данных для проектирования; − моделирование процессов и систем; − сертификация проекта по стандартам качества; − расчет обеспечения условий безопасной жизнедеятельности. Проектно-технологическая деятельность: − проектирование базовых и прикладных информационных технологий. В настоящее время ситуация на рынке труда такова, что при устройстве на работу от выпускника требуется опыт разработки программного обеспечения. Выйдя из стен высших учебных заведений, вчерашние студенты сталкиваются с рядом проблем: у них нет опыта создания программ в реальных условиях, они не умеют работать в команде. Возникает неуверенность в своих возможностях и перспективах. Конечно, при подготовке будущих инженеров преподаватели применяют различные подходы к повышению качества уровня знаний, 7 умений и навыков студентов. Например, это может быть рейтинговая (балльно-рейтинговая) система оценивания студентов, формулирование заданий на курсовой проект на основе реальных заказов потребителей, конкурсы на самый лучший курсовой проект или квалификационную работу и т. п. Однако это не всегда готовит студента к реальной разработке. В связи с этим в данном пособии предложен подход к обучению проектированию программного обеспечения (ПО) на основе методологии разработки ПО Microsoft Solutions Framework (MSF). Освоение данного продукта приблизит студента к реальному процессу разработки программ, позволит получить навыки работы в команде. Методология MSF предложена корпорацией Microsoft и опирается на практический опыт компании. В ней описывается последовательность шагов по управлению людьми и рабочими процессами в ходе разработки программного решения. Для учебного процесса данная методология позволит четко регламентировать вехи (контрольные точки проекта) и тем самым реализовать контроль над выполнением проектов. Кроме того, фазы, представленные в методологии, соответствуют фазам, которые проходят студенты в процессе выполнения заданий, соответственно они смогут оценить время, необходимое для выполнения работы в целом. MSF предлагает следующие фазы работы над проектом: 1. Выработка концепции проекта. На этапе происходит осмысление полученного задания студентом, уточнение и предварительный поиск способов решения. В качестве премежуточного результата формируется концепция проекта. 2. Проектирование. На этом этапе осуществляется проектирование продукта различными методами сбора информации. В качестве подитога формируются сценарии использования, описание логического и физического дизайна средствами диаграмм UML. 3. Реализация. Результатом данной технологической фазы являются программный код и beta-версия ПО. 4. Тестирование. На этапе осуществляется тестирование разработанного ПО: функциональное, нагрузочное, стресс-тестирование. В 8 результате прохождения этапа исполнитель создает спецификацию тестирования, план внедрения и сам программный продукт. 5. Подведение итогов. На этапе осуществляется сбор всей документации, полученной на предыдущих этапах, а также организуется защита проекта перед преподавателем и/или комиссией. Финальным результатом являются оценки студентов по дисциплине в экзаменационной ведомости. Стоит оговориться, что при выборе данного подхода увеличивается нагрузка на преподавателя, т. к. ему необходимо выступать еще и в роли заказчика, а значит быть на связи со студентом в любое время. Эти вопросы решаются, например, посредством электронной почты. Кроме того, можно использовать специальные программы-органайзеры работы в команде, например, онлайн-сервис Битрикс24. В данном пособии представлены лабораторные работы для организации работы студентов в рамках первых двух фаз и последнего этапа – подведения итогов в виде конвейера проектов. В качестве проектов, которые будут разрабатывать студенты в течение курса, могут выступать их курсовые работы или реальные заказы образовательной организации. 9 Лабораторная работа №1 Методологии управления ИТ-проектами Цель: знакомство с методологиями управления ИТ-проектами. Теоретические вопросы В настоящее время управление проектами имеет свою методологию и основывается на определенных стандартах. В основе таких методов лежат методики сетевого планирования, которые появились США в конце 1950-х гг. При этом методики управления проектами широко распространились не только в странах с рыночной экономикой, но и в странах с т. н. «плановой» экономикой. Они начали использоваться в строительстве, что послужило основой их распространения в других отраслях и появлению методов проектного управления. Примером здесь может служить объединение усилий фирмы «Дюпон» и фирмы «Ремингтон Рэнд» для составления плана графика комплексных работ по модернизации заводов «Дюпон» с помощью вычислительной машины Univac в 1956 г. Результатом стало создание рационального и простого метода описания проекта на ЭВМ – метода критического пути (CPM – Critical Path Method). Практически параллельно и независимо был создан метод анализа и оценки программ PERT (Program Evaluation and Review Technique) в военно- морских силах США. Данный метод разрабатывался корпорацией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» для ракетной системы «Поларис». Проект включал 3800 основных подрядчиков и состоял из 60 000 операций. Благодаря использованию данного метода проект стал успешным и завершился на два года раньше срока. После наглядного успеха метод PERT стал использоваться в вооруженных силах США для планирования проектов. Задание: найдите примеры других крупных успешных проектов прошлого века, использующих для своего управления ЭВМ. Учтите, что с одной стороны, применение информационных технологий для планирования и управления проектами давало в те времена значительное преимущество, а с другой стороны, первые компьютеры были дорогостоящими и оставались доступными только крупным компаниям. Все 10 изменилось с появлением персональных компьютеров, теперь ЭВМ стала рабочим инструментом для руководителей более широкого круга. Система управления проектами постоянно развивалась и стала самостоятельной областью профессиональной деятельности. В итоге были созданы унифицированные методологии, инструментарии, механизмы, стандарты, доступные и для проектов в ИТ-сфере. Например, на сегодняшний день существует единая Международная ассоциация управления проектами – IPMA (International Project Management Association) с центром в г. Цюрих (Швейцария). Из наиболее распространенных можно отметить процессную модель, используемую в документах методологических основ управления проектами – Project Management Body of Knowledge (PMBOK) Американского института управления проектами (PMI). Данный документ признается международным стандартом де-факто. Кроме того, стандарт ISO 10006:1997 придал ряду наиболее важных положений РМВОК статус стандарта де-юре. В 2014 г. вышло пятое издание PMBOK, содержащее указания на 589 страницах. Все положения представлены на сайте http://www.pmi.org/default.aspx [6]. Данные Международной ассоциации управления проектами (IPMA) говорят о том, что использование современных методологий управления проектами экономит около 20–30% времени и около 15–20% средств на осуществление проектов. Все методологии (еще их называют моделями, методиками) разработки программного обеспечения классифицируют по «весу», т. е. по количеству формализованных процессов и детальности их регламентации. Следовательно, чем больше процессов документировано, чем более детально описана методолгия, тем больше будет ее «вес». 1. Тяжеловесные методологии: − ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Стандарты на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход к разработке программного обеспечения; − Capability Maturity Model for Software (SW-CMM) определяет пять уровней «зрелости проекта»; 11 − Rational Unified Process (RUP) – итеративная модель разработки; − Microsoft Solutions Framework (MSF) – база знаний компании Microsoft по разработки программ; − Personal Software Process – модель определяет требования к компетенциям разработчика. Team Software Process – модель ориентирует на самоуправляемые команды от 3 до 20 разработчиков. − и др. 2. Легковесные или agile-методики: − eXtreme Programming или XP – экстремальное программирование, предлагающее 12 инженерных практик; − Crystal Clear – семейство методологий, определяют необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач [13]; − Feature Driven Development (FDD) – функционально- ориентированная разработка; − OpenUP – итеративно-инкрементальный метод разработки программ, позиционируется как легкий и гибкий вариант тяжеловесной методологии RUP; − Scrum – управление разработкой информационных систем с высокой степенью неопределенности; − Kanban – методология «бережливого производства»; − и др. Результаты исследования Agile Survey о популярности гибких методологий представлены на рис. 1 [11]. Рис. 1. Популярность гибких методологий 12 Легковесные методологии Agile появились сравнительно недавно. В феврале 2001 г. 17 специалистов (консультантов и практиков) провели семинар, на котором сформулировали основные принципы гибкой разработки ПО – Agile Manifesto – манифест гибкой разработки. Он переведен на многие языки мира и доступен на сайте http://agilemanifesto.org/iso/ru/ [12]. Идея всех гибких (легковесных) методологий состоит в том, что применяемый в разработке ПО процесс должен быть адаптивным, ориентированным на людей и их взаимодействие. По сути это скорее набор практик, чем методология. На том же семинаре было предложено новое название таких методологий – гибкая разработка Agile Software Development. При выборе модели управления проектом можно ориентироваться на следующую таблицу (таблица 2). Таблица 2 – Выбор методологии управления проектом Вес модели Достоинства Недостатки Тяжеловесные − процессы рассчитаны на среднюю квалификацию исполнителей; − большая специализация исполнителей; − низкие требования к стабильности команды; − отсутствуют ограничения по объему и сложности выполняемых проектов. − требуют существенной управленческой надстройки; − длительные стадии анализа и проектирования; − формализованные коммуникации. 13 Продолжение таблицы 2 Легковесные (гибкие) − снижение непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями; − упрощение стадий анализа и проектирования, основной упор на разработку функциональности, совмещение ролей; − неформальные коммуникации. − эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды; − объем и сложность выполняемых проектов ограничены. А. Коуберн, один из авторов «Манифеста», провел анализ ИТ-проектов за последние 20 лет [4], выполненных на основании разных моделей управления: от облегченных, гибких до тяжелых (СММ-5). Данный анализ показал отсутствие корреляции между успехом или провалом проектов и выбранными моделями разработки, применяемыми в проектах. А. Коуберн сделал также вывод о том, что: 1. У каждого проекта должна быть своя модель процесса разработки. 2. У каждой модели – свое время. Для разработчиков это означает, что не существует единственного правильного процесса разработки. В каждом новом проекте процесс должен определяться каждый раз заново по «закону четырех П» (рис. 2). Рис. 2. Закон четырех П 14 |