Показатели различных подходов по созданию бд

Показатели подхода	Лоскутная автоматизация	СУБД	СУБД +ТПР
Адаптация к текущим условиям и организационной структуре предприятия	Есть	Нет, следование условиям проекта
Запаздывание работ во времени	Минимальное	Высокое	Среднее
Управляемость изменениями	Высокая	Низкая	Минимальная
Риск неудачи проекта	Низкий	Очень высокий	Высокий
Оптимизация технологических решений	Высокая	Средняя	Низкая
Доступность системы для заказчика	Высокая	Низкая	Низкая
Размерность работ (число шагов и время для достижения результата)	Минимальная	Высокая	Высокая
Скорость адекватных изменений, вносимых в БД	Средняя	Низкая	Низкая
Реактивность технологии создания/сопровождения	Максимальная	Низкая	Низкая
Разновидность вносимых изменений на разработку	Высокая	Средняя	Низкая
Преемственность и сохранность результатов этапов создания БД	Максимальная	Низкая	Средняя
Потребность в техно –рабочей документации	Минимальная	Высокая	Высокая
Время создания требуемой документации	Минимальное	Максимальное	Малое
Время обучения пользователей	Минимальное	Среднее	Максимальное
Потребность в реструктуризации предприятия	Отсутствует	Отсутствует	Имеется
Относительная стоимость	Низкая	Высокая	Средняя

Рис.4. Зависимость затрат от времени нахождения ошибок

(Ряд 1 – системы 80-х годов, ряд 2 – инструментальные средства разработки)

• составление графика разработки – определение этапов разработки, расчет затрат, разработка стратегии внедрения;

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

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

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

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

• внедрение.

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

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

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

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

Большинство неудач с БД закладываются на первоначальных этапах их создания. Одной из основных причин построения неудачных БД является наличие плохо сформулированных требований, которым должна отвечать та или иная БД. Почему разработчики зачастую не в состоянии четко сформулировать требования к БД? Потому что это весьма непросто; разработчики имеют слабое представление о работе пользователей (и наоборот); представления разработчиков об этой фазе проектирования БД отличны от представлений об этом пользователей.

Требования к БД могут меняться, а потому необходимо иметь возможность вносить возникающие изменения. Надо иметь в виду, что

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

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

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

Возможно ли хорошо специфицировать БД? Для этого надо определить ее характеристики, среди которых можно выделить следующие:

• тип БД – статическая, динамическая.

• размер БД – количество таблиц, полей, связей, источников данных, интерфейсов.

• сложность БД – возможность обновления данных, логическая сложность связей таблиц; степень динамичности.