Методология преобразования правительства на основе архитектуры предприятия. Часть 2.

Информационное общество, 2009, вып. 4-5, с. 80-96.
Паллаб Саха

Методология архитектуры предприятия для органа власти

Эффективные программы применения архитектуры предприятия (АП) для электронного правительства основаны на методологии и процессном подходе.Методология описывает необходимые шаги, их последовательность и взаимосвязь (Bittler & Kreizman, 2005). АП как дисциплина имеет дело с процессами. Внедрение АП на институциональном уровне обеспечивает реализацию модели деятельности организации и более четкое следование ее стратегии. Эталонные модели АП для правительства Сингапура стали ответом на возникшую потребность в структурированной и четко определенной методологии развития АП.

Методология преобразования правительства на основе архитектуры предприятия. Часть 1.

Информационное общество, 2009, выпуск 2, с. 6-20.
Паллаб Саха - национальный университет Сингапура, Сингапур

Введение

С начала 90-х годов правительства различных стран инициируют движение по использованию информационно-коммуникационных технологий (ИКТ) для предоставления государственных услуг. Эти инициативы получили название «электронное правительство» (e-government). Согласно определению Всемирного банка, электронное правительство — это «использование органами власти информационных технологий, способных преобразовать взаимоотношения с гражданами, бизнесом, а также другими органами власти». Эти технологии облегчают предоставление государственных услуг гражданам, оптимизируют взаимодействие с бизнесом и промышленностью, помогают предоставить доступ граждан к информации и повысить эффективность государственного управления. Результатами внедрения являются снижение уровня коррупции, повышение прозрачности и удобства, рост доходов и снижение издержек (Всемирный банк, 2003).

ИНСТРУМЕНТАЛЬНАЯ РЕАЛИЗАЦИЯ АРХИТЕКТУРНЫХ МОДЕЛЕЙ ПРЕДПРИЯТИЯ НА ОСНОВЕ ОНТОЛОГИЙ

БИЗНЕС-ИНФОРМАТИКА №1(15)–2011 года

Н.Н. Лычкина, кандидат экономических наук, доцент, заместитель заведующего кафедрой «Информационные системы» Государственного университета управления,e-mail: lychkina@guu.ru

А.Р. Идиатуллин, аспирант кафедры «Информационные системы» Государственного университета управления, e-mail: idiatulla@gmail.com

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

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

ОПЯТЬ ПРО АРХИТЕКТУРУ

Марина Аншина, Председатель Комитета по стандартам Российского Союза ИТ-Директоров
электронный журнал "Управляем предприятием" № 8 (8), сентябрь 2011 года, www.consulting1c.ru

Хотя все развивается по спирали, но спираль эта иногда закручивается
не в ту сторону, в какую хотелось бы. То есть не в сторону развития и прогресса. А ровно наоборот. Конечно, это временный регресс, и развитие
остановить нельзя. А вот отложить можно. Речь идет о проектах внедрения
корпоративных информационных систем и ситуации в информационных
технологиях (ИТ) в целом, которая далека еще до стабильности, эффективности, а в отдельных случаях и просто разумности.

Заметки об опыте разработки стратегических планов

Автор: Рубенчик Андрей Викторович, arub@rambler.ru
Статья опубликована в журнале «Стратегический менеджмент», № 1 за 2009 год, http://www.grebennikoff.ru/product/36/

Введение

В США накоплен большой опыт по разработке стратегических планов развития государственных организаций.

Начало разработке стратегических планов на регулярной основе было положено в 1993 году, когда был принят Закон о повышении эффективности деятельности правительственных ведомств (The Government Performance and Results Act of 1993).

В настоящей статье рассматривается опыт разработки стратегических планов в Почтовой службе США (United States Postal Service).

Почтовая служба ведет разработку стратегических планов в тесном взаимодействии с широким кругом заинтересованных лиц: Конгресс США, почтовая индустрия и потребители почтовых услуг в лице различных союзов, ассоциаций и форумов, профсоюзы, сотрудники Почтовой службы.

Новые приемы управления требованиями с помощью Rational RequisitePro: Часть 1. Использование архитектурных методов

Кумар Мани, старший IT-архитектор, IBM
http://www.ibm.com/developerworks/ru/library/ar-reqframe1/index.html
11.07.2007

В данной серии статей Кумара Мани предлагаются новые приемы, помогающие выявить и проследить архитектурные требования, а также управлять ими. Введение В этой статье описываются новые архитектурные методы и приемы, направленные на проектирование требований, на умение их собирать, анализировать и управлять ими в течение всего жизненного цикла проекта. Хотя в данной статье для иллюстрации этих приемов используется набор инструментов Rational, она не является учебным пособием по использованию этих продуктов. Ваша цель - использовать основные архитектурные методы и применять их в своих проектах. Конечно же, IT-архитекторы, знакомые с Rational, смогут без труда воспроизвести эти методы в своих проектах. Требования важны, поскольку они образуют основу для разработки архитектур. На Рисунке 1 показан метод разработки архитектуры Open Group Architecture Framework Architecture Development Method (TOGAF ADM) и его восемь фаз.

Управление требованиями и автоматизация этого процесса

Автор: Волков Юрий Ольгердович, yvolk@yurivolkov.com

Последнее изменение: 21 марта 2007 г.
Cтатья опубликована 25 января 2005 г. в "PC Week/Russian Edition", №2 (464) 2005г., стр.27, http://kis.pcweek.ru/Year2005/N2/CP1251/DevApp/chapt1.htm
Как собирают требования в большой команде (практический опыт)

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