Файл: Основы проектирования программ. Этапы создания программного обеспечения (Проектирование программного обеспечения).pdf

ВВЕДЕНИЕ

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

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

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

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

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

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

Для достижения поставленной цели были поставлены задачи:

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

- рассмотреть основные понятия жизненного цикла ПО.

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

---

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Формирование детального описания будущего продукта — основная задача аналитика в процессе проектирования. Ранее, на этапах сбора и анализа определялись требования пользователей к системе — мотивы, по которым они будут её использовать. Теперь нужно определить, каким именно способом требования пользователей будут удовлетворены. Только с этого момента команда разработки продукта получает право принимать проектные решения — решать, какая конкретно функциональность будет реализована (Отвечать на вопрос — «что?»).

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

- Требования к продукту уровня системы;

- Модель взаимодействия с пользователем;

- Диаграммы вариантов использования продукта;

- Потоки выполнения вариантов использования;

- Ограничения интерфейсов;

- GUI макеты;

- CLI/ API спецификации;

- Архитектура продукта;

- Техническая информация^[2].

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

Определение функциональных требований к продукту уровня системы

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

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

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

---

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

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

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

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

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

В заключении должны быть определены непосредственные интерфейсы взаимодействия с системой;

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

1.2 Надежность и качество программных средств

Надежность программного обеспечения информационных систем

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

---

- ошибки, скрытые в самой программе;

- искажение входной информации;

- неверные действия пользователя;

- неисправность аппаратных средств ИС, на которой реализуется вычислительный процесс.

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

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

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

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

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

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

Ошибки сопряжений. Группа этих ошибок вызывает неверное взаимодействие ПО с другими программами или подпрограммами, с системными программами, устройствами ЭВМ или входными данными.

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

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

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

---

Следствием появления ошибок в программе является ее отказ. Последствия отказов ПО можно разделить на:

- полное прекращение выполнения функций программы;

- кратковременное нарушение хода обработки информации в Целью ИС.

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

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

Таким система образом, основными появления показателями надежности От ПО являются:

- Указать вероятность безотказной распоряжении работы программы p(t) , сопряжений представляющая собой построены вероятность того, объектов что ошибки выяснить программы не Каскадный проявятся в интервале следовательно времени (0,t);

- вероятность хода отказа программы q(t) рассмотрены или вероятность итерациями события отказа Умение ПО до ли момента времени t;

- стараются интенсивность отказов значений программы l(t) ;

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

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

---