Стандатризация программных средств

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

Рубрика Программирование, компьютеры и кибернетика
Вид лекция
Язык русский
Дата добавления 09.03.2009
Размер файла 352,8 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

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

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

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

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

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

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

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

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

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

Простота использования ИБД - возможность удобно и комфортно ее

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

Изучаемость может определяться требованиями ограниченной трудоемкости и длительности подготовки пользователя к полноценной эксплуатации информации БД. Изучаемость ИБД зависит от внутренних свойств и сложности структуры информации БД, а также от субъективных характеристик квалификации конкретных пользователей. Она может также характеризоваться объемом эксплуатационной документации и/или объемом и качеством электронных учебников.

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

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

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

· форматная совместимость характеризуется степенью соответствия данных в ИБД анализируемых платформ требованиям стандартов на форматы представления данных для документальных, фактографических, словарных и иных БД;

· лингвистическая совместимость определяется степенью использования в рассматриваемых ИБД единых лингвистических

средств (классификаторов, рубрикаторов, словарей), формализованных соответствующими стандартами этих платформ;

· физическая совместимость заключается в степени соответствия кодировки информации БД одинаковым стандартам на машиночитаемые носители информации.

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

Лекция 20. Модели оценки характеристик качества ПО

Размерно-ориентированные метрики. Функционально-ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно - ориентированных и функционально-ориентированных метрик.

Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC - оценках (Lines Of Code). LOC - оценка - это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл.3).

Табл. 3.Исходные данные для расчета LOC- метрик

Проект

Затраты, чел.-мес.

Стоимость тыс. $

КLOC, тыс. LOC

Страниц

Ошибки

Количество человек

А01

24

168

12,1

365

29

3

В02

62

440

27,2

1224

86

5

С03

43

314

20,2

1050

64

6

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте А01 показывает: 12100 строк программы были разработаны за 24 чел.-мес. И стоили $168 000. Кроме того, по проекту было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект три человека.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:

Производительность = Длина / Затраты (тыс.LOC/чел.-мес.);

Качество = Ошибки / Длина (Единиц/тыс. LOC);

Удельная стоимость = Стоимость /Длина (тыс.$/LOC);

Документированность = Страниц_Документа / Длина (Страниц/тыс.LOC)

Достоинства размерно-ориентированных метрик:

· широко распространены;

· просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

· зависимы от языка программирования;

· требуют исходных данных, которые трудно получить на начальной стадии проекта;

· не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

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

Используется 5 информационных характеристик.

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

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

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

4. Количество внутренних логических файлов. Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом).

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

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

Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл.

Тип элемента-записи - подгруппа элементов данных, распознаваемая пользователем в пределах файла.

Тип элемента данных - уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).

Табл.4. Примеры элементов данных

Информационная характеристика

Элементы данных

Внешние вводы

Поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки

Внешние выводы

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

Внешние запросы

Вводимые элементы: поле, используемое для списка, щелчок мыши.

Выводимые элементы: отображаемые на экране поля.

Табл.5. Правила учета элементов данных из ГИП

Элемент данных

Правило учета

Группа радиокнопок

Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных

Группа флажков (переключатели)

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

Командные кнопки

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

Списки

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

Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).

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

Обсудим порядок учета сообщений. В приложении с ГИП генерируются три типа сообщений: сообщение об ошибке, сообщение подтверждения и сообщение уведомления. Сообщения об ошибке (например, «Требуется пароль») и сообщение подтверждения (например, «Вы действительно хотите удалить запись о клиенте?») указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не образуют самостоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции.

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

Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.6-10 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.

Табл.6. Ранг и оценка сложности внешних вводов

Ссылки на файлы

Элементы данных

1-4

5-15

>15

0-1

Низкий (3)

Низкий (3)

Средний (4)

2

Низкий (3)

Средний (4)

Высокий (6)

>2

Средний (4)

Высокий (6)

Высокий (6)

Табл.7. Ранг и оценка сложности внешних выводов

Ссылки на файлы

Элементы данных

1-4

5-19

>19

0-1

Низкий (4)

Низкий (4)

Средний (5)

2-3

Низкий (4)

Средний (5)

Высокий (7)

>3

Средний (5)

Высокий (7)

Высокий (7)

Табл.8. Ранг и оценка сложности внешних запросов

Ссылки на файлы

Элементы данных

1-4

5-19

>19

0-1

Низкий (3)

Низкий (3)

Средний (4)

2-3

Низкий (3)

Средний (4)

Высокий (6)

>3

Средний (4)

Высокий (6)

Высокий (6)

Табл.9. Ранг и оценка сложности внутренних логических файлов

Ссылки на файлы

Элементы данных

1-19

20-50

>50

0-1

Низкий (7)

Низкий (7)

Средний (10)

2-5

Низкий (7)

Средний (10)

Высокий (15)

>5

Средний (10)

Высокий (15)

Высокий (15)

Табл.10. Ранг и оценка сложности внешних интерфейсных файлов

Ссылки на файлы

Элементы данных

1-19

20-50

>50

0-1

Низкий (5)

Низкий (5)

Средний (7)

2-5

Низкий (5)

Средний (7)

Высокий (10)

>5

Средний (7)

Высокий (10)

Высокий (10)

Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется на элемент данных (однократный учет).

После сбора всей необходимой информации приступают к расчетам метрики - количества функциональных указателей FP (Function Points). Автором этой метрики является А. Альбрехт (1979).

Исходные данные для расчета сводятся в табл. 11. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольником (этот символ играет роль метки - заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество.

Табл.11. Исходные данные для расчета FP - метрик

Имя характеристики

Ранг, сложность, количество

Низкий

Средний

Высокий

Итого

Внешние вводы

*3=_

*4=_

*6=_

=

Внешние выводы

*4=_

*5=_

*7=_

=

Внешние запросы

*3=_

*4=_

*6=_

=

Внутренние логические файлы

*7=_

*10=_

*15=_

=

Внешние интерфейсные файлы

*5=_

*7=_

*10=_

=

Общее количество

=

Количество функциональных указателей вычисляется по формуле:

FP= Общее количество*(0,65+0,01*Fi), (1)

Где Fi - коэффициент регулировки сложности (I=1..14).

Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 - важное, 5 - основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12).

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

Производительность = ФункцУказатель / Затраты (FP/чел.-мес.);

Качество = Ошибки / ФункцУказатель (Единиц/FP);

Удельная Стоимость = Стоимость / ФункцУказатель (Тыс.$/FP);

Документированность=СтраницДокумента/ФункцУказатель (Страниц/FP)

Табл.12. Определение системных параметров приложения

Системный параметр

Описание

1

Передачи данных

Сколько средств данных требуется для пердачи или обмена информацией с приложением или системой?

2

Распределенная обработка данных

Как обрабатываются распределенные данные и функции обработки?

3

Производительность

Нуждается ли пользователь в фиксации времени ответа или производительности?

4

Распространенность используемой конфигурации

Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?

5

Скорость транзакций

Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)?

6

Оперативный ввод данных

Какой процент информации нужно вводить в режиме онлайн?

7

Эффективность работы конечного пользователя

Приложение проектировалось для обеспечения эффективной работы конечного пользователя?

8

Оперативное обновление

Как много внутренних файлов обновляется в онлайновой транзакции?

9

Сложность обработки

Выполняет ли приложение интенсивную логическую или математическую обработку?

10

Повторная используемость

Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?

11

Легкость инсталляции

Насколько трудны преобразования и инсталляция приложения?

12

Легкость эксплуатации

Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?

13

Разнообразные условия размещения

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

14

Простота изменений

Была ли спроектирована, разработана и поддержана в приложении простота изменения?

Область применения функциональных указателей - коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО.

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

Табл.13. Исходные данные для расчета указателя свойств

Характеристика

Количество

Сложность

Итого

1

Вводы

*4

=

2

Выводы

*5

=

3

Запросы

*4

=

4

Логические файлы

*7

=

5

Интерфейсные файлы

*7

=

6

Количество алгоритмов

*3

=

Общее количество

=

После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.

Достоинства функционально-ориентированных метрик:

· не зависят от языка программирования;

· Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP - оценки легко пересчитать в LOC - оценки. Как показано в табл.14, результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Табл.14. Пересчет FP - оценок в LOC - оценки

Язык программирования

Количество операторов на 1 FP

Ассемблер

320

С

128

Паскаль

90

С++

64

Java

53

Visual Basic

32

Visual С++

34

Delphi Pascal

29

HTML 3

15

LISP

64

Prolog

64

ЗАКЛЮЧЕНИЕ

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

БИБЛИОГРАФИЯ

1. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: «Финансы и статистика». 2000. - 339 с.

2. А.М. Вендров. Практикум по проектированию программного обеспечения экомических информационных систем. М.: «Финансы и статистика». 2002. -190 с.

3. Практические аспекты информатизации. Стандартизация, сертификация и лицензирование. Справочная книга руководителя. Под редакцией Л.Д. Реймана. М.: 2000. -259с.

4. В.В. Липаев. Качество программных средств. Методические рекомендации. М.: «Янус-К». 2002. - 298с.

5. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ./Под ред. А.А. Красилова. М.:Радио и связь, 1985.

6. В.В. Липаев, А.И. Потапов. Оценка затрат на разработку программных средств. М.: Финансы и статистика. 1988.

7. С.А. Орлов. Технологии разработки программного обеспечения. Учебник для вузов. М., Санкт-Петербург: «Питер». 2002.

8. Г. Коллинз, Дж. Блей. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: «Статистика», 1980. 260с.:ил.

9. ГОСТ Р ИСО 9127 - 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов».

10. ГОСТ 34601 - 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

11. ГОСТ 34601 - 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

12. ГОСТ 34601 - 92. «Информационная технология. Виды испытаний автоматизированных систем».

13. Информационные системы в экономике. Под ред. Проф. В.В. Дика. Учебник для вузов, М., «Финансы и статистика». 1996. - 270 с.

ПРИЛОЖЕНИЕ

О СТАНДАРТЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ДЛЯ ДИАЛОГОВЫХ ИТ

Стандарт фирмы IBM. Проектирование пользовательского интерфейса на персональном компьютере.- Вильнюс, 1992

Стандартизация и согласованность интерфейса экономят время пользователя и разработчика.

Пользовательский интерфейс включает в себя три понятия: общение приложения с пользователем, общение пользователя с приложением, язык общения. Язык общение определяется разработчиком программного приложения. Свойствами интерфейса являются наглядность и конкретность. Наиболее распространенный ранее командный интерфейс имел ряд недостатков (многочисленность команд, отсутствие стандарта для приложения), что ограничивало круг его применения. Для преодоления этих недостатков были предприняты попытки его упростить (например, NC). Однако настоящим решением проблемы стало создание графической оболочки для ОС. В настоящее время практически все распространенные ОС используют для своей работы графический интерфейс. Примером здесь может служить интерфейс, разработанный в исследовательском центре Пало Альто фирмы Xerox для компьютеров Macintosh фирмы Apple. Немного позже была разработана графическая оболочка под названием Microsoft Windows, реализующая технологию WIMP и удовлетворяющая стандарту CUA. Новшеством были применение мыши, выбор команд из меню, предоставление программам отдельных окон, использование для обозначения программ образов в виде пиктограмм.

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

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

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

Преимущество использования меню действий (и выпадающего меню) заключается в том, что эти действия наглядны и могут быть запрошены пользователем установкой курсора, функциональной клавишей вводом команды либо каким-то другим простым способом. На цветном экране меню действий имеет обычно другой цвет по отношению к цвету панели. На монохромном экране используется сплошная линия для его отделения. Меню действий содержит объекты, состоящие из одного или нескольких слов. Два последних из них резервируются для действий “выход” и “справка”. Размещаются объекты слева направо по мере убывания частоты их использования. Возможны системы с многоуровневой системой выпадающих меню, но оптимальное число уровней - три, т.к. иначе могут появиться трудности в понимании многоуровневых меню.

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

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

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

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

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

Путь, по которому движется диалог, называется навигацией. Он может быть изображен в виде графа, где узлы - действия, дуги - переходы. Диалог состоит из двух частей: запросов на обработку информации и навигации по приложению. Часть запросов на обработку и навигацию является унифицированной. Унифицированные действия диалога - это действия, имеющий одинаковый смысл во всех приложениях. Некоторые унифицированные действия могут быть запрошены из выпадающего меню посредством действия “команда” функциональной клавишей. К унифицированным действиям диалога относятся: "отказ", “команда”, “ввод”, “выход”, “подсказка”, “регенерация”, “извлечение”, “идентификаторы”, “клавиши”, “справка” (см. прил.3).

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

Стандарт фирмы IBM. Элементы экрана

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

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

Идентификатор панели - защищенная алфавитно - цифровая информация (имя), предназначенная для идентификации панели. По умолчанию идентификатор выключен (не высвечивается). Действия с идентификатором осуществляются с помощью функциональных клавиш.

Заголовок панели сообщает пользователю о том, какая информация содержится в теле панели. Панель должна иметь заголовок, если это не оговорено другими правилами. Сообщения в всплывающем окне могут не иметь заголовка. Если другие области тела панели должны протягиваться, то заголовок образует самостоятельную область и не протягивается. Он может содержать переменную информацию, но не может содержать поле выбора или поле ввода.

Инструкция сообщает пользователю, что нужно сделать и как продолжить работу.

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

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

Заголовок поля обозначает поле выбора, поле ввода поле переменной информации.

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

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

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

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

Поле выбора - это обобщенное определение набора взаимосвязанных объектов (слов, пиктограмм и их сочетаний). Когда пользователь выбрал объект, приложение визуально отмечает это при помощи цвета, подсветки или символа, размещаемого перед выбранным объектом. Цвет и подсветка называются выделением, а символ - указателем выбора. Различают поля однозначного, многозначного и расширенного выбора.

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

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

В поле расширенного выбора пользователь выбирает объект, и к нему во всплывающем или вторичном окне дается пояснение (расширение). Если в первоначальном состоянии имеется один объект, то это поле рассматривается как поле однозначного выбора, а если есть несколько объектов, то многозначного.

Объекты поля выбора могут представляться тремя способами: по столбцам, выровненным влево; в одной строке; в несколько столбцов, которые разделены пробелами. Каждое поле может быть идентифицировано заголовком поля, столбца, группы, протягиваемого поля выбора. Объект поля выбора можно представить одним или несколькими словами, пиктограммами или их сочетанием. Поля однозначного выбора могут нумероваться, если их не более 9. При использовании мнемоники каждому объекту присваивают уникальную букву. Мнемоника активна только в том поле выбора, на которое указывает курсор. Протягиваемые поля выбора используются только для списка объектов, размещенных в одном столбце.

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

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

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

Рекомендуемая палитра:

Панель в первичных и вторичных окнах, за исключение панели “Справка”,- белая. Панель в окне справка - синяя. Панель во всплывающих окнах нечетного уровня - голубая, а четного уровня - белая. Ошибки выделяются красным. Предупреждения об ошибках - желтые. Критические сообщения - красные.

Стандарт фирмы IBM. Унифицированные действия диалога

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

Действие “ввод” включается, если панель содержит поле ввода или более одного поля выбора (многозначный выбор).

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

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

Унифицированное действие “справка” должно содержать следующие действия в выпадающем меню в порядке расположения:

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

Общая справка. Обеспечивает общую справку о панели, из которой она затребована.

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

Указатель. Содержит перечень имеющихся в приложении справок в алфавитном порядке. Тот же список отображается при выборе клавиши “указатель” в панели “справка”.

Учебная справка. Предусматривается в режиме приложения и должна быть последней в выпадающем меню “Справка”.

“Справка” должна быть включена во все панели и меню действий. Если меню отсутствует, то справка появляется в области функциональных клавиш.

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

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

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

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

Посредством действия “Идентификатор” пользователь запрашивает включение или выключение идентификатора панели.


Подобные документы

  • Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.

    курсовая работа [67,9 K], добавлен 29.05.2013

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

    презентация [350,6 K], добавлен 09.11.2015

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

    курсовая работа [974,0 K], добавлен 21.12.2016

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

    лекция [370,1 K], добавлен 22.03.2014

  • Критерии оценки эффективности и качества создания программных средств. Роль трудоемкости и длительности создания программных средств в определении эффективности их создания. Требования к качеству, суммарные затраты на разработку программного средства.

    реферат [26,7 K], добавлен 10.10.2014

  • Этапы тестирования при испытаниях надежности программных средств. Комплексирование модулей и отладка автономных групп программ в статике без взаимодействия с другими компонентами. Испытания главного конструктора. Жизненный цикл программного средства.

    презентация [339,6 K], добавлен 22.03.2014

  • Жизненный цикл программного обеспечения - непрерывный процесс, который начинается с принятия решения о необходимости создания ПО и заканчивается при полном изъятия его из эксплуатации. Подход к определению жизненного цикла ПО Райли, по Леману и по Боэму.

    реферат [39,1 K], добавлен 11.01.2009

  • Характеристика программных средств, использованных при разработке сайта. Параметры аппаратных средств для демонстрации ПП. Особенности архитектуры программного обеспечения. Анализ модели жизненного цикла программного продукта. Построение Gant-диаграммы.

    курсовая работа [886,9 K], добавлен 30.05.2015

  • Основные задачи национального органа по стандартизации в России. Структура Федерального агентства по техническому регулированию и метрологии. Характеристика международных организаций по стандартизации программных средств и информационных технологий.

    презентация [258,0 K], добавлен 27.12.2013

  • Разработка программных и аппаратных компонентов для проведения информатизации объекта. Выбор конфигурации рабочих станций. Комплектация персонального компьютера и сервера для обеспечения обработки информации. Схема лицензирования программного обеспечения.

    курсовая работа [2,5 M], добавлен 20.12.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.