|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
ОРГАНИЗАЦИЯ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯСтр 1 из 9Следующая ⇒
РАЗДЕЛ 9 ОРГАНИЗАЦИЯ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Методологии разработки программного обеспечения – каскадная, спиральная, инкрементальная. Их сущность и области применения. Каскадная (водопад) Данная модель также носит название «водопад». Классическими представителями реализации данной методологии являются стандарты ISO и CMM. Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. Модель предполагает следующие свойства взаимодействия этапов: • модель состоит из последовательно расположенных этапов; • каждый этап полностью заканчивается до того, как начнется следующий; • этапы не перекрываются во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий; • возврат к предыдущим этапам не предусмотрен либо всячески ограничен; • исправление ошибок происходит лишь на стадии тестирования; • результат появляется только в конце разработки. Критерием появления результата является отсутствие ошибок и точное соответствие продукта первоначальной спецификации. a) требования к объектам определены недостаточно четко; b) система обычно слишком велика, чтобы все работы по ее созданию выполнять однократно; c) предполагаемые скорые изменения в технологиях работ; Преимущества a) однократное представление всех возможностей (характеристик) системы; b) необходимость только единственной фазы перехода от старой системы к новой. Инкрементальная (итеративная) Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально. С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта). Недостатки а) требования к объектам определены недостаточно четко; b) предусмотрены сразу все возможности системы; c) предполагаемые скорые изменения в технологиях работ; d) возможные текущие изменения требований к системе; е) привлечение ресурсов (средств или персонала) на длительный период ограничено. Преимущества a) необходимость изначального использования характеристик системы; b) пригодность для использования промежуточного продукта; c) естественное разделение системы на наращиваемые компонент (инкременты); d) возможности наращивания привлекаемого персонала и средств. Спиральная модель Спиральная модель была впервые сформулирована Барри Боэмом. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков: Дефицит специалистов. Нереалистичные сроки и бюджет. Реализация несоответствующей функциональности. Разработка неправильного пользовательского интерфейса. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей. Непрекращающийся поток изменений. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. Недостаточная производительность получаемой системы. “Разрыв” в квалификации специалистов разных областей знаний. Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде. Коммерческими представителями данной методологии являются RUP (Rational Unified Process), MSF (Microsoft Consulting Services). Результат появляется фактически на каждом витке спирали. Этот результат, который является промежуточным, анализируется, а затем выявленные недостатки продукта становятся поводом для инициирования следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в итоге выбирается обоснованный вариант, который доводится до реализации. Спираль завершается тогда, когда клиент и разработчик приходят к согласию относительно результата. Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора: оценка и разрешение рисков, определение целей, разработка и тестирование, планирование. На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем. Основные приёмы XP Тестирование В XP особое внимание уделяется двум разновидностям тестирования: § тестирование модулей (unit testing); § приемочное тестирование (acceptance testing). Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Приемочные тесты позволяют убедиться в том, что система действительно обладает заявленными возможностями. Кроме того, приемочные тесты позволяют проверить корректность функционирования разрабатываемого продукта. Игра в планирование Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Заказчик всегда рядом «Заказчик» в XP — это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов. Парное программирование Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды. Непрерывная интеграция Если вы будете выполнять интеграцию разрабатываемой системы достаточно часто, вы сможете избежать большей части связанных с этим проблем. В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают. Рефакторинг XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Частые небольшие релизы Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса. Чем раньше мы выпустим первую рабочую версию продукта, тем раньше заказчик начнет получать за счет нее дополнительную прибыль. Следует помнить, что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные завтра. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям заказчика. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска. Простота дизайна XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Если в самом начале работы вы пытаетесь от начала и до конца детально спроектировать систему, вы напрасно тратите время. Стандарты кодирования Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому: § члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом; § обеспечивается эффективное выполнение остальных практик. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объемным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Не нужно тратить слишком много времени на предварительную разработку стандарта. Коллективное владение Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист. Применение: Во многом XP была создана как попытка описать процессы и практики, которые часто как бы сами собой появляются в эффективных, сплоченных командах разработчиков. Может показаться, что процесс в таких командах отсутствует, и, скорее всего, то же самое будут утверждать сами разработчики. Однако это не так, поскольку работа профессиональной команды всегда четко (хотя и неформально) организована и не имеет ничего общего с беспорядком и хаосом. Это во многом определяет условия, необходимые для эффективного использования XP. Прежде всего, XP имеет шансы работать только в команде опытных, профессиональных разработчиков. Поскольку большую роль в XP играет прямое общение, команда не должна быть разбита на несколько частей – внедрение XP в распределенной географически команде будет крайне рискованным мероприятием. По той же причине возможный размер команды ограничен сверху – по всей видимости, числом в 10-15 человек. Другие практики XP приносят свои ограничения. Далеко не всегда можно обеспечить постоянное присутствие представителя заказчика в проектной команде (например, если потенциальные пользователи системы делятся на несколько классов с частично конкурирующими требованиями). Поскольку XP практически не делает попыток предотвратить размывание границ проекта (scope creep), будет не очень хорошей идеей использовать XP в проекте с фиксированной ценой. Фактически проекты XP обладают жестким графиком, но переменными границами, поэтому предпочтительным типом контракта будет повременная оплата (time& materials). Практика поддержания максимально простой архитектуры может завести в тупик в конце проекта, когда окажется, что для реализации завершающих историй требуется полное перепроектирование системы (оказывается, нам нужно было предусмотреть возможность интеграции с системой SAP R/3, а также перевода на японский язык всего пользовательского интерфейса! ). Даже если подобная ситуация не возникнет, нет никакой гарантии, что создаваемая ad hoc архитектура не будет намного более запутанной и сложной, чем было бы продуманное заранее решение. Подобным образом может неконтролируемо откладываться разрешение некоторых нетехнологических рисков, наподобие неопределенных границ проекта. Несмотря на все перечисленные ограничения, XP может замечательно работать в подходящих для него условиях. Благодаря крайне низким накладным расходам, в таких ситуациях этот процесс может показать исключительную эффективность. XP является достаточно гибкой методологией. Не обязательно внедрять XP во всей компании, вполне разумно ограничиться теми командами и проектами, которые могут получить от этого реальный выигрыш. Например, для разработки ядра продукта можно использовать XP, а проекты по внедрению основывать на процессе RUP. Также не обязательно использовать все классические практики XP (на самом деле, мало кто это делает) – как правило, разумно ограничиться теми из них, которые сочетаются с корпоративной культурой и особенностями проектов. Scrum — это платформа для процессов гибкой разработки. Она не включает в себя конкретные инженерные приемы. Напротив, XP фокусируется на инженерных приемах, но не включает в себя всеохватывающую платформу процессов разработки. Это не значит, что Scrum не рекомендует определенные инженерные приемы, или что в XP нет процесса. Например, первый Scrum реализовал все инженерные приемы, которые теперь известны как XP. Однако платформа Scrum для разработки программного обеспечения была призвана начать работу команды в течение двух или трех дней, в то время как для реализации инженерных приемов часто требуются многие месяцы. Поэтому вопрос, когда (и стоит ли) внедрять те или иные приемы, остается на рассмотрение каждой команды. Соавторы Scrum Джеф Сазерленд и Кен Швабер рекомендуют командам Scrum немедленно начинать работу и создать список препятствий и план улучшения процесса. Так как инженерные приемы идентифицируются как препятствия, командам следует обращаться к приемам XP как к способу улучшения. Лучшие команды реализуют Scrum, дополненный приемами XP. Scrum помогает XP масштабироваться, а XP способствует надлежащей работе Scrum.
Стандарт ГОСТ 34.601-90 В основе канонического проектирования лежит каскадная модель жизненного цикла ИС. Процесс каскадного проектирования в жизненном цикле ИС в соответствии с применяемым в нашей стране ГОСТ 34.601-90 «Автоматизированные системы Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы: 1. Формирование требований к АС 1. Обследование объекта и обоснование необходимости создания АС 2. Формирование требований пользователя к АС 3. Оформление отчета о выполнении работ и заявки на разработку АС 2. Разработка концепции АС 1. Изучение объекта 2. Проведение необходимых научно-исследовательских работ 3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей 4. Оформление отчета о проделанной работе 3. Техническое задание 1. Разработка и утверждение технического задания на создание АС 4. Эскизный проект 1. Разработка предварительных проектных решений по системе и ее частям 2. Разработка документации на АС и ее части 5. Технический проект 1. Разработка проектных решений по системе и ее частям 2. Разработка документации на АС и ее части 3. Разработка и оформление документации на поставку комплектующих изделий 4. Разработка заданий на проектирование в смежных частях проекта 6. Рабочая документация 1. Разработка рабочей документации на АС и ее части 2. Разработка и адаптация программ 7. Ввод в действие 1. Подготовка объекта автоматизации 2. Подготовка персонала 3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) 4. Строительно-монтажные работы 5. Пусконаладочные работы 6. Проведение предварительных испытаний 7. Проведение опытной эксплуатации 8. Проведение приемочных испытаний 8. Сопровождение АС. 1. Выполнение работ в соответствии с гарантийными обязательствами 2. Послегарантийное обслуживание Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные. Процессы жизненного цикла информационной̆ системы. ГОСТ 12 207 Основные процессы жизненного цикла (раздел 5) состоят из пяти процессов, которые реализуются под управлением основных сторон, вовлеченных в жизненный цикл программных средств. Под основной стороной понимают одну из тех организаций, которые инициируют или выполняют разработку, эксплуатацию или сопровождение программных продуктов. Основными сторонами являются заказчик, поставщик, разработчик, оператор и персонал сопровождения программных продуктов. Основными процессами являются: 1) Процесс заказа (подраздел 5.1). Определяет работы заказчика, то есть организации, которая приобретает систему, программный продукт или программную услугу. 2) Процесс поставки (подраздел 5.2). Определяет работы поставщика, то есть организации, которая поставляет систему, программный продукт или программную услугу заказчику. 3) Процесс разработки (подраздел 5.3). Определяет работы разработчика, то есть организации, которая проектирует и разрабатывает программный продукт. 4) Процесс эксплуатации (подраздел 5.4). Определяет работы оператора, то есть организации, которая обеспечивает эксплуатационное обслуживание вычислительной системы в заданных условиях в интересах пользователей. 5) Процесс сопровождения (подраздел 5.5). Определяет работы персонала сопровождения, то есть организации, которая предоставляет услуги по сопровождению программного продукта, состоящие в контролируемом изменении программного продукта с целью сохранения его исходного состояния и функциональных возможностей. Данный процесс охватывает перенос и снятие с эксплуатации программного продукта.
Вспомогательные процессы жизненного цикла (раздел 6) состоят из восьми процессов. Вспомогательный процесс является целенаправленной составной частью другого процесса, обеспечивающей успешную реализацию и качество выполнения программного проекта. Вспомогательный процесс, при необходимости, инициируется и используется другим процессом. Вспомогательными процессами являются: 1) Процесс документирования (подраздел 6.1). Определяет работы по описанию информации, выдаваемой в процессе жизненного цикла. 2) Процесс управления конфигурацией (подраздел 6.2). Определяет работы по управлению конфигурацией. 3) Процесс обеспечения качества (подраздел 6.3). Определяет работы по объективному обеспечению того, чтобы программные продукты и процессы соответствовали требованиям, установленным для них, и реализовывались в рамках утвержденных планов. Совместные анализы, аудиторские проверки, верификация и аттестация могут использоваться в качестве методов обеспечения качества. 4) Процесс верификации (подраздел 6.4). Определяет работы (заказчика, поставщика или независимой стороны) по верификации программных продуктов по мере реализации программного проекта. 5) Процесс аттестации (подраздел 6.5). Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта. 6) Процесс совместного анализа (подраздел 6.6). Определяет работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании. 7) Процесс аудита (подраздел 6.7). Определяет работы по определению соответствия требованиям, планам и договору. Данный процесс может использоваться двумя сторонами, когда одна из сторон (проверяющая) контролирует программные продукты или работы другой стороны (проверяемой). 8) Процесс решения проблемы (подраздел 6.8). Определяет процесс анализа и устранения проблем (включая несоответствия), независимо от их характера и источника, которые были обнаружены во время осуществления разработки, эксплуатации, сопровождения или других процессов. Организационные процессы жизненного цикла (раздел 7) состоят из четырех процессов. Они применяются в какой-либо организации для создания и реализации основной структуры, охватывающей взаимосвязанные процессы жизненного цикла и соответствующий персонал, а также для постоянного совершенствования данной структуры и процессов. Эти процессы, как правило, являются типовыми, независимо от области реализации конкретных проектов и договоров; однако уроки, извлеченные из таких проектов и договоров, способствуют совершенствованию организационных вопросов. Организационными процессами являются: 1) Процесс управления (подраздел 7.1). Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла. 2) Процесс создания инфраструктуры (подраздел 7.2). Определяет основные работы по созданию основной структуры процесса жизненного цикла. 3) Процесс усовершенствования (подраздел 7.3). Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла. 4) Процесс обучения (подраздел 7.4). Определяет работы по соответствующему обучению персонала.
Корпоративные стандарты — это принципы и правила, регулирующие деятельность компании, и нормативные документы, закрепляющие эти правила. Зачем нужны корпоративные стандарты? Что изменится в компании с их появлением? Корпоративные стандарты позволяют воспроизводить заданную технологию работ, помогают выявлять типичные ошибки, формировать желаемую корпоративную культуру. Сотрудники получают готовые решения для типовых задач, а руководители компании — четко сформулированные, формализованные требования к результатам деятельности работников. Нормативные документы — процедуры и регламенты — описывают основные процессы, существующие в организации, их можно назвать операционными стандартами. Они дают ответы на вопросы: что делать? когда? кто делает? где? что для этого нужно? Можно выделить стандарты, определяющие отношение к клиенту, коллегам, партнерам компании, регламентирующие исполнение профессиональных обязанностей, оформление рабочего места. В стандарте формулируются навыки и компетенции, которыми должен обладать человек, занимающий определенную должность. Кроме того, фиксируется уровень качества исполняемых обязанностей и описываются внешние обстоятельства, в которых будет оцениваться качество его работы. Каждая компания разрабатывает свой перечень корпоративных стандартов. Корпоративными стандартами называют соглашение о принципах и правилах, используемых компанией при ведении бизнеса, а также нормативные документы, закрепляющие эти соглашения. Наличие корпоративных стандартов и их исполнение позволяет руководству и собственникам компании повысить эффективность бизнеса и его стоимость. Предпосылки стандартизации Идея разработки внутренних нормативных документов, которые бы описывали и регламентировали деятельность предприятия, не является чем-то абсолютно новым для отечественной хозяйственной практики. Однако разрабатываются и используются данные документы главным образом для сферы производства — это и технологические карты, и сборочные чертежи, и спецификации, и т.п.
Однако требование наличия нормативной документации не является обязательным для других функциональных областей деятельности предприятия — снабжения, сбыта, управления персоналом, исследований и опытных разработок, ведения учета и планирования, формирования организационной структуры и т.д. Можно подумать, что они менее важны, чем производство. Конечно, производственная сфера обеспечивает выдачу продукта — того, что удовлетворяет потребности внешних клиентов, ради чего существует предприятие. Но ведь для того, чтобы производить, сначала необходимо создать соответствующие условия: обеспечить производство средствами и предметами труда, человеческими ресурсами. И, конечно, произведенный продукт надо еще и продать, поскольку иначе теряется сам смысл производства. Поэтому другие функциональные области деятельности компании не менее важны, чем производство.
Корпоративная стандартизация в значительной степени снимает остроту кадровой проблемы. За счет создания технологической основы для труда исполнителя снижаются требования к его квалификации и, соответственно, с нижаются затраты на оплату труда. Вернемся к примеру с токарем. Чтобы его труд был успешным, ему необходимы:
Почему же в этом смысле, например, работник бухгалтерии, как типичный представитель «непроизводственной» сферы, оказывается в менее выгодном положении? Рабочее место и компьютерную программу для ведения учета ему предоставили, а где же «описание того, как производить»? Где инструкции по ведению учета для того участка, который курирует бухгалтер? Почему имеет место такая профессиональная дискриминация?
7.Управление конфигурацией: содержание процесса управления конфигурацией, организация информационной поддержки процесса управления конфигурацией Управление конфигурацией является основополагающей дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы проекта, вносимые в них изменения и информация о состоянии отдельных задач и всего проекта в целом. Успех проекта в большой степени зависит от того, насколько хорошо построен процесс управления конфигурацией, который может как спасти проект, так и похоронить его, если сам процесс УК работает плохо. Аудит соблюдения политики Аудит соблюдения политики - это традиционная функция аудита. Организация имеет политику, определяющую настройки и конфигурацию систем безопасности. Аудит определяет реальное состояние дел. Любые отклонения отмечаются как нарушения. Подобные проверки могут выполняться внутренним персоналом или внешними консультантами. И в том и в другом случае этот процесс требует участия системных администраторов. Аудит соблюдения политики не должен ограничиваться только проверкой конфигурации систем. Он должен проявлять интерес к тому, как выполняются другие формы управления информацией. Соблюдается ли информационная политика? Как хранятся и передаются секретные документы? Проверки должны проводиться раз в год. Они могут выполняться персоналом отдела безопасности, но, возможно, выполнение аудита больше подходит для отдела аудита организации или для сторонней фирмы. Причина в том, что в данном случае могут быть затронуты интересы самого отдела безопасности, что приведет к возникновению конфликта интересов. Стандарты ИТ-аудита Вопросу аудита и внутреннего контроля за информационными системами посвящены несколько зарубежных стандартов аудита и специальный российский стандарт «Аудит в условиях компьютерной обработки данных (КОД)». Из зарубежных источников можно отметить международный стандарт аудита CobiT, ISA 401, положения по международной практике аудита 1002, 1003, 1004, 1008, 1009. В них отражены вопросы практики аудита в среде компьютерных информационных систем, оценки рисков и надежности системы внутреннего контроля в условиях КОД, техника проведения аудита с учетом использования современных информационных технологий. Рисунок 1. Состав книг CobiT
По определению: процесс — это действие, направленное на достижение результата, при оптимальном использовании ресурсов, и которое может корректироваться при его выполнении. При выполнении процесса все задействованные ресурсы структурируются и выстраиваются таким образом, чтобы максимально эффективно выполнять этот процесс. Во-вторых, процессы в подавляющем большинстве организаций, а особенно их цели не так часто изменяются, по сравнению с организационными объектами (организационно-штатная структура: сотрудники, отделы, департаменты и т.д.). В-третьих, развертывание информационной системы или внедрение информационных технологий не может быть ограничено спецификой одного отдела или департамента, а затрагивает руководителей, пользователей из других подразделений и ИТ-специалистов. Таким образом, прикладные системы (прикладное программное обеспечение то, что видит пользователь) — это неотъемлемая часть структуры CobiT и могут быть стандартно оценены, как и прочие объекты контроля CobiT, в рамках единой структуры и с применением единых метрик. |
Последнее изменение этой страницы: 2017-03-15; Просмотров: 1227; Нарушение авторского права страницы
Недостатки 
небольшую команду программистов (от 2 до 10 человек); 
Модель процессов, выстраиваемая на базе CobiT, предпочтительней других подходов, в основе которых не лежат бизнес-процессы организации (методики и стандарты аудита производителей программно-аппаратных средств), по нескольким причинам: