Майкл ДМерс ГИС. Инициаторы проведения этого новаторского события надеются привлечь к нему внимание мировой общественности и широких масс пользователей географических информационных систем из всех стран.
 Скачать 4.47 Mb.
|
|
Глава 14 Интерактивный вывод Возможно, классическим примером замены картографического вывода альтернативной формой является использование ГИС в службе спасения. Если вызов требует тушения пожара, то ГИС позволяет одновременно с принятием вызова оператором определить ближайшую к указанному адресу пожарную часть и направить в нее электронный сигнал тревоги. То есть, в данном случае выводом ГИС будет не карта, а электронный сигнал. Кроме того, та же ГИС может определить кратчайший маршрут для пожарной машины и нанести его на карту, а саму карту дополнить маршрутным листом, в котором перечислены улицы, перекрестки и иные отметки, позволяющие пройти маршрут без помощи карты. Хотя эксплуатируемые сегодня системы не так интеллектуальны, технические возможности вполне позволяют реализовать описанный сценарий, в котором альтернативный вывод может как дополнять карту, так и заменять ее.  Рисунок 14.12. Сплошные картограммы и картограммы с разрывами. Таблицы и графики Существуют многие альтернативные виды вывода из ГИС [Garson and Biggs, 1992], но более других распространены таблицы и графики, которые, помимо прочего, не требуют для вывода дорогостоящего оборудования. Таблицы и графики могут существенно улучшить понимание картографических результатов. Представьте себе, что вы анализируете изменение распределения типов землепользования в процессе вытеснения жилой застройкой естественной среды и сельскохозяйственных угодий. Серия карт показывает области наиболее существенных изменений. Вы можете прямо в легенды карт вставить таблицы процентов по типам землепользования на каждый момент времени. Кроме того, под каждой картой можно поместить столбчатую диаграмму распределения классов землепользования, а также изменения с предыдущего момента. Можно также создать матрицу, показывающую изменения "от" и "до" для всех моментов времени. Такая таблица поможет понять, какие типы землепользования в основном поглотили естественную среду, какие - сельхозугодия. Как и в случае с картами, в дизайне не картографического вывода также есть свои принципы. Таблицы в ГИС чаще всего встречаются в легендах карт для связывания атрибутивных данных с графическими объектами карты и как распечатки значений атрибутов объектов. К ним может также прилагаться содержимое словаря данных для детального описания данных и дополнения легенды карты. Вопросы дизайна текстового вывода включают общие идеи назначения, читабельности и целевой аудитории, знакомые вам из раздела о картографическом дизайне. В вопросе назначения следует подумать о том, насколько эффективно текст и таблицы могут дополнить или полностью заменить картографический вывод. Текст и таблицы понятны практически всем, и вопросы читабельности достаточно общеизвестны, вспомним основные. Используемый шрифт должен быть простым, без украшательств. Цвет и яркость символов и фона должны образовывать хороший контраст. Таблицы и текст желательно отделять от карты рамкой. Не следует злоупотреблять сокращениями, - чем меньше таблица требует объяснений, тем она удобнее. Для групп близких по смыслу строк или столбцов можно использовать дополнительное выделение, например, цветом. В общем, как и с картами, здесь следует полагаться на здравый смысл и чувство визуального баланса. Рассматривая создаваемые таблицы с точки зрения целевой аудитории, следует использовать терминологию, понятную клиенту. Информация, которая содержится в таблицах, не должна быть избыточной, - избыток не только не интересен, но и может породить путаницу. Поэтому перед созданием табличного вывода следует выяснить, что именно нужно пользователю, и как это лучше представить. Вряд ли будет полезен монстр с полусотней столбцов и не меньшим числом строк. Наверняка его можно было бы заменить серией графиков и диаграмм, которые в изобилии имеются в программах электронных таблиц и деловой графики*. *Например, ГИС-продукты компании ESRI поддерживают связи с такими программами и статистическими системами. Во многих случаях можно также использовать стандартные механизмы передачи данных между приложениями, подобные DDE и Clipboard в Windows. — прим. перев. Обычно графики строятся в декартовых координатах; реже встречается другой тип координат - полярные, в которых координатами являются угол и длина вектора, проведенного из начальной точки. На простых графиках данные изображаются точками, которые часто соединяются прямыми отрезками или плавной кривой. Довольно часто используется другой вид графиков - гистограммы, в которых вместо точек используются столбцы, расположенные вертикально или горизонтально; они лучше подходят для изображения небольшого количества дискретных данных. Следует отметить еще один интересный тип графиков - аддитивный. В нем одновременно показываются значения нескольких параметров, причем столбцы строятся не на общей оси и не на отдельных осях, а прямо друг на друге, что отражает аддитивный характер этих показателей. Например, такими параметрами могут быть процентные содержания песка, ила и глины в почве, которые в сумме составляют сто процентов. Построение графиков благодаря компьютеру стало почти что тривиальной задачей. Сами программы их построения предлагают много дополнительных возможностей: использование цветов, объемных букв, линий и фигур, занимательных символов и т.д. На самом деле, такие украшательства в большинстве случаев не нужны, они только ухудшают читабельность вывода и напрягают зрение. Все решения о графическом представлении должны следовать основному критерию - простота и разборчивость. Значимые линии должны выделяться на общем фоне. Координатная сетка не должна быть слишком частой и заслонять собой сам график. Координатные оси должны доходить до максимальных значений изображаемых величин, желательно также наносить на оси максимальные и минимальные значения координат. При совмещении нескольких графиков следует позаботиться о том, чтобы масштаб для каждого показателя не вводил зрителя в заблуждение, что малые величины больше, чем они есть в реальности, и наоборот. В настоящее время имеется большой объем литературы по деловой графике и графическому представлению, к которой и следует обращаться для детального изучения этого вопроса [Cleveland and McGill, 1988; Holmes, 1984; Meilach, 1990; Robertson, 1988; Sutton, 1988; Tufte, 1983; Zelazny, 1985]. Наконец, следует упомянуть новую возможность некартографического вывода, становящуюся все более популярной - фотоснимки. Недаром говорят, что лучше один раз увидеть, чем сто раз услышать. Эти изображения могут быть получены сканированием обычных фотографий, съемкой цифровыми фотоаппаратами, оцифровкой отдельных кадров видеосъемки. Они позволяют показывать здания, характер местности, образцы растений и животных. Такие изображения, хранимые в атрибутивной БД, помогают существенно улучшить понимание того, что представлено на карте. Как и в прочих случаях, не стоит злоупотреблять этой возможностью, так как для хранения снимков требуется нередко значительное дисковое пространство, а сами изображения по своей природе способны отвлекать внимание зрителя от карты, к которой они являются всего лишь иллюстрациями. То есть, использовать их нужно лишь тогда, когда они действительно добавляют нечто уместное и важное к основному выводу. Вопросы
 Проектирование ГИС  Наше путешествие в мир геоинформатики подходит к концу. Мы прошли путь от представления географических объектов в цифровой форме до организации их в сложные модели, от ответов на простейшие вопросы до комплексного анализа множественных покрытий. Наш географический фильтр расширился, - теперь мы имеем гораздо больше возможностей для концептуализации, регистрации и анализа нашего окружения и представления результатов этого анализа. И теперь мы не только можем сами использовать полученные знания, но и показывать другим полезность компьютеризованной географии в широком спектре исследований. Эти знания пригодятся нам в новых путешествиях, в серьезных приложениях реального мира, и в данной главе мы рассмотрим, как следует планировать каждый проект, чтобы он был успешным. Главная тема главы - проектирование: выбор инструментария, определение объектов и их отношений, выбор области исследования, оценка данных, — все, что нужно для построения работоспособной ГИС. Важность хорошего проектирования очевидна: большинство проблем с неработоспособными или плохо работающими ГИС проистекают из некачественной разработки. Система не даст ожидаемых результатов при плохо организованных данных, некорректных моделях данных или ограничениях функциональности программного обеспечения; иногда менеджеры системы недооценивают временные затраты, необходимые для создания БД. С другой стороны, качественно спроектированная система может использоваться не на полную мощность, либо из-за ее сложности, либо просто из-за незнания персоналом всего потенциала системы. Первоначально полезные системы могут потерять свою актуальность из-за старения программного и аппаратного обеспечения, данных или методики работы, которые снижают гибкость системы в изменяющихся условиях. Наконец, возможны случаи провала из-за изменения организационной структуры в связи с внедрением новой технологии в среду, основанную на ручной работе. Многое из того, что мы можем сказать о хороших системах, узнается на опыте неудачных систем, - подобно тому, как успех в бизнесе зависит от способности учиться на чужих ошибках. Хотя некоторые ГИС создаются для внутреннего использования организацией-разработчиком, большинство систем создается на заказ, для других организаций, использующих их в своей работе. По этой причине мы уделим основное внимание организационной стороне проектирования ГИС. Другая причина в том, что успешность системы в научно-исследовательском окружении во многом основана на тех же критериях, что и успех в коммерческой среде. Если вы можете создать систему, работоспособную в условиях финансово-чувствительной коммерческой среды, то сможете достичь успеха и в других обстоятельствах. Успех проекта зависит не только от знания моделей данных и алгоритмов, но и от умения организовать работу для сборки их в нечто единое и подчиненное конечной цели системы, в чем знание теории бизнес-ориентированных систем и исследования операций может быть не менее ценным, чем навыки географа. Так что, закончив эту главу, следует не почивать на лаврах, а продолжать начатое путешествие. ЧТО ТАКОЕ ПРОЕКТИРОВАНИЕ ГИС? Первые ГИС стали появляться в 1960-х годах. Одни из них создавались в целях эксперимента в университетах, другие - как оперативные системы, подобно большинству создаваемых сегодня систем. Большинство из них не имели успеха: в одних случаях они вообще не работали как аналитический инструмент, в других - давали ошибочные результаты, в третьих - просто зависали. Такие системы не выжили главным образом потому, что были плохо спроектированы как программные системы. Однако сегодня можно наблюдать все большее число успешно работающих пространственно-аналитических средств, которые могут и не быть чисто географическими информационными системами, но выполняют свои задачи эффективно и за умеренную цену. Большинство проблем, связанных с ГИС сегодня, - не технические. На самом деле, современный уровень возможностей программ существенно превосходит требования сообщества пользователей, особенно в коммерческих приложениях. Главная проблема - частое несоответствие возможностей программного обеспечения и нужд пользователей: в данных, в анализе, в обучении, в признании пользователями. К сожалению, проблемам разработки до сих пор уделяется недостаточно внимания. Поэтому мы и рассмотрим проектирование ГИС, в основном как вариант общей разработки программного обеспечения, который может быть полезным для создания успешной ГИС. НЕОБХОДИМОСТЬ ПРОЕКТИРОВАНИЯ ГИС Проектирование не является гарантией успеха, недостижение которого может быть следствием и других причин, например, неадекватного маркетинга. Но в большинстве случаев оно позволяет увеличить шансы на успех. Конечно, ошибки в программах обычно не так опасны, как ошибки в ракетных двигателях, но действие их может быть незаметным, а поэтому более коварным, как в смысле обнаружения их присутствия, так и поиска того места программы, в котором кроется ошибка. Ошибки могут приводить к зависанию компьютера и потере данных. Воздействие даже одной простой ошибки может быть существенно усилено огромным количеством последующих операций над испорченными данными, и это распространение может продолжаться довольно долго, пока не будет обнаружено явное расхождение ожидаемого и получаемого. Значение проектирования геоинформационных систем особенно велико, поскольку они относятся к разряду наиболее сложных коммерческих программных систем. Даже если вычислительная точность соблюдена и данные введены без ошибок, нельзя забывать о существовании различных групп потенциальных пользователей и специфике задач, решаемых этими группами. В связи с этим мы должны понимать, что, особенно в многопользовательской организации важно учесть потенциальных пользователей на стадии проектирования. Так, например, системы в общественном секторе создаются для ответов на запросы о довольно больших территориях, таких как районы, области, регионы. Тем не менее, вы можете обнаружить, что многие государственные организации разрабатывают крупные базы данных без особой консультации или взаимодействия с другими заинтересованными сторонами. Такой близорукий подход дублирует усилия, приводя к ненужному расходу времени и денег [DeMers and Fisher, 1991). Проблема - в незнании других потенциальных пользователей тех же самых БД. Многие ГИС разрабатывались без предварительной оценки использования системы или вообще без указания потенциальной клиентуры. В качестве примера можно привести Региональную программу оценки окружающей среды на основе спутниковых данных, запущенную в штате Северная Дакота в 1970-х годах, когда стала очевидной полезность в оценке окружающей среды с применением данных со спутников LANDSAT. Хотя идея имела хорошее научное обоснование, клиентуры для использования результатов программы не существовало, что привело в конце концов к прекращению государственного финансирования этой программы. Касаясь второго вопроса - удовлетворения системой потребностей пользователей, - мы рассматриваем главным образом возможности программного обеспечения, требования к данным и соответствие задачам организации. Первые два пункта указывают на то, что знание функциональных возможностей системы и конструирования баз данных очень важно для долговременного функционирования ГИС. Перед тем, как будет приобретена ГИС с ее моделью данных и аналитическими способностями, должны быть четко определены потребности клиента в обработке пространственных данных. Например, задачи учета земель легче решаются с использованием векторной модели данных, тогда как задачи поверхностного моделирования или постоянного обновления данных на основе космоснимков могут быть легче удовлетворены системой с растровой моделью данных. В обоих случаях требования обработки данных диктуют тип используемой системы и ее аналитические возможности. Иметь соответствующие задачам организации данные и программы - еще не всё. Система должна также соответствовать профилю работ организации и ее персоналу. Как сами ГИС различаются по тому, что и как они делают, так и организации, использующие ГИС, различаются в своей деятельности. Университетская среда будет скорее всего местом сложных экспериментов на грани возможностей ГИС. Кроме того, там часто меняются исследуемые вопросы, а данные системы и аналитические потребности весьма переменчивы или едва определены [Burrough, 1986]. Частая смена персонала с различным уровнем подготовки, бюджетные ограничения, сроки выполнения исследовательских программ, - все это требует определенных параметров от университетской ГИС. Напротив, коммерческие организации имеют больше денег, более стабильный персонал, более определенные и более узкие рамки приложений. Кроме того, аналитические возможности могут быть менее широкими по сравнению с институтами. Организации, финансируемые государственными органами, имеют потребности в данных и анализе, вытекающие из их полномочий. Бэрроу [Burrough, 1987] дает отличный набор общих идей, связанных с работой ГИС в этих различных средах. И хотя такие обобщения создают хороший фундамент для принятия решений, немногие организации полностью вписываются в данную структуру. Следует учитывать, что каждая организация уникальна и должна рассматриваться именно так для наилучшего использования ГИС. Эта точка зрения позволяет нам также считать организацией наш собственный проект, особенно если он выполняется группой людей, занятых лабораторной работой, независимым исследованием или работой по гранту. ВНЕШНИЕ И ВНУТРЕННИЕ ВОПРОСЫ ПРОЕКТИРОВАНИЯ ГИС Прежде всего нам нужно договориться о терминах. Рисунок 15.1 показывает, что процесс проектирования в целом распадается на две основных составляющих - системное проектирование и проектирование программного обеспечения.  Рисунок 15.1. Процесс проектирования ГИС. Проектирование программного обеспечения требует досконального знания структур данных, моделей данных и программирования. Эта работа относится к наиболее высоко оплачиваемым в данной профессии и требует соответствующей компьютерной технической или научной степени вдобавок к знанию основ ГИС. Но нашим главным интересом является второй вопрос. Системное проектирование рассматривает взаимодействие отдельных людей, групп людей и компьютеров внутри организаций [Yourdon, 1989]. Этот аспект расширяет определение того, что такое ГИС. Это не только вычисления. Это также влияние внедрения системы на людей, на то как они выполняют свою работу, и как это, в свою очередь, влияет на функционирование самой организации. Автомобильная промышленность прошла путь от индивидуальной сборки автомобилей через конвейерное производство до внедрения роботов. Геоинформационные системы, как многообещающая технология, могут оказать сходное влияние на коммерческие, государственные и научные организации. Подобно тому, как компьютерные программы редактирования текста и справочные системы библиотек радикально изменили способ написания научных статей, так и ГИС фундаментально изменяют работу организаций, специализирующихся Проектирование ГИС на анализе пространственных данных. Внедрение новой технологии требует дополнительного обучения персонала, денег на приобретение программного и аппаратного обеспечения, оно изменяет потоки информации внутри организации и, следовательно, изменяет структуру самой организации. И теперь, когда появляется всё больше крупных БД, мы должны уделять больше внимания целостности и качеству данных, а доступ к ним многих пользователей поднимает актуальность мер безопасности и контроля качества внутри организации. Системное проектирование ГИС может быть разделено на две взаимодействующие части: техническое проектирование (technical design) (внутренние вопросы) и организационное проектирование (institutional design) (внешние вопросы). Внутренние вопросы чаще всего относятся к функциям системы и БД: Будет ли система работать так, как это требуется? Сможем ли мы получить ответы на вопросы, на которые нам нужно получить ответ? Имеются ли у нас данные в нужном формате? Есть ли у нас сотрудники, имеющие должную подготовку для эксплуатации системы? Сможет ли она меняться при изменении наших потребностей? Таковы некоторые наиболее общие вопросы технического проектирования. Организационные вопросы включают следующие: Имеем ли мы достаточно финансирования для обеспечения длительного функционирования системы? Можем ли мы получить данные за приемлемую цену? Нужно ли нам привлекать прикладных программистов для адаптации программного обеспечения? Получим ли мы достаточную поддержку от поставщиков программ? Будем ли мы нести ответственность на основании закона за ошибки в нашем анализе? Учтены ли цели, находящиеся за пределами окончания выполнения анализа в ГИС? Все эти вопросы важны для организационного проектирования. Техническая сторона проектирования не может быть отделена от организационной. Даже прекрасная с технической точки зрения работа ГИС должна считаться неудачей, если мы теряем поддержку нашей организации или внешнего спонсора. Причины Могут быть самыми разными, в том числе и мнение руководства о чрезмерности расходов на ГИС. И конечно, если ваша система не может дать ответы на задаваемые вопросы, поддержка организации может быть очень быстро утрачена. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Новая дисциплина, называемая разработкой программного обеспечения (ПО) (software engineering), появилась в информатике относительно недавно. Проблемы в создании различных программ часто аналогичны тем, что возникают на стадии реализации ГИС. Целью разработки ПО является создание программ, успешно решающих или помогающих решать задачи, которые прежде выполнялись вручную. В качестве примера можно привести текстовый редактор. Он должен позволять набирать и редактировать текст, проверять правописание, вставлять в текст иллюстрации, изменять шрифт, выводить текст на печать. Ранние программы имели лишь часть этих функций, в то время как сегодня все они являются стандартными для большинства программ редактирования текста. Как показывает этот пример, главная задача - не просто написать хороший программный код, но прежде всего знать, что именно кодировать. При реализации ГИС, перед началом процесса, мы также должны понять потребности пользователя, включая потребности в анализе, обучении, соответствии применяемых аналитических методов общим целям организации. Перед началом написания программного кода мы, как проектировщики ГИС, должны подготовить информацию по структурам данных и моделям, программам, имеющим нужные аналитические возможности при наименьшей цене, системе, наиболее соответствующей целям организации, и требованиям обучения персонала. Принципы проектирования систем Среди первых идей, возникших в области проектирования систем была идея жизненного цикла проекта (project life cycle). В большинстве организаций одновременно выполняются несколько проектов. Для каждого проекта мы должны решать, что и когда должно делаться, и кто ответственен за исполнение. Поскольку каждый проект имеет начало, середину и окончание (как мы надеемся ;-), мы можем сказать, что он имеет жизненный цикл, который, в свою очередь, диктует действия и организационную структуру, ведущие к успешному завершению. Если вы работаете над одним-единственным проектом, главные принципы остаются теми же, хотя детали и различаются. Возможен существенно иной подход к реализации проекта, с иным стилем руководства, иными задачами и другим типом участвующего персонала. Жизненный цикл такого проекта часто развивается в очень гибкой обстановке. Это в особенной степени относится к исследовательским проектам, в которых цели могут меняться в зависимости от промежуточной информации. Организации, больше ориентированные на бизнес, обычно используют более формальный и структурированный подход. При большой длительности проекта или частой смене персонала может быть полезным изменение структуры жизненного цикла проекта для учета нужд новых работников, их роли в проекте. Выполняете ли вы проект самостоятельно, внутри небольшой группы или внутри большой организации, должна быть установлена методика выполнения, обеспечивающая успешное завершение работы. В качестве простого примера жизненного цикла проекта можно привести курсовую работу. Она может потребовать полевой работы, вычислений, анализа, обзора литературы, подготовки результатов, написания. Вы не начинаете (я надеюсь) с написания, пока не завершите подготовительных этапов, - нужен определенный порядок выполнения для достижения конечного результата. Если вы выполняете работу в одиночку, то может быть достаточным определение подзадач и порядка их решения. В условиях многих взаимосвязанных проектов должны быть решены две другие задачи, которые вместе с первой можно формализовать так:
3. Определить точки принятия решений о запуске и остановке отдельных этапов проекта. Важно отметить, что жизненный цикл проекта - только общая его основа, главные решения принимает руководитель. Многие важные аспекты работы организации (внешняя конкуренция, поддержка работников, обеспечение здоровой атмосферы и т.д.) относятся, в принципе, к компетенции руководителя. Жизненный цикл проекта обеспечивает ориентиры для поддержки принятия правильных решений в должное время [Yourdon, 1989]. Линейная модель разработки системы Среди первых методов реализации жизненного цикла проекта была линейная модель (waterfall model) проектирования системы [Boehm, 1981; Royce, 1970] (Рисунок 15.2). Возможны различные состав и число шагов, которые в целом покрывают: определение требований пользователя, определение функциональных потребностей, системный анализ, детальное проектирование, тестирование отдельных модулей, подсистем и системы в целом. Линейная модель обеспечивает упорядоченное движение от анализа требований до ввода информационной системы в эксплуатацию. Обычно она проходит от концептуального проектирования через проектирование программ и написание кода до отладки и окончательного тестирования. При разработке ГИС с использованием линейной модели имеются некоторые проблемы. Поскольку модель требует завершения каждого этапа перед началом следующего, любая задержка на одном этапе замедлит создание всей системы [Yourdon, 1989]. То есть, в контексте ГИС, мы не сможем начать ввод данных, пока не получим все требования пользователя. Хотя это требование кажется вполне обоснованным, новые требования часто обнаруживаются в самом конце этапа их определения, и многие дни или недели, которые могут использоваться для ввода данных, будут потеряны в ожидании абсолютной уверенности, что все требования известны.  Рисунок 15.2. Линейная модель жизненного цикла системы. Другой проблемой данного метода является его линейность. Хотя нам желательно последовательное развитие нашей ГИС, почти каждая реализация сталкивается с трудностями. И, как оказывается, легче внести поправки в несовершенную систему, которую уже видели в работе, чем предсказать все возможные проблемы до начала реализации проекта. Вы, конечно, знаете, что гораздо легче написать черновик и отредактировать его, чем сразу написать целую курсовую работу. Кроме того, клиенты часто пренебрегают важными деталями до начала работ или открывают новые применения ГИС по мере наблюдения за реализацией системы. Может также измениться ситуация с финансированием, в результате чего к проекту могут быть предъявлены иные требования или урезаны дорогостоящие части системы. Следуя линейной модели, мы будем скорее всего иметь завершенную или почти завершенную систему как раз тогда, когда обнаружим, что нужно добавить что-то еще или устранить сделанные на прежних этапах ошибки. Мифический человеко-месяц Ошибки, обнаруживаемые после завершения системы могут показаться не такими уж важными. Но допустим, что мы создали работоспособную систему для внешнего заказчика, и теперь занимаемся другими проектами. Через несколько месяцев звонит клиент и сообщает, что ГИС не позволяет преобразовывать дорожные мили в мили расстояния на карте. Оказывается, что мы забыли включить в программное обеспечение функцию, выполняющую эту операцию. А тем временем, люди, занятые в этом проекте, точнее наши эксперты по транспорту, сменили место работы. Но наша компания остается ответственной за обеспечение недостающей функции. Подумайте о возможных последствиях этой ситуации, которая легко подпадает под заголовок идеи "мифический человеко-месяц", выдвинутой Бруксом [Brooks, 1975]. В простейшей форме эта идея утверждает, что ошибка в одну денежную единицу на первом этапе обойдется в сумму от 400 до 4000 единиц на пятом этапе. Другими словами, ошибки, которые могли быть легко исправлены вначале, вызывают значительные трудности на более позднем этапе. Наиболее распространенным ответом на такое несчастье является "денежное вливание". Таким образом, ответом на недостачу транспортного модуля для ГИС нашего клиента могло бы быть выделение большой группы людей на решение этой задачи. Однако, как предсказывает Брукс, это просто не сработает, эти люди скорее всего не будут знакомы с данным проектом, и ни один из них не будет иметь опыта построения транспортных модулей. Следовательно, нужно потратить время на обучение. Это не только неэффективный способ работы с людьми, но и приостановка других проектов. И пока мы пытаемся срочно повысить компетенцию работников для разработки транспортного модуля, клиент не может выполнять некоторые задачи, для решения которых ГИС приобреталась. Концепция мифического человеко-месяца может применяться и в научных приложениях. Поскольку цели в таком случае часто плохо определены, а также из-за быстрой смены работников-студентов, строго модульный и линейный подход к проектированию часто оказывается неэффективным. Ниже мы рассмотрим возможную альтернативу. Некоторые общие характеристики систем Имеем ли мы дело с программной системой или ГИС-проектом, чем более они специализированы, тем менее приспособляемы для решения новых задач. Разрабатывая, например, ГИС для работы с ДДЗ, вы скорее всего воспользуетесь моделями данных и методами, специфичными для растра. Если же в дальнейшем вы решите включить модель гравитации, использующую векторные данные, инструментарий вашей системы не будет соответствовать новым задачам, и вам придется добавить к ней возможности работы с векторными данными и провести обучение пользователей. Это в чем-то похоже на создание новой системы и помещение ее рядом с уже существующей. Размер системы тесно связан с количеством используемых ресурсов, — чем больше система, тем больше ресурсов нужно для ввода данных, их анализа и администрирования, устройств для вывода результатов, управляющего персонала, следящего за многими этапами анализа. К счастью, системы могут быть разбиты на составляющие части, каждой из которых можно управлять по отдельности, подобно отдельному проекту. Это другая характерная черта систем, имеющая первостепенную важность для крупных систем. С ней сильно связана также идея о том, что многие системы, возможно даже, большинство, имеют тенденцию расти. Поэтому, даже если ваша ГИС первоначально выполняла лишь несколько аналитических задач, по мере роста знаний, мастерства персонала и признания полезности системы управляющим звеном и клиентами, система должна будет расти для соответствия изменившимся условиям. В действительности, чем успешнее ее работа, тем больше вероятность роста. Нужно помнить и том, что успех проекта часто достигается умением "преподнести" его заказчику и спонсорам. Большинство коммерческих систем служат многим людям, следовательно, имеет значение знание их организационного окружения. ОРГАНИЗАЦИОННОЕ ОКРУЖЕНИЕ ГИС Ни одна ГИС не работает "в вакууме". Выполняя свою работу, вам приходится учитывать интересы других пользователей системы, выполняющих свои проекты, или координировать свои собственные усилия с коллегами по проекту. При внешнем финансировании нужно учитывать цели и задачи спонсора. Программное и аппаратное обеспечение часто также поступают со стороны. Как видите, в большинстве проектов имеются многие участники, как внутренние, так и внешние. Связь между системой и внешним миром Рисунок 15.3 иллюстрирует упрощенную модель отношений между ГИС (система) и внешним миром. Внутри системы происходит взаимодействие между людьми, ответственными за повседневную работу ГИС, с теми, кто эксплуатирует систему, и теми, кто отвечает за управление проектом. Это показано на рисунке двухсторонней внутренней стрелкой. Остальные стрелки показывают связи с внешним миром. Теперь определим участников и их взаимодействие.  Рисунок 15.3. Внутренние и внешние участники. Внутренние участники Система включает три основные группы участников, каждая - со своими задачами. Пользователи системы - те, кто используют ГИС для решения пространственных задач - обычно хорошо разбираются в ГИС, хотя возможно, в какой-то одной системе. Их основные задачи это оцифровка, проверка ошибок, редактирование, анализ исходных данных, получение ответов на запросы. Пользователям системы обычно требуется дополнительное обучение вследствие значительных изменений как в программном обеспечении, так и в требованиях к системе на выполнение анализа. В большинстве работ эта группа - наименее постоянная, в нее часто входят новые сотрудники, замещающие тех, кто перешел на другие должности. Операторы системы ответственны за ее ежедневную работу, чаще всего они решают задачи, позволяющие пользователям системы работать наиболее эффективно. В их обязанности входит устранение неполадок при зависаниях программ, или когда сложность анализа требует дополнительных ресурсов. В большинстве случаев они также отвечают за обучение пользователей. Это подразумевает, что операторы системы часто имеют опыт работы пользователей. Они знают как аппаратуру, так и программы, чтобы быть в состоянии производить их обновление. Вдобавок к функциям администраторов системы они часто являются и администраторами баз данных, следя за правами доступа и целостностью БД. И пользователи и операторы системы действуют в рамках большей организации, часто называемой спонсором системы. Спонсор выделяет финансирование для приобретения аппаратного и программного обеспечения и выплаты зарплаты. Он обеспечивает также политическую жизнеспособность системы. Иными словами, если нет достаточно крупной организации, то, вероятно, нет и ГИС. Спонсором системы может быть исследовательская группа университета, получившая грант для реализации проекта, или государственная организация, которой ГИС требуется для своей работы, или коммерческая организация, которой ГИС нужна для работы с клиентами. Финансирование и обеспечение жизнеспособности системы требуют, чтобы спонсор предпринимал долгосрочное планирование. Внешние участники Поскольку в большинстве установленных сегодня систем используется покупное программное обеспечение, нашим первым внешним участником будет поставщик ГИС, специализирующийся на разработке и распространении ПО ГИС одного или нескольких типов, а также его сопровождении и обновлении. Поставщики ПО могут работать совместно с поставщиками аппаратного обеспечения, для создания систем "под ключ". Во многих случаях поставщик обеспечивает и обучение персонала работе с системой, которое может проводиться силами специализированных учебных центров, сотрудничающих с поставщиками. Поставщики данных, второй внешний участник в мире ГИС, могут быть частными или государственными (общественными) организациями. Частные компании поставляют самостоятельно сгенерированные данные или данные из общедоступных источников, модифицированные для конкретного пользователя (например, преобразованные в нужный пользователю формат). Частные компании чаще всего являются коммерческими, то есть поставляют данные с добавленной стоимостью. Государственные агентства поставляют данные для больших участков или всей территории страны. Во многих случаях эти данные создаются ими для их же использования, но при этом могут поставляться также и внешним пользователям, обычно за некоторую цену, но для некоммерческого использования данные могут поставляться и бесплатно. Некоторые источники данных можно найти в Приложении 1. Еще одна группа внешних участников - разработчики приложений -становится все более значимой по мере роста сложности программного обеспечения ГИС. Они являются опытными программистами, создающими пользовательский интерфейс для уменьшения потребности в опытных специалистах по работе с ГИС при выполнении каждодневных задач. Во многих случаях программирование ведется на макроязыках, поддерживаемых поставщиками ГИС для разработки приложений, избавляющими от необходимости использования традиционных языков программирования*. В прошлом большинство разработчиков приложений были внутренними участниками (прикладными программистами), имеющими многолетний опыт работы с ПО ГИС и знающими его аналитические возможности. Сегодня же их функции отходят множеству фирм, специализирующихся на создании приложений на заказ. Помимо прочего, это позволяет снизить расходы на обучение новых пользователей системы за счет более низких требований к знанию того, что скрыто за интерфейсом. Наконец, есть системные аналитики ГИС. Эти внешние участники специализируются на проектировании систем. Чаще всего они являются частью группы профессионалов, ответственных за определение целей и задач системы внутри организации, "тонкую настройку" системы для обеспечения ею необходимых аналитических методов, гарантированную интеграцию системы в рамках организации. Короче говоря, системные аналитики действуют как штурманы для организаций, использующих ГИС. Обычно они предоставляются консультационной фирмой, специализирующейся на реализации ГИС для заказчиков, но могут быть и работниками компании-поставщика ГИС. СТРУКТУРИРОВАННАЯ МОДЕЛЬ ПРОЕКТИРОВАНИЯ Техническое проектирование В общем виде, мы разделили процесс проектирования ГИС на разработку программного обеспечения и проектирование системы (Рисунок 15.1), которое может быть далее разделено на техническое и организационное проектирование. * В настоящее время наблюдается обратная тенденция - расширение использования универсальных языков программирования для создания приложений ГИС, обусловленная развитием стандартных сред визуальной разработки приложений. Это избавляет программистов от необходимости изучать язык каждой системы, а также облегчает интеграцию ГИС с другими программными средствами. — прим. перев. Техническое проектирование включает две части: функциональность системы (операции) и БД системы (данные). Первая часть связана главным образом с выполнением тех видов анализа, которые система должна обеспечивать. БД системы это набор электронных карт и соответствующих компонентов, над которыми интерактивно работают программное обеспечение и персонал для реализации целей проекта.  Рисунок 15.4. Упрощенная модель проектирования ГИС. Любой проект содержит движение от концептуального уровня к детальному и далее - к уровню реализации (Рисунок 15.4) [Marble, 1994]. При продвижении от этапа концепции к этапу реализации растет уровень знания функциональности и БД, и наоборот, до того, как станут ясны детали, нам нужно выработать концепцию (идею) системы и найти способ ее реализации. Тщательное концептуальное проектирование - важный первый шаг в создании любой хорошей ГИС. Концептуальное проектирование Мы начинаем проект, делая самые общие утверждения о том, что система должна делать, какие задачи решать, об общих типах данных и т.д. Хорошее концептуальное представление позволяет планировать дальнейшее развитие и изменение системы. Но в отличие от линейной модели, концепция должна быть достаточно гибкой для учета предстоящих изменений в целях, доступности данных, персонале и требованиях управления. Таким образом, на стадии концептуального проектирования существенной является Проектирование ГИС независимость от конкретного ГИС-пакета, так как выбранное ПО может ограничить нашу свободу в определении целей вследствие собственных ограничений функциональности и используемых в ней моделей данных. При концептуальном проектировании определяется общий вид всей системы и ее потребности в данных. Если по какой-либо причине требования изменятся, то в это время мы сможем изменить общий вид. Вместо использования концептуального представления как жесткой структуры мы используем его как стартовую точку для выбора начального направления, что позволит нам ставить в дальнейшем адекватные вопросы. Вдобавок к независимости от программного обеспечения, концептуальное представление позволяет нам определить все возможные источники получения данных. Хотя ГИС не должна быть движима исключительно лишь данными, ее функциональность и даже жизнеспособность могут в значительной степени определяться доступностью, ценой и качеством данных для решения поставленных задач. Это значит, что нам может потребоваться использование разнородного ПО или выдвижение предложения об изменении бюджета проекта для приобретения дополнительных данных. Возможно даже, что мы поймем, что ГИС не является практически осуществимым или жизнеспособным решением для данной организации. Психологические проблемы внедрения ГИС Главным препятствием при внедрении любой информационной технологии, будь то текстовые процессоры, бухгалтерские системы или ГИС, является психология людей. Они нередко оказываются причиной низкой отдачи от вложений организации в это новшество, что чаще всего обусловлено фундаментальными изменениями в работе. Даже простые текстовые редакторы могут обескуражить людей, не знакомых с работой на компьютере и привыкших к пишущей машинке. Они будут сопротивляться всякой попытке внедрения компьютеров в их работу. Хотя, конечно, есть и такие, кто активно приветствует автоматизацию деятельности. Аналогичная проблема возникает при внедрении покупной бухгалтерской системы, созданной без внимания к людям, которые должны использовать ее ежедневно. Хотя программа сама по себе может быть пригодна для выполнения возложенных на нее задач, надо учитывать, что с ней должны работать люди. Те же, кто ожидает, что компьютер должен выполнять все основные задачи точно также, как они делали это до его внедрения, могут прибегать к прежним методам, пока система не будет изменена, или пока они не найдут себе другое место работы. Даже если ПО соответствует потребностям отдельных пользователей, оно не может гарантировать немедленного одобрения. Требуется некоторое время на его освоение, в течение которого возможно снижение производительности работы организации. Таким образом, обучение имеет две стороны: персонал должен иметь желание и возможность учиться использовать систему, а организация должна обеспечить соответствующее обучение. Наконец, есть еще одна проблема. Часто в организации есть люди или группы людей, знания и опыт которых гарантируют им их место работы. Но, поскольку ГИС, как и любая информационная технология, открывает двери для свободного потока информации и, по сути, позволяет многим другим решать задачи этих людей, они могут воспротивиться ослаблению их власти и, следовательно, внедрению системы. Эта причина часто объясняет трудности внедрения ГИС во многих организациях. Вопросы стоимости и отдачи Помимо желания персонала работать с системой необходимо еще желание администрации вкладывать деньги в ее создание и внедрение. Для этого администрация должна быть убеждена, что эффект оправдает вложения. В целом, управленцы считают, что нет надежного способа определения возврата инвестиций. Мало известно заранее о точной стоимости реализации ГИС и еще меньше - об экономическом выигрыше от этой реализации. Это отчасти объясняется тем, что число и сложность карт, которые вводятся в систему, радикально изменяются. Кроме того, поскольку на разработку БД уходит большое время, отдача в начальный период от этих вложений часто минимальна. В этом случае руководство организации должно быть уверено, что долговременные преимущества все-таки существуют. Среди наиболее успешных способов убеждения администрации является указание на положительный опыт внедрения ГИС в подобных же организациях. Другой вариант - узнать требуемое спонсором отношение отдача/цена и попытаться "вписаться" в него [Tomlmson, n.d.]. В таком перестраховочном подходе цена специально завышается, чтобы избежать на стадии реализации превышения объявленной стоимости. Модели требований к данным и к приложениям Структурированное техническое проектирование может быть двух видов. Модель потребностей данных (data requirements model) основана на идее, что наличие определенных данных влияет на то, какой анализ можно провести. Модель обычно проходит этапы концептуального, логического (логические связи между данными) и физического проектирования БД. А модель потребностей приложений (application requirements model) основана на той идее, что система движима анализом, который она должна выполнять. Эта модель идет от общего функционального анализа к проектированию приложений более высокого уровня и проработке конкретных деталей выполнения анализа. Но поскольку данные и приложения взаимосвязаны, ГИС лучше представлять движимой обоими этими факторами*. ФОРМАЛИЗОВАННАЯ МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ГИС Предпринимались несколько попыток создания и совершенствования моделей проектирования ГИС, начиная с той, что была разработана после тщательной оценки реализации одной системы [Calkins, 1982], которая была в дальнейшем усовершенствована в связи с ростом объема литературы по административно-информационным системам (MIS) [Johnson, 1981]. К тому времени были разработаны уже несколько систем поддержки разработки ПО, которые могли сразу же использоваться в области ГИС, с оговоркой, что проектирование ГИС фокусируется не только на программах, но и на базах данных, с которыми программы работают, причем с учетом организационного контекста для тех и других. Спиральная модель: Быстрое создание прототипов На основе одного из подходов к разработке ПО [Boehm, 1981,1986,1988] был разработан и реализован гибкий многоуровневый процесс проектирования. Эта спиральная модель [Marble, 1994] выделяет три уровня детальности и три задачи проектирования ГИС: сбор, организацию и анализ информации (Рисунок 15.5). Первый уровень - начальная модель - наиболее общая основа обсуждения реализуемости ГИС. Второй уровень -концептуальная модель - включает анализ потребностей и первые обсуждения проектирования БД. Третий уровень - детальное проектирование - занимается вопросами конкретного ПО для реализации системы. * Известная формула Вирта "программы = алгоритмы + данные" — прим. перев. В начальной модели создается блок-схема, показывающая отдельные задачи этого процесса. Каждый блок этой модели имеет несколько более детальных уровней. Концептуальная и детальная модели также имеют несколько уровней детализации. Объяснение всех трех подмоделей больше подходит для последующих курсов по геоинформатике и детально описано в книге автора этого метода. Здесь же мы рассмотрим только начальную модель и общие вопросы движения по спирали.  Рисунок 15.6 показывает последовательность принятия решений. На первом шаге информация от клиента используется для определения целей организации, ибо реализация ГИС, не отражающая понимание общих целей организации, возможно, выраженное как декларация производимых продуктов и услуг, не будет принята администрацией. Второй шаг (1.1.2) -определение того, что должна делать ГИС. Часто это трудно сделать для некоторых потенциальных пользователей, чей интерес к ГИС происходит от высокой оценки данной технологии в деловых кругах. Многие интересуются ГИС лишь потому, что кто-то еще использует ГИС. В этот момент мы должны спросить потенциального пользователя, действительно ли ему нужен анализ. Вполне возможно, что ему не нужен сложный анализ и вполне подойдет САПР или система компьютерной картографии. Задачи всех возможных пользователей должны быть учтены при решении о целях ГИС. Необходимо идентифицировать потребности каждого пользователя. Хорошим методом является выяснение того, какие конечные |
