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

Министерство науки и высшего образования Российской Федерации

САНКТ-ПЕТЕРБУРГСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ПЕТРА ВЕЛИКОГО

Институт компьютерных наук и кибербезопасности

Высшаяшколапрограммнойинженерии

А. В. Самочадин Т. Н. Самочадина

ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Учебное пособие

Санкт-Петербург

2023

УДК 004.414.3, 004.413.5(075.8) ББК 32.973я73

С17

Р е ц е н з е н т ы:

Кандидат технических наук, доцент Института компьютерных наук и кибербезопасности СПбПУ С. Г. Попов

Доцент факультета экотехнологий Университета ИТМО В. Л. Лазарев

Самочадин А. В. Оценка трудоемкости разработки программного обеспече-

ния:учеб.пособие/А.В.Самочадин,Т.Н.Самочадина.–СПб.:ПОЛИТЕХ-

ПРЕСС, 2023. – 87 с.

Соответствует содержанию дисциплины «Программная инженерия» образовательного стандарта по направлению 02.03.02 «Фундаментальная информатика и информационные технологии».

Рассмотрен подход к формированию требований и оценке трудоемкости пометодикамнаосновевариантовиспользования(UseCasePoints)ирасчета функциональных точек (Function Points). Главное внимание уделено примеру расчета трудоемкости разработки проекта заказа билетов через Интернет по методикам Use Case Points и Function Points.

Предназначенодлястудентов3–4-гокурсовспециальностей«Фундамен- тальная информатика и информационные технологии» и «Программная инженерия» для самостоятельного изучения разделов «Формирование требований к программному обеспечению на основе вариантов использования», «Оценка трудоемкости разработки программного обеспечения на основе вариантов использования», «Оценка трудоемкости разработки программного обеспечения на основе расчета функциональных точек» курсов «Программная инженерия» и «Управление программными проектами».

Табл. 19. Ил. 11. Библиогр.: 6 назв.

Печатается по решению Совета по издательской деятельности Ученого совета

Санкт-Петербургского политехнического университета Петра Великого.

Ministry of Science and Higher Education of the Russian Federation

PETER THE GREAT ST. PETERSBURG

POLYTECHNIC UNIVERSITY

Institute of Cybersecurity and Computer Science

GraduateSchoolofSoftwareEngineering

A. V. Samochadin T. N. Samochadina

SOFTWARE DEVELOPMENT EFFORT ESTIMATION

Training manual

Saint Petersburg

2023

ВВЕДЕНИЕ

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

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

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

Рассмотренаметодикаформированиятребований,основанная навариантахиспользования(UseCases),иметодикиоценкитрудо-

емкостиUseCasePoints(USP)иFunctionPoints.Следуетотметить,

чтоэтоширокоприменяемые,нодалеконеединственныеметодики выполнения таких работ.

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

6

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

1.ФОРМИРОВАНИЕ ТРЕБОВАНИЙ

1.1.Основные понятия

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

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

В основе классификации требований лежит модель FURPS+, согласнокоторойвсетребованияделятсянаследующиетипы(категории):

–Functionality (функциональность);

–Usability (удобство, практичность);

–Reliability (надежность);

–Performance (производительность);

–Supportability (возможность обслуживания);

–+ (дополнительные факторы).

7

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

Требования могут быть сформулированы с разной степенью детализации.Взависимостиотэтогопринятовыделятьследующие типы требований:

1.Бизнес-требования (Business Requirements). Содержат высокоуровневые цели, определяют назначение ПО, описываются в документе «Концепция» («Vision»). Пример бизнес-требований: системадолжнасократитьсрокоборачиваемостиобрабатываемых на предприятии заказов в три раза. Обычно бизнес-требования формулируются заказчиком.

2.Пользовательские потребности. Отражают представления проблем,нарешениекоторыхнаправленаразрабатываемаясистема.Частопользовательскиепотребностинеоднозначныеипротиворечивые.

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

4.Специфицированные требования (Software Requirement Specification, SRS) – ориентированное на разработчика детализированное описание системных функций и ограничений. Служат основой для контракта между заказчиком и разработчиком.

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

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

8

Рис. 1. Взаимосвязь между уровнями требований

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

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

зывается управлением требованиями [1, 3, 4].

Внаиболеечастовстречающемсяслучаепроцессформирования требованийвключаетвсебяследующиетипыдеятельности(рис.2):

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

–формированиеианализтребований–систематизациятребо- ваний,аименноопределение,являютсялисобранныетребования

9

Предварительные

исследования

Рис. 2. Процесс формирования требований

неясными, неполными, неоднозначными или противоречащими; выявление взаимосвязи требований;

–специфицирование требований;

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

–утверждение требований;

–изменение требований в процессе разработки.

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

В соответствии с этой методикой вначале формируется модель вариантов использования, затем на ее основе пользовательские

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

исроки ее создания.

10