50 лучших вопросов для бизнес-аналитиков

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

Звучит странно? Не за что! На высококонкурентном рынке несколько кандидатов смотрят на одну позицию, на которую вы претендуете. Ответы на вопросы бизнес-аналитиков в течение ограниченного периода времени — это единственный способ доказать свою компетентность и произвести впечатление на своего работодателя.

Следовательно, дайте себе достаточно времени, чтобы подготовиться к вопросам интервью бизнес-аналитика, с которыми вы можете столкнуться. Уровень и сложность вопросов для интервью с бизнес-аналитиками различаются в зависимости от должности, на которую вы претендуете, а также от конкретной должности в компании. Таким образом, это хорошо , чтобы сосредоточиться на конкретной области , как старший бизнес — аналитик вопросы интервью , проворные бизнес — аналитик вопросы интервью , младший бизнес — аналитик вопросы интервью , начального уровня бизнес — аналитик вопросы интервью наряду с родовыми бизнес — аналитика интервью вопросы и ответы .

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

Интервью топ-бизнес-аналитика Вопросы и ответы

Лучшие вопросы интервью бизнес-аналитика подпадают под общую категорию и могут быть заданы как часть вопросов интервью бизнес-аналитика для любых уровней карьеры.

1. Кто такой бизнес-аналитик?

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

2. Назовите некоторые документы, которые бизнес-аналитик использует для обработки?

Ответ: Ниже приведены некоторые из распространенных документов, которые бизнес-аналитик использует для обработки:

  • Проектный документ
  • Сценарии использования
  • План управления требованиями
  • Пользовательские истории
  • Матрица прослеживаемости требований (RTM)
  • Документ делового требования
  • Спецификация системных требований (SRS) / Документ системных требований (SRD)
  • Прецедент
  • Спецификация функциональных требований (FRS) / Документ функциональных спецификаций (FSD)

3. Что такое СГД и каковы его ключевые элементы?

Ответ: Спецификация системных требований (SRS) или Спецификация требований к программному обеспечению — это документ или набор документов, описывающих функции системы или программного приложения. Он включает в себя множество элементов, которые определяют предполагаемую функциональность, необходимую заинтересованным сторонам и клиентам для удовлетворения конечных пользователей.

В дополнение к этому, SRS предоставляет общее представление о системе и ее поведении, основных поддерживаемых бизнес-процессах, предположениях и ключевых параметрах производительности для системы. Ключевые элементы SRS:

  • Объем работ
  • Функциональные требования
  • Нефункциональные требования
  • зависимости
  • Модель данных
  • Предположения
  • Ограничения
  • Критерии приемки

4. Что такое требование?

Ответ. Требование — это целевое решение для достижения определенных бизнес-целей или задач. Это вход на различные этапы SDLC. Это основа проекта, который должен быть утвержден заинтересованными сторонами и бизнес-пользователями перед внедрением. Кроме того, каждое требование должно быть надлежащим образом документировано для использования в будущем.

5. Что такое вариант использования?

Ответ: Вариант использования — это схематическое представление системы, которая описывает, как пользователь использует систему для достижения цели. Это неотъемлемая часть разработки программного обеспечения и техники моделирования программного обеспечения, которая определяет целевые функции и устранение любых возможных ошибок, с которыми может столкнуться пользователь.

6. Какие шаги необходимо выполнить для разработки варианта использования?

Ответ: Шаги в разработке вариантов использования:

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

7. Что такое ползучесть области и как можно избежать ползучести области?

Ответ. Ползучесть области или ползучесть требований — это термин, который относится к неконтролируемым изменениям или отклонениям в объеме проекта в пределах одного и того же диапазона ресурсов, например, в рамках одного и того же графика и бюджета проекта. Это признак плохого управления проектом и жизнеспособного риска для проекта. Некоторые из возможных причин ползучести области:

  • Плохое общение между заинтересованными сторонами проекта
  • Неправильная документация требований проекта

Склонность к области действия может быть предотвращена:

  • Четкая документация о масштабах проекта
  • После надлежащего управления изменениями
  • Предварительное уведомление о последствиях изменений для связанных сторон
  • Надлежащая документация новых требований в журнале проекта
  • Воздержитесь от позолоты, что означает добавление дополнительных функций к существующим функциям

8. Что такое BRD? Чем он отличается от SRS?

Ответ: Документ бизнес-требований (BRD) — это официальный договор между клиентом и организацией на продукт.

Разница между BRD и SRS заключается в следующем:

                          BRD                             SRS
Это высокоуровневая функциональная спецификация программного обеспечения. Это функциональная и техническая спецификация программного обеспечения высокого уровня
Это официальный документ для описания требований, предоставленных клиентом (письменный, устный) Он описывает функциональные и нефункциональные требования программного обеспечения, которое будет разработано
Бизнес-аналитик создает его после непосредственного взаимодействия с клиентами Системный архитектор создает его, так как он нуждается в технической экспертизе. Хотя иногда Бас тоже может это создать.
Он получен на основе требований и взаимодействия с клиентом Это получено из BRS

9. Что такое анализ пробелов?

Ответ: Анализ пробелов — это метод анализа разрыва между существующей системой и функциональными возможностями и целевой системой. Здесь разрыв означает количество задач или изменений, которые могут потребоваться для получения желаемого результата. Это сравнение уровня производительности между настоящим и предлагаемым функционалом.

10. Что такое определение приоритетов? Какие методы используются для этого?

Ответ: Приоритизация требований — это процесс распределения требований на основе срочности бизнеса по различным этапам, графику, стоимости и т. Д.

Существуют различные методы, которые используются для определения приоритетов требований:

  • МОСКОВСКАЯ ТЕХНИКА
  • Метод ранжирования требований
  • 100-долларовый метод
  • Кано анализ и многое другое
  • Пять почему

Лучшие вопросы интервью бизнес-аналитика начального уровня

11. Что такое метод выявления требований?

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

12. В чем принципиальная разница между требованием и потребностью с точки зрения бизнес-анализа?

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

13. Что такое нефункциональные требования и как вы их фиксируете?

Ответ. Нефункциональные требования представляют характеристики уровня производительности, такие как скорость реагирования, плавность пользовательского интерфейса, безопасность и т. Д. Разрабатываемого приложения (AUD). Функциональные требования не отражены в документе СГД в указанном разделе.

14. Какими навыками должен обладать бизнес-аналитик?

Ответ: Мы можем широко классифицировать навыки бизнес-аналитика на три типа:

  • Фундаментальные навыки
  • Технические навыки
  • Навыки бизнес-анализа

Бизнес-аналитик должен обладать некоторыми навыками, указанными ниже:

                  Категория умений      Навыки
Фундаментальные навыки
  • Решение проблем 
  • связь
  • Управленческие навыки
  • Исследовательская работа 
Технические навыки
  • ИТ-навыки, такие как MS Office, операционные системы, языки программирования, знание базы данных, знание SDLC, знание предметной области
Навыки бизнес-анализа
  • Требование выявления
  • Документация 
  • Принятие решений
  • Креативность 
  • Аналитические навыки

15. Как вы определите требования к качеству как бизнес-аналитик?

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

16. Какие документы используются для сбора нефункциональных требований?

Ответ: Есть два документа, которые используются для фиксации нефункциональных требований:

  • SDD (системный проектный документ)
  • FRD (Документ о функциональных требованиях)

17. Что такое альтернативный поток в диаграмме вариантов использования?

Ответ: Это альтернативное решение или действие в случае использования, которое следует соблюдать в случае любого сбоя в системе.

18. Определить персонажей?

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

19. Что такое диаграмма действий и каковы ее важные элементы?

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

20. Что такое UML-моделирование?

Ответ: UML расшифровывается как Unified Modeling Language. Это стандарт, который отрасль использует для документирования, построения и визуализации различных компонентов системы. Этот стандарт моделирования в основном используется для разработки программного обеспечения. Однако он также используется для описания рабочих ролей, организационных функций и бизнес-процессов. Некоторые из важных диаграмм, которые БА используют как часть UML, представляют собой диаграмму классов, диаграммы состояний и варианты использования.

Самые популярные вопросы интервью для юных бизнес-аналитиков

21. Каковы лучшие практики, которым нужно следовать при написании варианта использования?

Ответ. Вот некоторые из лучших методов написания сценария использования:

  • Чтобы стать действительным вариантом использования, сценарий использования должен предоставить некоторую ценность обратно субъекту или заинтересованному лицу.
  • Функциональные и нефункциональные требования должны быть соответствующим образом отражены в сценарии использования.
  • Вариант использования должен иметь один или несколько альтернативных потоков наряду с основным потоком.
  • Вариант использования должен описывать только то, что делает система, а не то, как это делается, что означает, что она не будет описывать проект. Он будет действовать как черный ящик с точки зрения актера.
  • Вариант использования не должен иметь, то есть он должен быть изолированным.

22. В чем разница между потоком исключений и альтернативным потоком?

Ответ: Альтернативный поток — это альтернативные действия, которые могут выполняться отдельно для основного потока и могут рассматриваться как дополнительный поток. Поток исключений — это путь, пройденный в случае какого-либо исключения или ошибки.

23. Как вы думаете, бизнес-аналитик должен участвовать в тестировании?

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

24.  Что означает ИНВЕСТ?

Ответ: ИНВЕСТ означает —

  • независимый
  • оборотный
  • ценный
  • ценный
  • Размер соответственно
  • Тестируемые

Он может помочь менеджерам проектов и технической команде в предоставлении качественных продуктов / услуг.

25. Что такое анализ Парето?

Ответ: Анализ Парето, который также известен как правило 80/20, является техникой принятия решений. Это полезный метод для устранения дефектов и контроля качества. Согласно этому правилу анализа, 20% причин создают 80% эффектов в системе, поэтому оно называется правилом 80/20.

26.  Что такое BPMN и каковы его основные элементы?

Ответ: BPMN — это модель и нотация бизнес-процесса. Это графическое представление бизнес-процессов.

Есть пять основных элементов BPMN, и они —

  • Объекты потока
  • Данные
  • Соединение объектов
  • Swimlanes
  • Артефакты

27. Что такое анализ Кано?

Ответ: Kano Analysis используется для анализа системы относительно ее требований, чтобы определить ее влияние на удовлетворенность клиентов.

28. Какие типы актеров вы знаете по схеме вариантов использования?

Ответ: в сценарии использования могут быть изображены в основном актеры двух типов:

  • Главные действующие лица — начинается процесс
  • Вторичные актеры — это помогает первому актеру

Более того, мы можем разделить актеров на четыре типа:

  • Человек
  • система
  • аппаратные средства
  • таймер

29. С какими типами разрыва может столкнуться бизнес-аналитик во время анализа разрыва?

Ответ: в основном есть четыре типа пробелов —

  • Разрыв в производительности — разница между ожидаемой и фактической производительностью
  • Продукт / Рынок Gap — разрыв между бюджетом продажами и фактическими продажами называют как продукт / ниша на рынке
  • Profit Gap — Разница между целевой и фактической прибылью компании.
  • Разрыв в рабочей силе — разрыв между необходимым количеством и качеством рабочей силы и фактической силой в организации

30. Что такое бенчмаркинг?

Ответ: Бенчмаркинг — это измерение эффективности организации, которая конкурирует в отрасли. В этом процессе компания может измерять свою политику, результаты деятельности, правила и другие меры.

Самые популярные вопросы интервью старшего бизнес-аналитика

31. Как вы решаете, что как бизнес-аналитик вы собрали все требования?

Ответ: Мы можем сделать вывод, что все требования собраны только тогда, когда —

  • Это подтверждено и одобрено бизнес-пользователями.
  • Требования соответствующим образом соответствуют бизнес-требованиям проекта.
  • Требования могут быть реализованы с использованием доступных ресурсов.
  • Все ключевые деловые заинтересованные стороны приведены в соответствие с выявленными требованиями.

32. Как вы выполняете сбор требований?

Ответ: Процесс сбора требований обычно делится на несколько этапов, которые не зависят от цикла SDLC. Каждый шаг включает в себя:

  • конкретные задачи для выполнения
  • принципы, которым нужно следовать
  • документы для производства

Шаги следующие:

Шаг 1: Сбор исходной информации — это может включать сбор исходной информации о проекте, анализ любого потенциального риска, связанного с проектом. Для этой цели могут быть использованы такие методы, как анализ PESTLE, схема пяти сил Портера.

Шаг 2: Определите заинтересованные стороны — они принимают решения по проекту и утверждают требования и приоритеты. Заинтересованные стороны могут варьироваться от владельцев проектов до старших менеджеров, конечных пользователей и даже конкурентов.

Шаг 3: Откройте для себя бизнес-цели — это понять бизнес-потребности проекта, прежде чем углубляться в проект. SWOT-анализ, сравнительный анализ, анализ бизнес-целей SMART и перечисление бизнес-целей — вот некоторые из методов, используемых для этой цели.

Шаг 4: Оценить варианты — это определить варианты для достижения бизнес-целей. Анализ воздействия, анализ риска, анализ затрат и выгод являются одними из методов, которые используются для этой цели.

Шаг 5: Определение области действия — область действия — это цель развития проекта, которая устанавливается на основе бизнес-целей. Документ определения области используется для детализации целей для каждого этапа проекта.

Шаг 6: План доставки бизнес-аналитика — на основе объема проекта, доступности заинтересованных сторон и методологии проекта на этом этапе создается документ, называемый бизнес-аналитиком. Документ предоставляет информацию о результатах с их графиком.

Шаг 7. Определение требований проекта. На этом этапе используются два типа документов: документ функционального требования и документ нефункционального требования. Основываясь на методологии разработки, которая будет использоваться в проекте, бизнес-аналитик должен прояснить требования с заинтересованными сторонами, опросив их о требованиях и подписав их.

Шаг 8: Поддержка внедрения через SDLC. Это технический шаг внедрения требований, когда бизнес-аналитик взаимодействует с различными командами. Это включает в себя координацию с командой разработчиков и группой тестирования, чтобы гарантировать, что требования реализованы, как и ожидалось, и соответствующим образом протестированы для всех возможных бизнес-сценариев. Они также должны обработать запрос на изменение, который может возникнуть у заинтересованных сторон на более позднем этапе.

Шаг 9: Оценить добавленную стоимость проекта — это постоянная оценка проекта, чтобы оценить, правильно ли реализация бизнес-целей соответствует результатам и срокам бизнес-потребностей.

33. Почему бизнес-аналитику необходимо вовлекаться в процесс выполнения требований?

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

34. С какими проблемами может столкнуться бизнес-аналитик?

Ответ: От инициации до пост-реализации проекта бизнес-аналитик может столкнуться со следующими проблемами:

  • Вопросы, связанные с сотрудниками
  • Проблемы, связанные с технологией
  • Доступ связан
  • Вопросы, связанные с деловой политикой
  • Ошибки бизнес-модели

35. Объясните требование стратегии выявления?

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

  • мозговая атака
  • Интервью
  • наблюдение
  • Фокус-группы анализа документов
  • Требования Семинары
  • Анализ интерфейса
  • Опрос или вопросник
  • макетирования

36. Что такое анализ бизнес-модели?

Ответ: Анализ бизнес-модели — это метод анализа жизнеспособности и ценности бизнеса с точки зрения социальных, экономических и других аспектов. Анализ бизнес-модели обеспечивает основу для любых необходимых изменений бизнес-модели и инноваций для организации.

37. Считаете ли вы, что роль бизнес-аналитика необходима для проекта?

Ответ: Да, потому что роль бизнес-аналитика чрезвычайно выгодна с момента начала реализации проекта. Вот 5 главных причин:

  • Во время стартовой сессии проекта есть большие возможности, что некоторые технические вопросы поступают от заинтересованных сторон и клиентов. Поскольку мы не привлекаем техническую команду проекта на этом этапе, и немедленный ответ крайне важен, бизнес-аналитик может сыграть ключевую роль в ответе на эти запросы.
  • Следующий этап после начального сеанса включает в себя анализ пробелов, анализ бизнес-процессов, документирование, анализ SOW, планирование проекта и, конечно же, подготовку документации спецификации требований.
  • На этапе разработки и тестирования бизнес-аналитик может сыграть важную роль в решении любых связанных с требованиями запросов проектных групп. Кроме того, он может проверить, правильно ли выполнены и протестированы требования с учетом различных функциональных и нефункциональных сценариев.
  • В модели с водопадом у заинтересованного лица может быть запрошено новое требование или изменение требований с учетом меняющихся потребностей бизнеса. В этом случае бизнес-аналитик — это лицо, которое может обработать этот запрос на изменение с надлежащей проверкой и анализом.

38. В чем разница между бизнес-анализом и бизнес-аналитикой?

Ответ . Ключевое различие между бизнес-анализом и бизнес-аналитикой заключается в том, что первое связано с большим количеством функций и процессов, а второе — с данными.

Бизнес-анализ — признает потребности бизнеса и определяет пути решения этих проблем. Инструменты и методы, такие как SWOT, PESTEL, CATWOE, MOST, FIVE WHY и т. Д., Используются для бизнес-анализа.

Бизнес-аналитика — обрабатывает данные и анализирует данные, чтобы получить представление о бизнесе. Наконец, он генерирует отчеты. В основном используются четыре типа бизнес-аналитики, а именно: описательная аналитика, решающая аналитика, предписывающая аналитика и прогнозная аналитика Для этой цели используются такие инструменты и технологии, как большие данные, BI.

39.  Что такое процесс проектирования?

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

40.  Каковы эффективные навыки для решения любой проблемы в качестве бизнес-аналитика? Ответ:

  • Лидерский навык
  • Отличный навык общения
  • Навык анализа проблем
  • Технические знания
  • Базовые знания

Последние вопросы интервью Agile бизнес-аналитик

41. Что такое Agile Manifesto?

Ответ: Agile Manifesto — это руководство по программному обеспечению о принципах Agile-разработки, которые обеспечивают итеративные решения.

42. Каковы основные качества Agile BA?

Ответ: Agile BA должен уметь:

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

43.  Когда вы должны использовать модель водопада вместо Scrum?

Ответ: Если требование простое и конкретное, мы должны использовать модель водопада вместо Scrum.

44. Каковы четыре ключевых этапа развития бизнеса?

Ответ: четыре ключевых этапа развития бизнеса:

  • формирование
  • Storming
  • Нормирование
  • Выполнение

45.  Что ты знаешь о Канбан?

Ответ: Kanban — это инструмент, который помогает гибкой команде визуально направлять и управлять работой по мере ее прохождения. Кроме того, он работает как система планирования в Agile-производстве точно в срок. Доска Канбан используется для описания текущего состояния разработки.

46. ​​Упоминание о некоторых из самых важных гибких метрик

Ответ: Ниже приведены некоторые важные гибкие матрицы.

  • Скорость — используется для отслеживания хода выполнения проекта.
  • Матрица спринта — это помогает отследить работу, проделанную со спринтом.
  • Приоритет работы
  • Распределение категорий работ. Этот показатель помогает получить представление о приоритете распределения работ и категорий работ.
  • Диаграмма накопленного потока — равномерный поток работы можно проверить с помощью этой диаграммы совокупного потока. Здесь ось X представляет время, а ось Y обозначает количество усилий.
  • Осведомленность об удалении дефектов — это помогает производить качественную продукцию.
  • Ценность доставленного бизнеса — используется для оценки эффективности работы команды. Он связывает 100 точек для измерения.
  • Временной охват — оценивает время, затраченное на кодирование во время тестирования. Это отношение количества строк кода, вызываемых набором тестов, к числу относительных строк кода.
  • Время устранения дефекта — это время обработки для обнаружения и исправления ошибок. Там процессы, участвующие в этом для:
    • исправление ошибок
    • устранение ошибки
    • Планирование исправления
    • Фиксация дефектов
    • Передача отчета о резолюции

47. Объясните термин «приращение»?

Ответ. Инкремент относится к сумме всех элементов журнала невыполненных работ, выполненных в спринте. Новое значение приращения также включает приращение предыдущих спринтов.

48. Каковы различные типы гибких методологий?

Ответ: Некоторые из известных гибких методологий:

  • Scrum
  • Бережливая разработка программного обеспечения и экстремальное программирование (XP)
  • Функционально-ориентированная разработка (FDD)
  • Методология кристаллов
  • DSDM (метод динамической разработки программного обеспечения)

49. Есть ли разница между инкрементальной и итеративной разработкой?

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

50. Разница между экстремальным программированием и схваткой?

Ответ: Scrum и экстремальное программирование следуют итерациям, которые известны как спринты. Однако спринты в Scrum-процессе длятся от двух недель до одного месяца, тогда как в команде экстремального программирования (XP) итерация длится одну или две недели. Экстремальное программирование более гибкое, чем Scrum, так как Scrum не допускает никаких изменений во время итераций.

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

Список 10 лучших инструментов бизнес-анализа

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

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

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

Почему бизнес-аналитикам нужны лучшие инструменты бизнес-анализа для анализа?

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

  1. Отслеживать требования
  2. Управлять требованиями
  3. Подробно описать требования
  4. Диаграмма бизнес-процесса — моделировать требования там, где это возможно, в виде диаграммы, например диаграммы бизнес-процесса
  5. Сотрудничать с командами и заинтересованными сторонами

Типы инструментов бизнес-анализа

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

  1. Инструменты, связанные с требованиями, т.е. для описания, управления и отслеживания требований
  2. Инструменты моделирования
  3. Инструменты для совместной работы

Категория 1:  Какова цель инструментов бизнес-анализа, связанных с требованиями?

В общем, Microsoft Word или Microsoft Excel можно использовать для управления требованиями, например, для отслеживания требований и описания этих требований. Однако эти инструменты не всегда эффективны, и специализированное программное обеспечение для управления требованиями помогает управлять всей работой с помощью этих инструментов.

Ниже приведены причины, по которым бизнес-аналитик должен использовать инструменты, связанные с требованиями.

  • Чтобы запомнить меняющиеся требования 

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

  • Синхронизироваться с командой разработчиков

Лучшие инструменты бизнес-анализа имеют возможность автоматически уведомлять об изменениях требований. Следовательно, если бизнес-аналитик изменяет требования с помощью инструмента, команда разработчиков получает уведомление, не взаимодействуя с людьми. Это помогает предотвратить переработку кода и потерю усилий.

  • Скоординироваться с командой QA

Помимо команды разработчиков, для команды тестирования также важно быть в курсе измененных требований. Большинство функциональных тестов основаны на требованиях. Следовательно, если требования изменяются, тестировщики должны немедленно изменить сценарии тестирования, чтобы соответствовать новым требованиям.

  • Определить лучшие требования к проекту

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

  • Чтобы управлять отношениями один-ко-многим

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

Категория 2:  Как инструменты моделирования помогают в схематических представлениях?

Наглядное представление более эффективно, чем слова. Следовательно, описание бизнес-процесса и его функциональные отношения между различными функциональными компонентами выглядят более правильно, когда представлены на диаграмме. Более того, это снижает вероятность неправильных толкований.

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

Категория 3:  Как инструменты совместной работы участвуют в процессе бизнес-анализа?

Работа бизнес-аналитика — это не настольная работа. Кроме того, он должен сотрудничать с различными заинтересованными сторонами и бизнесом, чтобы выполнять свой долг. Не говоря уже о том, что это действительно важная задача.

Следовательно, инструменты сотрудничества играют важную роль, поскольку не всегда все заинтересованные стороны или МСП становятся доступными для обсуждения, и проекты должны следовать строгим срокам. Таким образом, сегодня многие инструменты для совместной работы, такие как Skype, входят в число лучших инструментов бизнес-анализа.

10 лучших инструментов бизнес-анализа, которые должен знать каждый бизнес-аналитик

1. Microsoft Office Suite

Следующие приложения пакета Microsoft Office входят в список лучших инструментов бизнес-анализа:

MS PowerPoint

Это программное обеспечение используется для подготовки и проведения официальных презентаций. Бизнес-аналитик часто сталкивается с ситуациями, когда ему необходимо поделиться идеями, обосновать или предоставить обновления проекта заинтересованным сторонам. Это общение становится более эффективным в форме презентации через PowerPoint.

MS Excel

Анализ данных также является частью бизнес-анализа, и он может иметь различные формы, такие как

    • Сводные таблицы
    • Изучение тенденций в данных
    • Сортировать и фильтровать данные
    • Создание диаграмм или графиков

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

MS Word

Microsoft Word служит для целей спецификации документа. Организации могут создавать свои конкретные шаблоны для документирования требований. Это служебное приложение, которое позволяет предпочитаемым пользователем шрифты, темы, объекты, фигуры, художественные объекты, диаграммы и даже возможность встраивания диаграмм Visio.

MS Visio

MS Visio — это инструмент моделирования, который бизнес-аналитики используют для эффективного сбора и представления идей заинтересованных сторон в форме бизнес-функций и взаимодействия с пользователями. Основные утилиты Visio —

  • Создание UML-диаграмм, таких как сценарии использования, диаграммы последовательности и действия.
  • Подготовить технологические схемы
  • Для создания моделей данных
  • Для создания диаграмм архитектуры

2. Документы Google

Совместное использование документов проекта осуществляется в рамках сотрудничества, и в настоящее время документы Google зарекомендовали себя как очень полезный инструмент для обмена документами в Интернете с участниками проекта и заинтересованными сторонами. Документы Google поддерживают все типы файлов, такие как .pdf, .txt, .docx и т. Д.

3. Rational Requisite Pro

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

4. Бальзамик

Многие проекты требуют каркасных приложений для демонстрации макетов предлагаемой системы. Как правило, каркасное внимание уделяется 

  • содержание
  • Взаимодействие с пользователем

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

Функции:

  • Представляет макеты с использованием PDF вместе со встроенными ссылками
  • Создает повторно используемые библиотеки компонентов и шаблоны
  • Обеспечивает быстрый и интуитивно понятный пользовательский интерфейс
  • Позволяет строить каркасы
  • Ссылки позволяют пользователю получить доступ к прототипам для демонстрации и юзабилити-тестирования
  • Обширная библиотека для готовых элементов управления
  • Обеспечивает достаточное количество пользовательских элементов управления и значков

5. SWOT

SWOT-анализ широко используется для стратегического анализа и оценки бизнеса.

Функции:

  • Инструмент бесплатный в использовании и наиболее безопасный инструмент.
  • Это позволяет бизнес-аналитику загружать и сохранять результаты анализа в локальных файлах XML.
  • Можно экспортировать и просматривать файлы .png

6. Карандаш

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

Карандаш — это такой инструмент для создания прототипов, который поставляется как самостоятельный инструмент, который можно загрузить и использовать локально. С простым интерфейсом, он позволяет пользователю перетаскивать элементы для создания экрана.

7. Трелло

Trello — это инструмент для совместной работы по бизнес-анализу, который помогает сотрудничать, общаться между командами и безопасно обмениваться информацией. Наряду с этим, это позволяет администратору анализировать бизнес-данные.

Функции:

  • Обеспечивает безопасное сотрудничество с командой
  • Позволяет просматривать командную активность через доски
  • Позволяет включать участников из аккаунта Google Apps
  • Связывать и организовывать доски с коллекциями
  • Назначает администраторов для управления настройками конфиденциальности
  • Помогает дезактивировать старых участников вместе с сохранением истории их работы
  • Экспорт данных в один клик

8. SmartDraw

Бизнес-аналитики часто используют SmartDraw как инструмент бизнес-аналитики, чтобы упростить свою работу по управлению проектами.

Функции:

  • Это помогает автоматизировать такие действия, как — добавить, переместить или удалить фигуры
  • Вы можете интегрировать его с такими инструментами, как Microsoft Office, Google Drive, Dropbox и OneDrive. Плагины SmartDraw Cloud могут повысить функциональность.
  • Это помогает поддерживать безопасность, так как вы можете установить его за брандмауэром
  • Он поддерживает 100 языков для создания диаграмм

9. Врайк

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

Функции:

  • Обеспечивает основные строительные блоки работы
  • Вы можете запросить формы и   автоматизацию
  • Это позволяет редактировать в реальном времени и управлять файлами
  • Предоставляет визуальную временную шкалу для просмотра расписания проекта
  • Обеспечивает представление рабочей нагрузки для балансировки ресурсов с отслеживанием производительности
  • Отчетность проекта
  • Отслеживание времени для планирования и управления бюджетом

10. Версия One Lifecycle

Это один из лучших инструментов бизнес-анализа в отношении его уникальной возможности интеграции с корпоративными приложениями и инструментами разработки программного обеспечения с открытым исходным кодом.

Функции:

  • Это в первую очередь связано с гибкой разработкой программного обеспечения
  • Гибкость, позволяющая легко масштабировать рабочие места проектов, портфели в разных группах и местах
  • Возможно встроенное редактирование и немедленное обновление атрибутов пользователями.
  • Это позволяет расширенному анализу принимать обоснованное решение
  • Он предоставляет специальную функцию, такую ​​как проектирование Agile Data Mart
  • Автоматизировать принятие решений в течение жизненного цикла программного обеспечения
Функционально-ориентированная (иерархическая) организация

Системный анализ деятельности организации. Виды организаций в ARIS

Системный анализ деятельности организации. Виды организаций в ARIS

Понятие организации

Международный стандарт ИСО 9000:2000 определяет организацию как группу работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений.
Организация может быть корпоративной, государственной или частной. Можно дать и другое определение: организация — это систематизированное, сознательное объединение действий людей, преследующих достижение конкретных целей.
Понятие «организация» раскрывает приведенная на рисунке модель технических терминов ARIS (Architecture of Integrated Information Systems — архитектура интегрированных информационных систем).

Рисунок «Виды организаций, представленные с помощью модели технических терминов ARIS»
Виды организаций, представленные с помощью модели технических терминов ARIS

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

С точки зрения управления главными заинтересованными сторонами являются:

  • заказчики и конечные пользователи;
  • сотрудники организации;
  • собственники и/или инвесторы;
  • поставщики и партнеры;
  • общество, интересы которого представляют органы местного управления, и население, оказывающее влияние на организацию.

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

Любая организация — многофункциональна. К ее основным функциям относятся:

  • маркетинг и анализ рынка;
  • стратегическое планирование деятельности предприятия;
  • стратегическое и оперативное управление;
  • планирование и разработка бизнес-процессов;
  • проектирование и разработка продукции;
  • производство продукции;
  • поставка продукции;
  • закупки материалов и комплектующих;
  • техническое обслуживание и ремонт оборудования и прочие функции;
  • оформление финансовых документов;
  • подготовка кадров и управление персоналом.

Для выполнения этих функций организация должна быть соответствующим образом структурирована.

Функционально-ориентированная (иерархическая) организация

Функционально-ориентированные организации остаются неизменными и характеризуются вертикальной топологией структуры и иерархией отношений между подразделениями (см. рисунок).

Рисунок «Функционально-ориентированная (иерархическая) организация»
Функционально-ориентированная (иерархическая) организация

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

Функционально-ориентированные организации обладают рядом недостатков, основными из которых являются:

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

Альтернативой строго функциональной структуре является процессно-ориентированная структура.

Процессно-ориентированная организация

Понятие «процесс» — ключевое в современной теории управления бизнесом.
Международный стандарт ИСО 9000:2000 определяет процесс как совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы и выходы (см. рисунок). Процесс включает одну или более связанных между собой процедур или функций, которые совместно реализуют некую задачу бизнеса — обычно в рамках организационной структуры. Он может выполняться в пределах одной организационной единицы, охватывать несколько единиц или даже несколько различных организаций, например, в системе «покупатель-поставщик».
Процесс обычно связан с операционными отношениями, например, процесс разработки нового изделия или процесс продаж. Введем некоторые термины, взаимосвязь которых представлена на рисунке (ниже).
Различают основные и вспомогательные процессы.

  • Основные процессы — это те процессы, которые добавляют новое качество продукции.
  • Вспомогательные процессы формируют инфраструктуру организации.
  • Владелец процесса — лицо (или группа лиц), отвечающее за процесс и имеющее полномочия изменять его с целью усовершенствования.
  • Границы процесса — граница входа и граница выхода. Граница входа предшествует первой операции процесса, граница выхода следует за его последней операцией.
  • Интерфейс процесса — механизм (организационный, информационный, технический), посредством которого процесс взаимодействует с предшествующим и последующим процессами.

В соответствии с новым взглядом на организацию работа должна быть организована вокруг процессов. По словам Хаммера и Чампи, «не товары, а процессы их создания приносят компаниям долгосрочный успех». Целью организации должно быть совершенствование бизнес-процессов для преодоления их фрагментарности и для достижения существенных улучшений в ключевых показателях результативности — затраты, качество, уровень обслуживания и оперативность.
Несмотря на явные преимущества процессно-ориентированного устройства компании, — добиться создания такой структуры в чистом виде не представляется возможным.
Первым шагом проекта по оптимизации деятельности должно стать выделение основных продуктов компании и выстраивание процессов в соответствии с продуктовыми линиями. Это позволяет получить продуктовые «срезы» бизнес-процессов, протекающих в организации.

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

Рисунок «Понятие «процесс», представленное с помощью модели технических терминов ARIS»
Понятие «процесс», представленное с помощью модели технических терминов ARIS

Понятие системы

Любая организация является сложной социально-технической системой. Термин «система», употребляемый в современной практике, имеет множество значений и смысловых нюансов. Это приводит к необходимости выделить те значения, которые имеют непосредственное отношение к системному анализу деятельности организации. Далее приведены три определения, которые представляются наиболее удачными.
Первое из них дано в Международном стандарте ИСО 9000:2000 «Системы менеджмента качества. Основные положения и словарь».

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

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

Для системы характерны следующие основные свойства:

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

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

Понятие «границы» в целом ряде случаев весьма условно, и при моделировании необходимо четко определить, где кончается система, а где начинается среда.

Между средой и бизнес-системой, которой является организация (см. рисунок), существует множество взаимных связей, с помощью которых реализуется процесс взаимодействия среды и системы.
По входной и выходной связям между системой и средой путем взаимной передачи происходит обмен материальными, финансовыми, энергетическими, информационными и иными элементами.
Элементы, передаваемые системой во внешнюю среду, будем называть конечными продуктами деятельности системы, а передаваемые из среды в систему — ресурсами.

Рисунок «Связи системы-организации с внешней средой»
Связи системы-организации с внешней средой

Цель системы — достижение и сохранение желаемого состояния или желаемого результата поведения системы.
Цель организации — стремление к максимальному результату, выражаемому в максимизации ценности капитала, при постоянном сохранении определенного уровня ликвидности и достижении целей производства и сбыта с учетом социальных задач. Вспомогательной стоимостной целью является стремление к оптимальной расчетной прибыли за период.
Задача системы — описание способа (технологии) достижения цели, содержащее указание на цель с желаемыми конкретными числовыми (в том числе временными) характеристиками.

Система целей — совокупность взаимоувязанных целей. В соответствии с определением понятия «система» для одного и того же объекта может быть рассмотрено несколько систем целей, т.е. использовано несколько оснований для их классификации, например:

  • стратегические и тактические цели;
  • долгосрочные (выполнение через несколько лет) и краткосрочные (выполнение через год и ранее) цели;
  • производственные, финансовые, социальные цели, цели повышения качества продукции и т.п.

Древовидная система целей (см. рисунок) включает как минимум глобальную цель — существование организации и две главные цели — цель функционирования (выпускать продукцию) и цель развития (развиваться).

Рисунок «Цели организации, представленные в виде диаграммы целей ARIS»
Цели организации, представленные в виде диаграммы целей ARIS

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

Системный подход

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

Методологическая специфика системного подхода определяется тем, что он ориентирует исследование на:

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

Системный подход реализует представление сложного объекта в виде иерархической системы взаимосвязанных моделей, позволяющих фиксировать целостные свойства объекта, его структуру и динамику.
Методология ARIS основана на применении системного подхода в полной мере.
Системный анализ — совокупность методологических средств, используемых для подготовки и обоснования решений по сложным проблемам социального, технического и экономического характера. Он основывается на системном подходе, а также на ряде математических дисциплин и современных методов управления. Основной процедурой системного анализа является построение обобщенной модели, адекватно отображающей интересующие исследователя свойства реальной системы и ее взаимосвязи.

Главной задачей системного анализа является поиск путей по превращению сложного в простое, по разложению труднопонимаемой задачи на ряд задач, имеющих решение.

Принципы системного анализа:

  • Оптимальность. В результате анализа необходимо найти оптимальное решение задачи.
  • Эмерджентность. Этот принцип предполагает следующее важное свойство системы: чем больше система и чем больше различие между частью и целым, тем выше вероятность того, что свойства целого могут сильно отличаться от свойств его частей.

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

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

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

Системный подход применяется для решения различного рода сложных задач, в число которых входят:

  • совершенствование системы управления организации и анализ ее деятельности;
  • подготовка к внедрению системы управления предприятием;
  • внедрение систем менеджмента качества и их сертификация;
  • оптимизация, инжиниринг и реинжиниринг бизнес-процессов;
  • внедрение информационных систем на предприятии;
  • документирование корпоративных знаний, в том числе в виде моделей прототипов.
Актуальность данных и аналитических исследований. Что такое аналитика? Виды анализа

Актуальность данных и аналитических исследований. Что такое аналитика? Виды анализа

Актуальность данных и аналитических исследований. Что такое аналитика? Виды анализа

Рост объема информации характерен почти для каждой сферы общественной деятельности. Если вы занимаетесь спортом, то наверняка знаете о бейсбольной статистике Moneyball и революции в профессиональном бейсболе, которую позволил совершить анализ данных об эффективности действий отдельных игроков. Сейчас такая статистика внедрена практически во всех популярных видах спорта. Если вы увлекаетесь сетевыми компьютерными играми, то наверняка знаете, что разнообразные сведения о вашем игровом поведении накапливают и анализируют компании Zynga и Electronic Arts. Любите кино? Возможно, слышали о методике, применяемой компанией Netflix для прогнозирования предпочтений в области кино. Может быть, вы не знаете, что некоторые голливудские киностудии (например, Relativity Media) используют похожие методики, принимая решение о том, какие кинопроекты финансировать.

Continue reading

Заявление о видении компании - Аналитическая культура

Заявление о видении компании — Аналитическая культура

Это приложение может стать стартовой точкой для формирования заявления о видении – мотивирующего описания того, чего компания стремится достичь в среднесрочной и долгосрочной перспективах, чтобы стать более ориентированной на данные. Суть в том, чтобы выделить цель компании, объединить всех участвующих лиц и стимулировать обсуждение того, как добиться целей компании. Каждая компания индивидуальна, скорректируйте этот документ так, чтобы он отражал видение вашей компании.

В процветающей компании с управлением на основе данных [название компании] присутствует следующее.
Заявление о видении компании - Аналитическая культура
Continue reading

навыки аналитика

Навыки и качества хорошего аналитика

Какие качества определяют хорошего аналитика?

Аналитический склад ума

Он не обязательно должен иметь научную степень по математике или статистике, но его не должна пугать, по крайней мере, описательная статистика (медиана, мода, квартиль и так далее), и он должен быть готов обучаться.
Continue reading

Что нужно знать и уметь бизнес-аналитику?

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

1. Бизнес-аналитик в сфере ИТ

Бизнес-аналитик — это разносторонний специалист, который должен уметь:

  • коммуницировать с различными заинтересованными сторонами (это может быть топ-менеджмент компании, либо мидл-менеджмент)
  • коммуницировать с бизнес-пользователями
  • коммуницировать с членами команды (разработчики, аналитики, менеджеры проектов)
  • использовать различные инструменты для систематизации требований (именно инструменты — почти всегда Excel)
  • знать и уметь предвидеть какие требования нужны для каждого конкретного проекта и кому задавать вопросы
  • уметь правильно формулировать вопросы и «выковыривать» информацию из людей (это очень сложный процесс, особенно когда начинается скрытое сопротивление)
  • проводить интервью по выявлению требований
  • понимать «политику игры» различных заинтересованных сторон и влияние этого процесса на исход проекта
  • видеть влиятельных людей и уметь убеждать их
  • уметь исключать мешающих членов рабочей группы из проекта (того, кто постоянно тратит время команды, либо уводит проект не в ту сторону, желательно перевести на другую деятельность внутри компании и обращаться только за отдельными консультациями)
  • уметь четко формулировать тезисы, делать четкие выводы
  • уметь проводить воркшопы для уточнения требований
  • уметь проводить общие конструктивные собрания (цель собрания, проблема, возможные решения должны описываться до собрания, чтобы исключить лишние бла-бла-бла)
  • понимать принципы построения систем, уметь трансформировать цели проекта в бизнес-требования, а бизнес-требования в функциональные и нефункциональные требования (т.е. трассировка должна быть в таком порядке)
  • быть способным генерировать новые решения
  • знать sql, принципы построения моделей данных, бизнес-процессов
  • знать и уметь использовать визуальные инструменты для представления информации

Советы по оформлению любой документации

1. Всегда пишите документацию для непосвященных людей в концепцию и внутреннее содержание системы, поэтому:

  • Включайте в документацию вводную часть о системе (либо ссылку на документ, который описывает систему)
  • Включайте в документацию список сокрещений
  • Если используются узкоспециализированная терминология — добавьте словарь в документ, либо создайте отдельный документ и приложите ссылку на него
  • Стремитесь сопровождать большие участки текста схемами, где показывается взаимодействие различных компонентов системы
  • После написания инструкций или документации, представьте себя человеком, который ранее не работал с данной системой и прочитать инструкцию/документацию. Если что-то непонятно — перепишете/дополните

2. Как документировать скрипты системы:

  • В документе должно находиться общее концептуальное описание последовательности запусков тех или иных скриптов
  • Можно представить карту вызова скриптов из компонентов системы, можно сделать некую «карту» по скриптам (mindmap)
  • Сами скрипты в документе описывать не надо. Скрипты должны быть самодокументируемыми, т.е. в коде должны быть комментарии, которые заполняются разработчиками (в том числе для разъяснения бизнес-смысла скрипта)

3. Всегда стремитесь к балансу между картинками и текстом. Отсутствие или избыток картинок — не самые лучшие варианты оформления документации

Отношения с подчиненными

  • Неважно какую должность Вы занимаете и сколько опыта у Вас — уважайте своих подчиненных, обсуждайте трудности, нехватку знаний или проблемы в работе. Не обвиняйте их, иначе при любой возможности они свалят от Вас (именно свалят и не будут даже думать о возникших резко у Вас трудностях при потере специалиста).
  • Ставьте задачи правильно и корректно
  • Обсуждайте с подчиненным всегда заранее о необходимости задержаться на работе — помните, что у подчиненных есть личная жизнь и свободное время, которое они не обязаны тратить на работодателя (либо Вы будете всегда работать с не очень выдающимися специалистами, т.к. хорошие сотрудники при случае свалят 😉 )
  • Многое другое можно найти в опубликованных материалах стратоплан.ру (участвовал в их конференциях и семинарах — и Вам советую)

Как устроиться работать бизнес-аналитиком

1. Открываем HeadHunter;
2. Находим 20 вакансий по бизнес-анализу;
3. Выписываем из них главные пункты, которых ожидают от бизнес-аналитиков;
4. Составляем список 7 наиболее важных (общих для всех вакансий), которыми Вы не владеете;
5. Изучаем быстро за неделю;
6. Идем на собеседование (получаем обратную связь);
7. Учим дальше;
8. Повторяем цикл пунктов 6-7-6-7-… до тех пор, пока не устроитесь;
9. Сначала идите на совеседование в те компании, устроиться в которые Вы не хотите (чтобы не потерять шанс устроиться в хорошие компании при плохом исходе собеседования).

Воркшоп (Workshop). План и пример воркшопа

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

План воркшопа «Приложение с аналитикой по магазинам — GCI»

Цели и границы

Цели воркшопа:

  1. Ознакомиться более подробно с приложением GCI.
  2. Понять, какие возможности использования имеются у приложения.
  3. Выявить дополнительные требования, которые не удовлетворены этим приложением. Другими словами понять объем и направление необходимых доработок.

Границы:

  1. Целью воркшопа является верхнеуровневые требования к аналитике, т.е. без погружения в формулы KPI.
  2. Какие KPI подходят, какие KPI нужны, какой уровень детализации данных нужен в приложении.
  3. Приложения содержат ограниченный набор исторических данных (1 день, по нескольким магазинам), т.к. слабый сервер.

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

Продолжительность:3 часа

Целевая аудитория: Аналитики отдела снабжения и закупок

Состав воркшопа

Этап 1 «Общая вводная по приложениям GRI и GCI»

Общий этап для двух воркшопов по приложениям GRI и GCI.

Описание результатов и дополнительных требований (см. План воркшопа по GRI).

Этап 2 «Обзор приложения GСI и выявление дополнительных требований»

Предполагаемая продолжительность 3 часа
Цели 1. Получить подробное представление о возможностях приложения GCI;
2. Выявить дополнительные требования к приложению;
3. Оценить достаточность детализации данных;
4. Оценить группировку данных;
5. Оценить достаточность данных для аналитики по магазинам.
Подпункты этапа ——————————————————————————————-
· Шаг 1 Обзор видов анализа в приложении GСI
· Шаг 2 Обзор дашборда приложения GCI (панель с группами KPI)
· Шаг 3 Обзор видов анализа для каждой группы KPI
· Шаг 4 Обсуждение табличного и графического представления данных
· Шаг 5 Обзор показателей в графическом и табличном представлении данных
· Шаг 6 Выявление дополнительных требований:
· Количество пользователей
· Дополнительные KPI
· Интеграция с другими источниками данных (помимо GOLD)
· Требования к скорости доработки приложений
· Требования по ограничению видимости данных разным пользователям
· Требования к объему данных

Описание результатов и дополнительных требований:

Оценка приложения

Приложение GCI оценивается каждым участником в отдельности и затем считается общий балл.

Складская аналитика в приложении GCI 1 = Плохо

5 = Отлично

Участник воркшопа:
1 Глубина детализирования данных для складской аналитики
2 Достаточность показателей KPI
3 Достаточность исторических данных
4 Возможность использования приложения GCI без дополнительных доработок
5 Удобство интерфейса для анализа
6 Общее впечатление от приложения GCI
7 Удовлетворенность параметрами перезагрузки данных (1 раз в сутки, ночью)
ИТОГОВАЯ ОЦЕНКА (сумма/количество):
Дополнительные комментарии:

Скачать План воркшопа по GCI.docx

Пояснение принципа прослеживания требований

Сбор и анализ требований

Сбор и анализ требований

Первые 90% работы отнимают
10% времени, а последние 10%
— оставшиеся 90% времени.
Правило 90/90

Все требования к проектируемой системе предлагается размещать на нескольких иерархических уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для автоматизации технологических процессов в целом без учета особенностей конкретной прикладной области. Здесь необходимо обратиться к ГОСТам и другим нормативным документам. Далее следует уровень требований к автоматизированной системе определенного (заданного) класса с учетом соответствующих нормативных документов, определяющих порядок и описание заданного технологического процесса. И наконец, третий уровень составляют требования к конкретной системе. Кроме того, в стандарте IEEE 830-1993 Спецификация требований к ПО (Software Requirements Specification – SRS) проведено деление всех требований на две группы. Первая группа документирует потребности заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. Вторая группа документирует требования в специальной, структурированной форме. Этот документ называют требованиями разработчика, или D-требованиями.

В ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» перечислены общесистемные принципы, которые необходимо соблюдать при создании АСОИУ:

  1. системность – заключается в том, что при создании, функционировании и развитии АСУ должны быть установлены и сохранены связи между структурными элементами, обеспечивающие ее целостность;
  2. развитие – заключается в том, что АСУ должна создаваться с учетом возможности пополнения и обновления функций и видов ее обеспечения путем доработки программных и (или) технических средств или настройкой имеющихся средств;
  3. совместимость – заключается в обеспечении способности взаимодействия АСУ различных видов и уровней в процессе их совместного функционирования;
  4. стандартизация и унификация – заключается в рациональном применении типовых, унифицированных и стандартизованных элементов при создании и развитии АСУ;
  5. эффективность – заключается в достижении рационального соотношения между затратами на создание АСУ и целевыми эффектами, получаемыми при ее функционировании.

Кроме того, в п.3.4. ГОСТ 24.103-84 при создании АСУ рекомендуется максимально использовать типовые проектные решения, пакеты прикладных программ, унифицированные пакеты а также применять для новых объектов управления ранее созданные проекты АСУ. Это положение полностью соответствует принципам инженерии ПО, в особенности, концепции повторного использования компонентов.
ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» устанавливает требования к каждому виду обеспечения отдельно. Перечислим те из них, на которые нужно обратить внимание.

Требования к программному обеспечению:

  1. В АСУ должны быть преимущественно использованы системы управления базами данных (СУБД), зарегистрированные в установленном порядке.
  2. Программное обеспечения АСУ должно иметь средства диагностики технических средств АСУ и контроля на достоверность входной информации.
  3. В программном обеспечении АСУ должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций АСУ.

Требования к информационному обеспечения АСУ

  1. Форма представления выходной информации АСУ должна быть согласована с заказчиком (пользователем) системы.
  2. В АСУ должны быть предусмотрены необходимые меры по контролю и обновлению данных в информационных массивах АСУ, восстановлению массивов после отказа каких-либо технических средств АСУ, а также контролю идентичности одноименной информации в базах данных.

Требования безопасности

  1. Неправильные действия персонала АСУ не должны приводить к аварийной ситуации.

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

Кроме сбора требований особое значение имеет процесс управления требованиями. В технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

  1. требования записаны в согласованном формате;
  2. требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;
  3. требования структурированы в соответствии со своими типами (функциональными и нефункциональными);
  4. требования отслеживаются в соответствии с их типом;
  5. требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

Чтобы соответствовать первому уровню, достаточно взять стандартный текстовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие модели в жизненном цикле ПО.

Хорошую спецификацию отличают следующие элементы:

  1. Акцент на деталях и их четкое определение.
  2. Забота о недопущении неверного толкования.
  3. Непротиворечивость внутри данной спецификации и другими спеками.
  4. Логическая взаимосвязь компонентов.
  5. Полнота охвата предмета.
  6. Соответствие нормативным актам.
  7. Соответствие деловой практике.

С-Требования

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

Перед проведением интервью:

  • перечислить и расставить приоритеты в списке интервьюированных;
  • спланировать интервью с фиксированным временем начала и конца;
  • составить глоссарий проекта, в котором перечисляются основные термины предметной области.

Во время интервью:

  • задокументировать требования;
  • составить эскиз графического интерфейса;
  • спланировать следующую встречу.

После интервью:

  • составить черновик С-требований SRS с использованием CASE-инструментов;
  • определить конфигурацию оборудования;
  • передать черновик С-требований заказчику для получения его замечаний.

Рисунок – Порядок составления С-требований
Порядок составления С-требований

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

  • Методология SADT;
  • Диаграммы вариантов использования (use case) UML.
  • Диаграммы последовательности (sequence diagram) UML.
  • Диаграммы состояний (statechart diagram) UML.
  • Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы формирования требований.

Порядок анализа требований заказчика включает следующие шаги:
1. Если требование простое и не имеет связей с другими требованиями, его выражают четкими предложениями в соответствующем разделе SRS.
2. Если требование представляет собой взаимодействие пользователя и приложения, то его, как правило, выражают с помощью варианта использования. Для этого:
2.1. Задают имена вариантам использования;
2.2. Определяют действующие лица;
2.3. Записывают последовательность действий пользователя и приложения;
2.4. Минимизируют ветвление.
3. Если требование затрагивает элементы обработки, каждый из которых получает и выдает данные, используют диаграмму потоков данных (DFD). При этом:
3.1. Определяют элементы обработки (обычно высокого уровня);
3.2. Определяют хранилища данных;
3.3. Показывают пути передачи данных между обрабатывающими элементами. Указывают типы данных, передаваемых в каждом случае.
4. Если требование затрагивает состояния, в которых может находиться программа (или части программы), строят диаграмму состояний в следующей последовательности:
4.1. Определяют состояния (каждое состояние обычно определяют отглагольным существительным, например «Ожидание»);
4.2. Указывают исходное и конечное состояние.
4.3. Определяют события, происходящие вне рассматриваемой части системы, и приводящие к переходу между состояниями;
4.4. Определяют вложенные состояния.

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

D-Требования

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

Рисунок – Порядок получения D-требований
Порядок получения D-требований

Существуют несколько типов D-требований:
1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
2. Нефункциональные требования.
2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д.
2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.
2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой.
2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением.
2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч.
3. Обратные требования – это функционал, который система не обеспечивает.

 

Типичная последовательность получения функциональных D-требований с использованием объектно-ориентированного подхода приведена ниже:

1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа.
2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области.
3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования.
4. Связи между классами определяются в два этапа:
4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации.
4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы.
5. D-требования проверяются и сравниваются с С-требованиями.
6. D-требования проверяются заказчиком и, затем, публикуются.

Особое внимание необходимо уделить вопросу получения классов анализа, поскольку – это творческий процесс, тесно связанный с анализом информации о предметной области.

При получении классов анализа необходимо учитывать следующие аспекты:

  1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами.
  2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта.
  3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области.
  4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов.
  5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.

Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием.
Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»:

  1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования;
  2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей;
  3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»;
  4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования;
  5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования.

Рисунок – Пояснение принципа прослеживания
Пояснение принципа прослеживания требований

На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями.
Во-первых, это позволяет прояснить требование.
Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы .

Таблица «Тестовые данные для проверки D-требования №nnn»

№ п/п Входные тестовые данные Ожидаемый результат
1 Иванов Иван Иванович Иванов Иван Иванович
2 length()<10 Сообщение с вопросом о корректности вводимых данных
3 length()>256 Сообщение с вопросом о корректности вводимых данных
4

При формировании требований к АСОИУ необходимо обеспечить достижение ряда показателей, среди которых наиболее значимыми являются: прослеживание, полнота, согласованность и т.д. Набор D-требований согласован, если между требованиями нет противоречий. По мере увеличения числа D-требований согласованность может стать труднодостижимой, но объектно-ориентированная организация требований помогает избежать несогласованности благодаря классификации D-требований по классам и с помощью разложения их на простейшие составляющие.
С целью проверки указанных характеристик составляют таблицу, форма которой приведена на рисунке:

Рисунок «Шаблон таблицы для проверки D-требований»
Шаблон таблицы для проверки D-требований

Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д.

В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода.

Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги:

  1. Предварительный анализ требования:
    1. Классификация требования как функциональное или нефункциональное (рекомендуется использовать подсказки IEEE SRS для большинства нефункциональных требований);
    2. выбор метода организации функциональных требований.
  2. Обеспечение прослеживания требования. Убедиться в возможности прослеживания при проектировании и реализации.
  3. Обеспечение тестируемости требования. Спланировать конкретный тест, устанавливающий выполнение требования.
  4. Проверка недвусмысленности требования.
  5. Назначение требованию приоритет. Например, высокий («важно»), средний («желательно») или низкий («не обязательно»).
  6. Проверка полноты требования. Для каждого требования следует убедиться в присутствии всех остальных необходимых или сопутствующих требований.
  7. Добавление состояния ошибки:
    1. сформулировать, что требуется выполнить при возникновении нештатных ситуаций;
    2. в критичных местах добавить состояния ошибок программирования.
  8. Проверка согласованности. Необходимо убедиться, что ни одно требование не противоречит каким-либо аспектам другого требования.

Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования под управление конфигурациями.
Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993.

ТРИЗ (Теория решения изобретательских задач)

ТРИЗ — Теория решения изобретательских задач

Что такое ТРИЗ?

Теория решения изобретательских задач, или ТРИЗ — область знаний о механизмах развития технических систем и методах решения изобретательских задач. ТРИЗ не является строгой научной теорией, а представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники. В результате своего развития ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).
[youtube]https://youtu.be/4yv8RR0uWFY[/youtube]

  1. Перевыставить задачу (найти суть задачи)
  2. Выставление эталона
    • Подбор примеров (как это уже сделано?)
    • Как бы задача была решена если бы была волшебная палочка?
    • Как решить задачу ничего не делая?
  3. Преодоление технического противоречия

Структура и функции ТРИЗ

Цель ТРИЗ — выявление и использование законов, закономерностей и тенденций развития технических систем.

Основные функции ТРИЗ

  • Решение творческих и изобретательских задач любой сложности и направленности без перебора вариантов.
  • Прогнозирование развития технических систем (ТС) и получение перспективных решений (в том числе и принципиально новых).
  • Развитие качеств творческой личности.

Вспомогательные функции ТРИЗ

  • Решение научных и исследовательских задач.
  • Выявление проблем, трудностей и задач при работе с техническими системами и при их развитии.
  • Выявление причин брака и аварийных ситуаций.
  • Максимально эффективное использование ресурсов природы и техники для решения многих проблем.
  • Объективная оценка решений.
  • Систематизирование знаний любых областей деятельности, позволяющее значительно эффективнее использовать эти знания и на принципиально новой основе развивать конкретные науки.
  • Развитие творческого воображения и мышления.
  • Развитие творческих коллективов.

Структура ТРИЗ

  • Законы развития технических систем (ТС)
  • Информационный фонд ТРИЗ
  • Вепольный анализ (структурный вещественно-полевой анализ) технических систем
  • Алгоритм решения изобретательских задач — АРИЗ
  • Методы развития творческого воображения

Список приемов устранения технических противоречий

1. Принцип дробления:
а) разделить объект на независимые части;
б) выполнить объект разборным;
в) увеличить степень дробления объекта.

2. Принцип вынесения:
отделить от объекта “мешающую” часть (“мешающее” свойство) или, наоборот, выделить единственно нужную часть (нужное свойство).

3. Принцип местного качества:
а) перейти от однородной структуры объекта (или внешней среды, внешнего воздействия) к неоднородной;
б) разные части объекта должны иметь (выполнять) различные функции;
в) каждая часть объекта должна находиться в условиях, наиболее благоприятных для ее работы.

4. Принцип асимметрии:
а) перейти от симметричной формы объекта к асимметричной;
б) если объект асимметричен, увеличить степень асимметрии.

5. Принцип объединения:
а) соединить однородные или предназначенные для смежных операций объекты;
б) объединить во времени однородные или смежные операции.

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

7. Принцип “матрешки”:
а) один объект размещен внутри другого, который, в свою очередь, находится внутри третьего и т. д.;
б) один объект проходит сквозь полости в другом объекте.

8. Принцип антивеса:
а) компенсировать вес объекта соединением с другим, обладающим подъемной силой;
б) компенсировать вес объекта взаимодействием со средой (за счет аэро- и гидродинамических сил).

9. Принцип предварительного антидействия:
а) заранее придать объекту напряжения, противоположные недопустимым или нежелательным рабочим напряжениям;
б) если по условиям задачи необходимо совершить какое-то действие, надо заранее совершить антидействие.

10. Принцип предварительного действия:
а) заранее выполнить требуемое действие (полностью или хотя бы частично);
б) заранее расставить объекты так, чтобы они могли вступить в действие без затраты времени на доставку и с наиболее удобного места.

11. Принцип “заранее подложенной подушки”:
компенсировать относительно невысокую надежность объекта заранее подготовленными аварийными средствами.

12. Принцип эквипотенциальности:
изменить условия работы так, чтобы не приходилось поднимать или опускать объект.

13. Принцип “наоборот”:
а) вместо действия, диктуемого условиями задачи, осуществить обратное действие;
б) сделать движущуюся часть объекта или внешней среды неподвижной, а неподвижную — движущейся;
в) перевернуть объект “вверх ногами”, вывернуть его.

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

15. Принцип динамичности:
а) характеристики объекта (или внешней среды) должны меняться так, чтобы быть оптимальными на каждом этапе работы;
б) разделить объект на части, способные перемещаться относительно друг друга;
в) если объект в целом неподвижен, сделать его подвижным, перемещающимся.

16. Принцип частичного или избыточного действия:
если трудно получить 100% требуемого эффекта, надо получить “чуть меньше” или “чуть больше” — задача при этом существенно упростится.

17. Принцип перехода в другое измерение:
а) трудности, связанные с движением (или размещением) объекта по линии, устраняются, если объект приобретает возможность перемещаться в двух измерениях (т. е. на плоскости). Соответственно задачи, связанные с движением (или размещением) объектов в одной плоскости, устраняются при переходе к пространству в трех измерениях;
б) использовать многоэтажную компоновку объектов вместо одноэтажной;
в) наклонить объект или положить его “на бок”;
г) использовать обратную сторону данной площади;
д) использовать оптические потоки, падающие на соседнюю площадь или обратную сторону имеющейся площади.

18. Принцип использования механических колебаний:
а) привести объект в колебательное движение;
б) если такое движение уже совершается, увеличить его частоту (вплоть до ультразвуковой);
в) использовать резонансную частоту;
г) применить вместо механических вибраторов пьезовибраторы;
д) использовать ультразвуковые колебания в сочетании с электромагнитными полями.

19. Принцип периодического действия:
а) перейти от непрерывного действия к периодическому (импульсному) ;
б) если действие уже осуществляется периодически, изменить периодичность;
в) использовать паузы между импульсами для другого действия.

20. Принцип непрерывности полезного действия:
а) вести работу непрерывно (все части объекта должны все время работать с полной нагрузкой);
б) устранить холостые и промежуточные ходы.

21. Принцип проскока:
вести процесс или отдельные его этапы (например, вредные или опасные) на большой скорости.

22. Принцип “обратить вред в пользу”:
а) использовать вредные факторы (в частности, вредное воздействие среды) для получения положительного эффекта;
б) устранить вредный фактор за счет сложения с другими вредными факторами;
в) усилить вредный фактор до такой степени, чтобы он перестал быть вредным.

23. Принцип обратной связи:
а) ввести обратную связь;
б) если обратная связь есть, изменить ее.

24. Принцип “посредника”:
а) использовать промежуточный объект, переносящий или передающий действие;
б) на время присоединить к объекту другой (легкоудаляемый) объект.

25. Принцип самообслуживания:
а) объект должен сам себя обслуживать, выполняя вспомогательные и ремонтные операции;
б) использовать отходы (энергии, вещества).

26. Принцип копирования:
а) вместо недоступного, сложного, дорогостоящего, неудобного или хрупкого объекта использовать его упрощенные и дешевые копии;
б) заменить объект или систему объектов их оптическими копиями (изображениями). Использовать при этом изменение масштаба (увеличить или уменьшить копии);
в) если используются видимые оптические копии, перейти к копиям инфракрасным и ультрафиолетовым.

27. Принцип дешевой недолговечности взамен долговечности:
заменить дорогой объект набором дешевых объектов, поступившись при этом некоторыми качествами (например, долговечностью).

28. Принцип замены механической схемы:
а) заменить механическую схему оптической, акустической или “запаховой”;
б) использовать электрические, магнитные и электромагнитные поля для взаимодействия с объектом;
в) перейти от неподвижных полей к движущимся, от фиксированных — к меняющимся во времени, от неструктурных — к имеющим определенную структуру;
г) использовать поля в сочетании с ферромагнитными частицами.

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

30. Принцип использования гибких оболочек и тонких пленок:
а) вместо обычных конструкций использовать гибкие оболочки и тонкие пленки;
б) изолировать объект от внешней среды с помощью гибких оболочек и тонких пленок.

31. Принцип применения пористых материалов:
а) выполнить объект пористым или использовать дополнительные пористые элементы (вставки, покрытия и т. д.);
б) если объект уже выполнен пористым, предварительно заполнить поры каким-то веществом.

32. Принцип изменения окраски:
а) изменить окраску объекта или внешней среды;
б) изменить степень прозрачности объекта или внешний среды.

33. Принцип однородности:
объекты, взаимодействующие с данным объектом, должны быть сделаны из того же материала (или близкого ему по свойствам).

34. Принцип отброса и регенерации частей:
а) выполнившая свое назначение или ставшая ненужной часть объекта должна быть отброшена (растворена, испарена и т. д.) или видоизменена непосредственно в ходе работы;
б) расходуемые части объекта должны быть восстановлены непосредственно в ходе работы.

35. Принцип изменения физико-химических параметров объекта:
а) изменить агрегатное состояние объекта;
б) изменить концентрацию или консистенцию;
в) изменить степень гибкости;
г) изменить температуру.

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

37. Принцип применения теплового расширения:
а) использовать тепловое расширение (или сжатие) материалов;
б) использовать несколько материалов с разными коэффициентами теплового расширения.

38. Принцип применения сильных окислителей:
а) заменить обычный воздух обогащенным;
б) заменить обогащенный воздух кислородом;
в) воздействовать на воздух и кислород ионизирующим излучением;
г) использовать озонированный кислород;
д) заменить озонированный кислород (или ионизированный) озоном.

39. Принцип применения инертной среды:
а) заменить обычную среду инертной;
б) вести процесс в вакууме.

40. Принцип применения композиционных материалов:
перейти от однородных материалов к композиционным.

Использование ТРИЗ в IT-технологиях

ТРИЗ начинает активно использоваться в IT-технологиях, особенно используются такие инструменты ТРИЗ, как «устранение технических противоречий», понятие «идеальной системы» и «идеальной программы». ТРИЗ критериями качественной разработки являются увеличение функциональности при одновременном сокращении программного кода; возможность сопровождения разработанной программы специалистом с меньшей квалификации, чем ее разработчик.