Концепция
Идентифицирует
функциональные процессы и информационные
потребности
Функциональная архитектура
Технологические
возможности и стандарты
Функциональные
требования к системе
Системные
возможности
Функциональные
требования к технологии
Технические
решения и стандарты
Технико–экономические
ограничения
Идентифицирует
все типы систем, поддерживающих
функциональные задачи
Системная
архитектура
Техническая
архитектура
Идентифицирует технологические
стандарты, правила и соглашения
Рисунок 4 – От концепции к архитектуре БД
В разделе Требования к программной документации указывается предварительный состав программной документации, и при необходимости, специальные требования к ней.
В рамках проектирования БД (ТЗ, ТП, РП) должно быть осуществлено:
-
определение состава, структуры и характеристик функциональных задач в рамках деятельности структурных подразделений;
-
определение состава и структуры программных средств автоматизации технологии решения задач с учетом существующих средств в структурных подразделениях;
-
определение структуры и характеристик информационного обеспечения технологии решения задач;
-
разработка технических решений по построению информационного обеспечения (логических структур БД, структур классификаторов);
-
разработка состава автоматизируемых процедур документооборота.
Технический проект должен включать:
-
полную функциональную модель требований к будущей системе;
-
комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);
-
пакет отчетов и документов по функциональной модели, включающий характеристику объекта моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;
-
концептуальную модель интегрированной базы данных (пакет диаграмм);
-
архитектуру системы с привязкой к концептуальной модели;
-
предложения по штатной структуре для поддержки системы.
Технический проект позволяет:
-
описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;
-
уменьшить затраты на разработку и внедрение системы;
-
оценить разработку по времени и результатам;
-
достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);
-
улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру БД, выполнить функциональную декомпозицию типовых модулей.
В последние годы многие разработчики стали применять документ, называемый «Техническая спецификация» (ТС). Он является чем-то средним между ТЗ и ТП. Но так как спецификация пишется на каждый компонент системы отдельно, то ТС позволяет до оформления ТП (или даже без него) начать разработку продукта.
В рабочем проекте должны быть определены этапы и стадии выполнения работ по разработке, внедрению и сопровождению БД. На этапе разработки необходимо:
-
определить информационные потребности и описать основных пользователей БД;
-
описать желаемые результаты функционирования БД;
-
составить список источников данных;
-
разработать информационную модель БД;
-
выбрать способ хранения данных и СУБД;
-
выбрать систему визуализации и анализа данных;
-
составить технологическую модель БД;
-
подготовить график внедрения БД и ответственных исполнителей.
Сдача в опытную и промышленную эксплуатации производится на основе приемосдаточных испытаний. Программа испытаний включает описание объекта испытаний, цель испытаний, состав функций (задач), подлежащих испытаниям, описание технического, программного, информационного и организационного обеспечения, подвергаемых испытаниям, порядок проведения испытаний, методика испытаний. Порядок регистрации испытаний, выявленных недостатков и формы представления результатов испытаний, порядок устранения недостатков. В приложении к программе испытаний дается порядок действий и условий испытаний при сдаче системы (объект приемки, что предъявляется, что проверяется, форма представления результатов проверки).
На этапе внедрения и настройки БД необходимы [2]:
-
покупка и установка программного обеспечения;
-
разграничение пользовательских прав доступа к БД;
-
подготовка структуры базы для заполнения данными и установление взаимосвязей;
-
наполнение БД;
-
пробная реализация одной из подзадач;
-
демонстрация и оценка реализованных возможностей БД;
-
корректировка дальнейших планов по развитию БД;
-
реализация оставшихся подзадач.
До внедрения в промышленную эксплуатацию системы должно быть переработано положение о подразделении, эксплуатирующем систему.
На этапе сопровождения и дальнейшего развития БД необходимо:
-
текущее администрирование БД;
-
обучение пользователей;
-
дальнейшая работа по модернизации БД.
Требования к БД могут меняться, а потому необходимо иметь возможность вносить возникающие изменения, которые оформляются как дополнение к техническому заданию и являются его неотъемлемой частью.
Создание БД это сложный процесс, в котором участвуют команды заказчика и исполнителя, взаимодействие этих команд показано на рис.5.
Рисунок 5 - Взаимодействие команд заказчика и исполнителя [3]
Команда заказчика должна включать куратора проекта, координатора проекта со стороны заказчика, экспертный совет, технический ИТ-персонал, программистов, тестировщиков, операторов, системных администраторов.
Группа обучения конечных пользователей функционирует временно в начале этапа опытной эксплуатации.
Команда исполнителя включает координатора (руководитель проекта), консультантов, аналитиков, разработчиков, кодировщиков, технический ИТ-персонал, тестировщиков, службу техподдержки, системных администраторов. В соответствии с методологией внедрения БД руководитель проекта должен управлять содержанием проекта, временем, стоимостью проекта, рисками, интеграцией данных.
В разработке приложений к БД могут участвовать «новички», «кодеры» и программисты.
Из постановки задачи «новичок» выбирает знакомые слова, между которыми интуитивно пытается найти хоть какую-то связь. При реализации в ход идут все средства. Зачастую используется чужой код. Основная цель - получить результат.
Кодер понимает постановку задачи "как есть" без обсуждений и конкретизации отдельных моментов. Реализация очень похожа на дословный перевод текста с иностранного языка. Кодер при реализации некоторого модуля совершенно не задумывается о уже существующих связях между соседними модулями, так же как и о роли и месте разрабатываемого модуля в рамках всего проекта. При необходимости кодер модифицирует соседние модули в соответствии со своими нуждами. Это халтура.
Программист - это всегда еще и постановщик задачи. Он никогда не возьмется за реализацию пока не поймет, что конкретно от него хотят и как результат должен взаимодействовать с остальным кодом проекта. Принимаясь за реализацию, программист будет более-менее четко представлять себе структуру и наполнение своего модуля. В этом заключается основная особенность программиста: сначала думаем и только потом делаем. Программист всегда будет пытаться обобщать, оптимизировать свой код. Главное, программист, работающий в команде, не станет останавливаться на дословном исполнении своего куска ТЗ (типа как сказали, так и сделал, а остальное не волнует), т.е. реализует его не в рамках локальной задачи, а в рамках всего проекта (обсудив с основным постановщиком естественно). Основная особенность программиста - он может реализовать практически всё пятью различными способами. И вместо поиска путей реализации он имеет возможность сконцентрироваться на выборе наиболее оптимального и уместного в рамках реализуемой задачи.