metoda_2013

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

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

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

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

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

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

срочность.

Анализ требований — это процесс сбора требований к системе, их систематизации, документир-ия, анализа, выявления противоречий, неполноты, разрешения конфликтов

Анализ требований

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

•Создание пользовательского интерфейса и технических прототипов;

•Анализ осуществимости требований;

•Определение приоритетов требований – определение относительных приоритетов реализации функций продукта, решаемых задач или отдельных требований. На основе приоритетов устанавливается, в какой версии будет реализована та или иная функция или набор требований. В ходе работы над проектом периодически происходит корректировка приоритетов в соответствии с потребностями клиента, условиями рынка и бизнесцелями.

90

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

•Моделирование требований – нужно сосредоточиться на наиболее сложных и опасных участках системы, а так же, где наиболее вероятны неясности и неопределённости.;

•Создание словаря терминов –определения всех элементов и структур данных, связанных с системой, что позволяет всем участникам проекта использовать согласованные определения данных;

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

10.Управление проектом. Этапы. Задачи. Треугольник проекта.

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

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

Чаще всего говорят о трех основных ограничениях(«железный треугольник»)

Содержание

91

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Время

Стоимость

Вприложении ПО добавляют четвертое ограничение – качество(приемлемое качество). В любом проекте существует функция четырех переменных: Функция(функциональность, дата сдачи(время),объем работ(стоимость), качество) = Const Варианты треугольников:

1)Содержание, сроки, бюджет

2)Содержание, сроки, стоимость

3)Содержание, сроки, ресурсы

4)Содержание, сроки, качество

5)Содержание, ресурсы, качество

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

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

Проект состоит из процессов. Процесс - это совокупность действий, приносящая результат.

Процессы Управления Проектами - касающиеся организации и описания работ проекта;

Процессы, ориентированные на продукт - касающиеся спецификации и производства продукта.

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

Процессы управления проектами могут быть разбиты на 6 основных групп:

процессы инициации - принятие решения о начале выполнения проекта;

процессы планирования - определение целей и критериев успеха проекта и разработка рабочих схем их достижения;

процессы исполнения - координация людей и других ресурсов для выполнения плана;

процессы анализа - определение соответствия плана и исполнения проекта поставленным целям и критериям и принятие решений о необходимости корректирующих воздействий;

процессы управления - определение корректирующих воздействий, их согласование, утверждение и применение;

процессы завершения - формализация выполнения

проекта и подведение его к упорядоченному финалу.

92

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Инициация

Планирование

Анализ

Завершение

PSI - число, лежащее в диапазоне 0-100, которое присваивается проектам и может быть рассчитано в любой точке жизни проекта и определяет вероятность того, что проект завершится успешно. PSI рассчитывается путем присвоения баллов каждому из Десяти Этапов, привязанных к определенному проекту.

Десять этапов руководства структурного руководства проектом;

1.Цель(Наглядное представление цели);

2.Список задач(Разработка списка задач, кот-е необходимо выполнить);

3.Один руководитель

4.Распределение людей по задачам;

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

6.Стиль руководства;

7.Знать то, что происходит;

8.Сообщать людям, что происходит;

9.Повтор этапов с 1 до 8;

10.Приз;

Создание проекта.

Трудозатраты (объем работ, работа)

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

График (затраченное время)

График - это затраченное или календарное время, за которое что-то должно быть выполнено. Измеряется в :час, день, месяц, год.

Критический путь

93

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Контрольные точки (промежуточные этапы)

Они - "вехи" проекта в специфических точках во времени. Они показывают, какая часть проекта была закончена и сколько он еще должен длиться.

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

Принятие решений в условиях неопределенности всегда связано

срисками

PMBOK(Project Management Body of Knowledge) :

Неопределенное событие или условие, которое, если осуществится, может иметь как негативное, так и позитивное влияние на итоги проекта

Риск–– Может не оказать влияния на проект

Проблема–– Уже сейчас влияет на проект

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

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

Большое количество быстро меняющихся факторов, влияющих на успех проекта

Требования пользователей

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

Рыночная конкуренция

Эволюция стандартов

Требования к безопасности

Подходы к управлению рисками

PMBOK: Количественный анализ рисков, Непрерывный процесс

Дисциплина управления рисками MSF:Основана на PMBOK, Превентивное управление рисками, Интеграция с другими компонентами MSF

eXtreme Programming: Откладывать принятие решения как можно дольше: информации для его принятия будет

больше, а возможно оно вообще не понадобится

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

Профилактика

Готовность к изменениям

Открытость

Непрерывность

94

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

2 подхода:

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

Предвидение вместо реакции на проблемы

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

Общий управляемый и воспроизводимый подход к борьбе

с возможными проблемами

Примеры рисков и их решение в XP:

Заказчик может остаться недовольным результатами и внезапно менять решение - Представитель заказчика работает в команде разработчиков каждый день

Продукт может содержать ошибки - После каждого изменения вся система подвергается юнит-тестированию

Качество кода может оказаться низким - Каждый участок программы пишется вдвоем за один компьютером – что не увидел один, заметит другой

Что нужно делать, чтобы эффективно управлять рисками?

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

Идентификация рисков

Качественная оценка рисков

Количественная оценка

Планирование реагирования на риски

Мониторинг и контроль рисков

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

95

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Шаг 1: Выявление рисков

Команда выявляет риски, которые связаны с проектом

Рассматриваются как следствия, так и причины рисков

Риски документируются в четкой и однозначной форме

Выполняется классификация (категоризация) рисков

Создается список рисков

Шаг 2: Анализ и приоритезация рисков

Приоритезация выявленных рисков

Невозможно управлять сразу всеми рисками

Существуют риски, которым необходимо уделить больше внимания

Некоторые риски имеют фатальные последствия, но крайне маловероятны

Некоторые риски очень вероятны, но их влияние на проект ничтожно

Пример: анализ риска

Риск: Если система не будет реализована и протестирована к началу соревнований, они будут сорваны

Оценка вероятности – 2 (средняя)

Угроза – 3 (высокая)

Общее влияние – 2*3 = 6

Риск попал в первую десятку

Шаг 3: Планирование рисков

Цели: Разработка планов действий по отношению к основным рискам, Внесение мероприятий по управлению рисками в расписание проекта

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

 Что можно сделать, чтобы уменьшить вероятность риска?

96

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Что можно сделать, чтобы уменьшить угрозу риска?

Уменьшений вероятности не есть избегание риска

Смягчение последствий

Если риск все-таки осуществится, надо быть готовым к этому

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

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

Триггеры - условия, которые определяют переход от профилактики к реакции на последствия:

Триггер устанавливается для каждого риска

Виды триггеров

•Событие

•Величина

Триггеры нужно контролировать

Шаг 4: Мониторинг

Цели

•Отслеживание рисков, триггеров

•Наблюдение за выполнением планов предотвращения и смягчения последствий

•Информирование членов комадны о событиях,

связанных с рисками

Шаг 5: Корректирование ситуации

Успешное выполнение планов предотвращения

Своевременное задействование планов смягчения последствий

Постоянная деятельность во время работы над проектом

Шаг 6: Извлечение опыта

Обратная связь в процессе управления рисками

Обмен опытом с другими проектными группами

Усовершенствование процесса управления рисками

Происходит на протяжении всей жизни проекта

Опыт, получаемый в результате управления рисками

Новые риски

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

Успешные стратегии предотвращения и смягчения последствий

База знаний по рискам

97

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

12. Технология SADT. Системы и модели. Пример.

SADT (аббревиатура выражения Structured Analysis and Design Technique -

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

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. В основе методологии лежит практический язык SA. Суть его в следующем: каждый блок диаграммы представляется [], в отличие от ИПД, здесь есть не только информационный поток, но и поток по управлению и механизм реализации.

Основные элементы этой методологии основываются на следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

ограничение количества блоков на каждом уровне декомпозиции (правило 3- 6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

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

98

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Типы связей между функциями

Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания:

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.

1. Тип случайной связности: наименее желательный.

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

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

3.Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

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

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

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

6.Тип последовательной связности. На диаграммах, имеющих

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

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

Организация бригады

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

авторы составляют требования, спецификации, описывают систему с помощью SADT;

комментаторы - проектировщики, которые анализируют работу авторов:

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

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

библиотекарь проекта – хранитель всех версий разработки программного продукта;

инструктор SADT – это специалист по непосредственной технологии SADT;

руководитель проекта – ответственный за разработку

Достоинства SADT:

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

99