Разработка программного обеспечения: факторы, процессы, этапы
Разработка программного обеспечения — это комплексный процесс, на который влияет множество факторов. Хотя для систематизации и объяснения каждого элемента потребовалась бы целая книга, важно подчеркнуть наиболее важные составляющие этого процесса.
Содержание статьи:
Разработка обычно подразумевает наличие модели, но это не единственное, что вам нужно знать. В нашей статье мы расскажем, на каком этапе находится разработка программного обеспечения, и проанализируем наиболее актуальные модели программ для выполнения заданий.
Понятие разработки программного обеспечения
Во-первых, необходимо определить концепцию разработки программного обеспечения.
Программное обеспечение (ПО) — это исполняемый код, выполняющий определенные вычислительные операции; POE — это набор элементов, содержащих исполняемый программный код, связанные библиотеки и документацию. Мы уже говорим о программных продуктах (ПП), когда они создаются для выполнения конкретной задачи.
Еще одно важное понятие, которое необходимо рассмотреть в рамках данной темы, — это инжиниринг. Эта область представляет собой разработку продукта с использованием определенной научной методологии.
Программная инженерия — это еще одна область деятельности, в которой разрабатываются программные продукты. В этом случае используются самые конкретные научные методы и принципы. Конечной целью является создание высококачественного, полезного программного продукта.
Согласно определению IEEE, разработка программного обеспечения — это применение систематического, дисциплинированного и количественного подхода к разработке и дальнейшему использованию и сопровождению результатов.
Методы структурного анализа для проектирования ПО
Структурные методы составляют дисциплину системного анализа и проектирования. Благодаря таким методам можно устранить различные трудности, связанные с детализацией больших систем. Это достигается за счет разделения на компоненты, также называемые «черными ящиками», и иерархической организации таких «черных ящиков».
Практическое преимущество дифференциации заключается в том, что при использовании приобретенных компонентов нет необходимости понимать принципы их работы. Пользователю достаточно знать их вход и выход, а также их назначение. Проще говоря, они должны понимать, какие задачи выполняет этот и «черный ящик».
Исходя из всего этого, первым этапом процесса упрощения сложной системы является разделение ее на несколько «черных ящиков». Однако подразделения должны соответствовать некоторым основным критериям.
- Каждый «черный ящик» должен иметь одну единственную функцию;
- Функции этих «ящиков» должны быть простыми для понимания, даже если их трудно реализовать на практике;
- Отношения между элементами системы необходимо создавать только в том случае, если эти функции взаимосвязаны. В бухгалтерском учете один из этих «черных ящиков» необходим для определения суммы валовой заработной платы работника, а другой — для определения суммы налогов. Очевидно, что между ними должна быть связь. Ведь чтобы рассчитать сумму налога, необходимо знать сумму заработной платы;
- Отношения между «черными ящиками» должны быть как можно более простыми. Благодаря этому они независимы друг от друга.
Другим фундаментальным аспектом в области структурных методов является идея иерархии. Чтобы понять сложную систему, необходимо не только выделить ее, но и обеспечить грамотную организацию полученных частей. Именно для этой цели используются иерархии.
Если задуматься, то каждая сложная система в нашем мире, будь то субатомная частица или целая галактика, обязательно выстроена в определенную иерархию. Если сложная система развивается сама по себе, он использует этот природный принцип в своей сфере деятельности.
Например, в каждой компании существует иерархия, состоящая из директоров, региональных представителей, руководителей отделов и рядовых сотрудников. Кроме того, структурные методы часто используют визуальное моделирование, которое необходимо для легкого понимания сложных структур.
Структурный анализ — это метод исследования системы. Прежде всего, создается общий обзор системы, а затем детально прорабатывается полученная информация. Наконец, исследователь получает иерархическую структуру с множеством уровней.
Функциональная декомпозиция является наиболее важным способом разграничения уровней абстракции в рамках структурного анализа. Декомпозиция — это разделение целого на части. В данном случае речь идет о разделении системы на функциональные подсистемы и на подфункции. Последняя делится на задачи, которые, в свою очередь, делятся на конкретные процедуры.
В то же время система продолжает интегрироваться, и все ее компоненты взаимосвязаны. Если система разрабатывается «снизу вверх» (от конкретных задач до всей системы), то теряется целостная картина. Кроме того, существуют трудности, связанные с описанием информационного взаимодействия отдельных элементов.
В процессе структурного анализа и проектирования используется ряд моделей, которые описывают:
- Функциональная структура системы;
- Последовательность операций, которые необходимо выполнить;
- Передача данных между функциональными процессами;
- Взаимосвязи между данными.
Этапы разработки программного обеспечения
Первая стадия работы над ПО — подготовка
Основная задача, решаемая на этом этапе, — сформулировать концепцию будущей системы на основе требований заказчика. Ориентируясь на эту концепцию, разработчики оценивают требования и осуществимость проекта. Если принято решение о привлечении подрядчика на основе конкурса, то речь идет об этапе подготовки потенциальных работников к этому конкурсу (включая подготовку всей документации).
Понятно, что нет смысла тратить время и деньги на проект, который невостребован и потенциально неосуществим. В этом случае завершение проекта является наиболее разумным решением.
Итерационная работа с заказчиком может потребоваться для корректировки концепции проекта до достижения удовлетворительного соотношения между требованиями заказчика и затратами подрядчика или до принятия решения о завершении разработки.
Если проект основан на реализуемой концепции, начинается этап разработки требований. На этом этапе определяются явные и неявные потребности клиента. Часто клиенты не имеют четкого представления о своих потребностях. В некоторых ситуациях их потребности могут не совпадать с реальной компетенцией разработчика. Потребности клиента могут иметь внутренние противоречия.
Этап разработки требований необходим для решения этих вопросов. Необходимо как можно точнее определить потребности клиента и выявить скрытые потребности. Кроме того, на этом этапе разрешаются противоречия между требованиями, создается полное техническое решение и анализируется его осуществимость.
Чтобы уточнить требования, часто необходимо скорректировать концепцию проекта. Однако в некоторых ситуациях эффективное техническое решение найти не удается, и проект впоследствии закрывается или замораживается до появления благоприятных условий.
Если решение найдено, исполнитель переходит к этапу разработки архитектуры будущей системы. Основная задача этого этапа — определить логическую и физическую архитектуру верхнего уровня, которая может полностью покрыть потребности заказчика. В процессе разработки архитектуры рассматриваются и уточняются концепции, требования и предварительные технические решения. Это снижает наиболее значимые риски.
В конце проектирования архитектуры проект следует пересмотреть, чтобы убедиться, что исполнители смогут реализовать концепции. На этапе разработки архитектуры рекомендуется удалить ненужные и громоздкие функции. Такая оптимизация часто помогает подобрать оптимальные параметры проекта.
Однако может потребоваться и значительное сокращение функциональных компонентов будущих систем. Однако даже если возникнет ситуация, когда работа над проектом будет прервана, это лучше, чем продолжение развития.
Если результаты окажутся положительными и будет сформирована благоприятная архитектура системы, можно приступать к этапу внедрения и доставки. В этом случае реализация может проходить в один или несколько этапов. Если речь идет о небольшом проекте, можно ограничиться одним шагом. Однако по мере того, как проекты становятся более масштабными, подсистемы в разрабатываемой системе становятся более зависимыми.
В таких случаях реализация разбивается на определенное количество этапов. Более того, это делается таким образом, что в конце каждого этапа разработчик получает готовые к сдаче результаты. Наиболее важные функции следует разрабатывать на ранних стадиях, а менее важные — на более поздних. Благодаря такому подходу в первую очередь устраняются наиболее опасные для системы ошибки и повышается стабильность инфраструктуры системы.
Следующий этап — опытная эксплуатация
Основная задача этого этапа — проверка качества системы в ее фактическом состоянии. Верификация в основном заключается в измерении количественных показателей, определяющих качество продукции. Сначала проверяются функциональные показатели качества, затем нефункциональные. Если в ходе проверки выявлены несоответствия, исполнитель корректирует код системы.
После того как система будет правильно настроена, ее можно вводить в эксплуатацию. Как правило, подрядчик сопровождает разработанный продукт в течение определенного периода времени (по крайней мере, в течение гарантийного срока). Если обнаружены ошибки, система корректируется. Пользователь и обслуживающий персонал заказчика должны получать поддержку в виде своевременных консультаций.
Рано или поздно система теряет свою значимость для клиента. С этого момента можно говорить об этапе вывода из эксплуатации. Однако в случае с программным обеспечением, изготавливаемым на заказ, этот этап может и не наступить. На практике заказчик полагается на свои исключительные права и может не разрешить подрядчику дальнейшую поддержку и настройку системы даже до потери ассоциации.
Конечный этап любого проекта — завершение
На этом этапе результаты анализируются, и процесс разработки программного обеспечения корректируется на основе полученного опыта. Кроме того, база знаний разработчиков пополняется новыми решениями, доказавшими свою эффективность, а также различными предупреждениями и новыми компонентами. В будущем все это должно быть применено при разработке других проектов.
Вспомогательные процессы при разработке ПО
В рамках разработки программного обеспечения можно выделить несколько вспомогательных процессов:
- Документация. Подрядчик создает документацию и руководства пользователя для созданного программного продукта, как во время, так и после разработки. Такая документация позволяет программистам понять структуру и код даже спустя долгое время после его создания. В то же время документация помогает пользователям в эксплуатации системы;
- Управление конфигурацией. Рассказывает о задаче управления набором созданных программных компонентов и версиями программного продукта;
- Обеспечение качества. Этот процесс необходим для обеспечения соответствия программного продукта предварительным требованиям разработки и стандартам исполнителя и организации-заказчика;
- Верификация. Он может обнаружить ошибки, возникающие во время разработки программного обеспечения. Верификация также может выявить несоответствия между разработанным программным обеспечением и построенной архитектурой;
- Сертификация. Необходимо проверить, чтобы полученные значения соответствовали утвержденным стандартам. Это означает, что выходные данные должны содержать ошибки, отвечающие всем требованиям и критериям;
- Совместная оценка. Этот процесс направлен на мониторинг и проверку состояния персонала и производимого программного обеспечения. Она выполняется заказчиком и подрядчиком на протяжении всего проекта;
- Аудит. Требуется самостоятельно оценивать текущее состояние, характеристики проекта, документацию и различные отчеты. Этот процесс позволяет сравнить фактическую ситуацию с контрактом и документацией, в которой указаны требования. Аудиторские проверки могут проводиться одной или двумя сторонами;
- Решение проблем. Ошибки, обнаруженные на этапе контроля и оценки, устраняются.
Факторы, влияющие на разработку ПО
Перечислены факторы, непосредственно влияющие на результат разработки программного обеспечения.
- Класс решенных задач. Определяется семантическое содержание созданной программы;
- Применяемые методики. В них изложены организационные и технические особенности реализации основных этапов разработки программного обеспечения;
- Методы и парадигмы программирования. От них зависит стиль кодирования и архитектура виртуальной машины;
- Аппаратное и системное программное обеспечение. Это виртуальные и физические ресурсы, которые позволяют использовать программное обеспечение.
Соотношение этих факторов формирует различные варианты для организации-разработчика. Давайте выделим основные компоненты этого процесса.
Основной целью разработки программного обеспечения является создание программы, которая может выполнять определенную задачу и соответствовать существующим стандартам. Проблема, которую необходимо решить, описывается набором формальных и неформальных (эмпирических) моделей. Они определяют процесс, который должна выполнить программа, и данные, используемые в этом процессе.
Модель задачи — это комплекс специальных моделей, описывающих специфические нюансы решаемой проблемы, которые отражаются в создаваемой программе.
Для описания конкретных параметров изучаемого явления необходимы специальные модели. Это позволяет сосредоточиться на конкретных характеристиках.
Созданная программа должна выполнять функции, необходимые для решения задачи в конкретном исполнителе (компьютерной системе). Для отражения его характеристик используется модель исполнителя.
Модель исполнителя — это набор конкретных моделей, описывающих конфигурацию и поведение компьютерной системы, на которой выполняется программа.
Разработанная программа выступает как отражение модели решаемой задачи в модели исполнителя. Уровень сложности программирования зависит от количества таких специализированных моделей, описывающих задачу, а также от размера и семантических различий со специализированными моделями исполнителя.
Кроме того, сложность процесса разработки зависит от требований к уровню абстракции создаваемой программы и параметров модели исполнителя, описывающих сходство с реальной архитектурой компьютера.
Модели разработки программного обеспечения
Существует несколько типов разработки программного обеспечения, основанных на различных моделях. Ниже перечислены пять наиболее распространенных из них.
Waterfall (каскадная модель, или «водопад»)
В этом случае разработка осуществляется в несколько этапов. Кроме того, каждый из последующих этапов может быть начат только после завершения предыдущего этапа. При правильном использовании водопадная модель является самой быстрой и простой; она используется с 1970-х годов.
- Простота управления. Заказчик всегда знает, чем в данный момент занят исполнитель, и может корректировать сроки и бюджет;
- Способность рассчитать стоимость проекта на ранней стадии. Каждый нюанс определяется на этапе переговоров по контракту;
- Нет необходимости привлекать очень опытных тестировщиков. Специалисты могут полагаться на подробную техническую документацию.
