Проектирование информационных систем
.pdfорганизует доступ к ним в соответствии с установленными правами и позволяет осуществлять их поиск;
- управление процессами, т. е. отслеживание всех операций пользователей с данными, в том числе версий создаваемых и изменяемых данных. Кроме того, PDM-система управляет потоком работ проекта;
-управление составом изделия. PDM-система содержит информацию о составе изделия. Важной особенностью является наличие нескольких представлений состава для различных предметных областей (конструкторское, технологическое, маркетинговое и т. п.), а также управление применяемостью компонентов изделия с помощью правил комплектации;
-классификация. PDM-система должна поддерживать различные классификаторы хранимой в ней информации (об изделиях и документах). Например, таким классификатором
можно пользоваться при автоматизации поиска изделий с нужными характеристиками;
- календарное планирование. PDM-система содержит функции формирования календарного плана работ, распределения ресурсов между отдельными задачами и контроля их выполнения;
В отличие от систем управления документами, системы PDM хранят и обрабатывают информацию, представленную не только в виде неструктурированных документов (бумажных, файлов и т.д.), так структурированную (как и базы данных в АСУП). Работа же с неструктурированными документами, тесное взаимодействие с САПР и ориентация на процессы проектирования и производства отличают системы документов от различных АСУ предприятия (MRP/ERP).
Фактически, современные системы PDM состоят из следующих функциональных модулей:
−хранилище объектов и средства управления документами
−средства управления структурой изделия
−средства поддержки классификаторов и справочников
−средства просмотра и аннотирования документов и моделей различных форматов
−средства управления проектом и проведением изменений
−средства поиска информации
−интерфейсы к прикладным пакетам
−коммуникационные интерфейсы и интерфейсы к АСУП
−интерфейсы прикладного программирования и трансляторы
24.Методология ITIL. Основные определения.
Information Technology Infrastructure Library (ITIL) - это набор руководств,
разработанных Отделом Правительственной Торговли Великобритании (United Kingdom`s Office Of Government Commerce, OGC). Каждое руководство представляет собой набор книг, в которых описывается интегрированная методология управления ИТ услугами, основанная на передовом опыте и использующая процессный подход. На сегодняшний день данные книги являются единственным, исчерпывающим, общедоступным руководством для управления услугами ИТ (IT Service Management), не основанном на частных патентах.
Методология ITIL описывает языки и процедуры, направленные на координацию усилий всех подразделений ИТ-службы и обеспечивающие слаженность их функционирования на уровне оркестра мирового класса.
Методология ITIL впервые была разработана в конце 1980- х годов Центральным компьютерным и телекоммуникационным агентством (Central Computer and Telecommunications Agency) — уже не существующим ныне структурным подразделением правительства Великобритании — в качестве каталога, в котором обобщался передовой опыт правительственных ИТ-служб и предназначалась для улучшения качества управления ИТ обслуживанием. Вскоре она получила распространение в частном секторе Соединенного королевства, затем в других европейских компаниях, а по прошествии нескольких лет проложила дорогу и в США.
Сегодня ITIL представляет собой больше, чем просто книги. Она породила целую индустрию, которая включает в себя:
•Обучение
•Сертификацию
•Консалтинг
•Программное обеспечение
•Торговую Ассоциацию (itSMF)
ITIL предлагает системный, профессиональный подход к управлению снабжением ИТ услугами. Преимущества ITIL для руководства:
•Увеличение степени удовлетворённости потребителей ИТ услуг
•Уменьшение риска того, что нужды бизнеса не будут удовлетворены
•Уменьшение затрат при разработке процедур и методов внутри организации
•Лучшее взаимодействие и обмен информацией между пользователями и ИТ
персоналом
•Стандарты и руководства для ИТ персонала
•Максимальная продуктивность и лучшее использование навыков и опыта
•Качественный подход к ИТ услугам
Имеются преимущества пользователей:
•Уверенность в том, что услуги предоставляются в соответствии с документированными процедурами и могут быть подвергнуты проверке
•Возможность положиться на ИТ услуги позволяет пользователю сосредоточиться на
достижении бизнес целей компании
•Определение контактных точек для запросов или консультирования, связанных с изменением требований
•Понимание того, какая информация необходима для обоснования затрат на ИТ обслуживание и для предоставления обратной связи при контроле соглашений уровня
обслуживания.
ITIL подчёркивает важность предоставления ИТ услуг для удовлетворения бизнес требований, причем экономически эффективным способом. Многие ИТ организации пытаются становиться более ориентированными на потребителя для демонстрации их вклада в дело компании. ITIL может помочь в достижении этого.
Организациям выгодно адаптировать руководство для удовлетворения своих потребностей. Однако, их следует предостеречь от игнорирования действий без должного обсуждения, потому что Управление ИТ Услугами представляет собой набор интегрированных и согласованных функций.
25.Предпроектное обследование
Процесс аттестации объекта в любом случае предусматривает полное предпроектное обследование, составление техзадания и т.д., поэтому оно должно быть проведено с составлением всей необходимой документации.
Услуги, предоставляемые Разработчиком, делятся на две большие группы:
1.работы по предконтрактному проектированию (до заключения контракта, договора);
2.работы по реализации контракта на проектирование ИС:
−предпроектное обследование и реинжиниринг;
−техническое задание;
−техническое проектирование;
−рабочее проектирование (реализация);
−испытания;
−внедрение и сопровождение.
В процессе предконтрактного проектирования определяются потребности и возможности заказчика, что оформляется в виде соответствующих документов (требований заказчика, технических предложений, спецификаций, проекта), происходит их согласование с заказчиком и, в случае совпадений интересов заказчика и поставщика услуг, происходит подписание контракта на предоставление услуг.
После завершения этого этапа разработчик предоставляет заказчику отчет о проведенной работе и план реинжиниринга бизнес-процессов. На основе данных, представленных в отчёте по обследованию, формируется и затем заключается контракт (финансовый договор) между Заказчиком и Исполнителем, к которому приложено предварительное ТЗ.
После заключения договора сотрудники Исполнителя приступают к полному предпроектному обследованию.
Первым шагом данного этапа будет - Получить у Заказчика концепцию существования и развития предметной области (ПрО)- миссию, а также основные элементы стратегии организации.
Основная цель данного этапа - принятие окончательного решения о создании ИС и перепроектировании (реинжиниринге) бизнес-процессов Учреждения с учётом автоматизации деловых процедур, т.е. - внедрения в деловые процессы автоматизированной обработки информации.
Порядок выполнения работ:
−определение назначения Учреждения, его роли и места во внешней среде, целей и характера деятельности;
−составление краткого лингвистического описания предметной области;
−разработка структурно-функциональной и информационной модели
существующей системы управления (СУ) документооборотом в Учреждении.
−базовые учётные единицы (объекты) предметной области, с которыми в первую
очередь имеют дело подсистемы Учреждения;
− выявление доминирующих бизнес-процессов (подсистем) на интегральном уровне Учреждения.
Выявление алгоритмов (сценариев) поможет скомпоновать бизнес-процессы по-новому - оптимальнее, - т.к. одним из критериев правильности формирования бизнес-процесса является группировка подсистем, тесно взаимодействующих между собой по сценарию, в пределах относительно автономного бизнес-процесса;
−маршруты движения конкретных наиболее важных (доминирующих) документов (ресурсов: информации, вещества, энергии) между подразделениями, рабочими местами или базами данных;
−существующие архивы и базы данных (таблицы), на основе которых формируются передаваемые документы, состав и объёмы исходных данных для выполнения операций
(функций), количество и характер их источников (первичных, вторичных), трудоёмкость их получения, качество получаемой информации - полнота, достаточность, достоверность, актуальность и т.п.;
−состав, уровень ответственности, полномочий и квалификации важнейших сотрудников на рабочих местах в Учреждении. Права доступа пользователей к различным данным, циркулирующим в Учреждении и др.;
−для выполняемых операций в системе указываются используемые методы и средства.
Все параметры и характеристики процессов функционирования должны рассматриваться с учётом тенденций их развития (и параллельно проводящегося проектирования будущегореинжиниринга бизнес-процессов Учреждения);
− формирование временных диаграмм, а также событийной и информационной схемы взаимодействия подсистем в рамках бизнес-процессов. Кратко описываются процессы технологического взаимодействия подсистем в рамках структуры Учреждения.
−оценка эффективности функционирования подразделений и сотрудников, а также выявление проблем структурно-функциональной организации системы;
−события, которые происходят в Учреждении (их имена, типы, внешние\внутренние, моменты появления, частота следования, действия, которые они инициируют в различных
подразделениях, и т.д.). Необходимо выявить обработчики каждого типа событий. События - это широковещательные сообщения или значимые для многих подразделений или сотрудников изменения во внутренней или внешней среде Учреждении.
−режимы функционирования Учреждения в штатных условиях, а также в условиях кризиса или некорректных ситуаций;
−существующие (используемые) критерии эффективностифункционирования подразделений Учреждения и наиболее важных подразделений;
−комплекс программно-аппаратных средств, используемых в системе информационного взаимодействия, его краткие характеристики;
−комплекс проблем, связанных с мотивацией деятельности персонала в составе
Учреждения, психологические и социальные аспекты взаимоотношений людей внутри коллектива и во внешней среде, выявление шкалы ценностей, которыми руководствуются люди
всвоей деятельности;
−технологическая и управленческая культура в учреждении, степень подготовленности технических средств и персонала к совершенствованию, развитию организационной
компоненты автоматизированной системы и использования для этих целей современных информационных технологий;
− формальные и неформальные лидеры в организационной структуре Учреждения. Из них формируется рабочая группа экспертов заказчика.
Работа по предпроектному обследованию системы должна сопровождаться формулировкой основных понятий, используемых в предметной области.
Документы, вырабатываемые на этапе:
Описание существующего документооборота в Учреждении (описание предметной
области).
Анализ и содержание будущего реинжиниринга бизнес-процессов Учреждения.
Концепция будущей ИС.
Первые три документа представляются в виде отчета (ДСТУ 3008-95) по предпроектному обследованию Заказчика. ТЭО - является предварительным обоснованием контракта на проектирование.
В отчете необходимо рассмотреть наиболее важные бизнес-процессы в Учреждении, предложить их реинжиниринг (перестройку), определить, какие процессы требуют первоочередной автоматизации и как после этого будет выглядеть организационная структура обновлённого учреждения.
В дальнейшем, следовательно, параллельно сосуществуют и развиваются два взаимодействующих друг с другом процесса:
−анализ текущих изменений в оргструктуре и нормативной базе Учреждения;
−реинжиниринг структуры и бизнес-технологии Учреждения в условиях создания и
внедрения ИС.
− проектирование и внедрение информационной системы (ИС).
26.Бизнес-требования
Требования к ПО состоят из трех уровней:
−бизнес требования;
−требования пользователей;
−функциональные требования.
Вдобавок каждая система имеет свои нефункциональные требования.
Бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью.
Бизнес-требования определяют и набор бизнес-задач (вариантов использования), которые позволяет выполнять приложение (ширина приложения], и глубину уровня, до которого реализуется каждый вариант использования. Бизнес-требования позволяют понять, для каких вариантов использования необходима надежная и полная функциональность, а для каких достаточно поверхностной реализации, по крайней мере на первое время.
Бизнес-требования влияют на приоритеты реализации вариантов использования и связанные с ними функциональные требования, также существенно влияют на способ реализации требований.
Бизнес-требования описывают основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Для различных типов продуктов — информационных систем, коммерческих пакетов ПО и систем контроля, работающих в режиме реального времени, — выделяются различные преимущества.
Исходные данные. Суммирует обоснование и содержание нового продукта. Возможности бизнеса. Для коммерческого продукта описывают существующие
рыночные возможности и рынок, на котором продукту придется конкурировать с другими продуктами. Для корпоративной информационной системы описывают бизнес-проблему, которая разрешается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт, а также среду, в которой система будет использоваться.
Бизнес-цели и критерии успеха. Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде.
Потребности клиентов или рынка. потребности типичных покупателей или целевых сегментом рынка, включая потребности, которые не удовлетворяют настоящие продукты или информационные системы.
Бизнес-риски. Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта. В категории рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы, влияющие на бизнес.
27.Требования пользователей
Требования к ПО состоят из трех уровней:
−бизнес требования;
−требования пользователей;
−функциональные требования.
Вдобавок каждая система имеет свои нефункциональные требования.
Бизнес-требования формируют каркас всего проекта. Любые другие функции и требования к продукту должны удовлетворять бизнес-требования. Тем не менее бизнестребования не предоставляют разработчикам достаточно информации для создания продукта.
Следующий уровень требований — требования пользователей: их определяют те, кто прямо или косвенно взаимодействуют с продуктом, то есть конечные пользователи. Они способны описать требуемую функциональность, а также ожидаемые качественные характеристики продукта.
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия
(scenario).
Требования пользователей - user requirement — цели и задачи, которые пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы событие — отклик . Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
28.Спецификация требований к ПО
Цель этой стадии — разработка требований к ПО. Она является основой для разработки и проведения приемо-сдаточных испытаний.
Главным моментом при составлении Спецификации является достижение взаимопонимания между разработчиком и заказчиком. Все требования к ПО должны одинаково пониматься как Разработчиком, так и Заказчиком. Именно на этой стадии жизненного цикла начинается визуальное моделирование и создаются первые диаграммы на UML. С другой стороны, процесс определения требований к ПО не сводится только к моделированию. От того, насколько полно и детально будут сформулированы требования, во многом зависит успех проекта в целом.
Разработка спецификации включает два основных процесса:
−обследование организации и анализ
−моделирование требований.
Обследование организации (бизнес-анализ)
Цели бизнес-анализа заключаются в следующем:
−понять структуру и динамику работы организации;
−определить проблемы, возникающие в работе организации, и возможности их
решения, направленного на повышение эффективности работы организации;
−гарантировать, что заказчики, конечные пользователи и разработчики будут иметь одинаковое понимание деятельности организации;
−вывести требования к программным системам, автоматизирующим работу организации.
Основным результатом бизнес-анализа является бизнес-модель, которая представляется на языке UML. Она включает:
−Структуру организации
−Cтатическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.
−Модель видов деятельности, описывающую бизнес-актеров и виды деятельности организации.
−Объектную модель включающую бизнес-актеров, исполнителей и бизнес-сущности, а также описание их взаимодействий при реализации видов деятельности.
−Модель предметной области, которая является подмножеством объектной модели.
При построении бизнес-модели используют нормативные документы организации (устав, штатное расписание и др.), а также информацию, предоставляемую заинтересованными лицами, для чего проводятся интервью и совещания, заполняются анкеты и опросные листы. Организация описывается как с внешней точки зрения — какие результаты предоставляются ее клиентам,- так и с внутренней — исполнители и их связи с деятельностью организации.
Анализ и моделирование требований
Требование — это условие или характеристика, которой должно удовлетворять разрабатываемое ПО. Функциональные требования определяют действия, которые должно выполнять ПО, без учета физических ограничений. Нефункциональные требования не описывают поведение ПО, но описывают его атрибуты или атрибуты окружения.
Целями процесса анализа и моделирования требований являются:
−достижение соглашения между Разработчиком и Заказчиком;
−ограничение функциональности ПО;
−создание базиса для планирования разработки проекта;
−определение пользовательского интерфейса;
−составление Спецификации требований (Технического задания).
Для достижения поставленных целей технология предусматривает создание следующих документов:
−Модель требований;
−Спецификация;
−Глоссарий.
Эти документы описывают, что должно делать ПО (но не как оно это делает!). Источниками информации являются эксперты заказчика и потенциальные конечные пользователи.
Спецификация описывает все требования к ПО (функциональные и нефункциональные). Она представляет собой текстовый документ, который определяет набор требований к конечному продукту (но не к процессу его разработки) и не содержит деталей реализации. Спецификация составляется как результат совместной работы аналитиков из Разработчика и экспертов Заказчика и является базисом для достижения соглашения между заказчиком и исполнителем.
Спецификация должна описывать:
−Функциональность. Все требования, должны быть точно сформулированы и одинаково пониматься заказчиком и исполнителем.
−Внешние интерфейсы. Как ПО взаимодействует с пользователями, оборудованием и
другими системами?
−Атрибуты ввода и вывода. Определяют вводимые и выводимые данные.
−Ограничения на функциональность.
−Производительность. Скорость, надежность, время ответа, время восстановления и
т.д.
−Прочие нефункциональные требования.
−Глоссарий определяет терминологию, общую для всех моделей и текстовых описаний
ПО.
Построение модели требований этот процесс включает три основных вида деятельности — Моделирование требований, Архитектурный анализ, и Функциональный реинжиниринг.
При использовании ОО подхода создается модель требований, которая служит для представления функциональных требований в удобном для понимания человеком графическом виде. Она включает актеров и варианты использования (ВИ), описываемые на UML в виде use case диаграмм.
29.Концепция новой ИС
Работы по созданию концепции новой ИС 1. первый документ – анализ предложений по совершенствованию характеристик и
выработка первичных требований к новой ИС, содержит обобщенные выводы и рекомендации:
a.формирует цели и задачи новых бизнес-процессов
b.определяет требования к бизнес-процессам и функциям новой ИС
c.обосновывает состав автоматизированных функций и комплексов задач с
указанием их очередности при разработке
d. формирует требования к характеристикам функций в соответствии с действующими нормативами к ИС конкретного вида
2. предварительное описание к постановке комплекта функциональных задач для проектирования новой ИС, содержит:
a.характеристики нового комплекса задач
b.характеристики бизнес-процессов ИС
c.ограничения бизнес-процессов и комплекс ИС
d.что наследуется из старой ИС
e.перечень объектов внешней среды, с которой будет взаимодействовать ИС
f.периодичность и продолжительность решения задач
g.входная информация:
i. |
источники информации |
|
|
ii. |
предварительное описание объемов, сроков |
представления |
и частоты этой |
информации |
|
|
|
iii. |
перечень структурных границ информации |
со ссылкой |
на конкретные |
документы |
|
|
|
h.выходная информация:
i.получатели
ii.назначение
iii.перечень и описание выходных сообщений
iv.периодичность выдачи сообщений, задержка
3.третий документ – предварительное описание характеристик внешней среды новой и модернизируемой ИС: перечень объектов, которые взаимодействуют с ИС, их характеристики,
средства коммуникаций, при удаленной обработке учитываются технические и программные ресурсы
4.четвертый документ – предварительный анализ доступных ресурсов и ограничений на проектирование ИС
5.пятый документ – предварительное технико-экономическое обоснование
альтернативных вариантов новой ИС, содержит:
a.ожидаемые экономические и социальные результаты
b.перечень основных источников экономической и социальной эффективности при
внедрении новой ИС
c.ожидаемые затраты на каждый вариант
6.шестой документ – предварительная идеальная модель бизнес-процессов и модель функционирования новой ИС, содержит:
a.результат анализа объекта информатизации, перечень рекомендаций к ИС
b.идеальная модель потоков событий в ИС с точки зрения пользователя, т.е. все сущности ИС, интерфейсы, управляющие объекты и др.
c.графический прототип – модель, которая демонстрирует основные средства и функции подсистем, краткое описание БД, каждой функции, подсистемы.
7.седьмой документ – отчет о разработке концепции, включает:
a.описание результатов обследования
b.описание и оценка преимуществ и недостатков альтернативных вариантов концепций
c.сопоставительный анализ требований к ИС с точки зрения заказчика
d.обоснование выбора оптимального варианта
e.ожидаемые эффективность и результаты этого варианта
f.описание и графическое представление идеальной модели без реальных ограничений
g.ориентированный план реализации выбранного варианта
h.ориентировочный перечень мероприятий, необходимых для перехода от старой ИС к
новой
i.затраты на разработку, ввод и функционирование ИС
j.принципы испытаний к приемке новой ИС
k.первичная оценка целесообразности новой ИС или модернизации старой ИС