
- •Понятие информационной системы (ис). Корпоративные ис
- •Понятие жизненного цикла ис (жц ис). Стандарты жц ис.
- •Понятие жизненного цикла ис (жц ис). Каскадная модель жц ис.
- •Понятие жизненного цикла ис (жц ис). Спиральная модель жц ис.
- •Методология разработки ис. Модель зрелости cmm/cmmi.
- •Методология разработки ис. Гибкие методологии. Манифест гибкой разработки.
- •Методология разработки ис. Экстремальное программирование.
- •Методология разработки ис. Методология Scrum.
- •Методология разработки ис. Унифицированный процесс
- •10. Язык uml. Способы использования uml. Model Driven Architecture. Executable
- •12. Требования и прецеденты. Формат описания прецедента. Структура прецедента.
- •13. Модель предметной области. Концептуальные классы. Выделение концептуальных классов. Ассоциации и атрибуты концептуальных классов. Выявление ассоциаций и атрибутов концептуальных классов.
- •14. Архитектура по. Архитектурные факторы. Описание архитектуры.
- •16. Паттерн: понятие, структура, классификация.
- •1) Понятие паттерна
- •2) Структура и Классификация паттернов
- •Диаграмма прецедентов. Диаграмма развертывания.
- •Диаграмма классов. Обозначение классов. Отношение ассоциации.
- •3. Диаграмма классов. Обозначение интерфейсов. Отношение обобщения и
- •Диаграммы: конечных автоматов и деятельности.
- •5. Диаграмма последовательности.
- •Диаграмма коммуникации.
- •Принцип единственности ответственности (srp).
- •Понятие функциональной связности (Cohesion). Принцип High Cohesion.
- •9. Понятие степени связанности (Coupling). Принцип Low Coupling.
- •Принцип открытости/закрытости (ocp).
- •Solid: принцип подстановки Лискоу (lsp)
- •Solid: принцип разделения интерфейса (isp).
- •Solid: принцип инверсии зависимости (dip).
- •Формулировка
- •1. .Net Framework. Общеязыковая среда исполнения (clr). Управляемые модули и
- •Net Framework. Механизм сборки мусора.
- •C#. Объявление класса.
- •C#. Делегаты. События.
- •C#. Наследование: правила, синтаксис. Сокрытие имен.
- •C#. Приведение типов. Операторы as и is.
Методология разработки ис. Методология Scrum.
Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост — легко изучается и применяется на практике. Вначале создаются требования ко всему продукту. Потом из них выбираются самые актуальные и создается план на следующую итерацию (спринт, Sprint). В течение итерации планы не меняются (этим достигается относительная стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и продемонстрировать, пусть и с минимальными функциональными возможностями. После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать.
Далее происходит планирование новой итерации и все повторяется. Внутри итерации проектом полностью занимается команда. Она является плоской, никаких ролей Scrum не определяет. Синхронизация с менеджментом и заказчиком происходит после окончания итерации. Итерация может быть прервана лишь в особых случаях.
Владелец продукта (Product Owner)
Scrum-мастер (Scrum Master)
Scrum-команда (Scrum Team)
Sprint Planning Meeting. Проводится в начале каждой итерации. Сначала Produсt Owner, Scurm-мастер, команда, а также представители заказчика и пр. заинтересованные лица определяют, какие требования из Project Backlog наиболее приоритетные и их следует реализовывать в рамках данной итерации. Формируется Sprint Backlog. Далее Scurm-мастер и Scrum- команда определяют то, как именно будут достигнуты определенные выше цели из Sprint Backlog. Для каждого элемента Sprint Backlog определяется список задач и оценивается их трудоемкость.
Daily Scrum Meeting — пятнадцатиминутное каждодневное совещание, целью которого является достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план сообразно реалиям сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущей встречи, мои проблемы, что я буду делать до следующей встречи? В этом совещании может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство
реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды. Такие встречи поддерживают дисциплину обязательств в Scrum-команде, способствуют удержанию фокуса на целях итерации, помогают решать проблемы «в зародыше». Обычно такие совещания проводятся стоя, в течение 15-20 минут.
Sprint Review Meeting. Проводится в конце каждой итерации. Сначала Scrum-команда демонстрирует Product Owner сделанную в течение итерации работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных представителей заказчика. Product Owner определяет, какие требования из Sprint Backlog были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в Sprint Backlog для следующей итерации. Во второй части митинга производится анализ прошедшей итерации, который ведет Scrum-мастер. Scrum-команда анализирует в последней итерации положительные и отрицательные моменты совместной работы, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также ищет пути для увеличения эффективности дальнейшей работы. Затем цикл повторяется