Организация контроля качества программного продукта

Кроме того, в нем могут быть отражены вопросы формирования отчетности по дефектам и документирования требований.Оценка и аудит. Пять типов оценок и аудитов:Управленческие оценки (managementreviews);Технические оценки (technicalreviews);Инспекции (inspections);“Прогонки” (walk-throughs);Аудиты (audtis).Управленческие оценки (ManagementReviews)Назначение управленческих оценок состоит в отслеживании развития <проекта/продукта>, определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей.Управленческие оценки поддерживают принятие решений о внесении изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного проекта.Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов — управления рисками проекта/проектного управления, конфигурационного управления, безопасности использования программного обеспечения (safety), оценки рисков и т.п.Технические оценки (TechnicalReviews)Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения (decision-maker); лидер оценки (reviewleader); регистратор (recorder); а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке.Техническая оценка требует, в обязательном порядке, наличия следующих входных данных:Формулировки целей;Конкретного программного продукта (подвергаемого оценке);Заданного плана проекта (плана управления проектом);Списка проблем (вопросов), ассоциированных с продуктом;Процедуры технической оценки.Команда технической оценки следует заданной процедуре оценки. Квалифицированные (с технической точки зрения) лица представляют обзор продукта (представляя команду разработки). Исследование <продукта> проводится в течение одной и более встреч (между теми, кто представляет продукт и теми, кто провидит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта.Инспекции (Inspections)Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте. Существует два серьезных отличия инспекций от оценок (управленческой и технической):Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды инспектирования, не должны участвовать в инспекциях.Инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей) лидера, обученного техникам инспектирования.Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как временные организационные единицы – группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества, прим. автора). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники в небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией инспекции и проверяет, что все члены команды подготовились к инспектированию.1.4. Требования к качеству ПОФакторы влияния (Influencefactors)На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности <людей>), критичное для бизнеса и т.п.);Системные и программные требования;Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние);Какие стандарты программной инженерии применимы в заданном контексте;Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов);Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов;Кто целевые пользователи и каково назначение системы;Уровень целостности системы.Информация об этих факторах влияет на то, как именно будут организованы и документированы процессы SQM, какие SQM-работы будут отобраны (стандартизированы в рамках проекта, команды, организационной единицы, организации), какие необходимы ресурсы и каковы ограничения, накладываемые в отношении усилий, направляемых на обеспечение качества.Гарантоспособость – гарантия высокой надежности, защищенности от сбоев.В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “highconfidence” или “highintegritysystem”, в русском языке к ним иногда применяют название “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным требованием качества, по отношению к основной функциональности <системы>.Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety – безопасность в контексте приемлемого риска для здоровья людей, бизнеса, имущества и т.п. ), информационная безопасность или защищенность (security – защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство и простота использования (usability). Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности.В обсуждении данного вопроса существенную роль играет обширная литература по системам повышенной надежности. При этом, применяется терминология, пришедшая из области традиционных механических и электрических систем (в т.ч. не включающих программное обеспечение) и описывающая концепции опасности, рисков, целостности систем и т.п.ЗаключениеБыстрое увеличение сложности и размеров современных комплексов программ при одновременном повышении ответственности выполняемых функций резко повысило требования со стороны пользователей к их качеству, надежности функционирования и безопасности применения.Для каждого проекта, выполняющего ответственные функции, должны разрабатываться и применяться система качества, специальные планы и программа, методология и инструментальные средства, обеспечивающие требуемые качество, надежность и безопасность функционирования. компьютерный качество информационныйДля удовлетворения высоких требований к функционированию необходимы выделение из ЖЦ ПС задач и работ по обеспечению качества программ, а также обучение и концентрация усилий разработчиков на анализе и обосновании рентабельности выбранной методологии и методов разработки комплексов программ.Список используемой литературы1. Воробьев В.И., Копыльцов А.В., Пальчун Б.П., Юсупов Р. Методы и модели оценивания качества программного обеспечения. М. С-Пб.: СПИИРАН.1992. - 33 с.2. Андон Ф.И., Суслов В.Ю., Коваль Г.И., Коротун Т.М. Основы качества программных систем. - Киев, Академпериодика. - 2002. -502 с.3. Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии. Учебник Киев: Знание, 2001. - 269 с.4. Боэм Б.У., Браун Дж., Каспар X. и др. Характеристики качества программного обеспечения. М. Мир, 1981.5. Фокс Дж. Программное обеспечение и его разработка М.: "Мир", 1982.6. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. - М.: Синтег, 2001. - 380 с.