Разработка программного обеспечения создание программ программирование. Процесс разработки программного обеспечения. Средства тестирования программ

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

1. Терминология

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

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

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

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

С учетом данного определения термин «Разработка программ» будет звучать следующим образом:

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

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

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

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

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

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

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

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

Проектирование приложения.
Реализация программного кода приложения.
Тестирование приложения.

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

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

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

2.1 Средства проектирования приложений

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

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

Результатом проектирования обычно является «Эскизный проект» (Software Design Document) или «Технический проект» (Software Architecture Document). Задача «Анализ требований» обычно выполняется с использованием методов системологии (анализа и синтеза) с учетом экспертного опыта проектировщика. Результатом анализа обычно является содержательная или формализованная модель процесса функционирования программы. В зависимости от сложности процесса для построения данных моделей могут быть применены различные методы и вспомогательные средства. В общем случае для описания моделей обычно применяются следующие нотации (в скобках приведены программные средства, которые могут быть использованы для получения моделей):

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

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

BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
Блок-схемы (Vision 2003 и многие другие).
ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
макеты, мат-модели и т.д.

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

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

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

Как мы руководствуемся безопасным развитием?

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

Никакой компонент не является надежным, пока не будет доказано иное

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

Функциональное программирование;
Структурное программирование;
Императивное программирование;
Логическое программирование;
Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование).

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

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

Скрыть сложные механизмы аутентификации для обхода

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

диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).

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

Авторизовать, в дополнение к аутентификации

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

Отдельные данные из инструкций по управлению

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

Проверять все данные явно

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

2.2 Средства реализации программного кода

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

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

Правильно использовать криптографию

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

языки программирования (C++,Си, Java, C#, php и многие другие);
средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.)
средства управления версиями программного кода (cvs, svn, VSS).
средства получения исполняемого кода (MS Visual Studio, gcc и многие другие).
средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие).
отладчики (MS Visual Studio, gdb и т.д.).

2.3 Средства тестирования программ

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

Всегда учитывайте пользователей системы

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

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

Тестирование на отказ и восстановление.
Функциональное тестирование.
Тестирование безопасности.
Тестирование взаимодействия.
Тестирование процесса установки.
Тестирование удобства пользования.
Конфигурационное тестирование.
Нагрузочное тестирование.

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

Интеграция компонентов изменяет поверхность атаки

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

средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic и т.д.);
средства для тестирования функциональности (TEST – Parasoft, QACenter – Compuware, Borland SilkTest и т.д.);
средства для тестирования производительности (QACenter Performance – Compuware и т.д).

3. Заключение

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

Также смотрите :

Аннотация: Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии. Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.

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

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

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

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

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

Каждый виток имеет следующую структуру (секторы):

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

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

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

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