CC BY
6
УДК 338.984
Царенок М.А. студент магистратуры Институт физики Казанский (Приволжский) федеральный университет научный руководитель: Пугачёва М.А., кандидат наук
доцент Россия, г. Казань
ПРЕДПРОЕКТНАЯ ОЦЕНКА ОБЪЁМА ТРУДОЗАТРАТ ПРОЕКТА РАЗРАБОТКИ ЗАКАЗНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ФИКСИРОВАННОЙ СТОИМОСТИ ДОГОВОРА
В статье перечислены входные данные, которые необходимы для оценки проекта разработки заказного программного обеспечения. Кратко рассмотрена последовательность этапов оценки проекта разработки системы заказного программного обеспечения. На примере продемонстрировано, каким образом может быть использована представленная модель расчёта при наличии необходимой входящей информации.
Ключевые слова: заказная разработка, система программного обеспечения, расчёт трудозатрат, риски проекта, оценка проекта.
Tsarenok M.A. graduate student Institute of Physics Kazan Federal University Russia, Kazan Sscientific director: Pugachyova M.A.
Associate Professor, Candidate of Science PRE-PROJECT EVALUATION OF THE AMOUNT OF LABOR COSTS OF A CUSTOM SOFTWARE DEVELOPMENT PROJECT WITH
FIXED CONTRACT COST
The article lists the input data that is needed to evaluate the custom software development project. Briefly review of a custom software development project evaluation stages sequence. Given an example of how the presented calculation model can be used in the presence of necessary incoming information.
Keywords: custom development, software, labor costs calculation, project risks, project evaluation.
Введение
Заказная разработка программного обесепечения в классическом виде предполагает наличие следующих этапов:
1. Оценка объёма трудозатрат на проекте и стоимости разработки исполнителем для заказчика.
2. Согласование стоимости разработки исполнителем и заказчиком
3. Подписание договора о разработке системы программного обеспечения.
4. Разработка программного обесепчения.
5. Приёмка результатов заказчиком.
6. Гарантийный период.
Важным этапом в процессе разработки заказного программного обеспечения является этап препроектной оценки проекта разработки программного обеспечения — от того, насколько качественно была произведена предпроектная оценка зависит успешность проекта и его окупаемость. Завышенная оценка может стать поводом отказа от заключения договора; если оценка занижена, то проект будет убыточным.
Особенно критично это для проектов с фиксированной стоимостью разработки. Модель фиксированной стоимости проекта используется для проектов, которые имеют определённое договором и техническим заданием содержимое. В случае с моделью фиксированной стоимости заказчик и исполнитель четко понимают объём работ и имеют конкретные ожидания относительно конечного результата разрабатываемой системы. При возникновении риска увеличения бюджета проекта, его принимает на себя исполнитель.
Оценка также должна включать работы по устранению дефектов создаваемой системы программного обеспечения — как на этапе разработки, так и на этапе гарантийного периода.
Цель статьи — описать процесс расчёта объёма трудозатрат проекта разработки заказного программного обеспечения при фиксированной стоимости договора.
В §1 дан список минимально необходимой информации для расчёта объёма трудозатрат на проекте. В §2 приведён общий сценарий расчёта объёма трудозатрат на проекте при заданном объёме входящих данных. В §4 приведён пример использования описанной модели.
1. Данные, необходимые для оценки проекта
Основным источником информации для оценки проекта являются входящие требования к разрабатываемой системе программного обеспечения. Идеальным вариантов является случай, когда заказчик приходит к исполнителю с полноценным техническим заданием, однако, как правило, именно исполнитель должен создать техническое задание в рамках разработки системы программного обеспечения.
В минимальном варианте необходимо ответить на следующие вопросы в рамках сбора первоначальных требований для оценки проекта:
1. Какая цель создания данной системы программного обеспечения?
2. Какие задачи решает для пользователя разрабатываемая система программного обеспечения?
3. Какие роли пользователей предполагаются в системе?
4. Какая функциональность в рамках решаемых задач доступны для
пользователя?
5. Из каких компонентов состоит система программного обеспечения? Какие из этих компонентов будут разрабатываться исполнителем? Как, предполагается, компоненты, разрабатываемые исполнителем, будут связаны с компонентами, разрабатываемыми сторонними исполнителями заказчика? На каком этапе находится разработка компонентов, разрабатываемых другими исполнителями? Есть ли прямой контакт со сторонними разработчиками? Ведётся ли разработка компонентов системы параллельно или последовательно или независимо друг от друга?
6. Какие технологии необходимо использовать при разработке системы программного обеспечения? Ответ на данный вопрос поможет исполнителю оценить свои возможности.
7. Предполагается ли интеграция разрабатываемой системы со сторонними системами?
8. Выполнение каких работ требуется от исполнителя в рамках разработки системы программного обеспечения? Основные виды работ:
• разработка технического задания;
• разработка дизайна пользовательского интерфейса;
• разработка архитектуры проекта;
• программная разработка (написание программного кода);
• управление проектом разработки системы программного обеспечения;
• тестирование системы программного обеспечения.
В рамках описания функциональности, доступной пользователю в разрабатываемой системе, необходимо для каждой функциональности ответить на следующие вопросы:
1. Пользователям с какими ролями доступна данная функциональность?
2. Какие данные используются поступают на вход в рамках данной функциональности? Какой источник данных и процесс их получения системой?
3. Какие операции система должна произвести в рамках данной функциональности и что передать на выход? Что является результатом выполнения работы системой в рамках функциональности?
Как правило, при оценке любой задачи такие вопросы формируются на интуитивном уровне, однако такое подробное документирование позволит не упустить важные моменты.
Однако, при оценке конкретным исполнителем мало учитывать информацию о будущей системе, её функциональности и компонентах, важно также иметь сформированное представление о непосредственных исполнителях, команде разработки системы: от навыков, знаний, опыта и даже характеристик личности участников в том числе зависит объём предполагаемых трудозатрат. Очень часто организации при оценке разработки проекта ориентируются на среднестатистического разработчика
уровня «Middle», что особенно критично в проектах с фиксированной стоимостью разработки, т.к. стоимость проекта на протяжении всего его цикла неизменна, а разработчик проекта может выйти из проекта, и не всегда новый разработчик будет соответствовать требованиям к разработчику уровня «Middle». Чтобы избежать издержек, связанных со сменой исполнителя, при оценке нужно важно ответить на следующие вопросы:
1. Какими навыками должен обладать исполнитель в рамках работы над системой?
2. Кто будет исполнителем в рамках работы над системой (конкретный сотрудник)? Обладает ли сотрудник необходимыми навыками, владеет ли используемыми в рамках разработки системы технологиями? Каков уровень знаний и опыт использования данных технологий у сотрудника?
3. Есть ли у данного сотрудника опыт работы на проектах соответствующего типа?
4. Какая предполагается занятость сотрудника на проекте (полноценный рабочий день, 2 часа в день или 6 часов на протяжении всего проекта)?
5. Есть ли необходимость в дополнительном обучении сотрудника исполнителя для участия в данном проекте?
При этом необходимо на этапе оценки подготовить список внутренних ставок сотрудников, которые будут задействованы на проекте (расчёт внутренних ставок в рамках данной статьи не рассматривается).
При формировании предпроектной оценки также полезно учитывать организационные вопросы:
1. Кто является владельцем требований на стороне заказчика? Каковы процессы согласования решений в рамках разработки на стороне заказчика?
2. По какой методологии планируется вести проект?
Важно также знать портрет заказчика: насколько заказчик заинтересован в разработке системы, каков уровень его знаний в рамках области разработки систем, а также области, в которой система будет функционировать.
Ответы на перечисленные вопросы позволят не только рассчитать объём работ проекта разработки системы программного обеспечения, но выявить возможные риски на этапе оценки и учесть их в стоимости проекта.
2. Общий сценарий расчёта объёма трудозатрат проекта
На данном этапе мы оцениваем объём трудозатрат проекта исходя из ответов, полученных на вопросы, перечисленные в §1. Процесс расчёта трудозатрат проекта включает в себя несколько основных этапов:
1 этап: Формирование команды оценки проекта.
На данном этапе формируется команда людей, которые будут ответственные за предоставление оценки трудозатрат проекта разработки системы программного обеспечения. Команда формируется исходя из следующих условий:
• Технологии, используемые в рамках разрабатываемой системы. Участники команды должны владеть соответствующими технологиями.
• Специфика проекта разработки. У участников должен быть опыт участия в разработке схожих программных продуктов: как минимум один участник команды должен иметь соответствующий опыт и быть в состоянии передать его другим участникам.
• Работы, которые планируются в рамках договора. Соответственно, если в рамках проекта исполнитель должен написать техническое задание, разработать систему и протестировать её на наличие дефектов, то специалисты-участники команды должны быть соответственно: аналитик требований, разработчик, тестировщик.
• Также в команде должны быть распределены роли: руководитель оценки — сотрудник, ответственный за результаты процесса оценки и аналитик — сотрудник, ответственный за процесс оценки и работу с требованиями.
2 этап: Декомпозиция требований. На данном этапе требования к разрабатываемой системе должны быть разбиты на отдельные пользовательские сценариев рамках конкретной функциональности. Такой сценарий может существовать отдельно от остальной функциональности; для выполнении данного процесса достаточно лишь данных, поступивших на вход этого сценария. При этом:
• пользовательский сценарий должен быть разбит на последовательность шагов;
• для шага должны быть описаны допущения (условия выполнения шага, ограничения. Если в рамках шага отсутствует какая-то важная информация, необходимая для полноценной оценки, необходимо указать это в допущениях);
• для сценария должны быть указаны возможные риски. Примером риска может быть непопулярная технология, при использовании которой у исполнителя могут возникнуть вопросы. Если процесс включает в себя интеграцию со сторонними сервисами, то это также влечёт за собой ряд рисков, связанных с интеграцией;
• для реализации функциональности в рамках процесса должна быть дана оценка в человеко-часах каждым задействованным в разработке специалистом. Оценка должна быть дана специалистом, имеющим опыт работы над аналогичными задачами. При этом при оценке учитывается опыт работы потенциального исполнителя. Так, если для реализации задачи планируется задействовать в проекте сотрудников с небольшим опытом работы в рамках выполнения аналогичных задач, то оценка даётся именно для специалиста соответствующего уровня,
• если у специалистов, дающих оценку, возникают вопросы по требованиям заказчика, то эти вопросы адресуются заказчику. Если нет возможности получить ответ на вопросы, то делается соответствующая
отметка, добавляется новый риск и оценивается наиболее вероятный вариант реализации (наиболее вероятный вариант реализации определяется на основе опыта работы над похожими задачами, а также обоснованности решения реализации именно таким образом).
3 этап: Формирование реестра рисков проекта.
На данном этапе анализируются все ответы на вопросы, перечисленные в §1, формируется реестр рисков и даётся их оценка в человеко-часах либо оценивается стоимость в рамках проекта.
4 этап: Расчёт объёма трудозатрат проекта. На основе данных, полученных на этапах 2 и 3 рассчитывается объём трудозатрат проекта (сумма трудозатрат на реализацию перечисленной функциональности и стоимости рисков проекта в человеко-часах).
Таким образом после 4 этапа на руках у исполнителя должен быть список работ, их оценка, перечень рисков проекта, их оценка и общий предполагаемый объём трудозатрат проекта при заданных входящих условиях.
5 этап: Расчёт объёма работ в рамках гарантийного периода.
Гарантийный период — это этап, на котором устраняются дефекты
системы программного обеспечения, выявленные заказчиком. Дефект — несоответствие работы системы требованиям технического задания, принятым результатам выполнения договора между исполнителем и заказчиком.
К этапу гарантийного периода уже завершены все основные работы по разработке системы и система сдана исполнителем заказчику и запущена в продуктовой среде.
На этапе гарантийной поддержки не ставятся новые задачи.
Сложность расчёта трудозатрат на гарантийный период заключается в невозможности предсказать, какой объём дефектов будет обнаружен на этапе гарантийного периода, а, следовательно, на какой объём работ необходимо запланировать специалиста исполнителя. Основным фактором в данном случае является качество проведённого внутреннего тестирования. Если внутреннее тестирование было проведено качественно, а все выявленные дефекты устранены, то и вероятность обнаружения новых дефектов снижается. Однако, как говорилось выше, цель статьи — не подтвердить правильность данного утверждения, а помочь в расчёте объёма работ на этапе гарантийного периода.
В общем случае на этапе гарантийного периода проекта сотрудник, задействованный на этапе разработки проекта, переходит в другой проект на полноценный рабочий день (англ. «Full-time»), а к данному проекту подключается по мере необходимости.
У такого подхода есть свой недостаток: в случае поступления большого объёма запросов на исправление дефектов исполнителю от заказчика, сотрудник не сможет полноценно работать на новом проекте, в
рамках которого его занятость распланирована без учёта работы на другом проекте.
Другой распространённый подход: выделять определённый процент от рабочего дня сотрудника на работу над дефектами проекта, находящегося на гарантийном периоде (например, 25% времени). Однако, в случае, если на этапе гарантийного периода не будет выявлено дефектов или они будут выявлены в минимальном объёме, то такой подход грозит простоями сотрудника.
4. Использования модели оценки объёма работ проекта на примере оценки пользовательского сценария авторизации пользователя в системе
Задача: оценить объём работ разработки функциональности авторизации пользователя в системе и максимально возможный объём работ на этапе гарантийного периода.
1. Предполагается, что в рамках договора исполнитель выполнит следующие виды работ:
• Написание технического задания,
• Разработка функциональности (написание программного кода),
• Тестирование функциональности,
• Управление процессом разработки функциональности.
3. В рамках системы планируется интеграция с сервером заказчика. Сервер заказчика будет реализован внутренними силами заказчика параллельно с разработкой описываемой функциональности исполнителем.
4. Краткое описание функциональности:
Точка входа: экран авторизации в системе.
Входные данные: логин пользователя в системе, пароль, соответствующий логину.
Система посылает на сервер запрос с указанием логина и пароля пользователя. Сервер возвращает ответ.
Выходные данные: результат обработки запроса сервером. Возможные варианты:
• пользователя с таким логином не существует,
• для данного логина введён неверный пароль,
• пользователь с таким логином существует, пароль введён верно.
5. Задачи в рамках разработки функциональности представлены в Таблице 1:
Таблица 1.
Задачи разработки программного обеспечения
Оценка трудозатрат, ч/час
Наименование задачи Аналитик Разработчик Тестировщик
Отрисовка формы ввода данных 1 1,5 1
пользователем
Формирование запроса для 0,15 1 0,25
отправки и получения данных с
сервера
Отрисовка экрана вывода 1 1 0,5
результатов авторизации
ИТОГО: 2,15 3,5 1,75
6. Планируется задействовать следующих специалистов с соответствующим уровнем подготовки:
• Аналитик требований, уровень подготовки: высокий.
• Разработчик, уровень подготовки: средний.
• Тестировщик, уровень подготовки: средний.
7. Используемые технологии: html, css, javascript.
8. Определены следующие риски:
• Увеличение сроков интеграции с сервером.
• Плохое качество программного кода.
10. Максимальный объём трудозатрат на этапе гарантийной поддержки равен 9 ч/часов.
Заключение
Этап предпроектной оценки трудозатрат проекта является ключевым этапом в рамках любого проекта заказной разработки. Именно от качества его выполнения зависит успешность проекта в целом и его окупаемость. Предложенная в статье методика позволит получить наиболее точную оценку трудозатрат проекта. Однако, недостаточно простого следования предложенным рекомендациям. Сам процесс оценки требует внимательности и ответственности к деталям, а также наличия знаний, связанных со спецификой разрабатываемого проекта. Сочетание этих компонентов позволит получить наиболее точную оценку проекта, а также станет одним из критериев успешности проекта.
Использованные источники:
1. Макконнелл С. Сколько стоит программный проект. М.:Русская Редакция; СПб.: Питер, 2007
2. Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат: Пер.с англ. М.: Издательский дом «Вильямс», 2003
3. Соммервилл А. Инженерия программного обеспечения. - М.: Вильямс, 2002
4. Петрова М.А. Исследование методов оценки сложности разработки информационных систем / М.А. Петрова, Шутов А.В. // Научное
сообщенство студентов XXI столетия. Технические науки: сб.ст.по мат. XV междунар.студ.науч.практ.конф №15.
УДК 343.01
Цецулина А.Е. студент магистратуры 1 курса направление подготовки «Правосудие по уголовным делам»
Юридический институт СФУ научный руководитель: Пономарева В.В., д.ю.н. профессор, начальник кафедры государственно-правовых
дисциплин
СибЮИ МВД России, ЮИ СФУ Россия, г. Красноярск
МОШЕННИЧЕСТВО В СФЕРЕ ЭКОНОМИКИ: ИСТОРИКО-
ПРАВОВОЙ АНАЛИЗ ВОЗНИКНОВЕНИЯ В РОССИЙСКОМ
ЗАКОНОДАТЕЛЬСТВЕ
Аннотация: статья посвящена рассмотрению вопроса возникновения мошенничества в сфере экономики в России, а также выделения обмана как способа совершения мошенничества. Анализируются труды И.Я. Фойницкого.
Ключевые слова: Мошенничество, обман, философия, история, учения.
Tsetsulina A.E., student of the first year of masters
degree
Law Institute of SFU Russia, Krasnoyarsk Scientific adviser: Ponomareva V. d. Professor, Head of the Department of State and Legal Disciplines Sibiu Ministry of Internal Affairs of the Russia, SFU FRAUD IN THE SPHERE OF ECONOMICS: THE HISTORICAL AND LEGAL ANALYSIS OF THE INITIATION IN THE RUSSIAN
LEGISLATION
Abstract: The article is devoted to the consideration of the issue of fraud in the sphere of economy in Russia, as well as the identification of fraud as a means of committing fraud. The works ofI.Ya. Foinitzky.
Keywords: fraud, deception, philosophy, history, doctrines.
Мошенничество считается одним из самых распространенных преступлений, совершаемых в Российской Федерации. По данным официальной статистики МВД России за период январь-февраль 2018 года на территории России зарегистрировано 56137 мошенничеств.23
История развития мошенничества как уголовно-наказуемого деяния
23 Состояние преступности в России за январь-март 2018 года [Электронный ресурс] // Сайт МВД России [2018]. - Режим доступа : https://xn--b1aew.xn--p1ai/reports/item/12899359/, свободный. - (25.04.2018).
