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

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

Введение

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

Информационные системы стали неотъемлемой частью современных компаний. ИТ-проекты становятся все более масштабными и охватывают все части бизнеса. Как следствие, срывы и провалы ИТ-проектов приводят к значительным потерям.

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

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

Превышение бюджета по провальным ИТ-проектам составляет более 200% от плановых значений. Проблемы, возникающие при реализации ИТ-проектов, влекут за собой существенные потери прибыли и наносят удар по репутации компании. [1]

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

Недооценка времени сказывается на увеличении бюджета, а при его невозможности увеличения на качестве проекта, что считается недопустимым. Недооценка бюджета также сказывается на качестве проекта. [2]

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

неполные требования;

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

недостаточное обеспечение ресурсами;

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

и другие. [3]

Все причины напрямую связаны с планированием реализации ИТ-проектов, а именно с проектированием информационной системы и оценкой стоимости разработки.

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

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

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

- проведен аналитический обзор различных методик, позволяющих произвести расчет трудоёмкости и стоимости разработки программного продукта, и выбрана методика, которая позволяет произвести такой расчет на ранних этапах;

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

- разработан алгоритм программы, определены интерфейсы и все программно реализовано;

- проведено тестирование системы;

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

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

1. Обзор и анализ методик управления проектами и оценки трудоемкости разработки проекта, выбор и обоснование варианта решения

1.1 Обзор и анализ существующих методик управления проектами и оценки трудоёмкости

Исторически сложилось развитие методик оценки трудоемкости и стоимости разработки информационных систем в двух направлениях: измерение строк кода (SLOC) и измерение функционального размера (FPA).

С начала 80-х гг. прошлого века экспертами в области планирования ИТ-проектов был накоплен значительный опыт и разработаны эффективные подходы и методологии для оценки размера ИТ-проектов.

Наиболее популярные методы расчета сроков, затрат и рисков ИТ-проекта их положительные и отрицательные стороны представлены в таблице 1.

Таблица 1. Преимущества и недостатки популярных методов расчета

Метод расчета	Каким образом	Преимущества	Недостатки
По аналогии	Сравнить с аналогичным завершенным проектом	+ в основе лежат точные фактические данные	? сложно найти аналоги, которые имеют много общего с новым проектом
Экспертный	Спросить эксперта	+ фактические данные не нужны + применимо для уникальных проектов	? наиболее ошибочный способ расчета из-за предубеждений эксперта ? трудно определить уровень экспертизы
Подход сверху-вниз	Покомпонентное разделение системы от более крупных блоков к менее	+ результаты оценки взаимоувязаны с проектными требованиями	? нужны четкие требования ? ошибки недооценки из-за предубеждений инженеров
Подход снизу-вверх	Ответственные сотрудники оценивают отдельные блоки, сумма которых дает результат	+ высокая точность + индивидуальная ответственность за результат	? длительное время расчета ? недоучет затрат на интеграцию компонентов ? ошибки недооценки из-за предубеждений инженеров
Параметричес кие модели	Модель основывается на статистике, оценка производится за счет математических алгоритмов и настройки параметров	+ высокая скорость и простота + в основе лежит статистика тысяч завершенных проектов + результаты оценки взаимоувязаны с проектными требованиями	? риск неадекватной настройки параметров модели

Использование параметрических моделей является наиболее эффективным способом планирования ИТ-проектов, так как позволяет с высокой скоростью производить точный расчет сроков, затрат и рисков, сравнивать результаты с историческими данными своих проектов и данными, накопленными разработчиком параметрической модели. Однажды настроенная и откалиброванная модель позволяет с минимальными усилиями уточнять и адаптировать оценки по ходу исполнения проекта в быстро меняющихся условиях бизнеса. Многолетний опыт доказывает, чем дольше конкретная организация использует модель, тем точнее получаются результаты расчета. [1]

На рисунке 1.1 приведена схема эволюции методик оценки стоимости разработки информационных систем.



Рисунок 1.1. Развитие методик оценки стоимости разработки

Из мировых методик наиболее успешными и распространёнными в настоящее время являются COCOMO (Constructive Cost Model, модель издержек разработки) II и FPA IFPUG (International Function Point User Group, метод функциональных точек). Обе методики базируются на принципе оценки функционального размера:

· FPA IFPUG производит оценку функционального размера в функциональных точках;

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

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

Для оценки трудоемкости по методике IFPUG необходимо достаточно детально смоделировать структуру информационной системы, ее функции, количество интерфейсов, структуру данных и атрибуты данных. В идеальном случае, все должно происходить именно так, т.е. должен быть разработан детальный проект информационной системы. Для оценки стоимости разработки информационной системы на стадии формирования бюджета государственного заказа либо при разработке требований при использовании методики FPA IFPUG необходимо иметь техническое задание и спецификации требований к программному обеспечению. Исходя из реалий процесса заказа и разработки информационных систем, данная задача представляется практически невозможной. Наиболее часто встречается практика заказа информационных систем по следующей схеме: формируется бюджет, затем разрабатывается ТЭО, впоследствии разрабатывается техническое задание и ведется разработка информационной системы.

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

На следующей схеме (Рис. 1.2) приведены два видения процесса разработки:

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

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



Рисунок 1.2. Виды ведения процесса разработки

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

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

В профессиональных кругах несколько раз поднимали проблему оценки стоимости разработки информационных систем. Ниже приведен перечень разработанных методов и их недостатки.

Методика Министерства финансов редакции 1994 года. Методика нормирует трудозатраты по проектам (разработка и внедрению проекта функционального комплекса задач; создание очередей систем; сопровождение проекта; привязка проектов; использование ПЭВМ для отладки и ввода в действие). Основным недостатком методики, являются:

a. неясная граница между различными функциями и отдельными единицами аналогичных функций (методика не дает детального определения НИ ОДНОЙ из функций);

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

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

На II Съезде IT-Предприятий Казахстана были заявлены следующие требования к разрабатываемой методике оценки трудоемкости разработки ИС, которые позволять учесть недостатки существующих методик для применения планирования ИТ-проектов в:

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

· принципы методики должны обеспечить ее применение, как на стороне Заказчика, так и на стороне Разработчика;

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

· методика должна основываться на процессах жизненного цикла информационных систем;

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

· применение методики для оценки любых информационных систем.

· использование нотации UML, как унифицированного языка для описания требований и структуры информационной системы;

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

За период 2010-2011 годы Ассоциаций IT-компаний была разработана Методика оценки трудоемкости и стоимости разработки и сопровождения прикладного программного обеспечения при создании информационных систем (Методика CETIN: C - Case, E - Entity, T - Tool, I - Interaction, N - Node.).

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

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

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

1. Понятийный аппарат

В методике применяются понятия и термины приведенные ниже:



Актер - кто-то или что-то вне системы, но взаимодействующее с системой. Актером может быть лицо, использующее систему, или другая система, взаимодействующая с данной.
Вариант использования - описание поведения информационной системы в терминах последовательности действий, которую информационная система может выполнять в процессе взаимодействия с актерами. Каждый вариант использования предполагает достижения значимого результата для выполняющего его актера. Вариант использования используется для спецификации функциональных требований к системе.
Информационная система (ИС) - система обработки информации совместно с соответствующими организационными ресурсами, такими как технические и финансовые ресурсы, человеческие, предоставляющия и распределяющия информацию.
Класс - абстрактный тип данных в объектно-ориентированном программировании, характеризующийся своими свойствами и методами и реализующий поведение типа объектов, в том числе, типа объектов предметной области.
Модель жизненного цикла ИС - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение прикладного программного обеспечения, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.
Нормативный коэффициент трудоемкости - трудоемкость в человеко-часах реализации функциональной единицы измерения для определенного процесса разработки информационной системы.
Прикладное программное обеспечение (ППО) - программное обеспечение являющееся частью информационной системы и реализующее функциональные возможности информационной системы.
Программное обеспечение (software): Набор машинных команд, программ, процедур, функций и связанных с ними артефактов.
Развитие программного обеспечения информационной системы - процесс наращивания возможностей существующего прикладного программного обеспечения с целью изменения его первичных функций и / или добавления новых функций или изменения системной архитектуры.
Создание прикладного программного обеспечения информационной системы определяется как процесс разработки прикладного программного обеспечения, включающий следующие работы: анализ требований, проектирование, программирование, сборка, тестирование, ввод в действие и приемка.
Сопровождение прикладного программного обеспечения информационной системы - управление модификацией, миграцией и выводом из действия компонентов системы (например, ее аппаратного, программного и сетевого обеспечения и соответствующей документации) в соответствии с запросами заказчиков. Причинами таких запросов могут быть выявленная проблема или потребность в усовершенствовании или адаптации. Целью запросов могут быть модификация и / или вывод из действия существующих систем и / или программных средств при сохранении целостности деятельности организации. (ENG.2 СТ РК ИСО/МЭК ТО 15504-2).
Тип объекта - объект предметной области, обладающий уникальными свойствами состояния и поведения в рамках разрабатываемой информационной системы.
Трудоемкость определяет затраты живого труда на производство продукции. В нее включаются время выполнения работы и время регламентированных перерывов. Трудоемкость измеряется в человеко-часах или человеко-месяцах.
Узел (node) - процессор или устройство.
Функциональные единицы измерения - устанавливаемые данной методикой метрики для измерения функционального размера прикладного программного обеспечения.
Функциональный размер - размер прикладного программного обеспечения, измеряемый в функциональных единицах измерения и определяемый измерением количества функциональных требований пользователя.
UML (Unified Modeling Language) - унифицированный язык моделирования, использующий графическую нотацию и предназначенный для спецификации, конструирования и документирования систем программного обеспечения, визуализации, разрабатываемых на основе объектно-ориентированных технологий и компонентного подхода. Язык универсальный, не от конкретных языков программирования, используемых при реализации разрабатываемых систем. Он не ориентируется также на какой-либо конкретный технологический процесс разработки. UML может быть адаптирован к различным процессам.

2. Порядок оценки трудоемкости разработки прикладного программного обеспечения

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

1 этап. Оценка функционального размера

Оценка функционального размера информационной системы производится на основании модели информационной системы и функциональных требований пользователей. Функциональный размер ИС представляет собой пять функциональных единиц измерения.

2 этап. Оценка базовой трудоемкости

На данном этапе оценивается базовая трудоемкость каждого основного процесса разработки ППО ИС в человеко-месяцах. Базовая трудоемкость каждого процесса определяется на основе нормативов трудоемкости.

3 этап. Определение поправочных коэффициентов

Согласно выявленным характеристикам системы и внешним факторам по отношению к системе определяются значения поправочных коэффициентов.

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

На основании поправочных коэффициентов делается корректировка базовой трудоемкости и расчет трудоемкости разработки ИС.

5 этап. Оценка срока разработки информационной системы

На данном этапе оценивается средний срок разработки ППО ИС.

6 этап. Корректировка трудоемкости разработки ППО при уменьшении срока разработки.

На данном этапе производится корректировка трудоемкости разработки ППО ИС в случае уменьшения среднего срока разработки ППО ИС на основе коэффициента эластичности трудоемкости.

7 этап. Оценка стоимости разработки ППО

На данном этапе, на основании рассчитанной трудоемкости создания ППО ИС определяется стоимость создания ППО ИС.

3. Оценка функционального размера ИС

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

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

1) количество вариантов использования (Case) - C;

2) количество типов объектов (бизнес объектов) (Entity) - Е;

3) количество свойств типов объектов (Tool) - Т;

4) количество взаимодействий между типами объектов (Interaction) - I;

5) количество типов узлов (Node) - N.

Функциональный размер обозначается как SIZE={C, E, T, I, N}

Функциональный размер информационной системы определяется путем подсчета значений функциональных единиц измерения для модели информационной системы.

Для оценки функционального размера рекомендуется использовать модель информационной системы, реализованной на языке моделирования UML. Для применения методики желательно изначально иметь следующие диаграммы: диаграмма вариантов использования (Use case diagram, диаграмма прецедентов), диаграмма классов (Class diagram), диаграмма коммуникаций (Communication diagram) и диаграмма развертывания (Deployment diagram). Если необходимые диаграммы построены, то расчет выполняется следующим образом:

Шаг 1. Количество вариантов использования (С) определяется из диаграммы вариантов использования модели информационной системы.

Шаг 2. Количество типов объектов (E) оценивается подсчетом количества неодинаковых классов, изображенных на диаграммах классов;

Шаг 3. Количество свойств типов объектов (T) оценивается подсчетом количества свойств классов, изображенных на диаграммах классов;

Шаг 4. Количество взаимодействий между типами объектов (I) оценивается подсчетом количества связей (отношений) между классами на диаграмме коммуникаций;

Шаг 5. Количество типов узлов (N) оценивается подсчетом количества типов узлов на диаграмме развертывания.

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

4. Расчет базовой трудоемкости разработки ППО

Базовая трудоемкость создания ППО ИС {Sj, j=1-6} определяется на основе оценки трудоемкости каждого процесса разработки ППО ИС. Ниже приведен перечень основных процессов разработки ППО ИС согласно методологии RUP:

1) бизнес моделирование;

2) управление требованиями;

3) проектирование;

4) реализация;

5) тестирование;

6) развертывание.

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

Базовая трудоемкость Sj процесса разработки с номером j рассчитывается по следующей формуле:

Sj=1/165·[C*Sj(C)+E*Sj(E)+T*Sj(T)+I*Sj(I)+N*Sj(N)], (1)

где:

Sj - трудоемкость процесса разработки с номером j в [человеко-месяц];

j - номер процесса разработки (значения от 1 до 6);

Sj(C) - норматив трудоемкости реализации одного варианта использования в процессе разработки с номером j=1,2,…, 6, {[человеко-час]/[вариант использования]};

Sj(E) - норматив трудоемкости реализации одного типа объектов в процессе разработки с номером j=1,2,…, 6. {[человеко-час]/[тип объектов]};

Sj(T) - норматив трудоемкости реализации одного свойства типа объекта в процессе разработки с номером j=1,2,…, 6. {[человеко-час]/[свойство типа объектов]};

Sj(I) - норматив трудоемкости реализации одного взаимодействия между типами объектов в процессе разработки с номером j=1,2,…, 6. {[человеко-час]/[взаимодействие между типами объектов]};

Sj(N) - норматив трудоемкости реализации одного типа узла в процессе разработки с номером j=1,2,…, 6. {[человеко-час]/[узел]};

165 - количество человеко-часов в одном человеко-месяце;

{C, E, T, I, N} - функциональный размер ИС.

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

5. Определение поправочных коэффициентов к трудоемкости

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

Поправочные коэффициенты трудоемкости процессов разработки ППО ИС определяются рассчитываются по формулам (2) - (7) через частные поправочные коэффициенты разработки и сопровождения ППО:

КП1=К11·К16·К17; (2)

КП2=К1·К2·К4·К5·К6·К7·К8·К9·К16·К17·К18; (3)

КП3=К1·К2·К4·К5·К6·К7·К8·К9·К11·К12·К13·К14·К15·К16·К17·К18; (4)

КП4 = К1·К2·К4·К5·К6·К7· К8·К9·К10·К12· К13·К14·К15·К16· К17·К18; (5)

КП5=К1·К2·К4·К5·К6·К7·К8·К9·К10·К11·К12·К13·К14·К15·К16·К17·К18; (6)

КП6=К1·К2·К11·К16·К18. (7)

Перечень частных поправочных коэффициентов приведен в таблице П2.2 приложения 2.

Все частные поправочные коэффициенты являются безразмерными величинами и сгруппированы в три группы в зависимости от типов влияющих факторов:

- внутренние факторы,

- факторы среды;

- факторы данных.

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

Границы значений частных поправочных коэффициентов приведены в таблице П2.2 приложения 2.

6. Расчет трудоемкости с учетом поправочных коэффициентов

На основании поправочных коэффициентов к трудоемкости разработки ППО делается расчет трудоемкости разработки ППО с учетом поправочных коэффициентов по следующей формуле:

S=КП1*S1+КП2*S2+КП3*S3+КП4*S4+КП5*S5+КП6*S6, (8)

где:

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

Sj - базовая трудоемкость процесса разработки с номером j в человеко-месяцах;

КПj - поправочный коэффициент трудоемкости процесса разработки с номером j.

7. Оценка срока разработки информационной системы

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

Зависимость срока разработки от трудоемкости приведена в таблице П2.3 приложения 2.

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

Срок разработки ППО может быть уменьшен до минимального срока разработки. При этом посчитанная трудоемкость разработки увеличивается пропорционально коэффициенту эластичности трудоемкости из таблицы П2.4 приложения 2. Если срок разработки уменьшается на Х%, то трудоемкость разработки увеличивается на L*X%, где L - коэффициент эластичности трудоемкости.

8. Оценка стоимости разработки ППО

Определение стоимости создания ППО ИС основано на расчете средней стоимости одного человека-месяца инженера-программиста и трудоемкости создания ППО ИС.

На стоимость создания ИС влияют следующие факторы:

1) срок разработки проекта;

2) планируемое начало или конец проекта;

3) место реализации;

4) уровень ежегодной инфляции.

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

Определяется зарплата по профессии «Инженер программного обеспечения» для конкретного места реализации проекта за последний завершенный год - З_ср⁰. Далее за предыдущие три года определяется средний размер инфляции как среднеарифметическое значение трех последних законченных-И_ср. По формуле (9) определяем среднее количество лет реализации проекта:

, (9)

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

Для каждого года реализации i определяем среднемесячную номинальную заработную плату З_срⁱ по формуле (10):

, (10)

где i меняется от 1 до Г_ср.

Далее для каждого года реализации определяем соответствующую среднюю стоимость 1 человека-месяца инженера-программиста Сⁱ_ср по формуле (11):

, (11)

где:

i меняется от 1 до Г_ср;

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

П_НР - накладные расходы (аренда, командировочные, канцелярские товары, отпускные и др.) в процентах от среднемесячной заработной платы;

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

П_Р - рентабельность,

П_НДС - налог на добавленную стоимость.

Значения нормативных коэффициентов расхода разработчика (П_НР, П_РП, П_Р) приведены в таблице П2.4 приложения 2.

Определяем трудоемкость разработки ИС по годам реализации S_i по формуле (12):

S_i = S/Г_СР, (12)

где i меняется от 1 до Г_СР.

Стоимость работ на создание ППО ИС - СППО производится по формуле (13):

, (13)

9. Оценка трудоемкости и стоимости развития ППО ИС

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

10. Оценка стоимости сопровождения ППО ИС

Стоимость сопровождения ППО ИС оценивается как доля от стоимости создания текущей версии ППО. Стоимость сопровождения ППО ИС в течение одного года - ССППО определяется от стоимости создания текущей версии ППО по формуле (14):

, (14)

где:

частные поправочные коэффициенты разработки и сопровождения ППО К2, К3, К16 определяются в таблице П2.2 приложения 2,

N - коэффициент трудоемкости сопровождения ППО определяется из значений нормативных коэффициентов расхода разработчика в таблице П2.4 приложения 2. [6]

1.2 Формирование требований и выбор варианта решения

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

Оценка по методике COCOMO заключается в оценке строк кода разрабатываемой системы. Соответственно стоимость разработки можно оценить на основании реализованной системы.

Методики COCOMO и IFPUG не могут оценить стоимость разработки информационной системы на ранних этапах создания, в отличие от методики CETIN, которая применяется на этапе технико-экономического обоснования проекта создания информационной системы при планировании бюджета, что позволяет использовать её при осуществлении государственных закупок. Поэтому я выбираю методику CETIN для разработки инструментария в рамках ВКР.

2. Архитектура программного продукта и требования к платформе

В настоящей ВКР разрабатывается программное приложение для предварительного расчёта трудоёмкости и стоимости программного проекта по методике CETIN, одной из наиболее современных и формализованных методик, позволяющей на ранних стадиях проекта оценить его объём по ряду характеристик будущего продукта.

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

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

количество вариантов использования - C;

количество типов объектов - E;

количество свойств типов объектов - Т;

количество взаимодействий между типами объектов - I;

количество типов узлов - N.

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

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

Потом находится средний срок разработки и при возможности его уменьшения скорректированный срок разработки.

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

В итоге пользователь видит срок разработки ИС, стоимость разработки и стоимость сопровождения ИС.

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

Javascipt-код представляет собой обычный текстовый документ, который написан по специальным правилам.

Практически все современные браузеры поддерживают Javascript, например эти: Internet Explorer, Opera, Google Chrome, FireFox и др. В браузерах есть специальный модуль, который может обрабатывать команды, написанные на этом языке и приводить их в понятный вид. То есть никаких специальных программ для просмотра приложения не нужно.

На рисунке 2.1 показана архитектура программы.

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

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

3. Алгоритмизация и программирование

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

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

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

3.2 Программная реализация

Исходные данные берутся из предварительно составленных диаграмм на языке UML, для этого разработаны различные программы. Например, ArgoUML. Если таких диаграмм нет, то может помочь метод из приложения 1.

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

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

Код приложения заказчика находится в пункте 1 приложения 1, код приложения подрядчика - в пункте 2 приложения 1, функции JavaScript - в пункте 3 приложения 1, текст файла CSS - в пункте 4 приложения 1, код страницы инициализации - в пункте 5 приложения 1.

Для программной реализации использовались JavaScript, CSS и JQuery.

JavaScript

JavaScript - это интерпретируемый язык программирования с объектно-ориентированными возможностями. С точки зрения синтаксиса базовый язык JavaScript напоминает C, C++ и Java такими программными конструкциями, как инструкция if, цикл while и оператор &&. Однако это подобие ограничивается синтаксической схожестью. JavaScript - это нетипизированный язык, т.е. в нем не требуется определять типы переменных. Объекты в JavaScript отображают имена свойств на произвольные значения. Этим они больше напоминают ассоциативные массивы Perl, чем структуры C или объекты C++ или Java. Механизм объектно-ориентированного наследования JavaScript сильно отличается от механизма наследования в C++ и Java. Как и Perl, JavaScript - это интерпретируемый язык, и некоторые его инструменты, например регулярные выражения и средства работы с массивами, реализованы по образу и подобию языка Perl. Ядро языка JavaScript поддерживает работу с такими простыми типами данных, как числа, строки и булевы значения. Помимо этого он обладает встроенной поддержкой массивов, дат и объектов регулярных выражений. Обычно JavaScript применяется в веб-браузерах, а расширение его возможностей за счет введения объектов позволяет организовать взаимодействие с пользователем, управлять веб-браузером и изменять содержимое документа, отображаемое в пределах окна веб-браузера. Эта встроенная версия JavaScript запускает сценарии, внедренные в HTML код веб-страниц. Как правило, эта версия называется клиентским языком JavaScript, чтобы подчеркнуть, что сценарий исполняется на клиентском компьютере, а не на веб-сервере. В основе языка JavaScript и поддерживаемых им типов данных лежат международные стандарты, благодаря чему обеспечивается прекрасная совместимость между реализациями.

В соответствии со стандартом ECMA_262 язык официально называется ECMAScript. Но это несколько неудобное название используется только в случае, если необходимо явно сослаться на стандарт. Чисто технически название «JavaScript» относится только к реализации, выполненной Netscape и Mozilla Foundation. Однако на практике все предпочитают использовать это название для обозначения любой реализации JavaScript [7].

JQuery

jQuery - библиотека JavaScript, фокусирующаяся на взаимодействии JavaScript и HTML. Библиотека jQuery помогает легко получать доступ к любому элементу DOM, обращаться к атрибутам и содержимому элементов DOM, манипулировать ими.

Основной целью создания jQuery автор видел возможность закодировать многоразовые куски кода, которые позволят упростить JavaScript и использовать их так, чтобы не беспокоиться о кросс-браузерных вопросах [8].

Благодаря использованию этой библиотеки и ее возможности закодировать многоразовые куски кода, была создана функция для генерации выпадающих списков (function generateSelect). Это позволило сократить количество кода, написав её лишь один раз, появилась возможность использовать её для выбора всех частных поправочных коэффициентов в приложении. Так как приложение построено пошагово, и каждый следующий шаг аналогичен предыдущему, то с использованием этой же возможности были написаны функции, например, для создания каждого шага, для обработки кнопок «НАЗАД» и «ДАЛЕЕ».

CSS

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

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

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

Установка левого, правого, верхнего и нижнего полей элемента (блока текста контейнера HTML).

Установка отступа элемента.

Изменение размера, стиля и других атрибутов шрифта элемента.

Установка рамки вокруг элемента.

Включение фонового изображения и фонового цвета в элемент.

CSS состоит из селекторов и правил представления.

Селекторы определяют элементы HTML-документа, для которых описываются правила.

В своем приложении я использовала, например, такие селекторы, как H1 - для описания заголовка и step - для описания шагов. Внутри селектора step существует несколько псевдоклассов. От основного элемента псевдоклассы отделяются двоеточиями. Были созданы псевдоклассы шагов, для активного (текущего) шага, заголовков, содержания, кнопок в обычном состоянии, при наведении на них курсором, при нажатии на них.

3.3 Разработка интерфейса пользователя

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

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

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

Первой рассмотрим страницу инициализации.

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

Рисунок 3.3.1. Страница инициализации

Рассмотрим форму заказчика.

Расчет состоит из семи шагов, на восьмом показывается итог.

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

Первый шаг - ввод функционального размера.

Второй и третий шаги - выяснение внутренних характеристик системы.

Четвертый шаг - факторы среды.

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

Шестой шаг - скорректированный срок разработки.

Седьмой шаг - ввод заработной платы инженера-программиста, уровень инфляции за последние три года, процент социальных выплат и НДС.

Восьмой, итоговый шаг - вывод срока разработки, стоимости разработки и сопровождения.

Далее приведен интерфейс приложения заказчика.

Рисунок 3.3.2. Выбор внутренних факторов



Рисунок 3.3.3. Выбор факторов среды

Рисунок 3.3.4. Результаты расчета трудоемкости

Рисунок 3.3.5. Результаты расчета скорректированной трудоемкости



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

Рисунок 3.3.7. Результаты расчета

Рассмотрим форму подрядчика.

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

Первый шаг - ввод функционального размера.

Второй, третий и четвертый шаги - выяснение внутренних характеристик системы. Отличием является уточнение языка разработки.

Пятый шаг - факторы среды. Дополнительно выясняется готовность ИС

На шестом шаге выясняется, какое представление данных будет в ИС.

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

Восьмой шаг - скорректированная трудоемкость и срок разработки.

Девятый шаг - ввод заработной платы инженера-программиста, уровень инфляции за последние три года, процент социальных выплат и НДС.

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

Интерфейс приложения подрядчика:

Рисунок 3.3.8. Ввод функционального размера



Рисунок 3.3.9. Ввод коэффмциентов базавой трудоемкости

Рисунок 3.3.10. Выяснение внутренних характеристик системы



Рисунок 3.3.11. Факторы среды

Рисунок 3.3.12. Факторы данных



Рисунок 3.3.13. Результат расчета трудоемкости

Рисунок 3.3.14. Результат расчета скорректированной трудоемкости



Рисунок 3.3.15. Получение стоимости разработки

Рисунок 3.3.16. Результаты расчета

3.4 Разработка форм ввода параметров расчёта и статистики по собственным проектам, отчётных форм (не менее 2)

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

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

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

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

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

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

Формы ввода для начала:

ввод реальной размерности (CETIN)

ввод данных по трудоёмкости составляющих каждого процесса

ввод значений коэффициентов из предварительного расчёта (в диалоге или из базы по номеру проекта)

Запуск расчётной процедуры

Запрос вывода реальных нормативов трудоёмкости по проекту и сравнения со стандартными

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

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

Таблица 2. Статистика по собственным проектам

Исходные данные
количество вариантов использования - C	12	12
количество типов объектов - E	26	26
количество свойств типов объектов - Т	134	134
количество взаимодействий между типами объектов - I	102	102
количество типов узлов - N	4	4
Характеристики:	Коэффициент предлагаемый	Коэффициент корректированный
Режим эксплуатации ИС: обработка данных в режиме разделения времени;	1,0	1,02
Масштаб ИС: средние ИС (от 11 до 100 пользователей с длительным ЖЦ с возможностью роста до крупных систем);	1,0	1,0
Стабильность ИС: дискретное внесение изменений;	1,0	1,0
Защита от несанкционированного доступа: средняя;		1,02
Защита программ и данных (на уровне операционной системы, на уровне сетевого программного обеспечения, на уровне СУБД): средняя	1,0	1,05
Контрольный след операций: не имеется;	1,0	1,0
Отказоустойчивость: средняя;	1,0	1,0
Продолжение таблицы 2 - Статистика по собственным проектам
Восстанавливаемость: средняя;	1,0	1,0
Длительность обработки (время отклика): умеренная;	1,0	1,0
Исходный язык разработки: объектно-ориентированный (С++ или эквивалентный);	1,0	1,0
Класс пользователя: специалист(эксперт);	1,0	1,0
Требования к центральному обрабатывающему устройству (процессору): средняя;	1,0	1,0
Требования к оперативной (основной) памяти: большая;	1,0	0,7
Требования к внешней памяти: большая;	1,0	0,7
Требования к локальной вычислительной сети: высокие требования;	1,0	1,0
Критичность ИС: организационная безопасность;	1,0	1,0
Готовность: общедоступная (известная методика);	1,0	1,0
Представление данных: индексируемый	1,0	1,0
Заработная плата разработчика	60 000	60 000
Инфляция за 2013 год	6,58	6,58
Инфляция за 2014 год	6,45	6,45
Инфляция за 2015 год	11,36	11,36
Процент социальных выплат, %;	22	22
Процент НДС, %.	13	13
Итоги:
Трудоемкость, (человеко-месяцы)	216,23	231,89
Срок разработки, (месяцы)	5	4
Число разработчиков, (человек)	43	58
Стоимость разработки, (рубли)	47215115,96	50634309,49
Стоимость сопровождения, (рубли)	7082267,39	7595146,42

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

3.5 Разработка организационно-технических решений по обеспечению информационной безопасности применения продукта

В приложении подрядчика предполагается выполнять детальные расчёты трудоёмкости и стоимости продуктов, имеющие интерес для конкурентов, эта информация может быть отнесена к категории «для служебного пользования» и быть доступной только для определенных категорий работников (коммерческая тайна). Приложение заказчика доступно людям, осуществляющим заказ, но только его интерфейс и собственные данные, информация о коде так же закрыта. Поэтому система должна защищаться в соответствии со специальными требованиями и рекомендациями по технической защите конфиденциальной информации (СТР-К) ФСТЭК РФ.

При работе с приложением не предполагается межсетевое взаимодействие, работа с системами управления базами данных и взаимодействие с информационными сетями общего пользования, а так же наличие речевой информации. Разработанный программный продукт при его применении на локальном АРМ, к которому имеют доступ заказчик и исполнитель, можно отнести в соответствии с классификацией АС и требованиями по защите информации ко 2А классу систем, так как с ним последовательно работают несколько пользователей с равными или разными правами доступа (полномочиями) соответственно. Для такого класса систем должна быть составлена документация, регламентирующая порядок работы с приложением, список разрешенных пользователей.

Так как регистрации пользователей в программе нет, то использовать такие меры, как идентификация и аутентификация средствами приложения не представляется возможным, эта задача возлагается на средства операционной системы. Полезно использовать такую меру защиты, как запрет использования съёмных материальных носителей информации. Возможен так же обмен конфиденциальной информацией между АРМ только на учтенных носителях информации с учетом допуска исполнителей, работающих на АРМ, к переносимой информации, согласно пункту 5.6.3 СТР-К.