Разработка, внедрение и адаптация программного обеспечения отраслевой направленности Часть 2. Разработка, внедрение и адаптация программного обеспечения отрас. Тема введение в обеспечение качества программных средств
 Скачать 418.37 Kb.
|
14.7. Формы документов процесса контроля качестваОписание процессов в стандарте ISO/IEC 122G7 выполнено по единой схеме: 1. Назначение (Purposes) (цели) процесса; 2. Результаты (Outcomes) выполнения процесса (продукты, артефакты, существенное изменение состояния, достижение определенных целей и требований); 3. Перечень действий (Activities), составляющих процесс; 4. Описание каждого действия и выполняемых заданий (задач) (Tasks). Описания не содержат каких-либо требований к составу входных и выходных рабочих продуктов (PH) процессов. Однако, для выполнения задач SQA по проверке рабочих продуктов процессов, а также для оценивания эффективности процессов и их совершенствования, состав рабочих продуктов должен быть определен. В части 5 стандарта ГОСТ ISO/IEC 155G4-5 [3G], содержащей пример модели оценивания, совместимой с эталонной, все процессы ассоциированы с входными и выходными рабочими продуктами (приложение А стандарта) и дано краткое описание этих рабочих продуктов (приложение С стандарта). Pабочие продукты отнесены к следующим категориям: PП уровня организации, PП ведения проекта и вспомогательные PП (таблица 13.2). Описание каждого PП касается его сути (содержания), но не формы представления. Форма, в которой могут существовать однотипные рабочие продукты в разных проектах, обычно определяется применяемыми методологиями и CASE-инструментами разработки (например, SSADM, CDM Oracle), а также требованиями и рекомендациями специализированных отраслевых стандартов и руководств (например, стандарта Министерства Обороны США MIL Std. 498 "Software Development and Documentation" разработка и документирование ПО) [3] или стандарта Министерства Обороны Великобритании DEF STAN GG55 "Requirements for Safety Related Software in Defence Equipment" (Требования к программному обеспечению обеспечения безопасности военного оборудования). Входными рабочими продуктами для процессов контроля качества являются практически все выходные продукты основных и поддерживающих процессов жизненного цикла (документация проекта, планы и отчеты о выполнении процессов, данные проверок в контрольных точках проекта и др.). В ходе SQA проверяется их соответствие стандартам, собирается информация о "качестве" процесса программной инженерии (допущенных ошибках и причинах их появления) и контролируются темпы продвижения разработки (выполненные объемы работ, потраченное время, трудоемкость, затраты). Таблица 13.2. Классификация рабочих продуктов по ISO/IEC 15504-5: 2006 По результатам всестороннего анализа полученной информации готовятся выходные рабочие продукты процессов контроля качества - планы проверок, отчеты о состоянии разработки, данные об эффективности процессов жизненного цикла, рекомендации для руководителей проекта или организации. Некоторые образцы этих рабочих продуктов уже встречались ранее в этой книге (например, план измерения, план качества), остальные - будут представлены в последующих главах. 14.8. Ключевые метрики для контроля разработки Ключевыми метриками, применяемыми при решении задач SQA , являются: метрики трудоемкости и стоимости разработки; метрики размера и сложности разрабатываемого программного продукта; метрики ошибок. Трудоемкость и стоимость разработки . Существует немало методов оценивания трудоемкости и стоимости программных средств, имеющих как достоинства, так и недостатки. Размер. Основная проблема и препятствие для применения ряда методов определения стоимости состоит в том, что для предсказания усилий на разработку нужно сначала предсказать размер конечной системы в единицах SLOC (число строк исходных инструкций кода) . Существуют хорошие руководства по определению длины кода "готового" программного продукта. Однако, во-первых, они непригодны для прогнозирования, а, во-вторых, длина кода не всегда отражает размер современных программных продуктов (например, продуктов, предназначенных для интенсивной работы с базами данных средствами современных СУБД). Достойную альтернативу измерению SLOC составляет определение размера программного обеспечения в условных единицах функциональности (FP, от Functional Points), выполняемое на ранних стадиях жизненного цикла исходя из анализа функциональных требований к программному обеспечению. Методологию анализа показателей функционального размера (FPA, Function Point Analysis) предложил А. Альбрехт в 1979 году. Обзор методов, разработанных на основе FPA и учитывающих пользовательский взгляд на разрабатываемый программный продукт. Сложность. Оценка таких характеристик качества программных средств, как надежность или сопровождаемость, не может быть выполнена до тех пор, пока не получена хотя бы первая версия кода программного средства. Однако еще до завершения разработки системы полезно знать, какие ее компоненты могут оказаться менее надежными, сложнее тестируемыми или хуже сопровождаемыми, и принимать это во внимание при распределении ресурсов разработки и тестирования. Многочисленные исследования показали, что хорошим "предсказателем" для этих целей служат метрики сложности. Наиболее известными метриками сложности являются метрики М. Холстеда (1977 год) и метрика "цикломатическое число" Т. МакКейба (1976 года). Метрики Холстеда и МакКейба широко использовались в 80-е годы, хотя и подвергались критике за излишнее упрощение и очевидный "недоучет" сложности потоков данных или неструктурных программ, что и побудило их критиков к созданию множества новых метрик, учитывающих самые разные аспекты сложности программ (например, глубина вложенности, число узлов и другие). Однако эти новые метрики определялись на отдельных программах и не были чувствительны к декомпозиции системы на процедуры и функции. Позже был предложен новый класс метрик, учитывающих сложность информационных потоков между модулями. Преимущество этих метрик состояло в том, что они могли применяться до этапа кодирования программного средства, уже во время детального модульного проектирования программного средства. Метрики, используемые при объектно-ориентированном подходе (ООП) . Хотя уже предложено немало метрик, учитывающих особенности объектно-ориентированного подхода к разработке программных средств, они, как правило, не имеют под собой теоретического базиса и не утверждены формально. Эти метрики предназначены для оценивания сложности таких конструкций и механизмов, как метод, класс, сцепление, связность, наследование Метрики ошибок. Обнаружение и своевременное устранение ошибок - основная задача процессов контроля качества программных средств. Между тем, ни за рубежом, ни в Украине, не достигнуто согласия по определению основных понятий в этой области - дефект, ошибка, отказ. Эти понятия по-разному определяются не только в научной литературе по качеству и надежности программного обеспечения, но и в стандартах. Проще всего поступили разработчики стандарта IEEE Std.1044 "Standard Classification for Software Anomalies" (Стандартная классификация аномалий программного обеспечения) , которые предпочли использовать единый термин "аномалия" (anomaly) вместо других - error, fault, failure, incident, flaw, problem, gripe, glitch, defect или bug - что для целей этого стандарта оправданно. В Украине положение усугубляется внесением "погрешностей перевода" специальных терминов в переводную литературу. Поэтому в данном изложении мы даем свое толкование используемых терминов и указываем их приемлемые английские эквиваленты. Существуют глубокие причинно-следственные связи между отказами программных средств в эксплуатации, дефектами в поставляемом программном обеспечении, ошибками разработчика и изъянами в процессах создания программных средств. Отказ (failure) - событие перехода программного средства из работоспособного состояния в неработоспособное или получения результатов, которые находятся вне области допустимых значений. Отказы программного средства могут быть обусловлены как внешними причинами (ошибками элементов среды функционирования, в том числе человека-оператора), так и внутренними причинами - дефектами в программных средствах. Дефект (defect) в программном средстве - запись элемента программы (кода) или текста документа (рабочего продукта), использование которой может привести к событию, заключающемуся в неправильной интерпретации этого элемента компьютером (ошибке (fault) в программе - ошибочному состоянию программы) или человеком (ошибке (error) исполнителя - заблуждению исполнителя). Дефект всегда является следствием ошибки исполнителя процесса на любом из этапов разработки. Дефектом могут обладать спецификации требований, проектные документы, тексты кода, эксплуатационная документация и т.д. Выходные рабочие документы одних процессов, содержащие не устраненные при проверке дефекты, служат входными документами для других процессов, а дефекты в них - источником ошибок исполнителей этих процессов. Кроме того, ошибки исполнителей могут являться следствием изъянов в определении процессов (неправильная последовательность действий, неправильно выбранный инструмент и др.), способствующих неправильной интерпретации исходной информации человеком и принятию неверных решений, или просто недостаточной профессиональной зрелостью. Ошибки исполнителей, в свою очередь, приводят к дефекту в рабочем продукте, и цикл "ошибка (error) - дефект (defect) - ошибка (error)" повторяется. Дефекты в коде, не обнаруженные в результате проверок текста кода, служат источником потенциальных ошибок и отказов программных средств. "Сработает" дефект или нет, зависит от того, по какому сценарию будет работать с программой пользователь, и "столкнется" ли обработчик кода с неправильным элементом. Дефект устраняется при проверке. Рис. 13.13. Связь ошибок, дефектов и отказов Если дефект "срабатывает" - возникает цепь ошибок, передаваемых от модуля к модулю. Если ошибка не компенсируется в программе (благодаря встроенным в программу средствам отказоустойчивости или в результате случайного "срабатывания" другого дефекта) - она может привести к аномалии в функционировании программного средства. Считать ли аномалию отказом - зависит от определения понятия отказ в спецификации требований к разрабатываемому программному средству. Обычно говорят, что в результате выполнения программы произошел Инцидент (Incident) , который проявился в виде определенной аномалии. Последующий анализ инцидента и аномалии может показать наличие Проблема (Problem) или ее отсутствие. О проблеме составляется отчет, который в виде входного документа направляется процессу "Управление решением проблем" . Таким образом, схему отказа программы можно представить цепочкой дефект в коде "(defect) [- ошибка (fault)] - аномалия (anomaly) = отказ (failure)". Основными процессами, обычно исследуемыми в проблематике инженерии качества, являются процессы внесения ошибок, устранения дефектов и процесс отказа, а ключевыми метриками - "количество дефектов", "плотность дефектов" (количество обнаруженных дефектов, деленное на размер программы) и "интенсивность отказов системы" (число отказов за определенный промежуток времени). Количество или плотность дефектов, обнаруженных в программе в ходе тестирования, нельзя считать хорошими индикаторами качества программного средства, в большей степени они служат индикаторами серьезности процесса тестирования. Тем не менее, регистрация дефектов определена как обязательное требование базового стандарта по качеству - ISO 90 00-3:1997 . Регистрация дефектов служит основой для построения банков исторических эталонных данных по программным проектам и продуктам, которые могут использоваться для сравнения вновь разрабатываемых программных средств с аналогами и улучшения процессов программной инженерии. Некоторые из них представлены в таблице 13.4. Таблица 13.4. Эталонные данные по программным проекта В таблице 13.5 представлены данные о процессах выявления и устранения дефектов, опубликованные С. Кэном . Таблица 13.5. Структура дефектов по стадиям жизненного цикла программного средства Количество (или плотность) дефектов в программе перед началом тестирования - важная метрика для определения, с одной стороны, эффективности процессов разработки (чем меньше допускается ошибок, тем лучше), и, с другой стороны - эффективности процесса инспекции (чем больше устраняется дефектов, тем эффективнее процесс). Количество дефектов, содержащихся в программе на момент начала тестирования, полезная метрика для раннего прогнозирования надежности программного средства и параметр ряда моделей роста надежности. |