2836

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

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

исформулировать многие решения, они проясняются и уточняются лишь впоследствии;

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

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

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

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

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

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

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

Раздел 4: " Оценка при планировании программного проекта ". –0 лекций.

Цель: дать практические навыкипо применению методов и подходовоценки планирования процесса создания ПО, планировании итерационного процесса.

Содержание:

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

-Содержание итерации и распределение вариантов использования

-Подробный план последующих итераций и критерии оценки

-Сроки/затраты на стадии уточнения

-План требуемых ресурсов на стадии конструирования и основы оценок

11

- Оценка рисков.

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

Раздел 5: "Разработка и анализ требований". – 1 лекций.

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

работать качественное ПО, удовлетворяющее реальные потребности пользователей. Успех проекта зависит от хорошо организованного управления требованиями. Ошибки в требованиях – наиболее часто встречающийся тип ошибок при разработке систем, а их устранение является наиболее дорогостоящим. Использование нескольких ключевых приемов может значительно снизить вероятность ошибок в требованиях и, следовательно, повысить качество ПО.Учитывая частоту возникновения ошибок в определении требований и эффект умножения стоимостей устранения, легко предсказать, что эти ошибки обусловят большую часть - часто 70% и более – затрат на повторную работу. Поскольку на переделки, как правило, расходуется 30-50% бюджета проекта, на устранение ошибок в определении требований может быть затрачено 25-40% всего бюджета проекта.

Раздел 6: "Управление требованиями". – 1 лекций.

Цель: дать общее представление о требованиях и управлении ими для понимания позиций заказчиков и создания систем, удовлетворяющих потребности заказчиков.

Содержание Требование – это возможность, которую должна обеспечивать система, новое свойство ПО,

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

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

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

Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений. Управление требованиями является актуальным, когда у нас существует 1000 (небольшой коммерческий проект) или 300000 (система управления самолетом Боинг 777) требований. Здесь приходится столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсов для выполнения этих различных требований. Применение методов управления требованиями связано с различными категориями программных приложений, которые существенно различаются по своей природе. Кроме того, можно рассматривать применение методов управления требованиями к системам общего вида. Важной вспомогательной конструкцией является понятие прецедента (case), описывающего серии взаимодействий пользователь/система, в результате которых пользователь решает некоторые задачи.

Раздел 7: "Архитектура ПО. Проектирование ПО". – 1 лекций.

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

Содержание Описание архитектуры – это организованное определенным образом представление архитек-

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

12

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

Типичная схема описания архитектуры включает следующие компоненты:

1.Общее представление архитектуры. 1.1.Цели

1.2.Ограничения 1.3.Степени свободы

2.Различные представления архитектуры. 2.1.Проектное представление 2.2.Представление процессов 2.3.Представление компонентов 2.4.Представление внедрения.

3.Архитектурные взаимодействия

3.1.Аспект функционирования для основных сценариев 3.2.Аспект функционирования для дополнительных сценариев 3.3.Аспект функционирования для аномальных условий

4.Производительность

5.Обоснования и соглашения

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

С точки зрения управления существуют три аспекта архитектуры6

-Архитектура – это разработка программной системы в отличие от разработки компонен-

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

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

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

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

13

Архитектурное представление – это абстракция проектной модели (информация для архитектуры).

Раздел 8: "Основы объектно-ориентированной разработки систем". – 3 лекций.

Цель: дать основы объектно-ориентированных методов и практические знания и умения использования этих методов.

Содержание

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

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

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

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

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

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

Понятия классов. Термины, типичные приемы моделирования. Создание словаря системы. Распределение обязанностей в системе, непрограммные сущности, примитивные типы.

Отношения. Термины, типичные приемы моделирования. Простые зависимости, одиночное наследование, структурные отношения.

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

Раздел 9: "Унифицированный процесс (UP) – объектно-ориентированный процесс разработки". – 6 лекций.

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

Содержание

14

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

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

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

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

Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях:

-Информационные системы масштаба предприятия

-Банковские и финансовые услуги

-Телекоммуникации

-Транспорт

-Оборонная промышленность, авиация, космонавтика

-Розничная торговля

-Медицинская электроника

-Наука

-Распределенные Web-системы

Раздел 10: «Тестирование ПО». – 3 лекций.

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

Содержание

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

-Анализ внутренне непротиворечивости и качества проектной модели

-Анализ непротиворечивости по отношению к модели требований

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

15

-Анализ изменений в текущей версии проектной модели по сравнению с предыдущими версиями (тенденции по уменьшению количества дефектов и доработок)

-Субъективное рассмотрение других составляющих качества.

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

-Анализ непротиворечивости по отношению к проектным моделям

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

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

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

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

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

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

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

-Анализ изменений в текущей версии комплекта внедрения по сравнению с предыдущими версиями.

-Субъективное рассмотрение других составляющих качества.

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

-Рабочие продукты тестирования должны создаваться параллельно с продуктом от начала до внедрения, т.е. тестирование – деятельность, присущая всему жизненному циклу

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

-Рабочие продукты тестирования реализуются в программируемом и воспроизводимом форматах (как и ПО).

-Рабочие продукты тестирования документируются тем же образом, что и сам продукт.

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

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

16

использовать методику расчета экономической эффективности проекта на основе модели жизненного цикла. Важно оценить во времени этапы жизненного цикла проекта и процессы, которые происходят в рамках его этапов. Результаты оценки целесообразно представить в виде таблицы. В связи с высокими темпами развития информационных технологий следует рассматривать более короткие промежутки времени, чем год. Длительность жизненного цикла программных продуктов от версии до версии и технических средств между последующими моделями с сопоставимыми функциональными свойствами составляет в настоящее время в пределах 1,5-2 лет. Соответственно для тех или иных этапов жизненного цикла и процессов принимаются месячные или квартальные промежутки времени в зависимости от необходимости в степени детализации проекта. Процессы затрат и возврата вложений часто совпадают во времени. Характер и объёмы их меняются.

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

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

Например, если оконный объект отображается в структуре работ для системы, поддерживающей код, требуемый для реализации процесса редактирования в данном окне, может занимать от 200 до 400 строк кода, причем скорее всего это число будет ближе к нижней границе, то итоговая оценка составит:

(200+(250*4)+400)/6=266 LOC

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

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

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

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

∙Не следует учитывать строки, содержащие комментарии.

18

∙Не следует учитывать временный код (отладочный, пробное ПО, средства тестирования, инструменты разработки и прототипирования).

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

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

нескольких проектов.

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

2.4Контрольные вопросы

1.Традиционное управление разработкой ПО.

2.Как определяется эффективность традиционного управления проектами?

3.Основные направления совершенствования экономики разработки ПО.

4.Современные принципы управления созданием ПО.

5.Стадии жизненного цикла процесса создания ПО.

6.Категории комплектов рабочих продуктов процесса

7.Контрольные точки процесса и их роль в оценке состояния.

8.Архитектура ПО, основанная на моделях. Отличительные особенности подходов.

9.Особенности планирования итерационного процесса

10.Показатели качества в проектах разработки ПО.

11.Влияние интенсивности изменений на качество ПО.

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

13.Как можно оценить ожидаемое поведение продукта на протяжении жизненного цикла?

14.Особенности современных проектов и пути решения проблем.

15.Модели стоимости следующего поколения.

16.10 важных принципов управления созданием ПО.

17.Модели оценки стоимости разрабатываемого ПО.

19

18.Значение и принципы объектного моделирования.

19.Концептуальная модель UML.

20.Классы, отношения и общие механизмы структурного моделирования.

21.Применение методов управления требованиями

22.Моделирование бизнес-процессов с использованием концепций UML.

23.Основные принципы системной инженерии.

24.Размещение требований в системной инженерии.

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

26.Управление масштабом и модели процесса разработки ПО.

27.Построение «правильной» системы.

20