Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Методологии и технологии проектирования информационных систем
2.1.1. Общие требования к методологии и технологии Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС (см. рис. 2.2.). Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла. Технология проектирования определяется как совокупность трех составляющих: - пошаговой процедуры, определяющей последовательность технологических операций проектирования; - критериев и правил, используемых для оценки результатов выполнения технологических операций; - нотаций (графических и текстовых средств), используемых для описания проектируемой системы. На данный момент существует две модели разработки программного обеспечения. Сейчас более современной и лучшей моделью разработки является - спиральная (см. рис. 2.1.). Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям: - технология должна поддерживать полный ЖЦ ПО; - разработки ИС с заданным качеством и в установленное время; Рис. 2.1. Спиральная модель разработки программного обеспечения.
Рис. 2.2. Представление технологической операции проектирования.
- технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций; - технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; - технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам; - технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; - технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования); - технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие: - стандарт проектирования; - стандарт оформления проектной документации; - стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: - набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; - правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; - требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; - механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д. Стандарт оформления проектной документации должен устанавливать: - комплектность, состав и структуру документации на каждой стадии проектирования; - требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), - правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; - требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; - требования к настройке CASE- средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: - правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; - правила использования клавиатуры и мыши; - правила оформления текстов помощи; - перечень стандартных сообщений; - правила обработки реакции пользователя [4].
2.2. Структурный подход к проектированию информационных систем
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы " снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие: - принцип " разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; - принцип иерархического упорядочивания; - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие: - принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных; - принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы; - принцип непротиворечивости - заключается в обоснованности и согласованности элементов; - принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: - SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; - DFD (Data Flow Diagrams) диаграммы потоков данных; - ERD (Entity-Relationship Diagrams) диаграммы " сущность-связь". На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы [1]. 2.3. Примеры комплексов CASE-средств
В заключение приведу примеры комплексов CASE-средств обеспечивающих поддержку полного жизненного цикла программного обеспечения. Здесь хотелось бы еще раз отметить нецелесообразность сравнения отдельно взятых CASE-средств, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков. По мнению автора, на сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, основанный на методологии и технологии DATARUN. В состав комплекса входят следующие инструментальные средства: - CASE-средство Silverrun; - средство разработки приложений JAM; - мост Silverrun-RDM < -> JAM; - комплекс средств тестирования QA; - менеджер транзакций Tuxedo; - комплекс средств планирования и управления проектом SE Companion; - комплекс средств конфигурационного управления PVCS; - объектно-ориентированное CASE-средство Rational Rose; - средство документирования SoDA [6]. Примерами других подобных комплексов являются: - Vantage Team Builder for Uniface + Uniface (фирмы " DataX/Florin" и " ЛАНИТ" ); - комплекс средств, поставляемых и используемых фирмой " ФОРС": - CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные); - средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное); - средство настройки и оптимизации ExplainSQL (Platinum); - cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum); - средство документирования ORACLE Book. - комплекс средств на основе продуктов фирмы CENTURA: - CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ); - средства разработки приложений SQLWindows и TeamWindows; - средство тестирования и оптимизации приложений " клиент-сервер" SQLBench (ARC); - средства эксплуатации и сопровождения Quest и Crystal Reports [8]. 3. Анализ языков программирования
|
Последнее изменение этой страницы: 2019-10-03; Просмотров: 182; Нарушение авторского права страницы