Концепция

Идентифицирует функциональные процессы и информационные потребности

Функциональная архитектура

Технологические возможности и стандарты

Функциональные требования к системе

Системные возможности

Функциональные требования к технологии

Технические решения и стандарты

Технико–экономические ограничения

Идентифицирует все типы систем, поддерживающих функциональные задачи

Системная архитектура

Техническая архитектура

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

Рисунок 4 – От концепции к архитектуре БД

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

В рамках проектирования БД (ТЗ, ТП, РП) должно быть осуществлено:

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

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

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

• разработка технических решений по построению информационного обеспечения (логических структур БД, структур классификаторов);

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

Технический проект должен включать:

• полную функциональную модель требований к будущей системе;

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

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

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

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

• предложения по штатной структуре для поддержки системы.

Технический проект позволяет:

• описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

• уменьшить затраты на разработку и внедрение системы;

• оценить разработку по времени и результатам;

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

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

В последние годы многие разработчики стали применять документ, называемый «Техническая спецификация» (ТС). Он является чем-то средним между ТЗ и ТП. Но так как спецификация пишется на каждый компонент системы отдельно, то ТС позволяет до оформления ТП (или даже без него) начать разработку продукта.

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

• определить информационные потребности и описать основных пользователей БД;

• описать желаемые результаты функционирования БД;

• составить список источников данных;

• разработать информационную модель БД;

• выбрать способ хранения данных и СУБД;

• выбрать систему визуализации и анализа данных;

• составить технологическую модель БД;

• подготовить график внедрения БД и ответственных исполнителей.

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

На этапе внедрения и настройки БД необходимы [2]:

• покупка и установка программного обеспечения;

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

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

• наполнение БД;

• пробная реализация одной из подзадач;

• демонстрация и оценка реализованных возможностей БД;

• корректировка дальнейших планов по развитию БД;

• реализация оставшихся подзадач.

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

На этапе сопровождения и дальнейшего развития БД необходимо:

• текущее администрирование БД;

• обучение пользователей;

• дальнейшая работа по модернизации БД.

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

Создание БД это сложный процесс, в котором участвуют команды заказчика и исполнителя, взаимодействие этих команд показано на рис.5.

Рисунок 5 - Взаимодействие команд заказчика и исполнителя [3]

Команда заказчика должна включать куратора проекта, координатора проекта со стороны заказчика, экспертный совет, технический ИТ-персонал, программистов, тестировщиков, операторов, системных администраторов.

Группа обучения конечных пользователей функционирует временно в начале этапа опытной эксплуатации.

Команда исполнителя включает координатора (руководитель проекта), консультантов, аналитиков, разработчиков, кодировщиков, технический ИТ-персонал, тестировщиков, службу техподдержки, системных администраторов. В соответствии с методологией внедрения БД руководитель проекта должен управлять содержанием проекта, временем, стоимостью проекта, рисками, интеграцией данных.

В разработке приложений к БД могут участвовать «новички», «кодеры» и программисты.

Из постановки задачи «новичок» выбирает знакомые слова, между которыми интуитивно пытается найти хоть какую-то связь. При реализации в ход идут все средства. Зачастую используется чужой код. Основная цель - получить результат.

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

Программист - это всегда еще и постановщик задачи. Он никогда не возьмется за реализацию пока не поймет, что конкретно от него хотят и как результат должен взаимодействовать с остальным кодом проекта. Принимаясь за реализацию, программист будет более-менее четко представлять себе структуру и наполнение своего модуля. В этом заключается основная особенность программиста: сначала думаем и только потом делаем. Программист всегда будет пытаться обобщать, оптимизировать свой код. Главное, программист, работающий в команде, не станет останавливаться на дословном исполнении своего куска ТЗ (типа как сказали, так и сделал, а остальное не волнует), т.е. реализует его не в рамках локальной задачи, а в рамках всего проекта (обсудив с основным постановщиком естественно). Основная особенность программиста - он может реализовать практически всё пятью различными способами. И вместо поиска путей реализации он имеет возможность сконцентрироваться на выборе наиболее оптимального и уместного в рамках реализуемой задачи.