Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления

Подождите немного. Документ загружается.

Последовательность действий, которые необходимо предпринимать на протяжении

жизненного цикла проекта с целью его улучшения, может быть, например, такой:

1. Выявить и определить метрики, которые будут использоваться командой на каждой фазе,

включая:

• время, затраченное на исследование, реализацию и анализ результатов;

• размер (например, количество строк кода);

• количество дефектов, обнаруженных в модуле (например, количество строк кода) и

источник обнаружения дефекта;

• оценка качества по шкале от 1 до 10.

2. Задокументировать полученную информацию в SQAP.

3. Собирать статистику на каждой фазе.

4. Назначить разработчиков, ответственных за сбор данных на каждой фазе, например,

«ответственный за качество».

5. Спланировать обзоры полезных в дальнейшем метрических данных.

Необходимо заранее определиться с тем, какими могут быть и какими должны быть

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

компании.

2.5.3.1. Модель зрелости возможностей организации

Процесс совершенствования технологии создания ПО отражается в стратегических

планах организации, ее структуре, используемых технологиях, общей социальной культуре и

системе управления.

В начале 1990-х годов американский Институт программной инженерии (Software

Engineering Institute – SEI университета Карнеги-Меллона (г. Питтсбурге, шт. Пенсильвания,

США)) сформировал модель технологической зрелости организаций СММ (Capability

[кэпэбилити] Maturity [мэтшэрити] Model). В настоящее время на западе компания-

разработчик испытывает значительные трудности в получении заказа, если она не

аттестована по CMM.

СММ представляет собой методический материал, определяющий правила

формирования системы управления созданием и сопровождением ПО и методы

постепенного и непрерывного повышения культуры производства. Назначение СММ –

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

повышения качества процессов путем анализа степени их технологической зрелости и

факторов, в наибольшей степени влияющих на качество выпускаемой продукции. На каждом

уровне СММ устанавливаются требования, при выполнении

которых достигается

стабилизация наиболее существенных показателей процессов.

2.5.4. Процесс управления

Управление проектом – это достижение баланса между стоимостью, возможностями,

качеством и сроками. С процессом управления проектом связано несколько аспектов:

управление персоналом, составление плана-графика, оценка стоимости проекта.

2.5.4.1. Управление персоналом

Известны эмпирические данные по определению оптимального количества членов

команды.

Рисунок 8 – Зависимость эффективности команды разработчиков от ее состава

Такая зависимость приводит к необходимости использования иерархической структур

управления

Рисунок 9 – Иерархическая структура управления

Несмотря на то, что количество связей каждого сотрудника является

удовлетворительным они не участвуют в постановке задачи, что нарушает одно из главных

требований системного анализа – в обсуждении проблемы должны принимать участие

максимально возможное число стейкхолдеров.

Альтернативная схема организации коллектива сотрудников называется «команда

равных». В этом случае все участники команды находятся на

одном уровне иерархии и

между ними распределяются роли. Причем распределение ролей может меняться по

истечении определенного периода времени. Проблема увеличения числа связей в большом

проекте в этом случае решается посредством выделения роли ответственного за внешние

коммуникации.

Главный Менеджер

Отдел Маркетинга Отдел Разработки

Отдел обеспечения

качества

Руководитель

Сотрудник

Руководитель

Сотрудник

Руководитель

Сотрудник

Рисунок 10 – Структура управления типа «команда равных»

В концепции экстремального программирования, предложенной Кентом Бэком.

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

заказчика делают одним из участников разработки), стремление к радикальному упрощению

процесса разработки системы и парное программирование. Причем, при парном

программировании разработчики работают только вдвоем за одним компьютером по

очереди. Тем самым реализуется форма непрерывного инспектирования.

2.5.4.2. Подготовка плана-графика

Существует множество стандартов, описывающих создание и поддержание планов

управления программным проектом. Рекомендуется использовать стандарт IEEE 1058.1-1987

план управления программным проектом (Software Project Management Plan – SPMP).

В SPMP приводят расписание, определяющее, как и когда должны быть выполнены

различные этапы проекта. По окончании выполнения каждого последующего этапа

проектирования план-график нуждается в дополнении и корректировке.

Наиболее распространенной формой представления плана-графика проекта является

диаграмма Ганта.

1-ая итерация

2-ая итерация

Буферный период

Рисунок 11 – Примерный вид диаграммы Ганта

Рекомендуется в плане предусматривать буферные периоды, когда не планируется

выполнение никаких процессов. План-график в виде диаграммы Ганта, в большинстве

случаев, строят с помощью Microsoft Office Project.

Процесс планирования работ по выполнению проекта в частности и управления

проектом в целом связан с оценкой стоимости и длительности проекта. Эта информация

приводится в разделе 5.4. «Выделение бюджета и ресурсов» SPMP и, кроме того,

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

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

ТЗ.

2.5.4.3. Оценка затрат на создание ПС

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

проекта и продолжается даже на стадии написания программного кода.

Среди наиболее распространенных методов оценки трудоемкости выделяют

следующие:

• Алгоритмическое моделирование. Метод основан на анализе статистических данных о

ранее выполненных проектах, при этом определяется зависимость трудоемкости проекта

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

размер программного кода). Проводится оценка этого показателя для данного проекта,

после чего с помощью модели прогнозируются будущие затраты.

• Экспертные оценки. Проводится опрос нескольких экспертов по технологии разработки

ПО, знающих область применения создаваемого программного продукта. Каждый из них

дает свою оценку трудоемкости проекта. Потом все оценки сравниваются и

обсуждаются.

• Оценка по аналогии. Этот метод используется в том случае, если в данной области

применения создаваемого ПО уже реализованы аналогичные проекты. Метод основан на

сравнении планируемого проекта с предыдущими проектами, имеющими подобные

характеристики. Он использует экспертные данные или сохраненные данные о проекте.

Эксперты вычисляют высокую, низкую и наиболее вероятную оценку трудоемкости,

основываясь на различиях между новым и предыдущими проектами.

Каждый метод оценки имеет слабые и сильные стороны, поэтому в настоящее время

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

Процедура оценки трудоемкости разработки ПО состоит из следующих действий:

1) оценка размера разрабатываемого продукта;

2) оценка трудоемкости в человеко-месяцах или человеко-часах;

3) оценка продолжительности проекта в календарных месяцах;

4) оценка стоимости проекта.

Основными единицами измерения размера ПО являются:

• количество строк кода (LOC – Lines of Code);

• функциональные точки (FP – Function Points).

Методология оценивания функционального размера

Методология оценивания функционального размера (FP – Functional Points)

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

размера приложения в виде

одного числа. Затем это число можно использовать для оценки

числа строк кода, стоимости и сроков проекта.

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

информационной характеристики системы. Международная группа пользователей

функционального измерения (IFPUG – International Function Point Users Group,

www.ifpug.org) опубликовала критерии, по которым следует выделять информационные

характеристики, которые делят на пять групп:

• Внутренний

логический файл (Internal Logical File) – распознаваемая пользователем

группа логически связанных данных, которая размещена внутри приложения и

обслуживается через внешние вводы.

Приложение

ILF

ПРОЦЕСС

• Внешний интерфейсный файл (External Interface File) – распознаваемая пользователем

группа логически связанных данных, которая размещена внутри другого приложения и

поддерживается им. Внешний файл данного приложения является внутренним

логическим файлом в другом приложении.

Приложение

EIF

ПРОЦЕСС

• Внешний ввод (External Input) – элементарный процесс, перемещающий данные из

внешней среды в приложение. Данные могут поступать по каналам связи, от

пользователя с экрана ввода или из другого приложения. Данные могут использоваться

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

так и деловую информацию. Управляющие данные не должны модифицировать

внутренний логический файл (Например, поля ввода данных, сообщения об ошибках,

вычисляемые значения, кнопки).

Приложение

ILF

Данные

Управляющая

информация

• Внешний вывод (External Output) – элементарный процесс, перемещающий данные,

вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут

обновляться внутренние логические файлы. Данные создают отчеты или выходные

файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе

внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот

процесс может использовать вводимые данные, их образуют критерии поиска и

параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные

поступают извне, но носят временный характер и не сохраняются во внутреннем

логическом файле (например, поля данных в отчетах, вычисляемые значения, сообщения

об ошибках).

Приложение

Данные

Управляющая

информация

• Внешний запрос (External Query) – элементарный процесс, работающий как с

вводимыми, так и с выводимыми данными, состоящий из комбинации «запрос-ответ», но

не связанный с вычислением производных данных или обновлением ILF. Его результат –

данные, возвращаемые из внутренних логических файлов и внешних интерфейсных

файлов. Входная часть процесса не модифицирует внутренние логические файлы, а

выходная часть не несет данных, вычисляемых приложением (в этом состоит отличие

запроса от вывода). Например: вводимые элементы – поле, используемое для поиска,

щелчок мыши; выводимые элементы – отображаемые на экране поля.

Приложение

ILF

Входные/Выходные

данные

EIF

Каждой информационной характеристике ставится в соответствие сложность. Для

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

числовая оценка ранга.

К примеру, в табл. 1 приведены данные для определения ранга и оценки сложности

внешних вводов. Из данных, приведенных в табл. 1, следует, что, например, внешнему

вводу, который ссылается на 2 файла и имеет 7 элементов данных, назначается средний ранг

и оценка сложности – 4).

Таблица 5

Ранг и оценка сложности внешних вводов

Ссылки на файлы Элементы данных

1-4 5-15 >15

0-1 Низкий (3) Низкий (3) Средний (4)

2 Низкий (3) Средний (4) Высокий (6)

>2 Средний (4) Высокий (6) Высокий (6)

Таблица 6

Ранг и оценка сложности внешних выводов

Ссылки на файлы Элементы данных

1-4 5-19 >19

0-1 Низкий (4) Низкий (4) Средний (5)

2-3 Низкий (4) Средний (5) Высокий (7)

>3 Средний (5) Высокий (7) Высокий (7)

Таблица 7

Ранг и оценка сложности внешних запросов

Ссылки на файлы Элементы данных

1-4 5-19 >19

0-1 Низкий (3) Низкий (3) Средний (4)

2-3 Низкий (3) Средний (4) Высокий (6)

>3 Средний (4) Высокий (6) Высокий (6)

Таблица 8

Ранг и оценка сложности внутренних логических файлов

Типы элементов-записей Элементы данных

1-19 20-50 >50

1 Низкий (7) Низкий (7) Средний (10)

2-5 Низкий (7) Средний (10) Высокий (15)

>5 Средний (10) Высокий (15) Высокий (15)

Таблица 9

Ранг и оценка сложности внешних интерфейсных файлов

Типы элементов-записей Элементы данных

1-19 20-50 >50

1 Низкий (5) Низкий (5) Средний (7)

2-5 Низкий (5) Средний (7) Высокий (10)

>5 Средний (7) Высокий (10) Высокий (10)

При подсчете количества информационных характеристик действует правило

«однократного учета». Т.е., если, например, во внешнем запросе ссылка на файл

используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз.

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

расчету функционального размера. Исходные данные для расчета общего количества

информационных характеристик сводятся в табл. 2.

В таблицу 2 заносится количественное значение характеристики каждого вида (по

всем уровням сложности). Полученные в каждой строке значения суммируются, давая

полное значение для данной характеристики. Эти полные значения затем суммируются по

вертикали, формируя общее количество информационных характеристик.

Таблица 10

Исходные данные для вычисления общего количества информационных

характеристик

Имя характеристики

Ранг, сложность, количество

Низкий Средний Высокий Итого

Внешние вводы _ х 3 = _ х 4 = _ х 6 =

Внешние выводы _ х 4 = _ х 5 = _ х 7 =

Внешние запросы _ х 3 = _ х 4 = _ х 6 =

Внутренние логические файлы _ х 7 = _ х 10 = _ х 15 =

Внешние интерфейсные файлы _ х 5 = _ х 7 = _ х 10 =

Общее количество

Функциональный размер вычисляется по следующей формуле [22, 48, 77]

FP = Общее количество х (0,65+ 0,01 x

∑

где F

– коэффициенты сложности. Каждый коэффициент может принимать следующие

значения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 –

основное. Значение каждого i-ого коэффициента определяется эмпирически в результате

ответа на 14 вопросов, которые характеризуют системные параметры приложения (см. табл.

3).

Таблица 11

Определение системных параметров приложения

№

Системный

параметр

Описание

1 Передача данных

0 Полностью пакетная обработка на локальном ПК

5 Несколько внешних интерфейсов, более одного типа

коммуникационного протокола

Распределенная

обработка данных

0 Передача данных или процессов между компонентами системы

отсутствует

5 Динамическое выполнение процессов в любом подходящем

компоненте системы

Производительнос

ть

0 К системе не предъявляется специальных требований,

касающихся производительности

5 Время реакции или пропускная способность являются

критическими в обычное рабочее время. Кроме того, на стадиях

проектирования, разработки и (или) реализации для

удовлетворения пользовательских требований к

производительности используются специальные средства анализа

Распространеннос

ть используемой

конфигурации

0 Какие-либо явные или неявные ограничения отсутствуют

5 Заданные эксплуатационные ограничения требуют специальных

ограничений на выполнение приложения в центральном или

выделенном процессоре. Кроме того, специальные ограничения

затрагивают распределенные компоненты системы

Частота

транзакций

0 Пиковых периодов не ожидается

5 Высокая частота транзакций требует анализа

В Интернете имеются свободно распространяемые инструменты для вычисления функционального размера,

см., например, www.ifpug.org.

производительности на стадии проектирования. Кроме того, на

стадиях проектирования, разработки и (или) внедрения

необходимо использовать специальные средства анализа

производительности

Ввод данных в

режиме «on-line»

0 Все транзакции обрабатываются в пакетном режиме

5 Более 30% транзакций требуют интерактивного ввода данных

Эффективность

работы конечного

пользователя

5 Пользовательские требования к эффективности работы

(средства навигации, меню, онлайновые подсказки, документация,

видеоэффекты, всплывающие окна и т.д.) требуют применения

специальных средств для учета эргономических факторов и

процессов, демонстрирующих их выполнение

On-line

обновление

0 Отсутствует

5 Онлайновое обновление основных внутренних логических

файлов. Кроме того, большой объем данных требует учета затрат

на процесс восстановления. Требуются автоматизированные

процедуры восстановления с минимальным вмешательством

оператора

Сложность

обработки

5 экстенсивная логическая и математическая обработка,

обработка большого количества исключений, поддержка

разнородных типов входных и выходных данных

Повторная

используемость

0 Отсутствует

5 Приложение оформляется как продукт и (или) документируется

для облегчения повторного использования с возможностью

параметрической настройки приложений

Легкость

инсталляции

0 К установке не предъявляется никаких специальных

требований.

5 Заданы пользовательские требования к конвертированию

(переносу существующих данных и приложений в новую систему)

и установке, которые должны осуществляться

автоматизированными средствами

Легкость

эксплуатации

0 К эксплуатации не предъявляется никаких специальных

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

копирования

5 Наличие автоматизированных процедур запуска, копирования и

восстановления работоспособности приложения после сбоев и

ошибок

Разнообразные

условия

размещения

0 Приложение рассчитано на установку у одного пользователя

5 Приложение рассчитано на много установок для различных

платформ. Кроме того, наличие документации и планов

поддержки всех установленных копий приложения

14 Гибкость

0 Отсутствие взаимодействия с внутренними логическими

файлами

5 Интерактивное взаимодействие пользователя с управляющей

информацией, размещенной в таблицах, обновляемых в режиме

on-line

После вычисления функционального размера FP формируются метрики

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

функциональному размеру вычисляют количество строк кода.

Язык Кол-во операторов

программирования (LOC) на один FP

Ассемблер 320

С 128

Паскаль 90

С++ 64

Java 53

Visual C++ 34

Visual Basic 32

Delphi Pascal 29

Perl 21

Для оценивания затрат труда и продолжительности проекта рекомендуется

использовать конструктивную модель стоимости СОСОМО (Constructive Cost Model),

предложенную в 1981г. Барри Боэмом [48, 77]. Подмодели СОСОМО могут применяться к

трем типам программных проектов. По терминологии Боэма, их образуют:

• распространенный тип – небольшие программные проекты, над которыми работает

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

требования к проекту;

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

с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

• встроенный тип – программный проект разрабатывается в условиях жестких аппаратных,

программных и вычислительных ограничений.

Уравнения базовой подмодели COCOMO имеют вид:

Е=а x(KLOC)

[чел-мес];

D = c x (E)

[мес],

где Е – затраты в человеко-месяцах, D – время разработки, KLOC – количество тысяч строк в

программном продукте. Коэффициенты а, b, с, d определяются по табл. 4.

Таблица 12

Коэффициенты для базовой подмодели СОСОМО

Тип проекта а b c d

Распространенный 2,4 1,05 2,5 0,38

Полунезависимый 3,0 1,12 2,5 0,35

Встроенный 3,6 1,20 2,5 0,32

С целью уточнения расчетов в 1995г. Боэм ввел более совершенную модель COCOMO

II, ориентированную на применение в программной инженерии XXI века.

В состав СОСОМО II входят:

• модель композиции приложения (макетирование пользовательских интерфейсов,

взаимодействие ПО и системы);

• модель раннего этапа проектирования используется в период, когда стабилизируются

требования и определяется базисная программная архитектура;

• модель этапа пост-архитектуры используется, когда архитектура сформирована и

выполняется дальнейшая разработка ПС.

Рассмотрим уравнения пост-архитектуры подробнее:

Затраты на проектирование в человеко-месяцах:

Е=2.94 x К

req

(KLOC)

x M

+ (KLOC)

auto

[чел-мес];

где К

req

– коэффициент учитывает возможности изменения в требованиях;

req

=1+(BRAK/100)

BRAK – процент кода, модифицированного из-за изменения требований

KLOC – размер продукта

KLOC = KLOC

new

+ KLOC

reuse

где KLOC

new

– размер создаваемого программного кода;

KLOC

reuse

– размер повторно используемого программного кода.

KLOC

auto

– размер автоматически генерируемого кода.

Значение показателя B изменяется в диапазоне 1,01…1,26.

Для определения множителя поправки М

используются 17 факторов затрат:

∏

EMM

Таблица 13

Идентификация Описание коэффициента Диапазон значений

RELY требуемая надежность 0.82 - 1.26

DATA размер базы данных 0.90 - 1.28

CPLX сложность продукта 0.73 - 1.74

RUSE требуемая повторная используемость 0.95 - 1.24

DOCU

документирование требований

жизненного цикла

0.81 - 1.23

TIME ограничения времени выполнения 1.00 - 1.63

STOR ограничения оперативной памяти 1.00 - 1.46

PVOL изменчивость платформы 0.87 - 1.30

АСАР возможности аналитика 1.42 - 0.71

РСАР возможности программиста 1.34 - 0.76

АPЕХ опыт работы с приложением 1.22 - 0.81

РLЕХ опыт работы с платформой 1.19 - 0.85

PCON преемственность персонала 1.29 - 0.81

LTEX опыт работы с языком и 1.20 - 0.84

TOOL

использование инструментальных

средств

1.17 - 0.78

SITE

Рассредоточенность команды

разработчиков

1.22 - 0.80

SCED требуемый график разработки 1.43 - 1.00

Для каждого фактора определяется оценка (по 6-балльной шкале).

Длительность = [3*E

(0,33+0,2(В-1,01))

]*SCEDPercentage/100 [мес],

SCEDPercentage – процент увеличения / уменьшения номинального графика.

Рассмотрим возможности этой модели в задачах анализа чувствительности

программного проекта к изменению условий разработки.

Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для

встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10

KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют

номинальные значения (показатель степени

В = 1,16) и что автоматическая генерация кода

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

программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в

месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает

с нужной аппаратной платформой.

В терминах СОСОМО II проблемную область (область применения продукта)

классифицируют как «операции с приборами» со следующим описанием: встроенная