Создание программного обеспечения
| Часть серии о |
| Разработка программного обеспечения |
|---|
Создание программного обеспечения — это дисциплина разработки программного обеспечения . Это детальное создание работающего значимого программного обеспечения посредством сочетания кодирования , проверки , модульного тестирования , интеграционного тестирования и отладки . Он связан со всеми другими дисциплинами разработки программного обеспечения, особенно с проектированием и тестированием программного обеспечения . [1]
Основы [ править ]
Минимизация сложности [ править ]
Необходимость снижения сложности обусловлена главным образом ограниченной способностью большинства людей удерживать сложные структуры и информацию в своей рабочей памяти. Снижение сложности достигается за счет упора на создание кода простого и читаемого , а не умного. Минимизация сложности достигается за счет использования стандартов и многочисленных специальных методов кодирования . Это также поддерживается методами обеспечения качества, ориентированными на строительство . [2]
Ожидание перемен [ править ]
Предвидение изменений помогает разработчикам программного обеспечения создавать расширяемое программное обеспечение, что означает, что они могут улучшать программный продукт, не нарушая его базовую структуру. [2] Исследования, продолжавшиеся более 25 лет, показали, что стоимость доработки может быть в 10–100 раз (в 5–10 раз для небольших проектов) дороже, чем стоимость правильного выполнения требований с первого раза. Учитывая, что 25% требований меняются в ходе разработки среднего проекта, необходимость снижения стоимости доработок подчеркивает необходимость предвидеть изменения. [3]
Построение для проверки [ править ]
Разработка для проверки означает создание программного обеспечения таким образом, чтобы ошибки могли быть легко обнаружены инженерами -программистами, пишущими программное обеспечение , а также во время независимого тестирования и эксплуатации. Конкретные методы, поддерживающие построение для проверки, следование стандартам кодирования для поддержки проверок кода , модульное тестирование , организацию кода для поддержки автоматического тестирования и ограниченное использование сложных или трудных для понимания языковых структур. включают , среди прочего, [2]
Повторное использование [ править ]
Систематическое повторное использование может обеспечить значительное улучшение производительности, качества и стоимости программного обеспечения. Повторное использование имеет два тесно связанных аспекта: [2]
- Создание для повторного использования: создавайте повторно используемые программные активы.
- Создание с повторным использованием: повторное использование программных активов при создании нового решения.
Стандарты в строительстве [ править ]
К стандартам, как внешним (созданным международными организациями), так и внутренним (созданным на корпоративном уровне), которые непосредственно затрагивают вопросы строительства, относятся: [2]
- Методы связи: например, стандарты форматов и содержания документов.
- Языки программирования
- Стандарты кодирования
- Платформы
- Инструменты: такие как диаграммные стандарты для нотаций, таких как UML .
Управление строительством [ править ]
Модель строительства. [ редактировать ]
множество моделей было создано Для разработки программного обеспечения , некоторые из которых больше ориентированы на строительство, чем другие. Некоторые модели более линейны с точки зрения построения, например «Водопад» и модели жизненного цикла поэтапной поставки. Эти модели рассматривают строительство как деятельность, которая происходит только после завершения значительных предварительных работ, включая над подробными требованиями работу , обширную работу по проектированию и детальное планирование . Другие модели являются более итеративными , например, эволюционное прототипирование , экстремальное программирование и 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 часами при тестировании. Microsoft обнаружила, что поиск и исправление дефекта с помощью проверки кода занимает 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 удалось сократить количество дефектов, о которых сообщали клиенты, в десять раз, а бюджет на обслуживание своей системы IMS сократить на 45 %, исправив или переписав только 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]
См. также [ править ]
Примечания [ править ]
- ^ Перейти обратно: а б с д Это ж г ШВЕДСКАЯ КНИГА Пьер Бурк; Робер Дюпюи; Ален Абран; Джеймс В. Мур, ред. (2004). «Глава 4: Создание программного обеспечения». Руководство к своду знаний по программной инженерии . Компьютерное общество IEEE . стр. 4–1–4–5. ISBN 0-7695-2330-7 .
- ^ Перейти обратно: а б с д Это СВЕБОК 2014 , с. 3-3.
- ^ МакКоннелл 2004 , Глава 3.
- ^ SWEBOK 2014 , с. 3-5.
- ^ МакКоннелл 2004 , Глава 5.
- ^ SWEBOK 2014 , с. 3-5 - 3-6.
- ^ МакКоннелл 2004 , Глава 4.
- ^ SWEBOK 2014 , с. 3-6.
- ^ МакКоннелл 2004 , Глава 11.
- ^ Перейти обратно: а б с МакКоннелл 2004 , Глава 6.
- ^ Перейти обратно: а б МакКоннелл 2004 , Глава 7.
- ^ МакКоннелл 2004 , Глава 12.
- ^ Перейти обратно: а б МакКоннелл 2004 , Глава 16.
- ^ Перейти обратно: а б МакКоннелл 2004 , Глава 19.
- ^ SWEBOK 2014 , с. 3-7.
- ^ Перейти обратно: а б с д МакКоннелл 2004 , Глава 20.
- ^ Перейти обратно: а б МакКоннелл 2004 , Глава 21.
- ^ Перейти обратно: а б МакКоннелл 2004 , Глава 22.
- ^ Перейти обратно: а б СВЕБОК 2014 , с. 3-8.
- ^ Тайер 2013 , стр. 140–141.
- ^ Тайер 2013 , с. 140.
- ^ Перейти обратно: а б с СВЕБОК 2014 , с. 3-9.
- ^ Тайер 2013 , с. 142.
- ^ Перейти обратно: а б СВЕБОК 2014 , с. 3-10.
Ссылки [ править ]
- Пьер Бурк; Ричард Э. Фэрли, ред. (2014). «Глава 3: Создание программного обеспечения». Руководство к своду знаний по программной инженерии, версия 3.0 . Компьютерное общество IEEE . ISBN 978-0-7695-5166-1 .
- МакКоннелл, Стивен (2004). Код завершен (2-е изд.). Майкрософт Пресс. ISBN 978-0-7356-1967-8 .
- Тайер, Ричард; Дорфман, Мерлин (2013). Основы программной инженерии . Том. Я: Процесс разработки (Четвертое изд.). Издательство по обучению управлению программным обеспечением, Кармайкл, Калифорния. ISBN 978-0-9852707-0-4 .