7.4. Оценивание практичности

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

Субхарактеристики практичности содержат (табл.4.3): понятность; простоту использования; изучаемость; привлекательность ПС.

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

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

Для обеспечения объективности оценивание целесообразно проводить группой экспертов–пользователей при типовом и экстремальном применении ПС

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

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

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

7.5. Оценивание сопровождаемости

Оценивание сопровождаемости заключается в определении мер и атрибутов процессов сопровождения и конфигурационного управления изменениями и версиями в ЖЦ комплексов программ. Субхарактеристики сопровождаемости включают (табл.4.3): анализируемость; изменяемость; стабильность; тестируемость программ.

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

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

• ожидаемую длительность поддержки сопровождением развития проекта ПС;

• объем, сложность и уровень предполагаемых изменений;

• возможное число и периодичность выпуска версий со значительными модификациями;

• организационные основы процессов сопровождения и конфигурационного управления;

• требования к документированию, изменений и версий;

• кто будет осуществлять сопровождение – покупатель, разработчик первичной версии или специальный персонал поддержки развития и адаптации версий ПС.

В стратегии сопровождения следует учесть характеристики системы:

• количество компонентов ПС;

• типы, размер и критичность создаваемых и модифицируемых программных продуктов;

• унифицированность внутренних и внешних интерфейсов.

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

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

После передачи версии в эксплуатацию затраты на обнаружение и первичную квалификацию дефектов несут в основном непосредственные пользователи. На разработчиков (поставщиков) ПС возлагается анализ и локализация причин дефектов и их устранение. Эти затраты зависят:

• от характеристик выявляемых дефектов,

• от объема и сложности комплекса программ,

• организации и технологии его разработки,

• инструментальной оснащенности сопровождения,

• квалификации специалистов,

• тиража и активности применения данного ПС.

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

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

• точно документально описывать и идентифицировать каждую оформленную версию программных компонентов и ПС в целом в любое время на всем протяжении их ЖЦ;

• надежно учитывать и регистрировать все анализируемые, подготавливаемые и реализованные изменения в версиях ПС;

• снабжать руководителей проекта обобщенной и детальной информацией для принятия решений на изменения программ;

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

Особое значение при оценивании сопровождаемости имеет тестируемость компонентов ПС и качество документации на реализованные изменения и тесты. На базе всего комплекса использованных тестов создается и документируется для каждой версии ПС эталонная тестовая (контрольная) задача и контрольные результаты ее решения. В течение этого времени возможны отдельные уточнения изменений в документации версии. В результате документация должна непрерывно «догонять» реальное состояние программного продукта. Для упорядочения этого процесса стандартами установлена возможность оперативного выпуска предварительных извещений на частные изменения.

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