7. Процесс разработки по с использованием case-средств.

См. 4.

8. Этап анализа в жизненном цикле программного обеспечения.

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

Совокупность требований задаёт рамки разрабатываемой системы.

На этапе анализа уочняются, формализуются, документируются требования заказчика.

Основные предметы анализа:

• внешние условия работы системы;

• функциональная структура системы;

• распределение функций между человеком и системой, интерфейсы;

• условия эксплуатации;

• требования к информационным, техническим и программных компонентам системы.

Результаты стадии анализа:

• спецификации;

• формализованное видение системы;

• ТЗ.

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

Этапы работы с требованиями:

• извлечение;

• анализ;

• спецификация;

• проверка.

Механизмы извлечения требований:

• интервьюирование;

• сценарии;

• прототипы;

• разъясняющие встречи (мозговые штурмы);

• наблюдение.

Перед извлечением требований необходимо определить их источники (и значимость источников).

Механизмы анализа требований:

• концептуальное моделирование (создание модели предметной области реального мира);

• архитектурное моделирование (модель реального мира →модель программной системы).

На этом этапе не требуется отображение бизнес-сущностей на компоненты, это задача проектирования.

Спецификация требований (спецификация отражает ограничения разрабатываемой ИС):

• определение системы;

• спецификация системных требований;

• спецификация программных тербований.

Механизмы проверки требований:

• обзор требований;

• прототипирование;

• утверждение модели (формальные тесты);

• проверочные тесты.

10. Проектирование, ориентированное на данные.

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

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

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

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

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

Атрибут - это характеристика сущности.

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

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

Альтернативные ключи – кандидаты на роль первичного ключа.

Важно упомянуть про нормальные формы см. 14.