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

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

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

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

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

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

Методологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выполнение это часть процесса, где программисты фактически программа код для проекта.

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

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

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

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

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

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

Подтемы

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

В ЧАЙФ Матрица взглядов и перспектив.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ «Разработка приложений (AppDev): определение и объяснение». Bestpricecomputers.co.uk. 2007-08-13. Получено 2012-08-05.
  2. ^ DRM Associates (2002). «Глоссарий по разработке новых продуктов». Получено 2006-10-29.
  3. ^ Методологии разработки систем для электронного бизнеса с поддержкой Интернета: структура настройки Линда В. Найт (Университет Депол, США), Тереза ​​А.Стейнбах (Университет ДеПола, США) и Винс Келлен (Blue Wolf, США)
  4. ^ Джозеф М. Моррис (2001). Бухгалтерский учет в индустрии программного обеспечения. п.1.10
  5. ^ Алан М. Дэвис. Великие дебаты по программному обеспечению (8 октября 2004 г.), стр: 125-128 Wiley-IEEE Computer Society Press
  6. ^ Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. In, Lyytinen, K., Loucopoulos, P., Милопулос, Дж., и Робинсон, У. (ред.), Разработка требований к дизайну: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103-136.
  7. ^ Отеро, Карлос. «Проблемы проектирования программного обеспечения». Повышение производительности ИТ. ООО "Тейлор и Фрэнсис". Получено 19 октября 2017.
  8. ^ Эдвард Дж. Баркмейер и др. (2003). Концепции автоматизации системной интеграции NIST 2003.
  9. ^ а б c d Пол Р. Смит и Ричард Сарфати (1993). Создание стратегического плана управления конфигурацией с помощью инструментов компьютерной инженерии программного обеспечения (CASE). Документ для группы пользователей CAD / CAE национального министерства энергетики / подрядчиков и предприятий, 1993 г.
  10. ^ Кун, Д.Л. (1989). «Выбор и эффективное использование инструмента автоматизированной разработки программного обеспечения». Ежегодный компьютерный симпозиум Westinghouse; 6-7 ноября 1989 г .; Питтсбург, Пенсильвания (США); Проект DOE.
  11. ^ П. Лукопулос и В. Каракостас (1995). Разработка системных требований. Макгроу-Хилл.
  12. ^ ДЕЛО В архиве 2012-02-18 в Wayback Machine определение в: Глоссарий по телекоммуникациям 2000 В архиве 2005-11-22 на Wayback Machine. Проверено 26 октября 2008 г.
  13. ^ К. Робинсон (1992). Включение программной инженерии в CASE. Нью-Йорк: John Wiley and Sons Inc.
  14. ^ Сяо Хэ (2007). "Метамодель для обозначения языков графического моделирования". В: Конференция по компьютерному программному обеспечению и приложениям, 2007. COMPSAC 2007 - Vol. 1. 31-я ежегодная международная конференция, Том 1, выпуск, 24–27 июля 2007 г., стр. 219–224.
  15. ^ Merx, Georges G .; Норман, Рональд Дж. (2006). Единая разработка программного обеспечения с Java. Prentice-Hall, Inc. стр.201. ISBN 0130473766.

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

  • Кит, Эдвард (1992). Тестирование программного обеспечения в реальном мире. Эддисон-Уэсли Профессионал. ISBN 0201877562.
  • Маккарти, Джим (1995). Динамика разработки программного обеспечения. Microsoft Press. ISBN 1556158238.
  • Конде, Дэн (2002). Управление программным продуктом: управление разработкой программного обеспечения от идеи до продукта, от маркетинга до продаж. Книги Аспатора. ISBN 1587622025.
  • Дэвис, А. М. (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.