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

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

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

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

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

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

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

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

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

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

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

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

Выявление потребности [ править ]

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

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

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

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

Процесс планирования [ править ]

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

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

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

Проектирование [ править ]

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

Внедрение, тестирование и документирование [ править ]

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

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

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

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

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

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

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

Подтемы [ править ]

Посмотреть модель [ редактировать ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Редактор исходного кода ,
• Компилятор или интерпретатор ,
• Создавайте инструменты автоматизации и
• Отладчик (обычно).

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

Язык моделирования [ править ]

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

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

• Нотация моделирования бизнес-процессов (BPMN и XML- форма BPML) является примером языка моделирования процессов .
• EXPRESS и EXPRESS-G (ISO 10303-11) - это международный стандартный язык моделирования данных общего назначения .
• Расширенный язык моделирования предприятия (EEML) обычно используется для моделирования бизнес-процессов на разных уровнях.
• Блок- схема - это схематическое представление алгоритма или пошагового процесса,
• Язык моделирования Fundamental Modeling Concepts (FMC) для систем с интенсивным программным обеспечением.
• IDEF - это семейство языков моделирования, наиболее известные из которых включают IDEF0 для функционального моделирования, IDEF1X для информационного моделирования и IDEF5 для моделирования онтологий.
• LePUS3 - это объектно-ориентированный язык описания визуального дизайна и язык формальных спецификаций, который подходит в первую очередь для моделирования больших объектно-ориентированных ( Java , C ++ , C # ) программ и шаблонов проектирования .
• Язык спецификаций и описания (SDL) - это язык спецификаций, нацеленный на недвусмысленную спецификацию и описание поведения реактивных и распределенных систем.
• Унифицированный язык моделирования (UML) - это язык моделирования общего назначения , являющийся отраслевым стандартом для описания систем с интенсивным использованием программного обеспечения. UML 2.0, текущая версия, поддерживает тринадцать различных техник диаграмм и имеет широкую поддержку инструментов.

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

Парадигма программирования [ править ]

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

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

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

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

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

• Аспектно-ориентированная разработка программного обеспечения
• Доменно-ориентированное моделирование
• Модельно-ориентированная инженерия
• Методологии объектно-ориентированного программирования
  • Гради Буч «с объектно-ориентированного проектирования (ООП), также известный как объектно-ориентированного анализа и проектирования (OOAD). Модель Буча включает шесть диаграмм: класс, объект, переход между состояниями, взаимодействие, модуль и процесс. ^[15]
• Разработка программного обеспечения на основе поиска
• Сервисно-ориентированное моделирование
• Структурированное программирование
• Дизайн сверху вниз и снизу вверх
  • Нисходящее программирование : разработано в 1970-х годах исследователем IBM Харланом Миллсом (и Никлаусом Виртом ) в виде развитого структурированного программирования .

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

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

• Структура программного обеспечения является многоразовым дизайн или реализации для программной системы или подсистемы.
• Компонентная разработка программного обеспечения включает в себя интеграцию существующих компонентов для создания приложения.
• Сервис-ориентированные архитектуры или сервис-ориентированное программирование основываются на концепции компонентов для предоставления сетевых сервисов, таких как веб-сервисы .
• Линии программных продуктов стремятся разрабатывать программное обеспечение на основе общего набора «основных» активов и процессов, чтобы производить ряд продуктов (или «приложений») для конкретного рынка.
• API ( интерфейс прикладного программирования , устанавливает набор « определений подпрограмм, протоколов и инструментов для создания прикладного программного обеспечения », которые можно использовать в будущих сборках.
• Документация с открытым исходным кодом через библиотеки, такие как GitHub , предоставляет разработчикам программного обеспечения бесплатный код для повторного использования и внедрения в новые приложения или проекты.

См. Также [ править ]

• Непрерывная интеграция
• Программное обеспечение на заказ
• DevOps
• Функциональная спецификация
• Производительность программирования
• План программного обеспечения
• Разработка программного обеспечения
• Оценка усилий по разработке программного обеспечения
• Процесс разработки программного обеспечения
• Управление программными проектами
• Спецификация и язык описания
• Пользовательский опыт
• Софтверная индустрия

Роли и отрасль [ править ]

• Бакалавр наук в области информационных технологий
• Программист
• Инженер-консультант
• Оффшорная разработка программного обеспечения
• Разработчик программного обеспечения
• Программист
• Издатель программного обеспечения

Конкретные приложения [ править ]

• Разработка видеоигр
• Разработка веб-приложений
• Веб-инженерия
• Разработка мобильных приложений

Ссылки [ править ]

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

Викискладе есть медиафайлы по теме разработки программного обеспечения .

• Кит, Эдвард (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.