Среда , 22 мая 2024


Разработка программного обеспечения: факторы, процессы, этапы

Разработка программного обеспечения: факторы, процессы, этапы

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

Содержание статьи:

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

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

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

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

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

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

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

Методы структурного анализа для проектирования ПО

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

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

Разработка программного обеспечения: факторы, процессы, этапы

Исходя из всего этого, первым этапом процесса упрощения сложной системы является разделение ее на несколько «черных ящиков». Однако подразделения должны соответствовать некоторым основным критериям.

  • Каждый «черный ящик» должен иметь одну единственную функцию;
  • Функции этих «ящиков» должны быть простыми для понимания, даже если их трудно реализовать на практике;
  • Отношения между элементами системы необходимо создавать только в том случае, если эти функции взаимосвязаны. В бухгалтерском учете один из этих «черных ящиков» необходим для определения суммы валовой заработной платы работника, а другой — для определения суммы налогов. Очевидно, что между ними должна быть связь. Ведь чтобы рассчитать сумму налога, необходимо знать сумму заработной платы;
  • Отношения между «черными ящиками» должны быть как можно более простыми. Благодаря этому они независимы друг от друга.

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

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

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

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

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

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

Разработка программного обеспечения: факторы, процессы, этапы

В процессе структурного анализа и проектирования используется ряд моделей, которые описывают:

  • Функциональная структура системы;
  • Последовательность операций, которые необходимо выполнить;
  • Передача данных между функциональными процессами;
  • Взаимосвязи между данными.

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

Первая стадия работы над ПО — подготовка

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

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

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

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

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

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

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

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

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

Разработка программного обеспечения: факторы, процессы, этапы

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

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

Следующий этап — опытная эксплуатация

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

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

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

Разработка программного обеспечения: факторы, процессы, этапы

Конечный этап любого проекта — завершение

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

Вспомогательные процессы при разработке ПО

В рамках разработки программного обеспечения можно выделить несколько вспомогательных процессов:

  • Документация. Подрядчик создает документацию и руководства пользователя для созданного программного продукта, как во время, так и после разработки. Такая документация позволяет программистам понять структуру и код даже спустя долгое время после его создания. В то же время документация помогает пользователям в эксплуатации системы;
  • Управление конфигурацией. Рассказывает о задаче управления набором созданных программных компонентов и версиями программного продукта;
  • Обеспечение качества. Этот процесс необходим для обеспечения соответствия программного продукта предварительным требованиям разработки и стандартам исполнителя и организации-заказчика;
  • Верификация. Он может обнаружить ошибки, возникающие во время разработки программного обеспечения. Верификация также может выявить несоответствия между разработанным программным обеспечением и построенной архитектурой;
  • Сертификация. Необходимо проверить, чтобы полученные значения соответствовали утвержденным стандартам. Это означает, что выходные данные должны содержать ошибки, отвечающие всем требованиям и критериям;
  • Совместная оценка. Этот процесс направлен на мониторинг и проверку состояния персонала и производимого программного обеспечения. Она выполняется заказчиком и подрядчиком на протяжении всего проекта;
  • Аудит. Требуется самостоятельно оценивать текущее состояние, характеристики проекта, документацию и различные отчеты. Этот процесс позволяет сравнить фактическую ситуацию с контрактом и документацией, в которой указаны требования. Аудиторские проверки могут проводиться одной или двумя сторонами;
  • Решение проблем. Ошибки, обнаруженные на этапе контроля и оценки, устраняются.

Факторы, влияющие на разработку ПО

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

  • Класс решенных задач. Определяется семантическое содержание созданной программы;
  • Применяемые методики. В них изложены организационные и технические особенности реализации основных этапов разработки программного обеспечения;
  • Методы и парадигмы программирования. От них зависит стиль кодирования и архитектура виртуальной машины;
  • Аппаратное и системное программное обеспечение. Это виртуальные и физические ресурсы, которые позволяют использовать программное обеспечение.

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

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

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

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

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

Разработка программного обеспечения: факторы, процессы, этапы

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

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

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

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

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

Waterfall (каскадная модель, или «водопад»)

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

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

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

Печать на кружках как создать уникальный и запоминающийся подарок

В современном мире персонализированные сувениры становятся все более популярными. Возможность создания индивидуальных и оригинальных подарков …

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.