Разработка программного обеспечения

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

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

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

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

Разработка программного обеспечения включает в себя анализ, проектирование, реализацию и тестирование программы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск по сайту: