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

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

Границы времени выполнения

· Распараллеливание задач требует согласования процессов их выполнения во времени. Для каждой из них должно быть запланировано приемлемое время решения T_proc, а также раннее T_min и позднее T_max время начала решения.

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

Распределение времени выполнения

· Рекомендуемое распределение времени выполнения проекта:///на свой усмотрение

Оценки, меры и метрики

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

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

Размерно-ориентированные метрики

· Основаны на LOC-оценках, т.е. на количестве строк в текстах программ (Lines Of Code).К числу размерно-ориентированных метрик относятся:

- производительность(Производительность = Длина [тыс. LOC]/Затраты [чел.-мес.])

- качество(Качество = Ошибки [Единиц]/Длина [тыс. LOC])

- удельная стоимость(Удельная Стоимость = Стоимость [Тыс. руб.]/Длина [LOC])

- документированность(Документированность = Страниц Документа/Длина [тыс. LOC])

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

· Размерно-ориентированные метрики:

- основаны на объективных данных;

- просты и легко вычислимы;

Недостатки:

- зависят от языка программирования;

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

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

Функционально-ориентированные метрики

· Исходят не из размера программного продукта, а из его функциональности.Оценивают:

Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей.

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

Анализ предметной области– это первый шаг этапа системного анализа, с которого начинается разработка программной системы.

В итоге:

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

- выявить цели их деятельности;

- определить набор решаемых ими задач;

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

Модели предметной области

· Анализом предметной области занимаются системные аналитики или бизнес-аналитики;

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

· Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов;

Определения

· Под системойподразумевается совокупность взаимодействующих компонентов и взаимосвязей между ними;

· Моделью Mнекоторой системы S называется информационный объект, который может быть использован для получения ответов на некоторый круг вопросов относительно S;

Цель моделирования:

· Получение ответов на эту совокупность вопросов является целью моделирования;

· Цель моделирования формулируется на самом раннем этапе разработки модели;

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

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

Виды моделей

· Формальные модели, используемые на этапе анализа предметной областиможно разделить на две группы:

- модели, зависящие от подхода к разработке (структурного или объектно-ориентированного);

- модели, не зависящие от подхода к разработке;

Методология IDEF0, синтаксис IDEF0-моделей.

Методологии IDEF

· В рамках проекта ICAM планировалась разработка семейства методологий моделирования различных аспектов функционирования систем:

- IDEF0 – методологиясоздания функциональной модели системы (основана на методе SADT Росса);

- IDEF1 – методологиясоздания информационной модели системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена);

- IDEF2 – методологиясоздания динамической модели системы;

- IDEF3 – методологиясоздания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

Синтаксис IDEF0-моделей

· Основной формой представления IDEF0-модели является диаграмма.

· Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки).

- Блоки изображают функции моделируемой системы.

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

· Функциональные блоки на диаграмме изображаются прямоугольниками, а дуги – стрелками.

Основные правила:

1. Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:

a) входные стрелки должны связываться с левой стороной блока;

b) управляющие стрелки должны связываться с верхней стороной блока;

c) выходные стрелки должны связываться с правой стороной блока;

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

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

2. В метках стрелок не должны использоваться следующие термины: функция, вход, управление, выход, механизм, вызов

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

4. Чтобы связать стрелку с меткой, следует использовать "тильду" (~)

Принцип декомпозиции

· Функции моделируемой системы могут быть разбиты на составные части и представлены в виде более подробных диаграмм (принцип декомпозиции)

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

- За этой диаграммой следует серия дочерних диаграмм, дающих детальное представление об объекте.

Состав IDEF0-модели

· IDEF0-модели состоят из трех типов документов:

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

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

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

· Эти документы имеют перекрестные ссылки друг на друга.

В методологии IDEF0 существует 6 типов отношений между блокамив пределах одной диаграммы:

- -доминирование;

- -управление;

- -выход - вход;

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

- -обратная связь по входу;

- -выход – механизм