кек. Ответы на вопросы контрольной работы. Ответы на вопросы по к р. 1 Основные элементы проектирования ис

• Название: Ответы на вопросы по к р. 1 Основные элементы проектирования ис
• Дата: 25.10.2021
• Размер: 157.45 Kb.
• Имя файла: Ответы на вопросы контрольной работы.docx
• Тип: Отчет; #255541
• страница: 2 из 3

4

Каскадная модель жизненного цикла

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

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

Жизненный цикл традиционно разделяют на следующие основные этапы:

1. 
   Анализ требований,
   
2. 
   Проектирование,
   
3. 
   Кодирование (программирование),
   
4. 
   Тестирование и отладка,
   
5. 
   Эксплуатация и сопровождение.
   

Каскадная модель Жизненного цикла

Достоинства модели:

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

Недостатки модели:

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

Область применения Каскадной модели

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

5

Интерактивная модель (с промежуточным контролем) жизненного цикла

Поэтапная модель с промежуточным контролем еще известна как итерационная модель или «водоворот».

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

Модель характеризуется следующими свойствами взаимодействия этапов:

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

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

- результат появляется только в конце разработки, как и в модели «водопад».



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

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

6

Спиральная модель жизненного цикла

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

Для лучшего понимая механизма разработки рассмотрим такую схему:



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

Четыре главные фазы это:

1. 
   Определение целей, альтернатив, ограничений, или фаза планирования. С этой стадии начинается работа над проектом. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна.
   
2. 
   
   Анализ, определение и разрешение рисков является одной из самых значимых стадий разработки. В данном контексте,  риски — это возможные события и состояния проекта, препятствующие достижению командой разработчиков поставленных целей. Существует довольно обширный диапазон возможных рисков, от тривиальных и легко преодолимых, до крайне серьезных. Главной задачей для команды разработчиков является выявление всех возможных рисков и присвоение им определенного уровня приоритета на основе их значимости. Следующим шагом является разработка возможных стратегий преодоления этих рисков. В итоге этих действий возможны изменения в последующих стадиях разработки. В качестве результата работы на этом этапе создается прототип.
   
3. 
   
   Фаза разработки. На этом этапе происходит разработка и последующее тестирование продукта. Во время первой итерации, когда общие требования еще не так четко сформулированы, разрабатывается так называемый концепция будущего продукта (Proof Of Concept), которая необходима для получения отзыва заказчика. На последующих витках спирали рабочие версии продукта, или билды (builds), отправляются заказчику. Это позволяет получить более детальный отзыв и четче сформулировать требования.
   
4. 
   
   Планирование следующей фазы. На этом этапе вся полученная информация используется для планирования дальнейших этапов разработки.
   

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

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

Достоинства:

• 
  Мониторинг рисков является одной из главных особенностей, делающих данную модель особенно привлекательной в том случае, если вам предстоит управление большим, сложным и дорогостоящим проектом. Более того, проект будет более прозрачным, поскольку спиральная модель изначально была спроектирована таким образом, чтобы каждая итерация тщательно анализировалась;
  
• 
  Заказчик может увидеть работающую версию продукта уже на ранних стадиях жизненного цикла ПО;
  
• 
  Изменения могут быть внесены на поздних стадиях разработки;
  
• 
  Проект может быть разделен на несколько частей и те из них, которые, согласно анализу, окажутся более рискованными, могут быть реализованы на ранних стадиях. Такой подход может снизить трудности, связанные с управлением проектом;
  Строгий контроль над документацией, как результат постоянного анализа рисков.
  

Недостатки:

• 
  Мониторинг рисков требует дополнительных ресурсов, а значит, эта модель может оказаться весьма затратной. Каждая итерация требует отдельной экспертизы, что делает управление проектом сложнее. Именно поэтому спиральная модель плохо подходит для небольших проектов;
  
• 
  Большое количество промежуточных стадий разработки. Как следствие — большой объем документации;
  
• 
  На самых ранних стадиях дата завершения работы над проектом может быть неизвестна, что также усложняет контроль над процессом разработки
  

7

Что такое БД и СУБД ( понятие и кратко раскрыть характеристики )

База данных (БД) представляет собой совокупность структуриро­ванных данных, хранимых в памяти вычислительной системы и ото­бражающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.

Логическую структуру данных, хранимых в базе, называют мо­делью представления данных. К основным моделям представления данных (моделям данных) относятся иерархическая, сетевая, реля­ционная.

Система управления базами данных (СУБД) — это комплекс языко­вых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, осно­ванные на использовании реляционной модели данных, называют ре­ляционными СУБД.

Для работы с базой данных зачастую достаточно средств СУБД. Однако если требуется обеспечить удобство работы с БД неквалифи­цированным пользователям или интерфейс СУБД не устраивает пользо­вателей, то могут быть разработаны приложения. Их создание требует программирования. Приложение представляет собой программу или комплекс программ, обеспечивающих автоматизацию решения какой-либо прикладной задачи. Приложения могут создаваться в среде или вне среды СУБД — с помощью системы программирования, исполь­зующей средства доступа к БД, к примеру, Delphi или С++ Вuildег. Приложения, разработанные в среде СУБД, часто называют приложе­ниями СУБД, а приложения, разработанные вне СУБД, — внешними приложениями.

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

Информационные системы, основанные на использовании БД, обычно функционируют в архитектуре клиент-сервер. В этом случае БД размещается на компьютере-сервере, и к ней осуществляется сов­местный доступ.

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

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

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

Выделяют следующие виды СУБД :

• 
  полнофункциональные СУБД;
  
• 
  серверы БД;
  
• 
  средства разработки программ работы с БД.
  

Полнофункциональные СУБД представляют собой традиционные СУБД. К ним относятся dBaseIV, Microsoft Access, Microsoft FoxPro и др.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД обеспечивают обработку запросов клиентских программ обычно с помощью операторов SQL. Примера­ми серверов БД являются: Microsoft SQL Server, InterBase и др.

В роли клиентских программ в общем случае могут использоваться СУБД, электронные таблицы, текстовые процессоры, программы элек­тронной почты и др.


Средства разработки программ работы с БД могут использоваться для создания следующих программ:

• 
  клиентских программ;
  
• 
  серверов БД и их отдельных компонентов;
  
• 
  пользовательских приложений.
  

 

По характеру использования СУБД делят на многопользователь­ские (промышленные) и локальные (персональные).

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

• 
  возможность организации совместной параллельной работы мно­гих пользователей;
  

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

Персональные СУБД — это программное обеспечение, ориентиро­ванное на решение задач локального пользователя или небольшой группы пользователей и предназначенное для использования на пер­сональном компьютере. Это объясняет и их второе название — на­стольные. Определяющими характеристиками настольных систем яв­ляются:

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

По используемой модели данных СУБД разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и др. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.

Для работы с данными, хранящимися в базе, используются следу­ющие типы языков:

 

• 
  язык описания данных — высокоуровневый непроцедурный язык
  декларативного типа, предназначенный для описания логической
  структуры данных;
  
  
• 
  язык манипулирования данными — совокупность конструкций, обеспечивающих выполнение основных операций по работе с дан­ными: ввод, модификацию и выборку данных по запросам.
  

Названные языки в различных СУБД могут иметь отличия. Наи­большее распространение получили два стандартизованных языка: QBE — язык запросов по образцу и SQL  — структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов.

СУБД реализует следующие основные функции низкого уровня:

• 
  управление данными во внешней памяти;
  
• 
  управление буферами оперативной памяти;
  
• 
  управление транзакциями;
  
• 
  ведение журнала изменений в БД;
  
• 
  обеспечение целостности и безопасности БД.
  

Реализация функции управления данными во внешней памяти обес­печивает организацию управления ресурсами в файловой системе ОС.

Необходимость буферизации данных обусловлена тем, что объем оперативной памяти меньше объема внешней памяти. Буферы пред­ставляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагает­ся использовать при обращении к СУБД или планируется записать в базу после обработки.

Механизм транзакций используется в СУБД для поддержания це­лостности данных в базе. Транзакцией называется некоторая недели­мая последовательность операций над данными БД, которая отсле­живается СУБД от начала и до завершения. Если по каким-либо причинам (сбои и отказы оборудования, ошибки в программном обес­печении, включая приложение) транзакция остается незавершенной, то она отменяется.

Транзакции присущи три основных свойства:

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

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

Ведение журнала изменений выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных и про­граммных сбоев.

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

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