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

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

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

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

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

Методологии

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

Большинство методологий разделяют некоторые комбинации следующих этапов разработки программного обеспечения:

  • Анализируем проблему
  • Исследования рынка
  • Сбор требований к предлагаемому ПО
  • Разработка плана или дизайна для программного обеспечения
  • Внедрение (кодирование) программного обеспечения
  • Тестирование и отладка программного обеспечения
  • Развертывание
  • Обслуживание и исправление ошибок

Стадии часто вместе называют жизненным циклом разработки программного обеспечения или SDLC. Различные подходы к разработке программного обеспечения могут выполнять эти этапы в разном порядке или уделять больше или меньше времени различным этапам. Уровень детализации документации, создаваемой на каждом этапе разработки программного обеспечения, также может различаться. Эти этапы также могут выполняться по очереди («структурированный» подход) или они могут повторяться в течение различных циклов или итераций («экстремальный» подход). Экстремальный подход обычно требует меньше времени, затрачиваемого на планирование и документацию, и больше. время, затраченное на кодирование и разработку автоматизированных тестов . Экстремальные подходы также способствуют непрерывному тестированию на протяжении всего жизненного цикла разработки, а также постоянному наличию работающего продукта. Структурированные подходы пытаются оценить большинство рисков и разработать подробный план для программного обеспечения до начала внедрения , а также избежать значительных изменений дизайна и перекодирования на более поздних этапах планирования жизненного цикла разработки программного обеспечения.

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

Выявление потребности

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

В книге «Великие дебаты программного обеспечения» , Алан М. Дэвис утверждает , в главе «Требование» , подраздел «недостающая часть разработки программного обеспечения»

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

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

Процесс планирования

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

«Несмотря на то, что на этапе требований прилагается много усилий для обеспечения полноты и согласованности требований, это случается редко; фаза разработки программного обеспечения остается наиболее важной, когда дело доходит до сведения к минимуму воздействия новых или изменяющихся требований. Неустойчивость требований сложно, потому что они влияют на будущие или уже предпринимаемые усилия по развитию ".

Как только общие требования получены от клиента, следует определить и четко изложить анализ объема разработки. Это часто называют документом области применения.

Проектирование

Основные статьи: Дизайн программного обеспечения и системный дизайн

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

Внедрение, тестирование и документирование

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

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

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

Развертывание и обслуживание

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

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

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

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

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

Примечание: программное обеспечение, особенно. мобильные приложения могут работать в сети.

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

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

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

Веб-разработчики используют кодирование и написание разметки для создания интерактивных веб-страниц.

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

Подтемы

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

TEAF Матрица мнений и взглядов.

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

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

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

Бизнес-процессы и моделирование данных

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

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

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

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

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

Компьютерная инженерия программного обеспечения (CASE) в области разработки программного обеспечения - это научное применение набора программных инструментов и методов для разработки программного обеспечения, которое приводит к созданию высококачественных, бездефектных и обслуживаемых программных продуктов. Это также относится к методам разработки информационных систем вместе с автоматизированными инструментами, которые могут использоваться в процессе разработки программного обеспечения. Термин «автоматизированная разработка программного обеспечения» (CASE) может относиться к программному обеспечению, используемому для автоматизированной разработки системного программного обеспечения , то есть к компьютерному коду. Функции CASE включают анализ, проектирование и программирование. Инструменты CASE автоматизируют методы проектирования, документирования и создания структурированного компьютерного кода на желаемом языке программирования .

Две ключевые идеи системной инженерии компьютерного программного обеспечения (CASE):

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

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

Анджута , C и C ++ IDE для среды GNOME

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

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

Язык моделирования

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

Примеры языков графического моделирования в области разработки программного обеспечения:

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

Парадигма программирования

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

Язык программирования может поддерживать несколько парадигм . Например, программы, написанные на C ++ или Object Pascal, могут быть чисто процедурными , или чисто объектно-ориентированными , или содержать элементы обеих парадигм. Разработчики программного обеспечения и программисты решают, как использовать эти элементы парадигмы. В объектно-ориентированном программировании программисты могут думать о программе как о совокупности взаимодействующих объектов, в то время как в функциональном программировании программу можно рассматривать как последовательность вычислений функций без сохранения состояния. При программировании компьютеров или систем с большим количеством процессоров процессно-ориентированное программирование позволяет программистам думать о приложениях как о наборах параллельных процессов, действующих на логически разделяемые структуры данных .

Подобно тому, как разные группы разработчиков программного обеспечения отстаивают разные методологии , разные языки программирования отстаивают разные парадигмы программирования . Некоторые языки предназначены для поддержки одной парадигмы ( Smalltalk поддерживает объектно-ориентированное программирование, Haskell поддерживает функциональное программирование), в то время как другие языки программирования поддерживают несколько парадигм (например, Object Pascal , C ++ , C # , Visual Basic , Common Lisp , Scheme , Python , Ruby , и Оз ).

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

Примеры парадигм высокого уровня включают:

Повторное использование программного обеспечения

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

Смотрите также

Роли и отрасль

Конкретные приложения

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

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

  • Кит, Эдвард (1992). Тестирование программного обеспечения в реальном мире . Эддисон-Уэсли Профессионал. ISBN 0201877562.
  • Маккарти, Джим (1995). Динамика разработки программного обеспечения . Microsoft Press. ISBN 1556158238.
  • Конде, Дэн (2002). Управление программным продуктом: управление разработкой программного обеспечения от идеи до продукта, от маркетинга до продаж . Книги Аспатора. ISBN 1587622025.
  • Дэвис, AM (2005). Достаточно управления требованиями: там, где разработка программного обеспечения встречается с маркетингом . Издательская компания "Дорсет Хаус", инкорпорейтед. ISBN 0932633641.
  • Хастед, Эдвард (2005). Программное обеспечение, которое продает: практическое руководство по разработке и маркетингу вашего программного проекта . Wiley Publishing. ISBN 0764597833.
  • Хоманн, Люк (2003). За пределами архитектуры программного обеспечения: создание и поддержка успешных решений . Эддисон-Уэсли Профессионал. ISBN 0201775948.
  • Джон У. Хорч (2005). «Два направления работы с объектами». В: Программное обеспечение IEEE . т. 12, вып. 2. С. 117–118, март 1995 г.
  • Риттингхаус, Джон (2003). Управление поставками программного обеспечения: методология управления разработкой программного обеспечения . Цифровая пресса. ISBN 155558313X.
  • Вигерс, Карл Э. (2005). Подробнее о требованиях к программному обеспечению: острые вопросы и практические советы . Microsoft Press. ISBN 0735622671.
  • Высоцкий, Роберт К. (2006). Эффективное управление программными проектами . Вайли. ISBN 0764596365.