Создание программного обеспечения

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

• 1 Основы построения программного обеспечения
  • 1.1 Минимизация сложность
  • 1.2 Прогнозирование изменений
  • 1.3 Строительство для проверки
  • 1.4 Повторное использование
  • 1.5 Стандарты в строительстве
• 2 Управление строительством
  • 2.1 Модель строительства
  • 2.2 Планирование строительства
  • 2.3 Измерение строительства
• 3 Практические соображения
  • 3.1 Проектирование конструкции
  • 3.2 Языки конструкции
  • 3.3 Кодирование
  • 3.4 Тестирование конструкции
  • 3.5 Повторное использование
  • 3.6 Качество строительства
  • 3.7 Интеграция
• 4 Строительство технологии
  • 4.1 Объектно-ориентированные проблемы времени выполнения
  • 4.2 Утверждения, проектирование по контракту и защитное программирование
  • 4.3 Обработка ошибок, обработка исключений и отказоустойчивость
  • 4.4 Построение на основе состояний и таблиц методы
  • 4.5 Конфигурация среды выполнения и интернационализация
• 5 См. также
• 6 Примечания
• 7 Ссылки
• 8 Внешние ссылки

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

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

Предвидение изменений

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

Создание для проверки

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

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

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

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

Стандарты в разработке

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

• Методы коммуникации: такие как стандарты для форматов и содержимого документов.
• Языки программирования
• Стандарты кодирования
• Платформы
• Инструменты: например, схематические стандарты для обозначений, таких как UML.

Модель построения

Многочисленные модели были созданы для разработки программного обеспечения, некоторые из которых делают упор на конструирование больше, чем другие. Некоторые модели более линейны с точки зрения построения, например, Waterfall и модели жизненного цикла поэтапной доставки. Эти модели рассматривают строительство как деятельность, которая происходит только после выполнения значительных предварительных работ, включая подробные требования работы, обширные проектные работы и подробные планирование. Другие модели более итеративные, такие как эволюционное прототипирование, Extreme Programming и Scrum. Эти подходы обычно рассматривают строительство как деятельность, которая происходит одновременно с другими разработкой программного обеспечения, включая требования, проектирование и планирование, или перекрывает их.

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

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

Измерение строительства

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

Создание программного обеспечения определяется многими практическими соображениями :

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

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

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

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

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

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

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

Кодирование

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

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

Тестирование конструкции

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

• Модульное тестирование
• Интеграционное тестирование

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

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

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

Строительство качество

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

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

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

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

Интеграция

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

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

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

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

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

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

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

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

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

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

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

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

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

• Руководство по своду знаний по программной инженерии - версия 2004 г., подготовленное IEEE Computer Society
• Руководство по своду знаний по программной инженерии, версия 3.0, IEEE Computer Society, 2014