Файл: Модели разработки.pdf

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

Структурированные методы проектирования были разработаны в 1970-х и 1980-х годах и были предшественниками UML и объектно-ориентированного проектирования^[8]. Они полагаются на создание графических моделей системы и, во многих случаях, на автоматическую генерацию кода из этих моделей. Модельно-ориентированная разработка (MDD) или модельно-ориентированная разработка^[9], где модели программного обеспечения создаются на разных уровнях абстракции, является эволюцией структурированных методов. В MDD больше внимания уделяется архитектурным моделям с разделением между абстрактными независимыми от реализации моделями и моделями, специфичными для реализации. Модели разработаны достаточно подробно, чтобы из них можно было создать исполняемую систему

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

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

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

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

2.3. Валидация

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

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

Процесс тестирования состоит из следующих этапов:

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

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

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

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

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

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

2.4. Эволюция, или дальнейшее развитие

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

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

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

Для уменьшения дополнительных затрат на внесение изменений, используются два взаимосвязанных подхода:

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

Здесь мы кратко рассмотрим рассмотрим следующие два подхода уменьшения стоимости внесения масштабных изменений в программный проект:

1. Прототипирование системы^[10] - это быстрая разработка демонстрационной версии системы или ее части, предназначенной для проверки требований заказчика и осуществимость некоторых проектных решений. Заказчик экспериментирует с прототипом, и при необходимости вносит изменения в требования к системе. Таким образом, мы избегаем значительных изменений в будущем, поскольку требования меняются до начала масштабных работ по разработке программы.
2. Поэтапная доставка - процесс поэтапной разработки, когда каждая новая итерация, или версия программы, доставляется заказчику на тестирование, после чего заказчик, при необходимости, вносит изменения в ту или иную часть системных требований. Это позволяет избежать преждевременной реализации системных требований и позволяет вносить изменения в последующих итерациях при относительно низких затратах.

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

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

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

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

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