Содержание курса
Инфраструктура (ландшафт) для организации проектной деятельности
Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity
Разработка логической структуры данных. 2. Паттерны проектирования применительно к структуре данных.
Моделирование поведения целевой системы. 1. Теория систем Часть 2
Моделирование поведения целевой системы. 2. Поведенческие диаграммы UML
Моделирование поведения целевой системы. 3. Моделирование процессов управления
Разработка требований на создание целевой ИС. 1. Правила формирования требований
Разработка требований на создание целевой ИС. 2. Формирование Спецификаций требований
Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта
Организация процессов проектирования в производстве ИТ-продукта
1. Организация процесса передачи требований на этап реализации
Для эффективной организации производства Информационных систем (ИС) требования должны стать каркасом, связывающим все этапы жизненного цикла ИТ-продукта и передаваться от одной фазы к следующей, обеспечивая непрерывность и согласованность всего проекта. Так при реализации разработчики наделяют продукт функциональностью в соответствии с утвержденными требованиями. А тестировщики на основе спецификации требований разрабатывают план тестирования: к каждому функциональному требованию привязывают сценарии, тест-кейсы и подтверждают, что готовое решение удовлетворяет требованиям, и так далее по цепочке.
Поэтому, когда спецификации требований разработаны и производство готово к переводу на этап реализации целевого продукта, крайне важно обеспечить надлежащий процесс приема/передачи инициативы команде разработки. Проектировщики не могут просто кинуть требования на стол разработчикам и считать свою часть работы выполненной. Процесс передачи должен быть регламентирован и по возможности соблюдаться.
Процедура передачи может регулироваться, например, управленческими правилами делегирования, а именно:
Передавать требования на разработку можно только сотруднику, который имеет соответствующие полномочия и может нести ответственность за его выполнение. В противном случае ставить руководство в известность, об отсутствии у Вас возможности качественно выполнять свои функции.
Явно оговорить с исполнителем, какой конечный результат необходимо получить при реализации требования, а также способы выполнения задания. Желательно убедиться, что Вас понимают правильно и видят результат работы таким же, каким видите его Вы.
Определить приоритеты реализации требований, с учетом функций: обязательных и желательных к исполнению.
Договориться, что при возникновении затруднений у исполнителей с реализацией требований, необходимо сразу же обращаться к Вам для уточнения, разъяснения или изменения требования.
Регулярно проводить анализ хода выполнения работ и обсуждать проблемы, возникающие в процессе.
Утвердить предварительный график сдачи готовых решений.
Процесс передачи требований должен учитывать и то, что в последствии при внедрении целевой системы необходимо будет обеспечивать соответствие ИС первоначальным требованиям заказчика, который принимает и оценивает продукт именно по утверждённой спецификации требований. Таким образом, при передаче требований важно уточнить и параметры для определения критериев приемки.
И далее после ввода системы в эксплуатацию жизнь требований так же не заканчивается. На этапе сопровождения они продолжают «сопровождать» систему через исправление ошибок и расширение функциональности.
2. Управление изменениями требований
Цель данной группы работ: Обеспечить устойчивость процесса разработки и сопровождения целевого продукта при изменении требований.
В процессе эксплуатации внедренного продукта собираются замечания пользователей и данные о работе системы. На их основе часто формулируются новые или уточнённые требования. В результате начинается новый цикл: вносятся изменения в спецификацию требований, которые затем прослеживаются в обновлении дизайна, кода, тестов и так далее.
Поэтому одной из важнейших характеристик процесса управления требованиями является его приспособленность к внесению изменений. Имея актуальные качественные требования, большую часть дополнительных модификаций продукта, можно спрогнозировать и спроектировать, или просто отказаться от новшеств в угоду стабильности эксплуатируемой системы.
Процесс модификации уже введенной в эксплуатацию ИС, зачастую сложнее и требует большей слаженности действий, чем разработка новой функциональности. В ходе модификации дополнительно возникают еще и структурные барьеры, вызывающие цепные реакции сбоев в связанных модулях, подсистемах, компонентах, а также организационные, в виде бюрократии, взаимодействия разных команд и служб заказчика, и прочее.
А потому изменения в продукт необходимо вносить, только через пересмотр и трансформацию требований. Удобно это делать, используя систему контроля версий. Процесс изменений требований обязательно должен затрагивать проработку вопросов организации взаимосвязанных активностей для последующего воплощения изменений, иногда совместными усилиями нескольких команд. Ведь если одна команда внесет изменения в продукт, а у смежной не будет на это времени и(или) ресурсов, может произойти глобальный сбой. Это касается не только команд разработчиков, но и пользователей ИТ-продукта и прочих заинтересованных лиц, которых коснуться новшества.
Поэтому процесс изменений целесообразно начинать с обсуждения самой необходимости нововведения, например, через заявку на модификацию. Это позволит не только систематизировать и структурировать обращения, но и в случае неуспехов и провалов избежать неаргументированных обвинений.
Учитывая все вышесказанное, при внесении изменения в требования необходимо выполнить следующий комплекс шагов:
2.1. Проанализировать изменения, согласовав контекст со всеми заинтересованными лицами.
Включает в себя 3 обязательных этапа:
Описание изменений. На данном этапе необходимо коротко и ясно изложить, для чего предназначено данное изменение, какие цели преследует и кто инициатор.
Это позволяет впоследствии легко вспомнить, зачем это было сделано, кому это было нужно и сохраняется ли такая необходимость сейчас. Даже если изменение чисто техническое, также укажите это, чтобы потом не вспоминать для чего именно был установлен этот патч или сделана эта настройка.
Описание зависимостей. Следующий этап определяет модули, от которых зависит наше изменение, а также те модули на которое оно может повлиять. Это поможет правильно оценить риски и оценить время вынужденного простоя инфраструктуры.
Также следует определить критичность вносимых изменений для той или иной команды. Иногда уже на этом этапе следует отказ от изменения, либо его более детальная проработка, если оказывается, что потенциальный риск превышает потенциальную выгоду.
Выделение ресурсов. Еще один момент, о котором часто забывают. Проанализируйте, какие ресурсы требуются или могут потребоваться вашему изменению и возможно цепочке изменений в связанных компонентах.
Это могут быть специалисты, процессорные и дисковые ресурсы, требования к наличию свободной памяти, место в стойке, наличие розеток и запаса по электропитанию и т.д.
2.2. Согласовать стоимость изменения с заказчиками/ поставщиками.
Этот шаг, так же включает 3 этапа:
1) Подготовка. Важно спланировать предварительные действия, которые необходимо провести перед тем, как вносить изменения. Особенно если они связаны с привлечением третьих лиц.
Например, будет очень неприятно узнать, смонтировав оборудование в новую стойку, что электрик еще не провел сюда электричество или провайдер не выделил необходимый блок адресов и т.п.
2) Планирование. Самый важный пункт документации. Он должен как можно более подробно и последовательно описывать все действия по внесению изменений. Подробно укажите действия на каждом этапе и планируемый результат данных действий.
В итоге у вас должен получиться чек-лист, в котором Вы будете отмечать выполненные изменений. Если вдруг что-то пойдет не так, вы будете четко знать, что вы сделали последним и круг поисков проблемы значительно сузится.
Далее отметьте критичность тех или иных этапов плана, некритичные шаги можно пропустить, проблемы средней важности допустимо решать непосредственно при изменениях, а при возникновении критических ошибок следует сразу переходить к восстановлению.
3) План восстановления. Важный момент, который необходимо продумать - последовательность действий по приведению системы в первоначальное состояние на случай, если что-то пойдет не так.
Приступая к изменениям очень важно убедиться в наличии резервных копий и что есть возможности восстановления.
Наличие плана восстановления хорошо тем, что в аварийная ситуация не перерастет в авральную, а будет находиться под контролем. Не забудьте четко ограничить временные рамки, по истечению которых вам нужно переходить к восстановлению.
2.3. Организовать анализ работ по переделке.
Чтобы оценить эффективность внедрения управления изменениями, воспользуйтесь следующими метриками:
Количество изменений, внесенных в продукт, согласно требованию клиентов.
Сокращение числа сбоев, ошибок и инцидентов, связанных с внесением изменений.
Сокращение количества несанкционированных изменений.
Коэффициент успеха – процент изменений, которые были признаны успешными, от количества запросов на изменение (RFC).
Число неудачных изменений.
Среднее время применения изменений с учетом срочности, приоритета и типа изменения.
Инциденты, связанные с применением изменений.
3. Стратегии замены ИТ продуктов
На практике очень часто приходится не просто разрабатывать новый программный продукт, а выполнять замену устаревшего ПО.
Эта тема подробнее будет рассмотрена в курсе «Организация производства Информационных систем», затронем лишь основные аспекты.
Из основных причин, побуждающих к замене средств автоматизации, можно выделить:
Изменение внешних, по отношению к системе, условий, влияющих на ее функционирование. Например, изменения в законодательстве;
Борьба с дезорганизацией в системе, связанная с быстрым накоплением информации и изменениям требований к ее качеству;
Качественное изменение инфраструктуры системы. Например, ужесточение требований к безопасности;
Геополитика. Импортозамещение;
Замена устаревших ИС на новые, часто является не просто эволюционным развитием бизнес деятельности предприятия, а трансформацией всей организации в целом. Такого рода вызовы требуют устранения не только технических проблем, но и, возможно, изменения структуры бизнеса, организации новых цепочек бизнес-процессов, создания новой корпоративной культуры и прочее. Поэтому сам процесс замены ИС должен рассматриваться как цельная, управляемая система, охватывающая технические, организационные, бизнесовые и социальные аспекты. Системный подход требует рассмотрения всех активностей от бизнес-целей до технических деталей перехода от старой системы к новой и управления изменениями.
Выработка стратегии замены ИС позволяет значительно снизить:
Длительность времени разработки критичной для бизнеса функциональности (ТТМ, time-to-market);
Рост стоимости владения программно-аппаратными комплексами (TCO);
Ограничения в масштабируемости, недостаточной доступности и надёжности;
Количество сбоев и потерь при переходе;
Сложности с организацией непрерывности бизнес-процессов;
Сложности с своевременны обучением пользователей;
Дублирования функциональности;
Прочее.
Термин | Значение |
Стратегия замены ИТ-продуктов | это продуманный план, как безопасно, поэтапно и эффективно заменить существующую информационную систему, программное обеспечение или ИТ-продукт на новое решение, минимизируя риски для бизнеса |
Перед началом проектирования, необходимо максимально полно провести аудит используемых систем и уже на основе его разработать стратегию перехода от старого к новому. При этом, чаще всего изменения ИТ-структуры предприятия сопровождаются следующими факторами влияния:
Наличие технологий уже используемого продукта, опыт его внедрения и проблемы эксплуатации;
Сложившиеся привычки и традиции пользователей, длительное время взаимодействующих с заменяемым ПО;
Необходимость переноса данных из старой системы в новую, а возможно и синхронизацию работы обоих систем на какое-то время;
Обеспечение достаточных ресурсов для замены системы.
В связи с перечисленными аспектами метод перехода может быть: единовременным, поэтапным или параллельным. Каждый имеет свои преимущества и риски, которые следует учитывать при планировании внедрения.
Big Bang (единовременный переход).
Этот подход называю еще «Взрывным». Он означает миграцию всей системы одномоментно: все модули и пользователи переключаются на новую систему разом. Характеризуется следующими аспектами:
Быстрый запуск. Проект перехода может завершиться в короткий срок, так как нет длительной фазы поддержки двух систем. Например, не нужно тратить ресурсы на организацию и поддержку обмена данными между старой и новой системами.
Экономия ресурсов. Нет расходов на параллельную эксплуатацию двух систем, что обычно удешевляет проект, снижает нагрузку на пользователей.
Высокий риск. Любая проблема, возникающая в рамках перехода, сразу отражается на всей организации. Отсутствует «запасной» вариант, и при любой критической проблеме приходится откатываться на старую систему, при этом восстанавливая в ней данные за период отключения. Каждый последующий откат накапливает негатив заказчика и пользователей.
Потеря гибкости. Поскольку переключение происходит единовременно, при ошибке сложнее скорректировать план или невозможно вернуть отдельные подразделения на старую систему.
Окупаемость инвестиций наступает лишь после полного завершения перехода.
Единовременный переход обычно подходит небольшим компаниям с простыми процессами или ситуациями, когда требуется быстрое, экономное внедрение даже ценой повышенного риска.
Phased migration (Поэтапная миграция)
При поэтапном подходе внедрение разбивается на этапы (за основу берутся модули, подразделения или функции). Сначала запускаются наименее критичные или пилотные части системы, затем — остальные. Такой подход снижает риски перехода. Характеризуется следующими аспектами:
Постепенный перенос. Система вводится по частям (например, сначала складской учет, потом бухгалтерия, и т. д.), что даёт возможность выявлять и устранять ошибки на ранних этапах и в локальных частях ИС.
Высокий ROI (коэффициент рентабельности инвестиций) для отдельных контуров системы. Менее критичные сегменты запускаются первыми, принося пользу заранее (ранняя окупаемость).
Возможность параллельного тестирования. Пока часть сотрудников работает на новой системе, остальные ещё на старой, что позволяет тщательно проверять данные и дорабатывать систему «на ходу».
Однако у этого подхода есть и минусы:
Продолжительность проекта. Многократные этапы внедрения новых частей ИС удлиняют общие сроки внедрения.
Двойные расходы. В течение перехода приходится поддерживать старую систему и новые модули одновременно — это увеличивает затраты на ИТ и усложняет проект.
Сложности интеграции. Между этапами может потребоваться интеграция старой и новой систем, синхронизация данных с разной структурой, миграции справочной информации и т. д.. Что усложняет архитектуру решения (нагружает ИТ‑команду и бюджет).
Стратегия поэтапной миграции оправдана в крупных, комплексных организациях, где важна стабильность бизнеса. Она позволяет адаптироваться постепенно и снижать риск простоя.
Parallel adoption (Параллельное внедрение)
При параллельном подходе новая и старая системы работают одновременно в течение переходного периода. Это обеспечивает надежность перехода, поскольку есть возможность в любой момент вернуться к старой системе. Характеризуется следующими аспектами:
Минимизация простоев. Ключевые бизнес‑процессы выполняются на старой системе до полной готовности новой, что исключает перерывы в работе.
Высокая надежность. Новую систему можно тщательно тестировать «на реальных данных», сверяя результаты с показателями старой системы. При необходимости легко откатиться к проверенной конфигурации.
Качественное обучение. Персонал продолжает работать в прежней системе, пока параллельно осваивает новую, что повышает качество подготовки и снижает человеческие ошибки.
Недостатки параллельной схемы связаны с её дороговизной и сложностью:
Двойные затраты. Обслуживание двух полноценных систем требует больших ресурсов и времени. Параллельный подход — самый дорогостоящий по сравнению с другими методами.
Дублирование работ. Пользователи выполняют операции в обеих системах (например, вводят одинаковые данные дважды), что увеличивает нагрузку и риск искажения при синхронизации.
Управленческие сложности. Двойное ведение процессов требует чёткой координации: нужно постоянно следить за согласованностью данных и прогрессом перехода.
Такой подход целесообразен, когда запрещён любой простой системы (например, в финансовом учёте или при строгих регламентированных сроках).
При замене ИС основой трансформации должен стать ИТ-ландшафт, обеспечивающий развитие компании на годы вперёд и поддерживающий её дальнейшую цифровую трансформацию. Кроме того, совместное решение этих задач требует регламентирования процессов и в конечном счете обеспечит экономию по сравнению с реализацией нескольких отдельных проектов.
ИТ-ландшафт должен предоставить:
Единую точку контакта в коммуникациях;
Единую команду, осуществляющую трансформацию;
Гибкие реактивные сервисы;
Гибкие преактивные сервисы;
Единый стандарт и инструментарий.
Тему ИТ-ландшафта мы подробно рассматривали ранее.
Еще один полезный инструмент системного подхода в организации ИТ-инфраструктуры предприятия - Портфель прикладных систем. Он, с одной стороны, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. С другой, включает в себя набор ИС, как существующих, так и вакантных на данный момент. То есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации.
Таким образом он позволяет определить актуальный уровень покрытия необходимой функциональности бизнес-архитектуры, цифровыми решениями. А также устанавливает ответственность и приоритетность каждого приложения и варианты достижения результата, посредством либо разработки системы, либо приобретения готовых продуктов, учитывая интеграцию и использование возможностей уже имеющихся приложений. Подробнее эти вопросы мы будем рассматривать в курсе «Архитектура предприятия».
Одним из критических условий внедрения изменений, является активное и, что немаловажно, эмоциональное вовлечение всех заинтересованных лиц в процессы обсуждения и разработки стратегии перехода от старого к новому.
Сотрудники, которых должны коснуться изменения, с самых ранних стадий проекта должны привлекаться к проектированию нового продукта. Дайте им почувствовать, что они являются авторами новой системы, что они ответственны за то, какой она получится.
Поскольку процесс замены старого ПО на новое длительный и сопряжен с проявлением множества трудно прогнозируемых рисков, необходимо постоянно следить за прогрессом перехода. Для этого можно заранее определить вехи проекта и четко отслеживать их наступление (или не наступление). Если выполнение какого-либо из этапов не увенчалось успехом, то может возникнуть необходимость организованно «откатиться» на предыдущий этап.
Так же очень важно, при выполнении действий по стратегическим изменениям, постоянно отслеживать барьеры, препятствующие реальному достижению запланированных целей. Для этого все подобные факты фиксируются, доводятся до внимания заинтересованных лиц и совместно с ними вырабатывается план мероприятий по их устранению.
Характерным для этого типа активностей является подход к управлению изменениями Джона Коттера:
«внедрение изменений происходит путем достижения краткосрочных успехов, которые происходят снова и снова, накапливая совокупную энергию, противостоящую скептикам и циникам. Именно поэтому, успехи необходимо всячески демонстрировать сотрудникам и всем заинтересованным лицам проекта. Именно это поможет достичь уважения и доверия при внедрении инноваций».
