stringtranslate.com

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

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

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

Разработка программного обеспечения включает в себя множество инструментов , включая: компилятор , интегрированную среду разработки (IDE), систему контроля версий , систему автоматизированной разработки программного обеспечения и текстовый процессор .

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

Методологии

Блок-схема эволюционной модели прототипирования, итеративной модели разработки [2]

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

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

В 2009 году было подсчитано, что 32 процента проектов программного обеспечения были доставлены в срок и в соответствии с бюджетом, и с полной функциональностью. Еще 44 процента были доставлены, но без по крайней мере одной из этих функций. Оставшиеся 24 процента были отменены до выпуска. [14]

Шаги

Жизненный цикл разработки программного обеспечения относится к систематическому процессу разработки приложений . [15]

Осуществимость

Источников идей для программных продуктов множество. Эти идеи могут поступать из маркетинговых исследований, включая демографические данные потенциальных новых клиентов, существующих клиентов, потенциальных клиентов, которые отклонили продукт, других внутренних сотрудников по разработке программного обеспечения или креативной третьей стороны. Идеи для программных продуктов обычно сначала оцениваются маркетинговым персоналом на предмет экономической осуществимости, соответствия существующим каналам распространения, возможного влияния на существующие линейки продуктов, требуемых функций и соответствия маркетинговым целям компании. На этапе маркетинговой оценки оцениваются предположения по стоимости и времени. [16] Анализ осуществимости оценивает окупаемость проекта , стоимость и сроки его разработки. На основе этого анализа компания может принять бизнес-решение об инвестировании в дальнейшую разработку. [17] После принятия решения о разработке программного обеспечения компания фокусируется на поставке продукта по предполагаемой стоимости и времени или ниже, а также с высоким стандартом качества (т. е. отсутствием ошибок) и желаемой функциональностью. Тем не менее, большинство программных проектов выполняются с опозданием, и иногда для соблюдения сроков приходится идти на компромиссы в функциях или качестве. [18]

Анализ

Анализ программного обеспечения начинается с анализа требований для определения бизнес-потребностей программного обеспечения. [19] Проблемы определения потребностей заключаются в том, что текущие или потенциальные пользователи могут иметь разные и несовместимые потребности, могут не понимать свои собственные потребности и менять свои потребности в процессе разработки программного обеспечения. [20] В конечном итоге результатом анализа является подробная спецификация продукта, с которой могут работать разработчики. Аналитики программного обеспечения часто разбивают проект на более мелкие объекты, компоненты, которые можно повторно использовать для повышения экономической эффективности, производительности и надежности. [19] Разбивание проекта может обеспечить многопоточную реализацию, которая работает значительно быстрее на многопроцессорных компьютерах. [21]

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

Дизайн

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

Программирование

Центральная особенность разработки программного обеспечения — создание и понимание программного обеспечения, реализующего желаемую функциональность. [26] Существуют различные стратегии написания кода. Связанное программное обеспечение имеет различные компоненты, которые независимы друг от друга. [19] Связанность — это взаимосвязь различных компонентов программного обеспечения, что считается нежелательным, поскольку увеличивает сложность обслуживания . [27] Часто программисты программного обеспечения не следуют лучшим отраслевым практикам, что приводит к тому, что код становится неэффективным, сложным для понимания или не имеет документации по его функциональности. [28] Эти стандарты особенно склонны нарушаться при наличии крайних сроков. [29] В результате тестирование, отладка и пересмотр кода становятся намного сложнее. Рефакторинг кода , например, добавление дополнительных комментариев к коду, является решением для улучшения понятности кода. [30]

Тестирование

Тестирование — это процесс обеспечения корректного и безошибочного выполнения кода. Отладка выполняется каждым разработчиком программного обеспечения на собственном коде, чтобы подтвердить, что код выполняет то, для чего он предназначен. В частности, крайне важно, чтобы программное обеспечение выполнялось на всех входных данных, даже если результат неверен. [31] Обзоры кода другими разработчиками часто используются для тщательной проверки нового кода, добавляемого в проект, и, по некоторым оценкам, значительно сокращают количество ошибок, сохраняющихся после завершения тестирования. [32] После отправки кода отдел обеспечения качества — отдельный отдел непрограммистов для большинства крупных компаний — проверяет точность всего программного продукта. Приемочные тесты, полученные на основе исходных требований к программному обеспечению, являются популярным инструментом для этого. [31] Тестирование качества также часто включает проверку нагрузки и стресса (устойчиво ли программное обеспечение к высоким уровням ввода или использования), интеграционное тестирование (для обеспечения адекватной интеграции программного обеспечения с другим программным обеспечением) и тестирование совместимости (измерение производительности программного обеспечения в различных операционных системах или браузерах). [31] Когда тесты пишутся до кода, это называется разработкой через тестирование . [33]

Производство

Производство — это фаза, на которой программное обеспечение развертывается для конечного пользователя. [34] Во время производства разработчик может создавать ресурсы технической поддержки для пользователей [35] [34] или процесс исправления ошибок и сбоев, которые не были обнаружены ранее. Также может быть возврат к более ранним фазам разработки, если потребности пользователя изменились или были неправильно поняты. [34]

Рабочие

Разработка программного обеспечения выполняется разработчиками программного обеспечения , обычно работающими в команде. Эффективная коммуникация между членами команды имеет важное значение для успеха. Этого легче достичь, если команда небольшая, привыкла работать вместе и находится недалеко друг от друга. [36] Коммуникации также помогают выявлять проблемы на более ранней стадии разработки и избегать дублирования усилий. Многие проекты по разработке избегают риска потери важных знаний, имеющихся только у одного сотрудника, гарантируя, что несколько сотрудников знакомы с каждым компонентом. [37] Разработка программного обеспечения включает в себя профессионалов из различных областей, не только программистов, но и лиц, специализирующихся на тестировании, написании документации, графическом дизайне , поддержке пользователей, маркетинге и сборе средств. Хотя работники, работающие над проприетарным программным обеспечением, получают оплату, большинство участников программного обеспечения с открытым исходным кодом являются волонтерами. [ 38] С другой стороны, им могут платить компании, чья бизнес-модель не подразумевает продажу программного обеспечения, а что-то другое, например, услуги и модификации программного обеспечения с открытым исходным кодом. [39]

Модели и инструменты

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

Компьютерная инженерия программного обеспечения (CASE) — это инструменты для частичной автоматизации разработки программного обеспечения. [40] CASE позволяет разработчикам набросать логику программы, будь то программа, которую нужно написать, или уже существующая, чтобы помочь интегрировать ее с новым кодом или провести ее обратную разработку (например, для изменения языка программирования ). [41]

Документация

Документация существует в двух формах, которые обычно хранятся отдельно: одна предназначена для разработчиков программного обеспечения, а другая — доступна конечному пользователю, чтобы помочь им использовать программное обеспечение. [42] [43] Большая часть документации для разработчиков представлена ​​в виде комментариев к коду для каждого файла, класса и метода , которые охватывают интерфейс прикладного программирования (API) — как часть программного обеспечения может быть доступна другому — и часто детали реализации. [44] Эта документация полезна для новых разработчиков, чтобы понять проект, когда они начинают над ним работать. [45] В гибкой разработке документация часто пишется одновременно с кодом. [46] Пользовательская документация чаще пишется техническими писателями . [47]

Оценка усилий

Точная оценка имеет решающее значение на этапе осуществимости и для поставки продукта в срок и в рамках бюджета. Процесс генерации оценок часто делегируется менеджером проекта . [48] Поскольку оценка усилий напрямую связана с размером полного приложения, на нее сильно влияет добавление функций в требования — чем больше требований, тем выше стоимость разработки. Аспекты, не связанные с функциональностью, такие как опыт разработчиков программного обеспечения и возможность повторного использования кода, также важны для рассмотрения при оценке. [49] По состоянию на 2019 год большинство инструментов для оценки количества времени и ресурсов для разработки программного обеспечения были разработаны для обычных приложений и не применимы к веб-приложениям или мобильным приложениям . [50]

Интегрированная среда разработки

Anjuta , интегрированная среда разработки (IDE) для C и C++ в среде GNOME

Интегрированная среда разработки (IDE) поддерживает разработку программного обеспечения с расширенными функциями по сравнению с простым текстовым редактором . [51] IDE часто включают в себя автоматическую компиляцию , подсветку синтаксических ошибок, [52] помощь в отладке, [53] интеграцию с контролем версий и полуавтоматизацию тестов. [51]

Контроль версий

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

Посмотреть модель

Матрица взглядов и перспектив TEAF

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

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

Фитнес-функции

Функции пригодности — это автоматизированные и объективные тесты, гарантирующие, что новые разработки не отклоняются от установленных ограничений, проверок и контроля соответствия. [56]

Интеллектуальная собственность

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

Ссылки

  1. ^ Дули 2017, стр. 1.
  2. ^ Дули 2017, стр. 12.
  3. ^ Методологии разработки систем для веб-ориентированного электронного бизнеса: структура настройки Линда В. Найт (Университет Де Поля, США), Тереза ​​А. Стейнбах (Университет Де Поля, США) и Винс Келлен (Blue Wolf, США)
  4. ^ Дули 2017, стр. 8–9.
  5. ^ Дули 2017, стр. 9.
  6. ^ ab Langer 2016, стр. 2–3, 5–6.
  7. ^ Такер, Морелли и де Сильва 2011, с. 8.
  8. ^ Дули 2017, стр. 11.
  9. ^ ab Dooley 2017, стр. 13.
  10. ^ Такер, Морелли и де Сильва, 2011, стр. 41–42.
  11. ^ ab Vishnu 2019, стр. 1–2.
  12. ^ Лаукканен, Ээро; Итконен, Юха; Лассениус, Каспер (2017). «Проблемы, причины и решения при принятии непрерывной доставки — систематический обзор литературы». Информационные и программные технологии . 82 : 55–79. doi : 10.1016/j.infsof.2016.10.001 .
  13. ^ Уинтерс, Мэншрек и Райт 2020, стр. 17.
  14. ^ Такер, Морелли и де Сильва 2011, с. 6.
  15. ^ Саиф 2019, стр. 46–47.
  16. ^ Моррис 2001, стр. 1.10.
  17. ^ Лангер 2016, стр. 7.
  18. ^ Дули 2017, стр. 3, 8.
  19. ^ abcd Langer 2016, стр. 8.
  20. ^ Лангер 2016, стр. 2–3.
  21. ^ Дули 2017, стр. 193–194.
  22. ^ Лангер 2016, стр. 103–104.
  23. ^ Лангер 2016, стр. 117, 127, 131, 137, 141.
  24. ^ Лангер 2016, стр. 106.
  25. ^ Дули 2017, стр. 142.
  26. ^ Такер, Морелли и де Сильва 2011, с. 31.
  27. ^ Лангер 2016, стр. 8–9.
  28. ^ Такер, Морелли и де Сильва, 2011, стр. 31–32.
  29. ^ Такер, Морелли и де Сильва, 2011, стр. 34–35.
  30. ^ Такер, Морелли и де Сильва 2011, стр. 31–32, 35.
  31. ^ abc Langer 2016, стр. 9.
  32. ^ Дули 2017, стр. 272.
  33. ^ Такер, Морелли и де Сильва 2011, с. 9.
  34. ^ abc Langer 2016, стр. 10.
  35. ^ Такер, Морелли и де Сильва 2011, с. 37.
  36. ^ Дули 2017, стр. 2.
  37. ^ Уинтерс, Мэншрек и Райт 2020, стр. 30–31.
  38. ^ Такер, Морелли и де Сильва 2011, с. 7.
  39. ^ Такер, Морелли и де Сильва, 2011, стр. 14–15.
  40. ^ Лангер 2016, стр. 22.
  41. ^ Лангер 2016, стр. 108–110, 206.
  42. ^ Такер, Морелли и де Сильва 2011, с. 243.
  43. ^ Уинтерс, Мэншрек и Райт 2020, стр. 192.
  44. ^ Уинтерс, Мэншрек и Райт 2020, стр. 193–195.
  45. ^ Такер, Морелли и де Сильва 2011, с. 143.
  46. ^ Такер, Морелли и де Сильва 2011, с. 144.
  47. ^ Уинтерс, Мэншрек и Райт 2020, стр. 204.
  48. ^ Саиф 2019, стр. 50–51.
  49. ^ Саиф 2019, стр. 52–53.
  50. ^ Саиф 2019, стр. 45.
  51. ^ аб Такер, Морелли и де Сильва 2011, стр. 68.
  52. ^ Дули 2017, стр. 236.
  53. ^ Дули 2017, стр. 239.
  54. ^ Дули 2017, стр. 246–247.
  55. ^ Эдвард Дж. Баркмейер и др. (2003). Концепции автоматизации системной интеграции Архивировано 25 января 2017 г. в Wayback Machine NIST 2003.
  56. ^ Основы архитектуры программного обеспечения: инженерный подход . O'Reilly Media. 2020. ISBN 978-1492043454.
  57. ^ Лангер 2016, стр. 44–45.

Дальнейшее чтение

Внешние ссылки