Файл: Проектирование архитектуры информационной системы. Эволюция архитектур ис.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 27.04.2024
Просмотров: 15
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Требования к переносимости информационных систем никогда не остаются постоянными. Потребности бизнеса и операционные технологии меняются, поэтому информационные системы, которые их поддерживают и работают на них, тоже должны измениться. Требования к переносимости определяют, как технические операционные среды могут изменяться с течением времени и как система должна реагировать (например, в настоящее время система может работать в Windows, но в будущем, возможно , придется работать в Linux). Требования к переносимости также относятся к потенциальным изменениям в бизнес-требованиях, которые будут определять изменения в технической среде. Например, многие организации сегодня работают над тем, чтобы их приложения были оптимизированы для таких устройств, как iPad, в ответ на запросы пользователей.
Требования к реинжинирингу. Требования к реинжинирингу определяют изменения бизнес-требований, которые можно ожидать. Не все изменения предсказуемы, но некоторые из них предсказуемы. Например, предположим, что небольшая компания имеет только одно производственное предприятие, но планирует строительство второго завода в ближайшие пять лет. Все информационные системы должны быть написаны таким образом, чтобы было легко отслеживать каждое растение в отдельности, будь то для личных целей, составления бюджета или управления запасами. Требование реинжиниринга пытается предвидеть будущие требования, чтобы системы, разработанные сегодня, было легко поддерживать, если и когда появятся эти будущие требования. Определяет цикл обновления системы, например частоту выпуска новых версий.
Требования к производительности. Требования к производительности сосредоточены на таких вопросах производительности, как время отклика, пропускная способность и надежность. Поскольку аналитики определяют требования к производительности системы, ключевым вопросом является возможность проверки этих требований. Каждое требование должно быть измеримым, чтобы можно было провести сравнительный анализ. Только таким образом можно проверить выполнение требований к производительности. Фактически, многие системные аналитики пишут спецификацию теста, содержащую четко определенный тест для каждого требования, одновременно с созданием требований. Такое внимание к тестируемости предотвращает создание требований к низкой производительности, таких как “Система должна иметь достаточно быстрое время отклика, чтобы сотрудники могли эффективно выполнять свою работу”.
Требования к скорости Требования к скорости - это именно то, что они говорят: насколько быстро должна работать система. В первую очередь, это время отклика системы:
Сколько времени требуется системе, чтобы ответить на запрос пользователя? В то время как все предпочли бы низкое время отклика, когда система немедленно реагирует на каждый запрос пользователя, это непрактично. Мы могли бы разработать такую систему, но это было бы дорого. Большинство пользователей понимают, что некоторые части системы будут реагировать быстро, в то время как другие будут работать медленнее. Те действия, которые выполняются локально на компьютере пользователя, должны выполняться практически мгновенно (например, ввод текста, перетаскивание), в то время как другие, требующие связи по сети, могут иметь более высокое время отклика (например, веб-запрос). В целом, время отклика менее 7 секунд считается приемлемым, когда требуется связь по сети.
Второй аспект требований к скорости заключается в том, сколько времени требуется для отражения транзакций в одной части системы в других частях. Например, как скоро после размещения заказа товары, содержащиеся в нем, будут показаны как недоступные для продажи кому-либо другому? Если запасы не будут обновлены немедленно, то кто-то другой может разместить заказ на тот же товар, только чтобы позже узнать, что его нет на складе. Или как скоро после размещения заказа он отправляется на склад для отбора из запасов и отправки? В этом случае некоторая задержка по времени может оказать незначительное влияние.
Требования к пропускной способности Требования к пропускной способности пытаются предсказать, сколько пользователей система должна будет поддерживать, как в целом, так и одновременно. Требования к пропускной способности важны для понимания размера баз данных, необходимой вычислительной мощности и так далее. Наиболее важным требованием обычно является максимальное количество одновременных пользователей, поскольку это напрямую влияет на вычислительную мощность компьютера (компьютеров), необходимого для поддержки системы.
Часто бывает проще предсказать количество пользователей для внутренних систем, предназначенных для поддержки собственных сотрудников организации, чем предсказать количество пользователей для систем, ориентированных на клиента, особенно в Интернете. Как это делает weather.com оцените максимальное количество пользователей, которые будут одновременно запрашивать информацию о погоде? Это такое же искусство, как и наука, поэтому команда часто предоставляет диапазон оценок, причем более широкие диапазоны используются для обозначения менее точной оценки.
Требования к доступности и надежности Требования к доступности и надежности сосредоточены на степени, в которой пользователи могут предполагать, что система будет доступна для их использования. В то время как некоторые системы предназначены для использования только в течение 40-часовой рабочей недели, другие системы предназначены для использования людьми по всему миру. Для таких систем членам проектной группы необходимо рассмотреть вопрос о том, как приложение может быть эксплуатируется, поддерживается и обслуживается 24/7 (т.е. 24 часа в сутки, 7 дней в неделю). Это требование 24 × 7 означает, что пользователям может понадобиться помощь или у них могут возникнуть вопросы в любое время, и службы поддержки, доступной 8 часов в день, будет недостаточно. Также важно учитывать, какая надежность необходима в системе. Система, требующая высокой надежности (например, медицинское устройство или телефонный коммутатор), нуждается в гораздо большем планировании и тестировании, чем система, не требующая такой высокой надежности (например, система персонала, веб-каталог).
Сложнее предсказать пики и спады в использовании системы с глобальной аудиторией. Как правило, резервное копирование приложений выполняется по выходным или поздним вечерам, когда пользователи больше не имеют доступа к системе. Такие мероприятия по техническому обслуживанию должны быть переосмыслены с учетом глобальных инициатив. Разработка веб-интерфейсов, в частности, усилила потребность в поддержке 24/7; по умолчанию доступ к Интернету может получить любой человек в любое время.
Требования к безопасности. Безопасность - это способность защитить информационную систему от сбоев и потери данных, будь то в результате преднамеренного действия (например, хакера или террористической атаки) или случайного события (например, сбой диска, торнадо). Разработчики новых систем должны обеспечить, чтобы требования безопасности системы приводили к разумным исправлениям для предотвращения проблем; разработчики систем несут ответственность за обеспечение безопасности в самих информационных системах.
Требования к контролю доступа Некоторые данные, хранящиеся в системе, должны быть конфиденциальными; некоторые данные требуют специального контроля над тем, кому разрешено их изменять или удалять. Например, записи о персонале должны быть доступны для чтения только отделу кадров и руководителю сотрудника; внесение изменений должно разрешаться только отделом кадров. В требованиях к контролю доступа указывается, кто может получить доступ к каким данным и какой тип доступа разрешен — может ли пользователь создавать, читать, обновлять и/или удалять данные. То требования снижают вероятность того, что авторизованный пользователь системы может выполнять несанкционированные действия.
Культурные требования. Культурные требования специфичны для стран, в которых будет использоваться система. В современной глобальной бизнес-среде организации расширяют свои системы, чтобы охватить пользователей по всему миру. Хотя это может иметь большой бизнес-смысл, его влияние на разработку приложений не следует недооценивать. Еще одной важной частью проектирования архитектуры системы является понимание глобальных культурных и политических требований к системе
Требование поддержки мультиязычности. Первое и наиболее очевидное различие между приложениями, используемыми в одном регионе, и приложениями, предназначенными для глобального использования, заключается в языке. Глобальные приложения часто имеют многоязычные требования, что означает, что они должны поддерживать пользователей, которые говорят на разных языках и пишут нерусскими буквами (например, татарский язык, китайский).
Некоторые системы предназначены для работы с несколькими языками на лету, чтобы пользователи в разных странах могли одновременно использовать разные языки; то есть одна и та же система поддерживает несколько разных языков одновременно (многоязычная система). Другие системы содержат отдельные части, написанные на каждом языке, и их необходимо переустановить, прежде чем можно будет использовать определенный язык; то есть каждый язык предоставляется другой версией системы, так что при любой установке будет использоваться только один язык (т.е. отдельная многоязычная система). Любой из подходов может быть эффективным, но эта функциональность должна быть встроена в систему задолго до ее внедрения
Требования к настройке. Для глобальных приложений проектной группе необходимо будет подумать о требованиях к настройке: Какая часть приложения будет контролироваться центральной группой, а какая часть приложения будет управляться локально? Например, некоторые компании разрешают дочерним компаниям в некоторых странах настраивать приложение, опуская или добавляя определенные функции. Это решение имеет компромиссы между гибкостью и контролем, поскольку настройка часто усложняет для проектной группы создание и поддержку приложения. Это также означает, что обучение может отличаться в разных подразделениях организации, а индивидуальная настройка может создать проблемы, когда сотрудники переезжают из одного места в другое.
Неустановленные нормы. Во многих странах существуют неустановленные нормы, которые не разделяются на международном уровне. Разработчику приложения важно четко сформулировать эти предположения, поскольку в противном случае они могут привести к путанице. В Соединенных Штатах неустановленной нормой для ввода даты является формат даты ММ/ДД/ГГ; однако в Канаде и большинстве европейских стран неустановленной нормой является ДД/ММ/ГГ. Когда вы разрабатываете глобальные системы, крайне важно признать эти неустановленные нормы и четко сформулировать их, чтобы пользователи в разных странах не путались.
Валюта - это еще один элемент, который иногда упускается из виду при проектировании системы; глобальные прикладные системы должны указывать валюту, в которой вводится и сообщается информация.
Требования к моделям архитектур
Для обеспечения эффективного выполнения запросов пользователя – информационная система должна удовлетворять ряду требований, которые можно представить приведенным нижеследующим набором характеристик:
1. Производительность. Требование высокой производительности системы предполагает такую архитектуру, где за все критические операции отвечало бы минимальное число подсистем с ограниченным взаимодействием между ними. В таких случаях лучше использовать компоненты в виде крупных модулей, а не мелкие структурные элементы.
2. Защищенность, для обеспечения которой требуется архитектура с многоуровневой структурой, где наиболее критические системные элементы защищены на внутренних уровнях, а проверка их безопасности осуществляется на более высоком уровне.
3. Безопасность, архитектуру следует спроектировать так, чтобы при этом за операции, влияющие на безопасность системы, должно отвечать как можно меньше подсистем.
4. Надежность, повысить можно путем разработки архитектуры с включением избыточных компонентов, которые можно было бы заменять и обновлять, не останавливая общее функционирование системы.
5. Удобство сопровождения предполагает, что системная архитектура должна основываться на уровне мелких структурных компонентов, которые можно легко заменять и модифицировать. Программные модули, создающие данные, необходимо отделить от модулей, их использующих. Кроме того, нужно избегать структур совместного использования данных.
Рассмотрим пример графического представления архитектуры ИС. Каждый веб-сайт, который вы просматриваете, будь то блог Wordpress или веб-приложение, Facebook, Twitter или банковское приложение, построен на архитектуре клиент-сервер.
