И. Соммервилл - Инженерия программного обеспечения (1133538), страница 20

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 20)

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

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

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

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

Поэтому эти работы должны быть спланированы 3. Процесс создании программного обеспечении 73 заранее. Если тестирование выполняет независимая команда испытателей, планы проведения тестирования должны быть согласованы с этапами разработки спецификации и проектирования. На рис. ЗЛ2 показано, как планы тестирования могут быль связаны с другими процессами разработки ПО. Рис. 3.12. Зтляы телзлкроеянкя в лрокесгефазработки ПО Приемочные испытания иногда называют альфа-ямсяифеванкен.

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

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

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

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

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

жет в несколько раз превышать стоимость разработки, все равно процесс сопро- 74 <Масть 1. Инженерия программного обеспеченилп обзор вождения считается менее творчсскил< н ответственным, чем процесс первоначального создания системы. В настоящее время упомяиутал демаркационная линия между процессами разработки и сопровождения постепенно стирается. Только немногие вновь создаш<ые программные системы можно назвать полностью новыми.

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

3.15. Ряс. 3. 13. Эав<юцкл п<сэим 3.7. Автоматизированные средства разработкиПО Лббрсвиазура СЛЯЕ (Со<при<сгкаЫс<1 Бой<ваге Епя<пее<(пя — автоматизированная разработка ПО) обозначает снсцивлыи <й пш програз«и<ого обеспечения. предназначенного для и<юлсржки таких процессов созщншя ПО, как разработка требований, прослгироваиие, ко. дироюишс и тестирование програзи<. Поэтому к САЯЕ. средствам относятся редакторы про. ектов. словари дщшых, компиляторы, отладчики, средства построения систем и т,п. САБЕ-технологии прсллага<от поллерэау процесса соэлашш ПО и<чем автоматизации некоторых втапов разработки, а также соэлаиил и предоставления информации, иеобходилшй для разработки. Приведем примеры тех процессов, которые можно автоматизиро. вать с помощью СЛЯЕ.средств. 1.

1'заработка графических моделей системы иа этапах создания спецификации и проектирования, 2. Проектирование структуры ПО с использованием словарей данных, храпящих ин- формацию об объектах структурь< и связях между инни. 3. Генерирование пользовательских интерфейсов на основе графического описания интерфейса, создаваемого в диалоговом режиме. 4. Отладка программ иа основе информации, получаемой в ходе выполнения про- граммы.

5. Автоматическая траисллция программ, написанных на устаревших языках программирования (например. СОВО1.), в программы, написанные иа современных языках. 3. Процесс создания программного обеспечения 7Б В настоящее время подходящие САБЕ технологии с>зцествуют ллл большинства процессов. выполняемых в ходе разработки ПО. Это ведет к определенному уийчшспию качества создаваемых программ и повышению производительности труда разработчиков пргнраммиого обеспечения. Вместе с тем этн постижения значительно усгупают тем ожиданиям, которые присутствовали при зарождении САБЕ.технологий.

'!'огда счпталгкь, гго стоит только внедрить САЯЕгредстаа — и можно получить весьма значительное повышение и качества программ, и производительности труда. Фактичесюз это повышение составляет примерно 40% ! !Г>Б]. Хотя и это повышение весьма значительно. САЯЕ технолопщ нс соверпгилп революции в инженерии программного обеспечения, как ожидалось.

Расширение применения СЛБЕ технологий ограничивают два фалтора. 1. Создание ПО, особенно этап проектирования, во многом является творческим процессом. Существ>ющие СЛБЕ-средства автоматизируют рутинные процессы, попытки привлечь их к решению интеллектуальных и творческих задач праслтирования особым >снохам нс > венчал>гол. 2. Во многих организациях.разработчиках создание ПΠ— результат работы команды специалистов по программному обеспечению. Прп этом много врслгсгггг тратится на "пустое" обнгспис между членами команды разработчиков. В этой сгпзуации САБЕ-технологии нс ыог>т предложить ничего такого, что способно повысить производительность труда разработчиков. Отомр>т ли эти факторы в бул>зцсм, иска неясно.

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

В настоящее время сложилась развитая индустрил СЛЯЕ-средств кр>т возможных поставщиков и разработчиков этих программных продуктов очень ншрокэ . Вместо того чтобы детально рассматривать отдельные СЛБЕ.продукты, здеп, будет гдслап пх обзор, а в последующих главах кппгп при рассмотрении соответгтвугщцих тем искаторыс из них Г>у. дуг описаны более подробно, Па >5>с»-стра>>и>>с этой книги писк>тгя ссылки иа Г>алсс подробный материал о САБЕ технологиях и на поставя>икогг СЛБЕ.средств. 3.7.1.

Классификация САЗЕ-средств Классификация САБЕ-средств помогает понять их основные типы и роль, которую оии играют в поддержке процегсов создания программпага обеспечения. Суп>сствует носк>>лгн ка различных классификаций САЯ>бсрсдств, и кажлая ггрсдиапгст свой взгляд па эти программные продукты. 15 этом разлелс рассматриваются следующие кзасспфикации. 1. Классификация но вмнаиикжым фуггкцккк 2. Классификация но тином ну>ог!вигов >>их>>обои>хи, которые опп поддерживают.

Характеристики

Список файлов книги