RPA: 4 варианта использования в IT-отделах
Пример использования 1: сброс пароля
Проблема: обычно IT-команда крупной нефтегазовой компании получает более 500 запросов на сброс паролей в день. Этот процесс повторяется и занимает около 30% времени члена IT-команды.
Решение:программный робот автоматизирует процесс сброса паролей, собирая запросы пользователей из корпоративной системы, входя в указанное приложение, сбрасывая пароль и отправляя его пользователю. Затем он отмечает запрос как решённый и уведомляет IT-команду о статусе.
Пример использования 2. Управление учётной записью
Проблема: IT-команда компании среднего размера, занимающаяся розничной торговлей через Интернет, тратит от 1 до 2 часов на создание учётной записи пользователя, что подразумевает обработку данных пользователей в различных системах в рамках процедуры адаптации.
Решение: программный робот создаёт новую учётную запись, настраивает и предоставляет пользователям данные для доступа по умолчанию, уведомляет IT-отдел и отдел кадров после завершения и отмечает задачу как решенную.
Пример использования 3: IT-поддержка
Проблема: IT-команда крупной юридической консалтинговой компании сталкивается с проблемой огромного количества времени, которое тратится на различные приложения и инструменты, используемые членами команды при решении пользовательских запросов.
Решение: используются, чтобы помочь IT-команде в обработке запросов на поддержку и администрирование. Пользователи создают запросы на обслуживание непосредственно из централизованной корпоративной системы, которые затем обрабатываются роботами и выполняются.
Пример использования 4. Управление данными
Проблема: перенос данных из одной системы в другую для IT-отдела крупной финансовой консультационной компании обычно занимает несколько часов. Помимо того, что эта задача отнимает много времени, она сложна из-за множества используемых форматов данных.
Решение: программный робот автоматизирует распознавание файловых данных и ввод в необходимые системы в заранее заданной последовательности. Отслеживание журналов выполнения также позволяет IT-команде отслеживать успешность и общее качество процесса переноса данных.
Не все так однозначно
Если единожды установлены требования к безопасности информационных систем, информационному наполнению, формату, управленческим задачам и прочим аспектам функционирования проекта, это еще не значит, что таковые будут неизменными до самого «победного конца». Рабочий процесс нередко сопровождается изменением установленных спецификаций, требований. Происходит это не только по инициативе заказчика, но и исполнителя, сталкивающегося с определенными техническими ограничениями, не допускающими воплощения в жизнь ряда запланированных аспектов
Важно учитывать особенности контроля процессов. Управление изменениями – это один из ключевых аспектов разработки требований и их реализации в рамках конкретной ИС
Важный аспект работы с требованиями – определение таковых с последующей разносторонней аналитикой информации. Для этого применяют обобщенную модель работы. В рамках конкретного предприятия реализуется уникальная система управления требованиями информационных систем, позволяющая формулировать, корректировать, принимать, отвергать выбранные условия. Многое зависит от квалификации работников, типа ИС, над которой работают, применяемых в рабочем процессе стандартов.
Требования: откуда их взять?
Задачи формулирования и утверждения требований к информационной системе не столь просты, как это может показаться на первый взгляд. Термином принято обозначать такой сложный структурированный процесс, в рамках которого создается, подтверждается заказчиком, исполнителем документация, четко регламентирующая все спецификации продукта. Разработка подразделяется на четыре последовательных шага:
- аналитическая деятельность для определения степени реализуемости запланированного;
- создание, аналитическое изучение непосредственно требований;
- формулировка требований для формирования сопроводительной документации;
- аттестация требований к данным информационной системы, а также прочих условий, правил реализации проекта.
COBIT (Control Objectives for Information and related Technology)
– стандарт управления и аудита в области информационных технологий. Основой стандарта COBIT являются 34 высокоуровневые цели контроля, по одной на каждый ИТ- процесс, которые сгруппированы в 4 домена: Планирование и Организация, Проектирование и Внедрение, Эксплуатация и Сопровождение, Мониторинг. Особенностью стандарта COBIT по отношению к другим стандартам в области ИТ является присутствие в нем модели зрелости разработанной в конце 80-х годов Институтом проектирования и разработки программного обеспечения (Software Engineering Institute’s). Maturity Models (MM) – не технология, не стандарт, для нее нет формальных описаний, в ней нет жестких требований, и она не привязана к конкретным информационным технологиям. Однако данная модель зрелости вводит понятие нескольких уровней зрелости процессов:
- Не существует. Полное отсутствие каких-либо процессов управления ИТ. Организация не признает существования проблем в ИТ, которые нужно решать, и, таким образом;
- Начало. Организация признает существование проблем управления ИТ и необходимость их решения. При этом не существует никаких стандартизованных решений;
- Повторение. Существует всеобщее осознание проблем управления ИТ. Показатели деятельности и ИТ-процессов находятся в развитии, охватывая процессы планирования, функционирования и мониторинга ИТ;
- Описание. Необходимость действовать в соответствии с принципами управления ИТ понимается и принимается. Процедуры стандартизованы и документированы;
- Управление. Существует полное понимание проблем управления ИТ на всех уровнях организации, постоянно происходит обучение сотрудников. Четко распределена ответственность, установлен уровень владения процессами;
- Оптимизация. В организации существует углубленное понимание управления ИТ, проблем и решений ИТ, а также перспектив. В результате непрерывного улучшения процессы соответствуют моделям зрелости, построенным на основании «лучшей практики».
Использование механизма оценки уровней зрелости и целей контроля, делает данный стандарт более высокоуровневым, хотя в нем содержится множество полезной информации для организации процессов ИТ. Данай стандарт наиболее эффективно использовать для определения целей в области ИТ, построения системы сбалансированных показателей (BSC) для ИТ- подразделения и проведения внутренних и внешних аудитов в области информационных технологий, помимо этого, на основании результатов аттестации процессов по уровням зрелости возможно сформировать мероприятия по совершенствованию процессов.
Как улучшить контроль и планирование ИТ
Результаты опросов российских гендиректоров, что они ожидают от улучшения планирования и контроля ИТ, проведены на Рис. 7:
Рис. 7. Увеличение планирования и контроля ИТ: типовые требования
Как правило, гендиректора оценивают, хорошо или плохо планируется и контролируется ИТ, рассматривая несколько показателей (к сожалению, малоформулируемых и сложных для оценки):
- контроль ИТ;
- планирование ИТ;
- мотивация сотрудников ИТ.
Результаты опросов гендиректоров показывают типовые проблемы и их решения в области планирования и контроля ИТ:
Табл. 7. Планирование и контроль ИТ: типовые проблемы и их решения
|
Типовые проблемы |
Типовые решения (проекты) |
|
|
В Табл. 8 приведены оценки, насколько типовые проекты по ИТ, могут улучшить планирование и контроль ИТ:
Табл. 8. Улучшение планирования и контроля ИТ
|
Типовые для российских предприятий проекты по ИТ |
Контроль ИТ |
Планирование ИТ |
Мотивация сотрудников ИТ |
Итого |
|
Автоматизация направлений бизнеса |
||||
|
Автоматизация продаж (внедрение CRM) |
||||
|
«Продающий сайт» |
||||
|
Автоматизация производства (ERP) |
||||
|
Автоматизация документооборота |
+ |
1 |
||
|
Внедрение BI |
||||
|
Автоматизации управления поставками (SCM) |
||||
|
Инфраструктура ИТ |
||||
|
ЦОД: создание |
+ |
++ |
3 |
|
|
ЦОД: аренда |
+ |
+ |
2 |
|
|
Сети: резервные каналы связи до всех филиалов |
||||
|
«Облачные вычисления» |
+ |
++ |
3 |
|
|
Управление ИТ |
||||
|
ИТ-стратегия |
+++ |
+++ |
++ |
8 |
|
Каталог ИТ-сервисов и SLA |
++ |
+ |
+ |
4 |
|
Автоматизация службы поддержки ИТ |
++ |
+ |
+ |
4 |
Обозначения: «+++»: высокое положительное влияние;
++» и «+»: среднее и небольшое положительное влияние;
— —» и «—»: среднее и небольшое негативно влияние;
?»: не ясно какое будет влияние.
Итого, вот наиболее потенциально уместные проекты по улучшению планирования и контроля ИТ:
- разработка ИТ-стратегии;
- каталог ИТ-сервисов и SLA;
- автоматизация службы поддержки ИТ.
Как снизить риски ИТ
Результаты опросов российских гендиректоров, что они ожидают в области уменьшения рисков ИТ, приведены на Рис. 5:
Рис. 5. Уменьшение рисков ИТ: типовые требования
Как правило, гендиректора обычно оценивают риски ИТ, как три показателя:
- время неработоспособности ИТ (как технических средств, так и информационных систем);
- объемы потерянной информации, если что то пойдет не так;
- вероятности кражи и утечек информации.
Результаты опросов гендиректоров показывают типовые проблемы и их решения в области уменьшения рисков ИТ (см. Табл. 3):
Табл. 3. Риски ИТ: типовые проблемы и их решения
|
Типовые проблемы |
Типовые решения (проекты) |
|
|
В Табл. 4 приведены оценки, насколько типовые проекты по ИТ могут уменьшить типовые ожидаемые риски от использования ИТ:
Табл. 4. Уменьшение рисков ИТ
|
Типовые для российских |
Неработо- |
Потеря |
Утечки |
Итого |
|
Автоматизация направлений бизнеса |
||||
|
Автоматизация продаж |
||||
|
«Продающий сайт» |
||||
|
Автоматизация производства (ERP) |
||||
|
Автоматизация документооборота |
||||
|
Внедрение BI |
||||
|
Автоматизации управления |
||||
|
Инфраструктура ИТ |
||||
|
ЦОД: создание |
+++ |
+++ |
+++ |
9 |
|
ЦОД: аренда |
+++ |
+++ |
+ |
7 |
|
Сети: резервные каналы связи |
+++ |
++ |
5 |
|
|
«Облачные вычисления» |
+ |
++ |
— — |
1 |
|
Управление ИТ |
||||
|
ИТ-стратегия |
++ |
+ |
+ |
4 |
|
Каталог ИТ-сервисов и SLA |
+ |
+ |
+ |
3 |
|
Автоматизация службы поддержки ИТ |
++ |
+ |
+ |
4 |
Обозначения: «+++»: высокое положительное влияние;
++» и «+»: среднее и небольшое положительное влияние;
— —» и «—»: среднее и небольшое негативно влияние;
?»: не ясно какое будет влияние.
Итого, наиболее потенциально уместные проекты для уменьшения рисков от использования ИТ, это:
- создание или аренда Центра Обработки Данных, который может существенно уменьшить время неработоспособности ИТ, а также возможные потери информации;
- сети: резервные каналы связи до всех филиалов.
Сделайте свою команду настоящими IT-энтузиастами
В этой статье мы рассмотрели реализацию RPA с разных сторон и предоставили вам реальные примеры использования того, как автоматизация берёт на себя бремя повторяющихся задач от IT-команд в компаниях различного размера и специфики.
Суть в том, что автоматизация — это правильное решение не только для устранения рутинных, повторяющихся задач или упрощения операционной рутины, но и для обеспечения повышения качества и управления IT в вашей организации.
Используя RPA в IT, вы можете освободить свою команду от утомительных задач и предложить им возможности использовать свои навыки критического мышления для улучшения IT-инфраструктуры компании, уделяя больше внимания успешной цифровой трансформации.
Готовы попробовать автоматизацию в своём IT-отделе? Свяжитесь с нашими экспертами и начните своё путешествие по RPA уже сегодня!
Цели и задачи стандарта обслуживания клиентов
Задача стандарта — установить минимальные требования к качеству обслуживания клиентов в компании и помочь сотрудникам с их соблюдением, чтобы в конечном счете обеспечить конкурентное преимущество на рынке. Стандарт должен описывать такой сервис, за который клиент будет готов заплатить.
Но стандарт обслуживания не должен учитывать только интересы клиента. В подобные документы часто включают перечень действий, направленных на повышение прибыли. Например, обязательство сотрудников предложить клиенту дополнительные услуги при обращении по заявке. Так в стандарте отражаются интересы бизнеса.
В целом стандарт помогает достичь определенной зрелости компании. Он описывает оптимальные рабочие процессы, а поэтому помогает избежать ненужных действий со стороны сотрудников. Фактически, стандарт может выполнять роль инструкции и помогает быстро вводить в курс дела новый персонал. Также стандарт задает измеримые и понятные персоналу критерии оценки качества их работы. А в крупных и сетевых компаниях стандарты помогают унифицировать эти критерии между филиалами.
Чем выгоден SLA для бизнеса
Для бизнеса договоры SLA — это гарантия сроков и качества сервисного обслуживания. Этот договор дает возможность понимать, как организована работа сторонних специалистов. Кроме того, с помощью SLA компания может настроить бизнес-процессы таким образом, чтобы добиться максимальной клиентоориентированности и тем самым отстроиться от конкурентов.
Заключение SLA показывает заказчику, что конкретно будет сделано, каков объем у этих работ и в какие сроки будет получен результат. А если исполнитель не выполняет взятые обязательства, то каков размер компенсации. Например, в SLA можно прописать сроки устранения инцидентов, которые связаны с прерыванием различных сервисов, а также штрафы за несоблюдение этих сроков.
Подытожим. Благодаря SLA заказчик:
- может измерить стоимость услуги с помощью четких параметров;
- получает реальное представление о сроках оказания услуг;
- минимизирует финансовые потери из-за возможных ошибок исполнителя;
- настраивает с учетом потребностей сервисное сопровождение бизнеса.
Индивидуальные настройки SLA
Ключевая ценность работы по SLA состоит в том, что соглашение об уровне обслуживания можно составить максимально персонализированно и адаптировать под бизнес-процессы заказчика. Как следствие, это позволит сократить затраты на ненужные для эффективной работы услуги.
Рассмотрим на примере. Есть бизнес-компания, сотрудники которой пользуются ее системами только в дневное время. Компания заключает договор с ИТ-службой с запросом на доступность поддержки в 99.999%. Если посчитать, то время простоя не должно превышать 1 минуту в год. Для исполнителя это довольно жесткие условия: нужно организовать резервное питание и постоянную техническую поддержку, что требует значительных финансовых вложений. На деле заказчику это не нужно: достаточно будет организовать поддержку в рабочее время: 8/5 вместо 24/7. Такой вариант будет дешевле и не отразится на надежности ИТ-сервисов, а значит не повлияет на конечную эффективность бизнеса. Все нюансы, которые относятся к времени обслуживания, также следует отразить в SLA.
Типовые варианты выявления требований бизнеса к ИТ на 1 год и более
Рекомендации в зависимости от того, что надо улучшать:
- если требования бизнеса к ИТ уже есть, лучше провести аудит выполнения требований к ИТ.
Аудит должен дать независимую оценку, адекватны ли требования бизнеса к ИТ в вашей компании. Вряд ли вашей компании надо работать также четко как Google, IBM и другие ИТ-компании, но надо быть не хуже ваших основных конкурентов. - если есть возможность, лучше также спланировав развитие на 1-3 года всех остальные элементов ИТ (информационные системы, инфраструктура, управление ИТ) в рамках совместной с консультантами разработки ИТ-стратегии.
- если гендиректор вашей компании обеспокоен (или наоборот, воодушевлен) цифровой трансформацией бизнеса, то запланировать развитие оргструктуры ИТ-службы (да и всех основных элементов ИТ) можно в рамках разработки стратегии цифровой трансформации бизнеса (или его первого шага — стратегии создания единой цифровой платформы бизнеса).
А вот рекомендации в зависимости от размеров компаний:
- для малых компаний вряд ли уместен консалтинг по разработке требований к ИТ. Однако, может быть уместен вариант обучения по ИТ-стратегии с параллельной разработкой ИТ-стратегии, все работы могут быть уместны и по стоимости и по количеству;
- для средних компании уместен аудит выполнения требований к ИТ, а также совместной с консультантами разработки ИТ-стратегии.
- для крупных компаний уместен любой консалтинг, с учетом всех особенностей компании.
|
Практики ЖЦ требований по ISO 15288
Жизненный цикл требований стейкхолдеров
- Подготовиться (идентифицировать стейкхолдеров, определить стратегию определения потребностей стейкхолдеров и требований, получить или купить обеспечивающую систему и сервисы)
- Определить потребности стейкхолдеров (определить контекст использования, идентифицировать потребности стейкхолдеров, приоритизировать и отобрать потребности, определить потребности стейкхолдеров и их обоснование)
- Разработать Концепцию функционирования (operational concept) и другие концепции жизненного цикла (определить набор сценариев, определить взаимодействия пользователей и системы)
- Преобразовать потребности стейхколдеров в требования стейкхолдеров (идентифицировать ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все функции для требований качества, гармонизировать требования стейкхолдеров)
- Анализировать требования стейкхолдеров (анализировать полное множество требований стейкхолдеров, определить критические показатели результативности, которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
- Управлять определением потребностей стейкхолдеров и требованиями (получить явное согласие на требования стейкхолдеров, поддерживать трассировку потребностей и требований, обеспечивать сведения по базисам)
Жизненный цикл требований к системе
- Подготовиться (определить функциональную границу системы в терминах поведения и свойств, которые нужно обеспечить, определить стратегию определения системных требований, идентифицировать и спланировать обеспечивающую систему для определения системных требований, получить или купить обеспечивающую систему)
- Определить системные требования (определить каждую функцию, которую должна выполнять система, определить необходимые реализационные ограничения, определить системные требования, которые относятся к риску, критичности системы или критические характеристики качества, определить системные требования и их обоснование)
- Анализировать системные требования (анализировать полный набор системных требований, определить критические характеристики качества, которые делают возможным оценку технического достижения, предоставить требования системы подходящим стейкхолдерам для рассмотрения, решить все возникшие проблемы с требованиями)
- Управлять системными требованиями (получить явное соглашение по системным требованиям, поддержать трассировку по системным требованиям, обеспечить информацию базиса)
Когда стандарты не помогут?
Важно помнить, что не только отсутствие стандартов обслуживания может быть узким местом вашего сервиса. Если у вас в принципе не организована работа выездных монтажников или поставка недостающих запчастей, разработка стандарта обслуживания не поможет создать у клиента представление о качественном сервисе
Когда клиенту приходится ждать по несколько дней приезда ремонтной службы, улыбка на лице выездного инженера вряд ли сможет нейтрализовать негатив.
Перед тем, как браться за разработку стандартов обслуживания, необходимо убедиться, что основные бизнес-процессы работают так, как надо.
1.6 Бизнес-риски
Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта. В категорию рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы, влияющие на бизнес. Бизнес-риски отличаются от рисков проекта, которые обычно связаны с доступностью ресурсов и особенностями технологий. Оцените возможные потери от каждого фактора риска, вероятность его возникновения, вашу способность контролировать его, а также определите все возможные действия по смягчению ситуации.
1.7 Предположения и зависимости
Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.
Бизнес-предположения тесно связаны с бизнес-требованиями. Неверные предположения могут не позволить достичь поставленных бизнес-целей. Например, куратор из руководства компании может поставить бизнес-цель увеличить доход на 100 тыс. долларов в месяц. Определяя такую цифру, куратор сделал определенные предположения, например что новый сайт будет привлекать 200 дополнительных уникальных посетителей в день и что каждый посетитель в среднем будет тратить 17 долларов. Если новый сайт не привлечет достаточно посетителей, тратящих достаточное количество денег, проект может не достичь своей бизнес-цели. Если окажется, что те или иные предположения не оправ дались, можете изменить границы или график проекта или запустить другие проекты, чтобы достичь другие цели.
Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ о концепции и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то избежите возможной путаницы и ухудшения ситуации в будущем.
Задокументируйте важнейшие зависимости проекта от внешних факторов — изменения отраслевых стандартов или предписаний регулирующих органов, других проектов, сторонних поставщиков или партнеров по разработке. Предположения и зависимости бизнеса могут превратиться в риски, которые должен регулярно отслеживать менеджер проекта. Нарушение зависимостей — популярная причина задержек проекта
Опишите возможные последствия того, что предположения окажутся ошибочными или зависимости нарушены, чтобы заинтересованные лица могли понять, почему это так важно
Обычно разработке качественного ТЗ мешают следующие моменты:
Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.
Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.
Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.
Исполнитель и заказчик не могут предвидеть заранее все возможные проблемы. Опытные участники проекта с обоих сторон могут заранее предусмотреть ряд типовых и уникальных проблем, но это не гарантирует, что вся работа над проектом пройдет гладко.
Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи – Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.
1 ответ
Лучший ответ
Функциональные требования
Хорошие функциональные требования должны четко описывать поведение системы. Вот некоторые примеры:
- «Если пользователь вводит неправильный пароль 3 раза при входе в систему, учетная запись будет заблокирована на 24 часа».
- «Когда электроника добавляется в корзину, пользователю предоставляется возможность приобрести гарантию».
- «Если пользователь пытается отменить заказ после того, как он был обработан, пользователь должен указать причину отмены, которая должна быть одобрена до того, как будет оформлен возврат»
Если вы хотите добавить больше функциональности, создайте больше требований, не складывайте их все в одно целое. Например, последнее требование в приведенном выше списке можно разделить на 2: (1) требуется причина отмены, (2) утверждение до возврата. Это также помогает организовать требования по функциям в электронных таблицах (одна строка на требование) или, например, в историях JIRA.
Убедитесь, что вы прочитали много примеров хорошо написанных требований и потренировались. Следуйте контрольному списку, и пусть коллега оценит вашу работу. Всегда спрашивайте себя, как вы будете проверять каждое требование. Если вы не можете понять, как написать тест на соответствие требованиям, как вы сможете доказать, что продукт работает так, как задумано?
Нефункциональные требования
Нефункциональные требования также известны как «атрибуты качества» или «ограничения» системы. Диапазон возможных элементов, которые могут быть добавлены в корзину (0..max), кажется ограничением для этого поля, поэтому я могу понять, как некоторые сочтут это NFR. Но как бы вы это протестировали?
Вместо этого вы можете выразить это как функциональное требование: «Когда пользователь вводит значение, превышающее максимальное, вывести сообщение об ошибке». NFR может описывать цвет, размер и расположение сообщения об ошибке. В NFR также можно указать, какой набор пользовательского интерфейса использовать, и рекомендации по стилю, которым следует следовать. Например, «Должен соответствовать Google Material Design» (https://material.io).
Вы также должны быть знакомы с категориями NFR (также известными как «способности»):
- Производительность
- стабильность
- Надежность
- Масштабируемость
- Гибкость
- Юзабилити
- Тестируемость
- Прослеживаемость / возможность аудита
- Безопасность
- Соответствие / Сертификация
- Гораздо больше:
Вот несколько примеров NFR для веб-сайта:
- Производительность: «Новая учетная запись пользователя будет создана менее чем за 2000 мс»
- Надежность: «Система должна иметь доступность не менее 99,9%»
- Емкость: «Система обслуживает до 1000 одновременных пользователей»
- Масштабируемость: «Система должна быть масштабируемой по горизонтали для увеличения количества одновременных пользователей».
- Удобство использования: «Пользователи должны иметь возможность переходить на любую страницу сайта за 3 клика».
Ссылки
Прочтите эти рекомендации из Свода знаний системной инженерии (SEBoK). Внимательно следите за ними, делитесь со своей командой:
https://www.sebokwiki.org/wiki/System_Requirements#Presentation_and_Quality_of_Requirements
Это отличная книга о крупномасштабных Agile-требованиях, если вы хотите глубже:
https://www.oreilly.com/library/view/agile-software-requirements/9780321685438/
4
DV82XL
23 Фев 2021 в 23:53
Продолжая работу
Следующий шаг конкретизации требований к информации в информационных системах, структуре проекта, функциональным, внутренним особенностям – выявление противоречий и устранение конфликтов. Когда от широкого спектра третьих лиц получают сведения о работе проектируемой ИС, сталкиваются со следующей проблемой: каждый человек имеет собственные уникальные представления о возможностях проекта, его предназначении. Нередко полученные от разных лиц представления вступают в конфликт друг с другом, а также противоречат логике, имеющимся техническим возможностям, посредством которых система воплощается в жизнь. Чтобы упорядочить ситуацию, необходимо после тщательного анализа выявить все противоречия и найти оптимальное компромиссное решение для их устранения.
Выявляя противоречия и анализируя реализуемость всех требований, необходимо также составить систему приоритетов. Всегда среди общего набора требований есть более важные и менее значимые. Задача разработчиков – тесное сотрудничество с теми, кто создает требования, чтобы выявить, какие из установленных аспектов функционирования продукта самые значимые, а какие могут подождать или вовсе отмениться, если этому будут способствовать негативные внешние условия (например, нехватка времени). Создав систему приоритетов, можно приступать к проверке выявленных аспектов на полноту, сочетаемость между собой, последовательность.
Вывод
В результате сравнения ITIL и MOF мы увидели, что MOF обладает рядом существенных особенностей по сравнению со стандартом ITIL, однако если рассмотреть данные особенности, то они не носят ключевого характера: o Процессы, не включенные в ITIL, являются интуитивно понятными и принятыми в оперативной деятельности; o Модель процессов дополнена моделями команды и управления рисками, но применение данных моделей осложнено из-за слабой их детализации; o В противовес документам чисто описательного характера, свойственным ITIL, в MOF предоставлены прикладные материалы, такие как документы серий Windows Operations Guide, Exchange Operations Guide и т.д. Однако данные документы имеют привязку к определенной операционной системе и в принципе не относятся к организации процессов. Если делать вывод о применимости рассмотренных стандартов в области ИТ для оптимизации деятельности, то можно с уверенностью сказать что все они содержат «зерно истины», поэтому применение их в совокупности наиболее предпочтительно, поскольку в определенных областях они имеют новшества относительно друг друга.
В данной статье использовались материалы: MOF (Microsoft Operations Framework); ITSM HP Reference Model; ITPM (IT Process Model); COBIT (Control Objectives for Information and related Technology).
