Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Тьюторское сопровождение проектной деятельности студентов теоретико-методологические основы и практика реализации. Монография
.pdf
Глава 4.1. Возможности информационных технологий в реализации тьюторского…
Организация проектной деятельности по модели Водопада
(Waterfall)
Водопадная модель – это последовательный способ ведения
проектной деятельности. Когда проект очень простой и дальнейших изменений требований нет, то удобнее придерживаться этого
подхода.
Модель Водопада разделена на разные фазы (рис. 9). В модели
водопада каждая фаза должна быть завершена до начала другой
фазы и при этом мы не имеем возможности управлять несколькими фазами одновременно.
Сбор
требований
Технико-
экономическое
обоснование
Дизайн проекта
Разработка
Рис. 9. Модель Водопада
Тестирование
Обслуживание
151
Раздел 4. Практика организации тьюторского сопровождения проектной деятельности…
Рассмотрим основной проектный функционал каждой из фаз в
отдельности.
1. Этап – Анализ требований
На первом этапе командный аналитик получает проектное задание для технического анализа. Требования обычно оформляются в формате CRS (Спецификация требований клиента). CRS
объясняет, какие действия(или задачи) должны быть выполнены
в проекте и как готовое решение(допустим, приложение) должно
работать в соответствии с указанными требованиями. Проектный
аналитик конвертируют CRS в SRS (Спецификация требований к
проектному решению).
Далее аналитик подробно обсуждает спецификации требований с группой разработки и тестирования и понимает требования
с точки зрения разработки и тестирования. Это этап обсуждения и
анализа требований для создания прикладного решения на основе фактических требований. На этом этапе все должно быть задокументировано в документе спецификации требований к проектному решению. В каскадной модели (модель водопада) поставка /
результат / выход каждой фазы является источником входных данных для следующих фаз.
2. Этап – Технико-экономическое обоснование
На этом этапе участник с выбранной ролью менеджера проекта проведет технико-экономическое обоснование. Это означает, что
менеджер совместно с командой проанализирует такие параметры, как, может ли это требование / приложение быть разработано
на существующей у команды ресурсной базе или нет, доступных
ресурсов достаточно или нет, стоимость и многие другие факторы.
3. Этап – Дизайн проекта
На данном этапе участник команды с ролью архитектор проекта подготовит макет проекта. Он определит оборудование, системные требования и спроектирует архитектуру проекта. В системном
дизайне есть 2 части: дизайн высокого уровня и дизайн низкого
уровня. В высокоуровневом дизайне участники проекта разрабатывают и исследуют различные блоки проектного решения. В низкоуровневом дизайне пишется псевдокод (если разрабатывается
программное решение) или формируется бизнес-процесс (если реализуем социальный или экономический проект).
152
Глава 4.1. Возможности информационных технологий в реализации тьюторского…
4. Этап – Разработка
Здесь обучающиеся проектной группы начинают детальную
проработку всех блоков проектного решения. Например, при разработке программного обеспечения на этом этапе участниками
проекта, с выбранной технологической ролью, осуществляется точное кодирование каждой функции и пользовательского интерфейса приложения, используя разные методы и разную логику. Они
могут использовать любой язык программирования, например,
Java, Python для создания приложения.
После завершения этапа разработки каждой функции конкрет-
ного проектного модуля техническими участниками проекта выполняется модульное тестирование. Если код работает нормально, разработчик развернет код в тестовой среде и передаст сборку
участникам команды занимающимся тестированием проектного
решения.
5. Этап – Тестирование
На этом этапе участник проекта осуществляют тестирование по-
лученного продукта в соответствии с теми тест-моделями, которые
предлагаются для данного типа проекта: функциональное тестирование, интеграционное тестирование, системное тестирование,
приемочное тестирование, регрессионное тестирование, специальное тестирование, исследовательское тестирование и кросс-браузерное тестирование и т. д.
Рассмотрим пример тестирования программного продукта, как
наиболее частой задачи, решаемой при проектном обучении.
При функциональном тестировании начинают тестировать
каждый компонент приложения. На этом этапе проверяются различные компоненты, такие как текстовые поля, кнопки, ссылки,
переключатели, кнопки загрузки, раскрывающиеся списки и ссылки навигации.
Далее осуществляется проверка пользовательского интерфей-
са, внешний вид, а также положительные и отрицательные входные тесты. Осуществляется переход к интеграционному тестированию.
На этом этапе команда тестировщиков проекта проверяет инте-
грацию данных. Осуществляется проверка, отражаются ли одни и
те же данные на разных соответствующих страницах или нет, про-
153
Раздел 4. Практика организации тьюторского сопровождения проектной деятельности…
веряется навигация по электронной почте, по ссылкам на соответствующие страницы, интеграция данных со сторонними приложениями и проверяется изменения базы данных в приложении.
Далее проводится тестирование всей системы в целом. Технические специалисты команды проверяют все приложение как единое
целое: проверяют функциональность, интеграцию страниц, проверки полей, сообщения об ошибках, подтверждающие сообщения
и многое другое.
Во время тестирования проектного решения проектной группой, будут регистрироваться проблемы в инструменте отслеживания ошибок (специальное приложение и текстовый редактор).
Важно на этом этапе сформировать приоритет для ошибки в зависимости от проблемы. После записи о писания ошибки, она передается участнику проекта, ответственному за разработку для
устранения проблемы. После исправления ошибки проект заново
проходит все этапы тестирования.
На последующем этапе переходим к приемочным испытаниям,
проект тестируется в различных средах.
6. Этап – Техническое обслуживание
После передачи готового проектного решения заказчику, возможно формирование этапа обеспечения поддержки или обслуживания проектного решения. Этот этап предназначен для наблюдения и исправления производственных ошибок в реальном
времени, для улучшения приложения и для разработки новых изменений требований.
Анализируя все выше описанные этапы проектного решения,
можно сделать вывод о том, в каких случаях предпочтительней использовать модель водопада для работы тьютора или наставника:
● когда в проекте нет необходимости вносить постоянные изменения;
● когда проект небольшой и его структура состоит из малого
числа информационных или программных блоков;
● когда в проекте не предполагается использовать сложные методики или технологические решения;
● когда для решения проектной задачи доступно большое количество технических и информационных ресурсов.
Выделим основные плюсы использования модели Водопада:
154
Глава 4.1. Возможности информационных технологий в реализации тьюторского…
● Модель Водопада проста в использовании и понимании. Не
требует специальной подготовки руководителей проектов
или участников проектных команд.
● Легко управлять циклом Водопада. Каждый этап имеет фиксированные результаты и процесс проверки.
● Меньшая сложность, поскольку фазы не пересекаются. Фазы
следуют одна за другой. В модели используется четкая структура по сравнению с другими методологиями разработки программного обеспечения. Проект проходит через фиксированные последовательные этапы, начиная со сбора требований
и, наконец, до обслуживания.
● Благодаря поэтапному развитию проекта соблюдаются временные рамки выполнения этапов.
● Хорошо подходит для небольших проектов, где у нас есть четкие требования.
● Процессы и результаты выполнения проектных этапов хорошо документированы.
● Простота распределения подзадач между участниками проектного решения.
●В процессе работы над проектами, тьютору и наставнику легко оценить прогресс решения проектной задачи, так как начало и концы каждого этапа предопределены заранее.
● Требования практически не меняются на протяжении всего
проекта, поэтому задачи остаются стабильными для разработчиков. Кроме того, любому новому участнику проектной
деятельности легко быстро освоиться и начать работу.
● Спецификация функциональных требований, задокументированная на этапе сбора требований, дает проектной команде
достаточно деталей для разработки сценариев тестирования
и тестовых случаев. Следовательно, в водопадной модели
процесс тестирования становится простым.
Но также следует выделить и основные минусы, по мнению ав-
торов, характерные для модели водопада:
● Поскольку все требования должны быть четко известны перед началом разработки проектного решения, увеличиваются сроки выполнения проекта.
● Требуется обширное исследование потребностей пользователей.
155
Раздел 4. Практика организации тьюторского сопровождения проектной деятельности…
●На начальном этапе проекта заказчику сложно четко определить и концептуализировать свои требования в форме функциональных спецификаций. Следовательно, существует высокая вероятность того, что они передумают после просмотра
конечного продукта. Это изменение также может произойти
из-за бизнес-плана или влияния рынка. Низкая гибкость
этой модели затрудняет адаптацию к любым таким изменениям, особенно когда продукт нуждается в значительной модернизации.
● Нет возможности создать рабочую модель до поздних стадий
жизненного цикла водопада.
● Медленные сроки реализации проекта. Заказчик не сможет
увидеть проектное решение, пока оно не будет полностью завершено.
● Заказчик не имеет возможности заранее ознакомиться с проектным решением. Модель водопада используется для внутренней организации рабочего процесса.
● Сроки могут быть пропущены, если не соблюдаются строгий
менеджмент и регулярный контроль.
● Нет места для изменений, даже если они видны во время разработки, поскольку продукт не будет соответствовать требованиям заказчика.
● Откладывает тестирование до завершения. Кроме того, на
этом этапе большие изменения обходятся очень дорого.
●В каскадной модели присутствуют высокий риск и неопределенность, поскольку существует слишком много места для
того, чтобы проблемы оставались незамеченными до тех пор,
пока проект не приблизится к завершению.
●Не подходящая модель для длительных и сложных проектов.
● Тестировщики будут сидеть без дела на многих этапах про-
екта.
Организация проектной деятельности с использованием Гибкой
модели (Agile workfl ow)
Гибкая модель проектной деятельности или Agile workfl ow – это
продвинутый подход к процессу разработки проектного решения.
Agile определяется как жизненный цикл разработки проектного
156
Глава 4.1. Возможности информационных технологий в реализации тьюторского…
решения на основе спринтов (рис. 10). Эта модель связана с методом управления проектами, для которых характерно разделение
задач на короткие фазы работы и частая переоценка и адаптация
планов.
Рис. 10. Гибкая модель организации проектного решения
При использовании гибкой модели (далее Agile) участники проектной деятельности работают параллельно над разработкой и тестированием проектного решения. Проект ведется в итеративном
режиме. Каждая итерация проектного решения требует от участников проектной деятельности анализа, проектирования, кодирования и тестирования.
Участник проектного решения тщательно анализируют каждое
требование заказчика, чтобы убедиться, что оно безошибочно и реализуемо. Весь процесс выполнения проектных задач сводится к переходу на следующую итерацию после окончания предыдущей, при
этом добавляя или изменяя предыдущие требования к проекту.
Таким образом, этот процесс разработки и тестирования проектного решения выполняется в короткие сроки с большей точностью
и гибкостью.
Рассмотрим ключевые термины, которые используются при работе с Agile.
Б эклог – это список задач для разработчиков проектного реше-
ния, которые нужно реализовать в текущей итерации или спринте.
157
Раздел 4. Практика организации тьюторского сопровождения проектной деятельности…
Спринт – это небольшая продолжительность, в течение которой участникам проектной деятельности нужно реализовать выбранные проектные задачи из бэклога в течение определенного
временного периода. Продолжительность спринта составит от 2 до
3 недель. Его продолжительность варьируется от решения проектной команды.
В течение этого спринта команда должна проанализировать
требование, разработать требования, выполнить кодирование, тестирование, исправление проблемы, повторное тестирование, регрессионное тестирование, демонстрацию и многие другие действия.
С тендап-митинг (ежедневная встреча) – участники проект-
ной команды (аналитик, разработчик, тестировщик, руководитель
проекта) участвуют в ежедневных встречах, цель которых, обсудить: что было сделано вчера, план работы на предстоящий день,
а также любые проблемы или зависимости, с которыми они сталкиваются в проекте.. Встреча, которая может проводиться как в
оффлайн так и в онлайн форматах, не должна длиться более 15–
30 минут.
Канбан диаграмма/Канбан доска – это диаграмма / инструмент управления проектом. Благодаря этому инструменту участник проекта могут управлять задачами всего проекта. Каждый
участник проектной деятельности (студент, преподаватель, наставник или тьютор) могут проверить статус выполнения проекта
и статус работы отдельных лиц. Он показывает графическое цифровое представление элементов прогресса, ожидающих элементов,
готовых элементов (рис11).
С крам Мастер – человек (в качестве этой роли может высту-
пать наставник или тьютор, в некоторых случаях руководитель
проекта), который помогает команде следовать гибкому процессу и соответствовать требованиям проекта. Он проводит ежедневную встречу и помогает обсудить потребности проекта. Скрам-мастер действует как промежуточное звено для всех членов команды,
чтобы разрешить проблемы и зависимости, которые встречаются
в проекте. В его задачи также входит отслеживать ход проекта и
фиксировать результаты по каждому спринту.
158
Глава 4.1. Возможности информационных технологий в реализации тьюторского…
Рис. 11. Пример Канбан-доски
История пользователя – это блок требований к проектному ре-
шению. Он содержит набор вариантов использования / требований,
связанных с одним и тем же модулем или этапом выполнения проектной задачи. В данном блоке определяется, как должен работать
каждый блок проекта и как должен выглядеть итоговый продукт.
Задачи – участники проектной команды формируют задачу для
пользовательской истории, которая им назначена. Им необходимо создать задачу на основе различных подзадач, таких как, например, задача разработки, задача тестирования, задача анализа
пользовательской истории.
Итерация – это разработка и тестирование некоторых моду-
лей / частей проектного решения. Каждая итерация состоит из
анализа задачи, проектирования продукта, разработки продукта,
тестирования продукта и демонстрации продукта.
На эффективность использования Agile в проектной деятельно-
сти студентов влияют следующие факторы:
● Наблюдение: участник проектного решения должны регулярно пересматривать работу и продукт и соответствующим
образом планировать свои действия.
159
Раздел 4. Практика организации тьюторского сопровождения проектной деятельности…
● Приветствуются изменения: изменения вносятся очень легко. Это не сильно влияет на продукт, поскольку модули проектного решения разрабатываются отдельно и интегрируются позже. Таким образом, никаких переделок не будет, если в
будущем требование изменится.
● Временные рамки: участникам проекта даны временные
рамки для выполнения каждой задачи и подзадачи.
● Удовлетворенность заказчиков проектного решения: удовлетворенность заказчика больше, потому что мы взаимодействуем с кзаказчиком проектного решения на протяжении
всего проекта, и есть возможность провести демонстрацию на
каждом уровне разработки проекта.
В настоящий момент существует несколько типов гибких методологий организации проектной деятельности (рис.12), отличающихся только спецификой применения в определенной предметной области.
Agile
Scrum
160
Kanban
ʶ
Agile
ʺ
XP
ʺ
DSDM
Рис. 12. Подвиды гибких методологий
ʺ
FDD
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]