ПРОГРАММА ПОВЫШЕНИЯ КВАЛИФИКАЦИИ ИНЖЕНЕРНЫХ КАДРОВ «Системный архитектор программного обеспечения. Часть 1» Продолжительность 112 часов.

УГС, направления подготовки: Информатика и вычислительная техника, Прикладная информатика Приоритетное направление модернизации и технологического развития экономики России: Развитие стратегических информационных технологий Согласование: ООО «Фуджитцу Сервисез» Слушатель прошедший подготовку и итоговую аттестацию должен быть готов к профессиональной деятельности: выполнение проектно-конструкторских, Разработка архитектуры, требований и спецификаций на уровне подсистем больших проектов; взаимодействие с заказчиком по обсуждению проектных решений; возложена определенная ответственность и автономность в принятии решений в качестве: архитекторов ПО малых компаний, руководителей проектов и руководителей команд разработчиков, старших технических специалистов, а также руководителей и специалистов корпоративных ИТ–отдело Соответствует 4-му квалификационному уровню стандарта АПКИТ «Системный архитектор»

Содержание программы Формат обучения: очная с отрывом от производства. График обучения: общая продолжительность обучения 14 дней, суббота – воскресенье выходной. Модуль 1 «Эволюция сложных систем » – 4 дней, Модуль 2 «Методы разработки ПО» – 5 дней. Модуль 3 «Архитектуры сложных систем» – 5 дней. Наименование модулейВсего часов лекци й практи ка Самост. работ 1Эволюция сложных систем (сопровождение ПО, ре- инженеринг) Методы разработки ПО Архитектуры сложных систем4020 Итоговая аттестация2 ИТОГО

Содержание модуля 1. «Эволюция сложных систем » Понятие эволюции ПО, различные определения Место эволюции в жизненном цикле ПО Эволюция ПО в терминах моделей и методологий (RUP, Agile и др.) Виды эволюции ПО (улучшающая, адаптивная и др.) Сопровождение ПО Реинжиниринг ПО Правила реинжиниринга (управление нарастанием сложности, использование обратной связи и др.) Методы и инструменты реинжиниринга ПО Трансформации кода

Примеры Практических заданий. Модуль 1. «Эволюция сложных программных систем» Практическое задание 1 Индивидуальная работа «Создание плана эксплуатационного обслуживания ПО» Цель: научиться формулировать требования к обслуживанию ПО и служебную информацию, необходимые в процессе эволюции ПО. Формулировка задания: Практическая работа по этому заданию состоит из нескольких частей: 1) В течение первого дня тренер вместе с группой совместно разбирают предлагаемую структуру плана экспуатационного обслуживания ПО, выясняются функциональное назначение каждого раздела и обсуждаются примеры заполнения. 2) Далее, каждый в качестве домашнего задания получает задачу составить план экспуатационного обслуживания ПО для любого выбранного проекта. Идеально, если бы каждый взял для описания тот проект над которым работает в текущий момент. Это позволит, кроме собственно повышения навыков, принести реальную пользу для организации. Список соответствия тем и слушателей составляется. Если нет возможности взять персональную тему, на выбор предлагается набор следующих систем: a. Веб-сайт: Система Интернет-банка Raiffeisen CONNECT ( [внимание на безопасность и надежность] b. Веб-сайт: (обратить внимание: реклама и коммьюнити) c. Система биллинга сотового оператора (например МТС) d. Веб-сайт: ЭТП ТНК (электронная торговая площадка для торговли нефтепродуктами) 3) Во второй день собираются результаты для проверки инструктором. 4) В течение третьего дня выделяется время для разбора сделанных заданий, обсуждаются наиболее частые ошибки и недоработки, выдаются рекомендации для улучшения работ.

Модуль 1. «Эволюция сложных программных систем» Практическое задание 2 Разбор кейса «Использование SOA архитектуры для рефакторинга сложных наследуемых систем» Цель: научиться выявлять некоторые проблемы в программной архитектуре сложных наследуемых систем, понять преимущества подхода сервис- ориентированной архитектуры приложения. Сценарий задания: В качестве наглядного материала используем презентацию: SEP-SEMPractice2- SOA-Refactoring.ppt В качестве групповой работы выделяем проблемы которые несет использование системы в текущем виде. Также делаем предположения о том чем была вызвана такая структура. Далее, выслушиваем предложения о рефакторинге со стороны студентов, обсуждаем их преимущества и недостатки. После чего рассматриваем выбранную в реальной жизни SOA арихитектуру для рефакторинга и обсуждаем какие преимущества и недостатки она может привнести в работу с системой.

Модуль 1. «Эволюция сложных программных систем» Практическое задание 3 Разбор кейса «Архитектура сложных систем на примере Amazon» Цель: познакомиться с лучшими практиками и ключевыми моментами в построении крупных Интернет-систем на примере сервисов компании Amazon. Сценарий задания: Рассмартиваеются и обсуждаются ключевые практики, в качестве дополнения к лекции «Современные подходы к разработке архитектуры корпоративного ПО»

Модуль 1. «Эволюция сложных программных систем» Практическое задание 4 Разбор кейса «История эволюции сложных систем на примере LiveJournal» Цель: рассмотреть эволюцию и историю развития крупного Интернет-проекта, также проблемы с которыми сталкивались при его реализации, и ключевые архитектурные подходы. Сценарий задания: Идет послайдовый разбор истории и проблем по презентации из файла «\_sep-sem\usenix.pdf». Всего около 100 слайдов

Экзаменационные задания Модуль 1. «Эволюция сложных программных систем» вариант 1 1. Какие из описываемых ниже характеристик не обязательно относятся к наследуемым системам a) Эксплуатируемую в течение длительного периода b) Эксплуатируемая большим количеством пользователей c) Полезную для бизнес-пользователей d) Разработанную на устаревшем языке программирования 2. Что из перечисленного является недостатком разбиения системы на слои a. Можно выбирать альтернативную реализацию базовых слоев b. Созданный слой может служить основой для нескольких различных слоев более высокого уровня c. Модификация одного слоя часто ведет к внесению каскадных изменений в остальные слои d. Можно выбирать альтернативную реализацию базовых слоев 3. Какой из этапов реинжиниринга ПО необходимо выполнить в последнюю очередь? a. Модернизация ПО b. Внедрение ПО c. Тестирование ПО d. Составление технического задания на модернизацию ПО

Экзаменационные задания Модуль 1. «Эволюция сложных программных систем» вариант 1 (продолжение) 4. Какие работы не включает в себя конфигурационное управление? a. Планирование конфигурационного управления b. Управление выпуском и поставкой c. Обеспечение качества программного обеспечения d. Контроль программных конфигураций 5. Какая из следующих категорий не является категорией сопровождения? a. Корректирующее сопровождение (corrective maintenance) b. Совершенствующее сопровождение (perfective maintenance) c. Творческое сопровождение (creative maintenance) d. Профилактическое сопровождение (preventive maintenance) 6. Какой из уровней ЖЦ является самым широким (включающим все остальные)? a. Цикл разработки программного обеспечения b. Жизненный цикл информационных технологий c. Жизненный цикл организации/бизнеса d. Жизненный цикл программной системы Ответы на экзаменационные вопросы 1 варианта 1. b, 2. c, 3. b, 4. b, 5. c, 6. c

Экзаменационные задания Модуль 1. «Эволюция сложных программных систем» вариант 2 1. Что из описываемого ниже не является частью наследуемых систем a) Прикладные программы b) Аппаратные средства c) База данных d) План разработки 2. Что из перечисленного не является одним из основных слоев архитектуры ПО a) Представление b) Доменная логика c) Программный код d) Источник данных 3. Какая из упомянутых ниже нужд не влечет за собой необходимость рефакторинга? a) Добавить новую функциональность b) Упростить добавление нового кода c) Улучшить проект существующего кода d) Достичь лучшего понимания кода

Экзаменационные задания Модуль 1. «Эволюция сложных программных систем» вариант 2 (продолжение) 4. Какой из следующих элементов не требует конфигурационного управления и контроля? a) Версия программного обеспечения (Software version) b) Программная конфигурация (Software configuration) c) Базовая линия, срез (Baseline) d) Промежуточные файлы компилятора (Object Libraries) 5. Какой из следующих методов оценки стоимости является параметрическим? a) Метод Delphi b) Аналогии c) Структура декомпозиции работ d) Метод функциональных точек 6. Что является отличительной особоенностью модели спирального ЖЦ? a) Раннее тестирование b) Устранение ошибок в реализации по мере тестирования c) Наличие нескольких фаз проекта d) Рассмотрение рисков, влияющих на организацию ЖЦ Ответы на экзаменационные вопросы 2 варианта 1. d, 2. c, 3. a, 4. d, 5. d, 6. d

Экзаменационные задания Модуль 1. «Эволюция сложных программных систем» вариант 3 1. Какая методология использовалась при разработке большинства настоящих наследуемых систем a) Обьектно-ориентированное программирование b) Функционально-ориентированное проектирование c) Сервисно-ориентированная архитектура d) SaaS (Software as a Service) 2. Какой из описанный паттернов является одним из типовых решений для организации бизнес-логики a) Сценарии транзакции (Transaction Script) b) Коллекция объектов (Identity Map) c) Модуль таблицы (Table Module) d) Фиктивная служба (Service Stub) 3. Какой способ проведения рефакторинга кода является наиболее безопасным? a) С предварительным предпросмотром b) С атомарной отменой операции c) Управляемый тестами d) Без использования IDE 4. Что не включает в себя сборка ПО? a) Системную сборку ПО b) Внесение изменений в ПО c) Передачу продукта d) Упаковку ПО

Экзаменационные задания Модуль 1. «Эволюция сложных программных систем» вариант 3 (продолжение) 5. Что не могут измерять метрики по сопровождению ПО? a) Расписание b) Качество c) Усилия d) Удовлетворенность 6. Что из перечисленного относится к основным процессам ЖЦ? a) Документирование – Documentation b) Обеспечение качества – Quality Assurance c) Разработка – Development d) Аудит – Audit Ответы на экзаменационные вопросы 3 варианта 1. b, 2. c, 3. c, 4. b, 5. d, 6. c__

Модуль 1. «Эволюция сложных систем » Приобретаемые компетенции По окончанию изучения модуля слушатели должны знать и уметь: Знать понятие эволюции ПО в контексте бизнес-требований заказчика. Знать об эволюции ПО в терминах жизненного цикла ПО, в том числе конкретных его моделей. Иметь представление о видах эволюции ПО. Знать как осуществляется сопровождение ПО. Уметь осуществлять реинжиниринг ПО с использованием соответствующих методов и инструментов. Знать правила эффективного реинжиниринга.

Содержание модуля 2. «Методы разработки ПО» Виды ПО и методологии его разработки SDLC и унифицированный подход Традиционные и облегченные методологии Agile SP, XP MSF Сравнение этапов жизненного цикла создания ПО в различныхметодологиях (планирование и оценка, управление требованиями,разработка архитектуры, кодирование, тестирование, поставка)

Модуль 2. «Методы разработки ПО» Практическое задание 1 Упражнение «Достижение командной цели» Инструкция тренера Требуется 1 или несколько колод игральных карт. Тренер готовит по 4 карты одного достоинства на человека. Но для каждого 4-го человека – 2 карты одного достоинства, 2 – другого. Например, для 4-х человек нужны 4 «шестерки», 4 «семерки», 4 «восьмерки», 2 «девятки», 2 «десятки». Тренер перемешивает карты и раздает студентам случайным образом. Тренер пишет на доске или слайде задание: Командная цель: 1. У каждого участника на руках 4 карты одного достоинства. 2. Достичь п.1 как можно быстрее. 3. Максимальное время: 15 минут. Тренер записывает на доске время начала выполнения. Правильное достижение цели следующее. Один из студентов собирает карты у всех остальных, сортирует их и раздает каждому по 4 карты одного достоинства. На последнем одном или нескольких студентах он обнаруживает, что цель не достижима на 100%, о чем докладывает тренеру. Время выполнения 1 минута. С большой вероятностью студенты начнут играть по принципу «каждый за себя» - каждый собирает себе 4 карты. Возможно даже, некоторые даже будут играть по принципу «один против всех» - мешать другим собрать 4 карты. Если группа рапортует о готовности, тренер задает вопросы «Кто считает, что цель достигнута?», «Кто считает, что цель не достигнута?». Правильный ответ «Цель достигнута частично, исходная цель недостижима». В остальных случаях тренер просит группу договориться. После завершения упражнения тренер спрашивает студентов, что они делали. Желательно, чтобы 1-2 человека рассказали свою «неправильную» стратегию. После этого тренер спрашивает, был ли способ достичь цель быстрее? В идеале студенты должны догадаться до правильного способа.

Модуль 2. «Методы разработки ПО» Практическое задание 1 (продолжение) Тренер рассказывает, что упражнение является метафорой командного выполнения проектов: 1. Чем больше людей, тем сложней договориться. При увеличении количества людей сложность растет экспоненциально. Для организации взаимодействия необходим менеджер. 2. Не всегда изначально поставленная цель достижима на 100%, поскольку разработка ПО – наукоемкая и исследовательская деятельность. Нужно как можно быстрее понять, в каких аспектах цель недостижима и четко сообщить об этом заказчику. 3. Действует принцип «один за всех, а все за одного». Если на одном из участков произошел сбой, то вся группа не достигла цели. Любая стратегия поведения студента на этом упражнении является метафорой его поведения в проектах, о чем студент должен задуматься. Если в группе найдется сильный менеджер, который организует всех на правильное достижение цели, тренер спрашивает, какие были идеи у других, что бы они делали, если бы не этот менеджер. Далее, как в основном варианте, тренер рассказывает метафору упражнения. Косвенные задачи упражнения: Сплотить тренинговую группу Освоить физическое пространство тренинга Подвигаться и проснуться Общее время на упражнение: 30 минут

Модуль 2. «Методы разработки ПО» Приобретаемые компетенции По окончанию изучения модуля слушатели должны знать и уметь: ­Знать основные принципы унифицированного подхода, экстремального программирования и MSF. Уметь оценивать качество реализации фундаментальных принципов организации производства ПО в том или ином методе разработки. Уметь оценивать пригодность использования того или иного метода разработки на примере конкретных проектов.

Содержание модуля 3. «Архитектуры сложных систем» Введение в архитектуру предприятия Интегрированная концепция архитектуры предприятия Архитектурные домены и абстракции Ведущие методики описания архитектуры предприятия Интеграционные решения уровня предприятия Системная архитектура и архитектура предприятия Разработка архитектуры Внедрение архитектуры Поддержка архитектурных решений Оценка зрелости архитектуры Архитектура предприятия как часть ИТ-стратегии

Модуль 3. «Архитектуры сложных систем» Приобретаемые компетенции По окончанию изучения модуля слушатели должны знать и уметь: Знать о взаимосвязи между бизнес-моделью предприятия и его информационной архитектурой. Знать методики описания архитектур. Знать шаблоны применяемые в процессе разработки архитектур. Уметь анализировать и давать оценку зрелости информационной архитектуры предприятия.

Контроль усвоения материала По завершении усвоения каждого модуля проводятся экзамены с использованием 3-х вариантов вопросов

Методические рекомендации по выполнению практических заданий Практический материал каждого модуля оптимально сочетается с теоретическим, что позволяет слушателям незамедлительно применять полученные знания в своей профессиональной деятельности. Более 50% времени составляют практические занятия. -Задания, рассмотрение кейсов, работа в командах, ролевые игры.

Программа стажировки в России Цель – формирование и закрепление на практике профессиональных знаний, умений и навыков, полученных в результате теоретической и практических занятий, изучение передового опыта, приобретение профессиональных навыков в области управления проектами по разработке программного обеспечения. Место (город) – Казань Место (предприятие) – ОАО «ICL-КПО ВС» Срок – 10 дней

Программа стажировки за рубежом Цель – формирование и закрепление на практике профессиональных знаний, умений и навыков, полученных в результате теоретической и практических занятий, изучение передового опыта, приобретение профессиональных навыков в области управления проектами по разработке программного обеспечения. Задача стажировки: Изучение используемых практик в области управления проектами по созданию ПО в ведущей ИТ компании и проведение сравнительного анализа с теоретическим материалом. Место (города) –Нидерланды, Бельгия, Ирландия, Великобритания. Франция, Германия, Швеция (на выбор) Место (предприятие) – FUJITSU TECHNOLOGY SOLUTIONS (HOLDING) B.V. ФУДЖИЦУ ТЕХНОЛОДЖИ СОЛЮШНЗ (ХОЛДИНГ) Б.В. Штаб квартира и подразделения холдинга. Каждое подразделение холдинга самостоятельное юридическое лицо с отличным от других профессиональным направлением Срок – 12 дней Образовательные результаты - Отчет- реферат.

Контактная информация , г. Казань, ул. Кремлевская, д. 18. Исполнитель: Высшая школа информационных технологий и информационных систем КФУ Тел. (843) Контактное лицо: Максимова Ирина Александровна