Процесс обучения включает следующие действия:

1) подготовительную работу;

2) разработку учебных материалов;

3) реализацию плана обучения.

10. 
    Модели жизненного цикла: поэтапная, каскадная, спиральная, переиспользования и реверсивной инженерии.
    

Каскадная модель. Первоначально (1970-1985 годы) была предложена и использовалась

каскадная схема разработки программного обеспечения, которая предполагала, что

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

проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.

Достоинствами такой схемы являются:

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

• простота планирования процесса разработки.

Именно такую схему и используют обычно при блочно-иерархическом подходе к разработке сложных технических объектов, обеспечивая очень высокие параметры эффективности

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

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

неудачного решения на предыдущих стадиях. На практике такие разработки встречается крайне

редко.



В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами:

• неточные спецификации, уточнение которых в процессе разработки может привести к

необходимости пересмотра уже принятых решений;

• изменение требований заказчика непосредственно в процессе разработки;

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

• отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи,

анализа и проектирования.

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

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

неудачных проектных решений приводит к ухудшению структуры программного продукта и,

---

соответственно, усложнит, растянет по времени и удорожит процесс его создания. Реальный

процесс разработки, таким образом, носит итерационный характер.

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

который выполняется по данной схеме после завершения каждого этапа, позволяет при

необходимости вернуться на любой уровень и внести необходимые изменения.

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

будет завершена, постоянно находясь в состоянии уточнения и усовершенствования.

Спиральная модель. Для преодоления перечисленных проблем в середине 80-х годов XX в,

была предложена спиральная схема. В соответствии с данной схемой программное

обеспечение создается не сразу, а итерационно с использованием метода прототипирования,

базирующегося на создании прототипов. Именно появление прототипирования привело к тому,

что процесс модификации программного обеспечения перестал восприниматься, как

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

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

функции и внешние интерфейсы разрабатываемого программного обеспечения.

На первой итерации, как правило, специфицируют, проектируют, реализуют и тестируют

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

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

Основным достоинством данной схемы является то, что, начиная с некоторой итерации, на

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

пользователю, что позволяет:

• сократить время до появления первых версий программного продукта;

• заинтересовать большое количество пользователей, обеспечивая быстрое продвижение

следующих версий продукта на рынке;



• ускорить формирование и уточнение спецификаций за счет появления практики

использования продукта;

• уменьшить вероятность морального устаревания системы за время разработки.

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

---

перехода на следующие стадии. Для ее решения обычно ограничивают сроки прохождения каждой

стадии, основываясь на экспертных оценках.

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

Постановка задачи. В процессе постановки задачи четко формулируют назначение

программного обеспечения и определяют основные требования к нему. Каждое требование

представляет собой описание необходимого или желаемого свойства программного обеспечения.

Различают функциональные требования, определяющие функции, которые должно выполнять

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

особенности его функционирования.

Требования к программному обеспечению, имеющему прототипы, обычно определяют по

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

Для формулирования требований к программному обеспечению, не имеющему аналогов, иногда

необходимо провести специальные исследования, называемые предпроектными. В процессе таких

исследований определяют разрешимость задачи, возможно, разрабатывают методы ее решения

(если они новые) и устанавливают наиболее существенные характеристики разрабатываемого

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

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

постановки задачи заканчивается разработкой технического задания, фиксирующего

принципиальные требования, и принятием основных проектных решений (см. гл. 3).

Анализ требований и определение спецификаций. Спецификациями называют точное

формализованное описание функций и ограничений разрабатываемого программного

обеспечения. Соответственно различают функциональные и эксплуатационные спецификации.

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

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

---

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

формализации, строят модель предметной области, определяют подзадачи и выбирают или

разрабатывают методы их решения. Часть спецификаций может быть определена в процессе

предпроектных исследований и, соответственно, зафиксирована в техническом задании.

На этом этапе также целесообразно сформировать тесты для поиска ошибок в проектируемом

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

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

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

программного обеспечения обычно включает:

• проектирование общей структуры - определение основных компонентов и их взаимосвязей;

• декомпозицию компонентов и построение структурных иерархий в соответствии с

рекомендациями блочно-иерархического подхода;

• проектирование компонентов.

Результатом проектирования является детальная модель разрабатываемого программного

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

выбранного подхода (структурный, объектный или компонентный) и конкретной технологии

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

программ (подпрограмм) и определение взаимосвязей между ними, так и проектирование данных,

с которыми взаимодействуют эти программы или подпрограммы.

Принято различать также два аспекта проектирования:

• логическое проектирование, которое включает те проектные операции, которые

непосредственно не зависят от имеющихся технических и программных средств, составляющих

среду функционирования будущего программного продукта;

• физическое проектирование - привязка к конкретным техническим и программным

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

Реализация. Реализация представляет собой процесс поэтапного написания кодов программы

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

Внедрение (тестирование, опытная эксплуатация) - комплексная отладка подсистем ИС,

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

---

Система редко вводится полностью. Как правило, это процесс постепенный или итерационный. Ввод в эксплуатацию проходит как минимум три стадии:

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

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

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

Выход системы на проектную мощность в хорошем варианте - это доводка мелких ошибок и редкие серьезные ошибки.

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

Сопровождение. Сопровождение - это процесс создания и внедрения новых версий

программного продукта. Причинами выпуска новых версий могут служить:

• необходимость исправления ошибок, выявленных в процессе эксплуатации предыдущих

версий;

• необходимость совершенствования предыдущих версий, например, улучшения интерфейса,

расширения состава выполняемых функций или повышения его производительности;

• изменение среды функционирования, например, появление новых технических средств и/или

программных продуктов, с которыми взаимодействует сопровождаемое программное

обеспечение.

На этом этапе в программный продукт вносят необходимые изменения, которые так же, как в

остальных случаях, могут потребовать пересмотра проектных решений, принятых на любом

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

---

Смотрите также файлы

• Утверждаю Руководитель Учебнометодического центра (подпись) (Ф. И. О.).docx

• Задача 2 Сезон ранней осени. Вы идете по улице и видите встревоженного мужчину, который зовет на помощь прохожих. На вопрос Что случилось.docx

• 2 Анализ результатов цифровизации экономики России на основе использования проектного управления 1 Анализ результатов реализации федерального проекта Цифровая экономика Российской Федерации.docx

• 1. 25 Масса сняряда 10 кг, масса ствола орудия 500 кг. При выстреле снаряд получает кинетическую энергию 1,5106 Дж. Какую кинетическую энергию получает ствол орудия при отдаче m1 10 кг.docx

• Практическое задание 4 Местникова А. А.docx