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

Завершение работ может также осуществляться в случае их удовлетворения абсолютно всем условиям с технического задания.

Поставка ПС охватывает также разные действия с требованиями поставщиков при получении готового ПС. [2]

К таким действиям можно отнести:

Инициирование поставки – это непосредственное рассмотрение поставщиком своих предложений.

Рисунок 7 – Виды тестирования

1. Подготовка ответов на предложения по результатам проверки;
2. Подготовка договоров осуществляется после процедуры определения поставщика;
3. Процесс реализации планирования часто используется также и после утверждения разных договоров и выполняет задачи:

– принятие решений для поставщиков с точки зрения выполнения самых различных работ;

– выполнение разработки целевого плана по управлению ПС, что в себе также содержит организацию проектов, их разграничение ответственности по интегрированной среде разработки.[7]

Субподрядчик (или подрядчик) является организацией или корпорацией (индивидуум), заключившие договоры по разработке и исполнении работ.[1]

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

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

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

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

К таким действиям часто относят: [9]

• эксплуатационное тестирование ПО;
• подготовительная работа с ПО;
• эксплуатация непосредственно ПО;
• поддержка ПО.

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

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

2.2. Применение вспомогательных процессов в ЖЦ

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

Процесс документирования любой работы с ПС может предусматривать специальное формальное описание по всей информации, что была создана в этапах ЖЦ.[4]

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

Этот процесс имеет этапы:

1. Подготовительную работу;
2. Процесс идентификации рабочей конфигурации – утверждаются все имеющиеся правила, при использовании которых однозначно можно определять компоненты ПС, их некоторые версии. Также ко всем из компонентов, его имеющимся версиям может ставится обозначаемый комплект документов в соответствие с ПС;
3. Контроль рабочей конфигурации предназначается для выполнения полностью систематического рассмотрения главных предполагаемых модификаций ПО, координированной реализации с эффективности модификации ПС;[3]
4. Учет состояния для конфигурации отображает регистрацию полностью всех состояний компонентов в ПС, подготовку разных отчетов всех реализованных, а также отвергнутых модификациях для версий разного рода составных частей ПС.

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

3.Описание моделей разработки программ

3.1. Каскадная модель

Каскадная модель может характеризоваться разбиением разработки определенного программного средства на некоторые этапы, причем все их переходы с определенных таких этапов к следующему будут реализованы только после завершения предварительных этапов (рисунок 8).[4]

Рисунок 8 – Каскадная модель

Рассмотрим некоторые положительные особенности описываемой модели ЖЦ:

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

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

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

В рассмотренную категорию относятся и сверхсложные расчетные системы, а именно системы реального времени.

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

Процессы разработки любого программного средства часто принимают внешний вид рисунка 9:

Рисунок 9 – Действительный процесс каскадной модели

Самое применяемое именование в международной литературе для такой схемы является считается "водопадная модель".

Главным недостатком рассматриваемого подхода также считают большое запаздывание по результату разработки.

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

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

3.2.Спиральная модель

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

При рассмотрении такой модели рассматривался упор на начальные этапы выше приведенной каскадной модели:[1]

– анализ проблемы;

– проектирование ПС.

Непосредственная реализация для всех технических фаз также выполняется по прототипам (рисунок 10). [10]

Рисунок 10 – Макет спиральной модели

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

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

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

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

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

Основная проблема для этой модели – это определение моментов с переходом к другой стадии модели.

Для решения проблемы также необходимо вводить специальные ограничения (в основном, по времени) [2].

Спиральная модель имеет свои достоинства:

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

– заказчики также могут принимать свое активное соучастие также в разработке программы;

– непосредственно в модели воплощаются полностью все преимущества модели ЖЦ.

В качестве улучшенной структуры ЖЦ рассматривают такую модель (рисунок 11).

Рисунок 11 – Схема улучшенной спиральной модели

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

3.3.Инкрементная модель

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

Каждая такая последовательностей может сама вырабатывать специальный необходимый инкремент ПО.

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

При 2-м инкременте могут использоваться более мощные возможности по редактированию и документировании.

Далее, на следующем инкременте – выполняется проверка пунктов орфографии, самых разных грамматик.

На 4-м шаге инкремента присутствуют возможности по созданию страничной структуры.[10]

Организация модели показана на рисунке 12. [3]

Рисунок 12 – Структура функционирования инкрементной модели

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

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

3.4.Поэтапная модель с промежуточным контролем

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

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

Такая модель также характеризуется свойствами для взаимодействия этапов ЖЦ, а именно:

– модель состоит с последовательно расположенных структур (водопадная модель);

– все имеющиеся этапы используют обратную связь с этапом предыдущего уровня;

– исправление ошибок происходить на всех шагах сразу (выполняется промежуточный контроль работы);

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

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

Рисунок 14 – Поэтапная модель

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