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

Warning: require_once() [function.require-once]: Unable to allocate memory for pool. in /home/magrecor/mag.mag-records.ru/docs/includes/common.inc on line 2661

Warning: require_once() [function.require-once]: Unable to allocate memory for pool. in /home/magrecor/mag.mag-records.ru/docs/includes/common.inc on line 2662

Warning: require_once() [function.require-once]: Unable to allocate memory for pool. in /home/magrecor/mag.mag-records.ru/docs/includes/common.inc on line 2663

Fatal error: Call to undefined function filter_xss() in /home/magrecor/mag.mag-records.ru/docs/includes/common.inc on line 655

Использование горного алгоритма для оценки затрат при проектировании программных проектов Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Зубкова Т.М., Наточая Е.Н.

Оценка затрат при разработке ПО позволяет снизить вероятность принятия неверных или непринятия нужных управленческих решений, вероятность получения незапланированных результатов программных проектов. В статье проведен анализ основных подходов к решению задачи оценки стоимости программных проектов: линейного подхода, методики функциональных точек и использования эмпирических данных. Предложена методика оценки затрат при проектировании программных проектов на основе горного алгоритма . В статье описано математическое и программное обеспечение для решения поставленной задачи. Она выполняется по модели композиции приложения и модели раннего этапа проектирования. Для определения стоимости программного проекта предлагается зафиксировать цену на программы в соответствии с их группой сложности. Рассмотрены три группы сложности программных продуктов: простая (проектирование занимает до 4 месяцев), средняя (проектирование – от 4 месяцев до года), высокая (срок проектирования превышает год). Обосновано использование метода горной кластеризации для объединения программных продуктов в группы на основе схожести признаков. На основе предложенной методики разработана программная система оценки стоимости программных проектов с целью повышения объективности и оперативности решений, принимаемых разработчиками. Входными данными программной системы являются структура предприятия, техническое задание , таблица оценок элементов программных продуктов, таблица Боэма. В качестве управляющего воздействия выступает алгоритм горной кластеризации . Ресурсами, поддерживающими выполнение функций программной системы, являются аппаратное и программное обеспечение предприятия. На выходе системы формируется отчет о затратах на проектирование программного продукта.

i Надоели баннеры? Вы всегда можете отключить рекламу.

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

УДК 004.5;004.8 Дата подачи статьи: 25.08.17

DOI: 10.15827/0236-235X.031.1.134-139 2018. Т. 31. № 1. С. 134-139

ИСПОЛЬЗОВАНИЕ ГОРНОГО АЛГОРИТМА ДЛЯ ОЦЕНКИ ЗАТРАТ ПРИ ПРОЕКТИРОВАНИИ ПРОГРАММНЫХ ПРОЕКТОВ

Т.М. Зубкова 1, д.т.н. профессор, barsS7@mail.ru Е.Н. Наточая 2, к.п.н. доцент, en_ischa@mail.ru

1 Оренбургский государственный университет, просп. Победы, 13, г. Оренбург, 460018, Россия

2 Российская академия народного хозяйства и государственной службы при Президенте Российской Федерации (Оренбургский филиал), ул. Курача, 26, г. Оренбург, 460000, Россия

В статье описано математическое и программное обеспечение для решения поставленной задачи. Она выполняется по модели композиции приложения и модели раннего этапа проектирования. Для определения стоимости программного проекта предлагается зафиксировать цену на программы в соответствии с их группой сложности. Рассмотрены три группы сложности программных продуктов: простая (проектирование занимает до 4 месяцев), средняя (проектирование — от 4 месяцев до года), высокая (срок проектирования превышает год). Обосновано использование метода горной кластеризации для объединения программных продуктов в группы на основе схожести признаков.

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

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

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

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

Методы оценки стоимости программных проектов широко представлены в работах зарубежных [2-4] и российских исследователей [5-7].

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

1. Линейный подход. Определяет стоимость разработки как произведение количественной оценки трудозатрат и их удельной стоимости.

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

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

мных средств (Wideband Delphi, метод ДеМарко, SLIM, COCOMO и т.д.).

Наиболее популярной моделью для оценки стоимости разработки ПО, которая практически стала стандартом, является COCOMO (Constructive cost model — конструктивная модель стоимости), разработанная Барри Боэмом. В состав усовершенствованной модели СОСОМО II входят модели композиции приложения, раннего этапа проектирования и этапа постархитектуры.

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

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

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

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

Методика решения поставленной задачи

Суть первых двух моделей СОСОМО II состоит в следующем.

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

Объектный указатель — средство косвенного измерения ПО, для его расчета определяется количество экранов (как элементов пользовательского интерфейса), отчетов и компонентов, требуемых для построения приложения. Каждый объектный экземпляр (экран, отчет) относят к одному из трех уровней сложности — простой, средний, сложный. В свою очередь, сложность является функцией от параметров клиентских и серверных таблиц данных, которые требуются для генерации экрана (делятся на три группы: меньше 3, от 3 до 7 и больше 8), а также от количества представлений и секций, входящих в отчет (делятся на три группы: от 0 до 1, от 2 до 3 и больше 4) [7].

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

Для учета реальных условий разработки вычисляется процент повторного использования программных компонентов %REUSE и определяется количество новых объектных указателей NOP: NOP = (Объектные_ указатели)-[(100-%Д£та£)/100].

Для оценки затрат, основанных на величине NOP, надо знать скорость разработки продукта PROD. Скорость определяют с учетом уровня опытности разработчиков и зрелости среды разработки.

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

ЗАТРАТЫ = NOP/PROD [чел.-мес.], где PROD — производительность разработки, выраженная в терминах объектных указателей (значения изменяются от 4 до 50).

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

Основное уравнение этой модели имеет следующий вид:

ЗАТРАТЫ = АРАЗМЕРВ -Ме + ЗАТРАТЫа1йо [чел.-мес.],

где масштабный коэффициент А = 2,5; показатель В отражает нелинейную зависимость затрат от размера проекта (размер системы РАЗМЕР выражается в тысячах LOC- количестве строк текста ПО); множитель поправки Me зависит от 7 формирователей затрат, характеризующих продукт, процесс и персонал; слагаемое ЗАТРАТЫ^ отражает за-

траты на автоматически генерируемый программный код.

Значение показателя степени В изменяется в диапазоне 1,01, . 1,26, зависит от пяти масштабных факторов Wi и вычисляется по формуле

Масштабные факторы отражают следующее:

— предыдущий опыт организации в реализации проектов этого типа;

— степень гибкости процесса разработки;

— степень выполняемого анализа риска;

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

— зрелость процесса в организации.

Оценки принимают 6 значений: от очень низкой

(5) до сверхвысокой (0).

Множитель поправки Мe зависит от набора формирователей затрат.

Для каждого формирователя затрат определяется оценка (по 6-балльной шкале), где 1 соответствует очень низкому значению, а 6 — сверхвысокому. На основе оценки для каждого формирователя по таблице Боэма определяется множитель затрат EMi. К ним относятся возможности персонала, надежность и сложность продукта, требуемое повторное использование, трудность платформы, опытность персонала, средства поддержки, график работ.

Перемножение всех множителей затрат форми-

рует множитель поправки: ме = ^ ЕМ1.

Слагаемое ЗАТРАТЫ^ используется, если некоторый процент программного кода генерируется автоматически. Поскольку производительность такой работы значительно выше, чем при ручной разработке кода, требуемые затраты вычисляются отдельно по следующей формуле:

ЗАТРАТЫа1йо = (KALOG■(AT/100))/ATPROD, где KALOC — количество строк автоматически генерируемого кода (в тысячах строк); AT — процент автоматически генерируемого кода (от всего кода системы); ATPROD — производительность автоматической генерации кода.

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

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

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

свыше этого срока, но менее года, то ПП попадает в группу средней сложности. В группу высокой сложности попадают ПП со сроком, превышающим год.

Для объединения ПП в группы на основе схожести признаков авторы предлагают использовать метод горной кластеризации, предложенный Яге-ром (Yager) и Филевым (Filev) в 1993 г. Особенностью алгоритма является то, что он не требует задания количества кластеров. Выбор горного алгоритма кластеризации обусловливается его достаточно высокой скоростью выполнения и хорошей точностью.

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

На первом шаге горной кластеризации определяют точки, которые могут быть центрами кластеров. Для алгоритма горной кластеризации число потенциальных центров кластеров (Q) должно быть конечным. Такими центрами могут быть как объекты кластеризации (строчки матрицы X), так и особые точки факторного пространства. В последнем случае диапазоны изменения входных признаков разбивают на несколько интервалов. Проведя через точки разбиения прямые, параллельные координатным осям, получаем решеточный гиперкуб. Узлы этой решетки и будут соответствовать центрам потенциальных кластеров. Обозначим через qr количество значений, которые могут принимать центры кластеров по r-й координате, r = 1, . n. Тогда количество возможных кластеров будет следующим: Q = q\, q2, . qn.

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

формуле P(Zh ) = £ exp(-a • D(Zh, Xk )),

где Zh = (zi,h, z2,h, h-го кластера, h = 1

Zn,h) — потенциальный центр ., Q; а — положительная константа; D (Zh, Хк) — расстояние между потенциальным центром кластера ^и) и объектом кластеризации (Хк). В евклидовом пространстве это расстояние рассчитывается по формуле

В данном случае Z — множество затрат, выраженных в человеко-часах, которые выбраны как потенциальные центры кластеров; X — простые объекты кластеризации, то есть затраты, не выбранные как потенциальные центры кластеров.

На третьем шаге итерационно выбираются центры кластеров среди точек с максимальными потенциалами — координаты «горных вершин». Центром первого кластера назначают точку с наибольшим потенциалом. Обычно наивысшая вершина

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

P2(Zh ) = Pl(Zh ) — Pl(Vl) ■ exp(-ß-D(Zh ,V)),

Zh * Vx, h = 1, . Q, где P1 — потенциал на 1-й итерации; Р2 — потенциал на 2-й итерации; ß — положительная константа; V — центр первого найденного кластера:

Затем снова пересчитываем значения потенциалов: P3(Zh ) = P2(Zh ) — P2(V2) ■ exp(-ß-D(Zh,VJ),

Zh * V1, Zh * V2, h = 1, . Q.

Итерационная процедура выделения центров кластеров продолжается до тех пор, пока максимальное значение потенциала превышает некоторый порог. Кластеризация по горному алгоритму не является нечеткой, однако ее часто используют при синтезе нечетких правил из данных [9].

Результаты реализации поставленной задачи

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

На рынке ПО существует целый ряд как коммерческих, так и бесплатных инструментов оценки программных проектов. Среди них наибольшей популярностью пользуются Duvessa Estimate Easy UC, USC COCOMO Tool, SoftStar Systems Costar, Construx Estimate, Borland CaliberRM Estimate Professional, CostXpert.

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

Начальным этапом разработки автоматизированной системы расчета затрат на программные

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

— структура предприятия: реквизиты предприятия;

— техническое задание: все данные о ПП, необходимые для расчета затрат;

— таблица оценок элементов ПП;

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

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

На выходе системы формируется отчет о затратах на проектирование ПП. Контекстная диаграмма и диаграмма первого уровня функциональной модели автоматизированной системы в нотации IDEF представлены на рисунках 1 и 2.

Для разработки программного средства были выбраны СУБД Microsoft SQL Server и Visual Studio 2012.

На рисунке 3 представлен интерфейс программного средства.

После авторизации пользователя программного средства необходимо ввести общие сведения о программном проекте, для которого рассчитываются затраты. Для этого выбираются пункты меню Данные ^ Справочные данные и поочередно заполняются справочники «Тип проекта», «Тип юр. лица», «Единицы измерения». Примеры заполнения справочников и введения другой информации представлены на рисунках (http://www.swsys.ru/uploaded/ image/2018_1/2018-1 -dop/22.jpg, http://www. swsys. ru/uploaded/image/2018_1/2018-1 -dop/23 .jpg).

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

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

После внесения вспомогательной информации осуществляется переход непосредственно к расчетам. Для работы с моделью композиции приложения выбираем пункты меню Модели расчета ^ Модель композиции приложения. Затем выставляем все параметры проекта, нажимаем кнопку «Рассчитать» и получаем оценку затрат на проект (http://www.swsys.ru/uploaded/image/2018_1/2018-1-dopZ24.jpg), кроме того, возможно сохранение данных.

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

Рис. 3. Главная форма автоматизированной системы Fig. 3. The automated system main form

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Рис. 4. Анализ данных алгоритмом горной кластеризации Fig. 4. Data analysis by the mountain clustering algorithm

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

Аналогичным образом выбирается модель раннего этапа проектирования, заполняются все параметры, представленные на форме, и результаты сохраняются в БД (http://www.swsys.ru/uploaded/ image/2018_1/2018-1 -dop/2 5 .j pg).

Когда расчет затрат выполнен, можно переходить к анализу данных (пункт меню «Анализ»). Откроется форма, где можно выбрать проект для анализа из ранее сохраненных либо задать количество человеко-месяцев и количество персонала. После нажатия на кнопку «Определить сложность» на среднем графике отобразится группа, в которую попадает выбранный проект по сложности из трех возможных кластеров: легкий, средний или сложный. На нижнем графике по эмпирическим кривым Боэма можно определить оптимальную длительность проекта и оптимальное число персонала для него на основании полученных затрат (рис. 4).

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

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

1. Зубкова Т.М., Ишакова Е.Н., Медведев А.С. Программная система оценки рисков в сфере высшего образования с использованием продукционно-фреймовой модели // Вестн. ОГУ. 2014. № 1. С. 183-188.

2. Boehm B.W. Software cost estimation with COCOMO II. Prentice Hall PTR, 2000, 540 p.

3. Jones C. Software estimating rules of thumb. 2007. URL: http://www.itmpi.org/default.aspx?pageid=197 (дата обращения: 24.08.2017).

4. Symons C.R. Function points analysis: difficulties and improvements. IEEE Transactions on Software Engineering. 1988, no. 1, pp. 2-11.

5. Архипенков С. Лекции по управлению программными проектами. URL: http://www.citforum.ru/SE/project/arkhipenkov_ lectures/12.shtml (дата обращения: 24.08.2017).

6. Липаев В.В. Экономика производства программных продуктов. М.: СИНТЕГ, 2011. 352 с.

7. Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения. СПб: Питер, 2012. 608 с.

8. Модель оценки стоимости СОСОМО. URL: http:// project.dovidnyk.info/index.php/programnye-proekty/upravleniepro ektamiposozdaniyuprogrammnogoobespecheniya/130-modelocenki stoimostisosomo (дата обращения: 24.08.2017).

9. Штовба С.Д. Проектирование нечетких систем средствами МА^АВ. М.: Горячая линия-Телеком, 2007. 288 с.

10. Зубкова Т.М., Колобов А.Н. Расчет затрат при проекти-

ровании программных проектов по методике СОСОМО II с использованием горного алгоритма. Свид. о гос. регистр. прогр. для ЭВМ № 2016616453. Зарег. 10.06.2016.

Received 25.08.17 2018, vol. 31, no. 1, pp. 134-139

COST ESTIMATION IN SOFTWARE PROJECTS DESIGN USING THE MOUNTAIN ALGORITHM

T.M. Zubkova 1, Dr.Sc. (Engineering), Professor, bars87@mail.ru

E.N. Natochaya 2, Ph.D. (Education), Associate Professor, en_ischa@mail.ru

1 Orenburg State University, Pobedy Ave. 13, Orenburg, 460018, Russian Federation

2 Russian Presidential Academy of National Economy and Public Administration (Orenburg branch), Curacha St. 26, Orenburg, 460000, Russian Federation

Abstract. Cost estimation in software development allows reducing the probability of making incorrect or not making necessary management decisions, the probability of obtaining unplanned results of software projects. The article performs the analysis of basic approaches to the problem of software projects cost estimation: the linear approach, the method of function points and using empirical data. The paper proposes the technique of cost estimation in software projects design based on the mountain algorithm.

The paper describes mathematical support and software to solve the problem. The task is implemented according to the application composition model and the early design model. To estimate software project costs it is offered to record the price of programs according to their group of complexity. The paper considers three groups of software products complexity: simple (design takes up to 4 months), average (design takes from 4 months to one year), high (design exceeds a year). The paper explains the use of the mountain clustering method for combining software products in groups based on a similarity of signs.

Based on the offered method, the software system of software projects cost estimation is developed in order to increase objectivity and efficiency of the decisions made by developers. Input data of the software system are a structure of an enterprise, a specification, a table of estimates of software product elements, the Boehm table. The algorithm of a mountain clustering acts as controlling influence. The resources supporting execution of software system functions are hardware and software of the company. At the system output, the report on costs of software product design is created.

Keywords: program project, cost estimation, mountain algorithm, clustering, specification, application composition model, early design stage model.

1. Zubkova T.M., Ishakova E.N., Medvedev A.S. Software system of risks assessment in the higher education with use of productional and frame model. Vestn. OGU [Vestnik of OSU]. 2014, no. 1, pp. 183-188 (in Russ.).

2. Boehm B.W. Software cost estimation with COCOMOII. Prentice Hall PTR Publ., 2000, 540 p.

3. Jones C. Software Estimating Rules of Thumb. 2007. Available at: http://www.itmpi.org/default.aspx?pageid=197 (accessed August 24, 2017).

4. Symons C.R. Function points analysis: difficulties and improvements. IEEE Trans. on Software Engineering. 1988, no. 1, pp. 2-111.

5. Arkhipenkov S. Lectures on Control of Program Projects. Available at: http://www.citforum.ru/SE/project/ arkhipenkov_lectures/12.shtml (accessed August 24, 2017).

6. Lipaev V.V. Ekonomikaproizvodstvaprogrammnykhproduktov [Software Products Production Economics]. Moscow, SINTEG Publ., 2011, 352 p.

7. Orlov S.A., Tsilker B.Ya. Tekhnologii razrabotkiprogrammnogo obespecheniya [Software Development Technology]. St. Petersburg, Piter Publ., 2012, 608 p.

8. Model otsenki stoimosti COCOMO [The Model of COCOMO Cost Estimation]. Available at: http://project.dovid-nyk.info/index.php/programnye-proekty/upravlenieproektamiposozdaniyuprogrammnogoobespecheniya/130-modelocenkisto imostisosomo (accessed August 24, 2017).

9. Shtovba S.D. Proektirovanie nechetkikh sistem sredstvamiMATLAB [Fuzzy Systems Design Using MATLAB]. Moscow, Goryachaya liniya-Telekom Publ., 2007, 288 p.

10. Zubkova T.M., Kolobov A.N. Raschet zatratpri proektirovanii programmnykh proektov po metodike COCOMO II s ispolzovaniem gornogo algoritma [Cost Estimation in Software Projects Design by COCOMO II Method Using the Mountain Algorithm]. State registration certificate of the computer program no. 2016616453, 2016.

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

8 января 2024 Регистрация Войти
12 января 2024

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО »СБЕР А». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

17 января 2024

Программа разработана совместно с АО »СБЕР А». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Новости и аналитика Правовые консультации Бухучет и отчетность В процессе разработки программного обеспечения N 1 (ПО1) в его составе выявилось еще несколько ПО (модулей), которые можно использовать самостоятельно. Все затраты при этом больше двух лет собирались на ПО1. Как определить себестоимость остальных модулей и в какой моменти на основании чего их учитывать?

В процессе разработки программного обеспечения N 1 (ПО1) в его составе выявилось еще несколько ПО (модулей), которые можно использовать самостоятельно. Все затраты при этом больше двух лет собирались на ПО1. Как определить себестоимость остальных модулей и в какой моменти на основании чего их учитывать?

29 октября 2021

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

Обоснование вывода:

Бухгалтерский учет

В общем случае нематериальный актив (далее — НМА) признается в тот момент, когда организацией понесены затраты, непосредственно связанные с его созданием и обеспечением условий для его использования в запланированных целях, при соблюдении условий для признания, указанных в п. 3 ПБУ 14/2007 «Учет нематериальных активов» (далее — ПБУ 14/2007) (п. 9 ПБУ 14/2007).
Объект принимается к учету в качестве НМА при единовременном выполнении условий, перечисленных в п. 3 ПБУ 14/2007. Одним из которых является идентифицируемость актива (имеется возможность выделения или отделения (идентификации) объекта от других активов)*(1).
Если в отношении отдельных модулей (ПО) выполняются все условия отнесения объекта к НМА, в том числе условие, поименованное в подп. «в» п. 3 ПБУ 14/2007, согласно которому программу возможно выделить или отделить (идентифицировать) от других компьютерных программ, то данная программа может быть отдельно учтена организацией в качестве самостоятельного инвентарного объекта НМА, что соответствует положениям п. 5 ПБУ 14/2007.
В данном случае выделяемые из разрабатываемого НМА модули, как мы поняли, могут быт идентифицированы как отдельный актив.
Объект НМА принимается к учету по фактической стоимости, которая складывается не только из затрат на его приобретение или создание, но и из расходов, связанных с обеспечением условий использования такого объекта в запланированных целях (п. 6, п. 8 и п. 9 ПБУ 14/2007). ПБУ 14/2007 содержит открытый перечень расходов, связанных с созданием нематериального актива.
При этом ПБУ 14/2007 не содержит правил формирования первоначальной стоимости НМА на стадии разработки.
Исходя из пп. 51-67 МСФО (IAS) 38 «Нематериальные активы» затраты, связанные с созданием НМА, начинают капитализироваться (относиться на счет 08), начиная с того момента, когда организация может продемонстрировать все перечисленное ниже:
(a) техническую осуществимость завершения разработки НМА и доведения его до состояния, пригодного для использования или продажи;
(b) свое намерение завершить разработку НМА и использовать или продать его;
(c) способность использовать или продать НМА;
(d) предполагаемый способ извлечения вероятных будущих экономических выгод (организация может также продемонстрировать наличие рынка сбыта для продукта, получаемого от использования НМА, или самого НМА, или же, если этот актив предназначен для внутреннего использования самой организацией, полезность такого НМА);
(e) наличие достаточных технических, финансовых и прочих ресурсов, необходимых для завершения процесса разработки и использования или продажи НМА;
(f) способность надежно оценить затраты, относящиеся к НМА в процессе его разработки.
Полагаем, что все эти требования могут быть продемонстрированы во внутреннем документе организации (например, бизнес-плане, плане разработки ПО), в котором отражаются:
— объект НМА;
— планируемый срок завершения его разработки;
— перечень технических, финансовых и прочих ресурсов, требуемых для разработки;
— калькуляция затрат. В состав первоначальной стоимости НМА, созданного самой организацией, включаются все затраты, непосредственно связанные с созданием, производством и подготовкой этого актива к использованию в соответствии с намерениями руководства (п. 66 МСФО (IAS) 38).
При этом до момента признания капитальных вложений в качестве НМА (на счете 04 «Нематериальные активы») организация может разделить накопленные вложения при необходимости выделения нескольких объектов. Во всяком случае, запрета на такое действие российские стандарты бухгалтерского учета, а также МСФО не содержат. Соответственно, и нет конкретных правил для случая, когда на стадии разработки (и капитализации затрат) необходимо выделить несколько объектов.
Отметим, что проектом ФСБУ 14/2021 «Нематериальные активы» также не установлены правила для рассматриваемой ситуации.
При этом в проекте изменений к ФСБУ 26/2020 «Капитальные вложения» (ID 04/15/09-21/00120962) Минфин России планирует отнести к капитальным вложениям помимо вложений, понесенных при приобретении, создании или улучшении основных средств, также и вложения в НМА. Кроме этого, проектом предусмотрено внесение в ФСБУ 26/2020 нового пункта, в соответствии с которым фактические затраты, связанные с осуществлением капитальных вложений в несколько объектов, распределяются между ними обоснованным способом, установленным организацией самостоятельно.
Таким образом, если на стадии капитализации расходов, понесенных при разработке НМА, возникла необходимость выделения нескольких объектов, которые могут быть идентифицированы как объекты НМА, организация может:
— не делить накопленные расходы, а стоимость модулей оценивать, исходя из расходов, понесенных после их идентификации как отдельных разрабатываемых объектов НМА (что возможно в ситуации, если при разработке ПО не были понесены существенные трудозатраты на разработку модулей, выделенных впоследствии. И если после выделения модулей они далее разрабатывались (дорабатывались))
или
— разделить накопленные затраты любым обоснованным способом с учетом принципа рациональности*(2).
Для оценки распределения затрат применяется профессиональное суждение ответственных за формирование первоначальной стоимости актива лиц (например, комиссии по оприходованию и выбытию активов), или отдельного лица (например, главного бухгалтера) (смотрите Рекомендацию Р-96/2018-КпР «Профессиональное суждение» (принята фондом «Национальный негосударственный регулятор бухгалтерского учета «Бухгалтерский методологический центр» от 17.12.2018)). При принятии решения в рассматриваемой ситуации должны быть учтены экспертные мнения квалифицированных специалистов (экспертов), руководящих процессом разработки ПО. В частности, указанные лица могут предоставить информацию о примерных трудозатратах, понесенных на разработку модулей при разработке ПО.
Профессиональное суждение подлежит документальному оформлению в произвольной форме (п. 7 Рекомендации Р-96/2018-КпР).

Документальное оформление

Конкретных форм документов, применяющихся при разработке, доработке, модернизации, адаптации НМА, не установлено — хозяйствующий субъект разрабатывает их самостоятельно (ч. 4 ст. 9 Федерального закона от 06.12.2011 N 402-ФЗ «О бухгалтерском учете», далее — Закон N 402-ФЗ).
По нашему мнению, процесс документального оформления выделения отдельных объектов НМА может быть организован следующим образом:
— руководителем организации издается приказ о необходимости выделения модулей из разрабатываемого ПО, в связи с тем, что модули могут быть использованы в деятельности организации отдельно от разрабатываемого ПО;
— главный бухгалтер на основании указанного приказа составляет документ (справка, распоряжение), в котором определяется порядок распределения расходов с учетом мнения экспертов (например, руководства отдела, разрабатывающего ПО) о примерных трудозатратах на разработку модулей, понесенных при разработке ПО.
Также определяется степень завершенности разработки ПО, и при необходимости определяется калькуляция дальнейших расходов, понесенных при разработке ПО и выделенных модулей;
— после окончания работ и формирования первоначальной стоимости НМА — определяется срок полезного использования каждого объекта НМА и оформляется карточка учета НМА (можно разработать на основе унифицированной формы N НМА-1, утвержденной постановлением Госкомстата России от 30.10.1997 N 71а).
При этом первичные документы принимаются к учету, если они содержат обязательные реквизиты, указанные в ч. 2 ст. 9 Закона N 402-ФЗ. Первичными документами будут являться: ведомости, содержащие данные о заработной плате сотрудников, документы, свидетельствующие о сумме прочих расходов, прямо связанных с работами по разработке НМА, карточка учета НМА.

Налоговый учет

Отметим, что в НК РФ не предусмотрено изменение первоначальной стоимости уже принятого на учет НМА, который уже амортизируется (смотрите письма Минфина России от 17.05.2018 N 03-03-06/1/33132, от 04.02.2016 N 03-03-06/1/5716, от 03.06.2014 N 03-03-06/4/26501, от 27.09.2011 N 03-03-06/1/595).
На стадии капитализации расходов на приобретение, разработку НМА, по нашему мнению, организация вправе выделить отдельные объекты, которые в дальнейшем будут амортизироваться как объекты НМА на основании общих правил признания нематериальных активов, определения срока их полезного использования и порядка амортизации.
Так, по общим правилам, в целях главы 25 НК РФ НМА признаются приобретенные и (или) созданные налогоплательщиком результаты интеллектуальной деятельности и иные объекты интеллектуальной собственности (исключительные права на них), используемые в производстве продукции (выполнении работ, оказании услуг) или для управленческих нужд организации в течение длительного времени (продолжительностью свыше 12 месяцев) (п. 3 ст. 257 НК РФ).
Первоначальная стоимость амортизируемых НМА определяется как сумма расходов на их приобретение (создание) и доведение их до состояния, в котором они пригодны для использования, за исключением НДС и акцизов, кроме случаев, предусмотренных НК РФ.
Стоимость НМА, созданных самой организацией, определяется как сумма фактических расходов на их создание, изготовление (в том числе материальных расходов, расходов на оплату труда, расходов на услуги сторонних организаций, патентные пошлины, связанные с получением патентов, свидетельств), за исключением сумм налогов, учитываемых в составе расходов в соответствии с НК РФ.
При этом для постановки на учет объекта в качестве НМА решающее значение имеет наличие надлежаще оформленных документов, служащих основанием для принятия созданного НМА к учету. Такими документами, помимо документов, подтверждающих затраты, могут служить также и документы о распределении затрат между отдельными объектами НМА.
Разъяснениями контролирующих органов применительно к анализируемой ситуации мы не располагаем. Поэтому выраженная позиция является нашим экспертным мнением и не препятствует руководствоваться нормами законодательства РФ в понимании, отличающемся от трактовки, изложенной в приведенном выше ответе.

Рекомендуем также ознакомиться с материалами:
— Энциклопедия решений. Учет НМА, созданных в организации;
— Энциклопедия решений. Определение первоначальной стоимости амортизируемого имущества в целях налогообложения прибыли;
— Вопрос: Создание объекта НМА (ответ службы Правового консалтинга ГАРАНТ, май 2020 г.).

Ответ подготовил:
Эксперт службы Правового консалтинга ГАРАНТ
Ткач Ольга

Ответ прошел контроль качества

8 октября 2021 г.

Материал подготовлен на основе индивидуальной письменной консультации, оказанной в рамках услуги Правовой консалтинг.

————————————————————————-
*(1) В соответствии с п. 12 МСФО (IAS) 38 «Нематериальные активы» актив отвечает критерию идентифицируемости, если он, в частности, может быть обособлен или отделен от организации и продан, передан, лицензирован, предоставлен в аренду или обменен индивидуально или вместе с относящимся к нему договором, идентифицируемым активом или обязательством независимо от того, намеревается ли организация так поступить.
*(2) Применяемый способ распределения накопленных затрат (капитализированных на счете 08) должен соответствовать требованиям, предъявляемым к учетной политике ПБУ 1/2008 «Учетная политика организации». В частности, учетная политика организации должна обеспечивать, в частности, соблюдение требования рациональности, установленное абзацем 7 п. 6 ПБУ 1/2008 — т.е. затраты на представление правдивой информации не должны превышать полезность этой информации для пользователей.

Принципы построения системы экологического контроля за деятельностью предприятий и разработки регионального кадастра отходов Текст научной статьи по специальности «Компьютерные и информационные науки»

Текст научной работы на тему «Принципы построения системы экологического контроля за деятельностью предприятий и разработки регионального кадастра отходов»

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

1. Карелов A.M. Методические и нормативно-аналитические основы экологического аудирования в Российской Федерации. Часть 1. М:, 1999.

2. Минье В.В. Системный подход к аудиту промышленного предприятия. // Экология производства. 2005. №¡6. С. 24-28.

3. Серов Г.П. Экологический аудит. Концептуальные и организационно-правовые основы. ML: «Экзамен», 2000. 767 с.

4. Серов Г.П. Руководящие указания по экологическому аудиту организаций. Корпоративный стандарт. М., 2007.

5. Трифонова Т.А., Ишунькина H.A. Оценка жизненного цикла производства — основа системы управления окружающей средой. // Экология и промышленность России. Январь 2008. С. 29-31.

6. Шмаль А.Г. Экологический аудит как элемент управления природоохранной деятельностью. // Экология и промышленность России. Июнь 2005. С. 40-42.

; И.Л. Зубцова, В.А. Смолин, ЛЛ. Лазарева, О.И. Литвинец

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

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

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

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

При создании автоматизированной системы обработки поступающих данных, следует иметь ввиду, что предприятия могут применять новейшие технологии, приводящие к образованию новых видов отходов, которые не отражены в каталогах ФККО и РККО. Выходом из такой ситуации может быть создание Временного кадастра отходов (ВККО), цель которого — оперативное отражение ситуации. В этот каталог должны заноситься данные, получаемые непосредственно от хозяйствующих субъектов в случае, если предприятие не может найти свой вид отхода в каталога* ФККО и РККО. Строение ВККО также должно соответствовать структуре ФККО. По мере поступления новых данных в ВВКО соответствующие региональные органы осуществляют процедуру по переводу данных из ВККО в РККО. Наличие трех кадастров в системе автоматизированного контроля отходов полностью отвечает принципу оперативности и преемственности данных и соответствует законодательству.

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

Таким образом, в создаваемой базе данных должны храниться сведения об административной привязке (муниципальное образование, населенный пункт и его тип), а также координаты мест хранения и переработки отходов. Это позволит получать соответствующие выборки по типу и характеру отходов и их взаиморасположению, проводить математическую обработку данных на основе статистических и аналитических алгоритмов и программ, которые также должны быть включены в систему контроля. Для оценки степени опасности для окружающей среды и населения при хранении отходов следует иметь данные о их количественном и качественном составе, условиях хранения и переработки, близости от жилых массивов и водоемов и т.п. Весь пакет данных, которые позволяют провести подобного рода оценку должны предоставлять хозяйствующие субъекты. Однако, при существующей нормативно-право вой базе предприятия не обязаны предоставлять столь подробные данных в своей отчетности, следовательно, требуется целый комплекс мер по созданию необходимого перечня нормативных документов, обязывающих организации предоставлять такие данные.

Итак, для создания системы экологического контроля необходимо:

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

2. Разработка Временного каталога отходов (ВККО) и сопутствующего к нему пакета нормативных документов.

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

При построении системы экологического контроля (программного комплекса) требуется решение следующих задач [1]:

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

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

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

4. Разработка структуры данных для хранения сведений об объектах размещения отходов, включая их координатную привязку.

5. Разработка мер по защите хранимых данных и их дублирования. ;

6. Разработка программных средств автоматического контроля получаемых сведений от хозяйствующих субъектов.

7. Разработка форм отчетности и характера предоставляемых материалов. :

8. Разработка интерфейса системы для пользователей. ^ ^ г > —

9. Разработка методического обеспечения и порядка ведения специализированной базы данных «Объекты размещения отходов производства и потребления».

3 0. Выбрать (создать) программные средства графического отображения данных на географических картах.

Прежде, чем мы перейдем к анализу перечисленных выше требований, для исключения неоднозначности в толковании терминов будем понимать под термином «База данных» сервер управления совокупностью данных различной природы, объединенных в какие-либо структуры (таблицы), связанные между собой отношениями входящих в них записей. Каждая структура (таблица) — это набор расположенных в определенной последовательности данных различных типов <записей). Под термином сервер управления базой данных будем понимать совокупность программных средств, обеспечивающих взаимодействие между пользовательским приложением и данными, хранящимися в базе.

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

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

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

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

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

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

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

Рассмотрим минимальный набор сведений, которые должны храниться в базе «Обращение с отходами производства и потребления»

— сведения о лимитах на размещения отходов производства и потребления (в разрезе хозяйствующих субъектов и муниципальных образований края);

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

сведения о выданных лицензиях на осуществление видов деятельности в сфере обращения с отходами;

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

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

Первоначальный перечень сведений, характеризующих предприятие — владельца объектов размещения отходов и сами объекты, был определен в соответствии с данными, представленными в таблицах 1 и 2 соответственно. ^ххуу1^-^—» : . < ^ '

Характеристика предприятия — владельца объекта размещения отходов

1. Наименование предприятия

2. Адрес (юридический и почтовый)

3 1 Телефон (код), факс, Ejmail

ФИО, должность руководителя

11. Наличие лицензии на размещение отходов: № кем и когда выдана лицензия

12. Лимиты на размещение отходов: № кем и когда выданы, срок действия

Таблица 2. Характеристика объекта размещения отходов

1. Наименование объекта размещения отходов ^.

2. Вид размещения (хранение/захоронение)

3. Категория объекта: действующий, законсервированный, закрытый без рекультивации, закрытый с рекультивацией

4, Местоположение объекта: наименование муниципального образования^ описание нахождения с привязкой к территориально значимым ориентирам (населенный пункт, водоем, устье реки, вершины, ключи, ручьи и т.д.)

5. I Координаты нахождения объекта: географическая широта и долгота

Документ на землеотвод по объекту размещения отходов

г Категория земель, на которой расположен объект (земли поселений, лесопарковая, земли с/’х назначений, территория предприятия и т.д.)

г Наличие проекта на объект, кем разработан

1 f 1 9. Заключение государственной экспертизы

10 Год ввода в эксплуатацию

И. Год окончания эксплуатации

12. Мощность (масса размещаемых отходов), т/год

13, Вместимость, т

Продолжение таблицы 2

14. Масса накопленных отходов, т

15. Размещаемые виды отходов: наименование, код ФККО, условия размещения (навалом, в таре и т.д.) по каждому виду

16 Площадь объекта, га

3 7. Площадь участка складирования проектная/фактическая для полигонов ТБО. га

18. Размер санитарно-защитной зоны, м

19. Наименование ближайшего населенного пункта и расстояние до него, км

20. Наименование ближайшего водотока и расстояние до него, км

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

22. Наличие системы мониторинга на объекте: мониторинг грунтовых вод, поверхностных вод, атмосферного воздуха.

23. Результаты экологического контроля (кем и когда проведена последняя проверка, выявленные нарушения)

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

Для анализа характера данных, которые должны быть помещены в базу, воспользуемся таблицами 1 и 2. Большинство сведений представляет собой текст, длина которого может быть ограничена 80 символами, исключение составляют описание местоположения и характера нарушений природоохранного законодательства, для которых следует зарезервировать больший размер записи, например 255 символов. Числовые данные представляют собой целые и действительные числа (размер 4 и 8 байт). Таким образом, можно считать, что средний размер записи не более 80 байт. Применительно к предприятию это составляет около 3Кб (верхняя оценка), а описание одного объекта — не более 4Кб (зарезервируем до 20 видов отходов на каждом объекте).

Учитывая, что на территории субъекта находится около 30 муниципальных образований, в каждом из которых не более 1000 предприятий, объем данных, описывающий все предприятия края, составит не более 90 Мб.

Приняв, что каждое из предприятий в среднем имеет не более 5 объектов, получим, что описание всех объектов составит не более 600Мб (верхняя оценка).

Таким образом, общий объем данных не более 700 Мб (реально он будет в 5-10 раз меньше).

Если обратиться к таблице 2 (пп. 3, 7, 15, 21), то можно заметить, что все используемые характеристики объекта могут быть сведены в ряд справочников (например, справочник категорий объектов будет содержать сведения о характере объекта). Любой ш справочников — это отдельная таблица, каждая запись которой имеет уникальный номер, т.е. объект характеризуется набором кодов, указывающих на соответствующую запись в таблицах. Для реализации подобной технологии организации базы наилучшим является реляционный тип базы данных (MS Access, InterBase, SQL Serveiy Oracle). Учитывая, что суммарный объем данных не более 700 Мб, а также то обстоятельство, что SQL Server и Oracle дорогостоящие системы, доступными (и, что не маловажно, бесплатными) являются MS Access и варианты InterBase (с поддержкой до 10 пользователей).

Оценим объем данных, которые будут циркулировать в сети при выполнении запросов. Средний запрос — это сведения об объектах или предприятиях на территории одного муниципального образования. По нашей верхней оценке это не более 20 Мб (реально 2-5), что при скорости передачи в сети ЮОМбит/с (около 6Мб/с с учетом контрольных кодов) составит не более 0,3-3 сек. При одновременном запросе от 10 пользователей время ожидания ответа составит не более 3-30 сек. Такое время вполне приемлемо, и, следовательно, строить сложную систему по технологии многоуровневых приложений для управления базой данных нецелесообразно. Это значительно упрощает задачу и снижает объем создаваемого программного кода, т.к. отпадает необходимость в создании собственного сервера управления данными.

Выбирая между платформами MS Access или InterBase, отметим, что на всех машинах, где имеется MS Office, устанавливается процессор (сервер) управления базами данных MS Jet, который полностью поддерживает базы типа MS Access.

Таким образом, для хранения данных следует выбрать тип базы данных MS Access. Не маловажным обстоятельством в пользу такого выбора является возможность просмотра и редактирования полей базы средствами MS Access. Естественно, она может управляться средствами самого MS Access. Тем не менее, рассмотрим этот вопрос подробнее, для чего оценим нагрузку на пользователя при вводе (редактировании) данных. Примем во внимание, что отчетность, предоставляемая предприятием, имеет квартальный или ежегодный период.

Будем использовать два способа оценки трудоемкости — по числу вводимых символов и по количеству обрабатываемых документов.

1. Пусть обновляется не более 10% от всех данных (это соответствует верхней оценке), тогда предельный объем обрабатываемых данных будет не более 70Мб (реальный объем составит от 2 до 7 Мб), что соответствует в пересчете на страницы 21000 (предельный объем) и 600-2100 страниц -реальный объем. (При оценке исходили из того, что на одной странице находится 38 строк по 80 символов в каждой, что соответствует 3Кб). В среднем за один рабочий день человек в состоянии набрать (с проверкой) около 15 страниц текста (норматив машинистки), что для наших условий составит 1400 рабочих дней (предельный случай) и от 40 до 140 рабочих дней (реальная оценка).

2. При визуальном контроле данных (чтение с экрана и сверка с распечаткой) на один документ человек тратится около 3 мин. Оценить общее количество обрабатываемых документов можно исходя из числа предприятий и среднего количества объектов размещения отходов на предприятии. Приняв условия ежегодной отчетности (30 районов, 500 предприятий в одном районе, 3 объекта на одном предприятии) получаем предельную оценку — 45000 документов (реальное число документов будет не более 9 000). При 6 часовой непрерывной работе за компьютером человек будет обрабатывать не более 100 документов в день, что дает оценку в 450 рабочих дней (предельный случай) и 90 рабочих дней (реальная оценка).

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

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

Таким образом, непосредственное использование MS Accsess не целесообразно по следующим причинам:

— . 1. Обработка запросов в MS Accsess проводится с использованием встроенного интерпретатора, скорость которого значительно уступает программам, написанным на объектно-ориентированных языках.

2. Отсутствие возможностей реализации управления графикой.

3. Скудные средства при создании интерфейсов.

4. Значительные трудности в организации многопользовательского режима доступа.

5. Большая нагрузка на сеть из-за постоянной связи с базой данных.

6. Нерациональная и трудоемкая работа пользователя в среде MS Access.

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

— обеспечение средствами распределенного доступа;

■ — средства контроля и обеспечения целостности базы данных; . — ^ ;

— средства для автоматического ввода и корректировки данных;

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

— систему связанных между7 собой справочников;

— средства экспорта данных в MS Excel и Word; ■■’■’■■■■■■:■>* ■ о-.-^,- л-. ; .

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

— генератор запросов; _ «

— средства архивирования данных;

— встроенная система помощи.

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

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

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

Проанализируем требование о необходимости наличия картографической базы данных совместимой со средой ТИС.

Как отмечалось выше, существует несколько способов решения поставленной задачи:

1. Использовать существующие ГИС;

2. Передавать данные в ГИС (используя конверторы); .. .

3. Разработать собствеш/ую ГИС;

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

Рассмотрим по порядку достоинства и недостатки каждого их этих решений.

На первый взгляд самое первое решение — самое лучшее. Действительно существует большое количество высококачественных ГИС, обеспечивающих высококачественный графический вывод на карты любых объектов с выводом их характеристик, которые хранятся в базе данных этой ГИС. К ним обносятся ArcView, ArcGis, ArcMap, Maplnfo и д.p. Однако, любая ГИС использует собственные форматы для обработки изображений и хранимых в ее базе данных, которые, являются объектами «ноу-хау» и, как правило, внешнему пользователю не предоставляются. Это означает, что, мы вынуждены будем проделывать двойную работу по внесению данных в нашу базу (для формирования отчетности) и в базу ГИС (для осуществления визуализации). Причем в последнем случае об автоматизации нет и речи. И, наконец, самое главное — поскольку обе базы независимы, то отследить расхождение в данных для какого-либо объекта не представляется технически возможным. Негативным является и такой момент: для работы с обеими программными комплексами (созданным нами и ГИС) пользователь должен досконально изучить их особенности, а это, безусловно, потребует от него достаточно больших усилий, т.к. любая ГИС — это сложная система с огромным объемом технической документации (как правило переводной).

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

Разработка собственной полноценной системы ГИС — задача практически не выполнимая как по стоимости, так и по срокам, поскольку средняя оценка стоимости разработки — от 1 ООО 000$ до 10 ООО 000$, а по времени — от 2 до 5 лет.

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

Встает вопрос: откуда брать эти подложки и как определять координаты планшетов. На территории субъектов РФ имеются специализированные организации, осуществляющие построение географических карт (обычно аэрогеодезические предприятия), которые являются владельцем таких данных. Следовательно, необходимо закупать у них системы, позволяющие создавать такие подложки и получать данные о координатной привязке. В соответствии с положением о государственной тайне в настоящее время открытыми для использования являются карты масштаба 100 000 и мельче, планшеты, полученные на основе таких карт путем простого увеличения масштаба, имеют искажения изображений. На сегодняшний день это обстоятельство делает невозможным использование реальных очертаний объектов, т.к. 1 км в масштабе карты равен 1 см, а большинство объектов имеет размеры десятки и редко сотни метров, следовательно, объекты на картах должны изображаться в виде условных знаков.

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

Наиболее важным для принятия управленческих решений является блок обработки и анализа информации. На первых этапах можно воспользоваться, простейшими алгоритмами, группирующими информацию по запрашиваемым критериям, однако в последующем неминуемо возникнет необходимость встраивания системы статистической обработки данных и представления результатов в графическом и табличном виде. Алгоритмы статистической обработки данных можно взять из [2], а в качестве базовой системы использовать пакет GeoStat [3]. ‘ ■ -^v-»-

1. Смолин В.А. Информационно-аналитическая система моделирования природных процессов. // В сб. Материалы II международной н-т конференции «Проблемы экологии, безопасности жизнедеятельности и рационального природопользования Дальнего Востока и стран АТР». — Владивосток, изд. ДВТГУ, 2006. — с. 388-392.

2. Смолин В.А. Математическое моделирование в геологии и геофизике. (Статистика). Уч. Пособие. — Владивосток, изд. ДВГТУ, 2007.-232 с.

3. Смолин В.А., Вагеник И.А. Пакет статистических программ «GeoStat». Св. 2007611398,

А.А Фаткулин, Л.П. Лазарева, О.Г. Пермякова, А.Н. Рябуха

ПРИНЦИПЫ РАЗРАБОТКИ МОДЕЛИ ДОПОЛНИТЕЛЬНОГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ НА БАЗЕ УЧЕБНО-НАУЧНО-ИННОВАЦИОННОГО УНИВЕРСИТЕТСКОГО КОМПЛЕКСА

В настоящее время на территории Российской Федерации в системе дополнительного профессионального образования (ДПО) функционируют более 2000 образовательных учреждений и

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

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

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Зубкова Т.М., Наточая Е.Н.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Зубкова Т.М., Наточая Е.Н.

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

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

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Зубцова И. Л., Смолин В. А., Лазарева Л. П., Литвинец О. И.

Текст научной работы на тему «Принципы построения системы экологического контроля за деятельностью предприятий и разработки регионального кадастра отходов»

Добавить комментарий Отменить ответ