Добавлен: 25.10.2018
Просмотров: 4929
Скачиваний: 12
16
В приложении к ПЗ необходимо привести план управления конфигурациями разрабатываемой
системы в соответствии со стандартом IEEE 828-1990. Пример составления плана см. в [55]. Оглавле-
ние плана управления конфигурациями приведено в приложении Е и включает в качестве примера
типовое описание некоторых разделов, которое необходимо адаптировать в соответствии с содержа-
нием выполняемого проекта. Примечание к тому или иному разделу приведено в квадратных скобках
курсивным шрифтом.
Таблица 5
Процедура выбора системы из нескольких альтернатив
j
Показатель
Вес
V
j
(1-
10)
Преимущество
системы №1, U
1,j
(от 1 - минимальное до
10 - максимальное)
Преимущество
системы №2, U
2,j
(от 1 - минимальное до
10 - максимальное)
Преимущество
системы №n, U
n,j
1
Трудоемкость ус-
тановки и на-
стройки
1 2
6
5
2
Удобство сетевого
взаимодействия
4 6
4
8
3 Стоимость 4
10
(бесплатная) 1
(очень дорогая) 5
…
…
…
…
…
ИТОГ 10
F
1
=1x2+4x6+4x10+… F
2
=1x6+4x4+4x1+… F
n
=1x5+4x8+4x5+…
4.7.1.4. План контроля качества программного обеспечения
Переход от штучной разработки АСОИУ к промышленному производству обусловил повы-
шение требований к качеству создаваемых систем. В настоящее время существует несколько стан-
дартов, связанных с оценкой качества этих процессов, например:
• Международные стандарты серии ISO 9000;
• Capability Maturity Model (CMM) – модель зрелости (совершенствования) процессов создания
ПО, предложенная SEI (Software Engineering Institute – Институт технологий программного обес-
печения);
• IEEE 739-1989 Software Quality Assurance Plan (SQAP) – план контроля качества программного
обеспечения.
Управление качеством при проектировании программного продукта (определение необходи-
мого уровня качества и выработка стратегии достижения заданного уровня) предполагает примене-
ние совокупности различных подходов (инспектирование, формальные методы, тестирование, мето-
ды управления проектом) в основе которых лежит использование численных оценок некоторых ха-
рактеристик проекта. Указанные характеристики получили название метрик.
Метрики, которые необходимо использовать при выполнении проекта:
• объем выполненной работы, измеренный в физических единицах (стр. документации);
• время, затраченное на выполнение единицы работы (например, на 1 стр. или 10 стр. документа-
ции);
• степень дефектности (число дефектов на страницу документации).
Предварительные или желаемые значения метрик заранее прогнозируются, а затем сравнива-
ются с полученными результатами.
Когда результаты обнаружения дефектов сравниваются с нормами организации, происходит
оценка всего процесса создания системы в целом, а не только конкретного проекта. Накопленные
данные о дефектах на каждой стадии сводятся в таблицу так, как показано, например, в табл. 6.
Таблица 6
Среднее количество дефектов на каждой стадии проекта
Стадии, на которых бы-
ли обнаружены дефекты
Стадии, содержащие дефекты (в данном проекте / норма)
Формирование требова-
ний
Техническое задание
Эскизный проект
Формирование требова-
ний
2/5
Техническое задание 0,5/1,5
3/1
Эскизный проект 0,1/0,3
1/3
2/2
17
Приведенные в качестве примера данные (табл. 6) свидетельствуют в частности о том, что
при проверке стадии «Формирование требований» степень обнаружения дефектов оказалась меньше
нормы на всех стадиях проекта. Обнаружено больше дефектов проектирования непосредственно на
той фазе, когда они были произведены, в то время как на более поздних фазах было обнаружено
меньше дефектов. Как правило, это достигается посредством проведения инспектирования, под кото-
рым понимается проверка всех этапов и стадий проекта (требований, результатов проектирования,
программного кода и т. п.) на наличие дефектов.
Инспектирование проводит, как правило, группа коллег автора работы, однако в учебных
проектах рекомендуется использовать систему «опеки», когда каждый студент, выполняющий про-
ект, «опекается» своим коллегой и наоборот [55]. Для проведения инспектирования требуется выпол-
нение следующих шагов:
1. Процесс инспектирования начинается с планирования. Планирование включает в себя выбор мет-
рик, по которым будет проводиться инспектирование, а также выбор инструментов для сбора и
анализа полученных данных. Результаты проверяемых этапов проекта должны быть логически
завершены.
2. Подготовка к инспектированию включает описание классификации дефектов, как правило, на три
уровня значимости.
3. Проведение инспектирования в ходе которого инспектирующий заносит все найденные дефекты
в базу данных (например, доступную через сеть) вместе с описанием и классификацией.
4. Если дефекты появляются из-за недопонимания или плохого представления, то организуется
встреча по анализу причин появления дефектов.
5. На окончательном собрании корректор и автор убеждаются в том, что все дефекты исправлены.
Однако это не предполагает детальной ревизии всей работы корректором. Все исправления оста-
ются на совести автора, ответственного за свою работу.
6. Студент-инспектор составляет отчет о проведенной работе, в котором в лаконичной форме (на-
пример, в виде таблицы) приводит информацию о выявленных дефектах. Например, информация
о найденном дефекте на стадии «Эскизный проект» может быть представлена в следующем виде:
№ дефекта – nn
Стадия – Эскизный проект
Этап – Разработка алгоритма функции поиска
Уровень значимости: высокий
Локализация – наличие дефекта в псевдокоде функции, выполняющей анализ дискриминанта.
FUNCTION D(a,b,c as REAL)
D=b^2-4*a*c
IF D > 0
уравнение имеет 2 корня
ELSE уравнение имеет 1 корень
ENDIF
Содержание дефекта:
строка 2: функции присваивается значение дискриминанта, а не результат анализа
строка 3: вариант D<0 и D=0 будет приводить к одному и тому же результату – «уравнение име-
ет 1 корень». Вместе с тем, при D<0 – корни уравнения комплексно-сопряженные.
Отчет, составленный в ходе инспектирования, подписывается автором работы, инспектирова-
ние которой проводилось, и помещается студентом-инспектором в приложение к своей пояснитель-
ной записки.
По итогам анализа и планирования качества проектируемой системы разрабатывается план
контроля качества программного обеспечения в соответствии со стандартом IEEE 730-1989 (Software
Quality Assurance Plan – SQAP), который помещается в приложение ПЗ. Пример составления плана
см. в [55]. Оглавление плана контроля качества программного обеспечения приведено в приложении
Ж и включает в качестве примера типовое описание некоторых разделов, которое необходимо адап-
тировать в соответствии с содержанием выполняемого проекта. Примечание к тому или иному разде-
лу приведено в квадратных скобках курсивным шрифтом. Итоговые значения метрик, собранные при
выполнении проекта и инспектирования, помещаются в раздел 5.2 SQAP.
4.7.1.5. План управления программным проектом
Управление проектом заключается в управлении производством продукта в рамках отведен-
ных средств и времени. Иными словами, управление проектом – это достижение баланса между
18
стоимостью, возможностями, качеством и сроками. Возможность управления появляется тогда, когда
этот баланс оценивается численно [93].
Существует множество стандартов, описывающих создание и поддержание планов управле-
ния программным проектом. В настоящих методических указаниях рекомендуется использовать
стандарт IEEE 1058.1-1987 «План управления программным проектом» (Software Project Management
Plan – SPMP). План управления программным проектом, оформленный в соответствии с IEEE 1058.1-
1987, помещается в приложение ПЗ. Пример составления плана см. в [55].
Принципиальное значение среди всех вопросов, связанных с управлением программным
проектом, имеет проблема управления рисками.
Управление рисками включает в свой состав идентификацию, планирование устранения, вы-
бор приоритетов и устранение (или уменьшение влияния).
В разделе «План управления программным проектом» на страницах ПЗ необходимо описать
работу по управлению рисками проекта, поскольку дальнейшее проектирование системы должно на-
чинаться с аспектов, имеющих наибольший риск.
Оглавление плана управления программным проектом приведено в приложении И. Оно
включает в качестве примера типовое описание некоторых разделов, которое необходимо адаптиро-
вать в соответствии с содержанием выполняемого проекта. Примечание к тому или иному разделу
приведено в квадратных скобках курсивным шрифтом.
Начиная с раздела ПЗ «План управления программным проектом» в конце каждой главы ПЗ
необходимо приводить уточненный план-график (в виде диаграммы Ганта), определяющий, как и
когда должны быть выполнены те или иные этапы проекта. Итоговая версия плана-графика помеща-
ется в разделе 5.5 SPMP.
4.7.2. Формирование требований к АСОИУ (ИМС)
Все требования к проектируемой системе предлагается размещать на нескольких иерархиче-
ских уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для
автоматизированных информационных систем в целом без учета особенностей конкретной приклад-
ной области. Здесь необходимо обратиться к ГОСТам и международным нормативным документам.
Далее следует уровень требований к автоматизированной системе определенного (заданного) класса.
При этом анализируются соответствующие нормативные документы, определяющие порядок и опи-
сание заданного технологического процесса. Например, если на нижнем уровне анализировались
требования к автоматизированным системам в целом, то среднему уровню будут соответствовать
требования к автоматизированным системам управления технологическим процессом или автомати-
зированным системам научных исследований. И наконец, третий уровень составляют требования к
проектируемой системе.
Существует множество подходов решения задачи системного анализа и документирования
требований. В настоящем курсовом проекте для формализации и документирования требований ре-
комендуется использовать спецификацию требований к программному обеспечению (Software Re-
quirements Specification - SRS) в соответствии со стандартом IEEE 830-1993.
В стандарте IEEE 830-1993 проведено деление степени детализации требований на два уров-
ня. Документы первого уровня (спецификации, диаграммы, эскизы и проч.) описывают потребности
заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. На втором уровне
детализации С-требования значительно уточняются, т.е. снабжаются максимально возможным коли-
чеством деталей. Такой набор документов называют требованиями разработчика, или D-
требованиями.
Большая часть анализа требований является коммуникационной деятельностью, тщательно
организованной для получения наилучших результатов.
4.7.2.1. C- требования
Заказчики разрабатывают концепцию, часто подсознательную и неполную, того, как их при-
ложение будет работать. Эту концепцию иногда называют моделью приложения, или концепцией
работы. Для формализации концепции работы приложения, представленной заказчиком, инженеры
могут использовать комбинации следующих подходов:
• Методология SADT (SADT – Structured Analysis and Design Technique), представляющая собой
набор методов, правил и процедур, предназначенных для построения структурно-
19
функциональной модели объекта какой-либо предметной области [60, 84, 92] с помощью широ-
кого спектра диаграмм: IDEF0, IDEF3, DFD, ERD и т.д.
• Для выражения взаимодействия приложения с внешним пользователем используют диаграммы
вариантов использования (use case) UML (описание нотации UML, как правило, всегда встреча-
ется в литературе, посвященной проектированию ИС, например [55, 56, 60, 62, 86, 88, 101, 103]).
Варианты использования в последующем могут быть применены для выбора классов, а также для
разработки прототипа.
• Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования про-
граммного обеспечения, однако его также можно считать и частью фазы формирования требова-
ний. Вопросам проектирования и дизайна пользовательского интерфейса посвящена обширная
литература. В настоящих МУ рекомендуется воспользоваться подходами, изложенными в [35, 39,
45, 85].
В большинстве случаев при проектировании корпоративных систем для каждого варианта ис-
пользования составляется комплект из трех диаграмм:
• диаграммы последовательности (sequence diagram) UML отражают коммуникационный аспект
реализации варианта использования и включают в свой состав объекты и сообщения между ни-
ми;
• диаграммы деятельности (activity diagram) UML отражают управленческий аспект реализации
варианта использования и включают в свой состав деятельности, состояния, решения, знаки син-
хронизации, а также переходы между ними;
• диаграммы классов (class diagram) UML отражают структурный аспект реализации варианта ис-
пользования и включают в свой состав классы, объекты, экземпляры, а также связи между ними.
Поскольку С-требования предназначены, прежде всего, для заказчиков, диаграммы, исполь-
зуемые для документирования требований на начальной стадии, как правило, имеют упрощенную
форму, которая подчеркивает лишь основные концептуальные моменты, а не детали, которые могут
затруднять чтение и понимание диаграмм заказчиком.
На стадии формирования С-требований выполняется эскиз пользовательского интерфейса,
который представляет собой лишь перечень интерфейсных элементов, достаточных для обеспечения
функционального назначения программной системы. Аргументированное расположение интерфейс-
ных элементов на форме, их группировка, выбор размеров, цветовой палитры и т.д. осуществляется
на базе концепции ГПИ, представленной в параграфе D-требования.
Как только С-требования собраны, как правило, возникает необходимость обновления SPMP.
Такое обновление происходит в течение всего жизненного цикла системы.
После анализа С-требований также может быть уточнена оценка стоимости системы.
Задача формулирования и корректного управления требованиями становится нетривиальной,
если количество требований исчисляется несколькими десятками. Вопросам формализации решения
этой задачи посвящена обширная литература, англоязычная и русскоязычная части которой доста-
точно полно представлены в работах [13] и [56, 81, 99], соответственно. Кроме того, разработаны и
успешно используются инструментальные CASE-системы управления требованиями (например, Re-
quisitePro, DOORS [99] и др.), которыми рекомендуется воспользоваться в процессе выполнения КП.
4.7.2.2. D-требования
Разработчикам программного обеспечения нужна база для проектирования и разработки. Эта
база представляет собой детальные требования (D-требования). D-требования состоят из полного
списка конкретных свойств и функциональности, которую должна иметь программа. Каждое из этих
требований пронумеровано, помечено и отслеживается по ходу разработки. D-требования должны
быть согласованы с С-требованиями.
Существуют несколько типов D-требований:
1. Функциональные требования – определяют работу, которую должна выполнять проектируемая
система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
2. Нефункциональные требования.
2.1. Производительность. Требования к производительности определяют временные ограничения,
которые должны быть выполнены в программе. Заказчики и разработчики обсуждают огра-
ничения по времени вычислений, использованию оперативной памяти, объему запоминаю-
щих устройств и т. д.
2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых
величинах. Требования такого типа предполагают вероятность неидеальной работы про-
20
граммы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уде-
лить вопросам обеспечения безопасности системы с учетом возможности искажения данных
посредством несанкционированного доступа, сбоя системного или прикладного ПО.
2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать
на возникающие ошибки. Например, что должна делать программа, если она получает сооб-
щение из другой программы в неразрешенном формате? Это не касается ошибок, генерируе-
мых самой программой.
2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором про-
грамма общается с окружением.
2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или усло-
вия того, как приложение должно быть задумано и разработано. Например, накладываются
ограничения на инструменты и языки программирования ввиду сложившихся традиций ор-
ганизации, опыта программистов, совместимости и проч.
3. Обратные требования – это функционал, который система не обеспечивает.
Типичная последовательность получения функциональных D-требований с использованием
объектно-ориентированного подхода приведена ниже:
1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н.
классы анализа.
2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы пред-
метной области.
3. Для каждого из полученных классов выписывается вся необходимая функциональность програм-
мы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут клас-
са Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод
класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть оп-
ределены. В это же время должны быть разработаны и планы тестирования для каждого D-
требования (см. ниже).
4. D-требования проверяются и сравниваются с С-требованиями.
5. D-требования проверяются заказчиком и, затем, публикуются.
Особое внимание необходимо уделить вопросу получения классов анализа, поскольку –
это творческий процесс, тесно связанный с анализом информации о предметной области.
При получении классов анализа необходимо учитывать следующие аспекты:
1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предмет-
ной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации
его назначения. Однако для реализации своего назначения класс должен иметь минимальное ко-
личество связей с другими классами.
2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень
высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на
несколько операций уровня проекта.
3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой
ошибкой при построении иерархии наследования является использование функциональной де-
композиции, где каждый уровень абстракции имеет только одну операцию. Наследование ис-
пользует только там, где есть явная иерархия наследования, вытекающая непосредственно из
предметной области.
4. При выявлении классов посредством анализа текста С-требования, существительные указывают
на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы
могут стать причиной появления ложных классов.
5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-
Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.
Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования
под управление конфигурациями.
На протяжении всего процесса проектирования необходимо прилагать усилия по планирова-
нию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно
с требованиями. Во-первых, это позволяет прояснить требование. Во-вторых, это переносит некото-
рую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например,
SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого
студента информационной системы «Деканат» будет представлять собой строку от 1 до 256 симво-