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

Размещено на http://www.allbest.ru

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ПОСТАНОВКА ЗАДАЧИ

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

1.2 Концептуальные требования к системе

2. МАТЕМАТИЧЕСКИЕ МЕТОДЫ И ИНСТРУМЕНТАРИЙ ДЛЯ ОЦЕНКИ ЗАТРАТ НА РЕАЛИЗАЦИЮ ПРОГРАММНОГО ПРОЕКТА

2.1 Информационная система

2.2 Классификации информационных систем

2.2.1 Классификации по архитектуре

2.2.2 Классификации по степени автоматизации

2.2.3 Классификации по характеру обработки данных

2.3 Метод согласованной оценки проекта (PERT)

2.4 Метод функциональных точек

2.5 Метод COCOMO II

3. АРХИТЕКТУРА И РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Функциональные требования

3.2 Технические требования

3.3 Структура БД

3.4 Программирование

3.5 Описание интерфейса

4. ПРИМЕРЫ РАСЧЕТОВ

4.2 Оценка затрат на разработку программы для расчета магнитного поля с использованием ИС

4.1 Оценка трудозатрат на реализацию разработанной информационной системы

ЗАКЛЮЧЕНИЯ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

программный затраты информационная система

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

После обоснования актуальности данной проблемы в работе приводится перечень и анализ существующих методов ее решения. В результате чего, из наиболее известных методов был выбран самый эффективный. Для его реализации средствами ЭВМ был создан программный комплекс, включающий в себя базу данных и WEB-приложение.

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

1 ПОСТАНОВКА ЗАДАЧИ

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

Использование программных продуктов является неотъемлемой частью быта современного человека. Постоянное использование программного обеспечения (ПО) и его моральное устаревание ведут к все большему и большему потребительскому спросу. Это в свою очередь толкает производителей к увеличению производительности путем привлечения большего количества специалистов и внедрения нового вспомогательного ПО. К вспомогательным ПО можно отнести информационные системы "Управление проектом", контроля разработки ПО, системы менеджмента и, конечно же, оценки программного обеспечения.

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

Таким образом, возникает ряд задач, которые необходимо выполнить в ходе работы: изучение используемых математических методов, разработка БД, реализация функционала ИС, адаптация интерфейса, проверка на практике (практическое применение ИС).

Коснемся используемых терминов более подробно.

Что такое программное обеспечение? Это совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ /5/. Также -- совокупность программ, процедур и правил, документации, относящихся к функционированию системы обработки данных.

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

Управление программным проектом - это процесс, направленный на его создание, поддержание работоспособности, качества и надежности.

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

водопадная модель;

спиральная модель;

Microsoft Solutions Framework (MSF);

ICONIX;

Rational Unified Process (RUP);

экстремальное программирование.

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

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

Система менеджмента /5/ - это система управления ресурсами (человеческими, финансовыми, техническими и пр.) для достижения определённых целей. Современные системы менеджмента в организациях состоят из наборов систем управления по определённому признаку, например, по типу управляемой системы. Разделение системы менеджмента организации на несколько составных систем управления производится с целью уменьшения комплексности общего управления и повышения управляемости образовавшихся подсистем. Качество управления всей организацией нередко зависит от степени взаимодействия данных (раздельных) систем управления при достижении общих целей.

Оценка - это вероятностное утверждение. Для доказательства этого приведем пример: попытаемся оценить трудоемкость добавления поля ввода телефонного номера клиента к уже существующей форме. Менеджер, наблюдающий работу программистов только со стороны, скажет, что эта работа потребует не больше 15 минут рабочего времени. Человек, умудренный программистским опытом, скажет, что эта работа может занять от 2 до 200 часов, и чтобы дать более точную оценку ему надо получить ответы на ряд вопросов:

может ли вводиться несколько номеров?

должна ли быть проверка номеров на действительность?

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

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

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

можно ли воспользоваться готовым решением?

сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя).

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

То, что наша оценка должна быть вероятностным утверждением, означает, что для нее существует некоторое распределение вероятности (рисунок 1), которое может быть очень широким (высокая неопределенность) или достаточно узким (низкая неопределенность).

 

Рисунок 1 Оценка трудозатрат

Если M -- наиболее вероятное значение, то это не означает что это хорошая оценка, поскольку вероятность того, что фактическая трудоемкость превысит эту оценку, составляет более 50%.

Стив Макконнелл /1/, чей пример приведен выше, утверждает: «Хорошей считается оценка, которая обеспечивает достаточно ясное представление реального состояния проекта и позволяет руководителю проекта принимать хорошие решения относительно того, как управлять проектом для достижения целей».

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

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

декомпозиция и сводные оценки;

оценка по аналогии;

опосредованные оценки.

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

метод согласованной оценки проекта (PERT);

метод функциональных точек;

COCOMOII.

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

1.2 Концептуальные требования к системе

Главной целью разрабатываемой информационной системы является повышение производительности организаций, занимающихся разработкой программного обеспечения. Повышение производительности достижимо путем улучшения предварительной оценки проекта. Так же производительность предприятия возможно увеличить путем верного распределения трудовых ресурсов (персонала) по задачам. Это способствует увеличению производственных мощностей по причине опытности сотрудника относительно той или иной задачи. Иными словами информационная система должна проводить оценку разрабатываемого проекта, собирать всю информацию о ходе выполнения задач и общем времени, затраченном на реализацию того или иного требования.

2 МАТЕМАТИЧЕСКИЕ МЕТОДЫ И ИНСТРУМЕНТАРИЙ ДЛЯ ОЦЕНКИ ЗАТРАТ НА РЕАЛИЗАЦИЮ ПРОГРАММНОГО ПРОЕКТА

2.1 Информационная система

В широком смысле информационная система -- это совокупность технического, программного и организационного обеспечения, а также персонала, предназначенная для того, чтобы своевременно обеспечивать надлежащих людей соответствующей информацией /5/.

Также в достаточно широком смысле трактует понятие информационной системы Федеральный закон РФ от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» /3/: «информационная система -- совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств».

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

В любом случае, основной задачей ИС является удовлетворение определенных информационных потребностей в рамках конкретной предметной области. Современные ИС де-факто немыслимы без использования баз данных и СУБД, поэтому термин «информационная система» на практике сливается по смыслу с термином «система баз данных».

В идеале в рамках предприятия должна функционировать единая корпоративная информационная система, удовлетворяющая всем существующим информационным потребностям сотрудников, служб и подразделений. Однако на практике создание такой всеобъемлющей ИС слишком затруднено или даже невозможно, вследствие чего на предприятии обычно функционируют несколько различных ИС, решающих отдельные группы задач: управление производством, финансово-хозяйственная деятельность и т.д. Часть задач бывает «покрыта» одновременно несколькими ИС, часть задач -- вовсе не автоматизирована. Такая ситуация получила название «лоскутной автоматизации» и является довольно типичной для многих предприятий /6/.

2.2 Классификации информационных систем

2.2.1 Классификации по архитектуре

По степени распределённости различают /5/:

- настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

- распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

- файл-серверные ИС (ИС с архитектурой «файл-сервер»);

- клиент-серверные ИС (ИС с архитектурой «клиент-сервер»).

В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные.

В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД (back-end), и рабочие станции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую.

В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности -- современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено -- веб-сервер с соответствующим серверным ПО.

2.2.2 Классификации по степени автоматизации

По степени автоматизации ИС делятся:

- на автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянного вмешательства персонала);

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

2.2.3 Классификации по характеру обработки данных

По характеру обработки данных ИС делятся:

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

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

Классификация по сфере применения.

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

- экономическая информационная система -- информационная система, предназначенная для выполнения функций управления на предприятии;

- медицинская информационная система -- информационная система, предназначенная для использования в лечебном или лечебно-профилактическом учреждении;

- географическая информационная система -- информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных.

Классификация по охвату задач (масштабности):

- персональная ИС предназначена для решения некоторого круга задач одного человека;

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

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

2.3 Метод согласованной оценки проекта (PERT)

Реализация метода основана на использовании собственного опыта или опыта коллег, полученного в похожих проектах /2/. Это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат.

Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис». Входом для данного метода оценки служит список элементарных пакетов работ. Для инженерного подхода нет необходимости точно знать закон распределения нашей оценки трудоемкости каждого такого элементарного пакета. Диапазон неопределенности достаточно охарактеризовать тремя оценками:

Mi -- наиболее вероятная оценка трудозатрат;

Oi -- минимально возможные трудозатраты на реализацию пакета работ; ни один риск не реализовался;

Pi -- пессимистическая оценка трудозатрат; все риски реализовались.

Оценку средней трудоемкости по каждому элементарному пакету можно определить по формуле:

Ei = (Pi + 4Mi + Oi)/6. (1)

Для расчета среднеквадратичного отклонения используется формула:

CKOi = (Pi - Oi)/6. (2)

Если наши оценки трудоемкости элементарных пакетов работ статистически независимы и не испорчены, например, необоснованным оптимизмом, то, согласно центральной предельной теореме теории вероятностей /2/ суммарная трудоемкость проекта может быть рассчитана по формуле:

Е = ? Ei. (3)

А среднеквадратичное отклонение для оценки суммарной трудоемкости будет составлять:

. (4)

Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, можно применить формулу:

(5)

Это значит, что вероятность того, что проект превысит данную оценку трудоемкости, составляет всего 5%.

Список элементарных пакетов работ, который используется при оценке трудоемкости, как правило, берется из нижнего уровня интегрированной среды разработки (ИСР) проекта /2/. Но может быть использован и накопленный опыт аналогичных разработок.

Проиллюстрием данный подход на примере проекта /2/. В Ассоциации CBOSS задачей проекта была разработка на основе стандартов J2EE общесистемного ПО для перевода рабочих мест CBOSS на новую трехзвенную архитектуру. Был разработан набор стандартных компонентов и сервисов, из которых как из конструктора можно эффективно и качественно собирать прикладные подсистемы. Высокоуровневая архитектура реализовывала стандартный паттерн MVC (рисунок 2), каждый из компонентов которого имел «точки расширения» для прикладной разработки, которые на рисунке выделены красным светом.

Такими точками расширения являлись:

пользовательский экран (UI Form), который собирался из готовых визуальных компонентов;

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

объекты (Business Obj), которые моделировали прикладную область и к которым обращались обработчики событий.

Рисунок 2 Высокоуровневая архитектура J2EE Фреймворка для разработки приложений

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

Согласно этой статистике, разработка и отладка требовала у программиста:

для одного экрана -- от 2 до 20 часов (наиболее вероятно -- 4 часа);

для одного обработчика событий -- от 4 до 32 часов (наиболее вероятно -- 8 часов);

для нового бизнес - объекта -- от 2 до 8 часов (наиболее вероятно -- 3 часа);

для добавления нового бизнес-метода -- от 2 до 26 часов (наиболее вероятно -- 6 часов).

Весь проект прикладной разработки измерялся в:

КUI -- количество пользовательских экранов;

KAct -- количество обработчиков событий;

КBO -- количество новых бизнес - объектов;

KBM -- количество новых или модифицируемых бизнес - методов.

Если новое разрабатываемое приложение содержит 20 пользовательских экранов, 60 обработчиков событий, 16 новых бизнес- объектов и 40 новых бизнес- методов, которые необходимо добавить, как в новые, так и в уже существующие бизнес - объекты, тогда, согласно нашей статистике,

ЕUI = (2 + 4*4 + 20) / 6 = 6.7 чел.*час, ЕAct = (4 + 4*8 + 32) / 6 = 11.33 чел.*час, ЕBO = (2 +4*3 + 8) / 6 = 3.7 чел.*час, EBM = (2 + 4*6 + 26) / 6 = 8.7 чел.*час,	СКОUI = (20 - 2) / 6 = 3 чел.*час, СКОAct = (32 - 4) / 6 = 4.7 чел.*час, CKOBO = (8 - 2) / 6 = 1 чел.*час, СКОBM = (26 - 2) / 6 = 4 чел.*час.

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

E=20*6.7+60*11.3+16*3.7+40*8.71220 чел.*час,

CKO=

Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, получим

Е95% = 1220 + 2 *46 ? 1300 чел.*час.

Хотя относительная погрешность в оценке трудоемкости каждой такой элементарной работы составляла десятки процентов, для реализованного проекта, в котором было 136 переменных, относительная погрешность оценки суммарной трудоемкости, сделанной по методу PERT, составила приблизительно лишь 4%.

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

Полученную оценку трудоемкости кодирования необходимо умножить на четыре, поскольку, кодирование составляет только 25% общих трудозатрат проекта. Поэтому суммарная трудоемкость проекта составит приблизительно 5200 чел.*час.

Если сотрудник занят только данным проектом, это, как правило, не означает, что он все 40 часов в неделю будет тратить на проектные работы. Тратить он будет 60-80% своего рабочего времени. Поэтому, в месяц сотрудник будет работать по проекту примерно 165 * 0.8 = 132 чел.*час/мес. Следовательно, трудоемкость проекта в человеко- месяцах составит, приблизительно 5200 / 132 ? 40.

Тогда согласно формуле Б.Боэма /5/ оптимальная продолжительность проекта составит:

T = 2.5 * (40)1/3 = 8.5 месяцев,

а средняя численность команды -- 5 человек.

Потребление ресурсов в проекте неравномерно, поэтому начинать проект должны 1-3 человека, а на стадии реализации начальная численность команды может быть увеличена в несколько раз.

2.4 Метод функциональных точек

Анализ функциональных точек -- стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов /2/. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group -- IFPUG), которая опубликовала несколько ревизий метода.

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

При анализе методом функциональных точек надо выполнить следующую последовательность шагов (рисунок 3):

определение типа оценки;

определение области оценки и границ продукта;

подсчет функциональных точек, связанных с данными;

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

определение суммарного количества не выровненных функциональных точек (UFP);

определение значения фактора выравнивания (FAV);

расчет количества выровненных функциональных точек (AFP).

Рисунок 3 Процедура анализа по методу функциональных точек

Первое, что необходимо сделать, это определить тип выполняемой оценки. Метод предусматривает оценки трех типов:

проект разработки: оценивается количество функциональности поставляемой пользователям в первом релизе продукта;

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

продукт: оценивается объем уже существующего и установленного продукта.

Второй шаг -- это определение области оценки и границ продукта. В зависимости от типа область оценки может включать:

все разрабатываемые функции (для проекта разработки);

все добавляемые, изменяемые и удаляемые функции (для проектов поддержки);

только функции, реально используемые, или все функции (при оценке продукта и/или продуктов).

Третий шаг. Границы продукта (рисунок 4) определяют:

что является «внешним» по отношению к оцениваемому продукту;

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

какие данные поддерживаются приложением, а какие -- внешние.

Рисунок 4 Границы продукта в методе функциональных точек

К логическим данным системы относятся:

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

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

Примером логических данных (информационных объектов) могут служить: клиент, счет, тарифный план, услуга.

Третий шаг -- подсчет функциональных точек, связанных с данными. Сначала определяется сложность данных по следующим показателям:

DET (data element type) -- неповторяемое уникальное поле данных, например, Имя Клиента -- 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) -- 9 DET's;

RET (record element type) -- логическая группа данных, например, адрес, паспорт, телефонный номер.

Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности (таблица 1).

Таблица 1 - Матрица сложности данных

	1-19 DET	20-50 DET	50+ DET
1 RET	Low	Low	Average
2-5 RET	Low	Average	High
6+ RET	Average	High	High

Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) (таблица 2) в зависимости от их сложности.

Для иллюстрации рассмотрим пример оценки в не выровненных функциональных точках объекта данных «Клиент» (Рисунок 5).

Таблица 2 - Оценка данных в не выровненных функциональных точках (UFP) для внутренних логических файлов (ILFs) и внешних интерфейсных файлов (EIFs)

Сложность данных	Количество UFP (ILF)	Количество UFP (EIF)
Low	7	5
Average	10	7
High	15	10

Рисунок 5 Пример оценки в не выровненных функциональных точках объекта данных «Клиент»

Объект «Клиент» содержит четыре логических группы данных, которые в совокупности состоят из 15 уникальное полей данных. Согласно матрице (таблица 1), нам следует оценить сложность этого объекта данных, как «Low». Теперь, если оцениваемый объект относится к внутренним логическим файлам, то согласно (таблице 2) его сложность будет 7 не выровненных функциональных точек (UPF). Если же объект является внешним интерфейсным файлом, то его сложность составит 5 UPF.

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

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

Транзакция -- это элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое /5/.

В методе различаются следующие типы транзакций (таблица 3):

EI (external inputs) -- внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне;

EO (external outputs) -- внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы; предполагает определенную логику обработки или вычислений информации из одного или более ILF;

EQ (external inquiries) -- внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

Таблица 3 - Основные отличия между типами транзакций.

Функция	Тип транзакции
	EI	EO	EQ
Изменяет поведение системы	О	Д	NA
Поддержка одного или более ILF	О	Д	NA
Представление информации пользователю	Д	О	О

Легенда: О -- основная; Д -- дополнительная; NA -- не применима.

Оценка сложности транзакции основывается на следующих ее характеристиках:

FTR (file type referenced) -- позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF, модифицируемых или считываемых в транзакции;

DET (data element type) -- уникальное поле данных.

Для оценки сложности транзакций служат матрицы, которые представлены в таблицах 4 и 5.

Таблица 4 - Матрица сложности внешних входных транзакций (EI)

EI	1-4 DET	5-15 DET	16+ DET
0-1 FTR	Low	Low	Average
2 FTR	Low	Average	High
3+ FTR	Average	High	High

Таблица 5 - Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ)

EO & EQ	1-5 DET	6-19 DET	20+ DET
0-1 FTR	Low	Low	Average
2-3 FTR	Low	Average	High
4+ FTR	Average	High	High

Оценка транзакций в не выровненных функциональных точках (UFP) может быть получена из таблицы 6.

Таблица 6 - Сложность транзакций в не выровненных функциональных точках (UFP)

Сложность транзакций	Количество UFP (EI & EQ)	Количество UFP (EO)
Low	3	4
Average	4	5
High	6	7

В качестве примера рассмотрим оценку управляющей транзакции (EI) для диалогового окна, задающего параметры проверки орфографии в MS Office Outlook (рисунок 6).

Рисунок 6 Диалоговое окно, управляющее проверкой орфографии в MS Office Outlook

Каждый "Check box" оценивается как 1 DET. Выпадающий список -- 1 DET. Каждая управляющая кнопка должна рассматриваться как отдельная транзакция. Например, если оценивать управляющую транзакцию по кнопке «OK», то для данной транзакции мы имеем 1 FTR и 8 DET. Поэтому, согласно таблице 4, мы можем оценить сложность транзакции, как Low. И, наконец, в соответствие с таблицей 6, данная транзакция должна быть оценена в 3 не выровненных функциональных точки (UFP).

Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ):

Помимо функциональных требований на продукт накладываются общесистемные требования, которые ограничивают разработчиков в выборе решения и увеличивают сложность разработки. Для учета этой сложности применяется фактор выравнивания (VAF). Значение фактора VAF зависит от 14 параметров, которые определяют системные характеристики продукта:

обмен данными (0 -- продукт представляет собой автономное приложение; 5 -- продукт обменивается данными по более чем одному телекоммуникационному протоколу);

распределенная обработка данных (0 -- продукт не перемещает данные; 5 -- распределенная обработка данных выполняется несколькими компонентами системы);

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

ограничения по аппаратным ресурсам (0 -- нет ограничений; 5 -- продукт целиком должен функционировать на определенном процессоре и не может быть распределен);

транзакционная нагрузка (0 -- транзакций не много, без пиков; 5 -- число транзакций велико и неравномерно, требуются специальные решения и инструменты);

интенсивность взаимодействия с пользователем (0 -- все транзакции обрабатываются в пакетном режиме; 5 -- более 30% транзакций -- интерактивные);

эргономика (эффективность работы конечных пользователей) (0 -- нет специальных требований; 5 -- требования по эффективности очень жесткие);

интенсивность изменения данных (ILF) пользователями (0 -- не требуются; 5 -- изменения интенсивные, жесткие требования по восстановлению);

сложность обработки (0 -- обработка минимальна; 5 -- требования безопасности, логическая и математическая сложность, многопоточность);

повторное использование (0 -- не требуется; 5 -- продукт разрабатывается как стандартный многоразовый компонент);

удобство инсталляции (0 -- нет требований; 5 -- установка и обновление ПО производится автоматически);

удобство администрирования (0 -- не требуется; 5 -- система автоматически самовосстанавливается);

портируемость (0 -- продукт имеет только 1 инсталляцию на единственном процессоре; 5 -- система является распределенной и предполагает установку на различные «железо» и ОС);

гибкость (0 -- не требуется; 5 -- гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

TDI = ? DI.

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

VAF = (TDI *0.01) + 0.65.

Например, если каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) + 0.65 = 1.07.

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

AFP = UFP * VAF.

Она учитывает только новую функциональность, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле:

DFP = (UFP + CFP) * VAF,

где CFP (conversion functional point) -- функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных.

Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле:

EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB),

где ADD -- функциональные точки для добавленной функциональности;

CHGA -- функциональные точки для измененных функций, рассчитанные после модификации;

VAFA -- величина фактора выравнивания рассчитанного после завершения проекта;

DEL -- объем удаленной функциональности;

VAFB -- величина фактора выравнивания, рассчитанная до начала проекта.

Суммарное влияние процедуры выравнивания лежит в пределах ±35% относительно объема рассчитанного в UFP.

Метод анализа функциональных точек ничего не говорит о трудоемкости разработки оцененного продукта. Вопрос решается просто, если компания разработчик имеет собственную статистику трудозатрат на реализацию функциональных точек. Если такой статистики нет, то для оценки трудоемкости и сроков проекта можно использовать метод COCOMOII.

2.5 Метод COCOMO II

Методика COCOMO позволяет оценить трудоемкость и время разработки программного продукта. Впервые была опубликована Бари Боэмом в 1981 году в виде результата анализа 63 проектов компании «TRW Aerospace» /2/. В 1997 методика была усовершенствована и получила название COCOMO II. Калибровка параметров производилась по 161 проекту разработки. В модели используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.

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

Формула оценки трудоемкости проекта в чел.*мес. имеет вид:

A=2.94,

E=B+0.01*

B=0.91,

где SIZE -- размер продукта в KSLOC;

EMi -- множители трудоемкости;

SFj -- факторы масштаба;

n=7 -- для предварительной оценки;

n=17 -- для детальной оценки.

Главной особенностью методики является то, что для того, чтобы оценить трудоемкость, необходимо знать размер программного продукта в тысячах строках исходного кода (KSLOC, Kilo Source Lines Of Code). Размер программного продукта может быть, например, оценен экспертами с применением метода PERT.

Если мы провели анализ продукта методом функциональных точек, то его размер может быть рассчитан с использованием собственных статистических данных или с использованием статистики по отрасли (таблица 7).

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

Язык программирования	Оценка количества строк
	Наиболее вероятная	Оптимистичная	Пессимистичная
Assembler	172	86	320
C	148	9	704
C++	60	29	178
C#	59	51	66
J2EE	61	50	100
JavaScript	56	44	65
PL/SQL	46	14	110
Visual Basic	50	14	276

Факторы масштаба

В методике используются пять факторов масштаба SF, которые определяются следующими характеристиками проекта:

PREC -- прецедентность, наличие опыта аналогичных разработок (Very Low -- опыт в продукте и платформе отсутствует; Extra High -- продукт и платформа полностью знакомы);

FLEX -- гибкость процесса разработки (Very Low -- процесс строго детерминирован; Extra High -- определены только общие цели);

RESL -- архитектура и разрешение рисков (Very Low -- риски неизвестны или не проанализированы; Extra High -- риски разрешены на 100%);

TEAM -- сработанность команды (Very Low -- формальные взаимодействия; Extra High -- полное доверие, взаимозаменяемость и взаимопомощь);

PMAT -- зрелость процессов (Very Low -- CMM Level 1; Extra High -- CMM Level 5).

Значение фактора масштаба, в зависимости от оценки его уровня, приведены в таблице 8.

Таблица 8 - Значение фактора масштаба, в зависимости от оценки его уровня

Фактор масштаба	Оценка уровня фактора
	Very Low	Low	Nominal	High	Very High	Extra High
PREC	6.20	4.96	3.72	2.48	1.24	0.00
FLEX	5.07	4.05	3.04	2.03	1.01	0.00
RESL	7.07	5.65	4.24	2.83	1.41	0.00
TEAM	5.48	4.38	3.29	2.19	1.10	0.00
PMAT	7.80	6.24	4.68	3.12	1.56	0.00

В нашу задачу не входит детальное описание метода COCOMO II, поэтому мы рассмотрим только случай предварительной оценки трудоемкости программного проекта. Для этой оценки необходимо оценить для проекта уровень семи множителей трудоемкости M:

PERS -- квалификация персонала (Extra Low -- аналитики и программисты имеют низшую квалификацию, текучесть больше 45%; Extra High -- аналитики и программисты имеют высшую квалификацию, текучесть меньше 4%);

RCPX -- сложность и надежность продукта (Extra Low -- продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется; Extra High -- продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация требуется в полном объеме);

RUSE -- разработка для повторного использования (Low -- не требуется; Extra High -- требуется последующее использование в других продуктах);

PDIF -- сложность платформы разработки (Extra Low -- специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; Extra High -- жесткие ограничения по памяти и быстродействию, платформа нестабильна);

PREX -- опыт персонала (Extra Low -- новое приложение, инструменты и платформа; Extra High -- приложение, инструменты и платформа хорошо известны);

FCIL -- оборудование (Extra Low -- инструменты простейшие, коммуникации затруднены; Extra High -- интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации);

SCED -- сжатие расписания (Very Low -- 75% от номинальной длительности; Very High -- 160% от номинальной длительности).

Влияние множителей трудоемкости в зависимости от их уровня определяется их числовыми значениями, которые представлены в матрице, приведенной ниже, (таблица 9).

Из этой таблицы, в частности, следует, если в нашем проекте низкая квалификация аналитиков, то его трудоемкость возрастет примерно в 4 раза по сравнению с проектом, в котором участвуют аналитики экстра-класса. И это не выдумки теоретиков, а отраслевая статистика!

Таблица 9 - Значения множителей трудоемкости, в зависимости от оценки их уровня

	Оценка уровня множителя трудоемкости
	Extra Low	Very Low	Low	Nominal	High	Very High	Extra High
PERS	2.12	1.62	1.26	1.00	0.83	0.63	0.5
RCPX	0.49	0.60	0.83	1.00	1.33	1.91	2.72
RUSE	n/a	n/a	0.95	1.00	1.07	1.15	1.24
PDIF	n/a	n/a	0.87	1.00	1.29	1.81	2.61
PREX	1.59	1.33	1.22	1.00	0.87	0.74	0.62
FCIL	1.43	1.30	1.10	1.0	0.87	0.73	0.62
SCED	n/a	1.43	1.14	1.00	1.00	1.00	n/a

Как было отмечено ранее, для того чтобы адекватно спланировать проект и оценить его трудоемкость, необходимо выполнить предварительное проектирование программного продукта. В результате декомпозиции мы получаем некоторое количество компонентов (N), которые составляют программный продукт.

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

PM

Простая сумма не учитывает взаимосвязи компонентов и трудозатраты на их интеграцию.

Методика COCOMO II определяет следующую последовательность вычисления трудоемкости проекта при многокомпонентной разработке.

Суммарный размер продукта рассчитывается, как сумма размеров его компонентов:

Базовая трудоемкость проекта рассчитывается по формуле:

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

На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCE:

И, наконец, итоговая трудоемкость проекта определятся по формуле:

PM=

Длительность проекта в методике COCOMO II рассчитывается по формуле:

TDEV=C*

где С = 3,67; D = 0,28;

PMNS - трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.

2.6 Анализ рассмотренных методов

Проанализировав выше изложенную информацию можно сделать следующий вывод: PERT является наиболее подходящим для реализации в информационной системе. Его неоспоримое преимущество в том, что для расчетов требуется минимальное количество машинного времени по сравнению с конкурирующими методами. Так же для использования данного метода нет необходимости создавать справочники, которые необходимо корректировать и изменять пользователю. Нет необходимости хранить строки кода разработанных проектов. Так же благодаря методу экспертной оценки можно получать точные оценки при минимальном участии сотрудников. Основное требование к данному методу оптимизированная и достаточно гибка БД, учитывающая оценки разработчиков и реальные затраты. Метод PERT позволяет нарастить статистическую информацию, в дальнейшем которую можно было бы использовать в развитии (расширении функционала) ИС.

3. АРХИТЕКТУРА И РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Функциональные требования

Для выполнения концептуальных требований, ранее изложенных в данной работе, необходимо реализовать функциональные требования, основные из которых приведены ниже :

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

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

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

вод названия проекта;

ввод подробного описания проекта;

вод названия требования;

ввод подробного описания требования;

присвоение требованию требования предка;

создание требований потомков относительно проекта;

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

присвоение классификации требованию;

присвоение уровня сложности проекта;

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

присвоение приоритетности проекта;

присвоение приоритетности требованию;

ввод информации о требованиях к проекту;

установка иерархии требований;

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

установка временного промежутка при реализации поставленной задачи;

управление и редактирование справочника сложности проектов;

управление и редактирование справочника сложности требований;

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

управление и редактирование справочника классификации требований;

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

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

построение иерархической таблицы проекта;

формирование графиков зависимости количества реализованных проектов от времени;

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

присвоение уровня доступа пользователям в информационной системе;

использование ИС множеством пользователей одновременно.

построение иерархической таблицы требований;

формирование отчета о разрабатываемом проекте;

расчет трудозатрат согласно математической модели PERT;

ввод данных об изменениях требований и проектов;

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

присвоение классификации разрабатываемому проекту;

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

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

экспорт данных из ИС в сторонние приложения Excel;

экспорт данных из ИС в текстовый файл формата txt;

расчет погрешности оценки;

вывод рассчитанной погрешности;

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

3.2 Технические требования

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

Разрабатываемая система должна иметь клиент-серверную структуру, возможность авторизации, регистрации пользователей под различными логинами и паролями. Так же необходима реализация гибкой БД, хранящей в себе информацию о пользователях, справочники, статистические данные и историю реализации того или иного проекта. В итоге целесообразнее при разработке подобной информационной системы использовать WEB-технологии и языки WEB-программирования(HTML, PHP, JAVA SCRIPT),базы данных на платформе СУБД MySQL.

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

Заполнение используемой БД будет реализовано посредством прямого внесения данных с форм и косвенного (расчетного). К расчетным данным относятся данные получаемые при помощи математической модели PERT, опирающейся на общие данные (статистические сведения), собранные при реализации проектов одной категории.

Рассмотрим технические требования подробнее.

Клиент-серверная структура. Реализовать данное требование позволят языки программирования HTML,PHP,JAVA SCRIPT, упомянутые ранее. Приложение, в котором клиента будет работать, является браузером. Серверную часть составят СУБД MySQL и ПО аналогичное Apache ( свободный web-сервер).

Персонализация в предлагаемой ИС (возможность нескольких пользователей, имеющих свои персональные данные, одновременно работать с системой), авторизация и регистрация. Для реализации данной возможности необходимо учесть в структуре БД сущность "пользователи" с различными уровнями доступа, сущность должна будет хранить персональную информацию пользователей, такую как имя, фамилию, отчество. Загрузка и выгрузка информации будет производиться при помощи SQL запросов.

Хранение статистических данных так же реализуемо структурой БД. В состав данной БД должны входить такие сущности как: требования, проекты, справочники статуса проекта, статуса требования, классификации требований, классификации проектов, приоритетности проекта, приоритетности требования, а так же сущность, хранящую данные расчетов метода PERT. Формирование таблиц, отчетов и графиков и их экспорт будет реализован при помощи языков программирования PHP, HTM, JAVA SCRIPT в отдельных пользовательских модулях. Коды программной реализации приведены в приложении.

3.3 Структура БД

Базы данных - представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) /5/.

Ранее изложенная информация позволила определить границы и структуры БД. В процессе ее разработки было рассмотрено много промежуточных вариантов, и выбран наиболее гибкий вариант структуры БД (рисунок 7). Таблица сущностей и атрибутов приведена в приложении А.

Рисунок 7 Диаграмма базы данных

На рисунке 7 изображена ER- диаграмма, состоящая из 12 сущностей:

customer- сущность заказчик, в данной сущности хранятся данные а заказчиках проектов, она состоит из 6 атрибутов:

id - тип (int) первичный ключ (классификатор) предназначенный для индексации списка заказчиков и оптимизации БД.

name - имя заказчика тип (varchar) длинна строки 20 символов. Данный атрибут предназначен для визуализации данных о заказчике, так же используется при рассылке электронных сообщений.

surname - фамилия заказчика тип (varchar) длинна строки 20 символов. Данный атрибут предназначен для визуализации данных о заказчике, так же используется при рассылке электронных сообщений.

company_name - название компании в которой работает заказчик тип (varchar) длинна строки 20 символов. Данный атрибут предназначен для визуализации данных о заказчике, так же используется при рассылке электронных сообщений.

mail - адрес электронной почты тип (varchar) длинна строки 20 символов. Данный атрибут предназначен для рассылки электронных сообщений.

tel - телефонный номер тип (int) длинна строки 20 символов. Данный атрибут предназначен для рассылки электронных сообщений используется в виде контактной информации.

project -проект основная сущность БД хранящая данные о разрабатываемых (разработанных проектах).

id - тип (int) первичный ключ (классификатор) предназначенный для индексации списка проектов и оптимизации БД.

name - название проекта тип (varchar) длинна строки 45 символов. Данный атрибут предназначен для визуализации данных о проекте, так же используется при рассылке электронных сообщений.

creation_date - дата создания, начальная дата разработки проекта тип (date), используется при расчете фактических трудозатрат на разработку проекта.

status_id - статус выполнения проекта тип (int), внешний ключ сущности status. Данный атрибут используется для связи сущностей.

customer_id - идентификационный номер заказчика тип (int), внешний ключ сущности customer. Данный атрибут используется для связи сущностей.

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

users_id - идентификационный номер пользователя ответственного за данный проект тип (int), внешний ключ сущности users. Атрибут используется для связи сущностей.

classification_project_id - классификатор проекта используется для разделений проектов по категориям тип (int). Атрибут используется для связи сущностей.

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

actual_work - значения фактических трудозатрат полученные в ходе разработки проекта тип (double). Используется при построении отчетов, графиков и таблиц.

classification_project - классификатор проекта, разделение проектов по категориям.

id - тип (int) первичный ключ (классификатор) предназначенный для индексации списка справочника категорий и оптимизации БД.

name - название категории тип (varchar) длинна строки 55 символов. Данный атрибут предназначен для визуализации данных о классификаторе.

classification - классификатор, дополнительный аргумент для определения сложности проекта тип (int) длинна строки 3 символа.

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

id - тип (int) первичный ключ (классификатор) предназначенный для индексации статистических данных и оптимизации БД.

project_id - идентификационный номер проекта к которому принадлежат статистические данные тип (int) внешний ключ. Используется для связи сущностей.

requirements_id - идентификационный номер требования относительно которого производится расчет трудозатрат тип (int) внешний ключ.

actual_work - фактические трудозатраты полученные при разработке проекта тип (double). Используется для расчета фактических трудозатрат на реализацию проекта.