Творческий конкурс для педагогов «Осенний листопад»

 

Творческий конкурс для педагогов «Самая лучшая Зима»

 

Конкурс для педагогов «Лучший конспект урока (занятия)»

 

Конкурсы на нашем сайте ped-kopilka.ru

План урока информатики для студентов колледжа. Разработка программного обеспечения по предмету «Управление проектами»

Тема урока: Разработка программного обеспечения.
Тип урока: Изучение нового материала с использованием учебной видеопрезентации и объяснения по ходу демонстрации слайдов.
Цель урока: познакомить студентов со схемой эффективного управления разработкой программного обеспечения в современных условиях. Дать понимание организации процесса разработки в группе.
Задачи урока: поэтапно показать процесс разработки ПО. Для этого показать роли участников проектной группы и взаимосвязи между ними.
Наглядный материал: видеопрезентация, детально поэтапно раскрывающая роли и деятельность каждого из участников разработки ПО.
Требования к уроку:
• Наличие технических средств (компьютер, проектор, экран)
• Присутствие на уроке всех студентов
• Наличие у студентов тетрадей для конспектирования.
Ход урока
1. Перекличка присутствующих студентов.
2. Разработка программного обеспечения предполагает комплекс действий по анализу, планированию, разработке, тестированию и внедрению программных продуктов. Но здесь не подойдет методология строгого крупномасштабного планирования, когда сначала пишется план разработки, а потом все части программного продукта разрабатываются согласно этому плану. Рынок информационных технологий постоянно и стремительно обновляется. И вполне вероятно, что пока новое ПО будет разрабатываться согласно плану, то оно станет уже просто неактуальным. Конкуренты выпустят более продуктивные аналоги. Поэтому при разработке ПО решающую роль играет связь с заказчиком, который держит под контролем ситуацию на IT-рынке и при изменении рыночных требований сразу же вносит корректировку в требования к будущему программному продукту.

3. Демонстрация на экране поясняющего изображения «Спринт».
Разработка программного продукта происходит за короткие временные интервалы, после каждого из которых заказчику выдается небольшой, но законченный, работающий, отлаженный и протестированный кусочек будущего программного комплекса. Этот кусочек сразу же может быть использован для практической работы. При этом, если разработанный элемент успел стать неактуальным, или не устраивает заказчика, он будет переделан с минимальными потерями, поскольку времени и труда на него было затрачено достаточно немного. Но такое случается редко – ведь заказчик постоянно находится в курсе разработки и заранее проверяет актуальность и целесообразность каждого его этапа.
Каждый временной интервал (итерация, спринт) делится на строго определенные этапы. В общем виде они представляют собой анализ и постановку задачи, разработку алгоритмов, кодирование, отладку, тестирование, внедрение элемента ПО. Но поскольку времени на все эти вещи предоставлено немного, то команда IT-проекта должна действовать очень слаженно и согласованно. Ежедневно разработчики собираются вместе и обсуждают, что было сделано за предыдущий день, что предстоит сделать сегодня и что не удалось. Все вместе они ищут причины неудач и меры их скорейшего устранения.Вот так, шаг за шагом, маленькими приращениями большого продукта создаются современные программные комплексы.

4. Демонстрация на экране схемы разработки ПО

Разработка программного обеспечения требует скоординированной работы сразу нескольких специалистов. Поэтому современные программные продукты обычно создаются командами разработчиков. У каждого члена команды есть своя строго определенная роль, которая тесно связана с ролями других участников. Именно в таком тесном и точном исполнении ролей всеми членами команды и кроется успешная разработка качественного программного продукта. В небольших командах один специалист может совмещать сразу несколько ролей.

5. Роли участников проекта

Теперь мы рассмотрим эту схему подробнее.

Кого вы видите? Человечков не так уж много: Заказчик, Аналитик, Тестировщик, UI-тестировщик, Backend-разработчик, Frontend-разработчик и Дизайнер.

Демонстрация видеопрезентации«Современные методы разработки программного обеспечения»
Вместе с презентацией происходит рассказ учителя о роли каждого участника проекта. Каждый из персонажей схемы управления поочередно появляется на экране, а также выстраиваются связи между участниками проекта.
Начинается все с Заказчика.

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

Аналитик
Аналитик (или системный аналитик) – это специалист по разработке технического задания. В его задачу входит анализ и формализация требований проекта в течение всего его жизненного цикла. Аналитик должен собрать как можно больше исходной информации о будущем проекте. При этом Заказчик сам часто не представляет до конца, в полном объеме, какой именно продукт он хочет получить на выходе. Обычно он ограничивается только общими требованиями. Он ожидает конкретизации своего заказа от разработчиков как от специалистов в данной области. Поэтому Аналитик должен обладать не только специальными профессиональными знаниями, но и развитыми навыками общения. Он должен стать связующим звеном, мостиком, между Заказчиком и командой разработчиков.
Чтобы точно установить цели проекта и для Заказчика, и для разработчиков, Аналитик должен уметь очень точно выделить предметную область будущего проекта и задачи в этой предметной области.
Этап аналитики в проекте является самым важным из всех этапов, поскольку ошибки системного анализа, выявленные на более поздних этапах, сделают ненужной всю работу, уже проделанную на данной итерации другими членами команды, и ее придется начинать с самого начала. И, само собой разумеется, что никто не станет оплачивать переделку напрасно выполненной работы – весь коллектив разработчиков останется без зарплаты. Поэтому ошибки аналитики в проекте являются самыми «дорогими» по масштабу последствий. Их появление в проекте недопустимо.
После определения предметной области, системный аналитик составляет ряд рабочих документов:
· Функциональные сценарии – это сценарии, которые описывают логику работы всей системы в целом. Чем сложнее система, тем строже должна соблюдаться последовательность взаимосвязанных процессов-сценариев. Сценарии отдельных процессов, выстроенные в строгой логической взаимосвязи, позволяют описать действие всей системы в динамике. Функциональные сценарии от Аналитика отправляются к Bаckend-разработчику и Тестировщику.
· Пользовательские сценарии – это сценарии взаимодействия системы с теми людьми, которые будут ее непосредственно использовать – Администратором, Модератором, Оператором (пользователем). Пользовательские сценарии - это сценарии того, что пользователь будет видеть на экране и того, как система будет реагировать на его действия. Пользовательские сценарии Аналитик передает Frontend-разработчику и Дизайнеру.
· Прототипы – модели финального продукта для проведения тестирования и уточнения. За время разработки проекта создается несколько версий прототипов, позволяющих отслеживать усовершенствования продукта. Прототипы Аналитик передает Дизайнеру.
После передачи сценариев и прототипов следующим разработчикам участие Аналитика в проекте не заканчивается. Фактически он продолжает держать в голове весь проект и его задача – сохранить целостную «картинку» даже при самых глобальных изменениях требований. Поскольку разработка ПО происходит в условиях поэтапного уточнения конечных требований, то их постоянное изменение - процесс естественный. Поэтому Аналитик должен постоянно отслеживать изменения и в соответствии с ними корректировать все части системы.

Backend-разработчик
Вack-end (задняя, изнаночная сторона) – это обобщенное название программно-аппаратной части информационной системы. Работа этой части программы не видна пользователю – она скрыта от него на внутреннем уровне. Сюда относятся базы данных, компоненты обработки хранящейся в них информации, а также вся программная логика. Вack-end является аппаратно-зависимым представлением. Если речь идет о веб-разработке, то под бекендом понимают работу серверной части сетевой информационной системы (в отличие от фронтенда – программного обеспечения клиентской стороны ).
Соответственно, backend-разработчик – это специалист, отвечающий за функциональную реализацию архитектуры системы в целом. Bekender должен уметь проектировать базы данных, выстраивать между ними связи, управлять логикой взаимодействия между компонентами системы. Он должен перенаправлять на обработку получаемые от пользователя данные и возвращать полученный результат. Для этого Bekend-разработчику необходимы знания по основам frontend-разработки, чтобы понимать в каком виде к нему придут входные данные и в каком виде их следует потом возвращать в интерфейс.
Результат работы backend-разработчика – АPI-наборы (application programming interface), которые Bekender передает Тестировщику.

Тестировщик
Тестировщик – это специалист, выясняющий насколько разработанная система работоспособна и отказоустойчива. Основная задача тестировщика – выявить возможные ошибки при работе с программным обеспечением. Тестировщик словно встает на место пользователя и начинает давать системе задания для решения. Реакция системы должна точно соответствовать функциональным сценариям, переданным Тестировщику Аналитиком. Для качественной проверки системы Тестровщик разрабатывает специальные тесты, заставляющие все части системы работать в стандартных и нестандартных режимах, которые могут возникнуть после передачи ее в эксплуатацию. Тестировщик разрабатывает специальные позитивные и негативные сценарии. Позитивные сценарии отражают всё то, что было заложено в функциональных сценариях. Негативные сценарии должны охватывать все ситуации, которые в функциональных сценариях не рассматривались. Для этого Тестировщику просто необходимы навыки аналитика. Для успешной работы Тестировщик должен не просто владеть языком программирования, но и в некоторых случаях он должен владеть им даже лучше, чем разработчики. Качество тестирования самым радикальным образом влияет на качество конечного программного продукта.
Все выявленные несоответствия функциональным требованиям Тестировщик тщательно документирует и возвращает backend-специалисту. Так происходит до тех пор, пока Тестировщик не даст «добро» на продолжение разработки не передаст протестированные API Frontend-разработчику. Это означает, что максимально возможное количество ошибок в наборах API выявлено и устранено.

Дизайнер
Дизайнер – это «узкий» специалист. Его предназначение в команде – продумывать все тонкости интерфейса будущей системы. Именно Дизайнер принимает окончательно решение о том, каким образом будут происходить изменения на экране пользователя. Он продумывает цветовые решения, форму и положение курсора и указателя мыши в различных режимах, размеры, расположение и свойства всплывающих окон, внешний вид средств навигации и представления данных в отчетах и выкладках.
В результате его работы появляются на свет так называемые исходники дизайна – эскизы всех возможных режимов работы интерфейса. Эти эскизы Дизайнер передает Frontend-разработчику, который осуществляет на их основе реализацию пользовательского интерфейса.

Frontend-разработчик
Front-end (передняя, лицевая сторона) – эта та часть информационной системы, которая находится в непосредственном контакте с пользователем. Frontend-разработчик соответственно – это специалист по разработке пользовательского интерфейса. Именно он выстраивает связи между внутренней логикой системы, заключенной в API-наборах, и действиями пользователя. Его задача сделать систему дружественной и понятной пользователю, и при этом удовлетворяющей всем его требованиям. Он разрабатывает машинно-независимые представления интерфейса, которые в дальнейшем будут соединены с API и составят единую информационную систему. Когда речь идет о разработке веб-сайта, то под front-end принято понимать его клиентскую часть.
Frontend- разработчик обычно хорошо владеет кодом разработки API и серверной разработки. Это требование вытекает из необходимости понимать все особенности API, созданных на предыдущем этапе.
Frontend-разработчик получает от Аналитика пользовательские сценарии, на основе которых разрабатывает программные модули, отвечающие за логику действий пользователя. От Дизайнера он получает исходники дизайна, которые будут положены в основу внешнего вида будущего интерфейса, от Тестировщика – протестированные API-наборы. Итогом работы frontend-специалиста является так называемая alpha-версия информационной системы, которая передается на проверку UI-Тестировщику – специалисту по тестированию интерфейсов.

UI-Тестировщик проверяет работоспособность интерфейса в разных режимах и составляет список выявленных ошибочных ситуаций в поведении системы. Этот список UI-Тестировщик передает обратно Frontend-разработчику для исправления ошибок.

UI-Тестировщик
UI-Тестировщик (UserInterface) – это в широком смысле специалист по эргономике. В его задачи входит тестирование интерфейса alpha-версии системы на удобство ее использования и на соответствие своему назначению. Несмотря на кажущуюся малозначимость такой работы, UI-тестирование имеет огромное значение в разработке качественной информационной системы. Удобство использования всех ее возможностей и инструментов позволяет эксплуатировать систему с максимальной производительностью – и наоборот, мелкие неудобства будут вызывать у пользователя чувство раздражения и снижать эффективность работы ПО в целом.
Все кнопки, ссылки и инструменты должны быть удобно расположены, они должны обеспечивать быструю и удобную смену экранов, должны однозначно идентифицироваться пользователем. Все элементы интерфейса должны отвечать принятым стандартам, должны адаптироваться к различным разрешениям экрана и аппаратному обеспечению. Цветовые решения должны быть сбалансированными и не утомлять зрение. Ну и, разумеется, в интерфейсе недопустимы грамматические ошибки и неточности.
Все возникшие проблемы UI-Тестировщик документирует и возвращает на доработку frontend-специалисту. Когда в процессе UI-тестирования не будет выявлено ни одной проблемы со стороны пользовательского интерфейса, то система в виде beta-версии передается в эксплуатацию Заказчику.

Вопрос: ребята, а как вы думаете, какой еще один важный этап не отражен на схеме?
Ответ: внедрение и сопровождение готового продукта.

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

6. Выводы
Какие выводы мы можем сделать из того, что узнали на этом уроке?
• Современное программное обеспечение разрабатывается группой специалистов, каждый из которых строго исполняет свои функции.
• ПО разрабатывается маленькими приращениями (подзадачами) большого конечного продукта.
• Приоритет задач может меняться в зависимости от изменения требований к проекту.
• Каждая подзадача разрабатывается за короткий промежуток времени – спринт.
• После передачи полного готового продукта заказчику, разработчики ведут еще некоторое время наблюдение за качеством созданного ПО – сопровождение.

7. Какие у вас возникли вопросы в течение сегодняшнего урока? (Ответы на вопросы и обсуждение новой темы)

8. Домашнее задание
Самостоятельно прочитать стр. 9-18 методического пособия (тема «Разработка программного обеспечения»). Знать роли участников проекта и пакеты документов, которыми они обмениваются. Уметь объяснить взаимосвязи между разработчиками в группе.

Рекомендуем посмотреть:

Конспект урока информатики для 2 курса колледжа. Информационные технологии Практическая работа для студентов 3 курса по дисциплине «Пакеты прикладных программ» на тему «Автома Коснпект урока информатики для студентов колледжа. Задачи оптимизационного моделирования Практическое пособие по MathCad для студентов СПО
Пить или не пить? | Учебно-методическое пособие «УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» для самостоятельной внеаудиторной работы студентов по дисциплине «Управление проектами»
Опубликовано: 2850 дней назад (2 февраля 2017)
Просмотров: 2312
Рубрика: Без рубрики
0
Голосов: 0

Нет комментариев. Ваш будет первым!