П.П.Мельников 1. 2 В соответствии с ФГОС в результате изучения дисциплины обучающийся должен: Знать методы анализа предметной области; технологию формирования. - презентация

1 П.П.Мельников 1

2 2 В соответствии с ФГОС в результате изучения дисциплины обучающийся должен: Знать методы анализа предметной области; технологию формирования требований к ИС; методологии и технологии проектирования ИС, проектирование обеспечивающих подсистем ИС; методы и средства организации управления проектом ИС на всех стадиях жизненного цикла, оценка затрат проекта и экономической эффективности ИС; основы менеджмента качества ИС; методы управления портфолио IT – проектов. Владеть навыками работы с инструментальными средствами моделирования предметной области, прикладных и информационных процессов; разработки технологической документации; использования функциональных и технологических стандартов ИС; работы с инструментальными средствами проектирования баз данных и знаний, управления проектами ИС и защиты информации.

3 3 Вид учебной работы Всего часов Семестры 56 Общая трудоёмкость дисциплины Аудиторные занятия Лекции (Л) Практические занятия (ПЗ) Самостоятельная работа (СР) В семестре

4 4 В соответствии с учебным рабочим планом предполагается два промежуточных контроля в конце каждого семестра. В пятом – зачет без оценки, в шестом – зачет с оценкой. Оценивание студентов на зачете осуществляется в соответствии с требованиями и критериями 100-балльной шкалы, установленными в вузе. Учитываются как результаты текущего контроля, так и знания, навыки и умения, непосредственно показанные студентами в ходе зачета. Распределение максимального числа баллов по видам работы: п/п Вид отчетностиБаллы (макс) 1Работа в семестре20 2Промежуточная аттестация20 3Зачет60 Итого:100 Оценка знаний студентов на зачете по итогам шестого семестра, полученная по 100- бальной шкале, проводится по принятой в университете методике: Количество набранных балловОценка удовлетворительно хорошо отлично Менее 51неудовлетворительно

5 Теоретические основы 1. Рациональный унифицированный процесс 2. Объектно-ориентированный подход к анализу и проектированию ИС 3. Язык UML, его назначение и особенности 4. Концепция модели в UML. Синтаксис и семантика UML 5.Представление нотаций в UML. Виды диаграмм, назначение и методика создания 5. Управление требованиями 6. Оценка рисков Практическая часть 1.Общая характеристика CASE-средства Rational Rose. Особенности реализации языка UML в CASE-инструментарии Rational Rose 2. Особенности рабочего интерфейса Rational Rose 3. Разработка учебного проекта 4. Выполнение заданий для самостоятельной работы 5. Выполнение курсового проекта 5

6 6 Основная 1.Мельников П.П. Проектный практикум: Учеб. пособие-М.: Финуниверситет, Мельников П.П., Некрылов И.И. Применение UML для проектирования информационных систем.: Учеб. пособие-М.: Финуниверситет, Дополнительная 1.Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. 2-е изд., перераб. и доп. М.: Финансы и статистика, с. 2.Вендров А.М. Проектирование программного обеспечения экономических информационных систем. Учебник. - 2-е изд., перераб. и доп. - М.: Финансы и статистика, Маслов А.В. Практикум по проектированию информационных систем в экономике: учебное пособие / А.В. Маслов, В.В. Исаков. – Томск: Изд-во Томского политехнического университета, Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно- ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, – 720 с. 5.Кватрани Т. Визуальное моделирование с помощью Rational Rose 2002 и UML: Пер, с англ. - М.: Вильямс, 2003.

7 Вопросы лекции 1. Общие сведения о проекте и процессе проектирования 2. Управление проектом 3. Жизненный цикл проект а Инициация Планирование проекта Планирование содержания проекта 4. Планирование ресурсов 7

8 Одно из самых простых определений гласит: проект это все, что имеет «начало, конец и цель». Проект это уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включающий ограничения по срокам, стоимости и ресурсам. Проект это работы, планы, мероприятия и другие задачи, направленные на создание нового продукта (устройства, работы, услуги). Выполнение проекта составляет проектную деятельность. Таким образом, когда предполагается запуск нового ПРОЕКТА – речь всегда идет о чем-то «конечном» и имеющим цель. «Разрабатывать программные продукты» – это не проект. Проект это, например, «создание и внедрение информационной системы XXY к 1 декабря следующего года». Проект включает комплект документации и материалов (определённого свойства), результат проектирования. 8

9 Проект обладает рядом свойственных ему характеристик. 1. Временность любой проект имеет четкие временные рамки, в случае, если таких рамок не имеется, деятельность называется операцией и может длиться сколь угодно долго. 2. Уникальные продукты, услуги, результаты проект должен порождать уникальные результаты, достижения, продукты. 3. Последовательная разработка любой проект развивается во времени, проходя через определенные ранее этапы или шаги, но при этом составление спецификаций проекта строго ограничивается содержанием, установленным на этапе начала. Несмотря на то, что конечный результат выполнения проекта должен быть уникален, он обладает рядом общих с процессным производством характеристик: Выполняется людьми Ограничен доступностью ресурсов Планируется, исполняется и управляется. По причине своей уникальности проектная деятельность связана с рисками. 9

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

11 11 Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации: требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования; требуемой пропускной способности системы; требуемого времени реакции системы на запрос; безотказной работы системы; необходимого уровня безопасности; простоты эксплуатации и поддержки системы. Процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

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

13 13 Любой проект имеет ограничения – это «сроки», «стоимость» и «содержание работ» проекта. Эти ограничения обычно называют тройственными и изображают в форме треугольника. Задача управления проектом сводится к тому, чтобы проект «не выскочил» за грани (сами грани согласовываются до начала работ).

14 14 Любой проект осуществляется с целью получить продукт, необходимый заказчику. Поэтому некоторые требования к управлению проектом понятны сразу же: Управление временем (необходимо уложиться в срок) Управление стоимостью (мы не должны превысить бюджет) Управление содержанием (нам нужно уточнить желания заказчика и правильно их реализовать) Другие – менее очевидны: Управление качеством Управление рисками Управление закупками (если мы используем субподрядчиков) Управление персоналом Управление коммуникациями Управление интеграцией

15 ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА 15 Начало проекта принято называть «инициацией», а окончание – «закрытием». Между этими двумя событиями располагаются (нелинейно) планирование, выполнение работ и «мониторинг и управление». Нелинейность в том, что данные процессы последовательны, но итеративны. Так, единожды спланированный проект начинает выполняться и «отслеживаться», однако по мере выполнения работ отслеживание выявляет накопившиеся «потребности в изменениях». Первоначальные планы корректируются, разработка и дальнейший мониторинг ведется уже по ним. В ходе инициации влияние принятых решений на проект очень велико, а стоимость их близка к нулю (т.е. нам ничего не стоит запланировать что-то, ибо работы еще не начинались, ничего не придется «переделывать»). Важно также понимать, что если мы ошибемся во время инициации, то чем дальше мы будем продвигаться по проекту, тем дороже будут обходится нам исправления подобных ошибок.

16 16 Входы: определен подход к управлению проектами информация по предстоящему проекту от заинтересованных лиц Выходы: спонсор утвердил руководителя проекта объявлено о запуске проекта утвержден устав проекта Устав проекта – документ, формализующий договоренности со спонсором в ходе инициации проекта. Устав проекта – это то, до чего вы договорились со спонсором. Фундаментальное свойство устава – его неизменность. Это самый стабильный документ проекта (именно потому, что он задает базовые рамки). Для чего нужен устав: устав наделяет полномочиями менеджера проекта устав фиксирует треугольник. Устав создается менеджером проекта и утверждается спонсором

17 17

18 18

19 19

20 20

21 ПЛАНИРОВАНИЕ ПРОЕКТА 21 Входы: устав проекта. Выходы: определен состав «плана управления проектом » Для чего нужны планы: Чтобы не забыть что-то существенное во время выполнения проекта Чтобы любой член команды сам, не «дергая» менеджера, в любой момент времени ПОНИМАЛ, «что ему делать сейчас» Чтобы общаться. Что необходимо помнить: План – это не «клятва», а «прогноз». Планируйте с «диапазоном». (невозможно совершенно точно прогнозировать продолжительность, а порой и состав работ. Опасайтесь раздувания оценок (padding). (Не выдавайте (и не требуйте) точную оценку там, где ее дать нельзя.) Планы будут изменяться. (На это необходимо ориентироваться сразу. В отличие от устава, единожды созданного и практически не подверженного изменениям, планы проекта – документы «живые».)

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

23 23 Возможный алгоритм планирования: Определить, как будет строиться планирование. Собрать и финализировать требования Сформировать концепцию (scope) Принять решение «что закупаем»? Определить команду Создать ИСР (иерархическую структуру работ) (WBS) Создать перечень действий (activity list) Создать сетевую диаграмму (network diagram) Оценить требуемые ресурсы Оценить продолжительность действий и стоимость Сформировать расписание Создать бюджет Планировать качество – создать метрики Создать план улучшения процессов Распределить роли и ответственности Создать план коммуникаций Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски Все повторить

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

25 25 Входы: устав проекта состав «плана управления проектом» Выходы: Реестр заинтересованных лиц Матрица требований Концепция проекта Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт. Для описания всех работ необходимо: Собрать и финализировать требования Сформировать концепцию Создать ИСР (WBS) Сбор требований. Требования, которые прописаны в Уставе проекта, являются укрупненными. Их необходимо уточнить. Для этого нужно: Выявить заинтересованных лиц. Результатом ее должен стать «реестр заинтересованных лиц».

26 26 Реестр заинтересованных лиц Даже на небольшом проекте такой реестр должен содержать десятки (или более) фамилий: 1.Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда). 2.Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта. 3.В третьих, не забывайте о боссах членов вашей команды. 4.В четвертых, это те, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние. Строки «Проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта)

27 27 ПолеАлгоритм заполнения IDУникальный идентификатор требования (st + инкремент) ИмяФамилия и имя заинтересованного лица Роль в проектеПроектная роль (пользователь, эксперт, спонсор, член команды и т.п.) ДолжностьЗанимаемая заинтересованным лицом должность Отдел / департаментПодразделение, где работает заинтересованное лицо Непосредственный начальникПрямой начальник заинтересованного лица Контактная информацияТелефон, и прочее – ВСЯ известная контактная информация Предпочитаемый вид коммуникаций Электронная почта / телефон / совещания и т.п. Главные ожиданияГлавные ожидания заинтересованного лица по проекту Главные требования Главные требования заинтересованного лица по проекту (или ID в матрице требований, если были внесены туда) Влияние на проект Влияние на проект по в баллах по шкале 1 – 10 (где 1 – минимальное влияние; 10 – максимальное влияние) Отношение к проектуПротивник / Сторонник / Нейтрал Интерес к проекту Возможно, заинтересованное лицо ХОЧЕТ принять участие в проекте как эксперт или в иной форме. КомментарийЛюбые комментарии

28 28 СБОР ТРЕБОВАНИЙ Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»». Требования формируются из ожиданий заинтересованных лиц. Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Для того, чтобы сформировать требования нужно выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований. Из наиболее распространенных методов можно выделить: Интервью Опросники Мозговые штурмы (в различных вариациях) Прототипирование Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). У этого метода много недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет. Мозговой штурм –условно можно назвать «коллективным интервью». Проведенный по определенным правилам, мозговой штурм может оказаться крайне эффективным. Прототипирование – это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (картинка, макет или какой-либо аналог).

29 29 Матрица требований Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор. По мере того, как сбор требований завершается – приступаем к их «балансировке» (т.е. оценке того, что войдет в проект). Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта. Процесс балансировки основан на сочетании интуиции и здравого смысла. Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта. Матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов. Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, мы снижаем риск «промахнуться мимо ожиданий заказчика»

30 30 Прецедент П1П1 П2П2 ПзП4П4 Требования Т1X Т2XX ТЗX Т4X Т5X

31 31 ПолеАлгоритм заполнения матрицы требований IDУникальный идентификатор требования (s + инкремент) Описание требования Подробное описание требования (функциональные и не функциональные характеристики) Автор Автор требования (т.е. тот, кто НАЗВАЛ требование команде, а не тот, кто записал названное в настоящий файл) Дата Когда требование впервые стало известно команде Документ выявления Документ, формализовавший названное требование (отчет об интервью, протокол совещания и т.д.) Статус требованияОткрыто / закрыто / отменено Заменено на (ID) Если настоящее требование изменилось – оно "закрывается" (отметка в столбце "статус требования"), заводится новое, с новым ID (он указывается и в данном столбце) Последователь чего? (ID) Если настоящее требование это результат изменения предыдущего, то в данном столбце указывается ID предшественника Спецификация (ID) Если формировался технический документ по реализации данного требования – то указать его ID Модуль Название модуля ПО, в который войдет реализуемое требования (назвать или перечислить через запятую) Дата реализации Дата внутренней приемки (внутри команды проекта) Дата приемки Дата приемки заказчиком Документ приемки (ID) Документ, подтверждающий приемку заказчиком Дополнительные комментарии Любые комментарии

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

33 33 Концепция проекта

34 34

35 35

36 36 На этом этапе работы по проекту необходимо решить ряд вопросов. Есть ли в нашей компании доступные сотрудники с нужной квалификацией? Требуется ли специфичное оборудование? Может, для выполнения каких-то работ нужна особая лицензия? Для проведения таких оценок нам потребуется хорошо спланированное содержание проекта. Необходимо решить, будут ли привлекаться субподрядчики. Некоторые из «лучших проектных практик» рекомендуют такой подход: Обязательно использовать субподряды: Если это снижает риски проекта Можно использовать субподряды: Если мы бережем (читай «испытываем дефицит») собственных ресурсов Если мы пытаемся повысить управляемость проекта Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п. Результатом определения ресурсов является список ресурсов Список ресурсов – совокупность договоренностей о выделении ресурсов на проект (обычно – в виде единого документа или набора электронных писем из корпоративной переписи). Входы: устав концепция проекта Выходы: Решение «что покупаем» (устно или письменно) Список ресурсов