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

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

592 Глава 12

нию внутренних проверок (аудитов) СМК и, кроме того, содержатся руководства

по самооцениванию СМК.

Для разработчиков ПС интерес представляет также международный стандарт

ISO 90003:2004 (нет гармонизированного стандарта ДСТУ) ”Software engineering --

Guidelines for the application of ISO 9001:2000 to computer software” (Программная

инженерия -- Руководящие указания по применению ISO 9001:2000 к компьютер-

ному ПО). Этот стандарт разъясняет порядок применения ISO 9001 при приобрете-

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

чения и связанных с ним услуг, не вступая в противоречие с требованиями ISO

9001. По сравнению с отмененным стандартом ISO 9000-3 он в большей степени

приспособлен к специфике отрасли, в частности, ссылается на модели ЖЦ ПС и

детально рассматривает вопросы, характерные для разработки ПО. Однако стан-

дарт ISO 90003:2004 – это стандарт обеспечения качества и не может быть исполь-

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

та. Положения стандарта не определяют критерии оценивания СМК при ее серти-

фикации.

Проверка систем менеджмента качества регулируется международным стан-

дартом ISO 19011:2002 (ДСТУ ISO 19011:2003) «Руководство по аудитам СМК и

(или) систем экологического менеджмента», который обеспечивает руководящие

указания по управлению и проведению внутреннего и внешнего аудитов СМК.

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

ции аудиторов СМК, а также управлению программой проверок [33].

Достаточно полный обзор и рекомендации по применению стандартов ISO

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

в книге В.В. Липаева «Обеспечение качества программных средств. Методы и

стандарты» [34]. Сопоставительный анализ моделей CMM, CMMI, SPICE, ISO 9000

и др. проведен, например, в [35].

12.4.2. Сертификация программных продуктов и систем менеджмента

качества

Сертификация – это эффективный механизм обеспечения гарантии соответ-

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

менеджмента качества требованиям нормативно-методической базы качества

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

стандарте ДСТУ 2464 [36].

Сертификация выполняется аккредитованными независимыми Органами

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

предприятием (организацией), отвечает обязательным требованиям нормативных

документов, а все технические административные и человеческие факторы, влияю-

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

ции оформляются сертификатом.

Сертификация системы менеджмента качества проводится в соответст-

вии с ДСТУ 3419-96 [37], заключается в сравнение фактической информации о сис-

теме менеджмента качества предприятия (организации) с моделью СМК, опреде-

ленной в стандартах ISO, и может выполняться по инициативе Заявителя или по

решению Органа сертификации.

Глава 12 593

Цели сертификации могут быть разными:

• получение независимой оценки состояния СМК для обеспечения внут-

ренней уверенности в способности предприятия стабильно обеспечивать выпуск

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

• получение сертификата соответствия как средства повышения доверия к

предприятию со стороны потребителей и расширения рынков сбыта продукции (ус-

луг);

• получение сертификата соответствия по требованию конкретного по-

требителя для повышения его уверенности в способности предприятия стабильно

выполнять условия договора.

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

два года и зависит от множества факторов, основными из которых являются:

• уровень управления качеством на предприятии к моменту начала подго-

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

товки персонала, уровень взаимопонимания в отношениях с партнерами и т.д.);

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

• наличие аттестованных специалистов по сертификации систем менедж-

мента качества.

Время на разработку и внедрение системы менеджмента качества можно со-

кратить, если подготовить несколько экспертов по сертификации СМК из числа

руководящих работников организации, а также группу экспертов по внутренним

проверкам СМК.

Примерная последовательность шагов процесса сертификации СМК указана

ниже петитом.

1. Заявитель подает в Орган сертификации обращение о намерении сертифицировать систе-

му менеджмента качества.

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

ях начала работы.

3. Заявитель оплачивает регистрационный взнос.

4. Орган сертификации регистрирует копию платежного поручения об оплате регистрацион-

ного взноса, уведомляет Заявителя о произведенной оплате и дает «добро» на начало работ.

5. Орган сертификации направляет Заявителю следующие документы: Форма декларации-

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

тельной оценки СМК.

6. Заявитель предоставляет следующие документы: Декларация-заявка, Политика в области

качества, Руководство по качеству, Анкета-вопросник (заполненная форма), Исходные данные для

предварительной оценки производства (заполненная форма), Структурная схема организации,

Структурная схема службы качества, Перечень документов СМК.

7. Дополнительно Орган сертификации может запросить: Стандарт предприятия «Управ-

ление документацией», Стандарт предприятия «Внутренние проверки СМК».

8. Орган сертификации проводит анализ комплектности представленной документации.

9. Орган сертификации уведомляет Заявителя о принятии заказа на сертификацию или об

отказе в принятии заказа на сертификацию (в последнем случае – возврат к шагу 1).

10. Орган сертификации оформляет договор на проведение предварительной оценки СМК.

11. Стороны подписывают договор и Заявитель производит оплату услуг Органа сертифика-

ции.

12. Орган сертификации назначает главного эксперта и формирует комиссию.

594 Глава 12

13. Комиссия выполняет анализ системы качества Заявителя по представленным исходным

документам и материалам.

14. Комиссия составляет заключение по результатам предварительной оценки. В случае отри-

цательного заключения – возврат к шагу 1).

15. Орган сертификации оформляет договор на проведение второго этапа сертификации.

16. Стороны подписывают договор и Заявитель производит оплату услуг.

17. Комиссия разрабатывает программу проверки.

18. Комиссия проводит проверку.

19. Комиссия составляет заключение по результатам проверки.

20. Комиссия принимает решение рекомендовать систему менеджмента качества к сертифи-

кации. Если заключение отрицательное – возврат к шагу 1.

21. Орган сертификации принимает решение о регистрации сертификата в Реестре Регистра и

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

22. Орган сертификации пересылает заявителю: Сертификат системы менеджмента каче-

ства, Лицензии на применение знака соответствия.

23. Орган сертификации оформляет договор на проведение инспекционного контроля.

24. Стороны подписывают договор и Заявитель производит оплату услуг.

25. Орган сертификации ежегодного проводит инспекционный контроль соответствия серти-

фицированной системы менеджмента качества. Если результаты отрицательны – возврат к шагу 1.

26. Орган сертификации подтверждает действие сертификата и знака соответствия. Он может

также приостановить его действие, либо вообще аннулировать сертификат.

Сертификация может быть обязательной или добровольной. Обязательная

сертификация применима по отношению к системам менеджмента качества, пред-

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

ределяется заказчиком (потребителем) ПС. В остальных случаях рекомендуется

необязательная (добровольная) сертификация.

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

дукции и услуг в Украине работает государственная Система сертификации про-

дукции УкрСЕПРО, объединяющая 149 Органов сертификации, а также 811 испы-

тательных лабораторий.

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

вой центр качества «ПРИРОСТ» (prirost.udc.com.ua), аккредитованный в "МО Со-

вАсК" с 1994 г., а в УкрСЕПРО - с 2000 г. Это головная организация по вопросам

качества и сертификации Украинской ассоциации качества, единственная в Украи-

не избранная членом Европейского фонда управления качеством (EFQM).

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

ных средств, является Украинский научный центр государственной регистрации и

сертификации информационных технологий «Софт-Рейтинг» (www.softrating.

com.ua/ukr/about.htm). Это базовая организация рабочей группы РГ6 «Випробуван-

ня, сертифікація та управління якістю програмних засобів ЕОМ» подкомитета ПК7

«Інженерія програмних засобів. Автоматична ідентифікація та методи роботи з да-

ними. Управління даними та обмін» Украинского технического комитета по стан-

дартизации ТК20 «Інформаційні технології». По данным сайта «Софт-Рейтинг» -

это первая в Украине независимая и технически компетентная организация – Орган

сертификации (УКРСЕРТСОФТ), аккредитованный Госпотребстандартом Украи-

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

Глава 12 595

сертификации УкрСЕПРО, а также предоставляет услуги по созданию систем ме-

неджмента качества и испытательных лабораторий. Сертификат соответствия вы-

дается УКРСЕРТСОФТ на период 1, 2 или 3 года в зависимости от выбранной схе-

мы сертификации. Схема учитывает серийность программного средства (единич-

ное или серийное) и спектр необходимых услуг (обследование производства, атте-

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

технический надзор) (http://www.softrating.com.ua/ukr/Rules.htm).

Кроме указанных Органов сертификации услуги сертификации СМК в орга-

низациях-разработчиках ПС Украины оказывают, например, Бюро Международной

Сертификации – SIC (www.sic.com.ua/org.php), Бюро Веритас Украина

(http://www.bureauveritas.com.ua) и другие Органы сертификации, осуществляющие

деятельность на территории Украины (http://www.sic.com.ua/org.php).

Литература к главе 12

ISO/IEC 12207:1995 / Amd.1:2002 Information technology – Software life cycle processes

2. Коваль Г.И. Подход к прогнозированию надежности ПО при управлении проектом //

«Проблемы программирования». –2002. - № 1 – 2. – C. 282 – 290.

3. Подход к управлению качеством программных систем обработки данных / Лаврищева

Е.М., Коваль Г.И., Коротун Т.М. // Кибернетика и системный анализ. – 2006.-

№5.-

с.174-185.

4. ISO/IEC 14598-1:1999. Information technologies - Software product evaluation - Part 1: Gen-

eral overview.(или

ДСТУ ISO/IEC 14598-1-2004.

Iнформацiйнi технологiї. Оцiнювання про-

грамного продукту. Частина 1. Загальний огляд).

5. ISO/IEC 14598-3:2000. Software Engineering - Product evaluation - Part 3: Process for de-

velopers.

6. ISO/IEC 14598-4:1999. Software Engineering - Product evaluation - Part 4: Process for ac-

quirers.

7. ISO/IEC 14598-5:1998. Information Technologies - Software product evaluation - Part 5:

Process for evaluators.

8. ISO/IEC 15026:1998. Information technologies - System and software integrity levels.

9. ДСТУ 2850-94. Програмні засоби ЕОМ. Показники і методи оцінювання якості.

10. Липаев В.В. Выбор и оценивание характеристик качества программных средств. Мето-

ды и стандарты. Серия «Информационные технологии». М.: СИНТЕГ, 2001. – 228 с.

11. ГОСТ 28195-99. Оценка качества программных средств. Общие положения.

12. DTR 9126-3:2001. Software Engineering - Product Quality - Part 3:Internal Metrics //

ISO/IEC JTC1/SC7 N2416, Software & System Eng. Secretariat, Canada. – 2001. – 66 p.

13. DTR 9126-2:2001. Software Engineering - Product Quality - Part 2:External Metrics //

ISO/IEC JTC1/SC7 N2419, Software & System Eng. Secretariat, Canada. – 2001. – 111 p.

14. DTR 9126-4:2001. Software Engineering – Software Product Quality - Part 4: Quality In Use

Metrics // ISO/IEC JTC1/SC7 N2430, Soft. & Syst. Eng. Secretariat, Canada. – 2001. – 70 p.

15. ISO/IEC 14598-6:1998. Information Technology - Software product evaluation - Part 6:

Documentation of evaluation modules.

16. Вронский К. Стандарты ISO и управление качеством проектов IT -

http://www.interface.ru/fset.asp?Url=/qad/mfg/isoit.htm

596 Глава 12

17. ISO/IEC TR 15504-1:1998. Information technologies - Software process assessment - Part 1:

Concepts and introductory guide.

18. ISO/IEC TR 15504-3:1998. Information technologies - Software process assessment - Part 3:

Performing an assessment.

19. Paulk M.C. et al. Capability Maturity Model for Software. Version 1.1. Technical Report

CMU/SEI-93-TR-024. - Software Eng.Inst., Pittsburgh, PA 15213, 1993. – 82 p.

20. Paulk M.C. et al. Key Practices of the Capability Maturity Model. Version 1.1. Technical Re-

port CMU/SEI-93-TR-025. - Software Eng.Inst., Pittsburgh, PA 15213, 1993. – 479 p.

21. Masters S., Bothwell C. CMM Appraisal Framework. Version 1.0. Technical Report

CMU/SEI-95-TR-001. - Software Eng. Inst., Pittsburgh, PA 15213, 1995. – 76 p.

22. Bumes P., Phillips M. Software Capability Evaluation (SCE). Version 3.0. Method Descrip-

tion. Technical Report CMU/SEI-96-TR-002. - Software Eng. Inst., Pittsburgh, PA 15213,

1996. – 192 p.

23. Zubrow D. et al. Maturity Questionnaire. Technical Report CMU/SEI-94-SR-007. - Software

Eng. Inst., Pittsburgh, PA 15213, 1994. – 57 p.

24. Whitney R. et al. Interim Profile: Development and Trial of Method to Rapidly Measure Soft-

ware Engineering maturity Status. Technical Report CMU/SEI-94-TR-004. - Software Eng.

Inst., Pittsburgh, PA 15213, 1994. – 44 p.

25. CMMI

for Software Engineering, Version 1.1, Staged Representation (CMMI-SW, V1.1,

Staged) - http://www.sei.cmu.edu/publications/documents/02.reports/02tr029.html

26. CMMI

for Software Engineering, Version 1.1, Continuous Representation (CMMI-SW,

V1.1, Continuous) - http://www.sei.cmu.edu/publications/documents/02.reports/02tr028.html

27. Мильман К., Мильман С. СММI – шаг в будущее // Открытые системы.- 2005.-№5-6 -

http://old.osp.ru/os/2005/05-06/085.htm

28. Липаев В.В. Модели зрелости программной инженерии - CMMI. Содержание и приме-

нение // Jet Info Online.-2006.-N6 - http://www.jetinfo.ru/2006/6/2006.6.pdf

29. ДСТУ 2844-94. Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.

30. ДСТУ ISO 9000:2001

http://www.zstu.zaporizhzhe.ua/base/i2/iff/k3/ukr/welding/guide/iso/

iso9000.htm

31. ДСТУ ISO 9001:2001 - http://www.iso.staratel.com/ISO9000/DOC/DSTUISO9001/

DSTUISO9001.doc

32. ДСТУ ISO 9004:2001 - http://www.iso.staratel.com/ISO9000/DOC/DSTUISO9004/

DSTUISO9004.htm

33. ДСТУ ISO 19011:2003 - http://www.nsu.ru/smk/files/iso_19011/iso_19011.doc

34. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. Серия

«Информационные технологии». М.: СИНТЕГ, 2001. – 380 с.

35. Колдовский В. Разработка ПО: стандарты качества // Компьютерное обозрение.-2005 (9

сентября).- http://itc.ua/article.phtml?ID=21715&IDw=33&pid=52

36. ДСТУ 2462-94. Сертифікація. Основні поняття терміни та визначення.

37.

ДСТУ 3419-96. Система сертифікації УкрСЕПРО. Сертифікація систем якості. Порядок

проведення -http://www.mdoffice.com.ua/pls/MDOffice/MDODOC.FindHelp?p_file=49&p_

page=394&context=

597

ЗАКЛЮЧЕНИЕ

В инженерии качества не так уж все сложно и скучно (а может быть и

грустно). Главное в ней – это здравый смысл, наблюдательность, усидчивость и

немного фантазии. Вот, например, рисунок в стиле авангард, обобщающий наш

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

ресурсов проекта, а за ним – краткое изложение содержания этой книги в

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

Круг качества

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

Пределы роста качества ПС при ее разработке

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

• Проект – это монолитный сплав функций будущей ПС, затрат и сроков

(классический треугольник).

• Проект находится под постоянными угрозами срыва и «окружен» риском

(большой круг риска). Нельзя допускать превышения затрат и сроков (две стороны

треугольника). Нет смысла увеличивать функциональность ПС (система не должна

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

основания треугольника)).

• Объем функциональных возможностей будущей ПС можно «прикинуть»

в самом начале проекта, применив для этого методы измерения в концепции FSM.

• Хорошо бы достичь абсолютного качества ПС и «обеспечить» лучшими

характеристиками каждую «функциональную точку» в основании треугольника.

Получился бы круг качества максимального размера (окружность пунктиром).

Жаль, этого нельзя добиться – такой круг качества частично «выйдет» в области

риска по факторам затрат и продолжительности (черные сегменты).

• Можно бы вообще не заботиться о качестве («стянуть» круг качества в

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

598 Заключение

пригодности ПС (нижний сегмент круга риска). Это риск разработчика (заказчик

откажется от уже «почти» готовой ПС). И это риск заказчика (риск отказа ПС при

эксплуатации).

• Выход – планомерно повышать качество (от центра круга качества в

направлении к его пунктирной границе), постепенно отвоевывая площадь у

нижнего сегмента круга риска. Для этого – построить все необходимые процессы и

начать их применять.

• Вечный вопрос – где остановиться? Нужно расширять круг качества, пока

он не коснется двух сторон треугольника. Можно считать, что оставшиеся не

прикрытыми кусочки нижнего сегмента риска, - это риск отказа ПС, но не по ее

вине.

Если в ряды разработчиков вашего проекта случайно «затесался» научный

сотрудник, да еще и математик – отдайте рисунок ему. А сами займитесь

институциализацией процессов ЖЦ.

Опять скучно? Вспомните слова Лапидуса – «стукните» по любому

сотруднику проекта. Пока он вытянет всю цепочку проблем, у Вас будет время

применить целе-ориентированный и процессо-ориентированный подходы. Ибо это

– элемент обязательной программы для менеджеров, без выполнения которой не

будет ясен внутренний смысл происходящих в проекте процессов (это - как

обучение программированию в DOS современных программистов).

В 2003 журнал IEEE Software опубликовал дискуссионную статью Р.Аустина

и Л.Девина

о проблемах формальной и не формальной разработки ПО.

Примечательно то, что один из авторов статьи (Л.Девин) драматург,

работающий в театральном обществе, а другой (Р.Аустин) – экономист и менеджер,

преподающий в Гарвардской школе бизнеса.

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

методологий. Борются «формалисты» (formalists) – сторонники промышленного

подхода, ставящие во главу угла слово «процесс» и «следование планам», и

«эйжилисты» (agilists), ключевые понятия для которых - «взаимодействие

личностей» и «реагирование на изменения».

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

когда все участники методом проб и ошибок выстраивают роли в спектакле,

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

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

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

Однако четко знать роль «по шагам» все же нужно.

Надеемся, что эту точку зрения специалистов вы разделите (вместе с нами).

Всяческих успехов.

Rob Austin, Lee Devin “Beyond Requirements: Software Making as Art”, IEEE Software,

Jan/febr, 2003

599

Приложение 1. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

В приложении приведен краткий обзор основных моделей жизненного цикла

программных систем (ПС).

Жизненный цикл ПС определяется как «…весь период существования систе-

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

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

•

Определение потребностей.

•

Анализ требований и формирование концепции.

•

Разработка (далее рассматривается подробнее).

•

Производство.

•

Внедрение/продажа.

•

Эксплуатация.

•

Сопровождение и поддержка.

•

Изъятие из эксплуатации.

Внутри каждой из этих стадий происходит дальнейшая детализация выпол-

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

Модели ЖЦ описывают взаимосвязи стадий.

Рассмотренные в данном приложении модели касаются стадий ЖЦ, связан-

ных с процессом разработки ПС, основные из которых:

•

Анализ требований.

•

Проектирование (предварительное и детальное).

•

Реализация.

•

Тестирование.

Наиболее известными типами моделей ЖЦ в настоящее время являются: по-

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

образуя смешанные модели ЖЦ.

Каждая из моделей имеет свои достоинства и недостатки, которые должны

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

1.1. Назначение моделей разработки

Модели ЖЦ могут использоваться для:

• организации, планирования, распределения ресурсов (трудозатрат и вре-

мени) и управления проектом разработки;

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

ментов (рабочих продуктов), разрабатываемых на каждой стадии;

• анализа и/или оценивания распределения ресурсов и затрат на протяже-

нии ЖЦ;

• наглядного описания или в качестве основы для проведения финансовых

расчетов с заказчиками;

• проведения эмпирических исследований с целью определения влияния

моделей на эффективность разработки и общее качество программного продукта.

В стандарте ISO/IEC 12207 определена структура процессов, но не указаны

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

ДСТУ 2941-94. Разработка систем. Термины и определения.

600 Приложение 1

ному отображению процессов ЖЦ на основные модели разработки приведены в

Руководстве по применению стандарта

1.2. Модели последовательного выполнения стадий

1.2.1. Каскадная модель

Каскадная (Waterflall) или стандартная модель - наиболее известная модель

разработки, по умолчанию предполагаемая стандартами (в частности, ГОСТ 34).

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

нок 1.1). Каждая стадия должна быть завершена до перехода к следующей, а созда-

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

«заморожены» и переданы на следующую стадию в качестве эталона. Пользователь

видит работающий программный продукт в самом конце разработки. Наиболее же-

сткое ограничение этой модели - необходимость «замораживания» требований. При

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

большие изменения.

Анализ

требований

Проектирование

Реализация

Тестирование

Рис. 1.1. Каскадная модель

С точки зрения качества ПС, в этой модели стоимость исправления дефектов

на стадии тестирования наибольшая (по сравнению с другими моделями), посколь-

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

на переделки и тестирование существует значительный риск выпуска ПС с серьез-

ными дефектами.

1.2.2. Каскадная модель с обратной связью

Эта модель расширяет стандартную модель включением в нее циклов обрат-

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

(конструкции) и по результатам инспекций или действий по V&V (рисунок 1.2).

Анализ

требований

Проектирование

Реализация

Тестирование

Рис. 1.2. Каскадная модель с обратной связью

Процессы V&V, выполняемые после завершения каждой стадии разработки,

играют в этой модели важнейшую роль.

Guide for ISO/IEC 12207 (Software Life Cycle Processes) // ISO/IEC JTC1/SC7 N1656

1997-02-01.

Приложение 1 601

В таблице 1.1. подытожены характеристики каскадных моделей и преимуще-

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

Таблица 1.1. Характеристики каскадной модели

Характеристики Преимущества

Последовательное упорядочение стадий Применение формальных проверок по-

зволяет своевременно выявить дефекты

Формальные проверки по завершении каж-

дой стадии (инспекции, технические обзоры)

Четкие критерии начала и завершения

стадий

Наличие документированных требований и

проекта

Четкие требования и цели проекта

1.2.3. V-образная модель

V-образная (V-shape) модель расширяет каскадную модель включением в нее

действий по раннему планированию тестирования. Структура и описание этой мо-

дели приведены в главе 7. Характеристики и преимущества модели перечислены в

таблице 1.2.

Таблица 1.2. Характеристики V-образной модели

Характеристики Преимущества

Проверка и оценка тестопригодности требова-

ний на ранних стадиях разработки (посредст-

вом анализа, выполняемого при планировании

тестирования)

Обеспечивает обратную связь с поль-

зователем на ранних стадиях ЖЦ

Наличие документированных тестовых требо-

ваний

Улучшает планирование и распреде-

ление затрат на тестирование

Четкие документированные цели тес-

тирования

1.2.4. Каскадная модель с прототипированием (пилообразная модель)

Модель является модификацией V-образной модели с включением в нее про-

тотипирования для моделирования требований и проекта (рисунок 1.3).

Анализ

требований

Проектирование

системы

Проектирование

ПО

Интеграционное

тестирование

Автономное

тестирование

Реализация

Приемочное

тестирование

Демонстрационный

прототип 1

Демонстрационный

прототип 2

Рис. 1.3. Последовательная модель с прототипированием

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

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

преимущества этой модели, перечислены в таблице 1.3.