1 Вопрос.

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

Методы ТКПО обеспечивают решение следующих задач:

• планирование и оценка проекта;

• анализ системных и программных требований;

• проектирование алгоритмов, структур данных и программных структур;

• кодирование;

• тестирование;

• сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

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

Процедуры определяют:

• порядок применения методов и утилит;

• формирование отчетов, форм по соответствующим требованиям;

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

• формирование «вех», по которым руководители оценивают процесс.

Стратегии конструирования ПО

• однократный проход (водопадная стратегия) – линейная последовательность этапов конструирования с определением всех требований в начале процесса;

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

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

Модели качества процессов конструирования

Классический жизненный цикл

Макетирование

Инкрементная модель

Быстрая разработка приложений (RAD - Rapid Application Development

Спиральная модель

Рисунок 1.5 – Спиральная модель, где:

1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальный требований;

4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком

2 вопрос Модели качества процессов конструирования

3 вопрос. Процесс руководства проектом

Работы, выполняемые в процессе руководства проектом

• Начало проекта

• Измерения, меры и метрики

• Процесс оценки

• Анализ риска

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

• Трассировка и контроль

Вопрос 4. Планирование проектных задач WBS – Work Breakdown

Рекомендуемое правило распределения затрат проекта – 40-20-40:

• на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ – 5%);

• на кодирование – 20%;

• на тестирование и отладку – 40%.

Вопрос 5. Предметы UML

• Структурные

• Класс (Класс реализует один или несколько интерфейсов

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

• Интерфейс .Интерфейс описывает поведение элемента, видимое извне . Интерфейс может представлять полные услуги класса или компонента или часть таких услуг . Графически интерфейс изображается в виде кружка с именем . Имя интерфейса обычно начинается с буквы «I»

• Кооперация .Кооперации имеют как структурное, так и поведенческое измерения

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

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

• Элемент Use Case (Прецедент). В модели элемент Use Case применяется для структурирования предметов поведения. Элемент Use Case реализуется кооперацией.

Изображается как эллипс, в который вписывается его имя

• Активный класс. Похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов. Изображается как активный прямоугольник, обычно включающий имя, свойства(атрибуты) и операции

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

• Узел. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Изображается как куб с именем.

• Поведения

• Взаимодействие

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

-Конечный результат

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

• Группирующие

• Пакет

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

• Пояснения

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