Смекни!
smekni.com

Внутрифирменная методология ведения проектов Дата (стр. 7 из 15)

PDS

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

CDM

На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных (ER-модель). От структур первичных данных концептуальная модель отличается удалением избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной системы. Цель концептуальной модели данных - описать используемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализованном виде.

ISA

На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура ИС. Определяются входящие в систему приложения, для каждого приложения специфицируются используемые данные и реализуемые функции. Архитектура ИС создается в модуле Silverrun BPM с использованием специальной нотации ISA. Основное содержание этой модели - структурные компоненты системы и навигация между ними. Концептуальная модель данных разбивается на части, соответствующие входящим в состав системы приложениям.

ADM

Перед разработкой приложений должна быть спроектирована структура корпоративной базы данных. DATARUN предполагает использование базы данных, основанной на реляционной модели. Концептуальная модель данных после нормализации переносится в модуль реляционного моделирования Silverrun RDM с помощью специального моста ERX-RDM. Преобразование модели из формата ERX в формат RDM происходит автоматически без вмешательства пользователя. После преобразования форматов получается модель реляционной базы данных. Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений ссылочной целостности). Правила обработки данных можно задавать как непосредственно на языке программирования СУБД, так и в декларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным СУБД переводят эти декларативные правила на язык требуемой системы, что снижает трудоемкость программирования процедур сервера базы данных, а также позволяет из одной спецификации генерировать приложения для разных СУБД.

SPM

С помощью модели системных процессов детально документируется поведение каждого приложения. В модуле BPM создается модель системных процессов, определяющая, каким образом реализуются бизнес-процессы. Эта модель создается отдельно для каждого приложения и тесно связана с моделью данных приложения.

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

IPM

Модель представления интерфейса - это описание внешнего вида интерфейса, как его видит конечный пользователь системы. Это может быть как документ, показывающий внешний вид экрана или структуру отчета, так и сам экран (отчет), созданный с помощью одного из средств визуальной разработки приложений - так называемых языков четвертого поколения (4GL - Fourth Generation Languages). Так как большинство языков 4GL позволяют быстро создавать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования.

ISM

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

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

2.3.2 Методология Oracle CDM/PJM

Oracle CDM/PJM – метод сквозного создания и внедрения информационных систем с использованием Oracle Designer. Полная методология CDM изложена в отдельном документе и находится в архиве фирмы. В этом разделе приводятся наиболее важные ее моменты [см. также 18].

Oracle Custom Development Method (CDM) — составная часть глобальной методологии разработки ИС — Oracle Method. Кроме CDM в Oracle Method входят метод разработки хранилищ данных (DWM), метод внедрения готовых приложений (Aim), метод управления проектом (PJM) и ряд других.

Поскольку решаемые в CDM задачи тесно связаны и переплетены с задачами руководителя проекта, то CDM наиболее сильно связан с методикой Oracle PJM по организации управления разработкой проекта. Цель PJM (Project Metod) – определить структуру, в рамках которой проекты в области информационных технологий можно было бы согласованно планировать, оценивать, контролировать и завершать.

Этапы классического подхода в CDM:

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

Процессы в CDM (в скобках – условные коды):

  • Постановка задачи или Определение производственных требований (RD).
  • Исследование существующих систем (ES).
  • Определение технической архитектуры (TA).
  • Проектирование и построение БД (DB).
  • Проектирование и реализация модулей (MD).
  • Преобразование (конвертирование) данных (CV).
  • Документирование (DO).
  • Тестирование (TE).
  • Обучение (TR).
  • Внедрение или Переход к новой системе (TS).
  • Поддержка и сопровождение (PS).

2.3.3 Методология RUP

По методологии Rational unified process (RUP) фирмы Rational Rose жизненный цикл системы состоит из следующих этапов:

  • Основные потоки работ процесса:
    • Деловое моделирование или Моделирование процессов предметной области.
    • Выработка требований.
    • Анализ и проектирование.
    • Выполнение или Кодирование (реализация программного кода).
    • Испытание или Тестирование.
    • Развертывание или Установка ПО.
  • Основные потоки работ поддержки:
    • Управление конфигурацией и изменениями.
    • Управление проектом.
    • Управление средой.

2.3.4 Методология фирмы SoftServe

Фирма SoftServe Inc. (Virginia, U.S.) осуществляет консалтинговые услуги на всех этапах жизненного цикла разработки ПО, который, по ее представлению, состоит в следующем:

  • Планирование (Planning):
    • Планирование информационных ресурсов (Information Resource Planning).
    • Планирование обмена данными (Electronic Data Interchange Planning).
    • Планирование внедрения (Implementation Planning).
  • Проектирование и разработка (Design and Development):
    • Системный анализ, проектирование и разработка (System analysis, design and development)
    • Определение технических требований к аппаратному и программному обеспечению (Hardware/Software selection).
    • Проектирование базы данных (Database Design).
    • Проектирование программной архитектуры (System Integration Design).
    • Проектирование пользовательского интерфейса (User-Interface Design).
  • Внедрение (Implementation):
    • Тестирование системы (System Testing).
    • Обучение и тренинг пользователей (Training and Education courses).
    • Выпуск документации (System and User Documentation).
  • Поддержка (Support):
    • Наблюдение за работой системы (System audits).
    • Техническое сопровождение (On-going technical support).
    • Пересмотр методов управления и обеспечения безопасности (Control and Security review).
    • Управление потоком данных (Data processing management).

2.4 Другие международные стандарты

2.4.1 Список международных стандартов

В целом, при проектировании систем используются следующие международные стандарты IEEE и ISO [1,2]:

  • ASTM 1340-90 - Standard Guide for Rapid Prototyping of Computerized Systems.
  • IEEE Std 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology (ANSI).
  • IEEE Std 730-1989 - IEEE Standard for Software Quality Assurance Plans (ANSI).
  • IEEE Std 828-1990 - IEEE Standard for Software Configuration Management Plans (ANSI).
  • IEEE Std 830-1993 - IEEE Recommended Practice for Software Requirements Specifications (ANSI). Рекомендации по разработке спецификаций требований программного обеспечения (см. п. 2.1.2).
  • IEEE Std 982.1-1988 - IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
  • IEEE Std 982.2-1988 - IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
  • (ANSI/)IEEE Std 983-1986 - IEEE Guide to Software Quality Assurance Planning.
  • IEEE Std 1002-1987 - IEEE Standard Taxonomy for Software Engineering Standards (ANSI).
  • (ANSI/)IEEE Std 1012-1986 - IEEE Standard for Software Verification and Validation Plans (ANSI).
  • IEEE Std 1016-1987 - IEEE Recommended Practice for Software Design Descriptions (ANSI).
  • IEEE Std 1028-1988 - IEEE Standard for Software Reviews and Audits (ANSI).
  • (ANSI/)IEEE Std 1042-1987 - IEEE Guide to Software Configuration Management (ANSI).
  • IEEE Std 1058.1-1987 - IEEE Standard for Project Management Plans (ANSI).
  • IEEE Std 1074-1991[1995?] - IEEE Standard for Developing Software Life Cycle Processes (ANSI) (см. п. 2.2.2).
  • IEEE P1233, October 1993 - Draft Guide to Developing System Requirements Specifications.
  • ANSI/IEEE 829-1983 Standard for Software Test Documentation.
  • ANSI/IEEE 1008-1986 Standard for Software Unit Testing.
  • IEEE 1063-1987 (confirmed 1993) - Standard for Software User Documentation.
  • ISO 9000-3:1991 - Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software (см. п. 2.4.4).
  • ISO 9126:1991 - Quality characteristics and guidelines for their use.
  • ISO 12119:1994 - Quality requirements and testing.
  • ISO 6592:2000 - Guidelines for the documentation of computer-based application systems.
  • ISO 9294-1990-TO - Guidelines for the management of software documentation.
  • ISO 9127:1988 - User documentation and cover information for consumer software packages.

2.4.2 Стандарт IEEE Std 830-1993 (Спецификация требований к ПО)

Стандарт IEEE Std 830-1993 описывается как «IEEE Recommended Practice for Software Requirements Specifications (ANSI)», т.е. Рекомендации по разработке спецификаций требований программного обеспечения (далее - СТПО).