Технологии программирования на базе Microsoft Solutions Framework

Бизнес и IT-проекты Рынок ПО в России и в мире Немного статистики

Для того чтобы бизнес был успешным, необходимо (но не достаточно) выполнение многих условий:

Продукт должен выходить на рынок

надлежащего качества;

вовремя;

интересным потенциальным пользователям.

Расходы должны соответствовать изначальному бюджету.

Рис. 1.1.  Статистика успешности IT-проектов. По данным The Standish Group International, Extreme Chaos
К сожалению, ситуация такова, что многие проекты не удовлетворяют этим, казалось бы естественным, условиям. Рассмотрим некоторую статистику (рис. 1.1)1).
Приведем расшифровку степени успешности проектов:

Проваленные: закончились неудачей - цель вообще не была достигнута.

Испытавшие большие проблемы: закончились созданием продукта, но превысили бюджет или (и) не уложились во время или (и) имеют лишь частичную функциональность.

Успешные: закончились созданием продукта, уложились в бюджет и время. Вся планируемая функциональность реализована.

Как видите, доля успешных проектов неуклонно возрастает, оставаясь по-прежнему сенсационно малой. И это притом, что в 2004 году на разработку программных средств ушло около 3 700 000 000$.
Рассмотрим еще один любопытный график:

Рис. 1.2.  Доля успешных проектов в зависимости от их бюджета.
Данная диаграмма2) говорит о том, что с ростом размера проекта (бюджет характеризует в данном случае размер и сложность задачи) шансы на его успех катастрофически падают.
Поговорим о текущем положении отрасли в России. В конце 90-х годов, обсуждая этот вопрос, мы приводили следующие качественные характеристики:

Хорошие программисты.

Грамотные аналитики.

Недостаток хороших управленцев.

Проблемы с документированием и локализацией.

Проблемы с рекламой и продвижением.

Прошло всего 5 лет, и ситуация существенно изменилась к лучшему. Объем экспорта программного обеспечения из России в 2005 г. превысил 1 млрд.$ (для сравнения экспорт в автомобильной отрасли составил 380 млн.$, в атомной энергетике - 850 млн.$). Объем IT-рынка в 2004 г. составил 9,2 млрд.$, в 2005 г. рост составил 22,1% (в то время как мире всего порядка 6%)! Конечно, доля нашего рынка в объемах мирового IT-рынка по-прежнему невелика (объем IT-рынка в мире в 2005 г. составил 900млрд.$), но тенденция выглядит обнадеживающе. При этом объем рынка разработки программного обеспечения в России в 2005г. составил 1,4млрд.$ ( от всего IT-рынка). В среднем этот показатель в России растет на 40-50% в год. 3)
Таким образом, основные тенденции на сегодняшний день представляются следующими:

Быстрый рост объемов IT-рынка, рынка ПО.

Укрепление позиций российских компаний.

По-прежнему малая доля в мировых объемах.

Для того чтобы повысить объемы рынка, необходимо повысить показатель успешности проектов, для чего отрасль нуждается не только в новых технологиях, но и в грамотных специалистах, способных эти технологии применять. Надеемся, что вы пополните эту, без сомнения почетную и востребованную когорту.

IT-проекты

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

Что такое программное обеспечение (ПО)?

Чем ПО отличается от обычной программы?

Вчера мы с другом написали "Калькулятор". Определенно, это программа. Является ли она ПО?

Компонентное программирование

Компонентное программирование - представляет собой развитие объектно-ориентированной технологии. В отличие от ООП введен следующий уровень абстракции - классы объединяются в компоненты.
Компонент:

программный код в виде самостоятельного модуля;

может быть использован в неизменном виде;

может допускать настройку;

обладает поведением (функциональностью).

Основной принцип компонентного программирования: сборка приложения из готовых компонент, в общем случае написанных на разных языках.
Компонент изолирован от внешнего мира своим интерфейсом - набором методов (их сигнатурами). Компонентная программа - набор независимых компонент, связанных друг с другом посредством интерфейсов.

  1)
  Источник: The Standish Group International. Данные взяты с http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html, http://www-128.ibm.com/developerworks/rational/library/feb06/marasco/
  2)
  Источник: The Standish Group International. Данные взяты с http://www.infoworld.com/infoworld/img/33FEmyth2_ch2.gif
  3)
  Источник: Светлана Шляхтина, Компьютер Пресс, 27 января 2006г. Данные взяты с http://www.aplana.ru/news

Модульное программирование

Технология модульного программирования - оформившаяся в начале 70-х годов XX века идея разработки больших программных систем [1.4]. Это фундаментальная концепция, являющаяся основой всех современных подходов к проектированию и реализации. В то же время суть ее проста и отражает широко известные научные и технические методы, заключающиеся в поиске и реализации некоторого базового набора элементов, комбинации которых дают решение всех задач из определенного круга.
Если концепция структурного программирования предлагает некоторый универсальный алгоритмический базис, то модульное программирование состоит в разработке под конкретную задачу или круг задач (предметную область) собственного базиса в виде набора модулей, позволяющего наиболее эффективно по целому ряду критериев построить программный комплекс. Модули, входящие в базис, это целые программы (в отличие от примитивов структурного программирования), решающие некоторые подзадачи основных задач.
С применением модульного программирования появляются возможности коллективной разработки программ как набора "независимых" частей, последовательного уменьшения сложности методом разбиения сложной задачи на более простые подзадачи, наконец, возможности повторного использования созданного ранее кода.

О предмете

Задачи нашего предмета:

Изучить причины неудач IT-проектов.

Выявить способы устранения этих причин.

Научиться применять эти способы на практике.

Объектно-ориентированное программирование

Развитие аппаратной базы привело к возможности решения при ее помощи все более или более сложных задач, а, значит, разработки все более и более сложных программ. Программы стали большими (даже очень большими), а разработка - коллективной. Объем работы увеличился, коллективы разрослись, код "разбух", и появились новые проблемы, которых не было раньше. Неожиданно выяснилось, что возможности структурного и модульного программирования ограничены и зачастую уже не позволяют добиваться желаемого результата (либо ничего не работает, либо проект не укладывается в сроки, либо в бюджет, либо через год после написания программы выясняется, что ее невозможно модифицировать и т.д.).
Объектно-ориентированная технология в некоторой степени решила большинство описанных проблем. В отличие от рассмотренных ранее технологий, объектно-ориентированная технология работает на стадиях анализа, проектирования и программирования. В основе технологии лежат объектная модель и объектная декомпозиция [1.3].
К основным принципам объектной модели часто относят следующие:

абстракция;

инкапсуляция;

иерархия (наследование, агрегация);

полиморфизм;

модульность.

Суть объектной декомпозиции состоит в выделении в предметной области классов и объектов, а также связей между ними, и лишь потом данных и алгоритмов, которыми характеризуется каждый класс. Таким образом, именно классы становятся основным "строительным блоком" в ООП, тогда как ранее таковыми блоками являлись алгоритмы.

Причины неудачи IT-проектов

Почему IT-проекты терпят неудачи?
Почему, казалось бы, хорошо спланированный проект не укладывается во временные рамки?
Почему по прошествии некоторого времени выясняется, что имеющегося бюджета недостаточно?
Почему полученный в итоге продукт не пользуется спросом?
Проблема сложна и многогранна. Трудно перечислить все возможные причины неудачи. Остановимся кратко на некоторых из них, представляющихся нам наиболее существенными.
Причина 1. Нереалистичные временные рамки.
Правильно оценить время, необходимое для выполнения проекта, - сложная задача, решение которой часто не под силу даже опытным менеджерам. Существуют специальные критерии, которые помогают принимать правильные решения, такие как учет времени в человеко-часах и т.д. Тем не менее, задача остается сложной, колоссальное значение в ней имеет грамотный учет рисков (далее мы поговорим про это подробнее).
Причина 2. Недостаток количества исполнителей.
Иногда менеджер решает сэкономить, иногда переоценивает возможности своих сотрудников, иногда в ходе разработки выясняется, что задача сложнее, чем казалось на самом деле, - проблема недостатка рабочих рук, так или иначе, возникает достаточно часто.
Причина 3. Размытые границы проекта.
Одна из наиболее серьезных причин неудачи проекта - нечетко сформулированные цели, неоднократно меняющиеся в ходе разработки. Поверьте, многоэтажные дома и дачные домики строятся на основе применения разных технологий и материалов. Если вам доведется управлять проектом - сделайте все, чтобы четко сформулировать требования к системе в соответствии с пожеланиями пользователя. Мы поговорим про это подробнее в подразделе "Управление требованиями".
Причина 4. Недостаток средств.
Известны две крайности при планировании бюджета: чрезмерное раздувание (подход пессимиста) и чрезмерное уменьшение (подход оптимиста). Использование первого подхода чаще всего (если только ваш заказчик не совсем дилетант) приводит к тому, что ваша команда теряет проект. "Слишком дорого, сэр. Мы идем к Вашим конкурентам".
Второй подход часто применяется не только в силу оптимизма менеджмента, но и в рекламных целях, чтобы любой ценой выиграть проект. "Мы сейчас напишем меньше всех, а там видно будет". Увы, в дальнейшем приходится расплачиваться за демпинговые меры. Качественно реализовать проект за выделенные деньги оказывается просто невозможным. Представляется разумным оценивать бюджет реально с некоторой перестраховкой на случай непредвиденных ситуаций (заболел ключевой сотрудник, вышло из строя дорогостоящее оборудование...). Не выиграем этот проект - выиграем другой. Хуже, если выиграем, но провалим. В нашу состоятельность больше могут и не поверить.

Причина 5. Нехватка квалифицированных кадров.

Нехватка квалифицированных специалистов - одна из существенных проблем отрасли. Технологии развиваются с такой скоростью, что профессионалы вынуждены все время обновлять свои знания. Относительная новизна самой области IT, с одной стороны, становящееся повсеместным внедрение информационных технологий во все сферы человеческой деятельности, с другой, а, значит, все возрастающий спрос на специалистов ведут к существенной нехватке квалифицированных кадров. Конечно, все хотят принять на работу лучших. Но опыт показывает, что их не так много, и на всех не хватает. Умение из потока кандидатов выбрать тех, кто вам нужен, очень важное качество специалистов по кадрам. Часто к подбору сотрудников рекомендуют привлекать всех членов команды. То, как новичок впишется в коллектив, совсем не последнее дело.

Программирование

На протяжении всего времени обучения на факультете мы изучаем программирование. Программирование (Computer science) - молодая, активно развивающаяся область.
Долгое время человечество волнует вопрос о том, к какому роду деятельности относится программирование. В 60-х - 70-х годах XX века данный вопрос активно обсуждался на научных конференциях. Существовало 2 популярных точки зрения: "программирование это искусство" и "программирование это наука". К единому мнению придти так и не удалось. В настоящий момент мы можем добавить к этим популярным трактовкам еще одну: "программирование это бизнес". Чтобы понять, что программирование это бизнес, достаточно посмотреть, какими числами выражаются доходы современных IT-компаний. Так, например, по данным www.microsoft.com доход корпорации Microsoft за 2005 финансовый год составил 39,70 млрд. $. Впечатлены? Вам нравится этот бизнес? Тогда приступим к изучению курса.

Программы и программное обеспечение (программные продукты)

Программное обеспечение (Software) - набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207).
Таким образом, программное обеспечение - это не просто программа. Это еще и документация и руководство пользователя.
Вместо словосочетания "программное обеспечение" часто используют другое - "программный продукт". Будем далее считать, что это одно и то же. Одно из главных свойств программного продукта - продаваемость. Продаваемость - залог успеха бизнеса по разработке программного обеспечения. Если вы собираетесь что-то разработать, это должно быть востребовано на рынке. В противном случае вы потратите деньги на разработку (зарплата сотрудников, накладные расходы, налоги, аренда помещения...) и ничего не получите взамен. Вы можете написать замечательную программу. Реализовать там новый быстрый алгоритм. Она может великолепно работать, но если она никому не нужна, то вы (как компания) на пути банкротству. Допустим, в таких программах, как ваша, действительно есть потребность. Допустим, вы год упорно работали, и вот, казалось бы, настал ваш звездный час: все готово, все модули написаны, отлажены, собраны вместе и, как вам кажется, работают. Один "маленький" момент портит всю картину - если у
вас нет хорошего (!) руководства пользователя (инструкции), желательно, в русскоязычном и англоязычном вариантах, то вашу программу никто не купит, особенно за границей. Если у вас все есть, но нет специалистов по рекламе, то про вашу программу никто не узнает. Если ...
Подытожим: программный продукт - это программа со всей сопутствующей документацией, программа, которую можно продать, либо извлечь из нею финансовую выгоду другим образом.
Вернитесь мысленно к пункту 1.2 и еще раз попробуйте ответить на поставленные вопросы. Получилось? Тогда перейдем к краткому обзору текущего состояния дел в отрасли разработки ПО в России и в мире.

Структурное программирование

Возникновение концепции структурного программирования [1.4, 1.5, 1.6] связывается с именем известного голландского ученого Э. Дейкстры - в 60-х годах прошлого века он сформулировал основные ее положения.
Принцип, на котором зиждется технология структурного программирования - фундаментальная научная и техническая идея о выделении множества базисных элементов, с помощью которых можно выразить (из которых можно собрать) любой объект из некоторого широкого набора.
Итак, основной принцип технологии структурного программирования гласит: для любой простой программы можно построить функционально эквивалентную ей структурную программу, т.е. программу, сформированную на основе фиксированного базисного множества, включающего структуру последовательного действия, структуру выбора одного из двух действий и структуру цикла, то есть многократного повторения некоторого действия с проверкой условия остановки повторения.

Рис. 1.3.  Блок-схемы базисных алгоритмических конструкций
На рисунке 1.3 представлено изображение указанных алгоритмических конструкций в виде блок-схем. Здесь прямоугольник обозначает обобщенное действие, ромб - проверку условия, стрелки - переход от одного действия к другому.
Под простой программой в данном случае понимается программа, имеющая ровно один вход и один выход по управлению, такая, что через все ее функциональные блоки проходит путь от входа до выхода.
Изложенный принцип представляет собой теорему о структурировании. Ее точная формулировка и доказательство не входят в нашу задачу, желающие могут обратиться к монографии [1.6].
Базисные алгоритмические конструкции обладают важным свойством - они в точности удовлетворяют определению простой программы, то есть имеют один вход и один выход, что обеспечивает возможность осуществлять их суперпозицию. Любая из трех структур может быть подставлена в остальные или в саму себя.
Таким образом, центральный технологический принцип структурного программирования состоит в том, что формулировку алгоритма и его запись в виде программы рекомендуется выполнять на основе базиса из трех алгоритмических конструкций, применяя при необходимости их суперпозицию. Результатом последовательного применения этого принципа будет более ясная структура программы (в особенности, если использовать выделение структурных уровней с помощью отступов), что, несомненно, облегчит поиск в ней ошибок и упростит ее модификацию.

Технологии программирования - путь к успеху в разработке ПО

Технология - совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства [1.1].
Уже в 60-х-70-х годах XX людям было ясно, что ввиду роста сложности решаемых при помощи компьютера задач неимоверно возрастает стоимость разработки программ. Причем, если стоимость аппаратуры растет умеренными темпами, а иногда и вовсе падает, то со стоимостью разработки программ ничего поделать не удается. Именно тогда вопрос о том, как оптимизировать процесс разработки, вышел на первый план.
Для того чтобы ответить на этот вопрос, потребовалось определить, куда уходят средства, за счет чего возрастает стоимость разработки программных систем?
Создание любой программной системы выполняется по некоторой схеме. Данная схема представляет собой последовательность стандартных этапов (очень приблизительно эта схема может выглядеть так: анализ, проектирование, разработка, тестирование, модификация). Именно на этих этапах и возникают существенные финансовые затраты. Для их оптимизации необходимо было понять, что программирование есть обычный технологический процесс, по характеру возникающих проблем мало чем отличающийся от, скажем, строительства дома или корабля.
Для сокращения затрат необходимо было конкретизировать схему, упорядочить действия, выполняемые на каждом этапе, разработать методы решения возникающих на разных этапах проблем. В довершении ко всему, схема подразумевает возвраты назад (циклы), в тех случаях, когда обнаруживается ошибка предыдущего этапа.
В результате кропотливой работы большого количества специалистов на каждом этапе и подэтапе возникли и продолжают появляться и совершенствоваться специальные технологии, позволяющие решать задачи в заданные сроки с заданным качеством.
Итак, технология программирования - совокупность методов, приемов и средств для сокращения стоимости и повышения качества разработки программных систем.
В любой серьезной компании, занимающейся разработкой программного обеспечения, на каждом этапе процесса разработки применяется большое количество разных технологий. Над созданием программного продукта работают представители таких специальностей как: аналитики, управленцы (менеджеры), тестеры, кодировщики, (программисты), технические писатели, системные администраторы, специалисты по повторному использованию, дизайнеры, специалисты по эргономике и др. Сейчас мы вспомним то, что вам должно быть известно из курса "Основы программирования", - ту часть технологий, которая наиболее устоялась и имеет отношение к общим вопросам анализа, проектирования и разработки: структурное, модульное, объектно-ориентированное и компонентное программирование.

Цели программных инженеров

Целями программных инженеров являются:

Создать качественный продукт.

Уложиться в бюджет.

Уложиться в сроки.

Разберем по очереди эти вопросы.

Инженеры и программные инженеры

Говоря о программной инженерии, необходимо выяснить, кто такие инженеры.
За ответом обратимся к Большой Советской Энциклопедии:
Инженер (франц. ingenieur, от лат. ingenium - способность, изобретательность), специалист с высшим техническим образованием. Первоначально - название лиц, управлявших военными машинами [2.5].
Понятие гражданский инженер появилось в 16 в. в Голландии применительно к строителям мостов и дорог, затем в Англии и др. странах. Первые учебные заведения для подготовки инженеров были созданы в 17 в. в Дании, в 18 в. - в Великобритании, Франции, Германии, Австрии и др. В России первая инженерная школа основана Петром I в 1712 в Москве. В Петербурге были открыты Горное училище, приравненное к академиям (1773), Институт инженеров путей сообщения (1809), Училище гражданских инженеров (1832, с 1882 - Институт гражданских инженеров), Инженерная академия (1855). С 19 в. за рубежом стали различать инженеров-практиков, или профессиональных инженеров (по существу специалистов, имевших квалификацию техника), и дипломированных инженеров, получивших высшее техническое образование (Civil Engineer) [2.5].
Итак, инженер - дипломированный специалист, имеющий высшее техническое образование. Нетрудно догадаться, что программный инженер - инженер в области разработки программного обеспечения.

Источник материала

При написании данной лекции активно использовались материалы Иана Соммервилля (Ian Sommerville) - одного из наиболее уважаемых авторов в данной области.
Источник (на английском языке):

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6

Ian Sommerville. Software Engineering. 6th Edition

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7

Ian Sommerville. Software Engineering. 7th Edition.

Источник (на русском языке):

Иан Соммервиль. Инженерия программного обеспечения. 6 изд, и.д. "Вильямс", 2002.

Итерационный подход

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

Эволюционная модель (Evolutionary development)

Суть эволюционной модели состоит в том, что многие стадии повторяются неоднократно. Так, после анализа требований производится разработка некоторого прототипа, удовлетворяющего этим требованиям. После этого прототип может быть показан пользователям. Далее - уточнение требований и вновь проектирование, реализация, отладка и тестирование. В результате нескольких повторений этого процесса на выходе получается продукт, удовлетворяющий пожеланиям пользователей. Заметим, что вместе с продуктом развивается и документация к нему.
Недостатки эволюционного подхода в плохой структурированности системы, отсутствия внятного подробного проекта на начальных этапах, необходимости в средствах быстрой разработки. Соответственно, подход хорошо подходит для малых и средних проектов.

Качественный программный продукт

Должен предоставлять требуемую функциональность.
Если вы создали продукт, который не нужен конечным пользователям, вы не сможете его продать и не только не получите прибыль, но и не окупите затраты на его создание.

Должен быть удобным в сопровождении.
ПО должно допускать развитие в связи с изменением потребностей пользователей. Если Вы начинаете разрабатывать программный продукт, обязательно учитывайте, что мир не стоит на месте. Допустим, вы автоматизируете крупное предприятие, ориентируясь на его конкретную структуру. Подумайте над таким вопросом: какие изменения и как вы будете вносить в программную систему в том случае, если на предприятии добавится пара новых подразделений? Ваш проект должен быть достаточно гибким, чтобы поддерживать его расширение без ущерба для реализованной ранее части. Поймите, что клиент будет готов оплатить модификацию, но не создание программы с нуля.

Должен быть надежным.
Возможные неполадки в работе не должны нанести существенный, тем более невосполнимый, ущерб. Если ваша программа рассчитывает орбиту полета спутника, вам придется потратить уйму времени на то, чтобы убедиться, что она работает правильно.

Должен быть эффективным.
ПО должно эффективно использовать имеющиеся ресурсы. Вряд ли клиент согласится полностью поменять свою аппаратную базу без должного обоснования. Вот в этот момент и придется задуматься об алгоритмической оптимизации, оптимизации кода…

Должен быть удобным в использовании.
ПО должно приниматься пользователями "на ура", работа должна быть удобной и естественной. Помните, что персонал, которому предстоит работать с программой, скорее всего не придет в восторг от ее появления. Постарайтесь сделать процесс обучения как можно более простым.

Каскадная модель (Waterfall model)

Суть каскадной модели состоит в следующем:

Требования к системе определяются на начальном этапе и далее не меняются.

Процесс создания ПО разбивается на следующие стандартные этапы: определение требований, проектирование, кодирование и тестирование модулей, интеграция и тестирование продукта, эксплуатация и сопровождение.

Каждый этап может начаться лишь тогда, когда закончился предыдущий.

Достоинства каскадной модели в простоте и хорошей структурированности. Основные недостатки связаны с прямолинейностью и отсутствием гибкости. Дело в том, что неизменность требований является мифом. Требования менялись, меняются и будут меняться всегда в ходе разработки. Каскадная модель не учитывает этот факт. В итоге, если ничего не предпринимать, конечный продукт будет отличаться от потребностей пользователей. Более того, скорее всего и документация в конце не будет отражать реальной ситуации (например, ТЗ, составленное в начале не будет совпадать с тем, что получится в конце). Поэтому каскадная модель в чистом виде перспективна лишь для очень больших проектов, где хорошая структурированность выходит на первые роли, а также в тех случаях, когда требования хорошо осознаны и зафиксированы в самом начале.

Модель пошаговой разработки

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

Модели процесса

Итак, некий "каркас" процесса обычно выглядит так:

Спецификация.

Разработка.

Аттестация.

Модернизация.

Сам этот "каркас" можно приводить в жизнь по-разному. Существуют общие модели процесса, которые определяют, как организовать работу по "каркасу" на практике. Фактически, модель процесса - некое абстрактное представление процесса на верхнем уровне. Так, модель не рассматривает детально содержимое каждого из этапов. Модель рассматривает состав этапов и способы их претворения в жизнь.
Рассмотрим некоторые устоявшиеся модели процесса разработки программного обеспечения.

Область действия программной инженерии

Программная инженерия имеет дело со всеми аспектами создания ПО.
В западной литературе часто используются термины: software engineering, system engineering и computer science. В чем разница?
Computer science имеет дело с теорией и основами разработки ПО.
System engineering связано с вопросами разработки систем с участием компьютеров (архитектура, дизайн, интеграция, ПО...).
Software engineering - часть System engineering, имеющая дело с разработкой ПО.
Итак, computer science предоставляет собой безусловно важный, но преимущественно теоретический базис. На практике его недостаточно. К числу открытых можно отнести следующие проблемы:

Поиск финансирования.

Работа с заказчиком.

Подбор персонала.

Этические вопросы. Микроклимат в коллективе. Команда.

Обеспечение качества программного продукта.

...

Всем этим занимается программная инженерия и программные инженеры.

Понятие процесса

Процесс создания программного обеспечения - совокупность мероприятий, целью которых является создание или модернизация программного обеспечения [2.1, 2.2, 2.3].
Выделяют 4 основных мероприятия (стадии) процесса:
Спецификация: формулирование спецификаций определяет основные требования к ПО (что должна делать система).
Разработка: создание ПО в соответствии со спецификациями.
Аттестация: проверка ПО на соответствие потребностям заказчика.
Модернизация: развитие ПО в соответствии с изменившимися потребностями заказчика.


Все стадии основаны на специальных технологиях. Например, рассмотренные кратко в предыдущей лекции модульное, структурное, объектно-ориентированное, компонентное программирование относятся к стадии Разработки.
Каждая организация может организовать процесс создания программного обеспечения так, как ей это представляется разумным. Этот процесс может иметь разную степень формализации. Так, создание продукта может идти по принципу "вечером обсудили и договорились", но этот принцип работает только для команд из 2-3 человек в достаточно простых проектах. Возможна другая крайность - каждое действие жестко определено и прописано в описании процесса. В этом случае возникает необходимость длительного предварительного обучения сотрудников работе в рамках этого, безусловно, сложного описания. Подобный подход, конечно, порождает и другие накладные расходы. Например, то, что вполне могло бы быть решено в частной беседе, теперь приходится долго и нудно "проводить" через соответствующий формализм. Пожалуй, такая степень формализации может пойти на пользу для очень больших, тем более распределенных, коллективов, решающих задачи большой сложности. Для небольшого или среднего проекта описанная степень формали зации принесет больше вреда, чем пользы (хорошая аналогия - забивание гвоздей микроскопом).
Несмотря на естественные отличия в описаниях процессов, как правило, в нем присутствуют рассмотренные стадии. Они могут иначе называться, детализироваться, но от них никуда не уйти.
Существуют известные, хорошо проработанные процессы: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и другие.
Эти процессы (ко второму в большей степени применим термин методология) имеют свои разновидности и могут применяться как для малых и средних компаний и проектов, так и для больших.

Процесс создания программного обеспечения

Сразу оговоримся, что по данному разделу написано немало литературы. Существуют многостраничные книги, ГОСТ-ы, стандарты... На сегодняшний день мы можем смело утверждать, что при некотором общем теоретическом (философском) и практическом понимании того, что происходит в отрасли, и что нужно делать для лучшей организации при создании программного обеспечения, терминология в данной области абсолютно не устоялась. Мы в данном курсе ориентируемся на вариант И. Соммервилля. При этом рекомендуем ознакомиться и с другими книгами и материалами. Каждая новая книга предложит вам новую терминологию. Не пугайтесь этого. Пройдет время, и терминология устоится. Общий смысл изложения во многих книгах по программной инженерии совпадает.

Программная инженерия как инженерная дисциплина

Теперь попробуем ответить на вопрос, что такое программная инженерия.
Программная инженерия (инженерия программного обеспечения, software engineering) - инженерная дисциплина, связанная с теорией, методами и средствами профессиональной разработки ПО [2.1, 2.2, 2.3].
Как было выяснено ранее, программное обеспечение представляет собой собственно программы плюс вся сопутствующая документация. На протяжении последних десятилетий стоимость разработки ПО неуклонно растет, в результате чего эта стоимость становится весьма высокой. Программная инженерия способствует решению этой проблемы.

Программные инженеры и научная среда

Взаимодействие с научной средой - один из способов повышения эффективности деятельности. Возможная выгода от сотрудничества с учеными:

Новые технологии.

Новые методы, алгоритмы.

Анализ новых перспективных разработок.

Исследовательская работа в смежных областях.

Помощь ученых жизненно необходима в по крайней мере в двух ситуациях:

Там, где в принципе не решить задачу своими силами.

Там, где есть специалисты, но нет времени и ресурсов для исследований.

Этот подход широко применяется современными IT-компаниями: Intel, Microsoft, IBM и другими.

Создание ПО должно укладываться в бюджет

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

60% - разработка;

40% - тестирование.

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

Создание ПО должно укладываться в сроки

Залог успеха - строгое соблюдение следующих принципов:

Грамотное планирование.

Анализ возможных рисков и способы реагирования.

Борьба за четкие границы проекта.

Мотивирование сотрудников.

Спиральная модель разработки

Спиральная модель (Боэм) оказалась чрезвычайно популярной. Суть ее состоит в том, что вместо действий с обратной связью происходит выполнение различных этапов по спирали. Каждый виток спирали соответствует 1 итерации. Заранее фиксированных фаз нет, их состав зависит от потребностей.
Каждый виток разбит на 4 сектора: определение целей, оценка и разрешение рисков, планирование, разработка и тестирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
Главное отличие от других моделей состоит в акценте на анализ и преодоление рисков (об этом мы еще будем говорить более подробно в 3 разделе нашего курса).

Вспоминая предыдущую лекцию

Наша предыдущая лекция целиком была посвящена знакомству с терминологией и введению в предмет. Сформулируем кратко некоторые выводы:

Программирование (Computer science) - молодая, активно развивающаяся область, за полвека своего развития преодолевшая огромный путь. Будучи как искусством, так и наукой, в наше время термин программирование приобрел качественно новую окраску, став одной из отраслей бизнеса.

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

Программное обеспечение (Software) - набор компьютерных программ, процедур и связанной с ними документации и данных. Таким образом, программное обеспечение - это не просто программа. Это еще и документация и руководство пользователя. Вместо термина программное обеспечение часто используют термин программный продукт.

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

Анализ рынка ПО в мире показывает большие темпы роста. В отрасль вкладываются огромные деньги. В России в отрасли IT наблюдается бум. Отрадный факт - укрепление Российских IT-компаний.

Основными причинами неудачи IT-проектов являются:
Причина 1. Нереалистичные временные рамки.
Причина 2. Недостаток количества исполнителей.
Причина 3. Размытые границы проекта.
Причина 4. Недостаток средств.
Причина 5. Нехватка квалифицированных кадров.

Технологии программирования - путь к успеху в разработке ПО. Использование различных технологий позволяет преодолевать сложность решаемых задач и, соответственно, сложность создания качественного ПО. Среди основных технологий можно выделить следующие: структурное программирование, модульное программирование, объектно-ориентированное программирование, компонентное программирование.

Актеры и варианты использования в UML

Программная система не функционирует сама по себе. Программная система функционирует под воздействием актеров (Actor) - пользователей, машин и других программ. При этом актер ожидает, что система ведет себя строго определенным образом. Актер оказывает воздействие - система выдает ожидаемый результат. В случае, если ожидаемого результата нет, требования пользователя не удовлетворены со всеми вытекающими отсюда результатами. Таким образом, актер в UML - человек, машина или программа, воздействует на систему, является внешним по отношению к ней. Модель того, как воздействие приводит к результату, называется Вариантом использования (Use case). Актеры и варианты использования имеют специальные обозначения в UML:

Рис. 3.5. 
Актеры и варианты использования общаются посредством посылки сообщений. Сообщения могут идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и может быть опущена.

Рис. 3.6. 
Выделим актеров и варианты использования в рассмотренном ранее примере с системой бронирования билетов (SRS). Анализ постановки задачи показывает наличие у системы двух актеров: "Пользователь" и "Администратор". Определимся с вариантами использования. Необходимо отметить, что выбор актеров и вариантов использования до некоторой степени условен и может отличаться у разных специалистов по анализу и проектированию. Принятые проектные решения определяют дальнейший выбор архитектуры системы и существенно влияют на успех всего процесса разработки. При этом "хороших" вариантов может быть несколько.
Перечень Вариантов использования для нашей задачи может быть, например, таким:

Забронировать билет.

Подобрать рейс.

Работать с данными.

Управлять рейсами.

Работать с БД аэропорта.

Для визуального представления актеров, вариантов использования и отношений между ними в UML предусмотрена специальная диаграмма - диаграмма вариантов использования. Ниже приведена диаграмма для рассматриваемого примера:

Рис. 3.7. 
Приведем некоторые дополнительные соображения [3.3]:

При таком моделировании обращают внимание на поведение системы, а не на ее реализацию.

Хорошая модель описывает основное поведение системы, не являясь слишком подробным.

Подобная модель позволяет проверить, удовлетворит ли система требования заказчика.

Система средних размеров может быть описана большим количеством вариантов использования.

Варианты использования могут описываться разными сценариями.

На последнем пункте остановимся подробнее. Очевидно, название варианта использования не дает полного представления о том, как он претворяется в жизнь. Для описания сценария работы варианта использования UML содержит специальные средства. Основное из них - диаграмма действия.

Диаграмма действия это блок-схема, которая отображает динамику в поведении системы. Заметим, что эта диаграмма может использоваться не только для описания сценариев Варианта использования.

Приведем пример соответствующей диаграммы для варианта использования Бронирование билетов в системе SRS.


Рис. 3.8. 

Алгоритмическая и объектная декомпозиции Классы и объекты

Принципиально можно выделить 2 вида разбиения предметной области на составляющие элементы:

Алгоритмическая декомпозиция (основные элементы программы - строительные блоки - алгоритмы).

Объектная декомпозиция (основные элементы программы - виды абстракций (классы) и представители этих классов (объекты)).

В соответствии с алгоритмической декомпозицией предметной области мы при анализе задачи пытаемся понять, какие алгоритмы необходимо разработать для ее решения, каковы спецификации этих алгоритмов (вход, выход), и как эти алгоритмы связаны друг с другом. В языках программирования данный подход в полной мере поддерживается средствами модульного программирования (библиотеки, модули, подпрограммы).
В рамках объектной декомпозиции мы пытаемся выделить основные содержательные элементы задачи, разбить их на типы (классы). Далее для каждого класса абстракций мы определяем его свойства (данные) и поведение (операции), а также, как эти классы абстракций взаимодействуют друг с другом.
На сегодняшний день объектный подход и его основы - объектная модель и объектная декомпозиция - поддерживаются современными объектно-ориентированными языками программирования (Object Pascal, C++, Java, C#…).

Анализ и проектирование Некоторые частные вопросы

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

Рис. 3.1. 
Или в укрупненном виде:

Рис. 3.2. 
3-я часть и элементы 2-ой части этой цепочки изучаются в курсе "Методы программирования".
1-я и 2-я части составляют объект изучения отдельного курса "Анализ и проектирование".
В настоящий момент в анализе и проектировании преобладает объектный подход (изучен в 1-2 семестрах).
Вспомним суть объектного подхода.

Анализ постановки - полное описание

Задача является математической. Система должна уметь решать однокритериальную задачу поиска кратчайших путей на графах. Критерий - цена.

Система распределенная: так как в каждом аэропорте своя база направлений полетов самолетов, то знают о рейсе только аэропорты-соседи по рейсам.

Объекты системы: распределенное хранилище рейсов, покупатель билетов, менеджер рейсов.

Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.

Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.

Среди причин:

Отсутствие рейсов в желаемом направлении даже с учетом пересадок.

Нехватка денег.

В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.
Менеджер рейсов: должен иметь следующие возможности:

создания и удаления аэропортов в системе.

создания и удаления рейсов в аэропортах.

Ассоциация

Ассоциация - связь между сущностями (классами, объектами). Ассоциация показывает наличие структурной связи между экземплярами (объектами). Структурная связь реализуется через поле класса. В обозначениях UML направление может быть не указано (двусторонняя связь).

Рис. 3.18. 

Частные случаи ассоциаций: агрегация и композиция

Агрегация предполагает, что 0 или более объектов одного типа включены в 1 или более объектов другого типа.
Композиция - вариант агрегации, в котором каждый объект второго типа может быть включен ровно в 1 объект первого типа.

Рис. 3.21. 

Диаграммы UML

Диаграммы UML предназначены для визуального отображения моделей и их компонентов.
UML 2.0 содержит 13 типов диаграмм. В том числе:

Структурные диаграммы (6).

Диаграммы поведения (3).

Диаграммы взаимодействия (4).

Рассмотрим каждую из групп подробнее:
Структурные диаграммы:

Диаграмма классов - показывает классы, их атрибуты и связи между классами.

Диаграмма компонентов - показывает компоненты и связи между ними.

Структурная диаграмма - показывает внутреннюю структуру классов и связи с внешним миром.

Диаграмма развертывания - показывает, как ПО размещается на аппаратуре (серверах, рабочих станциях...).

Диаграмма объектов - показывает структуру системы в конкретный момент времени, объекты, их атрибуты...

Диаграмма пакетов - показывает, как система раскладывается на крупные составные части и связи между этими частями

Диаграммы поведения:

Диаграмма действия - показывает потоки информации в системе.

Диаграмма состояния - представляет собой конечный автомат, показывающий функционирование системы.

Диаграмма вариантов использования - показывает работу системы с точки зрения пользователей.

Диаграммы взаимодействия

Диаграмма кооперации - показывает структурную организацию участвующих во взаимодействии объектов.

Диаграмма взаимодействия (новация UML 2.0).

Диаграмма последовательности - показывает временную упорядоченность событий.

Временная диаграмма - диаграмма связана с временными рамками проекта.

Достоинства повторного использования Виды повторного использования

Достоинства повторного использования (по Соммервилю, [3.1]):

Повышение надежности.

Уменьшение проектных рисков.

Эффективное использование специалистов.

Соблюдение стандартов (пример: пользовательский интерфейс).

Ускорение разработки.

Повторное использование достигается за счет следующих приемов (видов использования):

Компонентная разработка. Часть компонентов уже разработаны ранее, имеют четко описанный интерфейс. Они используются в качестве "кирпичиков" в новой системе.

Использование паттернов (шаблонов) проектирования. Применяются известные подходы к решению некоторых встречавшихся ранее проблем.

Использование стандартных прикладных (MKL, MFC…) и системных (API) библиотек.

По материалам www.wikipedia.org, www.uml.org

Закрыть окно

Идея повторного использования Важность повторного использования

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

Идея визуального моделирования

Вспомним, в чем состоит основная проблема в разработке ПО? Проекты не укладываются в сроки, бюджет, не удовлетворяют требованиям.
Как решать эту проблему? На помощь приходит моделирование. Под моделью обычно понимают упрощенное представление объектов и явлений реального мира.
Ответим на вопрос, зачем строят модели? Модели строят для того, чтобы лучше понять исследуемую систему.
Классики проклассифицировали задачи и принципы моделирования. Приведем здесь эту, несомненно, важную, классификацию.
Задачи моделирования [3.3]:

Визуализация системы в ее некотором состоянии.

Определение структуры и поведения системы.

Получение шаблона для создания системы.

Документирование принятых решений.

Принципы моделирования [3.3]:

Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.

Каждая модель может быть воплощена с разной степенью абстракции.

Лучшие модели - те, что ближе к реальности.

Наилучший подход при разработке сложной системы - использовать несколько почти независимых моделей.

Как уже упоминалось ранее, одним из наиболее популярных подходов к моделированию является объектный подход. В соответствии с этим подходом в результате OOA и OOD мы получаем "хороший" проект программной системы, прозрачный, удовлетворяющий требованиям, удобный для тестирования и отладки, коллективной разработки, развиваемый, допускающий повторное использование компонентов.
К сожалению, даже использование таких мощных средств, как объектный подход, не гарантирует нам успех. К сожалению, в больших проектах сложность моделируемого объекта (и, соответственно, сложность проекта) такова, что проект слишком велик для адекватного восприятия одним человеком, по крайней мере, в уме.
Это и означает необходимость визуального моделирования.
Идея визуального моделирования состоит в графическом отображении обсуждаемых и принимаемых проектных решений. При этом достигаются следующие цели:

Визуализация упрощает понимание проекта в целом.

Визуализация помогает согласовать терминологию и убедиться, что все одинаково понимают термины.

Визуализация делает обсуждение конструктивным и понятным.

Для визуального моделирования нужна специальная нотация или язык.
UML (unified modeling language) - это язык для визуализации, специфицирования, конструирования, документирования элементов программных систем [3.3]. UML - язык общего назначения, предназначенный для объектного моделирования.

Интерфейсы

Определимся с тем, что мы в данном случае понимаем под Интерфейсом.
Интерфейс определяет границу между спецификацией того, что делает абстракция, и реализацией того, как она это делает [3.3].
Интерфейс - это набор операций, используемых для специфицирования услуг, предоставляемых классом или компонентом [3.3].
Смысл использования Интерфейса состоит в отделении деталей реализации от функциональности. Так, класс, подсистема, компонент обычно предоставляют некоторую функциональность, которой могут пользоваться другие классы, подсистемы, компоненты. Описание этой, доступной извне, функциональности содержится в Интерфейсе.
Во многих языках программирования понятие Интерфейс включено в объектную модель, что сообразно отражается на синтаксисе (Object Pascal, Java и др.). С++, к сожалению, не содержит понятия Интерфейс, поэтому Интерфейсы моделируются посредством использования классов.

увеличить изображение
Рис. 3.12. 

История языка UML

Рассмотрим кратко историю языка UML1). К 1994 году существовало несколько нотаций для визуального отображения принимаемых проектных решений и несколько методов анализа и проектирования. В 1994 году состоялось знаковое событие - Grady Booch и James Rumbaugh, сотрудники фирмы Rational Software, объединили свои методы проектирования и анализа, создав так называемый Unified method. С этого момента процесс стандартизации договоренностей вошел в рабочий ритм. Приведем важные вехи этого пути:

1994: Grady Booch & James Rumbaugh (Rational Software) объединили методы Booch (проектирование) и OMT (анализ) ->Unified method.

1995: присоединился Ivar Jacobson (автор метода OOSE). Впоследствии группа авторов Booch, Rumbaugh и Jacobson вместе выпустила не одну книгу, ставшую бестселлером (например, см. список литературы). Эту троицу шутливо называли "three amigos", намекая на то, как жарко они спорили по поводу принимаемых решений.

1996 - Идея о Unified Modeling Language (three amigos).

1996 - создан консорциум UML Partners под руководством three amigos.

Июнь, Октябрь 1996 - UML 0.9 & UML 0.91.

Январь 1997 - спецификации UML 1.0 предложены OMG (Object Management Group).

Август 1997 - спецификации UML 1.1 предложены OMG.

Ноябрь 1997 - UML 1.2 - результат адаптации OMG.

Июнь 1999 - UML 1.3.

Сентябрь 2001 - UML 1.4.

Март 2003 - UML 1.5.

Принятый стандарт:

ISO/IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.

Октябрь 2004 - UML 2.0.

Классы

Рис. 3.9. 
Обозначения модификаторов доступа:
#protected-private

+	public

UML предусматривает возможность написания комментариев

UML предусматривает возможность написания комментариев (заметок). Делается это следующим образом:

Рис. 3.16. 

Компоненты

Компонент - физическая заменяемая часть системы, совместимая с одним набором интерфейсов и обеспечивающая реализацию какого-либо другого [3.3]. Компонент может разрабатываться и тестироваться независимо от системы.
Виды компонентов:

Исходные файлы (.cpp, .h, .java…).

Бинарные файлы (.dll, .ocx…).

Исполняемые файлы (.exe).

По смыслу компонент представляет собой реализацию подсистемы. На этапе проектирования мы работаем с подсистемами. На этапе реализации - с компонентами.

Рис. 3.15. 

Краткое описание

На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.
При формулировании требований менеджеры упомянули, что рейсы спланированы так, что до пункта назначения можно долететь с пересадками. Одно из требований заключалось в том, чтобы система помогала покупать билеты в зависимости от пожеланий пользователя.

Кратность

Кратность - способ конкретизации характера отношения. Показывает тип отношения 1:1, 1:M, N:1, N:M.

Рис. 3.20. 

Вид кратности	Значение
* или 0..*	?0
1..*	?1
	обычно 0 или 1
1	Ровно 1
3,5..6	{3,5,6}

Модели UML

UML позволяет описывать систему следующими моделями:

Модель функционирования (показывает, как описывается функциональность системы с точки зрения пользователя).

Объектная модель (показывает, как выглядит проект системы с точки зрения объектного подхода).

Динамическая модель (показывает, как взаимодействуют друг с другом компоненты системы в динамике, с течением времени). Демонстрирует, какие процессы происходят в системе.

Направление и навигация

Заметим, что наличие направления связано с понятием Навигация. Навигация означает, что в направлении стрелки один объект "видит" другой, в то время как обратное не выполняется.

Рис. 3.19. 

Отношения между элементами модели

UML поддерживает следующие виды отношений между элементами модели:

Зависимость.

Ассоциация.

Обобщение (наследование).

Реализация (для Интерфейса).

Отношения показывают наличие связей между элементами модели и семантику этих связей.
Рассмотрим каждый из этих типов отношений.

Пакеты

Пакет - структурная единица для группировки элементов модели, в частности, классов.
Пакет - это способ организации элементов модели в более крупные блоки, которыми впоследствии позволяется манипулировать как единым целым. Хорошо спроектированный пакет группирует семантически близкие элементы, которые имеют тенденцию изменяться совместно [3.3].

Рис. 3.13. 

Подсистемы

На этапе проектирования системы классы и пакеты могут объединяться в подсистемы. Подсистема - структурная единица. Каждая подсистема имеют свою область ответственности и реализует некоторую функциональность. Подсистема реализует Интерфейс, который описывает ее поведение. В рассматриваемом учебном примере SRS примерами подсистем являются: подсистема бронирования билетов; подсистема доступа к данным...

Рис. 3.14. 

Понятия UML

Для описания структуры: Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет.
Для описания поведения: Действие, Событие, Сообщение, Метод, Операция, Состояние, Вариант использования.
Для описания связей: Агрегация, Ассоциация, Композиция, Зависимость, Наследование.
Некоторые другие понятия: Стереотип, Множественность, Роль.

ООП и структуры хранения Стек

Постановка задачи:
Необходимо разработать структуру хранения Стек.
Примечания:

Не учитывать необходимость перераспределения памяти.

Считать, что элементы целого типа.

Анализ и проектирование.
Данные:

MemSize - максимальное количество элементов.

DataCount - количество элементов в стеке.

pMem - указатель на память для хранения значений.

Операции:

IsFull - проверка на полноту.

IsEmpty - проверка на пустоту.

Get - взять элемент с вершины.

Put - положить элемент в стек.

Рис. 3.3. 
Рассмотрим финальный результат нашего проектирования (используется нотация UML):

Рис. 3.4. 

Принципы объектного подхода

Рассмотрим наиболее важные принципы объектного подхода.
Абстрагирование применяется при решении многих задач. Любая построенная нами модель позволяет абстрагироваться от реального объекта, подменяя его изучение исследованием формальной модели. Абстрагирование в ООП позволяет выделить основные элементы предметной области, обладающие одинаковой структурой и поведением. Такое разбиение на классы позволяет существенно облегчить анализ и проектирование системы.
Инкапсуляция - важнейший элемент объектного подхода. Суть его заключается в скрытии деталей внутренней реализации. Инкапсуляция оказывает положительное влияние на защиту данных и существенно повышает шансы безболезненной замены одной из частей системы ее новой версией при условии сохранения интерфейса.
Иерархия помогает разбить задачу на уровни и постепенно ее решать, постепенно увеличивая детализацию рассмотрения. Иерархия упорядочивает абстракции. К счастью, разные иерархии можно обнаружить практически в любой системе. Агрегация и наследование - примеры таких иерархий. Они подчеркивают тот факт, что новые абстракции могут быть созданы на основе уже имеющихся.
Полиморфизм позволяет иметь естественные имена и выполнять действия, релевантные ситуации, разбираясь на этапе работы программы, какой из методов необходимо вызвать. Полиморфизм неразрывно связан с наследованием и поздним связыванием.

Составные части объектного подхода

Как было сказано ранее, основами объектного подхода являются объектная модель и объектная декомпозиция. Рассмотрим кратко составные части объектного подхода, грамотное выполнение которых, как правило, приводит к созданию качественного программного продукта.
Объектный подход:

OOA (object oriented analysis) - объектно-ориентированный анализ.

OOD (object oriented design) - объектно-ориентированное проектирование.

OOP (object oriented programming) - объектно-ориентированное программирование.

Рассмотрим кратко эти ключевые понятия (определения Г. Буча):
Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области [3.2].
Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы [3.2].
Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования [3.2].
В русскоязычной литературе, как правило, под аббревиатурой ООП рассматривают все 3 составляющих объектного подхода. Далее и мы будем следовать этому принципу.
Курсы из цикла "Методы программирования" и, конкретнее, "Объектно-ориентированное программирование" преимущественно концентрируются на OOP. Данный курс, по крайней мере, его теоретическая часть основное внимание уделяет OOA и OOD.

Структура системы и ее описание средствами UML

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

Вместо введения

При изучении материалов по визуальному моделированию и языку UML в качестве основного источника рекомендуется классическая книга [3.3]:
Г. Буч, Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя. - ДМК-Пресс, Питер, 2004.
Дополнительно рекомендуется следующая книга: G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004.
Большое количество материалов может быть найдено на сайте www.uml.org.

Вспоминая предыдущую лекцию

Наша предыдущая лекция целиком была посвящена введению в программную инженерию. При этом мы охватили следующие темы:
Программная инженерия, основные понятия

Инженеры и программные инженеры

Программная инженерия как инженерная дисциплина

Область действия программной инженерии

Цели программных инженеров

Программные инженеры и научная среда

Процесс создания ПО

Понятие процесса. Основные фазы.

Модель процесса. Каскадная и эволюционная модель.

Итерационный подход. Модель пошаговой разработки и спиральная модель.

Зависимость

Зависимость - связь между сущностями (классами, объектами). Зависимость показывает, что изменения в одной сущности могут повлиять на другую сущность. Зависимость - не структурная связь. Возникает через локальную, глобальную переменные или параметр метода.

Рис. 3.17. 

Архитектура продукта

Ролевая группа выполняет следующие задачи:

формулирует спецификацию решения и разрабатывает его архитектуру;

определяет структуру развертывания (внедрения) решения.

Что такое методология?

"Толковый словарь русского языка" С.И. Ожегова определяет понятие "Методология" как "Принципы и способы организации теоретической и практической деятельности. Совокупность методов, применяемых в какой-либо науке" [4.12].
Применительно к разработке программного обеспечения это определение можно переформулировать так: "Методология есть принципы и способы организации деятельности проектной группы для создания программного продукта".
Разберем формулировку на элементы, начиная с конца.
Во-первых, "программный продукт". С этим понятием мы познакомились еще на первой лекции. Именно продукт является конечной целью в любой методологии. Отметим также, что в последнее время вместо термина "программный продукт" все чаще используют термин "решение" ("solution"), а компании-разработчики вместо фразы "мы поставляем программные продукты" все чаще говорят "мы поставляем (готовые) решения".
Во-вторых, "проектная группа". Синонимами, которые и мы нередко будем использовать, являются "команда разработчиков" или просто "команда". В любом случае за этим скрывается коллектив людей, непосредственно занятых созданием "готового решения". Именно люди являются точкой приложения любой методологии, поскольку, как уже сказано, в организации деятельности людей и состоит основное назначение методологий.
Таким образом, в оставшейся части курса речь пойдет о "святой троице": проектная группа, программный продукт, методология.

произошло разделение методологии на

Важное нововведение состоит в том, что в MSF 4. 0 произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.

Все оставшееся время в течение курса мы будем работать в рамках первого направления. Что касается второго, то он предлагает в существенной степени формализованный подход к процессу разработки, чем-то сближающийся с RUP. В частности, помогает организациям работать на третьем уровне модели CMMI (Capability Maturity Model Integration4)). Если говорить кратко, MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д.

Формирование команды Модель проектной группы MSF for Agile Software Development

В этом разделе6) мы рассмотрим, наверное, самую главную из отличительных черт MSF в сравнении с другими методологиями - модель проектной группы и принципы, положенные в основу построения команды.

в отличие от предыдущих редакций

У MSF 4.0 в отличие от предыдущих редакций появилась инструментальная поддержка в среде разработки Microsoft Visual Studio 2005 Team System. Фактически среда Visual Studio 2005 может выступать теперь в качестве интегрирующего средства, из которого можно работать со всеми инструментами, обеспечивающими стадии процесса разработки от создания планов проекта до проведения различных видов тестирования, включая создание и выполнение тестовых сценариев.

Источники информации

Источники, в которых можно почерпнуть информацию о методологии MSF, можно разделить на три типа:
Основным источником, безусловно, являются белые книги (в настоящий момент доступные для версии MSF 3.0).
Немало сведений можно найти на сайте компании Microsoft, включая разделы портала TechNet (http://www.microsoft.com/rus/technet/default.mspx).
Кроме того, желающие могут прослушать курсы, связанные с MSF (например, [4.4, 4.5]).
Наконец, информация по последней версии MSF 4.0 может быть получена на http://msdn.microsoft.com/vstudio/teamsystem/msf.

К сожалению, с источниками информации по MSF 4.0 дела обстоят несколько хуже, чем по третьей версии. Наиболее полную информацию на данный момент можно получить на http://www.microsoft.com/msf.

Историческая справка

В 1993 году, стремясь достичь максимальной отдачи от IT-проектов, компания Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. 2) Эти знания базировались на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на тот момент IT индустрия.
Вторая версия методологии датируется 1998 годом. Версия MSF 3.0 была представлена в 2001 году, а последняя - MSF 4.0 в 2005.

представляет собой эволюционное развитие предыдущей

MSF 4.03) представляет собой эволюционное развитие предыдущей версии методологии. Тем не менее, изменений внесено довольно много. В этом разделе мы обсудим основные.

Прежде всего, в новой редакции методологии делается упор на то, что MSF - это не просто набор рекомендаций, MSF - это образ мыслей (mindsets![4.15]


Рис. 4.1.  "Образ мыслей" MSF 4.0. Источник: MSF for Agile Software Development Process Guidance

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

Основные концепции методологии MSF

Теперь перейдем непосредственно к Microsoft Solutions Framework (MSF).1)
Приближение первое. MSF - методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения. Взглянув на список программ, которые установлены на типовом персональном компьютере, нетрудно прийти к мысли, что практики, которые использовала Microsoft в своей работе, имеют под собой довольно весомые основания в виде множества выпущенных продуктов самой различной сложности, начиная от редактора Notepad и заканчивая операционными системами семейства Windows. В силу сказанного MSF не есть чисто теоретический взгляд на процесс разработки, напротив, методология предлагает не только концепции и модели, но и сугубо практические приемы и советы.
Приближение второе. MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых "белых книгах" ("whitepapers"), каждый из которых охватывает определенную дисциплину или модель MSF:

Модель процессов MSF

Модель проектной группы MSF

Дисциплина управления проектами MSF

Дисциплина управления рисками MSF

Дисциплина управления подготовкой MSF

Модель проектной группы мы подробно обсудим далее в этой лекции, модели процессов посвятим половину следующей. Что касается дисциплин, то мы потратим некоторое время на знакомство с управлением рисками и весьма детально изучим управление проектами. Управление подготовкой останется за рамками нашего курса (интересующихся отсылаем к соответствующей белой книге, доступной, например, на http://www.microsoft.com/rus/msdn/msf/default.mspx).
Приближение третье. MSF предлагает несколько оригинальных идей, с которыми мы подробно будем знакомиться далее, а пока просто перечислим их:

Единое видение проекта

Треугольник и матрица компромиссов

"Проектная группа - команда равных"

Управление рисками

…

В качестве комментария. Конечно, MSF не единственная методология разработки программных продуктов. Широко известна, например, технология Rational Unified Process (RUP) (см., например, http://ru.wikipedia.org/wiki/RUP), имеющая инструментальную поддержку в виде различных программных систем, наиболее известная из которых - Rational Rose (http://www-306.ibm.com/software/rational/) и предлагающая весьма сильно формализованный подход к процессу разработки. До версии 3.0 включительно MSF существенно отличалась от RUP - во-первых, намного меньшей формализованностью, во-вторых, не просто отсутствием инструментов, а скорее отсутствием необходимости в таких инструментах. Идеология MSF предполагала, что концепции, которые MSF предлагает разработчикам, могут и должны быть адаптированы к требованиям конкретного проекта. В последней версии (4.0) идеология MSF претерпела некоторые изменения, но об этом дальше.

Основные положения MSF for Agile Software Development

MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. Одним из примеров подобных методологий является Extreme Programming (XP5)).
Agile направление в MSF ориентируется на небольшие команды (5-6 человек), предполагает, что информация о разрабатываемом продукте не просто выясняется в процесе разработки, а может и будет изменяться по ходу. Таким образом, первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.
Методология MSF содержит весьма много элементов, в частности:

рекомендованные процессы создания IT-проектов;

структуру итераций;

роли членов команды;

шаблоны документов (Excel, Word);

шаблоны Microsoft Project;

отчеты;

портал проекта (шаблон сайта SharePoint).

MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях использования.

Основные принципы построения команды

Методология MSF считает, что успешная работа команды над проектом существенным образом зависит от ее структуры и распределения зон ответственности ролевых групп (более подробно о составе проектной группы далее) внутри команды. Построение команды в MSF соответствует ряду ключевых концепций (key concepts), часть которых кажутся самоочевидными, другие чем-то сродни "ноу-хау".
К самоочевидным можно отнести:

Концентрация на нуждах заказчика (customer-focused mindset) - главный приоритет любой хорошо работающей проектной группы. Означает обязательное понимание бизнес-задач заказчика и стремление к их решению со стороны команды. Не менее важным является активное участие заказчика в проектировании решения и получение его отзывов в ходе процесса разработки.

Нацеленность на конечный результат (product mindset) - каждый участник проектной группы должен рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. Установка на конечный продукт означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. Из этого не следует, что сам процесс может быть плох или непродуман - просто он существует для получения конечной цели, а не ради себя самого.

Установка на отсутствие дефектов (zero-defect mindset) - это стремление к высочайшему уровню качества. Она означает, что цель команды - выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. В успешной команде каждый сотрудник чувствует ответственность за качество продукта. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой.

Концепции, которые в определенном смысле можно отнести к "ноу-хау" методологии MSF:

"Проектная группа - команда равных" (teem of peers). Концепция означает равноправное положение каждой из ролей в команде. Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи.
В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.

Стремление к самосовершенствованию (willingness to learn) - это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.

К концепции команды равных в MSF тесно примыкает идея о том, что каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны (более подробно об этом далее).

Модель проектной группы в MSF может масштабироваться в зависимости от числа участников.

Разработка

Ролевая группа выполняет следующие задачи:

определяет детали физического дизайна;

оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;

разрабатывает или контролирует разработку элементов;

подготавливает продукт к внедрению;

консультирует команду по технологическим вопросам.

Рекомендации по возможному объединению ролей

Модель проектной группы в MSF может масштабироваться в зависимости от числа участников. Масштабирование модели проектной группы MSF for Agile Software Development на случай больших команд выходит за рамки нашего курса. Мы рассмотрим ситуацию, когда один человек может выполнять в проектной группе несколько ролей (небольшая команда, относительно несложный проект).
В этом случае MSF предлагает рекомендации по возможному объединению ролей. Рассмотрим их в виде таблицы.
Архитектура продуктаУправление продуктомУправление программойРазработкаТестированиеУдовлетворение потребителяУправление выпускомАрхитектура продуктаУправление продуктомУправление программойРазработкаТестированиеУдовлетворение потребителяУправление выпуском

Нет	Да	Да	Не желательно	Не желательно	Не желательно
Нет	Нет	Нет	Да	Да	Не желательно
Да	Нет	Нет	Не желательно	Не желательно	Да
Да	Нет	Нет	Нет	Нет	Нет
Не желательно	Да	Не желательно	Нет	Да	Да
Не желательно	Да	Не желательно	Нет	Да	Не желательно
Не желательно	Не желательно	Да	Нет	Да	Не желательно

Ролевые группы и роли

Методология MSF основана на постулате о качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждая из ее ролевых групп, определяемых моделью, ассоциирована с одной из целей и работает над ее достижением.
MSF for Agile Software Development выделяет 7 ролевых групп [4.15]:

Управление программой (program management)

Архитектура продукта (architecture)

Разработка (development)

Тестирование (test)

Управление выпуском (release operations)

Удовлетворение потребителя (user experience)

Управление продуктом (product management)

Рис. 5.2.  Модель команды в MSF 4.0 - ролевые группы. Источник: MSF for Agile Software Development Process Guidance
и 6 ролей [4.15]:

менеджер проекта (project manager) - ролевая группа Управление программой

архитектор (archrect) - ролевая группа Архитектура

разработчик (developer) - ролевая группа Разработка

тестер (tester) - ролевая группа Тестирование

релиз-менеджер (release manager) - ролевая группа Управление выпуском

бизнес-аналитик (business analyst) - ролевые группы Управление продуктом и Удовлетворение потребителя

Рис. 4.3.  Модель команды в MSF 4.0 - роли. Источник: MSF for Agile Software Development Process Guidance

Тестирование

Ролевая группа выполняет следующие задачи:

обеспечивает обнаружение всех дефектов;

разрабатывает стратегию и планы тестирования;

осуществляет тестирование.

Учебный пример Формирование команды

Применим полученные знания к сформулированному на предыдущей лекции учебному примеру "Система бронирования билетов для авиакомпании".
Пусть проектная группа состоит из 6 человек. Представим возможное распределение ролей, позволяющее выполнить поставленную в учебном примере задачу.
Несмотря на то, что модель проектной группы MSF выделяет ровно 6 ролей, идею о том, чтобы каждому участнику нашей команды выдать по одной роли и на этом успокоиться, следует оставить, как в корне неверную. При таком подходе, мы должны будем взвалить тяжесть разработки системы на одного человека, что, конечно же, не приведет к успеху. Отсюда очевидно, что разработчиков должно быть больше одного, а остальные роли придется совмещать. Как именно, сейчас обсудим.
Во-первых, следуя рекомендациям MSF по объединению ролей, дадим одному из разработчиков еще и роль архитектора.
Во-вторых, отбросим в сторону другую крайность - разработчиками не могут быть все. Отдельный участник команды должен заниматься тестированием. Ему же можно выдать "в нагрузку" роль бизнес-аналитика.
Незадействованными остались ролевые группы "Управление программой" и "Управление выпуском". Соответственно роли менеджер проекта и релиз-менеджер достаются еще одному участнику.
В итоге получаем следующее (возможное) распределение:

Участник 1 - менеджер проекта и релиз-менеджер

Участник 2 - архитектор и разработчик

Участник 3 - бизнес-аналитик и тестер

Участник 4 - разработчик

Участник 5 - разработчик

Участник 6 - разработчик

Удовлетворение потребителя

Ролевая группа выполняет следующие задачи:

представляет интересы потребителя в команде;

организует работу с требованиями пользователя;

определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;

определяет требования к системе помощи и её содержание;

разрабатывает учебные материалы и осуществляет обучение пользователей.

Управление продуктом

Ролевая группа выполняет следующие задачи:

выступает в роли представителя заказчика;

организует работу с требованиями заказчика;

формирует ожидания заказчика;

формирует общее видение и рамки проекта;

определяет компромиссы между параметрами "возможности продукта / время / ресурсы";

организует маркетинг;

разрабатывает, поддерживает и исполняет план коммуникаций.

Управление программой

Ролевая группа выполняет следующие задачи:

управляет процессом разработки с целью получения готового продукта в отведенные сроки;

регулирует взаимоотношения и коммуникацию внутри проектной группы;

следит за временным графиком проекта и готовит отчетность о его состоянии;

разрабатывает, поддерживает и исполняет сводный план и календарный график проекта;

организует управление рисками.

Управление выпуском

Ролевая группа выполняет следующие задачи:

представляет интересы отделов поставки и обслуживания продукта;

организует снабжение проектной группы;

организует внедрение продукта;

вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;

организует сопровождение и инфраструктуру поставки.

Вспоминая предыдущую лекцию

Наша предыдущая лекция была посвящена визуальному моделированию в процессе анализа и проектирования и основам языка UML.
При этом сначала в качестве введения мы кратко повторили:

типовую схему решения задач с использованием вычислительной техники;

основные положения алгоритмической и объектной декомпозиции;

принципы объектного подхода к анализу и проектированию.

Далее мы обсудили, чем вызвана необходимость в визуальном моделировании программных систем и рассмотрели историю языка UML.
Затем была рассмотрена структура и основные понятия UML, представлена постановка учебной задачи, на которой далее будет иллюстрироваться изучаемый материал на протяжении всего курса ("Система бронирования билетов для авиакомпании").
Наконец, мы подробно осветили средства UML для:

визуального описания функциональной модели: актеры, варианты использования, диаграммы вариантов использования, диаграммы действия;

описания структуры системы: классы, объекты и интерфейсы; пакеты, подсистемы и компоненты;

описания отношений между элементами модели: зависимость, ассоциация, обобщение, реализация.

Задачи ролевых групп и взаимодействие с заинтересованными лицами

Для каждой ролевой группы, помимо зоны ответственности, определены заинтересованные стороны, как внутри, так и вне команды, с которыми группа должна взаимодействовать и чьи интересы представлять/отстаивать при принятии решений.

Зоны ответственности ролевых групп

Каждая ролевая группа в команде имеет зону ответственности (advocacy), в которой роль из этой группы имеет решающий голос.

Управление программой - отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.

Архитектура продукта - отвечает за систему в целом, вырабатывает архитектуру решения, включая сервисы, технологии и стандарты, которые будут использованы в ходе работы над решением.

Разработка - отвечает за проектирование и осуществление реализации.

Тестирование - отвечает за качество решения с точки зрения заказчика и будущих пользователей.

Управление выпуском - отвечает за гладкое внедрение решения в инфраструктуру заказчика.

Удовлетворение потребителя - отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении.

Управление продуктом - представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика (успешное получение бизнес-отдачи от внедрения разрабатываемого решения, которое в результате сможет получить заказчик).

Будьте готовы к внедрению сегодня

Работа проектной группы в идеале должна быть построена так, чтобы при возникновении такой потребности у заказчика текущее состояние разрабатываемого решения могло быть немедленно внедрено (естественно с той функциональностью, которая в данный момент реализована). Это означает, что итерации работы над проектом должны быть максимально короткими, и в каждый момент времени должна существовать текущая работоспособная версия решения. Такой подход дает возможность раннего обнаружения рисков, ошибок, пропущенных или недопонятых требований, дает возможность своевременно получать обратную реакцию от заказчика, а, значит, сокращает затраты.

Цикличность процесса разработки

На каждом уровне процесса создания решения MSF предполагает цикличность. Создание версии продукта - цикл из итераций. Итерация - цикл из ежедневно собираемых билдов. Билд - цикл изменений, вносимых в систему контроля версий[5.11].

Рис. 5.6.  Циклы процесса разработки. Источник: MSF for Agile Software Development Process Guidance

Фазы и вехи процесса разработки

Модель MSF покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Весь процесс создания решения разбит на пять фаз. Каждая из них заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды [5.1].

Рис. 5.7.  Фазы и вехи модели процессов MSF. Источник: белая книга
Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых групп.
В рамках фазы обычно присутствуют промежуточные вехи, обозначающие достигнутые промежуточные результаты. MSF дает определенные рекомендации (будут рассмотрены при изучении соответствующих фаз) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вех.

Матрица компромиссов проекта

Другое полезное средство управления проектными компромиссами - матрица компромиссов проекта (project tradeoff matrix).
Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях.
Возможный вариант такой матрицы представлен на рисунке.

Рис. 5.4.  Матрица компромиссов (возможный вариант). Источник: белая книга
Матрица компромиссов [4.1] помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка "Фиксируется"), фактор, являющийся в проекте приоритетным (колонка "Согласовывается"), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка "Принимается").

Модель процессов MSF for Agile Software Development

Модель процессов MSF2) представляет общую методологию разработки и внедрения IT- решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).

Рис. 5.2.  Модели процесса (слева направо): каскадная, спиральная, MSF. Источник: белая книга
Процесс MSF ориентирован на "вехи" (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата.
Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду.

Основные сведения о рисках

Прежде всего, определим, что такое "риск". Заглянем в "Толковый словарь русского языка" С.И. Ожегова. "Риск - 1. Возможность опасности, неудачи. 2. Действие наудачу в надежде на счастливый исход" [12]. Отметим, что понятие "риск" включает в себя два по сути противоположных толкования: одно со знаком минус, второе со знаком плюс.
Риск проекта (project risk) понимается в MSF именно в таком полном виде - как всякое событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта. Такое же расширенное понимание спекулятивного риска (speculative risk) присутствует, например, в финансовой индустрии, где решения в условиях неопределенности могут привести к получению прибыли точно так же, как и к убыткам. Указанное понимание противоположно понятию чистого риска (pure risk) в индустрии страхования, где неопределенности связываются только лишь с потенциальными убытками в будущем.
Важно отметить, что риски не есть проблемы. Проблемы - это нечто, имеющие место в настоящее время, в то время как риски относятся к будущему и носят вероятностный характер (могут и не состояться). Однако риски могут стать проблемами, если ими эффективно не управлять.
Цель управления рисками - максимизировать их положительное влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы (убытки).
Дисциплина управления рисками в MSF основана на убеждении, что такое управление должно выполняться превентивно; это часть формального и систематического процесса, трактующего усилия, затрачиваемые на управление рисками, с позитивной точки зрения.
Говоря о рисках, MSF выделяет несколько ключевых концепций:

Риск - неотъемлемая часть всякого проекта или процесса. Несмотря на то, что различные проекты могут быть связаны с большим или меньшим числом рисков, не существует ни одного проекта, полностью свободного от них. Цель состоит не в том, чтобы избежать рисков, а в том, чтобы предвосхищать потенциальные проблемы и заблаговременно готовиться к их решению, если они возникнут.

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

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

О положении дел в проекте нужно судить не по количеству рисков, связанных с его выполнением, а по степени проработанности процедуры их выявления, анализа и управления ими.

Планирование управления рисками

Во время проектных фаз выработки концепции и планирования (изучению этих фаз будет посвящена лекция 7) проектная группа должна разработать формальный документ, описывающий управление рисками в проекте. В этом документе должны быть даны ответы на целый ряд вопросов, из которых здесь мы рассмотрим основные.

Как будет реализовываться процесс управления рисками? Из каких шагов состоит этот процесс?

Кто будет осуществлять действия по управлению рисками? Какие для этого требуются навыки/квалификация? Требуется ли дополнительное обучение?

Как будут строиться планы управления рисками и планы мероприятий по смягчению возможных негативных последствий?

Как деятельность по управлению рисками будет интегрирована в общий план проекта?

Какие действия будут предпринимать отдельные члены проектной группы для управления рисками?

Какие ресурсы доступны для управления рисками?

Каковы временные ограничения в мероприятиях, связанных с управлением рисками?

Часть вопросов, которые также должны быть учтены, мы сознательно опустили - интересующихся отсылаем к соответствующей белой книге [5.2].
Поскольку риски являются неотъемлемой частью всех фаз всех проектов от начала и до конца, должны быть изначально выделены и должным образом распределены ресурсы, необходимые для эффективного управления рисками. Планирование управления рисками осуществляется проектной группой во время фаз выработки концепции и планирования, и результирующий план управления рисками должен определять конкретные действия, ответственность за которые возложена на определенных членов проектной группы. Эти задачи должны быть интегрированы в сводный план проекта (master project plan) и в сводный календарный график проекта (master project schedule).

Поощряйте свободный обмен информацией в проекте

Модель процессов MSF считает очень важным открытый обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат, но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. Естественно речь здесь не идет об информации финансовой или имеющей статус коммерческой или иной тайны.

Процесс управления рисками

Дисциплина управления рисками MSF отстаивает превентивное управление рисками, непрерывную оценку имеющихся рисков и интеграцию этих процессов в общую деятельность по принятию решений на протяжении всего жизненного цикла проекта или бизнес-процесса.
Процесс управления рисками MSF определяет шесть логических шагов, посредством которых проектная группа управляет текущими рисками, разрабатывает и исполняет стратегии управления рисками и извлекает уроки из своего опыта для использования на уровне всего предприятия.[5.2]

Рис. 5.1.  Процесс управления рисками MSF. Источник: белая книга
Выявление рисков (risk identification) - этап, позволяющий членам проектной группы вынести на обсуждение всей команды факты наличия рисков. Выявление рисков является начальной стадией процесса управления ими. Оно должно быть осуществлено как можно раньше, и к нему необходимо постоянно возвращаться на протяжении всего жизненного цикла проекта.
Анализ рисков (risk analysis) - этап преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритезация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы.
Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом.
Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график.
Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки.
Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта.
Необходимо отметить, что описанные этапы являются логическими шагами и не обязательно должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги выявления-анализа-планирования по мере обнаружения дополнительных факторов, влияющих на проект.

Проявляйте гибкость - будьте готовы к изменениям

MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности. Проектная группа должна быть готова к переменам, и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.

Схема процесса разработки

Модели процессов описывают последовательность действий, осуществляемых в ходе реализации проекта. Можно сказать, что они задают тем самым жизненный цикл проекта. Спектр моделей, применяемых в настоящее время различными организациями, весьма широк. Среди них есть и модель процессов MSF, возникшая на основе используемого в компании Microsoft подхода к разработке программных приложений. В результате своего развития она объединила ряд наиболее эффективных принципов других известных моделей процессов, сформировав при этом единую базу для работы над проектами любых типов: ориентированных на фазы (phase-based), основанных на вехах/контрольных точках (milestone-driven) и итеративных (iterative).

Следите за качеством продукта

MSF настаивает на том, что каждый участник проектной группы должен ощущать ответственность за качество разрабатываемого решения. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой. Несмотря на наличие в команде ролевых групп "Удовлетворение потребителя" и "Тестирование", прямая задача которых - следить за качеством решения и повышать его, все остальные ролевые группы также постоянно должны иметь в виду нужды конечного пользователя.

Создавайте "единое видение проекта"

Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения (shared vision), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта. Изначально понимание того, что должно быть достигнуто в ходе работы над проектом, у заказчика может (и нередко) не совпадать с пониманием проектной группы. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели.
Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу (фаза "Выработка концепции"), которая заканчивается соответствующей вехой.

Ставьте "вехи"

Каждая итерация, каждая фаза процесса создания решения должна заканчиваться некоторым зримым результатом, некоторой вехой (milestone). Наличие вех позволяет проектной группе и заказчику видеть движение проекта вперед.

Структурные единицы схемы

MSF for Agile Software Development поддерживает быструю итеративную разработку. Проектирование, разработка, тестирование выполняются в перекрывающих друг друга итерациях, каждая из которых фокусируется на реализации отдельных аспектов решения [5.11].

Рис. 5.5.  Итерации процесса разработки. Источник: MSF for Agile Software Development Process Guidance
Короткие итерации позволяют свести к минимуму влияние ошибок в понимании и формулировании требований, дают быструю обратную реакцию о точности проектных планов.
Каждая итерация должна завершаться получением результата в виде стабильной части целого продукта.

Треугольник компромиссов

Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник компромиссов (tradeoff triangle) [5.1].

Рис. 5.3.  Треугольник компромиссов. Источник: белая книга
После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Нахождение верного баланса между ресурсами, временем разработки и возможностями - ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.

Учебный пример Выделение рисков

Вернемся к учебному примеру "Система бронирования билетов для авиакомпании".
Выделим некоторые возможные риски.
Наименование рискаКомментарий

1	Не успеем сдать проект во время	Из-за неправильной организации работ затратим больше времени, чем заявлено в контракте
2	Не хватит квалификации персонала	При создании продукта используется новая технология (JNL), персонал с ней не работал и может не разобраться
3	Один из членов команды заболеет	Команда не многочисленна и отсутствие одного из членов команды ведет задержке в работах
4	Заказчик изменит требования	В данный момент требования согласованы с заказчиком и утверждены, но в процессе работы заказчик может захотеть добавить в решение новую функциональность
5	Авария на подстанции, отключение электричества	Потеряем время, пока авария будет устраняться
6	Отключат доступ к Интернету	Ухудшится возможность быстрого получения необходимых сведений, пропадет электронная почта и другие средства коммуникации
7	Заказчик вовремя не оплатит счета	Задержка в покупке необходимого оборудования
8	Из-за необнаруженной вовремя ошибки система нанесет урон заказчику	На время устранения ошибки пассажиры не смогут заказывать билеты через систему. Потребуется "ручная" работа персонала. Компания потеряет возможных клиентов и часть прибыли
9	На стороне заказчика нет заявленной в требованиях аппаратуры	Не сможем адекватно развернуть систему
10	Не сможем подобрать необходимые кадры	Придется совмещать роли

Мы выделили не так уж и много рисков, однако можно заметить, что они происходят из самых разных областей и связаны с людьми (риск №3), с процессами (риски №1, №8, №10), с технологиями (риск №2), с внешними условиями (риски №5, №6), с заказчиком (риски №4, №7, №9). Помимо представленных риски могут иметь и другие источники.
Далее MSF рекомендует для каждого риска представить формулировку - выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта и потенциально возможным, еще не случившимся событием или ситуацией.
Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать.

В качестве примера представим формулировки некоторых выявленных выше рисков.

ПервопричинаУсловиеПоследствиеПриносимый ущерб

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

Управление компромиссами

В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade-offs).

Управление рисками как составная часть жизненного цикла проекта

Процесс управления рисками в MSF тесно интегрирован с общим жизненным циклом проекта. Оценка рисков может быть начата даже на этапе выработки концепций, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и рамок. По результатам анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план.
В ходе выполнения проекта команда постоянно проводит мониторинг рисков, осуществляет необходимые корректирующие действия в соответствии с расписанием и планом проекта, и при наступлении связанных с триггерами рисков событий.
Действия по выявлению и анализу новых рисков могут проводиться по достижении вех (milestones) проекта (подробнее о вехах далее в этой лекции). Также в этот момент можно резюмировать извлеченные уроки.
По ходу проекта тип рисков, которым уделяется внимание, также должен изменяться. На ранних этапах доминируют риски связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. С течением времени начинают играть важную роль технологические риски, связанные с реализацией проекта. Затем внимание переходит к рискам поддержки и сопровождения. Для организации деятельности по выявлению рисков в моменты основных фазовых переходов полезно использовать контрольные перечни (checklists) и классификации рисков.

Управление рисками в MSF for Agile Software Development

Дисциплина управления рисками MSF1) возводит процесс управления рисками в ранг стратегической задачи, затрагивающей все фазы проекта. В рамках MSF управление рисками - это процесс выявления, анализа и превентивной работы над рисками в целях избежания их превращения в проблемы, приносящие ущерб или иной вред.
В ходе всего проекта команда должна уделять внимание дисциплине управления рисками. Основные ее характеристики:

она всеобъемлюща и принимает во внимание все составляющие проекта: людей, бизнес-процессы, технологические элементы и т.д.;

она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта;

ее использование непрерывно на протяжении всего жизненного цикла проекта;

она превентивна и не исходит из идеологии действия по факту случившегося.

она вовлекает всю проектную группу в непрерывное извлечение уроков из полученного опыта.

Вспоминая предыдущую лекцию

Наша предыдущая лекция была посвящена введению в методологию Microsoft Solutions Framework. Мы обсудили, что такое методология вообще. Поговорили о том, чем является и чем не является MSF. В чем она схожа с другими методологиями и чем отличается от них. Перечислили и кратко охарактеризовали концепции MSF: модель процессов, управление проектом, модель проектной группы, управление рисками.
Далее мы дали краткую историческую справку по MSF и указали нововведения последней версии MSF 4.0.
Наконец, мы подробно остановились на модели проектной группы MSF и рассмотрели принципы формирования команды, роли и ролевые группы, которые выделяет MSF, их задачи и зоны ответственности.

Взаимодействуйте с "заказчиками"

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

Цели и Задачи

Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты - задачи.
В нашем случае цели системы:

работать с аэропортами и рейсами;

подобрать клиенту оптимальный маршрут.

Задачи системы:

решать однокритериальную задачу поиска кратчайших путей на графах (критерий - цена);

работать с базой данных аэропорта;

бронировать билеты;

…

Функциональность решения

Хранилище находится в оперативной памяти

Добавление аэропортов по нажатию кнопки

Проверка корректности введены данных

Проверка существования аэропорта с введенным номером

Создание визуальной формы для отображения аэропорта

Добавление рейсов

Проверка корректности введены данных

Проверка существования рейса с введенным номером

Проверка на существование аэропортов рейса

Добавление в визуальные формы аэропортов информации о добавленных рейсах

Удаление аэропортов

Удаление всех сопутствующих рейсов

Удаление рейсов

Поиск минимального по стоимости маршрута

Заказ билетов на найденные маршруты

Концепция решения

Концепция решения (solution concept) предоставляет общее описание подходов, которые проектная группа предполагает использовать для разрешения проблем и/или удовлетворения потребностей заинтересованных сторон.

Основные задачи фазы

Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и определение его рамок - не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) - это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Также во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования.
Наконец, во время данной фазы проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта.
Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".

В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории:

бизнес-требования (business requirements);

потребительские требования (user requirements);

эксплуатационные требования (operational requirements);

системные требования, относящиеся к решению в целом (system requirements).

В ходе проектирования решения и создания его функциональной спецификации необходимо следить за соответствием (traceability) между имеющимися требованиями и проектируемой функциональностью.
Процесс проектирования - это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей (user profiles, иногда называемых "персонажами" - "personas"), которые описывают различные типы пользователей и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя. В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых вариантами использования (use cases), которые необходимо выполнить пользователю для осуществления операции.
Существует три уровня процесса проектирования:

концептуальный дизайн (conceptual design);

логический дизайн (logical design);

физический дизайн (physical design).

Работа над логическим дизайном начинается через некоторое время после начала концептуального дизайна, и работа над физическим дизайном стартует через некоторое время после начала работы над логическим.
Результаты процесса проектирования документируются в функциональной спецификации (functional specification). Функциональная спецификация детально описывает вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.
Как только создана базовая версия функциональной спецификации, может быть начато детальное планирование. Каждый из руководителей ролевых кластеров проектной группы подготавливает план или планы, относящиеся к его роли, и принимает участие в командных сессиях планирования. Примеры планов включают в себя план внедрения, план тестирования, план эксплуатации, план мер безопасности, план обучения.
Затем проектная группа коллективно анализирует планы и выявляет взаимозависимости между ними. Все планы синхронизируются и представляются вместе в виде сводного плана проекта. В зависимости от проекта, число планов, образующих сводный план, может меняться.
Члены проектной группы, представляющие каждый из ролевых кластеров, оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule).

Планирование проекта Фаза планирования

На фазе планирования2) (planning) производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.

Пользователи

Основой формулировки требований является анализ использования, включающий определение пользователей (users) и описание того, как пользователи будут взаимодействовать с решением.
В системе будет две группы пользователей:

Менеджеры аэропорта

Покупатели билетов

Предположения и Ограничения

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

система не является распределенной;

нет разграничения прав между менеджерами и пользователями;

интерфейс системы представлен в одном окне;

система должна наглядно демонстрировать формы и способы хранения и взаимодействия данных.

Рамки

Рамки (scope) определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее.
Рамки решения (solution scope) определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) - это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора; шифрование почтовых сообщений - возможностью почтовой программы. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими решения.
Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения.

Результаты фазы планирования

Результатами фазы планирования являются:

Функциональная спецификация.

План управления рисками.

Сводный план и сводный календарный график проекта.

Результаты фазы выработки концепции

Результатами фазы выработки концепции являются:

Общее описание и рамки проекта (vision/scope document).

Документ оценки рисков (risk assessment document).

Описание структуры проекта (project structure document).

Сценарии использования

Сценарии использования (usage scenarios) определяют последовательности действий, которые пользователи выполняют при взаимодействии с решением. MSF не специфицирует явным образом способы описания сценариев использования. Один из возможных (и достаточно распространенных) вариантов - язык UML.
Начнем с диаграммы использования.

Рис. 6.1a. 
Затем расшифруем отдельные сценарии.

Рис. 6.1b. 

увеличить изображение
Рис. 6.1c. 

увеличить изображение
Рис. 6.1d. 

Старт проекта Фаза выработки концепции

Внимание! Презентации семинаров и шаблоны к ним находятся  здесь.
Фаза выработки концепции1) (envisioning phase) - первая фаза жизненного цикла проекта. MSF считает, что одним из фундаментальных факторов успеха проекта является создание и сплочение проектной группы на основе выработки единого видения (shared vision). Проектная группа должна совершенно четко представлять, что она хочет сделать для заказчика, а формулировка цели проекта должна максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.

Учебный пример Выработка концепции

Рассмотрим учебный пример "Система бронирования билетов для авиакомпании".

Вехи фазы планирования

Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между проектной группой и ключевыми заинтересованными сторонами о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.
Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта (project baseline). Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.
Изменения в созданной базовой версии проекта подвергаются строгому контролю. Это не означает, что все принятые во время фазы планирования решения окончательны - в ходе последующей фазы разработки проектная группа должна анализировать и формально утверждать (либо отвергать) все предлагаемые изменения базовой версии.
В течение фазы MSF рекомендует выделить промежуточные вехи:

Верификация технологий (technology validation)
Верификация это проверка соответствия продуктов и технологий, которые предполагается использовать, спецификациям их поставщиков. Это начальный шаг того процесса, который в последствии должен подтвердить выбранную концепцию и, в конце концов, трансформироваться непосредственно в разработку решения.
Зачастую верификация технологий включает в себя отбор наиболее подходящих из конкурирующих технологий.

Базовая версия функциональной спецификации создана
К моменту достижения этой вехи функциональная спецификация готова для распространения среди заинтересованных сторон с целью получения их отзывов. Также начинается контроль изменений, вносимых в подготовленную проектной группой базовую версию спецификации.
Функциональная спецификация является основой создания сводного плана и сводного календарного графика проекта.
Она содержит детальное описание вида и поведения каждой составляющей решения с точки зрения пользователя. Изменения в функциональной спецификации допустимы лишь с одобрения заказчика.

Базовая версия сводного плана проекта создана

В MSF сводный план проекта - это не отдельный самостоятельный план, а совокупность планов работы различных ролевых кластеров. В зависимости от проекта в нем могут быть собраны планы различных типов.


Рис. 6.2.  Сводный план проекта (возможный состав). Источник: белая книга

Компоновка различных проектных планов в один сводный документ [6.1] облегчает совместное планирование работы различных ролевых кластеров и составление единого календарного графика проекта, способствует организации отчетности ролевых кластеров, а также помогает выявить имеющиеся в планах изъяны и несоответствия.

Базовая версия сводного календарного графика проекта создана

Сводный календарный график проекта включает в себя все детализированные календарные графики вплоть до даты выпуска решения. Сводный календарный график интегрирует в себе календарное планирование деятельности каждого ролевого кластера. Дата выпуска определяется после обсуждения со всеми заинтересованными сторонами базовой версии функциональной спецификации и анализа сводного плана проекта. Зачастую, с целью обеспечения выпуска решения в намеченный срок, проектная группа вносит коррективы в функциональную спецификацию и/или сводный план проекта. Хотя принимаемая функциональность решения, доступные ресурсы и отведенное для проекта время могут варьироваться, всеобщий настрой на фиксированную дату выпуска решения мобилизует проектную группу, что помогает адекватно оценивать риски, расставлять приоритеты в работе и планировать.

Среды разработки и тестирования развернуты

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

Среда тестирования должна быть максимально приближена к производственной. Этого важно достичь даже тогда, когда подготовка такой среды требует больших затрат. В противном случае некоторые специфические ошибки могут остаться не выявленными до момента внедрения решения в производственную среду.

Вехи фазы выработки концепции

Главной вехой фазы выработки концепции является веха "Концепция утверждена".
К этому моменту проектная группа и заказчик должны прийти к соглашению об общих задачах проекта, включаемой и не включаемой в решение функциональности и временных рамках.
В течение фазы MSF рекомендует выделить промежуточные вехи:

Ядро проектной группы сформировано
К этому моменту назначены ключевые члены проектной группы, но, как правило, команда еще не сформирована полностью. До того, как формирование проектной группы завершено, уже приступившие к работе сотрудники могут брать на себя роли отсутствующих членов команды.
Документ описания структуры проекта включает в себя информацию об организации проектной группы, персонификации ролей и ответственности. Также документ описания структуры проекта разъясняет схемы взаимодействия проектной группы с заказчиком и заказчика - с проектной группой.

Черновой вариант концепции проекта составлен
К моменту этой промежуточной вехи появляется черновой вариант документа общего описания и рамок проекта, который с целью получения отзывов распространяется среди членов проектной группы, представителей заказчика и других заинтересованных сторон. Затем происходит итеративная доработка документа, включающая в себя рассмотрение полученных отзывов, их обсуждение и внесение изменений.

Видение проекта

Формулировка видения (vision statement) должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования.
Представим возможный вариант.
Разработанная система бронирования билетов позволит авиакомпании "GlobalAvia" повысить эффективность управления рейсами и даст возможность клиентам компании самостоятельно подбирать маршруты (в том числе с пересадками) с оптимальной стоимостью. Через год разработанное решение позволит авиакомпании увеличить число своих клиентов не менее чем в 1.5 раза.

Вспоминая предыдущую лекцию

Наша предыдущая лекция была посвящена управлению рисками и модели процессов в MSF.
Мы обсудили, что такое риски в понимании MSF, зачем необходимо планирование управления рисками. Поговорили о том, из каких стадий состоит процесс управления рисками в MSF. Рассмотрели место управления рисками в жизненном цикле программного продукта.
Далее были подробно описаны принципы модели процессов MSF и составляющие схемы процесса разработки.

За рамками решения

Распределенное хранилище не будет реализовано в первой версии

Раздельное приложение для менеджеров и клиентов не будет реализовано в первой версии

Поиск всех имеющихся маршрутов не будет реализован в первой версии

Задачи ролевых групп на фазе планирования

Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы планирования рассмотрим в виде таблицы.
Ролевой кластерЗадачи

Управление продуктом	Концептуальный дизайн; анализ бизнес-требований; коммуникационный план
Управление программой	Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет
Разработка	Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates)
Удовлетворение потребителя	Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение
Тестирование	Оценка дизайна; требования тестирования; план и календарный график тестирования
Управление выпуском	Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения

Задачи ролевых групп на фазе выработки концепции

Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы выработки концепции рассмотрим в виде таблицы.
Ролевой кластер Задачи

Управление продуктом	Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта.
Управление программой	Цели дизайна; концепция решения; структура проекта
Разработка	Прототипирование; анализ технологических возможностей; анализ осуществимости
Удовлетворение потребителя	Необходимые эксплуатационные характеристики решения и их влияние на его разработку
Тестирование	Стратегии тестирования; критерии приемлемости, их влияние на разработку решения
Управление выпуском	Требования внедрения и их влияние на разработку решения; требования сопровождения

Основные задачи фазы

Во время фазы стабилизации2) производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.
Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence) и точка достижения нуля ошибок (zero bug bounce). Они описываются ниже.
MSF не использует для описания состояния проекта термины "альфа" и "бета". Хотя эти понятия применяются довольно часто, их интерпретация далеко не однозначна. При желании проектная группа может их использовать, но при этом они должны быть четко определены и понятны как членам проектной группы, так и заказчику и другим заинтересованным сторонам.
Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения.

Основные задачи фазы

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

Разработка решения Фаза разработки

Внимание! Презентации семинаров и шаблоны к ним находятся  здесь.

Результаты фазы разработки

Результатами фазы разработки являются:

Исходный и исполнимый код приложений.

Скрипты установки и конфигурирования.

Окончательная функциональная спецификация.

Материалы поддержки решения.

Спецификации и сценарии тестов.

Результаты фазы стабилизации

Результатами фазы стабилизации являются:

Окончательный продукт (golden release).

Документация выпуска (release notes).

Материалы поддержки решения.

Результаты и инструментарий тестирования.

Исходный и исполнимый код приложений.

Проектная документация.

Анализ пройденной фазы (milestone review).

Результаты фазы внедрения

Результаты фазы внедрения включают в себя:

Информационные системы эксплуатации и поддержки.

Процедуры и процессы.

Базы знаний, отчеты, журналы протоколов.

Версии проектных документов, массивы данных и программный код, разработанные во время проекта.

Отчет о завершении проекта (project close-out report).

Окончательные версии всех проектных документов.

Показатели удовлетворенности заказчика и потребителей.

Описание последующих шагов.

  1)
  Раздел подготовлен на основе материалов белой книги [7.1]
  2)
  Раздел подготовлен на основе материалов белой книги [7.1]

  3)
  Раздел подготовлен на основе материалов белой книги [7.1]

Вехи фазы разработки

Веха "Разработка завершена" является кульминацией фазы разработки. К моменту ее наступления создание всех составляющих завершено, и решение готово к тестированию и стабилизации. Заказчики, потребители, персонал сопровождения и другие заинтересованные стороны получают возможность оценить решение и выявить все оставшиеся проблемы и неурегулированные вопросы, которые должны быть улажены до выпуска решения.
В течение фазы MSF рекомендует выделить промежуточные вехи:

Концепция подтверждена
Подтверждение концепции (proof of concept) включает в себя проверку ключевых элементов решения в непроизводственной копии существующей среды. Проектная группа демонстрирует группе сопровождения и потребителям все аспекты решения с целью верификации сформулированных требований.

Билд n завершен, билд n+1 завершен...
Поскольку центром внимания фазы разработки является создание решения, проектной группе необходимо установить промежуточные вехи, помогающие определить прогресс в этой работе.
Разработка ведется параллельно и сегментировано, поэтому возникает потребность в единой мере общего прогресса. Промежуточные билды предоставляют такую меру, заставляя команду разработчиков синхронизировать различные составляющие на уровне решения в целом.
В зависимости от проекта, количество промежуточных билдов и частота их создания может меняться.
Зачастую имеет смысл устанавливать вехи завершения (фиксации) графического дизайна и разработки базы данных, так как от этих составляющих зависит очень многое.

Вехи фазы стабилизации

Фаза стабилизации завершается вехой "Готовность решения утверждена" (release readiness approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.
К моменту наступления этой вехи проектная группа завершает разрешение всех существенных проблем и происходит выпуск или внедрение решения. Ответственность за непрерывное управление и поддержку решения формально переходит от проектной группы к командам сопровождения.
В течение фазы MSF рекомендует выделить промежуточные вехи:

Точка конвергенции
В точке конвергенции (bug convergence)[7.1] становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения.

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

Точка достижения нуля (zero-bug bounce) [7.1]
Это момент, когда впервые все выявленные ошибки оказываются устраненными. Вслед за ней пики количества активных ошибок должны становиться все меньше, вплоть до полного угасания в момент, когда решение уже достаточно стабильно для выпуска первой версии кандидата.

Рис. 7.2.  Точка достижения нуля . Источник: белая книга
Существенную роль играет тщательная приоритезация ошибок, поскольку устранение всякой из них содержит риск внесения новых ошибок. Точка достижения нуля ясно показывает, что проектная группа приближается к созданию стабильной версии кандидата (release candidate).
Заметим, что новые ошибки после достижения этой вехи наверняка будут найдены. Однако точка достижения нуля - это первый момент в работе над проектом, когда команда может честно отчитаться об отсутствии активных ошибок и сфокусироваться на сохранении этого состояния.

Версии-кандидаты

Для пилотной группы подготавливается и выпускается серия версий-кандидатов. Выпуск каждой из них является промежуточной вехой. Эти версии имеют следующие особенности:

Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство.

Создание версии-кандидата служит тестом готовности решения к выпуску, то есть проверяет готовность всех его составляющих.

Период тестирования, следующий за созданием каждой версии-кандидата, определяет, пригодна ли созданная версия к внедрению, или же проектная группа должна подготовить новую версию-кандидат, исправляющую недостатки предыдущей.

Тестирование версий-кандидатов, проходящее внутри проектной группы, требует высокой степени концентрации и интенсивности работы.

Маловероятно, что первая версия-кандидат окажется заключительной.

Контрольное тестирование завершено (pre-production test complete)

Суть этой промежуточной вехи заключается в подготовке к пилотному выпуску решения. Данная веха очень важна, поскольку наступает момент, когда решение "столкнется" с производственной средой, и проектная группа должна как можно тщательнее оттестировать решение до этого момента, - до начала испытания пилотного выпуска.

К данной вехе проектная группа должна:

Оценить результаты тестирования в соответствии с имеющимися критериями успешности.

Подготовить среду внедрения.

Создать необходимые для внедрения процедуры, скрипты, массивы данных.

Иметь готовые учебные материалы.

Обеспечить условия для сопровождения решения.

Создать и протестировать план "отката" (rollback plan).

Данная веха может считаться пройденной лишь после обретения проектной группой полной уверенности в готовности всего, что необходимо для внедрения решения.

Тестирование приемлемости для потребителей завершено

Тестирование приемлемости для потребителей (user acceptance testing) и исследование эргономичности (usability studies) выполняются начиная с фазы разработки и продолжаются на протяжении фазы стабилизации.


Их цель - убедиться в том, что новая система отвечает требованиям потребителей и бизнеса.

По достижению данной вехи пользователи осуществляют тестирование и одобряют работу решения в непроизводственной среде (non-production environment). Это включает в себя проверку интеграции системы с работающими в производственной среде бизнес приложениями. Также должны быть проверены разработанные процедуры "отката" и восстановления после сбоев (rollout and backout procedures).

После одобрения менеджерами выпуска, разработанное программное обеспечение и все докупленные к нему компоненты переносятся из архива группы разработки в архив группы сопровождения.

Пилотное внедрение завершено

Во время этой промежуточной вехи проектная группа тестирует решение целиком в среде, максимально приближенной к производственным условиям. В MSF пилотный релиз (pilot release) - это внедрение решения в часть производственной среды или для части пользователей. В зависимости от проекта, пилотный релиз может принимать различные формы.

На предприятии это может быть релиз для группы пользователей или подмножества серверов данных.

Для веб-разработки это может быть хостинг на тестовых серверах или в подкаталогах, которые доступны в Internet только через тестовый веб-адрес.

Производители коммерческого программного обеспечения, такие как Microsoft, часто выпускают новый программный продукт для специальной группы "первоиспытателей" до того, как будет создана окончательная его версия.

Общим для всех этих форм предварительно выпуска является максимальное приближение тестирования к реальным условиям.

Веха "Пилотное внедрение завершено" не может считаться пройденной, пока проектная группа не удостоверилась окончательно, что созданное решение жизнеспособно в производственной среде, и каждая его компонента готова к внедрению.

Как только в результате пилотного внедрения накоплено и проанализировано достаточное количество данных, проектной группе необходимо принять решение о дальнейших действиях.Возможны следующие варианты:

Шаг вперед: пилотное внедрение нового релиза.

Откат назад: выполняется план отката, и пилотная группа возвращается к конфигурациям, существовавшим до пилотного внедрения. Позднее попытка пилотного внедрения будет повторена вновь с более стабильной версией решения.

Приостановка: пилотная версия "замораживается".

Исправление и продолжение: пилотная группа получает "заплатку" (patch) к существующему коду.

Переход к фазе внедрения.

Вехи фазы внедрения

Главная веха фазы: "Внедрение завершено". Данная веха - кульминация фазы внедрения. К этому времени решение должно начать давать заказчику ожидаемую бизнес-отдачу, а проектная группа - свернуть свою деятельность.
Прежде чем считать решение запущенным в эксплуатацию и свернуть проект, проектная группа должна получить от заказчика подтверждение того, что его цели достигнуты. Для этого решение должно быть стабильным и четко удовлетворять выработанным критериям успешности. Стабильность решения означает также готовность систем его эксплуатации и сопровождения.
В течение фазы MSF рекомендует выделить промежуточные вехи:

Ключевые компоненты развернуты (core components deployed).
Большинство инфраструктурных решений включают в себя ряд компонент, образующих основу всего решения. С точки зрения отдельных пользователей, сами эти компоненты не имеют самостоятельной ценности. Однако внедрение полного решения зависит от ключевых компонент. Кроме того:

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

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

Внедрение на местах завершено (site deployments complete)
К моменту прохождения этой вехи все целевые потребители получают доступ к решению. Лица, ответственные за участки внедрения, подписывают акты о пуске решения в эксплуатацию, хотя определенные проблемы все еще могут возникать.
На этом этапе проектная группа концентрируется на завершении мероприятий по внедрению и на сворачивании проекта.

Многие проекты, в особенности веб-разработки, не подразумевают внедрения на местах, поэтому данная веха к ним не применима.

Внедренное решение стабилизировано

К моменту этой вехи заказчик и проектная группа приходят к соглашению о том, что решение функционирует правильно. Однако нужно понимать, что все еще могут возникать некоторые проблемы на местах. Они должны отслеживаться и разрешаться. Тем не менее, проектной группе важно четко зафиксировать точку завершения внедрения, а не пытаться достичь идеального состояния решения.

Если заказчик ожидает, что члены проектной команды будут участвовать в поддержке и сопровождении решения, после завершения проекта соответствующие сотрудники должны быть переведены на новые роли в структуре сопровождения.

На этой стадии, по всей вероятности, члены проектной группы и внешние заинтересованные лица начнут выходить из проекта.

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

Вспоминая предыдущую лекцию

Наша предыдущая лекция была посвящена фазам выработки концепции и планирования в MSF.
Для каждой фазы мы рассмотрели:

Основные задачи фазы

Задачи ролевых групп

Вехи фазы

Результаты фазы

Также обсудили учебный пример применительно к действиям, которые должны выполняться в течение указанных фаз.

Задачи ролевых групп на фазе разработки

Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы разработки рассмотрим в виде таблицы.
Ролевой кластерЗадачи

Управление продуктом	Ожидания заказчика
Управление программой	Управление функциональной спецификацией; мониторинг проекта; доработка планов
Разработка	Разработка программного кода и инфраструктуры; документирование конфигураций
Удовлетворение потребителя	Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн
Тестирование	Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования
Управление выпуском	Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists)

Задачи ролевых групп на фазе стабилизации

Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы стабилизации рассмотрим в виде таблицы.
Ролевой кластерЗадачи

Управление продуктом	Исполнение коммуникационного плана; планирование премьеры продукта
Управление программой	Мониторинг проекта; приоритезация ошибок
Разработка	Устранение ошибок; оптимизация программного кода
Удовлетворение потребителя	Доработка эксплуатационных руководств; учебные материалы
Тестирование	Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации
Управление выпуском	Развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения

Задачи ролевых групп на фазе внедрения

Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения рассмотрим в виде таблицы.
Ролевой кластерЗадачи

Управление продуктом	Получение отзывов и оценок заказчика; акт о приеме выполненной работы
Управление программой	Сопоставление рамок проекта с поставленным решением; управление стабилизацией
Разработка	Разрешение проблем; поддержка эскалации
Удовлетворение потребителя	Обучение; управление календарным графиком обучения
Тестирование	Тестирование производительности
Управление выпуском	Управление внедрением; одобрение изменений

Анализ постановки - полное описание

Задача является математической. Система должна уметь решать однокритериальную задачу поиска кратчайших путей на графах. Критерий - цена.

Система распределенная: так как в каждом аэропорте своя база направлений полетов самолетов, то знают о рейсе только аэропорты-соседи по рейсам.

Объекты системы: распределенное хранилище рейсов, покупатель билетов, менеджер рейсов.

Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.

Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.
Среди причин:

Отсутствие рейсов в желаемом направлении даже с учетом пересадок.

Нехватка денег.

В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.

Менеджер рейсов: должен иметь следующие возможности:

создания и удаления аэропортов в системе.

создания и удаления рейсов в аэропортах.

Цель преподавания курса

Отрасль разработки программного обеспечения - одна из самых молодых и перспективных отраслей человеческой деятельности. В настоящее время сложность задач, стоящих перед отраслью, непрерывно возрастает, что требует применения специальных технологий организации и проведения процесса разработки программного обеспечения. Теоретическое изучение подобных технологий, совмещенное с их практическим применением, представляет собой исключительно важную часть подготовки специалиста в области разработки программного обеспечения.
Цель данного курса состоит в изучении основных путей организации и проведения успешных проектов в области разработки программного обеспечения на базе принципов Microsoft Solutions Framework (MSF). Важная роль отводится практической составляющей курса.

Цели и задачи лабораторного практикума

Цель данного лабораторного практикума состоит в практическом знакомстве с процессом командной разработки программного обеспечения на примере Microsoft Solutions Framework (MSF).
В процессе выполнения лабораторного практикума предполагается решение следующих задач:

начальное освоение унифицированного языка моделирования UML;

получение практического опыта работы в команде из 5-7 человек;

освоение методологии Microsoft Solutions Framework for Agile Software Development в процессе командной разработки учебной программной системы.

Дисциплины, усвоение которых необходимо при изучении данного курса

Курс опирается на материалы следующих курсов: CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", CS105 "Дискретная математика" . Предполагается, что данный курс читается параллельно с курсом CS103 "Алгоритмы и структуры данных" с запаздыванием в 1 семестр (рис. 1).

Рис. 1.  Предполагаемая последовательность изучения курсов. Закрашенные части читаются одновременно

Характеристика курса

Данный курс читается в 4-ом семестре и опирается на прочитанные ранее общие курсы CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", в рамках которых студенты знакомятся с фундаментальными понятиями, принципами и методами программирования, изучают основные алгоритмы, простейшие структуры данных, языки программирования Object Pascal и C/C++. В 3-ем семестре студенты изучают первую часть курса CS103 "Алгоритмы и структуры данных", выполняют лабораторные работы согласно учебному плану. Таким образом, полученных к 4-му семестру знаний и навыков достаточно для того, чтобы приступить к ознакомлению с технологиями коллективной разработки программ.
Конечно, уровень студента 2 курса все еще не позволяет овладеть этой темой полностью, поэтому учебный план предполагает изучение нескольких последовательно расположенных курсов, первым из которых, вводным, является данный курс - "Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)".
В качестве базовой методологии разработки программного продукта выбрана перспективная, хорошо себя зарекомендовавшая методология MSF. В лекциях рассматривается суть методологии, ее основные этапы и принципы.
На протяжении изучения курса на лекциях рассматривается специально разработанный пример, на основе которого иллюстрируются все этапы разработки программного продукта.
Наряду с изучением теоретической составляющей - проблематики и базовых принципов коллективной разработки программ, сути и принципов MSF - большое внимание уделяется практической составляющей. В рамках лабораторного практикума студенты делятся на команды в соответствии с моделью команды MSF и, получив задачу, выполняют весь цикл работ по проектированию, разработке, тестированию и внедрению программного продукта.
В качестве некоторых управленческих ролей возможно привлечение магистрантов, имеющих некоторый опыт создания ПО в командах разработчиков.
Рассмотрим кратко основные разделы курса и их содержание.

Во введении ( лекция 1) дается понятие программного обеспечения (ПО), описывается проблема роста сложности разработки качественного продукта в заданные сроки в соответствии с имеющимся бюджетом, рассматриваются основные технологии программирования как средства борьбы со сложностью. Дается краткая характеристика курса, формулируются его цели, задачи и структура учебного плана.

Основная часть курса состоит из трех разделов.

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

В первом разделе курса (лекция 2) дается обзор некоторых понятий и принципов программной инженерии. В частности разбирается понятие программной инженерии, процесса, модели процесса разработки ПО. Рассматриваются конкретные модели процесса.

Во втором разделе курса (лекции 3, практики 1, 2, 3) идет речь о принципах объектно-ориентированного анализа и проектирования программного обеспечения при помощи визуальных средств языка UML. Дается обзор принципов объектного подхода, рассматриваются важные аспекты повторного использования, рассматриваются элементы языка UML. Демонстрируется применение UML для визуализации проектирования лекционных примеров из читаемого параллельно курса CS103 "Алгоритмы и структуры данных".

В третьем разделе курса (лекции 4, 5, 6, 7, практики 4, 5, 6, 7, 8) изучается методология разработки программного обеспечения Microsoft Solutions Framework 4.0. Рассматривается история MSF, основные принципы MSF, модель проектной группы, роли и фазы MSF. Через все фазы проводится лекционный пример - разработка системы бронирования билетов для аэропорта.

Характеристика практикума

Лабораторный практикум предполагает разбиение группы студентов на команды по 5-7 человек, распределение ролей в каждой команде в соответствии с положениями методологии Microsoft Solutions Framework for Agile Software Development и прохождение каждой командой всех фаз процесса разработки. Практикум состоит из двух разделов.
В первом разделе (практики 1, 2, 3) повторяются принципы объектного подхода и важные аспекты повторного использования, а также демонстрируется применение унифицированного языка моделирования UML для визуализации проектирования примеров из читаемого параллельно курса CS103 "Алгоритмы и структуры данных". Здесь же происходит разбиение студентов на команды и формулировка задач.
Во втором разделе (практики 4, 5, 6, 7, 8) каждая команда выбирает задачу из списка, предложенного преподавателем, и последовательно проходит через этапы: распределение ролей (в отличие от положений MSF в роли разработчика будут находиться все), выработка концепции и построение видения проекта, планирование, разработка решения, стабилизация и, наконец, внедрение решения.
В процессе разработки преподаватель выступает в роли заказчика. Постановки задач даются студентам в краткой форме. Задача студентов - извлечь из заказчика необходимые сведения.
Результатом работы команды должен быть работающий прототип системы и необходимые документы, являющиеся результатами прохождения фаз согласно методологии MSF.
Внедрение полученного каждой командой решения предполагается в одной из других команд. Таким образом, в процессе оценки решения участвует преподаватель, как лицо, принимающее решения со стороны заказчика, и другая команда, в качестве потенциальных пользователей.

Информационные ресурсы сети Интернет

Ian Sommerville. Software Engineering. 6th Edition. [http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6]

Ian Sommerville. Software Engineering. 7th Edition. [http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7]

www.uml.org

www.wikipedia.org

http://www.microsoft.com/msf

С. Якимчук. MSF - философия создания IT-решений или голые амбиции лидера, 2004: [http://www.citforum.ru/SE/project/msf/].

Алистер Кокбёрн. Каждому проекту своя методология:[http://software-testing.ru/lib/cockburn/methodology-per-project.htm](перевод статьи Alistair Cockburn. Methodology per project: [http://alistair.cockburn.us/index.php/Methodology_per_project]).

А. Терехов, А. Ложечкин. Microsoft Solutions Framework 4.0 - опыт Microsoft по организации командной разработки. Презентация с Microsoft Платформа 2006

MSF for Agile Software Development Process Guidance: [http://go.microsoft.com/fwlink/?linkid=63524]

Краткое описание

На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.
При формулировании требований менеджеры упомянули, что рейсы спланированы так, что до пункта назначения можно долететь с пересадками. Одно из требований заключалось в том, чтобы система помогала покупать билеты в зависимости от пожеланий пользователя.

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


Фирма "OurResearch" занимается написанием математических программ по заказу. При этом в фирме часто приходится писать отчеты заказчику. При написании отчетов заказчик хочет видеть в отчетах математические формулы в классическом виде.
У Вашей фирмы компания решила заказать удобное средство для перевода и написания математических выражений в разные форматы представления. Причем, если в редакторе присутствует ряд взаимосвязанных формул, то фирма хочет видеть адекватный код. При этом известно, что фирма часто использует C/C++, Pascal и Fortran.


Необходимо реализовать на стороне сервера хранилище, в которое можно помещать алгоритмы в некотором стандартном виде, а потом исполнять их. Для простоты алгоритмы могут представлять собой математические формулы. В алгоритмах должны быть заявлены следующие данные:

входные данные;

выходные данные;

код алгоритмов.

Доступ к алгоритмам должен быть ограничен на основе разделения прав по ролям.


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


В компании "Justice" были проведены исследования, в результате которых компания поняла, что теряет достаточно много средств из-за не всегда равномерного распределения зарплаты. Кроме денежных потерь есть и недовольство персонала, которое вызвано тем, что те, кто много работают, и те, кто мало, получают одинаковые зарплаты.
Компания решила изменить данную ситуацию. Вашей компании предложили выработать решение описанной проблемы.


На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. В первой требуется заносить необходимую информацию. Со второй частью будут работать покупатели билетов.
При формулировании требований менеджеры упомянули, что рейсы у них спланированы так, что до пункта назначения можно долететь с пересадками за разное время и с разным комфортом. Одно из требований заключалось в том, что бы система помогала покупать билеты в зависимости от требований пользователя.


Организация "Presentation for you" профессионально занимается подготовкой и проведением презентаций для фирм. В фирме за последние несколько кварталов сильно увеличился объем заказов. В результате постоянно стали наблюдаться ситуации, когда презентации задерживались из-за нехватки каких-либо ресурсов (аудиторий, проекторов, досок).
В фирме были проведены исследования и было установлено, что ситуация сильно улучшится, если у фирмы появится электронная система распределения ресурсов, а не бумажная как это было раньше.

Краткое постановка

В компании "SuperSoft" возникла потребность автоматизировать управление проектами. В силу того, что компания существует на рынке разработки ПО недавно и не обладает достаточным количеством свободных финансовых средств, было принято решение не покупать системы управления проектами типа Microsoft Project (стоимость коробочной версии от $600), а разработать собственное простое решение.
Система управления проектами должна иметь единую базу проектов, подключаться к которой могут менеджеры и исполнители. Содержимое базы составляет информация о ведущихся в компании проектах.

Литература

И. Соммервиль. Инженерия программного обеспечения, 6 изд. - И.д. "Вильямс", 2002.

Г. Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание. - Бином, 1998.

N. Wirth. Program Development by Stepwise Refinement // Communications of the ACM vol.26(1).- 1971, 1983.

O. Dahl, E. Dijkstra, C.A.R. Hoare. Structured Programming.-London, England: Academic Press, 1972.

Р. Лингер, Х. Миллс, Б. Уитт. Теория и практика структурного программирования. - М.: Мир, 1982.

Э. Салливан. Время - деньги. - М.:Microsoft Press, Русская редакция, 2002.

Г. Буч, Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя. - ДМК-Пресс, Питер, 2004.

G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004.

Модель процессов MSF. Белая книга, 2003, перевод eLine Software.

Дисциплина управления рисками MSF. Белая книга, 2003, перевод eLine Software.

Модель проектной группы MSF. Белая книга, 2003, перевод eLine Software.

1846A: Microsoft Solutions Framework Essentials. Microsoft Official Course, 2002

2710B: Analyzing Requirements and Defining Microsoft .NET Solutions Architecture. Microsoft Official Course, 2003

MSF Process Model. White paper, 2002 Microsoft Corporation.

MSF Risk Management Discipline. White paper, 2002 Microsoft Corporation.

MSF Team Model. White paper, 2002 Microsoft Corporation.

Полная постановка задачи

Функционирование системы предполагается на локальном компьютере. Работа в системе должна включать в себя три части:

редактирование карт;

задание и редактирование движения воздушных масс и циклонов;

демонстрация погодных условий.

Для редактирования карт и задания движения воздушных масс предполагается, разработка редактора векторной графики. Изображения могут сроиться как из векторных примитивов: линии, окружности, прямоугольники, - так и из более сложных объектов векторной графики: полигоны, кривые Безье, …
Желательно обеспечить возможность заливки внутренности замкнутых объектов выбранным цветом.
Объекты системы: карта, изображение воздушных масс, подсистема расчета движения воздушных масс, режим просмотра изменения метеоусловий.
Карта, изображение воздушных масс: набор векторных примитивов.
Подсистема расчета движения воздушных масс: в простейшем случае статические формулы. Более сложный случай - имитационная система или решатель систем дифференциальных уравнений.
Режим просмотра изменения метеоусловий: подсистема, которая должна быть реализована в двух видах:

интегрированное средство просмотра результата;

отдельное приложение просмотра.

Система должна уметь сохранять результат работы в определенном формате (рекомендуется XML). Возобновлять состояние после загрузки сохраненных данных, при этом желательно реализовать контроль правильности формата читаемого файла.

Необходимо разработать систему для редактирования и написания математических формул.
Объекты системы: формула, формульный редактор.
Формула: математическое выражение в одном из видов, желательно, что бы редактор сам распознавал язык и вид выражения по сигнатуре.
Формульный редактор: визуальная часть. Должен позволять:

транслировать стандартный синтаксис формул во внутренний формат;

отображать из внутреннего формата в графический вид;

визуально редактировать формулы;

отображать структуру данных формулы.

Дополнительно система должна обеспечивать сохранение формул в нескольких форматах (например, в XML).
Редактор должен включать в себя конвертор в различные форматы, к примеру, перевод формулы в стандартное выражение для C/C++, Pascal и Fortran.
Также обязательно нужна возможность перевода формулы в BMP-изображение.


Web-сервис должен быть рассчитан на небольшое число пользователей и работу в локальной сети. К web-сервису должен быть реализован разделенный доступ пользователей.
Объекты системы: пользователь, роль, алгоритм, web-сервис.
Пользователи: логин, пароль, роль.
Пользователь может на web-сервисе осуществлять следующие действия:

размещать алгоритмы;

изымать на редактирование алгоритмы;

удалять алгоритмы с web-сервиса;

исполнять алгоритмы.

Роль: представляет собой список пользователей.
Алгоритм: название, код (математическое выражение), принадлежность пользователю, входные и выходные параметры.
Web-сервис предоставляет следующие возможности:

хранить алгоритмы на сервере;

предоставлять доступ к алгоритмам:

редактирование;

удаление;

исполнение алгоритма на сервере.

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


Требуется реализовать комплексную систему обмена сообщениями для небольшого количества пользователей.
Система должна удовлетворять следующим требованиям:

возможность отправки и получения почты;

возможность чата с пользователями, находящимися в сети.

Объекты системы: пользователь, сервер, письмо, список контактов, быстрое сообщение, почтовый клиент, клиент для чата.
Пользователь: ФИО, логин, пароль.
Сервер: представляет собой хранилище почты и маршрутизатор сообщений. Сервер должен разграничивать доступ к информации различных пользователей. Каждый пользователь может получить только свою почту. Пользователь может присоединяться к чатам и участвовать в обсуждении, но только в том случае, если он входит в список тех, кому разрешен доступ.
Письмо: для написания писем предполагается разработка простейшего текстового редактора. Внутренний формат - некоторая динамическая структура данных. При сохранении и отправке должен генерироваться HTML-документ. При приеме HTML-документ должен разбираться во внутреннюю структуру. Предполагается ограниченный набор тегов и свойств тегов.
Быстрое сообщение: обычное текстовое сообщение, для генерации которого используется редактор письма. Отличие от почты в том, что сообщение видят все, находящиеся в чате, сразу после отправки.
Список контактов: список логинов пользователей системы.
Почтовый клиент: включает в себя редактор почты, средства просмотра и отправки почты лицам из списка контактов.
Клиент для чата: содержит список доступных чатов. Предоставляет возможность создания чатов и открытие чата для людей из списка контактов.


Нужно реализовать систему учета работы персонала.
Объекты системы: датчики, хранилища данных, менеджер, работник, система начисления зарплаты, система построения отчетов.
Датчики: считается, что фирма состоит из нескольких филиалов и в каждом филиале есть отдельные наборы датчиков. Каждый набор датчиков сохраняет информацию в свое хранилище данных. Основные данные, с которыми работает система:

Кто и во сколько пришел.

Кто и во сколько ушел.

Кто когда отбыл в командировку.

Кто и когда вернулся из командировки.

Хранилище данных: является распределенным. Предназначение - вести журнал данных, поступающих с датчиков. Доступ к хранилищу могут получать только работники и менеджеры.
В системе должны существовать две роли: работник и менеджер. При этом менеджер также может быть и работником.
Работник: ФИО, логин, пароль, табельный номер, счет для начисления зарплаты. При каждом посещении филиала записывается время прибытия отбытия и, возможно, работа, которую он выполнял. Работники могут просмотреть, сколько и когда они работали, и какая зарплата их ожидает.
Менеджер: контролирующая должность. Содержит ФИО, логин, пароль, табельный номер, счет для начисления зарплаты.
Выполняет следующие функции:

Построение и просмотр отчетности по работникам (через систему построения отчетов).

Премирование выделившихся работников.

Прием и увольнение персонала.

Поднятие и понижение разрядов и определение квалификационной группы.

Установление индексов зарплат для работников.

Контроль за системой начисления зарплаты.

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


Задача является больше математической. Система должна уметь решать трехкритериальную задачу поиска кратчайших путей на графах. Критерии:

Время.

Цена.

Комфорт.

Система является распределенной, поскольку в каждом аэропорту своя база направлений полетов самолетов, соответственно, знают о рейсе только аэропорты-соседи. Одно и требований, которое выдвигает компания, - не делать базу централизованной ввиду дороговизны оборудования, которое в противном случае пришлось бы приобрести.
Объекты системы: распределенное хранилище рейсов, покупатель билетов.
Распределенное хранилище рейсов: название рейсов, номера и тип самолетов, класс самолета по комфорту и стоимость билетов.
Покупатель: ФИО, сумма. Покупатель на сайте задает параметры, связанные с суммой, которую он хочет потратить, комфорт и время. Система должна подобрать оптимальные маршруты. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна дать в ответе причину, по которой не получается подобрать маршрут. Среди причин:

Отсутствие рейсов в требуемом направлении даже с пересадками.

Сумма слишком мала.

Комфорт завышен.

В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.


Система управления проектами должна быть рассчитана на небольшие команды. В каждом проекте выделяются только две роли: менеджер и исполнитель.
Менеджер может управлять несколькими проектами, исполнитель участвует только в одном проекте.
Менеджер управляет проектом, то есть с точки зрения системы: формирует список задач проекта, распределяет задачи по исполнителям (ограничение: нет задач, предназначенных более чем одному исполнителю), формирует план-график выполнения проекта (задает сроки выполнения задач), выставляет состояние задач (не начата, выполняется, завершена, отложена).
Исполнитель получает от менеджера задачи, на основании которых для него формируется "ToDo-List". Список может пополняться по ходу проекта, как менеджером, так и самим исполнителем.
Объекты системы: менеджер, исполнитель, задача, проект, "ToDo-List".
Менеджер: ФИО, проект(ы).
Исполнитель: ФИО, проект, "ToDo-List".
Задача: имя, формулировка, срок начала, срок окончания (выставленный менеджером), срок фактического окончания (когда исполнитель "сдал" задачу менеджеру, а тот ее "принял"), состояние (не начата, выполняется, завершена, отложена), причина изменения срока окончания/откладывания.
Проект: имя, менеджер, исполнители, задачи.
"ToDo-List": список задач для исполнителя. Часть списка формируется автоматически, доступна только для чтения. Часть формируется исполнителем "для себя", доступна для редактирования.
Сроки для задач могут задаваться с точностью до часов (начало: 21 июля 14.00, окончание: 21 июля 16.00, фактического окончание: 21 июля 17 часов, причина изменения сроков: учения по пожарной безопасности).
Хранение всех данных централизовано. Система имеет серверную часть (хранение информации и интерфейс для администрирования) и клиентскую часть, с которой работают менеджеры и исполнители.
По данным каждого проекта в системе должна быть возможность поиска.


Предполагается, что система будет функционировать на сервере, к ней будут подключаться клиенты для резервирования ресурсов на определенное время.
Объекты системы: сервер, ресурс, расписание использования ресурса, пользователь, администратор, менеджер ресурсов, клиент.
Сервер: Обладает следующей функциональностью:

Хранит информацию обо всех ресурсах и пользователях.

Позволяет управлять пользовательскими записями:

Добавлять.

Удалять.

Назначать уровень доступа.

Разделяет уровень доступа для различных пользователей на основе ролевых кластеров:

Администратор.

Менеджер.

Пользователь.

Выдает информацию о ресурсах в соответствии с уровнем доступа.

Ресурс: название, серийный номер (номер аудитории, номер доски), расписание использования ресурса.
Расписание использования ресурсов: порождается для каждого ресурса. Включается записи о времени занятости и цели использования.
Пользователь: ФИО, логин, пароль, информация о дополнительных ролях.
Дополнительных ролей две:

Администратор.

Менеджер ресурсов.

У пользователя должны быть следующие функции:

Запрос на занятие ресурса на определенное время с указанной целью.

Различные виды просмотров занятости ресурсов.

Конкретного ресурса.

Группы ресурсов.

Администратор: Выполняет функции менеджера пользователей. Не может управлять ресурсами.
Менеджер ресурсов: Основные функции:

Добавление и удаление ресурсов.

Подтверждение или отклонение запросов на занятие ресурсов.

Клиент: Должен быть реализован в виде web-сайта и Windows приложения.

Постановки задач

В приложении приведены краткие и полные постановки задач для лабораторного практикума. Студентам во время занятий будут озвучены краткие постановки, все остальное, необходимое для проектирования и реализации, они должны выяснить у преподавателя.

Содержание курса

Введение
Важность предмета.
Программа и программное обеспечение, основные отличия. О рынке программного обеспечения.
Сложность управления процессом разработки программного обеспечения.
Технологии программирования как способ борьбы со сложностью.
Обзор технологий программирования (структурное, модульное, объектно-ориентированное, компонентное программирование).
Цели и задачи курса. Структура учебного плана. Основная и дополнительная литература, Интернет-источники.
1. Элементы программной инженерии.
1.1. Программная инженерия, основные понятия.
Инженерия и инженеры.
Программная инженерия как инженерная дисциплина.
Область действия программной инженерии и отличия от других инженерий.
Программные инженеры и их деятельность.
Программные инженеры и научная среда - ключевые различия и принципы успешного взаимодействия.
Показатели качества программного продукта.
1.2. Процесс создания программного обеспечения
Понятие процесса создания ПО. Основные стадии процесса.
Модели процесса создания ПО. Каскадная и эволюционная модели.
Итерационные модели процесса создания ПО. Модель пошаговой разработки, спиральная модель.
2. Визуальное моделирование при анализе и проектировании. Основы Unified Modeling Language (UML).
2.1. Анализ и проектирование. Некоторые частные вопросы
2.1.1. Обзор принципов объектного подхода.
Алгоритмическая и объектная декомпозиции. Классы и объекты.
Объектно-ориентированный анализ.
Объектно-ориентированное проектирование.
Объектно-ориентированное программирование.
Принципы объектного подхода: абстрагирование, инкапсуляция, иерархия, агрегация и наследование, полиморфизм.
Пример: ООП и структуры данных. Проектирование структуры данных стек.
2.1.2. Повторное использование.
Идея повторного использования. Важность повторного использования.
Достоинства повторного использования. Виды повторного использования.
2.2. Визуальное моделирование. История языка UML.
Идея визуального моделирования.
Необходимость универсального языка для визуального моделирования.
История возникновения и развития языка UML.

2.3. Структура языка UML.

Модели UML.

Диаграммы и понятия UML.

2.4. Учебный пример: Задача о разработке программного комплекса бронирования билетов для авиакомпании "SRS - Seat Reservation System". Постановка задачи.

2.5. Визуальное описание модели функционирования системы средствами UML.

Понятия Актера и Варианта использования.

Ассоциация между Актером и Вариантом использования.

Диаграмма вариантов использования.

Диаграмма действия.

Пример: Использование средств UML для визуального моделирования поведения программной системы "SRS".

2.6. Классы, объекты, поля, методы, подсистемы, компоненты, пакеты и их отображение средствами UML.

Пример: Использование средств UML для визуального проектирования программной системы "SRS".

2.7. Проектирование системы. Диаграммы классов и их описание средствами UML.

Диаграммы классов. Зависимость, наследование, ассоциация, агрегация, композиция и их отображение средствами UML.

Пример: Использование средств UML для визуального проектирования программной системы "SRS".

3. Методология создания программных решений Microsoft Solutions Framework.

3.1. Введение в методологию MSF и историческая справка.

Что такое MSF. Основные концепции методологии: модель процессов, управление проектом, модель проектной группы, управление рисками. Позиционирование MSF в сравнении с другими методологиями разработки программного обеспечения. Инструментальная поддержка методологии до версии 3.0 включительно. Источники информации.

3.2. Нововведения версии MSF 4.0.

Разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. Причины разделения методологии MSF на "облегченный" и "тяжелый" варианты, основные отличия направлений. Почему в основу курса положено направление MSF for Agile Software Development? Характеристика основных положений MSF for Agile Software Development. Инструментальная поддержка MSF 4.0 в среде разработки Microsoft Visual Studio 2005. Источники информации.


3.3. Формирование команды. Модель проектной группы MSF for Agile Software Development.

Основные принципы построения команды.

"Проектная группа - команда равных".

Каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны.

"Масштабируемость" модели проектной группы в зависимости от числа участников.

Ролевые группы и роли, зоны ответственности ролевых групп, их задачи и взаимодействие с заинтересованными лицами.

MSF for Agile Software Development выделяет 7 ролевых групп: управление программой, архитектура продукта, разработка, тестирование, управление выпуском, удовлетворение потребителя, управление продуктом, - и 6 ролей: менеджер проекта, архитектор, разработчик, тестер, релиз-менеджер, бизнес-аналитик. Для каждой группы и роли, помимо зоны ответственности, в которой роль имеет решающий голос, определены заинтересованные стороны, как внутри, так и вне команды, с которыми группа должна взаимодействовать и чьи интересы представлять/отстаивать при принятии решений.

Рекомендации по возможному объединению ролей.

Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта.

3.4. Управление рисками в MSF for Agile Software Development.

Основные сведения о рисках.

Планирование управления рисками.

Процесс управления рисками: выявление, анализ и приоритезация, планирование, мониторинг, корректирование, извлечение уроков.

Управление рисками как составная часть жизненного цикла проекта.

Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта. Выделение рисков.

3.5. Модель процессов MSF for Agile Software Development.

Принципы модели процессов.

Взаимодействуйте с "заказчиками".

Поощряйте свободный обмен информацией в проекте.

Создавайте "единое видение проекта".

Следите за качеством продукта.

Проявляйте гибкость - будьте готовы к изменениям.

Ставьте "вехи".

Будьте готовы к внедрению сегодня.

Схема процесса разработки.

Основные структурные единицы схемы: циклы, фазы и вехи.


Цикличность всех уровней процесса разработки. Примеры циклов в различных задачах на различных уровнях: контроль версий, ежедневная сборка, итерация, версия продукта.

Фазы и вехи процесса разработки: выработка концепции, планирование проекта, разработка решения, стабилизация решения, внедрение решения. Распределение задач по фазам. Выбор продолжительности фаз. Принцип "каждой фазе - свои вехи". Вопросы, определяющие выполнение очередной фазы и достижение соответствующей вехи.

3.6. Старт проекта. Фаза выработки концепции.

Основные задачи фазы: создание ядра проектной группы, формирование видения проекта, подготовка документа общего описания и рамок проекта, подготовка документа оценки рисков и представление главных рисков проекта, выявление и анализ бизнес-требований.

Задачи ролевых групп на фазе выработки концепции.

Главная веха фазы: "Концепция утверждена".

Рекомендуемые промежуточные вехи: "Ядро проектной группы сформировано", "Черновой вариант концепции проекта составлен".

Результаты фазы: "Общее описание и рамки проекта", "Документ оценки рисков", "Описание структуры проекта".

Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта. Выработка концепции.

3.7. Планирование проекта. Фаза планирования.

Основные задачи фазы: анализ и документирование проектных требований, подготовка функциональной спецификации, разработка дизайнов, подготовка рабочих планов, оценка проектных затрат и сроков разработки различных составляющих проекта.

Категории проектных требований. Уровни процесса проектирования.

Задачи ролевых групп на фазе планирования.

Главная веха фазы: "Планы проекта утверждены".

Рекомендуемые промежуточные вехи: "Верификация технологий", "Базовая версия функциональной спецификации создана", "Базовая версия сводного плана проекта создана", "Базовая версия сводного календарного графика проекта создана", "Среды разработки и тестирования развернуты".


Результаты фазы: "Функциональная спецификация", "План управления рисками", "Сводный план и сводный календарный график проекта".

3.8. Разработка решения. Фаза разработки.

Основная задача фазы - создание компонент решения, включая как документацию, так и программный код.

Задачи ролевых групп на фазе разработки.

Главная веха фазы: "Разработка завершена ".

Рекомендуемые промежуточные вехи: "Концепция подтверждена", "Билд номер N завершен", "Билд номер N+1 завершен",…

Результаты фазы: "Исходный и исполняемый код приложений", "Скрипты установки и конфигурирования", "Окончательная функциональная спецификация", "Материалы поддержки решения", "Спецификации и сценарии тестов".

3.9. Стабилизация решения. Фаза стабилизации.

Основные задачи фазы: тестирование разработанного решения, приоритезация и устранение ошибок, подготовка решения к выпуску, пилотное внедрение.

Задачи ролевых групп на фазе стабилизации.

Главная веха фазы: "Готовность решения утверждена".

Рекомендуемые промежуточные вехи: "Точка конвергенции", "Точка достижения нуля ошибок", "Версии-кандидаты", "Контрольное тестирование завершено", "Тестирование приемлемости для потребителей завершено", "Пилотное внедрение завершено".

Результаты фазы: "Окончательный продукт", "Документация выпуска", "Материалы поддержки решения", "Результаты и инструментарий тестирования", "Исходный и исполнимый код приложений", "Проектная документация", "Анализ пройденной фазы".

3.10. Внедрение решения. Фаза внедрения.

Основные задачи фазы: внедрение технологий и компонент решения, стабилизация внедренного решения, передача работ персоналу поддержки и сопровождения, получение со стороны заказчика окончательного одобрения результатами проекта, анализ выполненной работы и удовлетворенности заказчика.

Задачи ролевых групп на фазе внедрения.

Главная веха фазы: "Внедрение завершено".

Рекомендуемые промежуточные вехи: "Ключевые компоненты развернуты", "Внедрение на местах завершено", "Внедренное решение стабилизировано".

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

Задачи изучения курса

В рамках изучения курса предполагается решение следующих задач:

рассмотрение технологических основ процесса разработки программного обеспечения;

изучение основ унифицированного языка UML для визуального моделирования элементов предметной области в рамках проектирования программной системы и ее основных компонент;

получение практического опыта работы в команде из 5-7 человек с применением методологии MSF;

приобретение и развитие навыков анализа, проектирования, документирования и разработки программных комплексов средней сложности.

По окончании изучения курса студенты будут уметь использовать методологию Microsoft Solutions Framework for Agile Software Development, включая:

разработку формальных требований к программной системе, основанных на потребностях заинтересованных лиц;

разработку проекта программной системы с учетом возможностей ее дальнейшего развития, а также повторного использования некоторых ее компонент в других проектах;

создание диаграммы классов и компонент UML для визуального представления архитектуры программной системы;

документирование процесса разработки программной системы.

Затрагиваемые разделы рекомендаций Computing Curricula (Software Engineering )

Данный курс является вводным курсом в рамках направления "Программная инженерия" и затрагивает следующие элементы курса SE201:
CMP.ct - Технологии разработки
MAA.md - Моделирование
MAA.tm - Типы моделей
MAA.rfd - Требования
MAA.rsd - Спецификация и документирование требований
MAA.rv - Проверка требований
DES - Проектирование
PRO.imp - Процесс разработки
MGT - Управление процессом разработки



    Программирование: Языки - Технологии - Разработка

• Программирование
  
• Технологии программирования
  
• Разработка программ
  
• Работа с данными
  
• Методы программирования
  
  
• IDE интерфейс
  
• Графический интерфейс
  
• Программирование интерфейсов
  
• Отладка программ
  
• Тестирование программ
  
  
• Программирование на Delphi
  
• Программирование в ActionScript
  
• Assembler
  
• Basic
  
• Pascal
  
  
• Perl
  
• VBA
  
• VRML
  
• XML
  
• Ada
  
  
• Lisp
  
• Python
  
• UML
  
• Форт
  
• Языки программирования