1.1. Анализ требований

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

Список требований к разрабатываемой системе должен включать:

- совокупность условий, при которых предполагается эксплуатировать будущую систему, аппаратные и программные ресурсы, внешние условия ее функционирования, список работ, имеющих к ней отношение;

- описание выполняемых системой функций;

- ограничения в процессе разработки, имеющиеся ресурсы.

На этапе анализа определяются:

- архитектура системы, ее функции, внешние условия;

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

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

1.2. Проектирование

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

Проектирование можно разделить на два основных этапа:

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

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

Трудности реализации проекта системы:

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

2. Отсутствие достаточных знаний у заказчика о проблеме обработки данных или знаний для решения вопроса о реализуемости отдельных составляющих системы.

3. Недостаточность знаний системного аналитика о закономерностях предметной области реализуемого приложения.

4. Спецификация системы из-за объема и новизны технических терминов часто непонятна заказчику.

5. Информационная недостаточность спецификаций для проектировщиков и программистов при ее понятости заказчиком.

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

Базовые принципы методологии структурного анализа:

1 принцип: - “разделяй и властвуй”- для решения трудных проблем путем разбиения их на множество мелких и независимых частей-задач;

2 принцип - “иерархического упорядочения”- дополняет первый и декларирует, что устройство этих частей также существенно для понимания.

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

Средства проектирования и структурного анализа объединяются в три группы:

1 группа- функции, которые система должна выполнять;

2 группа -отношения между данными;

3 группа -аспекты реального времени, т.е. время поведения системы.

Среди многообразия средств проектирования и структурного анализа наиболее часто применяются:

- DFD (data flow diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов;

- ERD (entity-relationship diagrams) диаграммы “сущность-связь”;

- STD (state transition diagrams) диаграммы переходов состояний.

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

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

Диаграмма STD содержит средства описывающие и раскрывающие поведения системы в реальном времени.

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

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

На основе репозитория осуществляется интеграция CASE-средств и разделение системной информации между участниками проекта. Возможности репозитория обеспечивают несколько уровней интеграции:

- общий пользовательский интерфейс по всем средствам;

- передачу данных между средствами;

- интеграцию этапов разработки через единую систему “представителей фаз;”

- передачу данных и средств между различными платформами.

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