Будь умным!


У вас вопросы?
У нас ответы:) SamZan.net

Тема- Создание индивидуального проекта

Работа добавлена на сайт samzan.net:

Поможем написать учебную работу

Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 4.6.2024

Тема: Создание индивидуального проекта.

  1.  Разработка «Постановки задачи» на конкретной предметной области.
  2.  Технологическая сеть анализа материалов обследования.
  3.  Выявление списка автоматизируемых задач.
  4.  Выявление требований к информационной системе.

1-3 Разработка «Постановки задачи» на конкретной предметной области.

Анализ предметной области

Постановка задач

Цель данного курсового проекта – разработка программной информационной системы «Интерактивная среда разработки IDEF-моделей» с использованием современных информационных технологий. 

Система должна быть реализована на платформе JAVA. 

Для достижения поставленной цели необходимо решить следующие задачи: 

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

Описание предметной области

   IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (к слову сказать, он активно применяется и в российских госструктурах, например в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF (и предшествующей методолoгии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес-процесс реинжиниринг).

Семейство стандартов

  • IDEF0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);
  • IDEF1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
  • IDEF1X (IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
  • IDEF2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);
  • IDEF3 — Process Description Capture — Документирование технологических процессов, IDEF3 — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
  • IDEF4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
  • IDEF5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;
  • IDEF6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;
  • IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;
  • IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);
  • IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;
  • IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;
  • IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;
  • IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;
  • IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;
  • IDEF14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.

Аналоги разрабатываемой ИС

  • AllFusion Process Modeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов. Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса. Графическое изложение этой информации позволяет перевести задачи управления организацией из области сложного ремесла в сферу инженерных технологий.
  • AllFusion Process Modeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. AllFusion Process Modeler 7 повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.
  • AllFusion Process Modeler 7 (BPwin) эффективен в проектах, связанных с описанием действующих баз предприятий, реорганизацией бизнес-процессов, внедрением корпоративной информационной системы. Продукт позволяет оптимизировать деятельность предприятия и проверить ее на соответствие стандартам ISO 9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции и повысить эффективность. В основу продукта заложены общепризнанные методологии моделирования, например, методология IDEF0 рекомендована к использованию Госстандартом РФ и является федеральным стандартом США. Простота и наглядность моделей Process Modeler упрощает взаимопонимание между всеми участниками процессов. Распространенность самого AllFusion Process Modeler 7 позволяет вести согласование функциональных моделей с партнерами в электронном виде. Продукт AllFusion Process Modeler 7 (BPwin) создан компанией Computer Associates. AllFusion Process Modeler 7 наряду с ERwin Data Modeler (ранее: ERwin), Data Model Validator (ранее: ERwin Examiner),Model Manager (ранее: ModelMart) входит в состав пакета программных средств AllFusion Modeling Suite, комплексное использование которого обеспечивает все аспекты моделирования информационных систем.

Основные возможности системы:

  • Поддержка различных технологий моделирования
  • Анализ показателей затрат и производительности
  • Интеграция процессов/данных
  • Поддержка стандартных нотаций
  • Экспорт объектов и свойств в другие модели
  • Документирование информации в пределеах всей модели 
  • Масштабируемость отчетности без потери качества графиков

Хорактеристики продукта поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD(моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область более комплексно. Позволяет повысить эффективность бизнеса, оптимизировать любые процедуры в компании. Полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC) недорог, распространён, по нему много информации и компетентных специалистов. Лёгок в освоении и применении, есть курсы на русском языке. Позволяет облегчить сертификацию на соответствие стандартам качества ISO9000 является стандартом де-факто, интегрирован с ERwin Data Modeler (для моделирования БД благодаря вышеупомянутой интеграции и поддержке совместной, командной работы над одними и теми же моделями (с помощью ModelManager), не имеет аналогов для крупных проектов. Интегрирован со средством имитационного моделирования Arena. Имитационное моделирование - создание компьютерной модели системы (физической, технологической, финансовой и т. п.) и проведение на ней экспериментов с целью наблюдения/предсказания. Реальный эксперимент проводить дороже, а зачастую опасно или невозможно.  Содержит собственный генератор отчётов. Позволяет эффективно манипулировать моделями - сливать и расщеплять их. Имеет широкий набор средств документирования моделей, проектов.

На данный момент AllFusion Process Modeler является единственным средством на рынке CASE-средств, позволяющих создавать диаграммы семейства IDEF. Существуют различные ПС позволяющие создавать диаграммы семейства IDEF, такие как Microsoft Visio, Dia, но данные продукты не являются CASE-средствами, т.к. не следят за целостностью связей, процессом декомпозиции. Еще одним недостатком AllFusin Process Modeler является то что данная ПС не является кросс-плотформенной, а значит пользователи других операционных систем не могут диаграммы семейства IDEF. 

Анализ платформ и средств разработки

Google App Engine

Google App Engine позволяет выполнять ваши веб-приложения в инфраструктуре Google. Приложения App Engine легко создавать, поддерживать и усовершенствовать по мере увеличения трафика и хранилища данных. При работе с App Engine вам не понадобится поддерживать сервер: просто загрузите свое приложение, и пользователи смогут работать с ним.

Приложение можно опубликовать в собственном домене (например, http://www.example.com/) с помощью Служб Google. Или воспользоваться бесплатным именем в домене appspot.com. Приложение можно сделать доступным для всех или предоставить доступ только участникам вашего коллектива.

Google App Engine поддерживает приложения, написанные на нескольких языках программирования. Благодаря среде выполнения Java App Engine можно создавать приложения с помощью стандартных технологий Java, в том числе JVM, сервлетов Java и языка программирования Java, или другого языка, использующего интерпретатор или компилятор на JVM, например JavaScript или Ruby. Кроме того, App Engine предоставляет специальную среду выполнения Python, которая включает быстрый интерпретатор и стандартную библиотеку Python. Среды выполнения Java и Python разработаны специально для того, чтобы приложения могли быстро и безопасно выполняться без взаимодействия с другими приложениями в системе.

С App Engine нужно платить, только за то, что используете. Не требуется платить за установку или вносить периодические платежи. Оплата за использованные приложением ресурсы, такие как объем хранения и трафик, измеряемые в гигабайтах, взимается по обоснованным ставкам. Можно управлять максимальным количеством ресурсов, которые приложение может использовать, что позволит всегда оставаться в пределах бюджета.

Начать использовать App Engine можно бесплатно. Вам не придется платить за приложения, использующие менее 500 МБ хранилища, а также ресурсы ЦП и трафик, достаточные для эффективного приложения, обслуживающего до пяти миллионов просмотров страниц в месяц. Включив оплату для приложения, эти ограничения повышаются, а оплата взимается только за ресурсы, использованные свыше бесплатных уровней

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

  • динамическую работу в Интернете с полной поддержкой основных веб-технологий;
  • постоянное хранилище с запросами, сортировкой и транзакциями;
  • автоматическое масштабирование и регулировку нагрузки;
  • API для аутентификации пользователей и отправку электронной почты с помощью аккаунтов Google;
  • полнофункциональную локальную среду разработки, имитирующую Google App Engine на вашем компьютере.
  • запланированные задачи для отслеживания событий в определенное время или через регулярные интервалы.

Приложение может выполняться в одной из двух сред выполнения: Java и Python. Каждая среда предоставляет стандартные протоколы и основные технологии для разработки веб-приложений.

2. Технологическая сеть анализа материалов обследования.

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

Важнейшими объектами обследования могут являться:

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

- функциональная структура

- состав хозяйственных процессов и процедур;

- стадии (техническая подготовка, снабжение, производство, сбыт);

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

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

Кроме того, объектами обследования служат:

- технологии, методы и технические средства их преобразования;

- материальные потоки и процессы их обработки.

Основной целью выполнения первого этапа предпроектного обследования "Cбор материалов" является:

- выявление основных параметров предметной области (например, предприятия или его части);

- установление условий, в которых будет функционировать проект ЭИС;

- выявление стоимостных и временных ограничений на процесс проектирования.

На этом этапе проектировщиками выполняется ряд технологических операций и решаются следующие задачи (технологическая сеть проектирования представлена на рис. 3.2:

Рис . 3.2. Технологическая сеть работ, выполняемых на этапе сбора

материалов обследования

 

П 1 ─ предварительное изучение предметной области;

П 2 ─ выбор технологии проектирования;

П 3 ─ выбор метода проведения обследования;

П 4 ─ выбор метода сбора материалов обследования;

П 5 ─ разработка программы обследования;

П 6 ─ разработка плана-графика сбора материалов обследования;

П 7 ─ сбор и формализация материалов обследования.

Д 1.1. ─ общие сведения об объекте;

Д 1.2. ─ примеры разработок проектов ЭИС для аналогичных систем;

U 2.1. ─ универсум технологий проектирования;

Д 2.1. ─ список ресурсов;

Д 2.2. ─ oписаниe выбранной технологии, методов и средств проектирования;

U 3.1. ─ универсум методов проведения обследования;

Д 3.1. ─ описание выбранного метода;

U 4.1. ─ универсум методов сбора материалов обследования;

Д 4.1. ─ описание выбранных методов;

Д 5.1. ─ программа обследования;

Д 6.1. ─ план-график выполнения работ на предпроектной стадии;

U 7.1. ─ универсум методов формализации;

Д 7.1. ─ общие параметры (характеристики) экономической системы;

Д 7.2. ─ организационная структура экономической системы;

Д 7.3. ─ методы и методики управления (алгоритм расчета экономических показателей);

Д 7.4. ─ параметры информационных потоков;

Д 7.5. ─ параметры материальных потоков.

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

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

Основными ограничениями при выборе технологии из некоторого универсума технологий (U2.1) могут служить: наличие денежных средств на приобретение и поддержку выбранной технологии, ограничения по времени проектирования, доступность соответствующих инструментальных средств и возможность обеспечения поддержки их эксплуатации собственными силами, наличие специалистов соответствующей квалификации (Д 2.1). Результатом выполнения этой операции служит получение описания выбранной технологии, методов и средств проектирования (Д 2.2).

Перед началом работ по проведению обследования необходимо выбрать метод проведения обследования (П 3). Все методы (U3.1) можно объединить в группы по следующим признакам (рис. 3.3):

- по цели обследования выделяют метод организации локального проведения обследования, используемый для разработки проекта отдельной задачи или для комплекса задач, и метод системного обследования объекта, применяемый для изучения всего объекта с целью разработки для него проекта ЭИС в целом;

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

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

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

Рис . 3.3. Схема классификации методов проведения обследования

 

Выполнение работ по обследованию предметной области в каком-либо подразделении и сбору материалов можно проводить на основе предварительного проведения выбора методов сбора материалов обследования(П 4), универсум которых (U4.1) можно разделить на две группы (рис . 3.4.):

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

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

Рис . 3.4. Схема классификации методов сбора материалов обследования

 

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

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

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

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

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

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

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

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

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

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

Расчетный метод применяется для определения трудоемкости и стоимости работ, подлежащих переводу на выполнение с помощью ЭВМ, а также для установления объемов работ по отдельным операциям.

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

При выборе метода следует учитывать следующие критерии:

- степень личного участия проектировщика в сборе материала;

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

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

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

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

Таблица 3.1 Программа обследования

N

п /п

Наименование вопроса

Источник

информации

Получатель

информации

1

Цель функционирования объекта

Руководитель предприятия

Руководитель

проекта

2

Основные параметры

объекта

Руководитель предприятия

Руководитель

проекта

3

Организационная

структура объекта

Секретарь

руководителя

Зам. руководителя проекта

 

. . . .

 

 

 

Третье направление предусматривает изучение и описание структуры информационных и (или ) материальных потоков: состава и структуры компонентов потоков, структуры компонентов, частоты их возникновения, объемов за определенный период, направления движения потоков, процедур обработки, в которых участвуют эти компоненты. Источником сведений являются получаемые от специалистов предметной области интервью, экономическая документация и результаты расчетов. Описание информационной структуры выполняется на уровне экономических документов и показателей.

Для организации труда проектировщиков во время выполнения сбора материалов обследования и его последующего анализа необходимо выполнение операции П 6 ─ разработки "Плана-графика выполнения работ на предпроектной стадии" (Д 6.1), фрагмент которого представлен в табл. 3.2.

Таблица 3.2 План-график выполнения работ на стадии сбора материалов обследования

N

п /п

Наименование Работы

Код рабо ты

Исполни-тель

Дата

начала

Длитель-ность

выполнения

Дата

окончания

 

1

Определение

целей и

параметров

предприятия

001

Руководитель проекта

Серов М .Р .

01.03.99

2

02.03.99

2

Определение

организационной

структуры предприятия

002

Заместитель

руководите

ля проекта

Иванов И .П .

03.03.99

1

03.03.99

 

. . .

 

 

 

 

 

 

. . .

 

 

 

 

 

 

"План-график " служит инструментом для планирования и оперативного управления выполнением работ на предпроектной стадии.

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

Рис . 3.5. Формы документов для формализации материалов обследования

Сбор материалов обследования следует проводить с помощью стандартных форм и таблиц, которые удобно читать и обрабатывать (рис .3.5).

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

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

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

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

Далее следует вторая группа форм, формализующих

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

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

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

Формы характеристик документов включают: наименование подразделения, тип документа (первичный, промежуточный или результатный), назначение документа, наименование документа, периодичность создания или время использования. Форма описания документов содержит: перечень показателей; описание структуры документов; перечень реквизитов; распределение реквизитов по разделам документа; типы реквизитов.

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

Полученное в результате проведенной формализации описание объекта содержит исходные данные для проектирования ЭИС и определяет параметры будущей системы. Так, материальные потоки обусловливают объемы обрабатываемой информации, состав первичных данных, периодичность и сроки сбора, их источники, необходимые для разработки информационной базы. Функциональная структура объекта определяет комплексы автоматизируемых задач управления, для каждого из которых указывают: состав входных и выходных показателей; периодичность и сроки их формирования; процедуры использования данных показателей; распределение функций и процедур между персоналом и техническими средствами. Организационная структура объекта служит основанием для выделения лиц, определяющих условие решения задач обработки информации, а также получателей выходных показателей и документов.

На основе формализованного описания предметной области выполняется этап "Анализ материалов обследования", целью которого являются:

- сопоставление всей собранной об объекте информации с теми требованиями, которые предъявляются к объекту, определение недостатков функционирования объекта обследования;

- выработка основных направлений совершенствования работы объекта обследования на базе внедрения проекта ЭИС, выбор направлений проектирования (выбор инструментария) и оценка эффективности применения выбранного инструментария;

- обоснование выбора решений по основным компонентам проекта ЭИС и определение общесистемных, функциональных и локальных требований к будущему проекту и его частям.

Рассмотрим технологическую сеть анализа материалов обследования (рис. 3.6), в которой в каждой из технологических операций используются документы обследования (Д 1.1 - Д 1.5).

 

Рис . 3.6. Схема процесса выполнения работ на этапе анализа материалов обследования:

Д 1.1. ─ общие параметры (характеристики) экономической системы;

Д 1.2. ─ методы и методики управления (алгоритм расчета экономических показателей);

Д 1.3. ─ организационная структура экономической системы;

Д 1.4. ─ параметры информационных потоков;

Д 1.5. ─ параметры материальных потоков;

U 1.1. ─ универсум факторов выбора;

Д 1.6 ─ обоснование и список объектов автоматизации;

U 2.1. ─ универсум факторов выбора задач;

Д 2.1. ─ обоснование списка задач по каждому подразделению (объекту автоматизации);

U 3.1. ─ универсум технических спедств;

U 3.2. ─ факторы отбора КТС;

Д 3.2. ─ обоснование выбора КТС;

U 4.1. ─ универсум операционных систем;

U 4.2. ─ критерии отбора;

Д 4.1. ─ обоснование выбора ОС;

U 5.1. ─ универсум способов организации ИБ;

U 5.2. ─ универсум программных средств ведения ИБ;

U 5.3. ─ факторы выбора;

Д 5.1. ─ обоснование выбора и описание организации ИБ и программного средства;

U 6.1. ─ универсум методов и программных средств разработки;

Д 6.1. ─ обоснование выбора метода проектирования и инструментального средства;

Д 7.1. ─ ТЭО;

Д 7.2. ─ ТЗ.

 

Анализ материалов обследования позволяет проектировщикам выделить и составить список автоматизируемых подразделений (П 1). На выбор объектов автоматизации оказывает влияние ряд факторов (U1.1), например, такие как:

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

- количество связей этого подразделения с другими подразделениями;

- важность этого подразделения в процессах управления объектом;

- степень подготовленности подразделения для внедрения ЭВМ и др.

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

При выявлении списка автоматизируемых задач (Д 2.1) на операции П 2, для которых необходимо разработать проекты, проектировщики принимают к сведению следующие факторы, представленные универсумом (U2.1):

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

- трудоемкость и стоимость расчета основных показателей данной задачи за год;

- сильная информационная связь рассматриваемой задачи с другими задачами;

- недостаточная оперативность расчета показателей;

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

- недостаточное количество аналитических показателей, получаемых на базе первичных документов;

- неэквивалентный метод расчета показателей и др.

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

Далее выполняется серия операций, связанных с анализом всех полученных ранее результатов, исходных универсумов и предварительным выбором комплекса технических средств (Д 3.1) на операции П 3. На выбор типа ЭВМ из универсума U3.1 оказывает влияние большое число факторов, которые принято объединять в следующие группы (3.2):

1. Факторы, связанные с параметрами входных информационных потоков, поступающих на обработку ЭВМ: объем информации, тип носителя информации, характер представления информации.

2. Факторы, зависящие от характера задач, которые должны решаться на ЭВМ, и их алгоритмов: срочность решения, возможность разделения задачи на подзадачи, выполняемые на другой ЭВМ, количество файлов с условно-постоянной информацией.

3. Факторы, определяемые техническими характеристиками ЭВМ: производительность процессора, емкость оперативной памяти, поддерживаемая операционная система, возможность подключения различных устройств  ввода-вывода.

4. Факторы, относящиеся к эксплуатационным характеристикам ЭВМ: требуемые условия эксплуатации, необходимый штат обслуживающего персонала и его квалификация.

5. Факторы, учитывающие стоимостные оценки затрат на приобретение, на содержание обслуживающего персонала, на проведение ремонтных работ.

Далее следует выполнение операции П 4 ─ выбора типа операционных систем (Д 4.1). Операционные системы осуществляют управление работой ПЭВМ, ее ресурсами, запускают на выполнение различные прикладные программы, выполняют всевозможные вспомогательные действия по запросу пользователя. Различают однопользовательские, многопользовательские и сетевые ОС (U4.1).

К критериям, определяющим выбор конкретного класса ОС (Д 4.2) и его версии, относятся:

-.необходимое число поддерживаемых программных продуктов;

-.требования к аппаратным средствам;

-.возможность использования различных устройств ввода-вывода;

-.требование поддержки сетевой технологии;

-.наличие справочной службы для пользователя;

-.наличие дружественного интерфейса и простота использования;

-.возможность переконфигурации и быстрой настройки на новые аппаратные средства;

-.быстродействие;

-.совместимость с другими ОС;

-.поддержка новых информационных технологий и др.

Следующей операцией (П 5) является операция выбора способа организации информационной базы (ИБ ) и программного средства ведения ИБ (Д 5.1). Информационная база имеет несколько способов организации (U5.1): как совокупность локальных файлов и интегрированную организацию в виде баз данных. Локальная (файловая ) организация подразумевает под собой хранение данных в виде совокупности локальных файлов, независимых между собой, создаваемых для документа, задачи или комплекса задач.

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

Программные средства ведения ИБ выбираются исходя из класса систем хранения данных : системы управления файлами либо системы управления базами данных (СУБД ). К основным факторам, определяющим выбор типа СУБД, относятся следующие факторы (Д 5.3):

- масштаб применения СУБД ─ по этому признаку выбираются персональные ─ настольные СУБД ( например, FoxPro или Access) или промышленные ─ сетевые СУБД (например, Oracle, Sybase, Informix, MS SQL,ADABAS, InterBase и др.);

- язык общения: выбирают СУБД с открытыми языками, замкнутыми или смешанными;

- число уровней в архитектуре: одноуровневые; двухуровневые; трехуровневые;

- выполняемые СУБД функции: информационные ─ организации хранения информации и доступа к ней и операционные функции, связанные с обработкой информации;

- сфера возможного применения СУБД: универсальное использование и специализированное.

При выполнении следующей операции (П 6) осуществляется выбор методов и средств проектирования программного обеспечения системы, который напрямую зависит от выбранной технологии проектирования . В универсум методов проектирования (U6.1), используемых при каноническом подходе, входят такие, как метод структурного проектирования, модульного проектирования и другие . Основными факторами, оказывающими влияние на выбор методов является их совместимость, сокращение времени и стоимостных затрат на проектирование, получение качественного продукта, который был бы удобен для последующей его эксплуатации и сопровождения. Выполнение всех этих операций завершается составлением ТЭО (Д 7.1) и формированием ТЗ (Д 7.2) на операции П 7. Целью разработки "Технико-экономического обоснования" проекта ЭИС является оценка основных параметров, ограничивающих проект ЭИС, обоснование выбора и оценка основных проектных решений по отдельным компонентам проекта. При этом различают организационные параметры, характеризующие способы организации процессов преобразования информации в системе, информационные и экономические параметры, характеризующие затраты на создание и эксплуатацию системы, экономию от ее эксплуатации. Основными объектами параметризации в системе являются задачи, комплексы задач, экономические показатели, процессы обработки информации.

Организационные параметры ЭИС дифференцируют по технологическим операциям процесса обработки информации : сбора, регистрации, передачи, хранения, обработки и выдачи информации. Для подготовительного этапа технологии обработки информации параметрами могут быть: вид связи между источником информации и ЭВМ, территориальное размещение технических средств, наличие промежуточного носителя информации, способ обеспечения достоверности информации и т.п. Для основного этапа технологии обработки информации в качестве параметров выступают: способ организации информационной базы, тип организации файлов, тип запоминающих устройств, режим обработки информации, тип ЭВМ, тип организации использования ЭВМ и т.п. Для заключительного этапа ─ способ организации связи пользователя с ЭВМ, наличие промежуточного носителя, организация размножения результатной информации и т.п. К информационным параметрам относятся такие, как достоверность, периодичность сбора, форма представления, периодичность обработки информации и т.д. К экономическим параметрам ЭИС относятся: показатели годового экономического эффекта, коэффициента эффективности затрат и т.п.

Параметризация позволяет определить требования к системе, оценить существующую информационную систему, определить пригодность типовых решений в проекте ЭИС, выбрать проектные решения в соответствии с предъявляемыми требованиями к ЭИС. К основным компонентам ТЭО относятся:

- характеристика исходных данных о предметной области;

- обоснование цели создания ЭИС;

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

- разработка перечня организационно-технических мероприятий по проектированию системы;

- расчет и обоснование эффективности выбранного проекта;

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

На основании ТЭО разрабатываются основные требования к будущему проекту ЭИС и составляется "Техническое задание" согласно ГОСТ 34.602 ─ 89 "Техническое задание на создание автоматизированной системы", в состав которого входят следующие

основные разделы.

1. В разделе "Общие сведения о проекте " указывают: полное наименование системы, код системы, код договора, наименование предприятия -разработчика и предприятия -заказчика, перечень документов, на основании которых создается система, плановые сроки начала и окончания работ по созданию системы, сведения об источниках финансирования, порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей).

2. Раздел описания "Назначение, цели создания системы" состоит из двух подразделов:

- в подразделе "Назначение системы" дается вид автоматизируемой деятельности, перечень объектов автоматизации, на которых предполагается ее использовать;

- в подразделе "Цели создания системы" указываются наименования и требуемые значения технических, технологических, производственно - экономических и других показателей объекта автоматизации, которые будут достигнуты в результате внедрения ЭИС.

3. В разделе "Характеристика объекта автоматизации " приводятся:

- краткие сведения об объекте автоматизации;

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

Раздел "Требования к системе" состоит из следующих подразделов:

- требования к системе в целом;

- требования к функциям (задачам), выполняемым системой;

- требования к видам обеспечения.

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

В подразделе "Требования к функциям (задачам)", выполняемым системой комплексам задач и отдельным задачам приводят по каждой подсистеме перечень функций, задач или их комплексов, подлежащих автоматизации; распределение их по очередям создания; временной регламент реализации каждой функции, задачи или комплекса; требования к качеству реализации каждой функции, задачи, комплекса, к форме представления выходной информации; характеристики необходимой точности и времени выполнения, достоверности выдачи результата.

В подразделе "Требования к видам обеспечения" содержатся требования к математическому, программному, техническому, лингвистическому, информационному и методическому обеспечению ЭИС.

Раздел "Состав и содержание работ по созданию системы" должен содержать: перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601 ─ 90; сроки выполнения; перечень организаций-исполнителей; перечень документов по ГОСТ 34.201 ─ 89 "Виды, комплектность и обозначения документов при создании автоматизированных систем", предъявляемых по окончанию работ; вид и порядок проведения экспертизы технической документации и др.

В разделе "Порядок контроля приемки системы" указывают: виды, состав, методы испытания системы и ее частей; общие требования к приемке работ по стадиям; порядок утверждения приемных документов; статус приемочной комиссии.

В разделе "Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие" необходимо привести перечень необходимых мероприятий и их исполнителей, которые следует выполнять при подготовке объекта к вводу ЭИС в действие: приведение информации, поступающей в систему к виду, пригодному для ввода в ЭВМ; создание условий функционирования объекта, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; создание необходимых для функционирования системы подразделений и служб; сроки и порядок комплектования штатов и обучения персонала.

В разделе "Требования к документированию" приводят: перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 ─ 89 и НТД отрасли заказчика.

В разделе "Источники разработки " должны быть перечислены документы и информационные материалы (ТЭО, отчеты о законченных научно-исследовательских разработках, информационные материалы на отечественные, зарубежные системы-аналоги и др.).

В состав ТЗ при наличии утвержденных методик включают приложения, содержащие: расчеты экономической эффективности системы; оценку научно-технического уровня системы.

4. Выявление требований к информационной системе.

Источники требований.

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

Результирующий, часто достаточно сырой материал рассматривается, как документ «Требования совладельцев»1. На требования совладельцев обычно не накладывается никаких специальных ограничений.

Продолжая рассуждения, начатые в предыдущей лекции, модель создаваемой информационной системы  в определённой мере должна отражать модель ОС.

Поэтому другим важным источником информации, помимо выявления требований, являются артефакты, описывающие предметную область. Это могут быть документы с описанием бизнес-процессов предприятия, выполненные консалтинговым агентством, либо просто документы (должностные инструкции, распоряжения, своды бизнес-правил), принятые на предприятии. Одной из немногих методологий, в которых специально выделяются рабочий поток делового моделирования, является Rational Unified Process.

Ещё одна альтернатива, используемая при выявлении требований – так называемые «лучшие практики», широко используемые в настоящее время в бизнес-консалтинге и при внедрении корпоративных информационных систем. Лучшие практики представляют собой описания моделей деятельности успешных компаний отрасли, используемые длительное время в сотнях и тысячах компаний по всему миру.

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

Стратегии выявления требований

Интервью

Ключевой стратегией выявления требований было и остаётся интервью с экспертами.

В ставшей уже классической, но ничуть не утерявшей актуальность монографии Д.Марко  в процессе проведения интервью предлагается выделить три подчинённых процесса: подготовку, проведение интервью (опроса) и завершение. Ниже приводится краткий обзор рекомендаций Д.Марко с акцентом на выявление требований (в монографии даны рекомендации по интервьюированию с целью формирования модели объекта исследования).

1. Подготовка

Подготовка позволяет спланировать процесс опроса и выработать стратегию управления этим процессом. Важность подготовительного этапа вырастает, если респондент является «дефицитным» полезным ресурсом, например – президентом крупной компании.

При подготовке Д.Марко рекомендует следующие шаги:

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

При выборе собеседника для целей сбора требований определяющими являются две вещи:

  •  Он действительно является экспертом по данному вопросу;
  •  Его мнение действительно является ценным при формировании целевого набора требований3.

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

Полезными приёмами являются формирование программы беседы и ознакомление с ней респондента, подробное планирование беседы вплоть до записи подготовленных вопросов. Подготовленное таким образом интервью называют структурированным. В дополнение к так построенному интервью автор  предлагает проводить неструктурированное интервью, «представляющее собой неформальную встречу, которой не свойственны заготовленные впрок вопросы или заранее поставленные цели». Цель такого интервью – пробудить респондента к креативу в области, в которой интервьюер недостаточно хорошо ориентируется.

2. Проведение опроса

Ниже приведёна цитата из , с некоторыми сокращениями и исключениям материала, не относящегося к АТ.

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

Начиная разговор, не забудьте представиться и сформулировать цель встречи. Это поможет избежать недоразумений и даст беседе правильное направление. Кроме того, обговорите возможность ведения записей.

Затем сформулируйте первый вопрос. Помните, что первый вопрос часто задает тон всему разговору, поэтому хорошо продумайте его.

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

Прежде всего, не возражайте.

Никогда не задавайте наводящих вопросов или вопросов с короткими ответами "да" или "нет". Вместо этого записывайте то, что вам говорят, и просите подвести итог или дать пояснения.

Вы получите от опроса больше, если вы дадите эксперту возможность говорить то, что он хочет сказать, а не то, что вы хотите услышать (конец цитаты).

3. Завершение

Следите за возникновением следующих ситуаций :

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

Любая из этих причин - достаточное основание для завершения беседы.

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

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

Что нужно помнить при опросе

Следующие рекомендации помогают поддерживать непрерывность потока и достоверность информации, поступающей от эксперта:

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

Анкетирование

Анкетирование – самый малозатратный для аналитика способ извлечения информации, он же – и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.

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

Л.Мацяшек  рекомендует формулировать в анкетах вопросы с замкнутым циклом ответов в одной из следующих трёх форм.

Многоальтернативные вопросы. Эта форма анкеты известна всем, кто когда либо проходил тестирование; может расширяться комментариями респондента в свободной форме.

Рейтинговые вопросы. Представляют предопределённый набор ответов на сформулированные вопросы. Используются такие значения, как «абсолютно согласен», «согласен», «отношусь нейтрально», «не согласен», «абсолютно не согласен», «не знаю».

Вопросы с ранжированием. Предусматривает ранжирование (упорядочивание) ответов путём присваивания им порядковых номеров, процентных значений и т.п.

Наблюдение

Наблюдение за работой моделируемой организационной системы - полезная стратегия получения информации (хотя, строго говоря, по результатам наблюдения можно получить модель ОС, а не модель АТ).

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

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

Недостатком этой стратегии является то, что наблюдатель, как и всякий «измерительный прибор», вносит помехи в результаты измерений: сотрудники организации, находясь «под колпаком» могут начать вести себя принципиально по другому, чем обычно.

Самостоятельное описание требований

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

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

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

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

Совместные семинары

Помимо классического интервью «тет а тет», существует значительное количество методик, предполагающих широкое участие представителей Заказчика и Исполнителя.

Правила мозгового штурма предполагают полную раскрепощённость и свободу мнений, даже самых вычурных и на первый взгляд «бредовых». Первое правило мозгового штурма – «полный запрет на любую критику». Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет  полноценным образом подключить творческую фантазию.

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

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

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

Секретарь – стенографист встречи. Фиксирует её результаты на компьютере. Возможно применение CASE-средств.

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

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

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

Эта стратегия, очевидно, одна из самых затратных, однако она окупается за счёт меньшего количества ошибок и отказе от формализации в пользу живого общения, выработке общего языка и пр. Некоторые методологии (например, XP) зиждутся на постоянном тесном контакте между Заказчиком и Исполнителем и, если такой возможности нет – XP-проект просто не сможет состояться.

“Разъясняющие встречи”  или «запланированный мозговой штурм» – термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.

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

Прототипирование

Прототипирование – ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в 10-Прототипирование требований). Программный прототип – «зеркало», в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путём прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя даёт ещё больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.

Метод RAD – один из наиболее известных способов быстро создавать прототипы4.

RAD базируется на следующих базовых принципах:

  •  Эволюционное прототипирование;
  •  CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
  •  Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
  •  Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
  •  Жёсткие временные рамки, как противоядие от «расползания границ» проекта: если команда не укладывается в срок – функционал сужается.

1  Терминология RUP

2  В нашем случае – группой аналитиков требований

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

4  Хотя задачи RAD на этом не ограничиваются




1. тема [2111] Терминология и свойства системы
2. Тема 8 МЕТОДИЧЕСКИЕ ОСНОВЫ ОПТИМИЗАЦИИ ПРОЕКТНЫХ РЕШЕНИЙ Содержание- [0
3. Тема- Шкільне життя Підтема- Здібності школярів
4. Политико и экономико географическое положение
5. За 3 ~ 4 тижні погіршився загальний стан знову зявився головний біль безсоння нудота пронос.html
6. ТЕМА 15 ХАРАКТЕРИСТИКА ФИНАНСОВЫХ РЕЗУЛЬТАТОВ ХОЗЯЙСТВЕННОЙ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ 1
7. Механизм осуществления государственной власти в Российской Федерации
8. ЛЕКЦИЯ 4 ПЛАН Основные классы рецепторов клеточной поверхности ~ топологическая классификация Рец
9. Воспитание образование педагогика в Киевской Руси и Русском государстве до XVII в Воспитание и обучение у
10. Независимая республика Турция
11. ку панкреатический пищеварительный сок содержащий ферменты расщепляющие белки УВ жиры а в кровь гормон
12.  Основы бухгалтерского учета
13. тематика Экология консульт
14. Роль президента Российской Федерации в правотворчестве
15. 1 Понятие содержание характеристика и разновидности системного подхода
16. Лекция 14 Национальная экономика и механизм ее развития 1
17. Косвенные налоги в РФ и перспективы их развития
18. Методы выбора поставщика
19. 1862 Приход в марте 1861 г
20. Место постпозитивизма в философии науки 2.html