Ответы на вопросы по базам данных (Вариант 14)

Проектирование информационных систем

1.Атрибуты и типы атрибутов. Способы отображения атрибутов в диаграммах

Чена и IDEF1Х. Понятие доменов атрибутов. Требования, предъявляемые для проектирования доменов на разных этапах проектирования БД. Определение атрибутов. Как правило, атрибуты указываются только для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Существенно помочь в определении атрибутов могут различные бумажные и электронные формы и документы, используемые в организации при решении задачи. Это могут быть формы, содержащие как исходную, так и результаты обработки данных (например, «Форма № 1»). Выявленные атрибуты могут быть следующих видов: · простой (атомарный, неделимый) – состоит из одного компонента с независимым существованием (например, «должность работника», «зарплата», «норма непогашенного ускорения», «радиус кривой» и т. д.); · составной (псевдоатомарный) – состоит из нескольких компонентов (например, «ФИО», «адрес», и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные; · однозначный – содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т. д.); · многозначный – содержит несколько значений (например, у одного отделения компании может быть несколько контактных телефонов); · производный (вычисляемый) – значение атрибута может быть определено по значениям других атрибутов (например, «возраст» может быть определен по «дате рождения» и текущей дате, установленной на компьютере); · ключевой – служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа); · неключевой (описательный) – не входит в первичный ключ; · обязательный – при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL). После определения атрибутов задаются их домены (области допустимых значений), например: · наименование участка – набор из букв русского алфавита длиной не более 60 символов; · поворот кривой – допустимые значения «Л» (влево) и «П» (вправо); · радиус кривой – положительное число не более 4 цифр. Задание доменов определяет набор допустимых значений для атрибута (нескольких атрибутов), а также тип, размер и формат атрибута (атрибутов). На основании выделенного множества атрибутов для сущности определяется набор ключей. Ключ – один или несколько атрибутов сущности, служащих для однозначной идентификации ее экземпляров или для их быстрого поиска. Выделяют следующие типы ключей: · суперключ (superkey) – атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности. Суперключ может содержать «лишние» атрибуты, которые необязательны для уникальной идентификации экземпляра. При правильном проектировании структуры БД суперключом в каждой сущности (таблице) будет являться полный набор ее атрибутов; · потенциальный ключ (potential key) – суперключ, который не содержит подмножества, также являющегося суперключом данной сущности, т. е. суперключ, содержащий минимально необходимый набор атрибутов, единственным образом идентифицирующих экземпляр сущности. Сущность может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Среди всего множества потенциальных ключей для однозначной идентификации экземпляров выбирают один, так называемый первичный ключ, используемый в дальнейшем для установления связей с другими сущностями; · первичный ключ (primary key) – потенциальный ключ, который выбран для уникальной идентификации экземпляров внутри сущности; · альтернативные ключи (alternative key) – потенциальные ключи, которые не выбраны в качестве первичного ключа. Если потенциальных ключей несколько, то для выбора первичного ключа рекомендуется придерживаться следующих правил: · количество атрибутов, входящих в ключ, должно быть минимальным (желательно, чтобы ключ был атомарным, т. е. состоял из одного атрибута); · размер ключа в байтах должен быть как можно короче; · тип домена ключа – числовой. При выборе символьных атрибутов в ключ часто возникают проблемы с вводом ошибочных значений (путают регистр букв; добавляют лишние пробелы; используют буквы, пишущиеся на разных языках одинаково). В числовых атрибутах вероятность ошибки при вводе значения меньше; · вероятность изменения значений ключа была наименьшей · с ключом проще всего работать пользователям В нотации IDEF1X атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.. В стандарте IDEF0 функциональная модель описывает моделируемый бизнес-процесс с качественной точки зрения. Чтобы получить количественные показатели, пользователь должен расширить модель набором дополнительных атрибутов, определить значения атрибутов для модели и ее отдельных функциональных блоков. Атрибуты используются как для задания исходных данных, так и для получения выходных расчетных данных. Набор дополнительных атрибутов расширяет функциональную модель и позволяет пользователю провести количественный анализ как по отдельным функциональным блокам, так и по модели в целом. По области определения атрибуты делятся на атрибуты модели, общие атрибуты и локальные атрибуты. При проектировании и эксплуатации БД к ней предъявляются следующие требования: •Адекватность отображения ПО (полнота, целостность, непро¬тиворечивость, актуальность данных). •Возможность взаимодействия пользователей разных категорий; обеспечение высокой эффективности доступа. •Дружественность интерфейса. •Обеспечение секретности и конфиденциальности. •Обеспечение взаимной независимости программ и данных. •Обеспечение надежности БД; защита данных от случайного и преднамеренного разрушения; возможность быстрого и полного восстановления данных в случае сбоев в системе.

2.Базовый принцип структурного метода проектирования. Понятия технологии и методов проектирования ИС. Требования, предъявляемые к современным технологиям проектирования ИС.

В качестве двух базовых принципов используются следующие: принцип «разделяй и властвуй» и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения. Второй принцип в дополнение к тому, что легче понимать проблему, если она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимание проблемы резко повышается при организации ее частей в древовидные иерархические структуры, т.е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали. Выделение двух базовых принципов инженерии программного обеспечения вовсе не означает, что остальные принципы являются второстепенными, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов. 1. Принцип абстрагирования — заключается в выделении существенных аспектов системы с целью представления системы в простом общем виде. 2. Принцип формализации — заключается в необходимости строгого мето¬дического подхода к решению проблемы. 3. Принцип инкапсуляции — заключается в упрятывании несущественной на конкретном этапе информации. 4. Принцип концептуальной общности — заключается в следовании единой философии (структурный анализ — структурное проектирование — структурное программирование — структурное тестирование). 5. Принцип полноты — заключается в контроле на присутствие лишних элементов. 6. Принцип непротиворечивости — заключается в обоснованности и согла¬сованности элементов. 7. Принцип логической независимости — обеспечение независимости логического проектирования от физического проектирования. 8. Принцип независимости данных — модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки. 9. Принцип структурирования данных — заключается в том, что данные должны быть структурированы и иерархически организованы. 10. Принцип доступа конечного пользователя — пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно Осуществление проектирования ИС предполагает использование проектировщиками определенной технологии проектирования, соответствующей масштабу и особенностям разрабатываемого проекта. Определение. Технология проектирования – это совокупность концептуальных методов и средств (методологий) проектирования ИС, а также методов и средств организации проектирования, то есть управления процессом создания или модернизации проекта информационной системы. Требования к технологии проектирования Технология проектирования предполагает возможность выбора различных методов и средств проектирования. Выбор оптимальной совокупности следует осуществлять с учетом следующих требований к технологии проектирования: Обеспечение создания ИС, отвечающей целям и задачам организации, а также предъявляемым требованиям по автоматизации производственных процессов заказчика; Гарантированное создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта (с минимизацией трудовых и стоимостных затрат); Поддержка удобной дисциплины сопровождения, модификации и наращивания системы; Обеспечение преемственности разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий); Обеспечение роста производительности труда проектировщика при использовании выбранной технологии; Обеспечение надежности процесса проектирования и эксплуатации проекта; Простота ведения проектной документации.

3.Задачи анализа транзакций на этапе логического проектирования и правила его проведения на примере одной транзакции.

Цель логического проектирования – развить концептуальное представление БД с учетом принимаемой модели БД (иерархической, сетевой, реляционной и т. д.). Примем в качестве модели реляционную БД в третьей нормальной форме (набор нормализованных отношений с кратностью связей 1:N). Поэтому необходимо будет проверить концептуальную модель с помощью методов нормализации и контроля выполнения транзакций [1, 20, 21]. Транзакция – одно действие или их последовательность, выполняемых как единое целое одним или несколькими пользователями (прикладными программами) с целью осуществления доступа к БД и изменению ее содержимого. 1. Удаление и проверка элементов, не отвечающих принятой модели данных. 1.1. Удаление связей N:M. Если в концептуальной модели присутствуют связи N:M, то их следует устранить путем определения промежуточной сущности. Связь N:M заменяется двумя связями типа 1:M, устанавливаемыми со вновь созданной сущностью. 1.2. Удаление связей с атрибутами. Связи с атрибутами должны быть преобразованы в сущности. В разработанной концептуальной модели существовала связь N:M («Раздельные пункты» : «Пути»), которая имела собственные атрибуты. После устранения связь N:M, ее атрибуты перешли в сущность «Раздельные пункты на пути» В графической нотации IDEF1X не предусмотрено отображение связей с атрибутами, хотя некоторые методологии ERD допускают их наличие и отображение. 1.3. Удаление сложных связей (со степенью участия более 2). Сложную связь заменяют необходимым количеством бинарных связей 1:N со вновь созданной сущностью, которая и показывает эту связь. 1.4. Удаление рекурсивных связей (со степенью участия 1). Рекурсивную связь заменяют, определив дополнительную сущность и необходимое количество связей 1.5. Удаление многозначных атрибутов (атрибутов имеющих несколько значений). Многозначность устраняется путем введения новой сущности и связи 1:N Данное преобразование, помимо соответствия реляционной модели данных, также позволяет хранить любое количество телефонов по одному филиалу. 1.6. Удаление избыточных связей. Связь является избыточной, если одна и та же информация может быть получена не только через нее, но и с помощью другой связи В приведенном примере одну из связей «Руководит» можно смело удалить (лучше между «Руководителем филиала» и «Сотрудником»). 1.7. Перепроверка связей 1:1. 2. Проверка модели с помощью правил нормализации. 3. Проверка выполнения транзакций. 4. Определение требований поддержки целостности данных.

4.Задачи анализа транзакций на этапе физического проектирования и правила его проведения на примере одной транзакции.

Физическое проектирование базы данных — процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты. Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных. Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. Проектирование физического представления базы данных Определение оптимальной файловой структуры для хранения базовых отношений и индексов, необходимых для достижения приемлемой производительности. Иными словами, определение способа хранения отношений и кортежей во вторичной памяти. Анализ транзакций Определение функциональных характеристик транзакций, которые будут выполняться в проектируемой базе данных, и выделение наиболее важных из них. Выбор файловой структуры Определение наиболее эффективной файловой структуры для каждого базового отношения. Выбор индексов Определение того, будет ли добавление индексов способствовать повышению производительности системы. Определение требований к дисковому пространству Оценка объема дискового пространства, необходимого для размещения базы данных.

5.Макет пользовательского интерфейса. Анализ макета на этапе логического проектирования.

Разработчики интерфейсов стремятся к отображению реального мира , а по некоторым свойствам даже превосходят возможности реальности . Сказанное можно отнести прежде всего к воспроизведению и моделированию процесса во времени . Следует отметить , что многое в содержании этапов предполагает имено обоснованный выбор свойств , непосредственно участвующих в деятельности пользователя . При таких возможностях от многого приходится скорее отказываться , чем включать в интерфейс . В связи с этим приходит в голову известная оппозиция недопрограммированных и перепрограммированных компьютерных систем , каждая из которых обладает своими недостатками . Задача же проектировщика интерфейса часто состоит в поиске того оптимума , который позволил бы освободиться от недостатков обоих родов . Понятно , что освободиться от недостатков пользовательский интерфейс может лишь в том случае , если процесс его разработки и настройки превратится в технологию и будет оснащен собственными средствами автоматизации . Это может означать , что традиционная архитектура пользовательского интерфейса дополнится новым слоем . Общепринято , нынешняя его архитектура содержит четыре слоя программного обеспечения (11): 1) графический интерфейс для управления аппаратурой дисплея ; 2) инструментальные средства (toolkits) для построения стандартных компонентов интерфейса , которые называют кубиками (widgets); 3) сам набор кубиков ; 4) программа интерфейса высокого уровня для процедур с операционной средой Принцип Описание Учет знаний пользователя В интерфейсе необходимо использовать термины и понятия, взятые из опыта будущих пользователей системы Согласованность Интерфейс должен быть согласованным в том смысле, что однотипные (но различные) операции должны выполняться одним и тем же способом Минимум неожиданностей Поведение системы должно быть прогнозируемым Способность к восстановлению Интерфейс должен иметь средства, позволяющие пользователям восстановить данные после ошибочных действий Руководство пользователя Интерфейс должен предоставлять необходимую информацию в случае ошибок пользователя и поддерживать средства контекстно-зависимой справки Учет разнородности пользователей В интерфейсе должны быть средства для удобного взаимодействия с пользователями, имеющими разный уровень квалификации и различные возможности

6.Нежелательные элементы при проведении анализа на этапе логического проектирования.

Временные оценки СУБД наиболее популярных тестов последнее время даются в виде числа транзакций определенного стандартизованного вида в единицу времени. Распределенная обработка строится на основе мониторов транзакций. Нужно будет обнаруживать пределы возможностей такого деления работ на достаточно мелкие порции. Здесь отметим очень важный эффект: практика ориентации на «транзакционный подход» тесно связана с классической методологией проектирования БД, которая развивалась, в основном, как методология проектирования так называемы «операционных» БД, то есть баз данных, которые должны фиксировать отдельные совершаемые операции и хранить модель текущего фактического состояния объекта или ПрО. Логическое проектирование базы данных. Процесс создания модели используемой на предприятии информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации. В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки правильносги логической модели данных используется метод нормализации. Нормализация гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации. Помимо всего прочего, логическая модель данных должна обеспечивать поддержку всех необходимых пользователям транзакций. Созданная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами поиска компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных играет также важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе.

7.Основные подходы к проектированию ИС. Основные принципы структурного и объектно-ориентированного методов проектирования.

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

8.Перечень элементов и их назначение для создания пользовательского интерфейса.

Интерфейс пользователя — эта та часть программы, которая находится у всех на виду. Некоторые программисты склонны оставлять дизайн интерфейса пользователя на потом, считая, что реальное достоинство приложения — его программный код, который и требует большего внимания. Однако часто возникает недовольство пользователей из-за неудачно подобранных шрифтов, непонятного содержимого экрана и скорости его прорисовывания, поэтому работу над интерфейсом также нужно воспринимать серьезно. Проектирование форм ввода данных Особый вид форм — формы, предназначенные для ввода данных. Они позволяют пользователю идти в нужном ему темпе, не оглядываясь на программиста. Работа с несколькими формами Если интерфейс пользователя должен содержать несколько форм, вам предстоит принять самое важное решение: какой использовать вид интерфейса — однодокументный или многодокументный.Эффективные меню Еще одна важная часть разработки форм — создание содержательных и эффективных меню. Приведем некоторые важные рекомендации:• Следуйте стандартным соглашениям о расположении пунктов меню принятым • Группируйте пункты меню в логическом порядке и по содержанию.• Для группировки пунктов в раскрывающихся меню используйте разделительные линии• Избегайте избыточных меню.• Избегайте пунктов меню верхнего уровня, не содержащих раскрывающихся меню• Ощущение скорости Ощущение — это реальность. Здесь мы попытаемся объяснить, как ощущения пользователя могут повлиять на то, понравится ему ваша программа или нет. Простой пример — скорость работы приложения. У вас может быть самый быстродействующий программный код, но это ничего не значит, если с точки зрения пользователя он работает медленно. Когда пользователи жалуется на скорость, программисты защищаются, утверждая, что «пользователь не знает, что делает программа». Однако, если воспользоваться некоторыми уловками, то можно сделать та что будет казаться, будто программа работает быстрее. Пользователь гораздо более расположен к ожиданию, если считает, что компьютер работает с максимальной скоростью. Хороший пример- загрузка Windows, которая обычно требует достаточно много времени. Однако вывод графики, сопровождающие звуки, шум жесткого диска отвлекают настолько, что пользователь не ощущает ожидания. Описанная ниже техника поможет в создании «более быстрых» приложений. Информируйте пользователя о ходе процесса Когда есть видимость работы приложения, пользователи более легко переносят длительное ожидание в работе программы. Один из способов информирования пользователя о ходе выполнения работы — использовать в форме индикатор процесса. Если вы обновляете записи базы данных, можно использовать такой индикатор для отображения числа записей, над которыми операция уже произведена. Для этого добавьте пару строк кода обновляющих показания индикатора по мере перехода к следующим записям. Выводы по проектированию пользовательского интерфейса Хотя ни одно ухищрение не гарантирует создания удачного интерфейса пользователя, плохой интерфейс гарантирует отсутствие пользователей вашей программы. Однако при стремительном появлении новшеств, в сфере пользовательских интерфейсов, понятие «хорошего» интерфейса очень быстро изменяется. Возьмем, например, процесс настройки часов видеомагнитофона. Раньше часы программировали «вслепую» кнопками и переключателями, потом стали применяться дисплеи, для которых использовался экран телевизора, а теперь в некоторых моделях этот процесс выполняется автоматически по радиосигналу. Так и интерфейс пользователя программ будет «эволюционировать» по мере того как индустрия будет устанавливать новые стандарты, и вы, в свою очередь, должны быть всегда в курсе, как в наибольшей степени удовлетворить ожидания пользователя

9.Показатель кардинальности. Правило нахождения и особенности связи с показателем кардинальности 1:1 Отражение связи с показателем кардинальности 1:1 в среде Erwin.

Для того чтобы указать количество возможных связей для каждого экземпляра участвующего в связи сущности, используют показатель кардинальности. Для бинарных связей показатель кардинальности может иметь следующие значения: «один к одному» (1 : 1), «один ко многим»(1 : N), «многие ко многим» (М : N). Если максимальная мощность связи в обоих направлениях равна одному, мы называем ее связью «один к одному» (1 : 1). Например, на факультете может быть один декан, и обратно, один и тот же декан может руководить только одним факультетом, что может быть обозначено следующим образом: ФАКУЛЬТЕТ <——> ДЕКАН. Если максимальная мощность в одном направлении равна одному, а в другом — многим, то связь называется «один ко многим» (1 : N). Например, в группе учится много студентов, но каждый студент учится только в одной группе: ГРУППА <——>> СТУДЕНТ Количество классов сущностей, охваченных данной связью, выражает степень связи. Связь со степенью два наиболее распространена и называется бинарной. Например, в вышеприведенном примере — бинарная связь. Такие связи между сущностями наиболее распространены. многие ко многим (N : M). В этом случае связь типа N : M (многие ко многим). Правила, определяющие показатели кардинальности связей, называют бизнес-правилами организации. Они устанавливаются для определенной организации исходя из особенностей её функционирования.. Бизнес – правила организации являются обязательными для реализации в создаваемой БД. Имеется два варианта участия сущности в связи: полное и частичное. Степень участия является полной, если для существования некоторой сущности требуется существования другой сущности. На ER — диаграмме участник связи с полным участием соединяется со значком связи двойной линией, а участник связи с частичным участием – одинарной линией.

10.Показатель кардинальности. Правило нахождения и особенности связи с показателем кардинальности 1:м. Отражение связи с показателем кардинальности 1:м в среде Erwin.

Для нахождения показателя кардинальности необходимо использовать следующее правило, состоящее из трех шагов: Выделяется один экземпляр первой сущности и проверяется, со сколькими экземплярами второй сущности он может вступать в связь. При этом не учитывается временной фактор, другими словами — со сколькими экземплярами второй сущности он может вступать в связь в любое время. Выделяется один экземпляр второй сущности и проверяется, со сколькими экземплярами первой сущности он может вступать в связь в любое время. Результаты первого и второго шага сравниваются, затем выбирается показатель кардинальности данной связи: Показатель кардинальности зависит от бизнес-правил описываемой организации, а также от набора атрибутов сущностей, вступающих в эту связь. Степень участия определяет, зависит ли существование некоторой сущности от участия в этой связи другой сущности. Для определения степени участия необходимо задать вопрос все ли экземпляры первой сущности принимают участие в заявленной связи? Если ответ — да, то степень участия первой сущности в этой связи – полная, если ответ — нет, то степень участия первой сущности в этой связи – частичная.

11.Понятие жизненного цикла ИС. Понятие модели жизненного цикла ИС.

Типы моделей ЖЦ ИС. Особенности, преимущества, недостатки Жизненный цикл программного обеспечения представляет собой модель его создания и использования. Модель отражает его различные состояния, начиная с момента возникновения необходимости в данном ПО и заканчивая моментом его полного выхода из употребления у всех пользователей. Известны следующие модели жизненного цикла: •Каскадная модель. Переход на следующий этап означает полное завершение работ на предыдущем этапе. •Поэтапная модель с промежуточным контролем. Разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью; время жизни каждого из этапов растягивается на весь период разработки. •Спиральная модель. Особое внимание уделяется начальным этапам разработки — выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание некой версии продукта или какого-либо его компонента, при этом уточняются характеристики и цели проекта, определяется его качество и планируются работы следующего витка спирали. Двумя классическими результатами анализа являются: •иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит); •модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними. Эти результаты являются необходимыми, но не достаточными. К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей. Довольно часто ошибки анализа возникают при попытке показать жизненный цикл сущности на диаграмме ER.