Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

632 Приложение 4

Visual Studio 2005. Основная рабочая среда для всех ролей.

Microsoft Project 2003 (но не Project Server). Альтернативное средство для ру-

ководителей проекта.

Microsoft Excel 2003. Альтернативное средство для руководителей проекта.

Microsoft Internet Explorer. Используется для взаимодействия с порталом

проекта Team System, а также для просмотра отчетов.

Microsoft планирует также выпустить надстройку MSSCCI (Microsoft Source

Code Control Interface — интерфейс Microsoft для управления исходным кодом).

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

компонента Team Foundation Version Control и предыдущих версий Visual Studio.

До этого времени, равно как и в случае применения ряда программных пакетов и

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

другими средами разработки можно пользоваться любыми API и утилитами с ин-

терфейсом командной строки.

В дополнение к перечисленным средствам Microsoft и ее партнеры анонсиро-

вали выпуск множества интегрированных инструментов и сервисов Team System.

Microsoft планирует включить в состав продукта миграционные утилиты для

Microsoft Visual SourceSafe, а ее партнеры обещают поддержку дополнительных

средств моделирования, сбора требований и тестирования.

3. Поддержка качества в семействе продуктов IBM Rational

Методология фирмы IBM Rational

ориентирована на решение следующих

основных задач:

- поддержка основных процессов создания программного обеспечения – мо-

делирования, разработки и тестирования (IBM Professional Bundle, IBM Rational

Suite);

- организация совместной работы проектной команды (IBM Team Unified

Process);

- управление проектами и портфелями (IBM Portfolio Manager).

Согласно идеологии фирмы, высокий уровень качества разрабатываемых

программных продуктов может быть обеспечен применением специальной мето-

дологии построения программного обеспечения, а также инструментов поддержки

всех стадий разработки на разных операционных платформах. Как и в семействе

продуктов Visual Studio 2005, в IBM Rational предоставляются разные варианты

комплектации наборов инструментов.

Вот некоторые примеры из всего разнообразия средств IBM Rational (по ма-

териалам сайта http://rational.aplana.ru/tools)

Rational Unified Process (RUP). Это методология создания программного

обеспечения, основанная на базе знаний, размещаемой на Web и снабженной поис-

ковой системой. RUP обеспечивает строгий подход к распределению обязанностей

(выполняемых работ) и ответственности внутри проекта. Способствует повышению

производительности коллективной разработки за счет использования образцов, во-

плотивших в себе все лучшее из накопленного опыта по созданию ПС, - руко-

После приобретения в 2003 году фирмы Rational концерном IBM в название всех ее

продуктов было добавлено соответствующее название.

Приложение 4 633

водств, шаблонов и рекомендаций, касающихся различных аспектов применения

инструментальных средств. В качестве языка моделирования объектов в общей ба-

зе знаний используется Unified Modeling Language (UML). Методология RUP крат-

ко описана в главе 11.

IBM Professional Bundle - пакет, объединяющий новую линейку продуктов

Atlantic для моделирования, разработки и тестирования ПО, создаваемого на плат-

форме J2EE

В состав пакета входит весь комплекс программных средств, необходимых

предприятию для разработки, конструирования и тестирования приложений, ори-

ентированных на J2EE/порталы/службы, на платформах Windows и Linux, а также

для тестирования приложений .NET. Интегрируется со средствами организации

совместной работы IBM Rational Team Unifying Platform. В состав пакета входят

следующие средства:

IBM Rational Software Architect - инструмент проектирования и разработки

приложений на основе моделей на языке UML. Позволяет выполнить детальное

проектирование ПС и обеспечить создание качественной архитектуры. Инструмен-

ты моделирования интегрированы со средствами разработки.

IBM Rational Performance Tester – инструмент для создания, выполнения и

анализа тестов производительности, предназначенный для проверки надежности и

масштабируемости Web-приложений до их развертывания. Объединяет простое в

использовании средство для записи тестов с масштабируемым механизмом выпол-

нения, поддерживающим планирование, создание отчетов в реальном времени и

автоматическое варьирование данных.

IBM Rational Functional Tester – интегрированный набор инструментов для

поддержки выполнения функционального и регрессионного тестирования широко-

го спектра приложений, включая клиент-серверные приложения, Java, web-

приложения, web-сервисы, Microsoft Visual Studio .NET. Поддерживает управление

версиями при одновременной разработке и тестировании распределенных террито-

риально групп. Включает, также, копию ClearCase LT.

IBM Rational Suite – пакет, объединяющий инструменты поддержки органи-

зации совместной работы по моделированию и тестированию ПС для разных плат-

форм разработки. В его состав входят следующие инструменты:

IBM Rational Rose — инструмент визуального моделирования ПС с использо-

ванием широкого круга инструментальных средств и платформ. Расширяет воз-

можности моделирования ПС, выходящих за рамки платформы J2EE и инструмен-

тальных средств моделирования в составе IBM Rational Professional Bundle.

IBM Rational XDE Developer и IBM Rational XDE DeveloperPlus. Эти инстру-

менты позволяют выполнять разработку информационных систем с использовани-

ем Round-Trip подхода, предполагающего автоматизированную генерацию каркаса

кода на базе визуальной модели и обратное проектирование – построение модели

на основе существующего кода.

IBM Rational XDE DeveloperPlus - дополнительно включает продукты Rational

Purify, Quantify и PureCoverage. Также в данный инструмент входит Rational Visual

J2EE – Java2 Enterprise Edition

634 Приложение 4

Trace, который позволяет создать диаграмму последовательности на основе выпол-

нения приложения. Этот продукт позволяет отображать созданные объекты прило-

жения и последовательность вызовов их методов.

Средства IBM Rational XDE Developer и IBM Rational XDE DeveloperPlus по-

ставляются для конкретных платформ разработки приложений.

IBM Rational XDE Tester – інструмент для функционального и регрессионного

тестирования Java- и Web-приложений для сред разработки Eclipse IDE, IBM

WSAD и Rational XDE.

IBM Rational Robot - инструмент поддержки создания, записи и выполнения

скриптов автоматизированного функционального и регрессионного тестирования

Java- и Web-приложений, а также предоставляющий полную поддержку тестирова-

ния элементов управления Visual Studio .NET для приложений Oracle Forms, Bor-

land Delphi, Sybase PowerBuilder.

IBM Rational PurifyPlus for Windows - выявление ошибок, связанных с обра-

щением к динамической памяти.

Rational PureCoverage. Это динамический анализатор покрытия, помогающий

выявить участки кода, пропущенные при тестировании. Определяет размер про-

граммы в строках кода (SLOC). Входит в состав набора инструментов тестирования

Rational PurifyPlus.

IBM Rational Quantify. Предназначен для выявления узких мест в коде, ока-

зывающих влияние на производительность ПС.

IBM Rational Team Unifying Platform (Объединяющая платформа) – набор

инструментов для организации совместной работы команды проекта. Использо-

вание средств коллективной разработки IBM Rational помогает синхронизировать

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

проекта об изменениях.

В основе работы инструментария лежит подход Unifying Change Management

(UCM), позволяющий организовать индивидуальные рабочие пространства для ка-

ждого участника проекта на базе единого репозитория. В зависимости от специфи-

ки деятельности конкретного участника проекта он использует необходимые инст-

рументы. Интеграция указанных средств позволяет объединить деятельность всей

команды в единый и четкий процесс построения эффективной ПС.

В состав набора входят следующие средства совместного управления проек-

тами и создания коллективной инфраструктуры:

IBM Rational RequisitePro - средство управления требованиями, позволяюще-

ее коллективу справляться с постоянно меняющимися требованиями;

IBM Rational ClearQuest – средство

отслеживания всех типов запросов на

изменения для любого проекта

, позволяющее управлять запросами на внесение

изменений и отслеживание проблем (от их возникновения до закрытия) на всех

стадиях разработки. Изменения архивируются в специально создаваемой для этого

базе данных. В качестве СУБД может использоваться MS SQL, MS Access, Sybase

SQL Anywhere или Oracle. Обеспечивает возможность добавлять собственные SQL-

запросы к существующей базе данных. Предоставляет стандартные и настраивае-

мые пользователем графические и табличные отчеты о состоянии проекта и исто-

рии внесения изменений. Имеет средства автоматического предупреждения и опо-

вещения по электронной почте.

Приложение 4 635

Интеграция ClearQuest с Rational RequisitePro позволяет связать требования к

разрабатываемой ИС с конкретными запросами на изменение. Таким образом, если

появились новые требования или изменились существующие, то легко определить,

какие запросы на улучшение или обнаруженные ошибки в системе послужили ис-

точником для этого.

Интеграция ClearQuest с Rational ClearCase предоставляет возможность на-

ладить контроль не только за запросами на изменения, но и за любыми изменения-

ми в артефактах проекта. В этом случае никто не сможет изменить ни один арте-

факт до тех пор, пока для него не определена соответствующая задача. Таким обра-

зом, значительно повышается контроль за ходом процесса разработки.

Интеграция ClearQuest со средствами тестирования позволяет вносить описа-

ния обнаруженных ошибок прямо по его результатам. Описание ошибки можно

взять либо прямо из журнала тестирования, сформированного в Rational

TestManager, либо из отчета по результатам анализа, выполненного в реальном

времени с помощью Rational Purify, Rational Quantify, Rational PureCoverage.

Интеграция ClearQuest с Rational SoDA позволяет автоматически формиро-

вать отчеты в необходимом виде по любым запросам на изменения.

Интеграция ClearQuest с Microsoft Project позволяет быстро сформировать

список задач для участников проекта, детализировать этот список до конкретных

поручений и реально отслеживать, не выходит ли проект за определенные в плане

проекта сроки, ресурсы и бюджет.

IBM Rational ClearCase — инструмент управления конфигурацией, версиями,

служащий в качестве общего репозитория для всех объектов разработки ИС. Все,

что создается и меняется в процессе разработки, может быть поставлено на верси-

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

шается надежность и качество работы проектной команды.

IBM Rational TestManager – инструмент для поддержки планирования и

управления процессом тестирования, а также классификации и отслеживания де-

фектов, обнаруженных на любой стадии разработки. Позволяет связывать тесты с

требованиями, планами тестирования, проверять полноту охвата требований набо-

ром тестов и пр. Поддерживает стандартные и настраиваемые пользователем отче-

ты о качестве и результатах тестирования. Продукт интегрирован с остальными

продуктами Rational Suite, но может использоваться самостоятельно для поддержки

процесса «Решение проблем» и управления тестированием.

IBM Rational Project Console — средство мониторинга ключевых показателей

проекта, которое упрощает контроль за статусом проекта и генерирование объек-

тивных метрик проекта с целью улучшения его предсказуемости.

IBM Rational SoDA — средство документирования, автоматизирует создание

и сопровождение проектной документации и отчетов.

Помимо перечисленных примеров наборов инструментов, специально для

поддержки контроля качества ПС, IBM Rational предлагает инструмент TestFactory

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

ного тестирования ПС. Новаторство инструмента заключается в автоматическом

создании «эффективных» сценариев тестирования, которые позволяют проверить

все части приложения за минимальное число шагов. Инструмент позволяет постро-

ить карту приложения, на основе которой с помощью Rational Robot можно автома-

тически генерировать тестовые скрипты. После этого TestFactory использует мет-

636 Приложение 4

рики покрытия кода для определения того, какая часть приложения была протести-

рована. Поскольку тестовые скрипты генерируются автоматически, то тестировщи-

ки могут протестировать каждую сборку, проверяя ее на надежность, независимо от

стадии разработки.

Дополнительную информацию об этих и других продуктах Rational можно

получить в компании Interface Ltd. (www.interface.ru) и на сайтах

rational.aplana.ru/tools/testing-tools.asp и www-306.ibm.com/software/rational/).

4. Отслеживание дефектов с помощью инструмента

Borland StarTeam

Наряду с рассмотренными выше инструментами известных фирм, в Украине

также широко используются программные продукты фирмы Borland. Среди них

для контроля за процессом разработки и отслеживания динамики устранения де-

фектов может использоваться инструмент управления конфигурацией и измене-

ниями Borland StarTeam.

Ниже перечислены основные возможности Borland StarTeam по обеспечению

качества (по материалам сайта www.borland.com/starteam/):

•

Хранение и отслеживание важной информации с помощью центрального

репозитория. Центральный репозиторий Borland StarTeam обеспечивает безопас-

ность, доступность и просмотр всех информационных ресурсов, необходимых для

разработки проекта, включая файлы, запросы на изменение, задачи, требования,

темы и другие определяемые пользователем объекты.

•

Интеграция с другими инструментами поддержки жизненного цикла при-

ложения. Поскольку StarTeam предназначен для прямой интеграции с существую-

щими средствами разработки, его можно интегрировать с различными технология-

ми и инструментами на протяжении всего ЖЦ приложения. StarTeam полностью

поддерживает стандарт Microsoft Source Code Control (SCC) API и, следовательно,

может быть интегрирован с инструментами на основе этого стандарта. Кроме того,

открытая архитектура StarTeam позволяет включать в любые приложения файлы,

запросы на изменения, задания, темы и требования. Независимо от того, использу-

ются ли Borland JBuilder, Borland CaliberRM, Mercury Interactive TestDirector, Micro-

soft Project, соответственно, в качестве средств разработки, управления требова-

ниями, управления тестированием и управления проектом или нет, StarTeam может

связать любой содержащийся в его репозитории информационный объект с соот-

ветствующими позициями, на которые этот объект оказывает влияние.

•

Обеспечение высокой производительности удаленно работающих групп.

Репозиторий StarTeam предоставляет всем сотрудникам рабочих групп доступ к

самым последним версиям информационных объектов, обеспечивая заданный уро-

вень безопасности и выполнение необходимых процессов управления изменения-

ми. Поскольку web-архитектура StarTeam поддерживает связь по протоколу TCP/IP

со всей областью доступа сервера, пользователь может использовать различные

клиентские интерфейсы с любого рабочего места с любой из следующих платформ:

Windows, UNIX, Linux, Mac OS X.

•

Гибкая настройка. Функциональные возможности StarTeam могут быть на-

строены и расширены в зависимости от потребностей конкретной организации.

Комплект разработчика программного обеспечения StarTeam SDK, содержащий

открытые программные интерфейсы Java и COM, поддерживает разработку спе-

Приложение 4 637

циализированных решений, включая настраиваемые клиентские приложения и ин-

теграции.

5. Инструменты тестирования Web-приложений

В таблице 5.1 для справки перечислены некоторые примеры программных

продуктов, позволяющих выполнять тестирование Web-приложений (по материа-

лам сайта http://rational.aplana.ru/tools/testing-tools.asp).

Таблица 5.1. Некоторые инструменты тестирования Web-приложений

Название Краткая характеристика Разработчик

IBM Rational

Web Developer

Инструмент для быстрой разработки,

тестирования и развертывания web-

приложений web-служб и приложе-

ний Java в среде IDE

IBM Rational

http://rational.aplana.ru/products

IBM Rational

XDE Tester.

Инструмент для функционального и

регрессионного тестирования Java- и

Web-приложений.

IBM Rational

http://rational.aplana.ru/products

e-TEST suite Набор интегрированных инструмен-

тов для тестирования Web-

приложений:

e-Manager Enterprise – управление

процессом тестирования;

e-Tester – автоматизированное функ-

циональное и регрессионное тести-

рование;

e-Load – тестирование производи-

тельности.

Empirix

http://www.empirix.com

Microsoft Web

Application

Stress Tool

Тестирование производительности

Web-сервера для среды Windows.

Microsoft

www.javausergroup.at/events/w

as.pdf

PureLoad Web Инструмент тестирования Web-

серверов для платформ Windows,

Sun Solaris, Red Hat Linux.

Minq Software

www.minq.se/ products/ pure-

load/ doc/ html/ web/ users-

guide/ index.html

LoadRunner

Анализ производительности круп-

ных распределенных ИС. Поддержи-

вает тестирование Web-серверов, баз

данных, компонентов COM, Java-

Beans, виртуальных машин Java и т.д

Mercury Interactive

http://www.mercury.com/us/pro

ducts

QALoad

Инструмент тестирования и анализа

Web-серверов, FTP-серверов, серве-

ров баз данных, а также распреде-

ленных систем, построенных на ос-

нове CORBA

Compuware

www.compuware.com/products/

qacenter/qaload/detail.htm

Литература

1. Дорси П. Oracle Designer Настольная книга пользователя. Издание второе. –М.: ЛОРИ. –

1999. – 592 с.

2. Хандхаузен Р. Знакомство с Microsoft Visual Studio 2005 Team System. - Санкт-

Петербург: Изд. «Питер». – 2006 (http://www.piter.com/chapt.phtml?id=978546901218)

638

Приложение 5. ПРИМЕРЫ КОНТРОЛЬНЫХ

ВОПРОСНИКОВ ДЛЯ ПРОВЕДЕНИЯ ИНСПЕКЦИИ

Вопросы для инспекции описания требований

1. Ясность

1.1. Действительно ли требования написаны на «не техническом» понятном языке?

1.2. Нет ли требований, которые могли бы иметь более одной интерпретации?

1.3. Действительно ли каждая характеристика конечного продукта описана с примене-

нием унифицированной терминологии?

1.4. Существует ли глоссарий, в котором разъясняется смысл каждого термина?

1.5. Могут ли быть требования осмыслены и реализованы независимой группой разра-

ботчиков?

2. Полнота

2.1. Присутствует ли оглавление (содержание)?

2.2. Помечены ли все рисунки, таблицы и диаграммы?

2.3. Имеют ли все рисунки, таблицы и диаграммы правильные перекрестные ссылки?

2.4. Все ли термины определены?

2.5. Все ли термины упомянуты в индексе?

2.6. Все ли единицы измерения определены?

2.7. Специфицированы ли области, где нет полной информации из-за того, что разра-

ботка не начата?

2.8. Есть ли в определении требований указания на упущенную информацию?

2.9. Должны ли какие-либо требования быть специфицированы подробнее?

2.10. Должны ли какие-либо требования быть специфицированы менее подробно?

2.11. Все ли требования определены?

2.12. Все ли требования, касающиеся функциональности, включены?

2.13. Есть ли какие-либо требования, которые Вы считаете сложными?

2.14. Все ли требования, касающиеся производительности, включены?

2.15. Все ли требования, касающиеся ограничений проекта, определены?

2.16. Все ли требования, касающиеся атрибутов, включены?

2.17. Все ли требования, касающиеся внешних интерфейсов, включены?

2.18. Все ли требования, касающиеся баз данных, включены?

2.19. Все ли требования, касающиеся ПО, включены?

2.20. Все ли требования, касающиеся коммуникаций, включены?

2.21. Все ли требования, касающиеся аппаратного обеспечения, включены?

2.22. Все ли требования, касающиеся входов, включены?

2.23. Все ли требования, касающиеся выходов, включены?

2.24. Все ли требования, касающиеся отчетов, включены?

2.25. Все ли требования, касающиеся безопасности, включены?

2.26. Все ли требования, касающиеся сопровождаемости, включены?

2.27. Все ли требования, касающиеся инсталляции, включены?

2.28. Все ли требования, касающиеся критичности, включены?

2.30. Все ли требования, касающиеся ограничений производительности, включены?

2.31. Специфицированы ли возможные изменения в требованиях?

2.32. Для каждого ли требования специфицирована вероятность его изменения?

3. Согласованность

3.1. Есть ли какие-либо требования, описывающие тот же объект, что и другие требо-

вания, конфликтуя с ними в отношении терминологии?

3.2. Есть ли какие-либо требования, описывающие тот же объект, что и другие, кон-

фликтуя с ними в отношении характеристик?

Приложение 5 639

3.3. Есть ли какие-либо требования, которые описывают два и более действия, логиче-

ски конфликтующих?

3.4. Есть ли какие-либо требования, которые описывают два и более действия, терми-

нологически конфликтующих?

4. Трассируемость

4.1. Все ли требования трассируемы к определенным нуждам пользователей?

4.2. Все ли требования трассируемы к определенным исходным документам или другим

источникам информации (например, устным договоренностям)?

4.3. Все ли требования допускают трассировку к ним определенных проектных доку-

ментов?

4.4. Все ли требования допускают трассировку к ним определенных модулей ПО?

4.5. Верифицируемость

4.6. Все ли требования трассируемы к определенным нуждам пользователей?

4.7. Включены ли какие-либо требования, которые невозможно реализовать?

4.8. Для каждого ли требования существует процесс, который может быть выполнен

вручную или автоматизировано с целью проверки требования?

4.9. Есть ли какие-либо требования, которые будут представлены в пригодных для ве-

рификации терминах позже?

5. Модифицируемость

5.1. Все ли требования трассируемы к определенным нуждам пользователей?

5.2. Действительно ли документ требований четко и структурировано изложен?

5.3. Отвечает ли форма и содержание документа требований принятым стандартам?

5.4. Есть ли дублирование в требованиях?

6. Общее содержание

6.1. Каждое ли требование адекватно проблеме и ее решению?

6.2. Не являются ли какие-либо требования в действительности проектными деталями?

6.3. Не являются ли какие-либо требования в действительности деталями верификации?

6.4. Не являются ли какие-либо требования в действительности деталями управления

проектом?

6.5. Есть ли в документе раздел введения?

6.6. Есть ли в документе раздел основного описания требований?

6.7. Есть ли в документе раздел с описанием сферы действия?

6.8. Есть ли в документе раздел с определениями, акронимами, аббревиатурой?

6.9. Есть ли в документе раздел, в котором представлены специальные требования?

6.10. Есть ли в документе раздел с описанием перспектив применения продукта?

6.11. Есть ли там раздел с описанием функций продукта?

6.12. Есть ли там раздел с описанием категорий пользователей продукта?

6.13. Есть ли там раздел с описанием общих ограничений?

6.14. Есть ли там раздел с описанием предположений и зависимостей?

6.15. Есть ли там раздел с указанием специальных требований?

6.16. Присутствуют ли в документе все необходимые приложения?

6.17. Присутствуют ли в документе все необходимые рисунки?

6.18. Присутствуют ли в документе все необходимые таблицы?

6.19. Присутствуют ли в документе все необходимые диаграммы?

7. Специальные требования

Входы

1. Все ли источники ввода специфицированы?

2. Все ли требования к точности входных данных специфицированы?

3. Все ли области значений для входов специфицированы?

4. Указана ли частота поступления данных от всех источников?

640 Приложение 5

5. Все ли форматы входных данных специфицированы?

Выходы

1. Все ли пункты назначения выходных данных специфицированы?

2. Все ли требования к точности выходных данных специфицированы?

3. Все ли области значений для выходов специфицированы?

4. Указана ли частота выдачи данных?

5. Все ли форматы выходных данных специфицированы?

Отчеты

1. Все ли форматы отчетов специфицированы?

2. Все ли вычисления /формулы, используемые в отчетах, специфицированы?

3. Все ли требования по фильтрации данных в отчетах специфицированы?

4. Все ли требования по сортировке данных в отчетах специфицированы?

5. Все ли требования по подведению итогов в отчетах специфицированы?

6. Все ли требования в форматированию отчетов специфицированы?

Функции

1. Все ли функции ПО специфицированы?

2. Все ли входы для каждой функции специфицированы?

3. Все ли аспекты обработки специфицированы для каждой функции?

4. Все ли выходы специфицированы для каждой функции?

5. Все ли требования по производительности для каждой функции специфициро-

ваны?

6. Все ли проектные ограничения специфицированы для каждой функции?

7. Все ли атрибуты специфицированы для каждой функции?

8. Все ли требования по безопасности специфицированы для каждой функции?

9. Все ли требования по сопровождаемости специфицированы для каждой функ-

ции?

10. Все ли требования к базам данных специфицированы для каждой функции?

11. Все ли операционные требования специфицированы для каждой функции?

12. Все ли инсталляционные требования специфицированы для каждой функции?

Внешние интерфейсы

1. Все ли пользовательские интерфейсы специфицированы?

2. Все ли интерфейсы пакетной обработки специфицированы?

3. Все ли интерфейсы с оборудованием специфицированы?

4. Все ли программные интерфейсы специфицированы?

5. Все ли коммуникационные интерфейсы специфицированы?

6. Все ли проектные ограничения специфицированы?

7. Все ли требования по безопасности интерфейсов специфицированы?

8. Все ли требования по сопровождаемости интерфейсов специфицированы?

9. Все ли сценарии человеко-машинного взаимодействия специфицированы при

описании пользовательских интерфейсов?

Внутренние интерфейсы

1. Идентифицированы ли все внутренние интерфейсы?

2. Все ли характеристики внутренних интерфейсов специфицированы?

Затраты времени

1. Все ли ожидаемые периоды процессорной обработки специфицированы?

2. Все ли интенсивности передачи данных специфицированы?

3. Все ли интенсивности трафиков в системе специфицированы?

Надежность

1. Специфицированы ли последствия отказа ПО для каждого требования?

2. Специфицирована ли информация, которая должна защищаться при отказе?

3. Специфицированы ли стратегии обнаружения дефектов?

Приложение 5 641

4. Специфицированы ли стратегии корректировки дефектов?

Компромиссы

1. Специфицированы ли приемлемые компромиссы для конкурирующих атрибу-

тов?

Техническое обеспечение

1. Специфицирована ли минимальная оперативная память?

2. Специфицирована ли минимальная дисковая память?

3. Специфицирована ли максимальная оперативная память?

4. Специфицирована ли максимальная дисковая память?

Программное обеспечение

1. Специфицированы ли программные среды и операционные системы?

2. Специфицированы ли все требуемые программные утилиты?

3. Специфицированы ли все приобретаемые продукты ПО, которые должны ис-

пользоваться в системе?

Коммуникационные среды

1. Специфицирована ли сеть, с которой будет использоваться система?

2. Специфицированы ли требуемые сетевые протоколы?

3. Специфицирована ли производительность сети?

4. Специфицирована ли требуемая (ожидаемая) пропускная способность сети?

5. Специфицировано ли оценочное количество сетевых соединений?

6. Специфицированы ли минимальные требования к производительности сети?

7. Специфицированы ли максимальные требования к производительности сети?

8. Специфицированы ли оптимальные требования к производительности сети?

Вопросы для инспекции спецификации проекта

1. Функциональность

1.1. Определена ли используемая терминология? Соответствует ли она общепринятой

терминологии в данной области и совпадает ли она с терминологией спецификации в

техническом задании (ТЗ)? Обозначает ли один и тот же термин одно понятие?

1.2. Представлена ли информационно-функциональная схема проекта отражающая

взаимосвязь задач и потоков данных в ПО? Адекватна ли она концептуальной модели

проблемной области?

1.3. Представлена ли таблица или схема соответствия функций, указанных в ТЗ, и за-

дач, которые реализуют эти функции?

1.4. Покрывают ли представленные постановки задач все функции, указанные в ТЗ?

1.5. Все ли функции ТЗ (задачи) представлены описаниями своих входов, выходов и

алгоритмов обработки (решения)?

1.6. Представлено ли общее описание алгоритма функционирования ПО? Адекватно ли

оно модели пользователя ПС (отражающей технологию использования ПО)?

1.7. Достаточно ли обоснован выбор математических методов и алгоритмов? Адекват-

ны ли математические методы и алгоритмы модели предметной области?

1.8. Достаточно ли полно определены модели данных по отношению к требованиям к

информационным структурам в ТЗ?

1.9. Обоснован ли выбор методов организации и доступа к данным? Адекватны ли ме-

тоды организации и доступа к данным выбранным моделям данных?

1.10. Описаны ли допущения и ограничения, связанные с выбранным математи-

ческим аппаратом? Адекватны ли они применяемым алгоритмам, описаниям струк-

тур данных, а также требованиям к функциональным характеристикам ПО и техни-

ческим характеристикам среды функционирования ПО?