Лекция2_1. Организация и методы сбора информации. Анализ предметной области. Основные понятия системного и структурного анализа
 Скачать 111.87 Kb.
|
Организация и методы сбора информации. Анализ предметной области. Основные понятия системного и структурного анализа. Предметную область можно определить, как сферу человеческой деятельности, выделенную и описанную согласно установленным критериям. В описываемое понятие должны входить сведения об ее элементах, явлениях, отношениях и процессах, отражающих различные аспекты этой деятельности. В описании предметной области должны присутствовать характеристики возможных воздействий окружающей среды на элементы и явления предметной области, а также обратные воздействия этих элементов и явлений на среду. Работа по изучению и анализу предметной области: проектировании информационных систем оказывает решающее влияние на эффективность ее работы. Специфика предметной области может оказывать существенное влияние на характер функционирования проектируемой системы, выбор метода представления знаний, способов рассуждения о знаниях, и т. д. Предметную область можно определить как объект или производственную систему со всем комплексом понятий и знаний о ее функционировании. При исследовании проблемной области необходимы знания о задачах, решаемых в производственной системе, и стоящих перед ней целях. Определяются также возможные стратегии управления и эвристические знания, используемые в процессе эксплуатации производственной системы. Анализ предметной области (анализ осуществимости, бизнес - моделирование) Одна из первых задач, с решением которых сталкивается разработчик программной системы - это изучение, осмысление и анализ предметной области. Дело в том, что предметная область сильно влияет на все аспекты проекта: требования к системе, взаимодействие с пользователем, модель хранения данных, реализацию и т.д. Анализ предметной области, позволяет выделить ее сущности, определить первоначальные требования к функциональности и определить границы проекта. Модель предметной области должна быть документирована, храниться и поддерживаться в актуальном состоянии до этапа реализации. Для документирования могут быть использованы различные средства. Для управления обсуждением области действия проекта можно использовать методику "будет - не будет". В простейшем случае - это список с двумя столбцами, в одном из которых записывается, что проект будет делать, а во втором - что не входит в проект. Такой список, формируется заинтересованными лицами при рассмотрении каждой бизнес-цели проекта, используя любую технику, например метод "мозгового штурма" (см. тему "Выявление требований"). Полученные характеристики позволяют четко определить границы проекта и довольно просто преобразуются в предположения, которые фиксируются в документе. Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список "Действующее лицо/Цель", в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу - цель каждого действующего лица, а в третью - приоритет или предположение о том, в какую версию войдет эта услуга. Формы списков приведены на рисунке. Для определения основных функций продукта можно использовать, например, краткое описание варианта использования. Описание каждой функции можно представить также в виде списка, состоящего из трех граф: действующее лицо, цель и краткое описание варианта использования. Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта. Анализ осуществимости Разработка новых программных систем должна начинаться с анализа осуществимости. На основании анализа предметной области, общего описания системы и ее назначения необходимо принять решение о продолжении или завершении проекта. Для этого необходимо ответить на следующие вопросы. Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика? Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени? Можно ли объединить систему с другими уже эксплуатируемыми системами? Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того, что произойдет с организацией, если система не будет введена в эксплуатацию; как система будет способствовать целям бизнеса; какие текущие проблемы поможет решить система и т.д. После получения и обработки информации готовится отчет, в котором должны быть даны рекомендации относительно продолжения разработки системы. Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы. Вопросы, которые ему стоит задать, это: Почему вообще пошла речь о создании системы? В чём Вы видите её назначение? Какие бизнес-возможности она должна реализовать? Какие проблемы должна решить? В качестве "Стандарта" на вопросы такого рода смотрите шаблон документа "StakeholderRequest", например, из RUP. Бизнес-требования может выразить Заказчик или Эксперты предметной области. Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP. Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области. Вопросы по сути сводятся к "Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?" Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области. На основании каких правил - международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. - происходит то, что происходит в предметной области? Результат оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели. Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT (IDEF0, IDEF3, DFD) / ARIS (eEPC и т.д.) / UML (BusinessUse-caseDiagram (BUC) + ActivityDiagram + SequenceDiagram). Это один из сложнейших этапов. Какими свойствами обладает каждое из выделенных понятий - структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью - ER - IDEF1X / UML ClassDiagram (BOM). Существует российский стандарт функционального моделирования P 50.1.028-2001, созданный на основе IDEF0. Определение требований - частично Бизнес-требования и Требования, проистекающие из предметной области вы уже определили выше, теперь осталось исследовать Пользовательские требования и Системные требования и ограничения к отдельным аспектам качества системы. Пользовательские требования, как можно понять, нужно выявлять из общения с потенциальными пользователями системы. Вопросы: На какую систему будет похожа создаваемая? С какими системами и как давно вы работаете? Какое у вас образование? Каковы ваши ожидания от системы - что и как она должна делать, какие задачи помогать решать, как должна выглядеть? Какие шаги необходимо предпринять для решения каждой задачи? В каком случае вы будете считать, что система "Хороша"? Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй (UserStory, Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS, Activity/State UML Diagram. Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике. Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика: Будет ли система единичной или тиражируемой? В каких странах она будет работать? Насколько важна информация, хранящаяся, обрабатываемая и передающаяся системой? Каков возможный ущерб от потери той или иной информации? Сколько пользователей будет работать с системой сегодня, завтра, через год? Переработанный результат оформляется в виде Системных требований (SoftwareRequirementSpecification, стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде SupplementarySpecificaion из RUP). Приложения для настольных компьютеров подобны широкоугольным объективам в том смысле, что в типичных случаях они отображают значительный объем информации, который позволяют предоставлять пользователю экраны большого размера. В отличие от этого мобильные приложения напоминают увеличительное стекло или объектив с переменным фокусным расстоянием. Они предоставляют пользователю возможность быстро просматривать необходимые подробные данные, быстро переходить к ограниченным наборам данных и получать к ним доступ, а также принимать решения в реальном масштабе времени. Как правило, мобильные приложения пре доставляют более специализированный набор сценариев по сравнению с приложениями, ориентированными на настольные компьютеры. Очень важно точно определиться с тем, на каких сценариях должно специализироваться ваше приложение. Прежде чем приступать к реальной разработке приложения, определите подмножество функциональных средств, к которым пользователь сможет получать быстрый доступ в манере, свойственной мобильным устройствам. В случае создания нового приложения, аналога которого для настольных компьютеров не существует, выпишите ключевые сценарии, которые пользователи смогут выполнять с помощью вашего приложения, а также порядок действий пользователя, обеспечивающий использование этих сценариев на мобильном устройстве. Во многих случаях вам будет легче придать этим сценариям реальные очертания, если вы подготовите соответствующие рисунки или создадите прототипы. Если подразумевается определенная группа конечных пользователей, пообщайтесь с ними и предоставьте им возможность поработать некоторое время с экспериментальными версиями своих приложений, чтобы они могли дать о них свои отзывы. Оптимальный подбор предоставляемых средств определяет все остальное Если вы правильно выделите ключевые сценарии и возможности вашего приложения, то это окажет определяющее влияние на всю оставшуюся часть процесса разработки. Наличие явно сформулированного описания того, как конечные пользователи будут использовать ваше приложение, и детальное понимание их потребностей окажут вам неоценимую помощь при настройке производительности приложения, а также проектировании пользовательского интерфейса, коммуникационной системы и модели памяти. Если вы не определите важнейшие с вашей точки зрения сценарии и возможности, то в результате вы получите бессистемную смесь средств, объединенных в одно приложение. Отсутствие явного списка основных функций приложения или разделения функций на группы в соответствии с их приоритетами приведет к тому, что пользовательский интерфейс не будет оптимизирован для эффективного решения ключевых задач. Например, если ожидается, что пользователь в основном будет заинтересован во вводе данных, то вы должны оптимизировать пользовательский интерфейс таким образом, чтобы обеспечить как можно более точное и надежное выполнение операций ввода. И наоборот, если ввод данных используется лишь изредка, то вариант пользовательского интерфейса ввода, оптимизированного не самым идеальным образом, может оказаться вполне допустимым, что позволит перебросить ресурсы проектирования и разработки на другие направления. Лишь только если группой разработчиков будут идентифицированы, перечислены и согласованы наиболее важные сценарии, эксплуатационные характеристики приложения могут быть настроены для их выполнения должным образом, а конечные пользователи не будут лишены важных для них средств из-за недосмотра. Чтобы процесс разработки мог быть успешно завершен, составьте список ключевых требовании, которым должно удовлетворять приложение, и возможностей, которые оно должно обеспечивать, и пусть этот список будет первым разделом вашего основного документа проекта. Основные понятия системного анализа Системный анализ - наука, занимающаяся проблемой принятия решения в условиях анализа большого количества информации различной природы. Цель системного анализа (к конкретной проблеме)-повышение степени обоснованности принимаемого решения из множества вариантов, среди которых производится выбор, с одновременным указанием способов отбрасывания заведомо невыгодных. В системном анализе выделяют методологию; аппаратную реализацию; практические приложения. Методология включает определения используемых понятий и принципы системного подхода. Элемент - некоторый объект (материальный, энергетический, информационный), который обладает рядом важных для нас свойств, но внутреннее строение (содержание) которого безотносительно к цели рассмотрения. Связь - важный для целей рассмотрения обмен между элементами веществом, энергией, информацией. Система - совокупность элементов, которая обладает следующими признаками: связями, которые позволяют посредством переходов по ним от элемента к элементу соединить два любых элемента совокупности; свойством, отличным от свойств отдельных элементов совокупности. Практически любой объект с определенной точки зрения может быть рассмотрен как система. Вопрос состоит в том, насколько целесообразна такая точка зрения. Большая система - система, которая включает значительное число однотипных элементов и однотипных связей. В качестве примера можно привести мост с пролетами и опорами. Сложная система - система, которая состоит из элементов разных типов и обладает разнородными связями между ними. В качестве примера можно привести ЭВМ, самолет или судно. Автоматизированная система - сложная система с определяющей ролью элементов двух типов: -в виде технических средств; -в виде действия человека. Для сложной системы автоматизированный режим считается более предпочтительным, чем автоматический. Например, посадка самолета или управление автомобилем выполняется при участии человека, а автопилот или бортовой компьютер используется лишь на относительно простых операциях. Типична также ситуация, когда решение, выработанное техническими средствами, утверждается к исполнению человеком. Структура системы - расчленение системы на группы элементов с указанием связей между ними, неизменное на все время рассмотрения и дающее представление о системе в целом. Указанное расчленение может иметь материальную, функциональную, алгоритмическую или другую основу. Пример материальной структуры - структурная схема сборного моста, которая состоит из отдельных, собираемых на месте секций и указывает только эти секции и порядок их соединения. Пример функциональной структуры - деление двигателя внутреннего сгорания на системы питания, смазки, охлаждения, передачи крутящего момента Пример алгоритмической структуры - алгоритм программного средства, указывающего последовательность действий или инструкция, которая определяет действия при отыскании неисправности технического устройства. Структура системы может быть охарактеризована по имеющимся в ней типам связей. Простейшими из них являются последовательное, параллельное соединение и обратная связь Декомпозиция- деление системы на части, удобное для каких-либо операций с этой системой. Примерами будут: разделение объекта на отдельно проектируемые части, зоны обслуживания; рассмотрение физического явления или математическое описание отдельно для данной части системы. Иерархия - структура с наличием подчиненности, т.е. неравноправных связей между элементами, когда воздействие в одном из направлений оказывают гораздо большее влияние на элемент, чем в другом. Виды иерархических структур разнообразны, но важных для практики иерархических структур всего две - древовидная и ромбовидная Древовидная структура наиболее проста для анализа и реализации. Кроме того, в ней всегда удобно выделять иерархические уровни - группы элементов, находящиеся на одинаковом удалении от верхнего элемента. Пример древовидной структуры - задача проектирования технического объекта от его основных характеристик (верхний уровень) через проектирование основных частей, функциональных систем, групп агрегатов, механизмов до уровня отдельных деталей. Принципы системного подхода- это положения общего характера, являющиеся обобщением опыта работы человека со сложными системами. Их часто считают ядром методологии. Это такие принципы, как: -принцип конечной цели: абсолютный приоритет конечной цели; -принцип единства: совместное рассмотрение системы как целого и как совокупности элементов; -принцип связности: рассмотрение любой части совместно с ее связями с окружением; -принцип модульного построения: полезно выделение модулей в системе и рассмотрение ее как совокупности модулей; -принцип иерархии: полезно введение иерархии элементов и(или) их ранжирование; -принцип функциональности: совместное рассмотрение структуры и функции с приоритетом функции над структурой; -принцип развития: учет изменяемости системы, ее способности к развитию, расширению, замене частей, накапливанию информации; -принцип децентрализации: сочетание в принимаемых решениях и управлении централизации и децентрализации; -принцип неопределенности: учет неопределенностей и случайностей в системе. Аппаратная реализация включает стандартные приемы моделирования принятия решения в сложной системе и общие способы работы с этими моделями. Модель строится в виде связных множеств отдельных процедур. Системный анализ исследует как организацию таких множеств, так и вид отдельных процедур, которые максимально приспосабливают для принятия согласующихся и управленческих решений в сложной системе. Модель принятия решения чаще всего изображается в виде схемы с ячейками, связями между ячейками и логическими переходами. Ячейки содержат конкретные действия - процедуры. Совместное изучение процедур и их организации вытекает из того, что без учета содержания и особенностей ячеек создание схем оказывается невозможным. Эти схемы определяют стратегию принятия решения в сложной системе. Именно с проработки связанного множества основных процедур принято начинать решение конкретной прикладной задачи. Отдельные же процедуры (операции) принято классифицировать на формализуемые и неформализуемые. В отличие от большинства научных дисциплин, стремящихся к формализации, системный анализ допускает, что в определенных ситуациях неформализуемые решения, принимаемые человеком, являются более предпочтительными. Системный анализ рассматривает в совокупности формализуемые и неформализуемые процедуры, и одной из его задач является определение их оптимального соотношения. Формализуемые стороны отдельных операций лежат в области прикладной математики и использования ЭВМ. В ряде случаев математическими методами исследуется связное множество процедур и производится само моделирование принятие решения. В этом и состоит математическая основа системного анализа. Такие области прикладной математики, как исследование операций и системное программирование, наиболее близки к системной постановке вопросов. Практическое приложение системного анализа чрезвычайно обширно по содержанию. Важнейшими разделами являются научно-технические разработки и различные задачи экономики. |