Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
Связь качества программного обеспечения и инженерии требований – понимания процесса проверки реализация тре- бований, при их трансформации на более низкий уро- вень. [50] На разных уровнях используются различные виды моделей. Для формирования пользовательских требований (stakeholder requirements) можно ис- пользовать пользовательские сценарии (stakeholder scenarios). При переходе к системным требованиям могут использоваться различные типы функциональных мо- делей. Например, UML-диаграммы: диаграммы клас- сов (class diagrams), диаграммы последовательности сообщений (message sequence charts) и диаграммы со- стояний (state charts). При переходе от системных требований к архи- тектуре, большее значение начинают играть различные аспекты производительности создаваемой системы. В этом случае несколько различных типов моделей могут быть использованы для того, чтобы продемонстриро- вать то, что выбранная архитектура может удовлетво- рить как функциональным, так и нефункциональным требованиям. Как уже было отмечено, требования тесно свя- заны с тестированием. Под тестированием можно по- нимать любое действие, направленное на выявление и предотвращение дефектов в системе, где дефект — это отклонение от требований. Таким образом, в допол- нении к классическим методам тестирования добав- ляются рецензирование, инспектирование и анализ с использованием моделирования. Тестирование начинается на этапе разработки спецификаций системы (design) и состоит в рецензи- ровании требований, инспекции спецификаций и при- менении различных форм моделирования системы. 32 Методы оценки и измерения характеристик информационных систем На рисунке 14 продемонстрирована V-модель цикла разработки требований и стратегия проверки системы. Как уже отмечалось, системное проектирование является жизненно важным процессом для бизнеса, поскольку, с его помощью, принятые решения опреде- ляют возможности выхода на рынок с «правильным» продуктом. Для разграничения зон ответственности и ускорения принятие решений на первоначальном эта- пе разработки, необходимо четкое разделение между «областью проблем» и «областью решения» конкрет- ного проекта. К проблемной области следует отнести: – формулировку проблем; – модели использования; – пользовательские требования. Рисунок 14 – Стратегия проверки системы в соответствии с циклом разработки [50] 33 Связь качества программного обеспечения и инженерии требований Начиная с системных требований, все должно быть, отнесено к области решения. В таблице 2 пред- ставлено «идеальное» разделение между проблемной областью и областью решения, а также сформулирова- ны цели, которым должны удовлетворять требования трех верхних уровней. Таблица 2 – Краткое описание областей решений и проблем [50] Уровень требований Область Точка зрения Цель Пользова- тельские требования Область проблем Представи- тели заинте- ресованных сторон Определяет – что пользователь хочет достичь с помощью создаваемой системы. Системные требования Область решений Аналитик Абстрактно опреде- ляет – как система будет удовлетворять пользовательским требованиям. Системные специфика- ции (архитекту- ра) Область решений Архитектор Определяет – как кон- кретная архитектура системы будет удов- летворять системным требованиям. Описание области проблем должно содержать возможности системы и всё, что необходимо, для оп- ределения проблем, при этом не должна содержать ни- чего, что определяет конкретные решения. Благодаря этому, системные инженеры не ограничиваются в вы- боре наилучшего решения проблемы. Моделирование, помогая переходить от уровня к уровню, тоже может привносить элементы конкрет- 34 Методы оценки и измерения характеристик информационных систем ных решений, уже даже на верхнем уровне. Для того чтобы избежать уклона в плоскость решения, на ран- них этапах лучше применять моделирование только для описания системы (подсистемы). Отсутствие четкого разделения между проблема- ми и решениями, может привести к следующим нега- тивным последствиям: – недостаточное понимание существующих проблем; – невозможность определить границы (масштаб) системы и понять какой функционал должен в нее вхо- дить, а какой нет; – доминирование разработчиков и исполните- лей в дискуссиях о системе, поскольку единственное описание, существующее для системы, описывает ее в терминах реализации, а не в формулировках проблем; – невозможность нахождения наилучшего реше- ния из-за ограничений свободы в выборе решения [50]. В связи с большой сложностью и обширностью области требований в проектах, необходим процесс управления ими. Сопоставив информацию, можно вы- делить три стадии этого процесса (Рисунок 15): – планирование; – разработка; – управление изменениями [50-58]. Рисунок 15 – Стадии процесса управления требованиями 35 Связь качества программного обеспечения и инженерии требований Процесс управления требования начинается с планирования. На этапе планирования системный аналитик создает план управления требованиями и шаблоны необходимой документации. Планирование – первый шаг при работе с требованиями, он начина- ется на этапе предпроектного обследования [54]. План управления требованиями является одним из наиболее важных документов в процессе управле- ния требованиями. В данном документе определяются типы требований и атрибуты каждого типа, отноше- ния между требованиями, документы, использующие- ся в данном процессе. Также системный аналитик оп- ределяет и заносит в план решение об использовании специального инструментального средства для уп- равления требованиями. Расширенный вариант плана управления требованиями может содержать описание ролей, участвующих в процессе; задач, выполняемых каждой ролью, и другую служебную информацию. Как было сказано выше, на этапе планирования также создаются шаблоны необходимых документов: глоссария, технического задания, документа-концеп- ции. При работе с государственным заказчиком для опи- сания требований чаще всего используется техническое задание, разработанное в соответствие с ГОСТ 34.602- 89 или ГОСТ 19.201-78. Если нет жестких требований со стороны заказчика на соответствие государственным стандартам, можно использовать спецификацию требо- ваний на основе стандарта IEEE 830-1998. [59] Современные инструментальные средства позво- ляют создавать автоматические отчеты с необходимой информацией. Если принято решение о том, что доку- ментация будет создаваться автоматически с использо- ванием отчетов, на этапе планирования необходимо со- здать шаблоны таких отчетов. Шаблоны отчетов, также 36 Методы оценки и измерения характеристик информационных систем как и шаблоны документов, должны быть разработаны с учетов требований государственных стандартов. Как уже говорилось ранее, планирование являет- ся начальным этапом в работе с требованиями и пред- ставляет собой входную точку в процесс разработки и управления требованиями. Основные результаты пла- нирования требований представлены ниже: – методология и процесс разработки програм- много обеспечения; – роли участников проекта и выполняемые ими задачи; – список участников проекта и их навыки; – различные регламенты работ в части выявления, документирования, согласования требований и др.; – план управления требованиями; – шаблоны документов [54]. Все результаты планирования необходимо согла- совывать с руководителем проекта, так как он должен быть в курсе всех аналитических задач и их распреде- ления между членами команды. Методологию, процессы, типы требований, шаб- лоны документов, регламенты проверки требований и управления изменениями необходимо согласовывать с процессами разработки и тестирования. Для того чтобы чётко понимать процесс разра- ботки требований, который будет в полной мере соот- ветствовать плану, необходимо рассмотреть каждый его этап. В зависимости от масштаба компании и слож- ности задач, которые стоят при реализации проектов, количество этапов может различаться. Процесс разра- ботки требований содержит следующие этапы: Идентификация заинтересованных сторон. Выявление требований заинтересованных сторон. 1. 2. 37 Связь качества программного обеспечения и инженерии требований Формирование требований. Уточнение и переформулирование требований. Анализ требований. Приведение требований к виду одинаково по- нятному для всех заинтересованных сторон. Определение критериев приёмки требований. Определение стратегии проверки требований. Создание тестов. . Спецификация требований. Определение приоритетов требований. . Выведение зависимых требований. Классификация требований. Распределение требований. Отслеживание требований. Тестирование требований. Проверка требований. Утверждение требований. [50; 51; 52; 53; 60] 1.3 Влияние инженерии требований на качество программного обеспечения Существует большое количество методов обеспе- чения качества программного обеспечения, но одним из самых эффективных можно считать инженерию требований. Учитывая сущность качества програм- много обеспечения, как совокупности свойств, можно представить их в качестве требований и применить к ним соответствующие процедуры. В результате, меха- низмы управления требованиями позволят в полной мере формировать перечни требуемых свойств и от- слеживать их на всех этапах жизненного цикла про- граммного обеспечения. Таким образом, контроль качества будет осу- ществляться за счёт контроля над реализацией задан- ных требований. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 38 Методы оценки и измерения характеристик информационных систем 2. Метрики качества программного обеспечения 2.1 Факторы, влияющие на качество программного обеспечения Проектирование программных средств сопро- вождается анализом взаимодействия факторов, влия- ющих на качество конечного продукта. К таким фак- торам относятся [45]: • назначение, содержание и описание функциональ- ных и конструктивных характеристик, субхарактеристик и атрибутов, определяющих специфические особеннос- ти свойств и качества программного средства; • метрики, меры и шкалы выбранных и пригод- ных для измерения и оценивания конкретных характе- ристик и атрибутов качества программных средств; • внешние и внутренние негативные факторы, влияющие на достигаемое качество программных средств; • доступные ресурсы, ограничивающие возмож- ные величины реальных характеристик качества про- граммных средств; • доступные ресурсы, ограничивающие возмож- ные величины реальных характеристик качества про- граммных средств. Взаимодействие перечисленных факторов пока- зано на рисунке 16. Степень влияния указанных факторов на качест- во программного средства зависит, в первую очередь, от требований к его функционалу, а также от его на- значения. Общее пространство характеристик качест- ва разделено на две различные группы: • функциональные характеристики; • конструктивные характеристики. 39 Метрики качества программного обеспечения Функциональные характеристики определяют назначение, свойства и задачи, которые решаются про- граммным средством для основной группы пользова- телей. Специфику этих характеристик сложно унифи- цировать, поскольку они весьма разнообразны, а кате- горизация возможна только при большом количестве категорий и свойств. В силу своей высокой значимости, подобные характеристики, в совокупности, представля- ют собой основную цель создания программного средс- Рисунок 16 – Факторы качества программных средств 40 Методы оценки и измерения характеристик информационных систем тва, а также его самую главную характеристику. Набор этих характеристик называется функциональной при- годностью и описывается в ISO 9126. Конструктивные характеристики, в отличие от функциональных, могут быть унифицированы, адаптированы и использованы для выявления дру- гих характеристик (внутренних и внешних) качес- тва, способствующих реализации главных функци- ональных требований к качеству объектов и про- цессов жизненного цикла программных средств. Таким образом, они поддерживают и обеспечивают высокое качество реализации функций программно- го средства. В соответствии с нормативными доку- ментами, перечень конструктивных характеристик состоит из: • корректность; • защищённость; • надёжность; • ресурсная эффективность; • практичность; • сопровождаемость; • мобильность. Выбор этих характеристик определяется требо- ваниями к функциональной пригодности программно- го средства. 2.2 Внутреннее и внешнее качество программного обеспечения Согласно международному стандарту ISO 9126 качество программных средств следует описывать тремя составляющими: • внутренне качество – формируется в процессе разработки и других этапах жизненного цикла про- граммного средства; 41 Метрики качества программного обеспечения • внешнее качество – определяется требования- ми заказчика и отражается в характеристиках конечно- го продукта; • в процессе эксплуатации – представляется ре- зультативностью достижения пользовательских пот- ребностей с учётом затрат. Измерение качества программного средства можно производить двумя способами: • внутренне – статистический анализ програм- много кода; • внешне – поведенческий анализ программного кода при исполнении. Все эти типы метрик могут быть использованы для определения требований к качеству программно- го средства на всех этапах его жизненного цикла. При этом внутренние атрибуты качества являются основой для достижения требуемого внешнего поведения, ко- торое непосредственно влияет на достижения качест- ва в процессе эксплуатации. Внешнее качество – степень, в которой продукт удовлетворяет установленным и зафиксированным потребностям в среде эксплуатации определёнными пользователями для достижения заданных целей с не- обходимой результативностью, производительностью и качеством [45]. Метрики внешнего качества фор- мируются при помощи различных испытаний, опыт- ной эксплуатации и наблюдения и используются для наблюдения за качеством со стороны разработчиков, заказчиков и пользователей. Разработка программных средств подразумевает поэтапное создание промежуточных продуктов (вер- сий), которые ведут к финальному продукту. Создан- ные промежуточные версии оцениваются при помощи внутренних метрик, отражающих некоторые функ- 42 Методы оценки и измерения характеристик информационных систем циональные и конструктивные свойства программ. Подобные метрики применяются к неисполняемым компонентам программных средств (спецификации, исходный код). Внутренние метрики позволяют разра- ботчикам, испытателям и заказчикам оценивать качес- тво жизненного цикла программных средств, а также управлять технологическим обеспечением качества до момента создания готового конечного продукта. Структура процесса формирования внутренних метрик представлена на рисунке 17. Рисунок 17 – Структура процесса подготовки внутренних метрик 43 Метрики качества программного обеспечения 2.3 Качество при использовании в процессе эксплуатации Качество при использовании в процессе эксплу- атации отражает степень удовлетворённости потреб- ностей пользователей продуктом в достижении требу- емых целей с результативностью, продуктивностью и удовлетворённостью в заданных условиях. Под результативностью понимается точность и полнота достижения заданных целей пользователями при применении программного средства. Продуктив- ность представляет собой соотношение потраченных ресурсов и результатов при эксплуатации программно- го средства. Удовлетворённость, в свою очередь, под- разумевает технологическое и психологическое отно- шение к качеству процессов и результатов применение программного продукта. Данная метрика напрямую не регламентируется стандартом ISO 9126, поскольку является слишком общей, однако рекомендуется как составная часть интегральной оценки функциониро- вания и использования программных средств. Качество при использовании в процессе эксплуа- тации – это объединённый эффект функциональных и конструктивных характеристик качества программно- го средства для пользователя [45]. Связь с внешним и внутренним аспектами ка- чества программного средства зависит от типа и задач пользователей: • для конечного пользователя качество в процес- се эксплуатации программного средства определяется характеристиками функциональных возможностей, надежности, практичности и эффективности; • для персонала сопровождения качество в про- цессе эксплуатации программного средства характе- ризуется непосредственно сопровождаемостью; 44 Методы оценки и измерения характеристик информационных систем • для персонала по внедрению качество в процес- се эксплуатации программного средства определяется, прежде всего, мобильностью. Результаты оценивания данного аспекта качест- ва могут различаться для сценариев и задач отдельных пользователей. Для крупных программных средств практически не возможно измерить все внутренние и внешние характеристики качества со всеми атрибу- тами, аналогично не оцениваются и все возможные сценарии. Происходит ранжирование сценариев по приоритетам, а затем производится оценивание харак- теристик, с учётом рационального распределения име- ющихся ресурсов. Качество при использовании в процессе экс- плуатации характеризуется эффектом и сложностью использования программного средства, описываемые трудоёмкостью с требуемой результативностью. |