Разработка информационных систем. Учебное пособие

Сухомлинов А.И.

Возрастное ограничение: 12+ Жанр: Наука Издательство: Проспект Дата размещения: 10.08.2015 ISBN: 9785392189540 Язык: Объем текста: 269 стр. Формат: epub

Оглавление

Предисловие

Глава 1. Архитектура информационных систем

Глава 2. Жизненный цикл и методологии разработки систем

Глава 3. Анализ методологий

Для бесплатного чтения доступна только часть главы! Для чтения полной версии необходимо приобрести книгу

Глава 3.
АНАЛИЗ МЕТОДОЛОГИЙ

Область методологий информационных систем можно охарактеризовать как «малопроходимые джунгли» и маловероятно, что ситуация в ней в скором будущем изменится к лучшему из-за непрерывного развития информационных технологий, информационных систем и в целом организаций. Уже в 1994 г. в мире насчитывалось более 1000 брендовых методологий и их количество продолжает быстро увеличиваться. Многие из них, конечно, очень похожи и видоизменены только для маркетинговых целей. Другие были разработаны собственными силами компаний для внутреннего применения. Тем не менее, можно твердо утверждать, что в настоящее время существует большое, сбивающее с толку многообразие методологий.

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

3.1. Определение методологии

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

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

• В чем состоит отличие между методологией и методом?

• Включает ли в себя методология спецификацию методов и средств, которые должны использоваться?

• Составляет ли набор методов и средств методологию?

• Должно ли использование методология приводить каждый раз к одному и тому же результату?

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

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

• Как должен разбиваться на этапы проект?

• Какие задачи должны выполняться на каждом из этапов?

• Какой вход должен создаваться на этапах?

• Когда и при каких обстоятельствах эти этапы должны выполняться?

• Какие применяются ограничения?

• Какой персонал должен быть привлечен?

• Как осуществляется менеджмент и контроль проекта?

• Какие поддерживающие средства могут быть использованы?

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

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

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

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

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

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

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

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

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

3.2. Обоснование необходимости методологий

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

Улучшение конечного продукта

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

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

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

• Работоспособность. Является ли система работоспособной, когда и где это требуется.

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

• Совместимость. Согласовываются ли система с другими системами и другими частями организации.

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

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

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

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

• Производительность. Использует ли система выделенные ресурсы с наибольшей пользой.

• Быстрый темп разработки. Является ли время, требуемое для разработки проекта, достаточно быстрым относительно его размера и сложности.

• Гибкость. Является ли система легкой в модификации, добавлении и удалении компонент.

• Функциональность. Обеспечивает ли система потребности организации.

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

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

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

• Переносимость. Может ли система выполняться на другом оборудовании или в других местах.

• Надежность. Минимизирована ли частота ошибок и являются ли выходы непротиворечивыми и правильными.

• Робастность. Является ли информационная система устойчивой к отказам и отказоустойчивой.

• Безопасность. Является ли система робастной по отношению к неправильному использованию.

• Простота. Минимизирована ли неоднозначность и сложность.

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

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

• Обозримость. Является ли возможным для пользователей отследить, почему имело место определенное действие.

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

Улучшение процесса разработки

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

Некоторые считают, что проблемы разработки информационных систем могли бы быть улучшены за счет применения стандартов качества, которые доказали пригодность в производстве и промышленных процессах, например, BS5750/ISO9001. Эти стандарты разработаны, скорее, для обеспечения качества процессов, чем конечного продукта, и это иногда является причиной акцента на соответствие стандарту, независимо от того, улучшает ли это качество информационной системы.

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

Стандартизация процесса разработки

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

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

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

3.3. Истоки методологий

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

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

Коммерческие методологии

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

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

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

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

Консультирующие компании, в конечном счете, инвестировали свои методологии. Эти вложения привели к ряду последствий.

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

Сухомлинов А.И. Разработка информационных систем. Учебное пособие

Сухомлинов А.И. Разработка информационных систем. Учебное пособие

В книге отражено бурное информационное развитие последних лет, многие технические и научные достижения в информационных системах и экспоненциальный рост таких систем в коммерции, промышленности, исследовательских институтах и университетской среде. Пособие охватывает архитектуру информационных систем, методологии, методы и средства их разработки. Оно интегрирует технические, социальные, организационные и экономические представления о разработке информационных систем.<br /> Предназначено для студентов технических специальностей, изучающих информационные системы в административно-организационном управлении, а также для специалистов, стремящихся к совершенствованию в данной области.

Внимание! Авторские права на книгу "Разработка информационных систем. Учебное пособие" (Сухомлинов А.И.) охраняются законодательством!