Всем известно, что качество программного обеспечения не поддается точному определению и измерению
Любопытна публикация английских исследователей М. Тэйлор и Дж. ДаКоста. Они провели анализ проблемы качества КИС (Корпоративной Информационной Системы) на одном конкретном примере. Внедрили на небольшую фирму своего человека в качестве консультанта, который наблюдал за ходом создания информационной системы. Главный вывод статьи: "на средних и малых предприятиях при разработке и внедрении КИС возникают те же проблемы с качеством, что и на больших, поэтому требуется применение методологии "Гибких Систем". Это не очень интересно. Интереснее перечень проблем, с которыми столкнулись английские товарищи:
- Программисты и коммерсанты говорят и мыслят разными категориями, поэтому им трудно найти общий язык.
- Имея опыт работы на старой программе, сотрудники фирмы-заказчика "напридумывали" такое количество новых идей, что система под их тяжестью едва могла шевелиться, при этом многие из этих идей остались невостребованными.
- Заказы принимались "на слух", многие из них так никогда и не были записаны.
- Техническое задание не было подготовлено в полном объеме.
- "Вечные" проблемы с внедрением (даже не будем цитировать, так это все банально - ошибки, разногласия по поводу ТЗ, нежелание операторов учиться…).
- Как результат: "снижение доверия к разработчику, которое усугубилось неприятным фактом, когда вместо того, чтобы изменить настройки принтера, разработчик выставил счет за ремонт материнской платы принтера на 250 фунтов стерлингов".
- Чаша терпения была переполнена, когда заказчик придумал будто "оператор на складе должен иметь возможность работать на нескольких экранах одновременно". Программисты сказали "нет проблем", а система стала перегружаться, так что начала "подвисать иногда", не мало не много - несколько раз в день.
- Низкое качество конструирования.
- Отсутствие системного подхода при планировании КИС
- Плохое обслуживание при внедрении и сопровождении.
- Низкое качество программного обеспечения.
Критерии качества с точки зрения разработчика: техническое качество работы (быстродействие, надежность), пригодность к сопровождению и развитию, устойчивость - полностью относятся к компетенции системы качества ПО.
Можно строить и другие структуры критериев и параметров качества. Вот, например, какую структуру характеристик качества предлагает стандарт ИСО-9126 (да и то, в качестве нормативного приложения, как пример, оговариваясь, что фирмы могут применять совершенно другие наборы характеристик, лишь бы они удовлетворяли общим требованиям стандарта):
- Функциональность
- Соответствие назначению
Точность
Способность взаимодействовать со средой
Соответствие нормам
Безопасность (защита от взлома данных и других преступных посягательств)
- Зрелость ("обкатанность")
Отказоустойчивость
Способность восстанавливаться после сбоев
- Понимаемость
Изучаемость
Удобство и простота в работе
- Быстродействие и время отклика
Потребление ресурсов
- Анализируемость (диагностика причин ошибок и сопоставление с исходным кодом)
Пригодность к изменениям
Стабильность
Тестируемость
- Адаптируемость
Легкость инсталляции
Соответствие нормам по переносимости и инсталляции
Заменяемость (способность заменить аналоги?)
Last modified: Thursday, 14 July 2011, 6:47 PM