- •Оглавление
- •Глава 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 особенности современных проектов
- •Категории «безнадежных» проектов
- •Причины, порождающие «безнадежные» проекты
- •Причины разногласий между участниками проекта
- •Переговоры в «безнадежном» проекте
- •Человеческий фактор в «безнадежных» проектах
- •Процессы в «безнадежных» проектах
- •Динамика процессов
- •Контроль над продвижением проекта
- •Технология и инструментальные средства «безнадежных» проектов
- •Дополнительная литература
- •Краткий словарь терминов
- •Список основных сокращений
Размер программного обеспечения в fp и loc
Тип ПО |
Размер, FP |
Размер, LOC |
Количество LOC на одну FP |
Текстовые процессоры Электронные таблицы Клиент-серверные приложения ПО баз данных Производственные приложения Крупные бизнес-приложения Крупные корпоративные приложения Крупные приложения в госучреждениях Операционные системы Системы масштаба предприятий Крупные оборонные системы |
3500 3500 7500 7500 7500 10000 25000
50000
75000 150000 250000 |
437500 437500 675000 937500 937500 1050000 2625000
5250000
11250000 18750000 25000000 |
125 125 90 125 125 105 105
105
150 125 100 |
На реализацию проектов размером в одну функциональную точку требуется один день, и они практически всегда заканчиваются успешно. Таковы, как правило, небольшие утилиты для временных нужд.
Объем в 10 функциональных точек — это типичный объем небольших приложений и дополнений, вносимых в готовые системы. Такие проекты требуют до 1 месяца работ и тоже всегда успешны.
Объем в 100 функциональных точек близок к пределам возможностей программиста-одиночки. Проект доводится до конца за 6 месяцев в 85% случаев. Эти цифры верны для современных средств разработки: 15 лет назад 15 тысяч строк занимал профессиональный интерпретатор Бейсика для MS-DOS, создать который одному человеку (среднему программисту) было не под силу.
Объем проекта в 1000 функциональных точек характерен для большинства сегодняшних коммерческих настольных и небольших клиент-серверных приложений. Заметную долю общего объема работы начинает занимать документация. Для разработки проекта необходима группа примерно из 10 программистов, проектировщиков, специалистов по управлению качеством и около года работы. Проваливается 15% подобных групповых проектов и 65% попыток программистов-одиночек. В 20% случаев не удается уложиться в срок. Перерасход средств отмечается в 25% проектов.
Для проекта объемом в 10000 функциональных точек требуется около 100 разработчиков. Остро встают вопросы организации совместной работы нескольких групп сотрудников. Работы длятся от 1,5 до 5 лет, при этом запланированные сроки чаще всего не выдерживаются. Хорошее качество системы невозможно обеспечить без использования формальной технологии тестирования. До 50% проектов заканчивается неудачей, а реализация таких проектов в одиночку вообще невозможна.
Объем в 100000 функциональных точек — пока что предел для большинства сегодняшних проектов. Это объем современных операционных систем, таких как MS Windows или IBM MVS, и крупнейших военных систем. На их создание уходит 5-8 лет. Над проектом трудятся сотни разработчиков иногда из разных стран, и эффективно координировать их работу не удается. В законченных системах много ошибок. До 65% проектов завершается провалом. Во всех успешных проектах используются системы управления конфигурацией.
Табл. 6.6 иллюстрирует различия в распределении временных затрат по стадиям жизненного цикла в случае большого и маленького проекта. Маленький проект (например, приложение Windows объемом 50000 строк исходного кода на Visual Basic, создаваемое командой из 5 человек) может потребовать 1 месяц на начальную стадию, 2 месяца на проектирование, 5 месяцев на разработку и 2 месяца на ввод в действие. Большой, сложный проект (например, бортовая программа для летательного аппарата объемом 300000 строк исходного кода, создаваемая командой из 40 человек) может потребовать 8 месяцев на начальную стадию, 14 месяцев на проектирование, 20 месяцев на разработку и 8 месяцев на ввод в действие. Сравнение долей жизненного цикла, приходящихся на каждую стадию, позволяет обнаружить очевидные различия.
Таблица 6.6
