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

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

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

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

Методологии [ править ]

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

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

  • Самая простая методология — это «код и исправление», обычно используемый одним программистом, работающим над небольшим проектом. Кратко обсудив назначение программы, программист кодирует ее и запускает, чтобы проверить, работает ли она. Когда они будут завершены, продукт будет выпущен. Эта методология полезна для прототипов, но не может использоваться для более сложных программ. [4]
  • «сверху вниз» В каскадной модели технико-экономическое обоснование, анализ, проектирование , разработка, обеспечение качества и реализация происходят последовательно в указанном порядке. Эта модель требует завершения одного шага до начала следующего, что приводит к задержкам и делает невозможным пересмотр предыдущих шагов в случае необходимости. [5] [6] [7]
  • В итеративных процессах эти этапы чередуются друг с другом для повышения гибкости, эффективности и более реалистичного планирования. Вместо того, чтобы завершать проект сразу, можно выполнить большинство шагов с одним компонентом за раз. Итеративная разработка также позволяет разработчикам расставлять приоритеты для наиболее важных функций, позволяя при необходимости отказаться от менее приоритетных функций позже. [6] [8] Agile — это один из популярных методов, изначально предназначенный для малых и средних проектов. Он направлен на предоставление разработчикам большего контроля над функциями, над которыми они работают, чтобы снизить риск перерасхода времени или средств. [9] К производным Agile относятся экстремальное программирование и Scrum . [9] При разработке программного обеспечения с открытым исходным кодом обычно используется гибкая методология с одновременным проектированием, кодированием и тестированием из-за использования распределенной сети волонтеров. [10]
  • Помимо agile, некоторые компании интегрируют операции информационных технологий (ИТ) с разработкой программного обеспечения, что называется DevOps или DevSecOps , включая компьютерную безопасность . [11] DevOps включает в себя непрерывную разработку, тестирование , интеграцию нового кода в систему контроля версий, развертывание нового кода и иногда доставку кода клиентам. [12] Целью этой интеграции является более быстрое и эффективное предоставление ИТ-услуг. [11]

Еще одним направлением многих методологий программирования является идея попытаться выявить такие проблемы, как уязвимости безопасности и ошибки , как можно раньше ( тестирование со сдвигом влево ), чтобы снизить затраты на их отслеживание и исправление. [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. ^ Jump up to: Перейти обратно: а б Лангер 2016 , стр. 2–3, 5–6.
  7. ^ Такер, Морелли и де Сильва 2011 , стр. 8.
  8. ^ Дули 2017 , с. 11.
  9. ^ Jump up to: Перейти обратно: а б Дули 2017 , с. 13.
  10. ^ Такер, Морелли и де Сильва, 2011 , стр. 41–42.
  11. ^ Jump up to: Перейти обратно: а б Вишну 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. ^ Jump up to: Перейти обратно: а б с д Лангер 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. ^ Jump up to: Перейти обратно: а б с Лангер 2016 , с. 9.
  32. ^ Дули 2017 , с. 272.
  33. ^ Такер, Морелли и де Сильва 2011 , стр. 9.
  34. ^ Jump up to: Перейти обратно: а б с Лангер 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. ^ Jump up to: Перейти обратно: а б Такер, Морелли и де Сильва 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.

Дальнейшее чтение [ править ]

  • Конде, Дэн (2002). Управление программными продуктами: управление разработкой программного обеспечения от идеи до продукта, от маркетинга до продаж . Книги Аспаторе. ISBN  1587622025 .
  • Дэвис, AM (2005). Достаточно управления требованиями: где разработка программного обеспечения встречается с маркетингом . Издательская компания Дорсет Хаус, Инкорпорейтед. ISBN  0932633641 .
  • Дули, Джон Ф. (2017). Разработка программного обеспечения, проектирование и кодирование: с шаблонами, отладкой, модульным тестированием и рефакторингом . Апресс. ISBN  978-1-4842-3153-1 .
  • Кит, Эдвард (1992). Тестирование программного обеспечения в реальном мире . Аддисон-Уэсли Профессионал. ISBN  0201877562 .
  • Хастед, Эдвард (2005). Программное обеспечение, которое продается: практическое руководство по разработке и маркетингу вашего программного проекта . Издательство Уайли. ISBN  0764597833 .
  • Хоманн, Люк (2003). За пределами архитектуры программного обеспечения: создание и поддержка выигрышных решений . Аддисон-Уэсли Профессионал. ISBN  0201775948 .
  • Хорч, Джон В. (март 1995 г.). «Два направления работы с объектами». Программное обеспечение IEEE . 12 (2): 117–118. ПроКвест   215832531 .
  • Лангер, Артур М. (2016). Руководство по разработке программного обеспечения: проектирование и управление жизненным циклом . Спрингер. ISBN  978-1-4471-6799-0 .
  • Маккарти, Джим (1995). Динамика разработки программного обеспечения . Майкрософт Пресс. ISBN  1556158238 .
  • Моррис, Джозеф М. (2001). Бухгалтерский учет в отрасли программного обеспечения (2-е изд.). Джон Уайли и сыновья . OCLC   53863959 .
  • Риттингхаус, Джон (2003). Управление результатами разработки программного обеспечения: методология управления разработкой программного обеспечения . Цифровая пресса. ISBN  155558313X .
  • Саиф, Сайед Мохсин (2019). «Оценка усилий по разработке программного обеспечения для успешной разработки программных приложений». У Вишну, Пендьяла (ред.). Инструменты и методы разработки программного обеспечения в крупных организациях: Новые исследования и возможности: Новые исследования и возможности . IGI Global. стр. 45–97. ISBN  978-1-7998-1865-6 .
  • Такер, Аллен; Морелли, Ральф; де Сильва, Чаминдра (2011). Разработка программного обеспечения: подход с открытым исходным кодом . ЦРК Пресс. ISBN  978-1-4398-8460-7 .
  • Вишну, Пендьяла (2019). «Эволюция интеграции, сборки, тестирования и выпуска в DevOps и DevSecOps». У Вишну, Пендьяла (ред.). Инструменты и методы разработки программного обеспечения в крупных организациях: Новые исследования и возможности: Новые исследования и возможности . IGI Global. стр. 1–20. ISBN  978-1-7998-1865-6 .
  • Вигерс, Карл Э. (2005). Подробнее о требованиях к программному обеспечению: острые вопросы и практические советы . Майкрософт Пресс. ISBN  0735622671 .
  • Уинтерс, Титус; Маншрек, Том; Райт, Хайрам (2020). Разработка программного обеспечения в Google: уроки, извлеченные из программирования с течением времени . O'Reilly Media, Inc. ISBN  978-1-4920-8276-7 .
  • Высоцкий, Роберт К. (2006). Эффективное управление программными проектами . Уайли. ISBN  0764596365 .

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_development&oldid=1226977339"