Преподаватель который помогает студентам и школьникам в учёбе.

Основы проектирования программ. Этапы создания программного обеспечения (Обобщенная характеристика процесса разработки программного обеспечения)

Содержание:

Введение

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

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

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

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

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

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

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

Для достижения цели необходимо решить следующие задачи:

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

Объект работы: проектирование программного обеспечения.

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

Структура работы: работа состоит из введения, 3 разделов, заключения и списка использованных источников.

Глава 1. Обобщенная характеристика процесса разработки программного обеспечения

1.1. Жизненный цикл программного обеспечения

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

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

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

Основным нормативным документом, регламентирующим жизненный цикл информационной системы, является международный стандарт ISO/IEC12207.

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

проектирование объектов данных, которые будут реализованы в базе данных;
проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
учет конкретной среды или технологии: топологии сети, конфигурации аппаратных средств, использования архитектур «файл-сервер», «клиент-сервер», параллельной обработки, распределенной обработки данных и так далее.

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

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

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

каскадная модель;
V-образная модель;
модель прототипирования;
спиральная модель;
RAD модель;
инкрементальная модель.

Одной из наиболее распространённых моделей жизненного цикла является каскадная модель. Данная модель представляет собой формальный метод разработки «сверху вниз» [3].

Жизненный цикл информационной системы по каскадной модели представлен на рис. 1.

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

$D:\YandexDisk\YandexDisk\Документы\Мои работы СТУДВОРК\OneDrive\Студворк_2_полугодние_16_17\Ludasergeewna_Разработка справочно-информационной системы предприятия\каскадная схема разработки ПП.png$

Рисунок 1 - Каскадная схема разработки АИС

Рисунок 2 - Реальный процесс разработки ПП по каскадной схеме

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

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

Рисунок 3 - Спиральная модель жизненного цикла информационной системы

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

стратегия;
анализ;
проектирование;
реализация;
тестирование;
внедрение.
эксплуатация и техническая поддержка [3].

1.2. Краткая характеристика этапов проектирования программного обеспечения

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

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

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

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

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

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

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

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

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

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

Глава 2. Проектирование программного обеспечения

2.1. Моделирование бизнес-процессов

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

Моделирование позволяет:

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

Термин «моделирование» может применяться применяется в двух значениях:

как процесс изучения модели ее функционирования;
как процесс создания модели системы.

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

анализ, оценка и внесение предложений, направленных на оптимизацию функционирования организации;
подготовка и проведение сертификации организации согласно требованиям качества ISO серии 9000:2000.
разработка АСУ организацией, проекта запуска комплексной информационной системы организации.

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

На практике моделирование бизнес-процессов организации включает два этапа - структурное и детальное. Наиболее популярная методология структурного моделирования IDEF – это методология IDEF0. Методология IDEF0 может считаться новым этапом в развитии хорошо известного графического языка описания функциональных систем SADT. IDEF0 как стандарт разработали в 1981 г. в рамках широкой программы автоматизации предприятий промышленности, называвшейся ICAM. Семейство стандартов IDEF собственное обозначение унаследовало от наименования данной программы, и его последнюю редакцию выпустил в декабре 1993 г. Национальный Институт по Стандартам и Технологиям Соединенных Штатов Америки (NIST). В Российской Федерации приняты официальные рекомендации по использованию IDEF0 [5].

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

Структурным моделированием бизнес-процесса отражается следующее:

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

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

Модели в нотации IDEF0 необходимы для высокоуровневого описания бизнеса фирмы в функциональном аспекте. Нотация DFD дает возможность отражения последовательности работ, которые выполняются по ходу процесса, и потоков сведений, циркулирующих между данными работами [1].

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

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

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

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

верхняя сторона обладает значением "Управление" (control) – определяет управляющие элементы бизнес-процесса;
левая сторона обладает значением "Вход" (input) – указывает ресурсы: которые находятся на входе в модель;
правая сторона обладает значением "Выход (output) – отображает элементы, которые являются результатом работы процесса;
нижняя сторона обладает значением "Механизм" (mechanism) – показывает объекты, которые задействованы в выполнении бизнес-процесса.

Дуга (arrow) отображает компонент системы, который обрабатывает функциональный блок или иным образом влияет на функцию, представленную этим функциональным блоком. Интерфейсные дуги нередко называются потоками или стрелками [5].

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

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

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

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

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

Выход (output) - информация или материальный объект, которые производит деятельность. Каждая активность должна обладать хотя бы одной стрелкой выхода. Работа без результата бессмысленна и ее не нужно моделировать.

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

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

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

Декомпозиция (decomposition) – ключевое понятие стандарта IDEF0. Принцип декомпозиции применяют в процессе разбиения сложного процесса на составляющие его функции. Декомпозиция дает возможность постепенного и структурированного представления модели системы в форме иерархической структуры отдельных диаграмм, за счет чего она становится менее перегруженной, а также легко усваиваемой [7].

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

Модель в методологии IDEF0 является совокупностью взаимосвязанных и иерархически упорядоченных диаграмм. Каждая диаграмма – это единица описания системы, она располагается на отдельном листе. В модели могут быть 4 типа диаграмм:

Контекстная диаграмма, представляющая всю систему в качестве одного блока и показывающая контекст системы, то есть связь системы с внешним миром. Модель может обладать только одной контекстной диаграммой.
Диаграммы декомпозиции, получаемые после разбиения контекстной диаграммы на отдельные активности. Данный процесс называют функциональной декомпозицией, а диаграммы, которые получились после декомпозиции, называют диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводят декомпозицию каждой получившейся диаграммы и т.п.
Диаграммы дерева узлов отражают иерархическую зависимость работ. Т. е., в форме дерева отражается, какие активности были получены после декомпозиции каждой активности.
Диаграммы только для экспозиции (FEO - for exposition only). Их построение осуществляется с целью отображения альтернативной точки зрения, с целью хранения старых версий. FEO является обычной картинкой. Суть в том, что альтернативные варианты декомпозиции не поддерживает методология. Если требуется каким-либо образом сохранить альтернативный вариант декомпозиции, то используется диаграмма только для экспозиции.

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

Методология IDEF0 предполагает, что модель – это не просто совокупность диаграмм, а содержит все необходимые данные о моделируемой области. Данные о модели задаются в свойствах модели [18].

В общих свойствах (general) приводится указание имени модели, названия проекта, автора модели, временных рамок модели (Time Frame) - AS-IS и ТО-ВЕ. Как правило, сначала создается модель существующей организации работы - AS-IS (как есть). Изучение функциональной модели дает возможность понимания того, где можно выявить самые слабые места, в чем будут заключаться преимущества новых бизнес-процессов, а также того, насколько глубокие изменения произойдут в существующей структуре организации бизнеса. Детализация бизнес-процессов дает возможность выявления недостатков организации даже там, где функциональность может показаться очевидной. Выявленные в модели AS-IS недостатки могут быть исправлены в процессе создания модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. В некоторых случаях текущая AS-IS и будущая ТО-ВЕ модели имеют сильные отличия, поэтому переход от начального к конечному состоянию неочевиден. Здесь требуется третья модель, которая описывает процесс перехода от начального к конечному состоянию системы, так как данный переход тоже является бизнес-процессом.

Для придания диаграммам удобочитаемости, в стандарте IDEF0 принято ограничения сложности: на диаграмме могут быть 3-6 активностей, вместе с тем колво подходящих к одной активности и выходящих из одной активности дуг предполагается до 4.

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

Каждая активность модели нумеруется. Номер включает в себя префикс и число. Может использоваться префикс любой длины, но, как правило, используется префикс А. Контекстная активность обладает номером А0. Активности, которые получили после декомпозиции контекстной активности номера А1, А2, A3 и т. д. У работ декомпозиции нижнего уровня есть номер родительской активности, а также очередной порядковый номер, к примеру у активностей декомпозиции A3 будут номера А31, А32, А33, А34 и т. п. Активности формируют иерархию, в которой каждая активность может обладать одной родительской и несколькими дочерними работами, формируя дерево. Это дерево называется деревом узлов, а вышеописанная нумерация - нумерацией по узлам [7].

Диаграммы IDEF0 обладают двойной нумерацией. Прежде всего, диаграммы обладают номерами по узлу. Контекстная диаграмма всегда обладает номером А-0, декомпозиция контекстной диаграммы - номером А0, другие диаграммы декомпозиции - номерами по соответствующему узлу (к примеру, Al, A2, А21, А213 и т. д.).

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

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

Стрелки, которые соединяют активности на диаграмме, называют внутренними. В IDEF0 отличают 5 типов связей работ.

Связь по входу (output-input), при которой стрелка выхода вышестоящего блока направляется на вход нижестоящей работы.

Связь по управлению (output-control), при которой выход вышестоящего блока направляют на управление нижестоящего блока. Связь по управлению отражает доминирование вышестоящей работы.

Обратная связь по входу (output-input feedback), при которой выход нижестоящей активности направляется на вход вышестоящей. Такую связь, как правило, используют в целях описания циклов.

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

Связь выход-механизм (output-mechanism), при которой выход одной работы направляют на механизм другой. Данную взаимосвязь используют реже остальных, она отражает, что одна активность подготавливает ресурсы, требуемые для выполнения другой активности [1].

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

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

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

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

Следующей рассмотренной методологией является методология DFD. Цель методологии - построить модель рассматриваемой системы в форме диаграммы потоков данных (Data Flow Diagram - DFD). Диаграммы потоков данных используются, в первую очередь, для описания документооборота, а также обработки информации, но допускают и представление иных объектов.

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

потоки данных,
процессы (работы) преобразования входных потоков данных в выходные,
внешние сущности,
накопители данных (хранилища).

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

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

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

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

Помимо ключевых элементов, в состав DFD входят словари данных, а также миниспецификации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектуру CASE-средства можно представить в виде совокупности шести компонентов (рис.4): репозиторий данных, графический редактор диаграмм, верификатор диаграмм, генератор отчётов, администратор проекта, сервис.

Рисунок 4 – Компоненты CASE-средства

При рассмотрении разнообразных CASE-систем можно выделить CASE-системы двух поколений:

1. Первое поколение. Обеспечивает:

поддержку графических моделей;
проектирование словарей данных;
проектирование спецификаций;
проектирование экранных редакторов.

2. Второе поколение. Обеспечивает:

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

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

В качестве примеров можно выделить следующие популярные CASE-средства:

ARIS Express;
CA ERwin Data Modeler;
Visual Paradigm for UML;
CA ERwin Process Modeler.

Программа ARIS Express принадлежит к семейству средств моделирования ARIS компании IDS Scheer.

CA ERwin Data Modeling представляет собой среду моделирования данных. CA ERrwin Data Modeler позволяет проектировать структуру баз данных в нотациях IDEF1x, IE и Dimensional, генерировать SQL-код разработанной базы данных, осуществлять прямое и обратное проектирование, составлять различные отчёты.

Visual Paradigm for UML относится к профессиональным инструментам работы со стандартом UML. При помощи встроенного функционала данный пакет способен поддерживать весь рабочий цикл программы: анализ, ориентированный на объекты, дизайн, ориентированный на объекты, конструкция, тестирование и разработка.

CA ERwin Process Modeler является инструментом позволяющим моделировать, анализировать, документировать и оптимизировать бизнес-процессы. Данный продукт поддерживает такие нотации как: IDEF-0, IDEF0, IDEF3, DFD, FEO, Swimlane [5].

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

2.2. Проектирование базы данных

Проектируемая программа определяет хранение определенной информации. Лучшим вариантом хранения данных является использование реляционных баз данных. Реляционная база данных – база данных, основывающаяся на реляционной модели. Слово «реляционный» произошло от английского слова «relation» (отношение). Для того, чтобы работать с реляционными базами данных, как правило, применяют реляционные системы управления БД. Первым, кто стал инициатором применения таких БД еще в 1979 г., стал профессор Кодд, который работал в корпорации IBM [11].

Реляционная модель организует данные в виде двумерных таблиц.

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

Больше всего распространились серверы реляционных БД, которые базируются на клиент-серверной архитектуре. Данными серверами обеспечивается устойчивая работа с базами данных сразу множества клиентов (ими могут являться десятки, сотни, а также тысячи и млн. клиентов – все зависимо от применяемого оборудования и ПО). Помимо того, реляционная модель данных реализуется так называемыми настольными базами данных, к примеру, dBASE, FoxPro, а также Clarion и Paradox, Access. Почти каждая ведущая настольная БД на данный момент поддерживает возможность работать как клиенты серверов БД с помощью технологий ODBC, а также BDE, ADO и других.

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

В таблице реляционной БД не могут содержаться повторяющиеся записи (строки). Данное требование следует из теории множеств. Наименьший набор полей, дающий возможность отличия записи от любой иной записи — ключ. Все значения ключа в рамках таблицы должны являться уникальными. Каждая таблица должна обладать хотя бы одним ключом, что прямо вытекает из того, что в таблице не могут содержаться повторяющиеся записи. Ключи таблицы могут включать одно поле – эти ключи носят название атомарных или простых ключей. Ключи могут включать несколько полей, то есть составные ключи. Таблица БД может обладать одним ключом или несколькими ключами. Один из ключей назначают как первичный ключ, а остальные — потенциальные (в теории реляционных БД) либо альтернативные (в определенных реализациях отдельных БД) [10].

Нередко применяют суррогатный первичный ключ – ключ, включающий поле (или поля), не несущие сведения из предметной сферы, а выступают как замена (суррогат) для естественных (натуральных) первичных ключей. Как суррогатные ключи зачастую применяются счетчики (генераторы, последовательности) autoincrement либо глобально–уникальные идентификаторы (GUID). В правильности созданная структура БД должна отвечать специальным правилам, основанным на теории отношений и называющимся как нормальные формы [4].

Нормализация – это процесс преобразования базы данных, к виду, который отвечает нормальным формам и обеспечивает минимальную избыточность. Цель нормализации – защита базы данных от структурных и логических проблем, являющимися аномалиями данных. К примеру, если есть несколько одинаковых записей в таблице, то в этом случае есть риск нарушения целостности данных при последующем обновлении таблицы. Таблица, прошедшая нормализацию, меньше подвергается этим проблемам, поскольку структура такой таблицы определяет связи между данными, таким образом исключается необходимость существования записей с информацией, которая повторяется. Избыточность можно устранить при помощи разбиения отношений (таблиц) таким образом, чтобы в каждом отношении хранились только первичные факты (факты, которые не выводятся из других хранимых фактов). Таким образом, нормализация не ставит цель уменьшения или увеличения производительности работы или же уменьшения, или увеличения объёма базы данных. Конечная цель нормализации – уменьшение потенциальной противоречивости, хранимой в БД информации. Нормализация применима к таблице, которая представляет собой правильное отношение.

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

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

Также отметим, что концептуальное проектирование – это сбор, анализ и корректировка требований к информации, состоящей из ряда положений:

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

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

Для изображения концептуальной модели БД в виде графической схемы разработан ряд специальных языков. Так, в 1976 г. Питер Пин-Шэн Чен предложил для этих целей специальный язык диаграмм «сущность-связь» (ER-диаграммы).

Основными конструктивными элементами модели «сущность-связь» (entity-relationship model, ER-model) являются сущности, их свойства (атрибуты) и связи между сущностями.

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

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

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

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

Основными понятиями ER–модели являются сущность, связь и атрибут. Сущность – это реальный или представляемый объект, информация о котором должна быть сохранена и доступна. В диаграммах ER–модели сущность представлена в виде прямоугольника, который содержит имя сущности. Каждый экземпляр сущности должен отличаться от любого другого экземпляра той же сущности. Связь представляет собой ассоциацию, которая представлена в графическом виде и установлена между двумя сущностями. Каждая связь имеет два конца. На каждом обязательно указывается имя и степень конца связи и обязательность связи. В качестве атрибута сущности выступает деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Запись имен атрибутов производится в прямоугольник, изображающий сущность, под именем сущности и изображающийся маленькими буквами [6].

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

Глава 3. Тестирование и отладка программного обеспечения

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

Одним из устоявшихся способов контроля качества является тестирование. Тестирование ПО (Software testing) — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. Тестирование включает следующие этапы (рис. 5):

планирование работ (Test Management);
проектирование тестов путем ручной разработки или автоматической генерации (Test Design);
выполнение тестирования с получением результатов (Test Execution);
анализ полученных результатов выполнения с целью оценки качества ПО (Test Analysis).

Рисунок 5 – Последовательность тестирования ПО

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

На каждом этапе жизненного цикла информационной системы должны выполняться верификация и валидация проекта. Верификация (Veriﬁcation) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Валидация (Validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [9].

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

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

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

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

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

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

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

Предусловия (PreConditions) — шаги, которые переводят систему в состояние, пригодном для проведения проверки.
Описание теста (Description) — шаги, которые переводят систему из стояния в состояние. На основании полученного результата делается вывод о соответствии реализации заявленным требованиям.
Постусловия (PostConditions) — шаги, которые переводят систему в изначальное положение.

Рисунок 6 – Базовые части теста

План тестирования (Test plan) — это основной документ этапа тестирования, который описывает работы по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения [14].

Основные вопросы, которые план тестирования должен раскрыть (рис. 7):

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

Рисунок 7 – План тестирования

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

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

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

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

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

Test Cases — это набор условий, при которых тестировщик будет определять, удовлетворяется ли заранее определённое требование. Чтобы определить, что требование полностью выполняется, может потребоваться много вариантов тестирования. Часто варианты тестирования группируют в тестовые наборы. UnitTest - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок [9].

Заключение

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

При достижении цели были решены следующие задачи:

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

Список использованной литературы

Верников Г. Основы IDEF3 [Электронный ресурс] / Г. Верников. – Режим доступа: http://www.cfin.ru/ vernikov/idef/idef3.shtml (дата обращения: 08.07.2020).
Горбаченко В. И. Проектирование информационных систем с CAERwin Modeling Suite 7.3: учебное пособие / В. И. Горбаченко, Г. Ф. Убиенных, Г. В. Бобрышева – Пенза: Изд-во ПГУ, 2012. – 154 с
Информационные технологии. Процессы жизненного цикла программных средств: СТБ ИСО/МЭК 12207-2003 [Электронный ресурс]. – Режим доступа: www.nbrb.by/payment/TechCodePract/pdf/tcp_135_2008.pdf. – Дата доступа: 20.07.2020.
Катаев М. Ю. Указания по учебно-исследовательской работе для бакалавров по направлению 230100.62 «Информатика и вычислительная техника». — Томск: Факультет дистанционного обучения, ТУСУР, 2014. — 283 с.
Козодоев А. Использование методик моделирования данных IDEF1X и IE в программном средстве AllFusion ERwin Data Modeler компании Computer Associates [Электронный ресурс] / А. Козодоев // Режим доступа: http://www.interface.ru/ca/MethodsDM_ERwin.htm (дата обращения: 21.07.2020).
Коцюба И. Ю. Основы проектирования информационных систем. Учебное пособие / И. Ю. Коцюба, А. В. Чунаев, А. Н. Шиков // СПб: Университет ИТМО, 2015. – 206 с.
Людоговский А. Моделирование бизнес-процессов [Электронный ресурс] / А. Людоговский // Инф. портал «Script coding». - Режим доступа: http://www.script-coding.com/bp.htm l (дата обращения: 20.07.2020).
Ляндау Ю. В. Концепции моделирования бизнес-процессов / Ю. В. Ляндау, М. А. Пономарев // Вестник ИжГТУ. 2013. № 2(58) – С. 83 – 87.
Методологии разработки программного обеспечения [Электронный ресурс]: электронный журнал «КомпьютерПресс» №7 за 2003. – Режим доступа: http://compress.ru/article.aspx?id=11321 (дата обращения: 19.07.2020).
Проектирование интерфейсов пользователя: пособие для студентов специальности 1-47 01 02 «Дизайн электронных и веб-изданий» / Т. П. Брусенцова, Т. В. Кишкурно. – Минск: БГТУ, 2019. – 172 с.
Проектирование программного обеспечения: учеб. пособие / Т. В. Черушева. – Пенза: Изд-во ПГУ, 2014. – 172 с.
Репин В. В. Процессный подход к управлению. Моделирование бизнес-процессов / В. В. Репин, В. Г. Елиферов - М.: Манн, Иванов и Фербер, 2013. - 544 с.
Смирнова Г. Н. Проектирование экономических информационных систем (часть 1) / Г. Н. Смирнова, Ю. Ф. Тельнов - М.: МЭСИ, 2004. – 223 с.
Тестирование ПО [Электронный ресурс]. – Режим доступа: www.tester.com.ua. – Дата доступа: 20.07.2020.
Технология программирования: учебник / Г. С. Иванова. — 3-е изд., стер. — Москва: КНОРУС, 2018. — 336 с.
Цуканова О. А. Методология и инструментарий моделирования бизнес-процессов: учебное пособие / О. А. Цуканова. - СПб.: Университет ИТМО, 2015. - 100 с.
Этапы разработки программного обеспечения : [Электронный ресурс] // Режим доступа: https://ru.intechcore.com/stages-software-development/ (дата обращения: 22.07.2020).
Component Object Model [Electronic resource]. – Mode of access: www.microsoft.com/tech/COM. asp. – Date of access: 20.07.2020.
Consulting [Электронный ресурс] Статья «Основные методологии обследования организаций. Стандарт IDEF0» - Режим доступа: http://consulting.ru/econs_wp_4235 (дата обращения: 15.07.2020).