Повышение точности и сокращение времени планирования в процессах управления проектами по разработке программного обеспечения

Введение

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

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

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

Проблемы повышения точности и сокращения времени планирования

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

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

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

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

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

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

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

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

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

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

Несмотря на то, что работы в области формирования оценки изменений ведутся в течение нескольких десятков лет силами российских и зарубежных ученых, многие обзоры по-прежнему рапортуют о том, что разработчики, инструментарий, артефакты и процессы все еще слабо интегрированы и взаимосвязи чаще всего определены неявно, что не позволяет отслеживать несогласованность моделей и затрудняет оценку распространения изменений [1], [3]. Создание и поддержка трассировочной информации вручную крайне затратна [2] и определение трассировочных связей между проектными моделями различных уровней абстракции не тривиальна даже для экспертов [4]. Также отсутствует единый подход к классификации взаимосвязей требований для организации их трассировки [5] и несмотря на то, что преимущества трассировки известны, ее реализация на практике дается с трудом [3].

Требования к методу формирования оценки изменений.

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

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

Метод ФОИ должен содержать: 1) формальное определение понятия «требование»; 2) описание структуры требований; 3) формальный язык описания требований с однозначно определенной семантикой; 4) правила контроля семантических ошибок в требованиях; 5) правила определения связей между требованиями, отражающие приоритетные направления распространения изменений, позволяющие автоматизировать процесс поиска таких связей; 6) правила формирования оценки изменений.

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

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

Структура требований метода (- модель трассировки) должна: 1) отражать весь объем изменений; 2) позволять легко проецировать изменения в проектных моделях на описание требований для ФОИ и обратно; 3) не должна зависеть от парадигмы проектирования, технологии и средств разработки; 4) позволять определять правила контроля семантических ошибок в требованиях и приоритетные направления распространения изменений;

Структура требований не должна: 1) фиксировать степень детализации описания требований; 2) усложнять описание требований. Должна быть легко применима на практике.

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

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

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

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

3. Разработать формальные определения типов ошибок в требованиях и возможные механизмы их контроля.

4. Разработать формальный метод ФОИ, удовлетворяющий поставленным требованиям.

5. Разработать реализацию метода ФОИ для практического применения при создании и эволюционном сопровождении АСУП.

Базовая модель трассировки требований для ФОИ

При разработке программной системы некоторая составная структура требований заранее определена выбранным набором методов описания системы, (назовем ее проектной). Чтобы учитывать при ФОИ весь объем изменений в требованиях, структура требований для ФОИ должна быть определена как мета-структура проектной модели.

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

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

Исследование показало:

• Наиболее полной и универсальной структурой требований, используемой при разработке систем класса АСУП, КИС и других информационных систем, не зависящей от парадигмы проектирования, технологии и средств разработки является схема Захмана [8], которая отражает процесс проектирования информационной системы;

• Использование схемы Захмана напрямую для формирования оценки изменений не возможно, так как она не содержит описания связей между элементами разных слоев;

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

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

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

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

1) модель трассировки должна отражать четыре уровня требований, соответствующих уровням схемы Захмана;

2) модель трассировки должна содержать 3 категории описания проектных моделей процесс, объект, правила.

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

Модель трассировки требований это способ структурирования описания требований, ориентированный на процесс формирования оценки изменений. В соответствии с разработанными требованиями, модель трассировки можно представить в виде связанного графа, вершинами которого являются три категории: процесс, объект, правила, а дугами 5 отношений: определяет, обрабатывает, декомпозиция, являться классом, эквивалентны. На рисунке 1 приведена эта модель (треугольник трассировки).

Рис. 1 Треугольник трассировки.

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

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

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

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

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

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

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

Рис. 2 Взаимосвязи между компонентами Комплекса.

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

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

Рис.3. Схема расширения Базового метода для систем класса АСУП

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

• Требование к системе определяется как высказывание о свойствах системы.

• Правила контроля ошибок представляются в виде высказываний.

• Структура высказываний задается системой предикатов, которые используют категории и отношения модели трассировки.

• Взаимосвязанные требования определяются как взаимосвязанные высказывания.

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

Такой подход к формализации описания требований реализует принцип открытости и обеспечивает: трассируемость требований; возможность визуализации модели требований для ФОИ; возможность применения существующего инструментария управления требованиями для ее реализации. Иллюстрация данного подхода применительно к формализации треугольника трассировки приведена в [9].

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

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

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

• Описание – совокупность высказываний.

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

• Метод описания – формальная система, предназначенная для формирования описаний с целью решения задачи моделирования, включающая язык, правила описания сформулированные с использованием данного языка.

• Предметная константа – набор символов, обозначающий понятие рассматриваемой предметной области.

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

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

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

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

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

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

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

Технология разработки расширений Базового метода основана на итеративном процессе разработки онтологий. Для оценки разрабатываемого набора отношений предлагается использовать Гештальт-принципы построения онтологий.

В качестве расширения Базового метода для систем класса АСУП, разработана Сбалансированная трехуровневая онтологическая модель требований. СТОМ детализирует структуру описания требований с учетом специфики процесса разработки АСУП, что позволило ввести дополнительные правила контроля ошибок в описании требований, оказывающих влияние на ФОИ. Множество аксиом СТОМ расширено, относительно базового метода до 42-х, что позволяет сократить объем ошибок проектирования и повысить точность и сократить сроки ФОИ. СТОМ также как и базовый Метод поддерживает принцип открытости.

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

Заключение

В ходе проведенных теоретических и экспериментальных исследований получены следующие результаты:

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

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

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

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

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

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

7. Разработана технология разработки расширений базового метода ФОИ , определяющая задачи процесса разработки расширения Метода, критерии оценки расширения Метода и фазы процесса разработки расширения Метода. Технология позволяет сократить время разработки расширения метода ФОИ для конкретной предметной области.

8. Разработана онтологическая модель описания ИО и ПО АСУП (СТОМ), позволяющая сократить объем ошибок проектирования и повысить точности и скорость формирования оценки изменений для систем класса АСУП.

9. Разработана технологическая модель реализации СТОМ, позволяющая эффективно использовать существующую промышленную систему управления требованиями для внедрения автоматизированного процесса ФОИ на базе СТОМ – сокращая тем самым сроки и расходы на внедрение СТОМ. Модель значительно сокращает объем работ в ходе ФОИ, позволяет повысить точность формирования оценки изменений за счет сокращения ошибок не только в исходных данных, но и в самом процессе ФОИ.

В целом разработанный комплекс решений:

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

• Позволяет сократить объем работ по каждому запросу на изменение.

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

Литература:

1. Aizenbud-Reshef , B. T. Nolan, J. Rubin, and Y. Shaham- Gafni. Model traceability. //IBM SJ, 45(3):- 2006. PP.-515-526,

2. Grammel, B. & Voigt, K. (2009), ‘Foundations for a Generic Traceability Framework in Model-Driven Software Engineering,’ Proceedings of the ECMDA Traceability Workshop 2009.

3. Kannenberg А., Dr. Hossein Saiedian Why Software Requirements Traceability Remains a Challenge //P Visibility - CROSSTALK, Jul/Aug 2009 Issue

4. Maeder P., Riebisch M. and Philippow I.: Traceability for Managing Evolutionary Change - A Roadmap. In: Proceedings 15th International Conference on Software Engineering and Data Engineering (SEDE-2006), July 6 - 8, 2006, Los Angeles, California, USA. International Society for Computers and their Applications, 2006. pp 1-8 

5. Prosyk P., Zhereb K."A Criteria-Based Approach to Classifying Traceability Solutions" Proceedings of IEEE International EAST-WEST DESIGN & TEST SYMPOSIUM (EWDTS'07), Yerevan, Armenia. - 7-10 September 2007, p. 622-628.

6. Zachman J. A.,. Sowa J. F, Extending and formalizing the framework for information systems architecture // IBM Systems Journal. 1992, vol. 31, № 3, P. 590-561

7. Мадорская Ю.М. Формирование оценки изменений программного обеспечения АСУП // Научно-технические ведомости СПбГПУ, №I (115) - 2011