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

Не путать с Разработка программного обеспечения.
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Основы построения программного обеспечения

Минимизация сложности

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

Ожидание перемен

Предвидение изменений помогает разработчикам программного обеспечения создавать расширяемое программное обеспечение, что означает, что они могут улучшать программный продукт без нарушения базовой структуры.[2] Исследования, проведенные за 25 лет, показали, что стоимость доработки может быть в 10-100 раз (в 5-10 раз для небольших проектов) дороже, чем выполнение требований с первого раза. Учитывая, что 25% требований меняются во время разработки в среднем проекте, необходимость снижения затрат на доработку проясняет необходимость предвидения изменений. [3]

Конструирование для проверки

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

Повторное использование

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

  • Конструкция для повторного использования: создание повторно используемых программных активов.
  • Построение с повторным использованием. Повторное использование программных активов при построении нового решения.

Стандарты в строительстве

Стандарты, внешние (созданные международными организациями) или внутренние (созданные на корпоративном уровне), которые напрямую влияют на вопросы строительства, включают:[2]

Управление строительством

Модель конструкции

Многочисленные модели были созданы для развития программного обеспечения, некоторые из которых делают упор на строительство больше, чем другие. Немного модели более линейны с точки зрения конструкции, например Водопад и модели жизненного цикла поэтапной доставки. Эти модели рассматривать строительство как деятельность, которая происходит только после выполнения значительных предварительных работ, включая подробные требования работа, обширная дизайн работа, и подробно планирование. Остальные модели больше итеративный, Такие как эволюционное прототипирование, Экстремальное программирование, и Scrum. Эти подходы склонны рассматривать строительство как деятельность, которая происходит одновременно с другими разработка программного обеспечения мероприятия, в том числе требования, дизайн, и планирование, или перекрывает их.[1]

Планирование строительства

Выбор конструкции метод является ключевым аспектом деятельности по планированию строительства. Выбор конструкции метод влияет на степень, в которой предпосылки строительства (например, Анализ требований, Разработка программного обеспечения, ... и т. д.), порядок, в котором они выполняются, и степень, в которой они должны быть выполнены до начала строительных работ. Планирование строительства также определяет порядок, в котором составные части созданы и интегрированы, управление качеством программного обеспечения процессы, распределение задач по конкретным программисты, и другие задачи, согласно выбранному метод.[1]

Строительные измерения

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

Практические соображения

Конструирование программного обеспечения определяется многими практическими соображениями:

Строительный дизайн

Чтобы учесть непредвиденные пробелы в разработка программного обеспечения, во время разработки программного обеспечения необходимо внести некоторые изменения в дизайн в меньшем или большем масштабе, чтобы конкретизировать детали разработка программного обеспечения.[4]

Низкий Разветвление одна из конструктивных характеристик, признанных исследователями полезными. Скрытие информации оказалось полезным методом проектирования в больших программах, который упростил их изменение в 4 раза. [5]

Строительные языки

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

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

Программисты, работающие на языке, который они использовали в течение трех или более лет, примерно на 30 процентов более продуктивны, чем программисты с аналогичным опытом, которые плохо знакомы с языком. Языки высокого уровня, такие как C ++, Java, Smalltalk и Visual Basic, обеспечивают от 5 до 15 раз большую производительность, надежность, простоту и понятность, чем языки низкого уровня, такие как ассемблер и C. Было показано, что эквивалентному коду требуется меньше строк для быть реализовано на языках высокого уровня, чем на языках более низкого уровня.[7]

Кодирование

Основная статья: Компьютерное программирование

Следующие соображения относятся к деятельности по кодированию построения программного обеспечения:[8]

  • Приемы создания понятных исходный код, включая именование и макет исходного кода. Одно исследование показало, что усилия, необходимые для отладки программы, сводятся к минимуму, когда имена переменных содержат от 10 до 16 символов.[9]
  • Использование классы, перечислимые типы, переменные, названный константы, и другие подобные объекты:
    • Исследование, проведенное НАСА, показало, что размещение кода в хорошо продуманных классах может удвоить код. возможность повторного использования по сравнению с кодом, разработанным с использованием функционального дизайна.[10][11]
    • Один эксперимент показал, что схемы, которые обращаются к массивам последовательно, а не случайным образом, приводят к меньшему количеству переменных и меньшему количеству ссылок на переменные.[12]
  • Использование управляющих структур:
    • Один эксперимент показал, что циклы с выходом более понятны, чем другие виды циклов.[13]
    • Что касается уровня вложенности в циклы и условия, исследования показали, что программистам трудно понять более трех уровней вложенности.[13][14]
    • Было показано, что сложность потока управления коррелирует с низкой надежностью и частыми ошибками.[14]
  • Обработка состояний ошибок - как запланированных ошибок, так и исключения (например, ввод неверных данных)
  • Предотвращение нарушений безопасности на уровне кода (переполнение буфера или индекс массива переполнение, например)
  • Ресурс использование за счет использования механизмов исключения и дисциплины при доступе к последовательно используемым Ресурсы (включая потоки или блокировки базы данных )
  • Исходный код организация (в заявления и распорядки ):[11]
    • Высоко сплоченный подпрограммы оказались менее подверженными ошибкам, чем подпрограммы с меньшей связностью. Изучение 450 процедур показало, что 50 процентов процедур с высокой степенью согласованности были безошибочными по сравнению с только 18 процентами процедур с низкой связностью. Другое исследование 450 различных программ показало, что программы с наибольшим связь Отношения сцепления и сцепления имели в 7 раз больше ошибок, чем те, которые имели самые низкие коэффициенты сцепления и сцепления, и их исправление было в 20 раз дороже.
    • Хотя исследования показали неубедительные результаты относительно корреляции между размерами рутин и количеством ошибок в них, одно исследование показало, что исправлять подпрограммы с менее чем 143 строками кода в 2,4 раза дешевле, чем более крупные подпрограммы. Другое исследование показало, что код нужно менять меньше всего, когда подпрограммы содержат в среднем от 100 до 150 строк кода. Другое исследование показало, что структурная сложность и количество данных в рутине коррелировали с ошибками независимо от их размера.
    • Интерфейсы между подпрограммами - одни из наиболее подверженных ошибкам областей программы. Одно исследование показало, что 39 процентов всех ошибок были ошибками при обмене данными между процедурами.
    • Неиспользуемые параметры коррелируют с повышенным уровнем ошибок. В одном исследовании только от 17 до 29 процентов процедур с более чем одной переменной, на которую не ссылались, не имели ошибок, по сравнению с 46 процентами в процедурах без неиспользуемых переменных.
    • Количество параметров рутины должно быть максимум 7, поскольку исследования показали, что люди, как правило, не могут отслеживать более семи блоков информации одновременно.
  • Исходный код организация (в классы, пакеты, или другие конструкции). При рассмотрении сдерживание, максимальное количество элементов данных в классе не должно превышать 7 ± 2. Исследования показали, что это число представляет собой количество отдельных элементов, которые человек может запомнить при выполнении других задач. При рассмотрении наследование, количество уровней в дереве наследования должно быть ограничено. Было обнаружено, что деревья глубокого наследования в значительной степени связаны с увеличением количества отказов. При рассмотрении количества процедур в классе оно должно быть как можно меньшим. Исследование программ на C ++ обнаружило связь между количеством подпрограмм и количеством ошибок.[10]
  • Документация по коду
  • Настройка кода

Строительные испытания

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

Повторное использование

Реализация повторное использование программного обеспечения влечет за собой больше, чем создание и использование библиотеки активов. Это требует формализации практики повторное использование путем интеграции процессов и действий повторного использования в жизненный цикл программного обеспечения. Задачи, связанные с повторным использованием при построении ПО при кодирование и тестирование находятся:[1]

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

Качество строительства

Основные методы, используемые для обеспечения качества код как он построен, включает:[15]

  • Модульное тестирование и интеграционное тестирование. Одно исследование показало, что средний уровень обнаружения дефектов при модульном тестировании и интеграционном тестировании составляет 30% и 35% соответственно.[16]
  • Тестовая разработка
  • Использование утверждения и защитное программирование
  • Отладка
  • Инспекции. Одно исследование показало, что средний уровень обнаружения дефектов при проверке официального кода составляет 60%. Что касается стоимости обнаружения дефектов, исследование показало, что чтение кода выявляет на 80% больше ошибок в час, чем тестирование. Другое исследование показало, что обнаружение дефектов конструкции с помощью тестирования обходится в шесть раз дороже, чем с помощью проверок. Исследование, проведенное IBM, показало, что на обнаружение дефекта путем проверки кода потребовалось всего 3,5 часа по сравнению с 15–25 часами при тестировании. Корпорация Майкрософт обнаружила, что для поиска и исправления дефекта с помощью проверок кода требуется 3 часа, а с помощью тестирования - 12 часов. Сообщалось, что в программе на 700 тысяч строк проверка кода была в несколько раз более рентабельной, чем тестирование.[16] Исследования показали, что проверки приводят к уменьшению количества дефектов на 20-30% на 1000 строк кода, чем менее формальные методы проверки, и что они повышают производительность примерно на 20%. Официальные проверки обычно занимают 10-15% бюджета проекта и снижают общую стоимость проекта. Исследователи обнаружили, что наличие более 2–3 рецензентов на формальной проверке не увеличивает количество обнаруженных дефектов, хотя результаты, похоже, различаются в зависимости от типа проверяемого материала.[17]
  • Технические обзоры. Одно исследование показало, что средний уровень обнаружения дефектов неофициальных обзоры кода и проверка стола составляют 25% и 40% соответственно.[16] Прохождение Было установлено, что уровень обнаружения дефектов составляет 20% - 40%, но было также установлено, что это дорого, особенно при увеличении проектного давления. НАСА обнаружило, что чтение кода выявляет 3,3 дефекта в час усилий по сравнению с 1,8 дефекта в час при тестировании. Он также обнаруживает на 20–60% больше ошибок за время существования проекта, чем различные виды тестирования. Изучение 13 обзоров встреч по обзору показало, что 90% дефектов были обнаружены при подготовке к совещанию по обзору, в то время как только около 10% были обнаружены во время встречи.[17]
  • Статический анализ (IEEE1028)

Исследования показали, что для достижения высокой скорости обнаружения дефектов необходимо использовать комбинацию этих методов. Другие исследования показали, что разные люди склонны находить разные дефекты. Одно исследование показало, что Экстремальное программирование практика парное программирование, проверка стола, модульное тестирование, интеграционное тестирование, и регрессионное тестирование может достичь 90% -ного уровня обнаружения дефектов.[16] Эксперимент с участием опытных программистов показал, что в среднем они могут найти 5 ошибок (в лучшем случае 9) из 15 ошибок путем тестирования.[18]

80% ошибок обычно сосредоточены в 20% классов и процедур проекта. 50% ошибок обнаруживаются в 5% классов проекта. IBM смогла сократить количество дефектов, сообщаемых заказчиком, в десять раз и сократить их бюджет на обслуживание на 45% в своей системе IMS, отремонтировав или переписав только 31 класс из 425. Около 20% рутинных операций проекта составляют 80% затрат на разработку. Классическое исследование IBM показало, что несколько подпрограмм OS / 360, подверженных ошибкам, были самыми дорогими. У них было около 50 дефектов на 1000 строк кода, и их исправление обходилось в 10 раз дороже, чем разработка всей системы.[18]

Интеграция

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

Строительные технологии

Проблемы с объектно-ориентированной средой выполнения

Объектно-ориентированные языки поддерживают ряд механизмов времени выполнения, которые повышают гибкость и адаптируемость программ, например абстракция данных, инкапсуляция, модульность, наследование, полиморфизм, и отражение.[19][20]

Абстракция данных - это процесс, с помощью которого данные и программы определяются в представлении, аналогичном по форме их значению, но при этом скрывая детали реализации.[21] Академические исследования показали, что абстракция данных делает программы примерно на 30% легче для понимания, чем функциональные программы.[10]

Утверждения, дизайн по контракту и защитное программирование

Утверждения - это исполняемые предикаты, которые помещаются в программу, что позволяет выполнять проверки программы.[19] Дизайн по контракту - это подход к разработке, в котором предусловия и постусловия включаются для каждой процедуры. Защитное программирование это процедура защиты от взлома неверными входами.[22]

Обработка ошибок, обработка исключений и отказоустойчивость

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

Методы построения на основе состояний и таблиц

Программирование на основе состояний - это технология программирования, использующая конечные автоматы для описания поведения программ.[22] Табличный метод - это схема, которая использует таблицы для поиска информации, а не логические операторы (такие как if и case).[24]

Конфигурация среды выполнения и интернационализация

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

Смотрите также

Примечания

  1. ^ а б c d е ж г SWEBOK Пьер Бурк; Роберт Дюпюи; Ален Абран; Джеймс В. Мур, ред. (2004). «Глава 4: Построение программного обеспечения». Руководство к своду знаний по программной инженерии. IEEE Computer Society. С. 4–1–4–5. ISBN  0-7695-2330-7.
  2. ^ а б c d е SWEBOK 2014, п. 3-3.
  3. ^ МакКоннелл 2004, Глава 3.
  4. ^ SWEBOK 2014, п. 3-5.
  5. ^ МакКоннелл 2004, Глава 5.
  6. ^ SWEBOK 2014, п. 3-5 - 3-6.
  7. ^ МакКоннелл 2004, Глава 4.
  8. ^ SWEBOK 2014, п. 3-6.
  9. ^ МакКоннелл 2004, Глава 11.
  10. ^ а б c МакКоннелл 2004, Глава 6.
  11. ^ а б МакКоннелл 2004, Глава 7.
  12. ^ МакКоннелл 2004, Глава 12.
  13. ^ а б МакКоннелл 2004, Глава 16.
  14. ^ а б МакКоннелл 2004, Глава 19.
  15. ^ SWEBOK 2014, п. 3-7.
  16. ^ а б c d МакКоннелл 2004, Глава 20.
  17. ^ а б МакКоннелл 2004, Глава 21.
  18. ^ а б МакКоннелл 2004, Глава 22.
  19. ^ а б SWEBOK 2014, п. 3-8.
  20. ^ Тайер 2013 С. 140 - 141.
  21. ^ Тайер 2013, п. 140.
  22. ^ а б c SWEBOK 2014, п. 3-9.
  23. ^ Тайер 2013, п. 142.
  24. ^ а б SWEBOK 2014, п. 3-10.

Рекомендации

внешняя ссылка