Модель (методология) Преимущества Недостатки - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Модель качества программных средств 1 99.15kb.
Уроки icc: «Интенсивный курс подготовки к экзамену cdcs» ОАО «Газпромбанк» 1 22.99kb.
Домашнее задание№1. Разбор этического кодекса поведения 1 112.26kb.
«социс». 2011.№5. С. 10-18. Перформанс этнометодологический потенциал... 1 223.67kb.
Джеймс А. Холл Юнгианское толкование сновидений 15 1635.51kb.
Интеллектуальный поиск Новиков Роман 1 140.98kb.
Моу знаменская сош № Минусинского района Красноярского края 1 70.8kb.
«Международная экономика». 2010.№3. С. 43-46. Региональная торговля... 1 113.22kb.
Семинар Биоэтика Педиатрический факультет 1 87.55kb.
Вопросы по курсу «Теория и методология культуры» 1 30.7kb.
Численные методы в теории приближений. Лекция 1 Структура погрешности... 1 65.3kb.
Методология Rational Unified Process (rup) 1 117.78kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

Модель (методология) Преимущества Недостатки - страница №1/1

Методологии разработки ПО





Модель (методология)

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

Недостатки

1

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

Переход от одной фазы к другой предполагает полное завершение предыдущего этапа.

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

2

Спиральная модель - состоит из фаз-спиралей, на каждой из которых выполняются этапы,характерные для каскадной модели жизненного цикла

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

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

3

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

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




4

Гибкая разработка — собственно итеративная разработка с длиной итерации до 2 недель (как правило)

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

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


Виды деятельности в разработке ПО




Название

Роль исполнителя

Автоматизируется ли?

Средства автоматизации

Пример

1

Сбор и выявление бизнес-требований пользователей

Бизнес - аналитик

нет







2

Анализ бизнес-процессов

Бизнес - аналитик

да

Пункт 6




3

Составление концепции

Бизнес - аналитик

нет







4

Сбор и выявление требований пользователей к ПО

Системный аналитик

нет







5

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

Системный аналитик

да







6

Проектирование архитектуры

Архитектор приложения

да

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

DFD, IDEF, UML
MagicDraw, Enterprise Architect, Microsoft Visio, Rational Rose, Visual Paradigm for UML, Rhapsody Modeler

7

Проектирование ПО и информационной системы

Проектировщик ПО

да

8

Написание кода

Программист

да

Интегрированные среды разработки (IDE`)

Visual Studio, NetBeans, Eclipse, ZendStudio, Kdevelop, MonoDevelop, Aptana, Delphi

9

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

Тестировщик

да

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

Xunit, Selenium, Hudson, Bamboo, CruiseControl

10

Документирование

Технический писатель

да

Документирование кода,
Технологии документирования

JavaDoc, phpDoc, PLSQLDoc,

DITA, DocBook



11

Внедрение

Системный администратор

нет







12

Техническая поддержка и сопровождение

Специалист технической поддержки

нет









Верификация программных требований к ПО.

Инструменты автоматизации этапа.

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

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



Р
ис. 1.
Процессы и документы при разработке программных систем

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

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

В состав задач процесса верификации входит последовательная проверка того, что в программной системе:



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

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

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

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

  5. исходные тексты программ и соответствующий им исполняемый код не содержат ошибок.

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

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


Тестирование, верификация и валидация (сравнение понятий)


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

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

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

Р
ис. 2.
Тестирование, верификация и валидация

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


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

Перед началом верификации менеджером тестирования (test manager) создается документ, называемый планом верификации (или планом тестирования, но это не то же самое, что тест-план).



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

Для каждого этапа определяется:



  1. типы входных и выходных документов;

  2. общая процедура верификации;

  3. роли и ответственности;

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

  5. критерии оценки результативности этапа.

Иногда план верификации разделяется на отдельные документы, описывающие более подробно каждый из этапов, например:

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

  2. план верификации архитектуры;

  3. план тестирования программного кода;

  4. план тестирования модулей и их интеграции;

  5. план системного тестирования;

  6. план нагрузочного тестирования;

  7. план полунатурных испытаний;

  8. план приемо-сдаточных испытаний.

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

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

Согласно этим требованиям по системным и функциональным требованиям разработчиками тестов (test procedure developers) создаются тест-требования - документы, в которых подробно описано то, какие аспекты поведения системы должны быть протестированы. На основании описания архитектуры создаются низкоуровневые тест-требования, где описываются аспекты поведения конкретной программной реализации системы, которые необходимо протестировать.




Рис. 3. Документация, сопровождающая процесс верификации


На основании тест-требований разработчиками тестов (test developers) создаются тест-планы - документы, которые содержат подробное пошаговое описание того, как должны быть протестированы тест-требования.

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

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

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

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



Формальные инспекции

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

Такие экспертные исследования обычно называют инспекциями или просмотрами. Существует два типа инспекций - неформальные и формальные.

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

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

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

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

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

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

Уровни процесса верификации


Как уже было сказано ранее, процесс верификации активен в течение практически всего жизненного цикла системы и работает параллельно с процессом разработки.

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



  1. системное тестирование, в ходе которого тестируется система в целом;

  2. интеграционное тестирование, в ходе которого тестируются группы взаимодействующих модулей и компонент системы;

  3. модульное тестирование, в ходе которого тестируются отдельные компоненты.

Способы автоматизации процесса верификации

1. Системное тестирование.

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

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

Можно выделить два подхода к системному тестированию:


1) на базе требований (requirements based)
2) на базе случаев использования (use case based)

2. Интеграционное тестирование.

Интеграционное тестирование — фаза тестирования, при котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного и до системного.

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

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

Автоматизация интеграционного тестирования осуществляется средствами систем непрерывной интеграции. Функции систем непрерывной интеграции (CIS):


  1. CIS производит мониторинг системы контроля версий;

  2. При изменении исходных кодов в репозитории производится обновление локального хранилища;

  3. Выполняются необходимые проверки и модульные тесты;

  4. Исходные коды компилируются в готовые выполняемые модули;

  5. В
    ыполняются тесты интеграционного уровня;

  6. Генерируется отчет о тестировании.




Рис. 3. Вариант реализации непрерывной интеграции

Назначение элементов схемы (рис. 3):



  1. рабочая машина программиста — написание кода,

  2. сервер SVN — хранение кода,

  3. сервер Staging — установка и тестирование собранных проектов,

  4. сервер Selenium — тестирование web-интерфейса,

  5. сервер Repo — хранение собранных пакетов,

  6. сервер CI — соединение всех узлов системы в единое целое.

3. Модульное тестирование.

Модульное тестирование (unit-тестирование)— процесс разработки, позволяющий проверить на корректность отдельные модули системы.

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

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

Примеры инструментов





Название

Технологии

Операционые системы

Язык тестов

Тестируемые приложений

Вид тестирования

1

Selenium

DHTML, JS, AJAX

MacOS, MS Windows, Linux, Solaris

HTML, Java, C#, Perl, PHP, Python, Ruby

веб-приложения

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

2

Testing Anywhere

VB.NET, C#, C++, Win32, VB6, AJAX, ActiveX, JavaScript, HTML, Delphi, Java, Perl, 32 bit apps, 64 bit apps, Oracle Forms, PHP, Python, Macromedia Flash 1.0-8.0, Adobe Flash 9.0 & later

MS Windows

визуальное проектирование

веб- приложения, windows приложения

Универсальный инструмент

3

PHPUnit (+много аналогичных инструментов для других языков — Ruby, C#, Perl, Python, Java и т.д)

PHP

MacOS, MS Windows, Linux, Solaris

PHP

веб-приложения

модульное тестирование

4

Watin

.NET, HTML, JavaScript

MS Windows

C# и др. языки, NET

веб-приложения

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

5

Watit

HTML, JavaScript

MS Windows, Linux, Mac OS

Ruby, Java, .NET, Perl

веб-приложени

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

6

TOSCA TestSuite

HTML, Java, .NET

MS Windows

VB6, Java, C#

Бизнес-приложения (CRM, SAP)

Универсальный инструмент

7

Hudson

CVS, Subversion, Mercurial, GIT, Apache Tomcat, GlassFish, Apache Ant, Apache Maven, Java, PHP

Linux




Универсальный инструмент, но чаще веб-приложения

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


Пример использования: PHPUnit и Selenium картинками на слайдах (создание, запуск, отчет, покрытие кода).