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 Дули 2017, стр. 13.
  10. ^ Такер, Морелли и де Сильва, 2011, стр. 41–42.
  11. ^ аб Вишну 2019, стр. 1–2.
  12. ^ Лаукканен, Ээро; Итконен, Юха; Лассениус, Каспер (2017). «Проблемы, причины и решения при внедрении непрерывной доставки — систематический обзор литературы». Информационные и программные технологии . 82 : 55–79. дои : 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 Лангер 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 Лангер 2016, стр. 9.
  32. ^ Дули 2017, с. 272.
  33. ^ Такер, Морелли и де Сильва 2011, с. 9.
  34. ^ abc Лангер 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. ^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454.
  57. ^ Лангер 2016, стр. 44–45.

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

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