ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 16.10.2024
Просмотров: 5
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Основные этапы жизненного цикла ПО (лекция по программной инженерии)
Одним из основных понятий программной инженерии является понятие жизненного цикла ПО (software life cycle). Жизненный цикл ПО это период времени с момента принятия решения о необходимости создания ПО до момента его полного изъятия из эксплуатации. Жизненный цикл ПО состоит из определенных этапов. В соответствии с различными международными и национальными стандартами, регламентирующими этапы и процессы жизненного цикла ПО эти этапы могут носить различные названия. Если сложить и скомпоновать все этапы более плотно, что можно получить следующие этапы:
·Подготовка (сбор требований)
·Планирование (оценка, расписание)
·Моделирование (анализ требований, проектирование)
·Конструирование (кодирование, интеграция, тестирование)
·Развертывание (поставка, внедрение и сопровождение)
Заметим, что часто под жизненным циклом понимают непосредственно процесс разработки в этом случае выделают такие этапы как: анализ требования. проектирование, кодирование, тестирование.
1. Подготовка (сбор требований, анализ бизнес-процессов, разработка концепции, постановка задачи). На этапе подготовки осуществляется активное взаимодействие между фирмой-разработчиком ПО и фирмой-заказчиком, заключается контракт, собираются и формулируются требования, определяющие характеристики и функции разрабатываемого ПО.
При разработке ПО этот этап исключительно важен. Ошибки, допущенные на этом этапе, даже при условии безупречного выполнения последующих этапов могут привести к тому, что разработанный программный продукт не будет соответствовать требованиям практики, сферы его применения.
Для создания конкурентоспособных продуктов в ходе выполнения этого этапа должны быть получены четкие ответы на следующие вопросы:
-Что должна делать программа?
-В чем состоят реальные проблемы, разрешению которых она должна способствовать?
-Что представляют собой входные данные?
-Какими должны быть выходные данные?
Ответы на вопросы этого этапа должны быть зафиксированы в документе, называемым «задание на разработку», который должен быть подписан представителями заказчика и исполнителя. Этот документ обычно содержит следующие укрупненные разделы:
-общая характеристика задачи;
-описание входных данных;
-описание выходных данных;
-описание алгоритмов решения задачи;
-источники разработки.
В разделе «Общая характеристика задачи» должно как минимум три подраздела: назначение системы, экономическая эффективность и участники проекта.
Назначение программы — это четкое представление о том, что зачем создается данная программа (это действительно необходимо подробно описать, так как часто заказчик и разработчик вкладывают разный смысл в одни и те же понятия).
В разделе «экономическая эффективность» нужно определить, насколько внедрение данной программы будет способствовать увеличению экономической эффективности конкретной фирмы, то есть насколько сократятся непродуктивные затраты пользователя после внедрения данной программы. Иногда экономическую эффективность можно выразить в денежном эквиваленте (например, суммированием затрат сотрудников, сокращенных в результате внедрения новой программы). Но чаще всего используют такие показатели эффективности как снижение времени на решение задач, уменьшение количества сотрудников, привлекаемых для решения задач, снижение накладных расходов. Чем полнее и ярче будет подана предполагаемая экономическая эффективность, тем легче будет продать программу.
В разделе «Участники проекта» должны быть перечислены все подразделения заказчика, которые участвуют в решении задачи до и после внедрения программы. Желательно также указать графическое представление подразделений и связей между ними. Это очень облегчит дальнейший этап - определение спецификаций.
В разделе «Входные данные» должны быть подробно описаны все документы, являющиеся источником данных для решения задачи. Учитывая структуру подразделений, участвующих в проекте нужно обойти их и собрать у сотрудников организации образцы всех таких документов. Если данные не документированы (например, телефонный звонок) сотрудник должен так или иначе дать их формальное описание. Пропуск хотя бы одного документа на данном этапе может привести к серьезным проблемам на этапе внедрения. Для каждого документа должна быть получена информация о его структуре, о том, откуда он поступает и с какой частотой. Если же программа разрабатывается не под конкретного заказчика и предназначена для автоматизации каких-либо
реальных производственных задач, то для описания входных данных необходимо обратиться к экспертам. Причем желательно привлекать экспертов с реальных предприятий. Программы, которые проектируются на основе книжных описаний конкретной задачи, плохо продаются.
Аналогично должны быть описаны выходные данные. Причем следует указать необходимость наличия физической копии. Например, некоторые данные можно хранить в базе данных и просматривать на экране, а другие нужно в обязательном порядке распечатывать.
В разделе «Алгоритмы решения задачи» должны быть описаны не алгоритмы, используемые в разрабатываемой программе, а алгоритмы, которые используются для решения задачи на момент обследования. Возможно, это уже используемая устаревшая программа или ручная технология. В процессе обследования может быть выявлено, что некоторые документы, имеющие отношение к разрабатываемой программе, являются выходными для одного отдела и входными для другого. Именно такие документы должны «исчезнуть» в первую очередь после того, как программ будет внедрена. Необходимо абсолютно четко понять существующий алгоритм формирования выходной информации на основе входной. Для выяснения этого алгоритма не надо стесняться быть нудным и надоедливым.
В разделе «Источники разработки» должна содержаться информация о том, откуда получены сведения, на основе которых описаны входные, выходные данные и алгоритмы решения задачи: фамилии и должности сотрудников, желательно даты бесед, законы, номера внутренних инструкция.
2. Планирование. На этапе планирования определяется
· объем работ,
· риск работ,
· необходимые трудозатраты,
· рабочие задачи
· план-график работ
3. Моделирование. Этап моделирования состоит из двух подэтапов: анализ требований и проектирование. Результат этих этапов обычно фиксируется в виде диаграмм и графических схем в документе, называемом «Техническое задание».
В определенной степени анализ требований можно рассматривать как формулировку выводов, следующих из результатов этапа сбора требования. На этом этапе требования анализируются и формулируются в виде ряда строгих спецификаций, явно определяющих функции, интерфейс и рабочие характеристики разрабатываемого ПО. В число таких характеристик могут входить скорость выполнения, объем потребляемой памяти, гибкость применения и др.
Данный этап должен завершиться составлением и подписанием документа «Техническое задание», в котором, как правило, содержатся следующие разделы
-название системы (полное и сокращенное название, версию);
-цели создания;
-характеристика области применения;
-перечень автоматизируемых функций и требования к системе в целом (требования к соблюдению режимов безопасности, функциональной согласованности, к интерфейсу, степень взаимодействия с другими программами);
-информационная база (все используемые файлы, их структура, организация взаимодействия пользователя с данными);
-программное обеспечение (интегрированные среды программирования, СУБД);
-аппаратное обеспечение (обычно указывается нижние пределы характеристик аппаратного обеспечения, но следует указать и оптимальную конфигурацию);
-график работ.
-Устав проекта
В некоторых разделах техническое задание похоже на задание на разработку, с тем отличием, что в техническом задании указывается не то, как данные обрабатываются в настоящей момент, а как они должны обрабатываться создаваемой программой.
Основная задача проектирования состоит в разработки архитектуры ПО. Архитектура ПО определяет структуру ПС (задает ее разбиение на компоненты, связи между ними, их интерфейсы), а также основные принципы проектирования и развития системы.
Современные программы часто разрабатываются на основе модульной технологии. Модуль — это физически и логически независимая часть ПС. Физическая независимость подразумевает, что каждый модуль описан в отдельном файле. Логическая независимость подразумевает, что модуль решает логически объединенную между собой группу задач.
В качестве модульной структуры программы принято использовать древовидную структуру, называемую модульное дерево ПС. В вершинах такого дерева размещаются программные модули, а стрелки указывают их подчиненность. В тексте модуля, из которого исходит стрелка, должна быть ссылка на тот модуль, на который она показывает. Другими словами, каждый модуль может обращаться только к подчиненным ему модулям.
На этапе проектирования необходимо описать модульное дерево, то есть количество модулей, их подчиненность, для каждого модуля определить функциональность. Для каждого модуля должна быть составлено собственное описание – спецификация. Сложно ввести стандарт на степень детализации спецификации модуля, но обычно придерживаются следующих рекомендаций. В спецификации модуля приводится только интерфейсная часть. Можно высказать пожелания к общим типам данных и классов объектов, которые могут быть доступны из других модулей. Если описываются спецификации на подпрограммы, в них указывает назначение подпрограммы, а также количество и тип формальных параметров, их порядок, тип возвращаемого значения для функции. Кроме того, следует указать изменение изображение на экране или вывод печатного документа, который может произойти в результате вызова подпрограммы.
Существуют различные методы разработки структуры программы. В процессе ее создания модульная структура может по-разному формироваться и использоваться для определения порядка кодирования. К двум основным методам разработки структуры программы относят метод восходящей разработки («снизу вверх») и нисходящей разработки («сверху вниз»).
Существуют различные методы разработки структуры программы. В процессе ее создания модульная структура (т.е. структура модулей – компонент программы) может по-разному формироваться и использоваться для определения порядка кодирования. К двум основным методам разработки структуры программы относят метод восходящей разработки («снизу вверх») и нисходящей разработки («сверху вниз»).
Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева путем описания всех режимов работы программы. Затем поочередно программируются модули, начиная с самого нижнего уровня. Для каждого программируемого в данный момент модуля должны быть заранее созданы те модули, к которым он может обращаться. После того как все модули созданы, производится их поочередное тестирование и отладка в том же порядке, в каком велось их программирование. При восходящем методе разработки модулей нижнего уровня глобальная информация для них может быть еще не окончательно определена, поэтому приходится перепрограммировать их позже, если при программировании других модулей производилось существенное уточнение глобальной информации.
Метод нисходящей разработки заключается в следующем. Так же, как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно кодируются модули, начиная с самого верхнего уровня (головного модуля). К программированию очередного модуля переходят только после того, как запрограммирован модуль, который непосредственно к нему обращается. После того, как все модули описаны, производится их поочередное тестирование и отладка в том же нисходящем порядке. При этом те модули, к которым обращается данный, заменяют заглушками. Каждый модуль-заглушка представляется простым программным фрагментом, основная задача которого - сигнализировать о факте обращения к имитируемому модулю. После завершения тестирования и отладки модуля переходят к тестированию одного из модулей, которые пока представлены заглушками. При этом модуль-заглушку заменяют «полным» модулем, добавляя заглушки в те модули, к которым он обращается в ходе тестирования. Каждый модуль на момент обращения к нему при тестировании имеет «естественное» состояние данных. Таким образом, нисходящий метод позволяет заменить большой объем «отладочного» программирования программированием достаточно простых заглушек используемых модулей. Такой порядок разработки дает возможность своевременно формировать все необходимые глобальные переменные. У данного метода также есть недостаток – необходимость абстрагироваться от базовых возможностей используемого языка, придумывая абстрактные операции, которые позже необходимо реализовывать в модулях нижнего уровня.