12
называемый объектный код, который далее с помощью редактора связи
формирует загрузочный модуль, что и будет пригодным для запуска на ПК.
Такой процесс осуществляется, к примеру, при написании программ на языке
Фортран.
В иных языках высокого уровня (на Бейсике) трансляция начального
кода в выполняемый происходит последовательно по каждой команде
(оператором).
Такая трансляция будет осуществляться программой-
интерпретатором.[30]
Созданная программа должна проходить проверку на пригодность к
применению с помощью отладчиков программ. Он также позволяет
отслеживать последовательную реализацию программы, выявлять места и
типы ошибок в ПО, давать комментарии.
Разные интегрированные среды программирования в себя включают
весь спектр средств для комплексного применения на всех этапах разработки
программы.
Главное назначение такого инструментария в том, чтоб с его
использованием повысить эффективность и производительность труда
программистов.
Стоит отметить, что по способу использования и распространения
на:[35]
– несвободное;
– открытое;
– свободное.
К примеру, свободное ПО может распространяться, устанавливаться,
использоваться на разных компьютерах дома, в школах, вузах, офисах, а
также государственных и коммерческих учреждениях без каких-либо
ограничений на применение.
13
1.2. Понятие жизненного цикла ПО
Жизненным циклом (сокращенно ЖЦ) ПО называют период времени
от момента появления непосредственно идеи создания программного
обеспечения и до момента завершения его функционирования и поддержки
разработчиком.
Состав типовых процессов ЖЦ регламентируется международным
стандартом ISO/IEC 12307: 1995.
Указанный стандарт описывает непосредственно структуру ЖЦ ПО и
его типовые процессы. [40]
Процесс ЖЦ определяется как множество взаимосвязанных действий,
что могут преобразовать некоторые начальные данные в результат.
На рисунке 2 представлены процессы ЖЦ по указанному стандарту.
Все процессы характеризуются определенными задачами их решения, а
также начальными данными и полученными результатами.
Рисунок 2 – Схема процессов ЖЦ
14
Процесс разработки программ в соответствии с указанным выше
стандартом предусматривает разные действия и задачи, которые нужно
выполнить разработчиком, и охватывает разные работы по созданию ПО и
его составных компонентов (модулей) в соответствии с указанными
заказчиком требованиями, при этом включая оформление всей
эксплуатационной и проектной непосредственную подготовку документации,
материалов, необходимых для выполнения проверки работоспособности,
соответствия качества ПО, материалов для обучения персонала и прочих
составных частей.
По выше приведенному стандарту процесс разработки ПО в себя
включает такие действия:[40]
– работа по подготовке к разработке ПО: выбор модели ЖЦ,
стандартов, методов, средств разработки;
– анализ требований к проектируемой системе – определение ее
возможностей по функционированию, пользовательских требований,
требований к внешним пользовательским интерфейсам, безопасности и
надежности и т.п.;
– проектирование архитектуры ПО – определение перечня
необходимого аппаратного оборудования, ПО и операций, что выполняются
обслуживающим персоналом;
– реализация анализа требований к ПО – определение
функциональных возможностей, также включая характеристики уровня
производительности, среды для функционирования компонентов, а также
внешних интерфейсов, надежности, эргономических требований,
безопасности, требований к применяемым данным, приемке, установке,
пользовательской документации и сопровождению;
– проектирование архитектуры ПО – это определение структуры
ПО, интерфейсов, компонентов, разработку предварительных версий
пользовательской документации, требований к тестам, а также плана
интеграции ПО в существующую корпоративную систему;
15
– детальное проектирование ПО – это подробное описание разных
компонентов ПО, интерфейсов между ними, выполнение обновления
пользовательской документации, а также документирование и разработка
требований к плану тестирования и тестам компонентов ПО, обновление
плана для интеграции компонентов;
– кодирование, тестирование ПО – разработка и документирование
каждого с планируемых компонентов, а также всей совокупности тестовых
процедур для их непосредственного тестирования, а также тестирование
компонентов, обновления пользовательской документации, обновления
плана интеграции ПО;
– интеграцию ПО – процесс сборки программных компонентов по
плану интеграции и тестирование ПО на соответствие разным
квалификационным требованиям, что представляют собой набор критериев,
которые необходимо выполнить для квалификации программного продукта,
как соответствующего своим спецификациям или готовым к использованию
в указанных условиях эксплуатации;
– выполнение квалификационного тестирования ПО –
тестирование ПО в присутствии заказчика, демонстрируя его соответствия
установленным требованиям и готовности для введения в эксплуатацию; при
этом проверяется полнота и готовность документации;
– интеграцию системы – практическую сборку всех модулей
системы, включая ПО и оборудование;
– тестирование системы на соответствие всем требованиям к ней, а
также проверка полноты документации и ее оформления;
– установку ПО – установку ПО на оборудовании заказчика,
проверку его общей работоспособности;[4]
– приемку заказчиком ПО - оценку результатов тестирования ПО и
системы в целом, а также документирование результатов для оценки
совместно с заказчиками, окончательную передачу ПО заказчику.
16
Все указанные действия можно также сгруппировать, при этом условно
выделив основные этапы разработки ПО [8] (в скобках будут указаны
соответствующие этапы разработки по ГОСТу 19.132-77 «Стадии разработки
ПО»):
– постановка задачи (этап «Техническое задание»);
– выполнение анализа требований и разработки спецификаций
(этап «Эскизный проект»);
– проектирование (этап «Технический проект»);
– непосредственная реализация (этап «Рабочий проект»).
Традиционно вся разработка включала этап сопровождения (началу
указанного этапа соответствует этап «Внедрение»). Но по международному
стандарту по изменениях, произошедшими в индустрии создания
программного обеспечения, указанный процесс теперь рассматривается
только отдельно.
Условность в выделении этапов связана также с тем, что практически
на любом этапе есть возможность принятия решений, которые также
потребуют пересмотра решений, что приняты ранее.
Под постановкой задачи четко понимается процесс формулирования
назначение ПО и определения основных требований к нему. Каждое с таких
требований представляет собой описание самого необходимого и желаемого
свойства ПО. При чем различают такие виды требований:
– функциональные;
– эксплуатационные.
Требования к ПО, которые используют прототипы, обычно
определяются по аналогии, при этом учитывая структуру уже
существующего ПО. Для формулирования требований для ПО, не имеющему
аналогов, необходимо провести иногда специальные исследования, что
называется предпроектными.
17
Также в процессе таких исследований часто определяют разрешимость
задачи, разрабатывают методы для ее решения (если они являются новыми) и
устанавливают существенные характеристики разрабатываемого ПО.
Анализ требований или определение спецификаций. Под
спецификациями понимают точное формализованное функций и
ограничений для разрабатываемого ПО. По аналогии с требованиями
различают эксплуатационные и функциональные спецификации.
Совокупность спецификаций может представлять собой общую логическую
модель для проектируемого ПО.
Основной задачей проектирования является определение самых
подробных спецификаций для разрабатываемого ПО. Процесс
проектирования сложного ПО обычно включает в себя:
– проектирование общей структуры;
– построение структурных иерархий;
– декомпозицию компонентов;
– проектирование компонентов.
Результатом такого проектирования является подробная модель
разрабатываемого ПО вместе с спецификациями его основных компонентов
практически всех уровней. Типы модели зависят от выбранного подхода для
проектирования:[12]
– структурный;
– объектный;
– компонентный,
а также конкретной технологии проектирования.
Заметим, что в любом случае процессы проектирования охватывают
как проектирование программ (модулей) и определение имеющихся
взаимосвязей между ними.
Принято различать также основные 2 аспекта проектирования: [16]
– логическое проектирование;
– физическое проектирование.
18
Под реализацией представляют собой процесс последовательного
написания кодов программы с помощью выбранного ЯП (кодирование), их
детальное тестирование и отладку.
Сопровождением является процесс создания или внедрения новых
версий ПО.
Причинами выпуска более новых версий служат такие предусловия:
– необходимость исправления ошибок, что были выявлены в
процессе эксплуатации предыдущих версий ПО;
– необходимость совершенствования разного рода предыдущих
версий, к примеру, улучшения интерфейса пользователя, расширения состава
функций;
– изменение среды функционирования, к примеру, появление
новых средств или программных продуктов, для которых выполняется
взаимодействие сопровождаемого ПО.
На указанном этапе в П вносят необходимые изменения, аналогично,
как и в остальных случаях, могут также потребовать пересмотра всех
проектных решений, которые приняты на любой предыдущей стадии. С
изменением модели ЖЦ программного обеспечения роль рассматриваемого
этапа существенно возрастает, поскольку продукты теперь создаются
посредством итерационной процедуры – сначала выпускается простая
версия, а потом следующая с несколько большим функционалом, затем
следующая и т. п.
Именно этот факт послужил причиной выделения стадии
сопровождения в отдельный этап жизненного цикла по стандарту ISO/IEC
12207.[24]
Рассматриваемый стандарт называет и определяет все процессы
жизненного цикла ПО, не конкретизируя непосредственно в деталях, как
выполнять и реализовывать действия и задачи, что включаются в эти
процессы.
19
1.3. Обзор моделей жизненного цикла
На протяжении последних десятилетий в программировании сменились
3 основные модели жизненного цикла ПО:
– каскадная;
– модель промежуточного контроля;
– спиральная.
Первоначально (в первой половине 1970-х гг.) была предложена
каскадная модель разработки ПО (рисунок 3), которая предполагала, что
непосредственный переход на следующий этап осуществляется лишь после
того, как будут завершены все проектные операции с предыдущей стадии, а
также получены все начальные данные для другой стадии. [28]
Рисунок 3 – Схема каскадной модели
Главными достоинствами указанной схемы являются [32]:
– получение в конце всех стадий законченного набора основной
проектной документации, что должна отвечать требованиями
согласованности и полноты;
20
– простота планирования непосредственного процесса разработки
ПО.
Данную схему часто используют обычно при так называемого блочно-
иерархическому подходе к разработке сверхсложных технических объектов,
при этом обеспечивая очень высокие показатели эффективности разработки.
[5]
Но рассмотренная схема оказалась применимой лишь к созданию
систем, что в самом начале этапа разработки удавалось полно и точно
сформулировать все требования.
Данный факт уменьшал вероятность возникновения при разработке
проблем, что связаны с принятием неудачного решения в предыдущих
стадиях.
Стоит заметить, что на практике эти разработки применяются крайне
редко.
Факт необходимости возвратов на предыдущие этапы обусловлена
такими главными причинами:
– неточные спецификации, практическое уточнение которых при
разработке может привести к острой необходимости пересмотра принятых
ранее решений;
– изменение требований клиентов непосредственно при
выполнении разработки ПО;
– быстрое устаревание используемых программных и технических
средств;
– отсутствие хороших средств для описания разработки на
основных стадиях постановки задачи.
Отказ от уточнения спецификаций приведет также к тому, что
окончательный продукт не будет никак удовлетворять потребности разных
пользователей.
При отказе от выполнения учета смены оборудования, а также
программной среды пользователь получит сразу устаревший продукт. [36]
21
Отказ от пересмотра плохих проектных решений непосредственно
приводит к ухудшению схемы программного продукта, а также усложнит,
растянет во времени и сделает процесс его создания более дорогостоящим. В
результате реальный процесс разработки будет носить итерационный
характер.
Схема, поддерживающая так называемый итерационный характер
разработки ПО, была названа схемой, что поддерживает промежуточный
контроль (рисунок 4).
Контроль, что выполняется по указанной выше схеме после
завершения каждого следующего этапа, позволяет вернуться при
необходимости на любой уровень, а также при этом внести необходимые
изменения.
Главная опасность использования рассмотренной схемы связана также
с тем, что непосредственная разработка никогда не будет завершаться,
постоянно находясь в фазе уточнения или усовершенствования.
Рисунок 4 – Схема разработки ПО на основании промежуточного контроля
Для преодоления всех перечисленных выше проблем еще в середине
1980-х гг. была предложена так называемая спиральная схема (рисунок 5). В
соответствии с рассматриваемой схемой ПО создается не сразу, а используя
итерационный метод прототипирования, что базируется на создании
прототипов.