Какие области охватывает проектирование ис

• Название: Какие области охватывает проектирование ис
• Дата: 12.12.2018
• Размер: 50.45 Kb.
• Имя файла: voprosy_k_IS.docx
• Тип: Документы; #59926

1. 
   Какие области охватывает проектирование ИС?
   

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

2. 
   Какие характеристики архитектуры определяются на этапе проектирования?
   

на этапе проектирования определяются следующие характеристики архитектуры:

• 
  будет ли это архитектура "файл-сервер" или "клиент-сервер";
  
• 
  будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
  
• 
  будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
  
• 
  будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
  
• 
  будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
  

3. 
   Опишите модели жизненного цикла?+
   
4. 
   Перечислите основные стандарты для проектирования ИС?
   

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

• 
  ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания, соответствуют каскадной модели жизненного цикла.
  
• 
  ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Стандарт не содержит описания фаз, стадий и этапов.
  
• 
  ISO/IEC 15288:2002. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.
  
• 
  Custom Development Method - методика Oracle по разработке прикладных информационных систем с применением Oracle. Применяется для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки", рекомендуемых в случае малых проектов.
  
• 
  Rational Unified Process (RUP) предлагает итеративную модель разработки, на основе спиральной модели ЖЦ на базе UML.
  
• 
  Microsoft Solution Framework (MSF) так же является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
  
• 
  Extreme Programming (XP). Экстремальное программирование. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
  

5. 
   На какие три группы жизненного цикла ПО по базовым международным стандартом ISO/IEC 12207 делятся процессы?
   

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. 
   Основные процессы:
   
   • 
     приобретение;
     
   • 
     поставка;
     
   • 
     разработка;
     
   • 
     эксплуатация;
     
   • 
     сопровождение.
     
2. 
   Вспомогательные процессы:
   
   • 
     документирование;
     
   • 
     управление конфигурацией;
     
   • 
     обеспечение качества;
     
   • 
     разрешение проблем;
     
   • 
     аудит;
     
   • 
     аттестация;
     
   • 
     совместная оценка;
     
   • 
     верификация.
     
3. 
   Организационные процессы:
   
   • 
     создание инфраструктуры;
     
   • 
     управление;
     
   • 
     обучение;
     
   • 
     усовершенствование.
     

В таблице 1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.

Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов:

• 
  Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207)
  
• 
  Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management).
  

Таблица 1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)
Процес (исполнительный)	Действия	Вход	Результат
Приобрет ение (заказчик)	Инициирование Подготовка заявочных предложений Подготовка договора Контроль деятельности поставщика Приемка ИС	Решение о начале работ по внедрению ИС Результаты обследования деятельности заказчика Результаты анализа рынка ИС/ тендера План поставки/ разработки Комплексный тест ИС	Технико- экономическое обоснование внедрения ИС Техническое задание на ИС Договор на поставку/ разработку Акты приемки этапов работы Акт приемно- сдаточных испытаний
Постака (разработчик ИС)	Инициирование Ответ на заявочные предложения Подготовка договора Планирование исполнения Поставка ИС	Техническое задание на ИС Решение руководства об участии в разработке Результаты тендера Техническое задание на ИС План управления проектом Разработанная ИС и документация	Решение об участии в разработке Коммерческие предложения/ конкурсная заявка Договор на поставку/ разработку План управления проектом Реализация/ корректировка Акт приемно- сдаточных испытаний
Разработк а (разработчик ИС)	Подготовка Анализ требований к ИС Проектирование архитектуры ИС Разработка требований к ПО Проектирование архитектуры ПО Детальное проектирование ПО Кодирование и тестирование ПО Интеграция ПО и квалификационно е тестирование ПО Интеграция ИС и квалификационно е тестирование ИС	Техническое задание на ИС Техническое задание на ИС, модель ЖЦ Подсистемы ИС Спецификации требования к компонентам ПО Архитектура ПО Материалы детального проектирования ПО План интеграции ПО, тесты Архитектура ИС, ПО, документация на ИС, тесты	Используемая модель ЖЦ, стандарты разработки План работ Состав подсистем, компоненты оборудования Спецификации требования к компонентам ПО Состав компонентов ПО, интерфейсы с БД, план интеграции ПО Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам Тексты модулей ПО, акты автономного тестирования Оценка соответствия комплекса ПО требованиям ТЗ Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

6. 
   Опишите стадии канонического проектирования ИС?
   

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

Стадия 1. Формирование требований к ИС.

• 
  обследование объекта и обоснование необходимости создания ИС;
  
• 
  формирование требований пользователей к ИС;
  
• 
  оформление отчета о выполненной работе и тактико-технического задания на разработку.
  

Стадия 2. Разработка концепции ИС.

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

Стадия 3. Техническое задание.

• 
  разработка и утверждение технического задания на создание ИС.
  

Стадия 4. Эскизный проект.

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

Стадия 5. Технический проект.

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

Стадия 6. Рабочая документация.

• 
  разработка рабочей документации на ИС и ее части;
  
• 
  разработка и адаптация программ.
  

Стадия 7. Ввод в действие.

• 
  подготовка объекта автоматизации;
  
• 
  подготовка персонала;
  
• 
  комплектация ИС поставляемыми изделиями (программными и техническими средствами);
  
• 
  строительно-монтажные и пусконаладочные работы работы;
  
• 
  проведение предварительных испытаний; опытной эксплуатации и приемочных испытаний.
  

Стадия 8. Сопровождение ИС.

• 
  выполнение работ в соответствии с гарантийными обязательствами.
  

7. 
   Типовое проектирование это ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
   
8. 
   Типовое проектное решение (ТПР) – это тиражируемое (пригодное к многократному использованию) проектное решение.
   

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

9. 
   Опишите этапы параметрического - ориентированного проектирования.
   

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

Критерии оценки ППП делятся на следующие группы:

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

10. 
    Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.
    

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

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

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

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

12. 
    Миссия это согласно [ISO-15704] -это
    

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

13. 
    Что является деревом стратегий?иерархические списки уточнения и детализации способов достижения целей. При этом на корпоративном уровне разрабатываются стратегии роста, интеграции и инвестиции бизнесов. Блок бизнес-стратегий определяет продуктовые и конкурентные стратегии, а также стратегии сегментации и продвижения. Ресурсные стратегии определяют стратегии привлечения материальных, финансовых, человеческих и информационных ресурсов. Функциональные стратегии определяют стратегии в организации компонентов управления и этапов жизненного цикла продукции. Одновременно выясняется потребность и предмет партнерских отношений (субподряд, сервисные услуги, продвижение и пр.). Это позволяет обеспечить заказчикам необходимый продукт требуемого качества, в нужном количестве, в нужном месте, в нужное время и по приемлемой цене. При этом компания может занять в партнерской цепочке создаваемых ценностей оптимальное место, где ее возможности и потенциал будут использоваться наилучшим образом. Это дает возможность сформировать 14 бизнес-потенциал компании - набор видов коммерческой деятельности, направленный на удовлетворение потребностей конкретных сегментов рынка. Далее, исходя из специфики каналов сбыта, формируется первоначальное представление об организационной структуре (определяются центры коммерческой ответственности). Возникает понимание основных ресурсов, необходимых для воспроизводства товарной номенклатуры.
    
14. 
    В тексте
    
15. 
    функционал компании это Бизнес-потенциал, в свою очередь, определяет функционал компании - перечень бизнес-функций, функций менеджмента и функций обеспечения, требуемых для поддержания на регулярной основе указанных видов коммерческой деятельности. Кроме того, уточняются необходимые для этого ресурсы (материальные, человеческие, информационные) и структура компании.
    
16. 
    Опишите матрицу коммерческой ответственности закрепляет ответственность структурных подразделений за получение дохода в компании от реализации коммерческой деятельности. Ее дальнейшая детализация (путем выделения центров финансовой ответственности) обеспечивает построение финансовой модели компании, что, в свою очередь, позволяет внедрить систему бюджетного управления.
    
17. 
    Опишите матрицу функциональной ответственности закрепляет ответственность структурных звеньев (и отдельных специалистов) за выполнение бизнес-функций при реализации процессов коммерческой деятельности (закупка, производство, сбыт и пр.), а также функций менеджмента, связанных с управлением этими процессами (планирование, учет, контроль в области маркетинга, финансов, управления персоналом и пр.). Дальнейшая детализация матрицы (до уровня ответственности отдельных сотрудников) позволит получить функциональные обязанности персонала, что в совокупности с описанием прав, обязанностей, полномочий обеспечит разработку пакета должностных инструкций.
    
18. 
    Процессные потоковые модели  это - это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо бизнес-функции или функции менеджмента. Сначала (на верхнем уровне) описывается логика взаимодействия участников процесса, а затем (на нижнем уровне) - технология работы отдельных специалистов на своих рабочих местах.
    
19. 
    Что предполагает организационный анализ?
    

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

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

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

20. Опишите Шаблон разработки миссии

Миссия представляет собой результат позиционирования компании среди других участников рынка. Поэтому миссию компании нельзя описывать путем анализа ее внутреннего устройства. Для построения модели взаимодействия компании с внешней средой (определение миссии компании на рынке) необходимо:

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

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

При разработке модели миссии компании рекомендуется:

1. 
   Описать базис конкурентоспособности компании - совокупность характеристик компании как социально-экономической системы.
   
2. 
   Выяснить конъюнктуру рынка, т.е. определить наличие платежеспособного спроса на предлагаемые товары или услуги и степень удовлетворения рынка конкурентами.
   
3. 
   Выявить наличие способствующих и противодействующих факторов для выбранного вида деятельности со стороны государственных институтов в области политики и экономики.
   
4. 
   Оценить перспективу развития технологии в выбранной сфере деятельности.
   
5. 
   Оценить возможную поддержку или противодействие общественных организаций.
   
6. 
   Сопоставить результаты вышеперечисленных действий с учетом правовых, моральных, этических и др. ограничений со стороны персонала и сформировать позицию "хочу".
   
7. 
   Оценить уровень возможных затрат и доходов.
   
8. 
   Оценить возможность достижения приемлемого для всех сторон компромисса и сформулировать Миссию компании в соответствии с шаблоном, приведенным на
   

21. Опишите Шаблон формирования бизнесов

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

22. 
    Агрегированная модель  это - модель организационной структуры, учетные регистры которой имеют ограничение по степени детализации до 2-3 уровней.
    

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

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

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

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

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

26. 
    Процессный подход к организации деятельности предприятия предполагает.
    

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

27. 
    Референтная модель  это модель эффективного бизнес-процесса, созданная для предприятия конкретной отрасли, внедренная на практике и предназначенная для использования при разработке/реорганизации бизнес-процессов на других предприятиях. По сути, референтные модели представляют собой эталонные схемы организации бизнеса, разработанные для конкретных бизнес-процессов на основе реального опыта внедрения в различных компаниях по всему миру. Они включают в себя проверенные на практике процедуры и методы организации управления. Референтные модели позволяют предприятиям начать разработку собственных моделей на базе уже готового набора функций и процессов.
    
28. 
    моделью предметной области понимается понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.
    
29. 
    Структурный аспект предполагает построение
    

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

30. 
    Информационное обеспечение ИС является средством для решения следующих задач
    

• 
  однозначного и экономичного представления информации в системе (на основе кодирования объектов);
  
• 
  организации процедур анализа и обработки информации с учетом характера связей между объектами (на основе классификации объектов);
  

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