ВСТУПИТЕЛЬНАЯ ЛЕКЦИЯ. ИСТОРИЯ РАЗВИТИЯ. 1 страница

6.1. Аттестация программных систем

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

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

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

Рис. 6.1. Процесс тестирования

Процесс тестирования состоит из нескольких этапов.

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

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

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

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

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

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

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

Рис. 6.2. Этапы тестирования в процессе разработки ПО

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

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

6.2. Эволюция программных систем

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

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

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

Рис. 6.3. Эволюция систем

6.3. Автоматизированные средства разработки ПО

Аббревиатура CASE (Computer-aided Software Engineering — автоматизированная разработка ПО) обозначает специальный тип программного обеспечения, предназначенного для поддержки таких процессов создания ПО, как разработка требований, проектирование, кодирование и тестирование программ. Поэтому к CASE-средствам относятся редакторы проектов. словари данных, компиляторы, отладчики, средства построения систем и т.п.

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

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

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

3. Генерирование пользовательских интерфейсов на основе графического описания интерфейса, создаваемого в диалоговом режиме.

4. Отладка программ на основе информации, получаемой в ходе выполнения программы.

5. Автоматическая трансляция программ, написанных на устаревших языках программирования (например. COBOL), в программы, написанные на современных языках.

В настоящее время подходящие CASE-технологии существуют для большинства процессов, выполняемых в ходе разработки ПО. Это ведет к определенному улучшению качества создаваемых программ и повышению производительности труда разработчиков программного обеспечения. Вместе с тем эти достижения значительно уступают тем ожиданиям, которые присутствовали при зарождении CASE-технологий. Тогда считалось, что стоит только внедрить CASE-средства — и можно получить весьма значительное повышение и качества программ, и производительности труда. Фактически это повышение составляет примерно 40%. Хотя и это повышение весьма значительно, CASE-технологии не совершили революции в инженерии программного обеспечения, как ожидалось.

Расширение применения CASE-технологий ограничивают два фактора.

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

2. Во многих организациях-разработчиках создание ПО — результат работы команды специалистов по программному обеспечению. При этом много времени тратится на «пустое» общение между членами команды разработчиков. В этой ситуации CASE-технологии не могут предложить ничего такого, что способно повысить производительность труда разработчиков.

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

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

6.4. Классификация CASE-средств

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

1. Классификация по выполняемым функциям.

2. Классификация по типам процессов разработки, которые они поддерживают.

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

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

Таблица 6.1. Классификация CASE-средств по выполняемым функциям

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

Таблица 6.2. Классификация CASE-средств по типам поддерживаемых ими процессов разработки

Другая классификация CASE-средств строится на основе широты охвата процессов разработки ПО, поддерживаемых данным средством. Предложена классификация, содержащая следующие три категории[7].

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

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

3. Рабочие среды разработчика (environments) поддерживают все или большинство процессов разработки ПО. Рабочие среды обычно включают несколько различных интегрированных инструментальных средств.

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

Рис. 6.4. Классификация CASE средств по категориям

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

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

Лекция 7. Требования к программному обеспечению

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

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

3. Проектная системная спецификация — обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и се последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований.

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

Таблица 7.1. Пользовательские и системные требования

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

Рис. 7.1. Различные типы спецификаций требований и их читатели

7.1. Функциональные и нефункциональные требования

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

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

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

3. Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.

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

7.1.1. Функциональные требования

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

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

1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных или по определенному их подмножеству.

2. Система должна предоставлять пользователю подходящее средство просмотра библиотечных документов.

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

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

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

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

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

7.1.2. Нефункциональные требования

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

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

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