Модель прогнозирования COCOMO II

Общая характеристика и классификация CASE-средств

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

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

· обследование объекта и обоснование необходимости создания ИС;

· формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

· изучение объекта автоматизации;

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

· разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

· оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

· разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

· разработка предварительных проектных решений по системе и ее частям;

· разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

· разработка проектных решений по системе и ее частям;

· разработка документации на ИС и ее части;

· разработка и оформление документации на поставку комплектующих изделий;

Стадия 6. Рабочая документация.

· разработка рабочей документации на ИС и ее части;

· разработка и адаптация программ.

Стадия 7. Ввод в действие.

· подготовка объекта автоматизации;

· подготовка персонала;

· комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

· строительно-монтажные работы;

· пусконаладочные работы;

· проведение предварительных испытаний;

· проведение опытной эксплуатации;

· проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

· выполнение работ в соответствии с гарантийными обязательствами;

· послегарантийное обслуживание.

Средства автоматизации разработки программ — (CASE-средст-ва (англ. Computer-Aided Software Engineering)) — инструменты автоматиза­ции процессов проектирования и разработки программного обеспече­ния для системного аналитика, разработчика ПО и программиста. Перво­начально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять как програм­мные средства для поддержки процессов жизненного цикла ПО.

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

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

· интеграция отдельных компонент CASE-средств, обеспечиваю­щая управляемость процессом разработки ИС;

· использование специальным образом организованного храни­лища проектных метаданных (структурированных данных, представляющих собой характеристики описываемых сущностей для их идентификации, поиска, оценки, управления ими).

Интегрированное CASE-средство (или комплекс средств, поддерживаю­щих полный жизненный цикл ПО) содержит следующие компоненты;

· репозиторий, являющийся основой CASE-средства. Он должен обес­печивать хранение версий проекта и его отдельных компонентов, синхрони­зацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечи­вость;

· графические средства анализа и проектирования, обеспечиваю­щие создание и редактирование иерархически связанных диаграмм
(DFD - Data Flow Diagrams - диаграммы потоков данных, ERD - entity-relationship Diagram - диаграмма «сущность-связь» и др.), образующих модели ИС;

· средства разработки приложений, включая языки 4GL
(4-th Generation Languages - четвертое поколение языков программирования - визуальное программирование) и генера­торы кодов;

· средства конфигурационного управления;

· средства документирования;

· средства тестирования;

· средства управления проектом;

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

Все современные CASE-средства могут быть классифицированы по ти­пам и категориям. Классификация по типам отражает функциональную ориента­цию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функ­циям и включает отдельные локальные средства, решающие небольшие автоном­ные задачи (tools), набор частично интегрированных средств, охваты­вающих большинство этапов жизненного цикла ИС (toolkit) и полно­стью интегрированные средства, поддерживающие весь жизненный цикл ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифициро­вать по следующим признакам:

· применяемым методологиям и моделям систем и БД;

· степени интегрированности с СУБД;

· доступным платформам.

Классификация по типам в основном совпадает с компонентным соста­вом CASE-средств и включает следующие основные типы:

· средства анализа, предназначенные для построения и анализа моде­лей предметной области

· средства анализа и проектирования, поддерживающие наиболее рас­пространенные методологии проектирования и использующиеся для созда­ния проектных спецификаций. Выходом таких средств являются специфика­ции компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

· средства проектирования баз данных, обеспечивающие моделирова­ние данных и генерацию схем баз данных для наиболее распростра­ненных СУБД.

· средства разработки приложений. К ним относятся средства 4GL и генераторы кодов

· средства реинжиниринга, обеспечивающие анализ программных ко­дов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.

Вспомогательные типы включают:

· средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

· средства конфигурационного управления (PVCS (Intersolv));

· средства тестирования (Quality Works (Segue Software));

· средства документирования (SoDA (Rational Software)).

На сегодняшний день Российский рынок программного обеспечения распо­лагает следующими наиболее развитыми CASE-средствами:

· Vantage Team Builder (Westmount I-CASE);

· Designer/2000;

· Silverrun;

· ERwin+BPwin;

· S-Designor;

· CASE.Аналитик.

COnstructive COst MOdel (COCOMO – модель издержек разработки) – это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом. Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов.

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

Модель COCOMO II была разработана в 1997 году, окончательно доработанная и опубликованная в 2000 году в книге «Оценка стоимости разработки ПО». Она предоставляет более полную поддержку современных процессов разработки ПО и построена на обновленной базе проектов.

COCOMO II является средним уровнем, который рассчитывает трудоемкость разработки как функцию от размера программы и множества «факторов стоимости», включающих субъективные оценки характеристик продукта, проекта, персонала и аппаратного обеспечения. Это расширение включает в себя множество из четырёх факторов, каждый из которых имеет несколько дочерних характеристик:

1. Характеристики продукта:

• требуемая надежность ПО;

• размер БД приложения;

• сложность продукта.

2. Характеристики аппаратного обеспечения:

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

• ограничения памяти;

• неустойчивость окружения виртуальной машины;

• требуемое время восстановления.

3. Характеристики персонала:

• аналитические способности;

• способности к разработке ПО;

• опыт разработки;

• опыт использования виртуальных машин;

• опыт разработки на языках программирования.

4. Характеристики проекта:

• использование инструментария разработки ПО;

• применение методов разработки ПО;

• требования соблюдения графика разработки.

Каждому из этих 15 факторов ставится в соответствие рейтинг по шести бальной шкале, начиная от «очень низкий» и до «экстра высокого» (по значению или важности фактора). Далее значения рейтинга заменяются множителями трудоемкости из нижеприведенной таблицы. Произведение всех множителей трудоемкости составляет Регулирующий фактор трудоемкости (РФТ). Обычно он принимает значения в диапазоне от 0.9 до 1.4. Коэффициенты представлены в таблице 2.

Таблица 2

Факторы стоимости	Рейтинг
Очень низкий	Низкий	Средний	Высокий	Очень высокий	Критический
Характеристики продукта
1. Требуемая надежность ПО	0.75	0.88	1.00	1.15	1.40
2. Размер БД приложения		0.94	1.00	1.08	1.16
3. Сложность продукта	0.70	0.85	1.00	1.15	1.30	1.65
Характеристики аппаратного обеспечения''''
4. Ограничения быстродействия при выполнении программы			1.00	1.11	1.30	1.66
5. Ограничения памяти			1.00	1.06	1.21	1.56
6. Неустойчивость окружения виртуальной машины		0.87	1.00	1.15	1.30
7. Требуемое время восстановления		0.87	1.00	1.07	1.15
Характеристики персонала''''
8. Аналитические способности	1.46	1.19	1.00	0.86	0.71
9. Опыт разработки	1.29	1.13	1.00	0.91	0.82
10. Способности к разработке ПО	1.42	1.17	1.00	0.86	0.70
11. Опыт использования виртуальных машин	1.21	1.10	1.00	0.90
12. Опыт разработки на языках программирования	1.14	1.07	1.00	0.95
Характеристики проекта''''
13. Применение методов разработки ПО	1.24	1.10	1.00	0.91	0.82
14. Использование инструментария разработки ПО	1.24	1.10	1.00	0.91	0.83
15. Требования соблюдения графика разработки	1.23	1.08	1.00	1.04	1.10

Формула модели COCOMO для среднего уровня принимает вид:

Е — трудоемкость разработки ПО в человеко-месяцах;

KLoC — оценочный размер программы в тысячах строках исходного кода;

РФТ — регулирующий фактор;

Коэффициенты ai и показатель степени bi представлены в таблице 3.

Таблица 3

Тип проекта	ai	bi
Органический	3.2	1.05
Полуразделенный	3.0	1.12
Встроенный	2.8	1.20

Органический (Organic mode) — маленькие команды с хорошим опытом работы и не жесткими требованиями к разработке

Полуразделенный вид (Intermediate/Semi-detached mode) — средние по размеру команды со смешанным опытом разработки и со смешанными требованиями (как жесткими, так и нет).

Встроенный вид (Intered/Embedded mode) — разрабатываются с учетом множества жестких ограничений (по аппаратному, программному, операционному обеспечению и т.д.)].

Дата добавления: 2015-03-31