Метод оценки сложности модификации программного обеспечения АСУП

• Автор: Мадорская, Юлия Михайловна
• Шифр специальности: 05.13.06
• Научная степень: Кандидатская
• Год защиты: 2011
• Место защиты: Санкт-Петербург
• Количество страниц: 170 с. : ил.

Оглавление
ОГЛАВЛЕНИЕ.
ВВЕДЕНИЕ.

1 МЕТОДЫ ФОРМИРОВАНИЯ ОЦЕНКИ ИЗМЕНЕНИЙ ПО АСУП.

1.1 Задлчл формирования оценки изменений ПО АСУП.

1.2 Обзор современных методов ФОИ.

1.3 КОНЦЕПЦИЯ ФОИ ДЛЯ ПЛАНИРОВАНИЯ МОДИФИКАЦИИ АСУП.

ВЫВОДЫ ПО ГЛАВЕ 1

2 МОДЕЛЬ ТРАССИРОВКИ ТРЕБОВАНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АСУП.

2.1 Метод ПОСТРОЕНИЯ МОДЕЛИ ТРАССИРОВКИ.

2.2 Анализ структур и методов описания требований к по асуп.

2.3 Базовая модель трассировки ПО.
2.4 модель трассировки ПО АСУП
Вь вОДЫ ПО ГЛАВЕ 2.
3 КОМПЛЕКС РЕШЕНИЙ ДЛЯ ФОИ В ПРОЦЕССАХ ПЛАНИРОВАНИЯ МОДИФИКАЦИИ АСУП
3.1 Структура комплекса решений.
3.2 Подход к формализации описания требований и согласованная система определений.
3.3 Классификация ошибок в требованиях
3.4 Базовый метод ФОИ.
3.5 Метод ФОИ для АСУП
Выводы по главе 3
4 РЕАЛИЗАЦИЯ МЕТОДА ФОИ В СЕМАНТИЧЕСКИ СВОБОДНОЙ СИСТЕМЕ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ
4.1 Выбор инструментальной среды.
4.2 Функциональные возможности СяаХЕ для реализации метода ФОИ для АСУП.
4.3 Схема реализации метода ФОИ для АСУП в системе Сяаоее
4.4 Применение метода ФОИ для АСУП при создании и сопровождении АСТПП МСБ.
4.5 Применение метода ФОИ АСУП для оценки изменений при создании и сопровождении СМК компании . 6 Выводы по главе 4.
ЗАКЛЮЧЕНИЕ.
СПИСОК ЛИТЕРАТУРЫ


Это заставляет пересмотреть накопленный опыт ФОИ - изменить алгоритмы анализа проектных данных и методики перевода объема изменений. Если объем изменений выражен то в «мартышках», то в «попугаях» [], невозможно по обратной связи сравнивать эффективность применяемых технологий разработки и оценивать квалификацию специалистов, а значит учитывать влияние этих факторов при планировании модификации АСУП. Несравнимость оценок, также препятствует эффективному межпроекгному планированию, что является необходимым условием поддержания конкурентоспособности- организации. Большой объем, множественность и многомерность представления исходных данных на каждом этапе жизненного цикла. II. Неполнота описания связей, отражающих направления распространения изменений. Наличие ошибок в требованиях и связях между ними. Несравнимость оценок из-за различных технологий проектирования у разных команд и изменения технологий в ходе жизненного цикла АСУП. Перечисленные проблемы отражают сложность организации проектирования интеллектуального продукта в ограниченные сроки и являются объективными характеристиками процессов разработки и сопровождения ПО. ОРИ является ключевой информацией, определяющей ход каждой итерации модификации системы. Повышение точности и сокращение времени ФОИ является необходимым условием повышения точности и сокращения времени планирования модификации АСУП. ОРИ для систем класса АСУП рассчитывается на основании анализа моделей, представляющих требования к системе. Процесс ФОИ основан на процессе проектирования, поэтому слабо формализуем. Точно определить ОРИ можно только после выполнения всех изменений. ОРИ на этапе планирования работ всегда рассчитывается на неполных данных, так как в приемлемые для принятия решения сроки, невозможно не только провести полное проектирование, но и собрать все данные, необходимые для анализа. Таким образом, основное направление повышения точности и сокращения времени ФОИ - это устранение проблем обработки исходных данных и создание условий для накопления опыта ФОИ экспертом. При ФОИ для систем класса АСУП эксперт сталкивается с пятыо основными проблемами. Совместное решение этих проблем позволит повысить точность и сократить время планирования модификации АСУП. Понятие «требование» является одним из ключевых понятий как в рамках всей дисциплины «Инженерия программного обеспечения», гак и задачи ФОИ. Процесс разработки программного обеспечения начинается с определения требований, завершается проверкой на соответствие требованиям и является по сути процессом перевода неформализованных требований заказчика в программный код, реализующий данные требования. Для решения задачи ФОИ необходимо обеспечить трассируемость требований, для чего используются модели трассировки требований (МТ). Состав и объем данных, который попадет в ОРИ, полностью зависит от того, какую именно информацию, используемую при разработке системы, относят к требованиям, поэтому при разработке и использовании метода ФОИ важно опираться на четкое, семантически однозначное определение понятия требование. К сожалению, в инженерии программных систем до сих пор не сложилось устойчивого формального определения понятия «требование», которое бы использовалось и однозначно интерпретировалось всеми участниками процесса разработки. Несмотря на то, что теме разработки требований к программным системам посвящено множество публикаций, обзор литературы показывает, что понятие требования определено плохо, о чем явно упоминают авторы различных публикаций []. Отсутствие общепринятых определений терминов, которыми пользуются для описания требований, признается одной из проблем индустрии программного обеспечения []. Определение понятия «требование» игнорируется, дается в неоднозначной форме, сводится к какому-либо частному случаю или подклассу. Это приводит к различным проблемам, в том числе к тому, что при использовании МТ невозможно понять границы категорий, однозначно соотнести проектные данные с категориями МТ, однозначно определить трассировочные связи. Также невозможно формально определить ошибки в требованиях, а значит обеспечить их контроль.