- •Оглавление
- •Глава 1. Жизненный цикл программного обеспечения ……………………………………………43
- •Глава 2. Методические аспекты
- •Глава 3. Моделирование бизнес-процессов
- •Глава 4. Анализ и проектирование
- •Глава 5. Технологии создания программного
- •Глава 6. Оценка трудоемкости создания
- •Глава 7. Особенности современных проектов ........527
- •Предисловие
- •Введение
- •Глава 1 жизненный цикл программного обеспечения
- •Нормативно-методическое обеспечение создания по
- •Стандарт жизненного цикла по
- •Основные процессы жц по
- •Вспомогательные процессы жизненного цикла по
- •Организационные процессы жизненного цикла по
- •Взаимосвязь между процессами жц по
- •Модели жизненного цикла по
- •Каскадная модель жц
- •Итерационная модель жизненного цикла
- •Методика spmn
- •Пример процесса «управление требованиями»
- •Пример процесса «управление конфигурацией по»
- •Общие принципы проектирования систем
- •Визуальное моделирование
- •Структурные методы анализа и проектирования по
- •Метод функционального моделирования
- •Описание типов связей
- •Моделирования процессов idef3
- •Типы связей idef3
- •Типы соединений
- •Моделирование потоков данных
- •Количественный анализ диаграмм
- •Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •Моделирование данных
- •Объектно-ориентированные методы анализа и проектирования по
- •Основные принципы построения объектной модели
- •Основные элементы объектной модели
- •Значения мощности
- •Унифицированный язык моделирования uml
- •Диаграммы вариантов использования
- •Диаграммы взаимодействия
- •Диаграммы классов
- •Диаграммы состояний
- •Диаграммы деятельности
- •Диаграммы компонентов
- •Диаграммы размещения
- •Механизмы расширения uml
- •Количественный анализ диаграмм uml
- •Основные элементы языка uml
- •Основные типы связей языка uml
- •Диапазоны оценок для диаграмм uml
- •Образцы
- •Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
- •Структурный (процессный) подход к моделированию бизнес-процессов
- •Принципы процессного подхода
- •Применение диаграмм потоков данных
- •Система моделирования aris
- •Метод ericsson-penker21
- •Пример использвания процессного подхода
- •История болезни пациента
- •Спецификация структур данных
- •Построение диаграмм потоков данных нулевого и последующих уровней
- •Объектно-ориентированный подход к моделированию бизнес-процессов
- •Методика моделирования
- •Пример использования объектно-ориентированного подхода
- •Пример спецификации требований к программному обеспечению
- •Пример структурного проектирования по
- •Построение диаграмм системных процессов и диаграмм последовательностей экранных форм
- •Объектно-ориентированный анализ
- •Архитектурный анализ
- •Анализ вариантов использования
- •Объектно-ориентированное проектирование
- •Проектирование архитектуры системы
- •Проектирование элементов системы
- •Глава 5 технологии создания программного обеспечения
- •Определение технологии
- •Общие требования, предъявляемые
- •Внедрение тс по в организации
- •Общие сведения
- •Определение потребностей в тс по
- •Оценка и выбор тс по
- •Критерии оценки и выбора тс по
- •Выполнение пилотного проекта
- •Практическое внедрение тс по
- •Примеры тс по
- •Технология rup (rational unified process)
- •Технология oracle
- •Технология borland
- •Технология computer associates
- •Глава 6 оценка трудоемкости создания программного обеспечения
- •Методы оценки и их классификация
- •Методика оценки трудоемкости разработки по на основе функциональных точек
- •Определение функциональных типов
- •Определение количества и сложности функциональных типов по данным
- •Сложность ilf и eif
- •Определение количества и сложности транзакционных функциональных типов
- •Подсчет количества функциональных точек
- •Зависимость количества fp от сложности функционального типа
- •Коммуникации данных
- •Распределенная обработка данных
- •Сложность ei
- •Сложность ео
- •Производительность
- •Эксплуатационные ограничения
- •Частота транзакций
- •Ввод данных в режиме «онлайн»
- •Эффективность работы конечных пользователей1
- •Онлайновое обновление
- •Сложная обработка31
- •Повторное использование
- •Простота установки
- •Простота эксплуатации
- •Количество возможных установок на различных платформах
- •Гибкость32
- •Оценка трудоемкости разработки
- •Размер программного обеспечения в fp и loc
- •Распределение временных затрат по стадиям для маленьких и больших проектов
- •Статистические данные
- •Статистические (регрессионные) модели
- •Группа процессов
- •Определение весовых показателей вариантов использования
- •Определение технической сложности проекта
- •Определение уровня квалификации разработчиков
- •Оценка трудоемкости проекта
- •Методы, основанные на экспертных оценках
- •Метод дельфи
- •Метод декомпозиции работ
- •Средства оценки трудоемкости
- •Планирование итерационного процесса создания по
- •Глава 7 особенности современных проектов
- •Категории «безнадежных» проектов
- •Причины, порождающие «безнадежные» проекты
- •Причины разногласий между участниками проекта
- •Переговоры в «безнадежном» проекте
- •Человеческий фактор в «безнадежных» проектах
- •Процессы в «безнадежных» проектах
- •Динамика процессов
- •Контроль над продвижением проекта
- •Технология и инструментальные средства «безнадежных» проектов
- •Дополнительная литература
- •Краткий словарь терминов
- •Список основных сокращений
Методы, основанные на экспертных оценках
Подходы, основанные на экспертных оценках, применяются при отсутствии дискретных эмпирических данных. Они используют опыт и знания экспертов-практиков в различных областях. Оценки, получаемые при этом, представляют собой синтез известных результатов прошлых проектов, в которых принимал участие эксперт.
Очевидными недостатками таких методов являются зависимость оценки от мнения эксперта и тот факт, что, как правило, не существует способов проверить правильность этого мнения до тех пор, когда уже сложно что-либо исправить в том случае, если мнение эксперта окажется ошибочным. Известно, что годы практической работы не всегда переходят в высокое качество профессиональных знаний. Даже признанные эксперты иногда делают неверные догадки и предположения. На основе экспертных оценок были разработаны два метода, допускающие возможность ошибки экспертов: метод Дельфи и метод декомпозиции работ.
6.5.1.
Метод дельфи
Метод Дельфи был разработан в корпорации «Рэнд» в конце 1940-х гг. и использовался первоначально для прогнозирования будущих событий (отсюда метод и получил свое название по сходству с предсказаниями Дельфийского оракула в Древней Греции). Позднее метод использовался для принятия решений по спорным вопросам. На предварительном этапе участники дискуссии должны без обсуждения с другими ответить на ряд вопросов, относительно их мнения по спорному вопросу. Затем ответы обобщаются, табулируются и возвращаются каждому участнику дискуссии для проведения второго этапа, на котором участникам снова предстоит дать свою оценку спорного вопроса, но на этот раз, располагая мнениями других участников, полученными на первом этапе. Второй этап завершается сужением и выделением круга мнений, отражающих некоторую общую оценку проблемы. Изначально в методе Дельфи коллективное обсуждение не использовалось; обсуждение между этапами метода было впервые применено в обобщенном методе Дельфи. Метод достаточно эффективен в том случае, если необходимо сделать заключение по некоторой проблеме, а доступная информация состоит больше из «мнений экспертов», чем из строго определенных эмпирических данных.
6.5.2.
Метод декомпозиции работ
Долгое время являясь фактическим стандартом в практике разработки как программного, так и аппаратного обеспечения, метод декомпозиции работ (МДР) представляет собой способ иерархической организации элементов проекта, упрощающий задачу составления бюджета проекта и контроля за расходованием средств. Он позволяет определить, на что именно расходуются средства. Если с каждой категорией расходов, связанной с тем или иным элементом иерархии проекта, сопоставить некоторую вероятность, можно определить ожидаемую сумму расходов на разработку, начиная с некоторых структурных элементов проекта и заканчивая совокупными затратами на выполнение всего проекта. В рамках данного метода экспертные оценки применяются для составления наиболее нужных спецификаций элементов структуры проекта и для сопоставления каждому элементу определенной степени вероятности категории расходов, связанной с ним. Методы, основанные на экспертных оценках, пригодны для проектов, связанных с разработкой принципиально нового ПО, и для совокупной оценки проектов, но содержат ряд «узких мест», упомянутых выше. Кроме того, методы, основанные на экспертных оценках, плохо масштабируемы, что затрудняет масштабный анализ чувствительности. Подходы, в основу которых положен МДР, хорошо пригодны для планирования и управления.
Метод декомпозиции работ для ПО предполагает существование двух иерархий элементов проекта. Одна из них отражает структуру ПО, другая представляет собой упорядоченные стадии разработки ПО. Иерархия структуры ПО отражает фундаментальную структуру ПО и показывает функции и местоположение каждого элемента в рамках ПО. Иерархия стадий разработки показывает основные этапы, связанные с разработкой данного компонента ПО.
Наряду с процессом оценки МДР широко применяется для расчета себестоимости разработки ПО. Каждому элементу иерархий МДР можно приписать свой бюджет и уровень издержек, что позволяет персоналу составлять отчеты о количестве рабочего времени, которое было затрачено на выполнение заданной задачи в рамках проекта или какого-либо компонента проекта, которые затем могут быть обобщены для административного контроля над использованием средств.
Если организация применяет МДР как стандарт для всех проектов, то с течением времени формируется ценная база данных, отражающая распределение расходов на разработку ПО. На основе этих данных может быть разработана собственная модель оценки расходов, подстроенная под практический опыт организации.
6.6.
