Жизненный цикл программного обеспечения

Основными этапами жизненного цикла программного обеспечения являются:

□ определение требований и разработка спецификаций;

□ проектирование;

□ кодирование;

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

□ внедрение и сопровождение.

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

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

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

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

Рис. 19.10. Модель водопада Рис. 19.11. Итерационная модель

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

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

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

Лица у которых собираются требования:

□ заказчик (инвестор);

□ руководитель подразделения, в котором будет внедряться создаваемая про­грамма;

□ потенциальные пользователи программы;

□ исполнители программного проекта;

□ потенциальные пользователи результатов работы программы;

□ консультанты.

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

□ выработать соглашение о наличии проблемы;

□ выделить основные причины возникновения проблемы;

□ выявить заинтересованных лиц и пользователей;

□ определить границы системы решений;

□ выявить ограничения, которые необходимо наложить на решение.

Несмотря на то, что требования формируются до начала программного про­екта, нужно помнить, что они будут сопровождать работу на каждом этапе раз­работки ПО. Поэтому требования должны строго документироваться. Лучше всего использовать для этого специальное программное обеспечение управления требованиями, например, Borland CaliberRM. Эта программа позволяет не только документировать требования, но и декомпозировать их до конкретных специфи­каций и метрик, а также вывести граф метрик, показывающий сбалансированность собранных требований. Кроме того, Borland CaliberRM поддерживает режим кол­лективной работы над требованиями на протяжении всего жизненного цикла ПО (рис. 19.13).

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

Fte -Vieiv-.'Insert Format: Requifemerit:.

■.; Р2 Order Processing

Itr ф I, Business Requirements (WHY) B 2, User Requirements (USER) I Ш- ^ Customer places order ; Ш- ф Customer cancels order ; ' --ф Time to ship order •• Ш- ф Customer changes order B |2 3, Functional Requirements (WHAT)

. ф Query Order Status . - -ф Generate Invoice ^; .- ф Modify Orders ^j _: ^ Book Training Courses

:'S ф Order Fulfillment EbtШ Design Requirements (DSGN) ; ^ Handle 10 Orders Per Hour ' Ш -ф- Supported Platforms ' ffi ф Security lii'-ф 5, Project Tasks (WBS) 6. Test Scenarios (TEST)

ешвг$. ^ejrsfM;;^: -

? WHA: ! ■ ;

PfWty:'^:

The system must be able to enter new customer orders. Orders can consist of multiple order items, arid each order item must specify a quantity of an available product, a scheduled delivery of an on-site training course, or a purchase of a periodic software support Iceiise

Рис. 19.13. Borland CaIiberRM

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

Работу по проектированию при объектно-ориентированном подходе выполняет системный архитектор средствами языка UML. Задачи проектирования вклю­чают в себя две составляющие: разработку физической и логической структур. Логическое проектирование заключается в разработке классов для реализации

их экземпляров — объектов. Для этого требуется подробное описание полей и методов классов, а также связей между ними. Статические диаграммы классов и пакетов являются основными в UML-проектировании, поскольку именно они обеспечивают генерацию шаблонов исходного кода для следующего этапа, коди­рования. Динамические диаграммы предназначены для более полного понимания программистом логики функционирования системы и взаимоотношения классов. Для проектирования физической структуры, предназначены UML-диаграммы компонентов развертывания. Эти диаграммы описывают физическое размещение компонентов системы на аппаратном обеспечении заказчика.

Для повышения эффективности этапа проектирования нужно, чтобы про­граммный пакет создания архитектуры был совместим со средством разработки кода. Если в качестве среды разработки выбрана Delphi, то системный архитектор может использовать пакет Together производства Borland, полностью совместимый с этой средой (рис. 19.14).

19.5.3. Кодирование и тестирование

Разработка исходного кода ведется в интегрированной среде быстрой раз­работки, такой как Delphi или Microsoft Visual Studio, на основе полученных от системного архитектора UML-диаграмм и автоматически сгенерированного по этим диаграммам шаблонам исходного кода.

Тестирование программного обеспечения — это та ступень разработки ПО, на которую в последнее время обращается все более пристальное внимание. Этап те-

стирования, если он организован недостаточно хорошо, может вызывать затраты, равные половине всех затрат на создание ПО.

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

Тестирование подразделяется на три стадии: автономное, комплексное и си­стемное.

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

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

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

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

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

□ каждая ветвь в программе должна быть испытана хоть один раз с использова­нием набора тестовых данных.

^[1] Существуют и другие нормальные формы с более строгими условиями.

^[2] IrDA (Infrared Data Association — ассоциация разработчиков систем передачи данных) — стан­дарт на беспроводную передачу данных в инфракрасном (ИК) диапазоне частот. Wi-Fi (Wireless Fidelity — беспроводная точность, произносится как «вай-фай») и BlueTooth (в переводе с англ. — «синий зуб», произносится как «Блю Туз») являются стандартами (спецификациями) для сетей беспроводной передачи данных.

[3] Интегральная память (ИС) — электронная схема, изготовленная на полупроводниковом кристалле и помещенная а неразборный корпус. Сверхбольшая ИС (ИБИС) содержит до 1 миллиона элементов в кристалле.

^[4] Кроме блок-схем алгоритмов, для тех же целей представления алгоритмов, программ или иных видов деятельности, в том числе и на этапе проектирования систем, могут использоваться и дру­гие виды графической нотации. Среди них заметное место в современных методиках разработки занимает диаграмма деятельности (Activity diagram), являющаяся частью унифицированного языка моделирования UML.

^[5] Приведенная классификация не является единственной.

Рис. 14.21. Вставка элемента в начало списка

также пригодных к обработке на компьютере: в виде матриц инцидентности или матриц смежно­сти, а также других структур для представления «веса» и «цвета» связей, пометок вершин и т. д.

^[8] Достаточно широко в качестве операционных систем серверов применяются различные ОС семейства BSD (например, FreeBSD).

[9] а г

ju ^ о

[10] Ctftfe Вйх ; i-Ы

|жйга1йзг ^: Sfefer '

Bar ' :■',-Fofmatteij FfeW, rj» x:

Temt-

Рис. 19.9. NetBeans

[11] Order Processing