Фонд оценочных средств профессионального модуля
 Скачать 6.85 Mb.
|
|
Практическая работа №12 Построение физической схемы Цель работы: Освоить процесс построения физической модели и генерации схемы данных. Ход работы: 1. Построение логической модели • Откройте программу Пуск – Программы – Computer Associates Erwin 4.0 - Erwin 4.0. • В открывшемся окне выберите Greate a new model (создать новую модель). • В открывшемся окне выберите тип модели Logical/ Physical (логическая /физическая). В этом же окне в пункте Target Database выберите Acсess и установите версию 2000. Нажмите ОК. • Постройте логическую модель базы данных. В автохозяйстве организации имеются несколько автомобилей. Каждый автомобиль приписан к опре-деленному гаражу. За каждым сотрудником закреплены определенные автомобили. Для работы сотрудники организации могут использовать любой автомобиль, на который выписан путевой лист. База данных должна содержать государственные номера марку и цвет машин, отметку о прохожде-нии последнего техосмотра и его дату, номера и адреса гаражей, ФИО начальников гаражей, табельные номера сотрудников, их ФИО, должности. В путевом листе отражаются пункты отправления и назначения, время выезда и прибытия, пройденный километраж. 2. Построение физической модели. Экспорт модели с MS Access. • В раскрывающемся списке, расположенном в правой части панели инструментов, выберите пункт Physi-cal. Erwin автоматически генерирует физическую модель данных для конкретной СУБД на основании ло-гической модели по следующему принципу: сущности становятся таблицами, атрибуты – столбцами, а ключи – индексами. • Прежде чем приступать к генерации физической схемы базы данных создайте новую базу данных в Ac-cess. • В программе Erwin выполните команду Tools | Forward Engineer/Schema Generation. • Щелкните по кнопке Generate. В диалоговом окне Access Connection установите связь с созданной базой данных, заполнив все предложенные поля: 1. Connection UserName – admin; 2. пароль – пусто; 3. Database - путь на базу; 4. SystemDatabase - путь на system.mdw (C:\Documents and Settings\Admin\Application Data \Microsoft\Access). В случае установления соединения будет выполняться SQL-скрипт. Если в процессе генерации возника-ют ошибки, то она прекращается, открывается окно с сообщениями об ошибках. 3. Построение логической модели. Импорт базы данных в Erwin. • Создайте новую модель. Установите тип модели Logical/ Physical. В этом же окне в пункте Target Database выберите Acсess и установите версию 2000. Нажмите ОК. • В программе Erwin выполните команду: Tools - Revers Engeneer. Пункт задания параметров базы данных можно пропустить. • В диалоге Access Connection задайте: 1. Connection UserName – admin; 2. пароль – пусто; 3. Database - путь на базу (база данных Студент в вашей папке); 4. SystemDatabase - путь на system.mdw (C:\Documents and Settings\Admin\Application Data \Microsoft\Access). Задание для самостоятельного выполнения: 1. Построить логическую и физическую модель базы данных. Экспортировать полученную модель в Access. Задание: Вы работаете в страховой компании. Вашей задачей является отслеживание финансовой деятельности компании. Компания имеет различные филиалы по всей стране. Каждый филиал характеризуется названием, адресом и телефоном. Деятельность компании организована следующим образом: к вам обращаются различные лица с целью заключения договора о страховании. В зависимости от принимаемых на страхование объектов и страхуемых рисков договор заключается по определенному виду страхования (например, страхование автотранспорта от угона, страхование домашнего имущества, добровольное медицинское страхование). При заключении договора вы фиксируете дату заключения, страховую сумму, вид страхования, тарифную ставку и филиал, в котором заключался договор. 2. Построить логическую модель базы данных. Импортировать базу данных в Erwin. Практическая работа №13 Построение диаграмм вариантов использования Цель работы: научиться строить диаграмму вариантов использования. Теоретическая справка: Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы вариантов использования преследует цели: Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. Сформулировать общие требования к функциональному поведению проектируемой системы. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Состав диаграммы Use Case Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии. Виды взаимодействий Между актерами и вариантами использования могут быть различные виды взаимодействия. Основные виды взаимодействия следующие: Простая ассоциация - отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использованияпросматривать заказ. Направленная ассоциация - то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой. Наследование - показывает, что потомок наследует атрибуты и поведение своего прямого предка. Может применяться как для актеров, так для вариантов использования. Расширение (extend) - показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений "включение" расширенная последовательность может осуществляться в зависимости от определенных условий. Включение (include)- показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан). Существуют и другие виды взаимодействия, но они менее важны и реже применяются. Задание 1. Построить диаграмму вариантов использования модели вариантов использования банкомата. Выполните следующие действия: Добавить актера с именем Клиент банкомата. Добавить вариант использования Снятие наличных по кредитной карте Добавить направленную ассоциацию от бизнес-актера Клиент Банкомата к варианту использования Снятие наличных по кредитной карте Добавить вариант использования Проверка ПИН-кода.  Добавить актера с именем Банк. Добавить вариант использования Получение справки о состоянии счета. Добавить вариант использования Блокирование кредитной карточки. Добавить направленную ассоциацию от бизнес-актера Клиент Банкомата к варианту использования Получение справки о состоянии счета. Добавить направленную ассоциацию от варианта использования Снятие наличных по кредитной карточке к сервису Банк. Добавить направленную ассоциацию от варианта использования Получение справки о состоянии счета к сервису Банк. Добавить отношение зависимости со стереотипом «include», направленное от варианта использования Снятие наличных по кредитной карте к варианту использования Проверка Пин-кода. Добавить отношение зависимости со стереотипом «include», направленное от варианта использования Получение справки о состоянии счета к варианту использования Проверка Пин-кода. Добавить отношение зависимости со стереотипом «extend», направленное от варианта использования Блокирование кредитной карточки к варианту использования Проверка Пин-кода. Задание 2. Построить диаграмму вариантов использования. Имеются следующие данные: четыре действующих лица: Клиента банка, Банк, Кассира и Оператора, пять вариантов использования: Снять наличные, Перевести деньги со счета, Положить деньги на счет, Пополнить запас денег и Подтвердить пользователя, три Варианты использования: Снять наличные, Перевести деньги со счета, Положить деньги на счет - требуют включения идентификации клиента в системе. Это поведение может быть выделено в новый вариант использования включения, называемый Подтвердить пользователя. Базовые варианты использования не зависимы от метода, используемого для идентификации. Поэтому он инкапсулируется (скрывается) в варианте использования включения. С точки зрения базовых вариантов использования не имеет значение производится ли идентификация с помощью магнитной карты или сканированием сетчатки глаза. Они только зависят от результата выполнения варианта использования Подтвердить клиента. Задание для самостоятельной работы: Построить диаграмму вариантов использования на основе вербальной модели информационной системы «Компьютерный клуб» Контрольные вопросы: Какие цели преследует разработка диаграммы использования? Для чего нужна диаграмма вариантов использования? Из чего состоит диаграмма вариантов использования? Виды взаимодействия используемые в диаграмме вариантов использования? Из чего состоит созданная вами диаграмма? Практическая работа №14 Построение диаграмм классов анализа Изучить инструкционно-технологическую карту Познакомиться с программным средством CASEBERRY Изучить основные элементы диаграммы классов. Повторить общие сведения о диаграммах классов Построить диаграмму классов Сформировать отчет по практической работе №7 После того, как мы определились с функциональными требованиями к системе и её границами, начнём анализировать предметную область с целью построения диаграммы классов. Основные элементы диаграммы классов  Основными элементами являются классы и связи между ними. Классы характеризуются при помощи атрибутов и операций. Атрибуты описывают свойства объектов класса. Большинство объектов в классе получают свою индивидуальность из-за различий в их атрибутах и взаимосвязи с другими объектами. Однако, возможны объекты с идентичными значениями атрибутов и взаимосвязей. Т.е. индивидуальность объектов определяется самим фактом их существования, а не различиями в их свойствах. Имя атрибута должно быть уникально в пределах класса. За именем атрибута может следовать его тип и значение по умолчанию. Операция есть функция или преобразование. Операция может параметризоваться и возвращать значения. Виды связей: ассоциация, агрегация и наследование. Ассоциация (association) - представляет собой отношения между экземплярами классов. Каждый конец ассоциации обладает кратностью (синоним - мощностью, ориг. —multiplicity), которая показывает, сколько объектов, расположенных с соответствующего конца ассоциации, может участвовать в данном отношении. В примере на рисунке каждый Товар имеет сколь угодно Записей в накладной, но каждая Запись в накладной обязательно один Товар. В общем случае кратность может быть задана любым множеством. Ассоциации может быть присвоено имя. В качестве имени обычно выбирается глагол или глагольное словосочетание, сообщающие смысл и назначение связи. Также, на концах ассоциации под кратностью может указываться имя роли, т.е. какую роль выполняют объекты, находящиеся с данного конца ассоциации. Агрегация (aggregation) - это ассоциация типа «целое-часть». Агрегация в UML представляется виде прямой с ромбом на конце. Ромб на связи указывает, какой класс является агрегирующим (т.е. «состоящим из»), — класс с противоположного конца —агрегированным (т.е. те самые «части»). Композиция (composition) - это такая агрегация, где объекты-части не могут существовать сами по себе и уничтожаются при уничтожении объекта агрегирующего класса. Композиция изображается так же как ассоциация, только ромбик закрашен. Важно понимать разницу между агрегацией и композицией: при агрегации объекты-части могут существовать сами по себе, а при композиции — нет. Пример агрегации: автомобиль—колесо, пример композиции: дом—комната. Наследование (inheritance)- это отношение типа «общее-частное». Позволяет определить такое отношение между классами, когда один класс обладает поведением и структурой ряда других классов. При создании производного класса на основе базового (одного или нескольких) возникает иерархия наследования. Реализация принципов наследования является ключевой предпосылкой возможности повторного использования кода, поскольку это основной инструмент достижения полиморфизма. Порядок построения диаграммы классов Создаём новую диаграмму с именем «Сущности». Проанализируйте предметную область и постройте диаграмму классов. У вас должно получиться нечто подобное: Давайте поподробнее рассмотрим эту диаграмму. Основной сущностью в нашей системе будет являться товар. Как мы знаем из задания на проектирование, товар хранится на складе. Но понятия товара как некоего описания и товара лежащего непосредственно на складе отличаются друг от друга. Товар, лежащий на складе, кроме того что связан со складом отношением композиции (агрегация не совсем подходит, поскольку в данной системе товар является товаром, пока он не покинет склад), ещё характеризуется количеством. Аналогично следует рассуждать и при рассмотрении отношения Товара иЗаказа, Товара и Накладной. В связи с тем, что Заказ и Накладная в сущности являются документами и имеют сходные атрибуты, они были объединены с помощью общего класса- предка Документ. Также заметьте, что тут есть два класса со стереотипом «Enumeration» (перечисление). Стереотип можно установить из контекстного меню для класса.  3. Сохраните диаграмму Перечень вопросов на экзамен 1.Обзор программных продуктов (изделий). 2.Жизненный цикл ПО. Модели жизненного цикла ПС. 3.Каскадная модель жизненного цикла ПС. Усовершенствование каскадной модели ЖЦ ПС. 4.Спиральная модель ЖЦ. 5.Метрология и качество ПО. 6.Критерии качества ПО: сложность, корректность, надежность, трудоемкость. 7.Измерения и оценка качества ПО. 8.Процесс производства ПО: методы, технология и инструментальные средства. 9.Проектирование программного обеспечения. 10.Принципы построения, структура и технология использования САПР ПО. 11.Понятие бережливой разработки программного обеспечения. Принципы. 12.История развития ПО. 13.Типы ПО. 14.Уникальное ПО и ПО, как продукция. Требования к ПО как к продукции. 15.Доведение ПО до товарного уровня. 16.Понятие качества ПО. Критерии качества ПО: функциональность, надежность, их примитивы. 17.Критерии качества: легкость применения, эффективность, их примитивы. 18.Критерии качества: сопровождаемость, мобильность, их примитивы. 19.Функциональные и конструктивные критерии качества. Факторы, определяющие качество ПО. 21.Оценка качества ПО (показатель качества, единичный, комплексный, групповой). 22.Методы разработки структуры ПС. Восходящая разработка ПС. 23.Нисходящая разработка ПС. Конструктивный подход разработки ПС. 24.Вспомогательные средства проектирования ПС (схемы Варнье-Орра, СИС, схемы HIPO, привести примеры ). 25.Причины появления ошибок. Методы обнаружения ошибок. 26.Основные понятия отладки и тестирования. Различие между отладкой и тестированием. 27.Преимущество тестирования сверху вниз. Проверка программ в нормальных, экстремальных и исключительных ситуациях. 28.Основные принципы тестирования программ. Заповеди по тестированию, предложенные Г. Майерсом. 29.Методы тестирования, два подхода к тестированию. 30.Выбор и обоснование языка программирования. Критерии выбора языка программирования. Перечень практических (лабораторных) работ по МДК 03.03 Документирование и сертификация
Практическая работа №1 Структура, содержание и сфера применения международных стандартов в области обеспечения качества и безопасности ПО и процессов жизненного цикла программных средств Цель работы: А) Ознакомление со стандартами в области обеспечения жизненного цикла программных средства. Б) Рассмотреть стадии создания ПС. Опишите особенности каскадной модели жизненного цикла ПС. В) Рассмотреть жизненный цикл АС. Перечислите этапы работ согласно ГОСТ 19.102-77 «Стадии разработки программ и программной документации». Время выполнения работы: 2 часа Необходимая документация: ГОСТ 19.102-77 «Стадии разработки программ и программной документации» (Приложение 4) Введение В основе деятельности по созданию и использованию программных средств лежит понятие жизненного цикла. Жизненный цикл является моделью создания и использования программного обеспечения, отражающей его различные состояния, начиная с момента возникновения необходимости в программном средстве и заканчивая моментом его полного выхода из употребления у пользователей. Основными целями применения стандартов и нормативных документов в жизненном цикле ПС являются: - снижение трудоемкости, длительности, стоимости и улучшение других технико-экономических показателей проектов ПС; - повышение качества разрабатываемых и/или применяемых компонентов и ПС в целом при их приобретении, разработке, эксплуатации и сопровождении; - обеспечение возможности расширять ПС по набору прикладных функций и масштабировать в зависимости от размерности решаемых задач; - обеспечение переносимости прикладных программ и данных между разными аппаратно-программными платформами. Применение стандартов позволяет ориентироваться на построение систем из крупных функциональных узлов, отвечающих требованиям стандартов, применять отработанные и проверенные проектные решения. Они определяют унифицированные интерфейсы и протоколы взаимодействия компонентов таким образом, что разработчику системы, как правило, не требуется вдаваться в детали внутреннего устройства этих компонентов. В нашей стране жизненный цикл разработки ПС установлен стандартом ГОСТ 19.102-77 «Стадии разработки программ и программной документации» и содержит следующие этапы работ: - техническое задание (ТЗ); - эскизный проект (ЭЗ); - технический проект (ТП); - рабочий проект (РП); - внедрение. В таблице 3 приведены стадии разработки и этапы, их составляющие. Таблица 3. Стадии и этапы разработки ПС
Кроме рассмотренного выше жизненного цикла программ, существует жизненный цикл автоматизированных систем (АС) ГОСТ 34.601–90 «Информационная технология. Автоматизированные системы. Стадии создания». Настоящий стандарт распространяется на автоматизированные системы, используемые в различных видах деятельности (исследование, проектирование, управление и т. п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях. Стандарт устанавливает стадии и этапы создания АС, а также содержание работ на каждом этапе. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям (табл. 4). Допускается исключение стадии «Эскизный проект» и отдельных этапов работ на всех стадиях, объединение стадий «Технический проект» и «Рабочая документация» в одну стадию «Техно-рабочий проект». Таблица 4. Стадии и этапы разработки АС
В зависимости от специфики создаваемых АС и условий их создания допускается выполнение отдельных этапов работ до завершения предшествующих стадий, параллельное выполнение этапов работ, включение новых этапов работ. Стандарт ISO 12207 (ГОСТ Р ИСО/МЭК 12207) «Информационная технология. Процессы жизненного цикла программных средств» наиболее полно на уровне международных стандартов отражает жизненный цикл, технологию разработки и обеспечения качества сложных программных средств. Жизненный цикл ПС представлен набором этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующих ведение разработки на всех стадиях от подготовки технического задания до завершения испытаний ряда версий и окончания эксплуатации ПС. В жизненный цикл включаются описания исходной информации, способов выполнения операций и работ, устанавливаются требования к результатам и правилам их контроля, а также к содержанию технологических и эксплуатационных документов. Определяется организационная структура коллективов, распределение и планирование работ, а также контроль за реализацией жизненного цикла ПС. Стандарт может использоваться как непосредственный директивный, руководящий или рекомендательный документ, а также как организационная база при создании средств автоматизации соответствующих технологических этапов или процессов. Для реализации положений стандарта должны быть выбраны инструментальные средства, совместно образующие взаимосвязанный комплекс технологической поддержки и автоматизации ЖЦ и не противоречащие предварительно скомпонованному набору нормативных документов. Имеющиеся в стандарте пробелы следует заполнять спецификациями или нормативными документами, регламентирующими применение выбранных или созданных инструментальных средств автоматизации разработки и документирования ПС. Ход работы Задание 1. Рассмотреть ГОСТ 19.102-77 «Стадии разработки программ и программной документации», выписать основные стадии разработки ПС, цели каждого этапа. Задание 2. Рассмотреть ГОСТ 19.102-77 «Стадии разработки программ и программной документации». Перечислите этапы работ по созданию АС. Согласно ГОСТа, определить каскадный и спиральный метод создания ПС. Задание 3. Выполнить сравнение каскадной и спиральной модели создания ПС. Практическая работа №2 Содержание Федеральных законов РФ , постановлений Правительства, Концепций и Доктрин, регламентирующие вопросы технического регулирования, стандартизации и сертификации продукции, процессов производства и оказания услуг Цель работы: А) Знакомство с ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» Б) Определить способы получения информации о ПС. В) Формирование информационно - правовых компетенции обучающихся. Время выполнения работы: 2 академических часа Необходимая документация: ГОСТ 28.195-89 (Приложение 5) Введение Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Показатели качества программного обеспечения устанавливают ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» и ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению». Одновременное существование двух действующих стандартов, нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже рассмотрим каждый из перечисленных стандартов. ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения»устанавливает общие положения по оценке качества программных средств, номенклатуру и применяемость показателей качества. Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями. Методы определения показателей качества ПС различаются: - по способам получения информации о ПС – измерительный, регистрационный, органолептический, расчетный; - по источникам получения информации – экспертный, социологический. Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели. Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы. Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т. п. Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы. Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности. Социологические методы основаны на обработке специальных анкет-вопросников.  Рис. 1 – Уровни системы показателей качества Показатели качества объединены в систему из четырех уровней. Каждый вышестоящий уровень содержит в качестве составляющих показатели нижестоящих уровней (рисунок 1). Стандарт ИСО 9126 (ГОСТ Р ИСО/МЭК 9126) «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению». Определенные настоящим стандартом характеристики дополнены рядом требований по выбору метрик и их измерению для различных проектов ПС. Они применимы к любому типу ПС, включая компьютерные программы и данные, содержащиеся в программируемом оборудовании. Эти характеристики обеспечивают согласованную терминологию для анализа качества ПС. Кроме того, они определяют схему для выбора и специфицирования требований к качеству ПС, а также для сопоставления возможностей различных программных продуктов, таких как функциональные возможности, надежность, практичность и эффективность. Все множество атрибутов качества ПС может быть классифицировано в структуру иерархического дерева характеристик и субхарактеристик. Самый высший уровень этой структуры состоит из характеристик качества, а самый нижний уровень – из их атрибутов. Эта иерархия не строгая, поскольку некоторые атрибуты могут быть связаны с более чем одной субхарактеристикой. Таким же образом, внешние свойства (такие, как пригодность, корректность, устойчивость к ошибкам или временная эффективность) влияют на наблюдаемое качество. Недостаток качества в использовании (например, пользователь не может закончить задачу) может быть прослежен к внешнему качеству (например, функциональная пригодность или простота использования) и связанным с ним внутренним атрибутам, которые необходимо изменить. Внутренние метрики могут применяться в ходе проектирования и программирования к неисполняемым компонентам ПС (таким, как спецификация или исходный программный текст). При разработке ПС промежуточные продукты следует оценивать с использованием внутренних метрик, которые измеряют свойства программ, и могут быть выведены из моделируемого поведения. Основная цель внутренних метрик – обеспечивать, чтобы было достигнуто требуемое внешнее качество. Внутренние метрики дают возможность пользователям, испытателям и разработчикам оценивать качество ЖЦ программ и заниматься вопросами технологического обеспечения качества задолго до того, как ПС становится готовым исполняемым продуктом. Внутренние метрики позволяют измерять внутренние атрибуты или формировать признаки внешних атрибутов путем анализа статических свойств промежуточных или поставляемых программных компонентов. Измерения внутренних метрик используют категории, числа или характеристики элементов из состава ПС, которые, например, имеются в процедурах исходного программного текста, в графе потока управления, в потоке данных и в представлениях изменения состояний памяти. Документация также может оцениваться с использованием внутренних метрик. Внешние метрики используют меры ПС, выведенные из поведения системы, частью которых они являются, путем испытаний, эксплуатации или наблюдения исполняемого ПС или системы. Перед приобретением или использованием ПС его следует оценить с использованием метрик, основанных на деловых и профессиональных целях, связанных с использованием, эксплуатацией и управлением продуктом в определенной организационной и технической среде. Внешние метрики обеспечивают заказчикам, пользователям, испытателям и разработчикам возможность определять качество ПС в ходе испытаний или эксплуатации. Когда требования к качеству ПС определены, в них должны быть перечислены характеристики и субхарактеристики, которые составляют полный набор показателей качества. Затем определяются подходящие внешние метрики и их приемлемые диапазоны значений, устанавливающие количественные и качественные критерии, которые подтверждают, что ПС удовлетворяет потребностям заказчика и пользователя. Далее определяются и специфицируются внутренние атрибуты качества, чтобы спланировать удовлетворение требуемых внешних характеристик качества в конечном продукте и обеспечивать их в промежуточных продуктах в ходе разработки. Подходящие внутренние метрики и приемлемые диапазоны специфицируются для получения числовых значений или категорий внутренних характеристик качества, чтобы их можно было использовать для проверки того, что промежуточные продукты в процессе разработки удовлетворяют внутренним спецификациям качества. Рекомендуется использовать внутренние метрики, которые имеют наиболее сильные связи с целевыми внешними метриками, чтобы они могли помогать при прогнозировании значений внешних метрик. Метрики качества в использовании измеряют, в какой степени продукт удовлетворяет потребности конкретных пользователей в достижении заданных целей с результативностью, продуктивностью и удовлетворением в заданном контексте использования. При этом результативность подразумевает точность и полноту достижения определенных целей пользователями при применении ПС; продуктивность соответствует соотношению израсходованных ресурсов и результативности при эксплуатации ПС, а удовлетворенность – психологическое отношение к качеству использования продукта. Эта метрика не входит в число шести базовых характеристик ПС, регламентируемых стандартом ИСО 9126, однако рекомендуется для интегральной оценки результатов функционирования комплексов программ. Оценивание качества в использовании должно подтверждать его для определенных сценариев и задач, оно составляет полный объединенный эффект характеристик качества ПС для пользователя. Качество в использовании – это восприятие пользователем качества системы, содержащей ПС, и оно измеряется скорее в терминах результатов использования комплекса программ, чем собственных внутренних свойств ПС. Связь качества в использовании с другими характеристиками качества ПС зависит от типа пользователя, так, например, для конечного пользователя качество в использовании обусловливают, в основном, характеристики функциональных возможностей, надежности, практичности и эффективности, а для персонала сопровождения ПС качество в использовании определяет сопровождаемость. На качество в использовании могут влиять любые характеристики качества, и это понятие шире, чем практичность, которая связана с простотой использования и привлекательностью. Качество в использовании, в той или иной степени, характеризуется сложностью применения комплекса программ, которую можно описать трудоемкостью использования с требуемой результативностью. Многие характеристики и субхарактеристики ПС обобщенно отражаются неявными технико-экономическими показателями, которые поддерживают функциональную пригодность конкретного ПС. Однако их измерение и оценка влияния на показатели качества, представляет сложную проблему. Ход работы: |