» » » » Сергей Авдошин - Информатизация бизнеса. Управление рисками


Авторские права

Сергей Авдошин - Информатизация бизнеса. Управление рисками

Здесь можно купить и скачать "Сергей Авдошин - Информатизация бизнеса. Управление рисками" в формате fb2, epub, txt, doc, pdf. Жанр: Управление, подбор персонала, издательство ДМК Пресс, год 2011. Так же Вы можете читать ознакомительный отрывок из книги на сайте LibFox.Ru (ЛибФокс) или прочесть описание и ознакомиться с отзывами.
Сергей Авдошин - Информатизация бизнеса. Управление рисками
Рейтинг:
Название:
Информатизация бизнеса. Управление рисками
Издательство:
неизвестно
Год:
2011
ISBN:
978-5-94074-109-1
Вы автор?
Книга распространяется на условиях партнёрской программы.
Все авторские права соблюдены. Напишите нам, если Вы не согласны.

Как получить книгу?
Оплатили, но не знаете что делать дальше? Инструкция.

Описание книги "Информатизация бизнеса. Управление рисками"

Описание и краткое содержание "Информатизация бизнеса. Управление рисками" читать бесплатно онлайн.



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

В основу учебного пособия положен многолетний опыт преподавания авторами дисциплины «Управление рисками» на отделении программной инженерии Высшей школы экономики.

Книга предназначена для студентов магистратуры, обучающихся по направлениям 080500.68 «Бизнес-информатика» и 231000.68 «Программная инженерия», а также для ИТ-специалистов, разработчиков и заказчиков программных продуктов, менеджеров ИТ-проектов.






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

К специфичным методологиям, уделяющим большее внимание управлению рисками ИТ-проектов, нежели процессу разработки программного обеспечения, можно отнести CRAMM и CORAS.

Методология CRAMM разработана британским Центральным компьютерным и телекоммуникационным агентством в 1985 году, применяется в области управления ИТ-рисками как для крупных, так и для небольших организаций правительственного и коммерческого сектора. CRAMM предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. Для оценки рисков в методологии используется механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. Компания Siemens предлагает программную реализацию методологии и представляет продукты CRAMM Expert и CRAMM Express.

Методология CORAS разработана в рамках программы Information Society Technologies. Ее суть состоит в адаптации, уточнении и комбинировании таких методов проведения анализа рисков, как Event-Tree-Analysis, цепи Маркова и прочие. В соответствии с CORAS информационные системы рассматриваются не только с точки зрения используемых технологий, но и с нескольких сторон, а именно как сложный комплекс, в котором учтен и человеческий фактор. Методология получила программную реализацию в виде Windows– и Java-приложений.

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

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

2.3. Риски при использовании методологий разработки ПО

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

В зависимости от назначения проектный менеджер выбирает наиболее подходящие для разработки и управления ПО модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики. Универсальные концепции, а также управленческие стандарты, например серии ISO 9000, аккумулируют опыт и лучшие управленческие практики, которые стали основой методологий совершенствования деятельности компаний-разработчиков, таких как модели зрелости (CMM/CMMI), стандарты оценки и улучшения процессов (SPICE) и прочие. Объектами стандартизации в сфере ИТ являются:

• конструкторская документация (состав, структура, требования к оформлению);

• стандарты кодирования и оформления программных текстов;

• терминология и определения;

• модели процессов;

• модели жизненного цикла;

• требования к безопасности хранения и передачи информации и способы ее обеспечения;

• качество программного обеспечения, характеристики качества, методы получения данных по качеству;

• графические и нотации и инструменты формализованного описания требований и технических решений;

• форматы хранения данных, обмена и передачи данных.

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

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

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

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

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

Для долгосрочных проектов, как правило, подходят «более тяжелые» и формализованные методологии, такие как MSF, RUP, CMM-SE. Тяжелые методологии дают наибольший эффект в крупных компаниях, занятых промышленным выпуском ПО и готовых на многолетние инвестиции в кардинальную перестройку организационной структуры. Такие подходы обычно дают очень хорошие результаты, но процесс внедрения растягивается на несколько лет. Стоимость использования подобной методологии достаточно высока. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, что является достоинством методологии. Однако в ряде случаев такая детальность планирования является излишней и не оправдывает затраченных ресурсов.

Методология RAD (Rapid Application Development) идеально подходит для быстрой разработки приложений (до 6 месяцев) с использованием ограниченной команды специалистов. Поскольку методология предполагает активное вовлечение пользователей в процесс разработки, отсутствие базовых навыков в области информационных технологий может стать ключевым риском в процессе разработки. Фаза построения и разработки приложения происходит крайне быстро, поэтому существуют определенные риски внесения изменений – дополнительных требований и пожеланий, которые практически невозможно реализовать из-за ограниченных сроков реализации. Также методологии быстрой разработки приложений и экстремального программирования (XP) характеризуются наличием сильного менеджера проекта. Его роль становится ключевой, поэтому крайне важно уделять внимание организационным аспектам, взаимодействию коллектива, компетентности команды.

По сравнению с монументальными методологиями, в гибких (Scrum, Crystal, Open Source, ASD) очевидно прослеживается меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Легкие методологии дают возможность обрабатывать большие объемы информации, относящиеся к проекту, в процессе неформального, непосредственного, личного общения, а не с помощью документации. При этом отсутствие документации может быть ограничением использования методологии в государственных учреждениях или организациях, требующих высокой степени формализации и документирования. Поскольку практически все гибкие методологии ориентированы на максимально неформальный подход к разработке, зачастую возможны спорные вопросы при реализации тех или иных изменений, расстановке приоритетов.

При этом легкие методологии также отличаются друг от друга – Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология «Adaptive Software Development» разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках). Scrum характерен активным воздействием внешних лиц по отношению к рабочей группе, при этом у заказчика сохраняется максимальный приоритет. Заказчик продукта сам решает, как оформить бэклог продукта, выбирает требования для следующей итерации. При этом несоблюдение базовых принципов, заложенных в Scrum, таких как самонаправляемые команды, обязательная расстановка приоритетов или еженедельные обновления, может привести к срыву проекта.


На Facebook В Твиттере В Instagram В Одноклассниках Мы Вконтакте
Подписывайтесь на наши страницы в социальных сетях.
Будьте в курсе последних книжных новинок, комментируйте, обсуждайте. Мы ждём Вас!

Похожие книги на "Информатизация бизнеса. Управление рисками"

Книги похожие на "Информатизация бизнеса. Управление рисками" читать онлайн или скачать бесплатно полные версии.


Понравилась книга? Оставьте Ваш комментарий, поделитесь впечатлениями или расскажите друзьям

Все книги автора Сергей Авдошин

Сергей Авдошин - все книги автора в одном месте на сайте онлайн библиотеки LibFox.

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

Отзывы о "Сергей Авдошин - Информатизация бизнеса. Управление рисками"

Отзывы читателей о книге "Информатизация бизнеса. Управление рисками", комментарии и мнения людей о произведении.

А что Вы думаете о книге? Оставьте Ваш отзыв.