В докладе представлены основные положения, которые касаются работы с требованиями при создании программного обеспечения бортовой радиоэлектронной аппаратуры с учетом использования стандарта RTCA DO-178C (Software Considerations in Airborne Systems and Equipment Certification), фактически являющегося основным руководящим документом при создании программного обеспечения различных уровней критичности, разрабатываемого для бортовой аппаратуры.

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

• DO-333 Formal Methods Supplement to DO-178C and DO-278A
• DO-331 Model-Based Development and Verification Supplement to DO-178C and DO-278A

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

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

Наш случай был такой же. Около 2 месяцев ушло на выявление требований к системе Билинга по учету оплаты за содержание лабораторных животных. Это миллионный оборот клеток, десятки комнат, сотни полок и тарифов, учет особого питания и ежедневный подсчет наличия клеток на конкретном месте; поддержка 8 видов потоков, интеграция с 3 финансовыми системами. И простая задача – сдать проект генерации счетов через 2 месяца, что допускало только один прогон на реальных данных для проверки правильности наших расчетов.

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

Как обеспечить юридическую значимость при работе по схеме "Заявка- документ-выгрузка"? 

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

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

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

Возможные варианты реализации в зависимости от бизнес-потребностей и требований заказчика

• В чем ценность диагностики бизнес-процессов?
• Как «Управленческий баланс» и «Отчет о прибылях и убытках» могут диагностировать процессы компании?
• Почему онлайн, и что это означает практически?
• Почему нельзя использовать бухгалтерские отчеты?
• Как сформировать структуру финансовых отчетов не имея финансовых знаний?
• Как получить список непрозрачных процессов чужими руками?
• В чем универсальность подхода? Новая компетенция бизнес-аналитиков.

• Как найти индивидуальный подход к каждому сотруднику в компании, чтобы повысить его эффективность?
• Как определить людей, с которыми компании лучше расстаться?
• Кто те профессионалы, на которых всегда можно положиться?

Добрый день.

Есть желание поделиться опытом использования Sсrum на базе Jira 6. Расскажу как настроить плагин, проведу обзор основных возможностей и покажу слайды с примерами.

Тезисно план доклада:

1. Как создать первый «дашборд»?

2. Основные параметры настройки «дашборда» (добавление цветовых индикаторов, быстрых фильтров).

3. Планирование с использованием плагина. Версии и спринты.

4. Реализация и мониторинг работ.

5. Закрытие спринта. Ретроспектива и отчеты.

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

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

Приведу как пример несколько форматов описания бизнес-процесса, форматов документов, которые являются исходными для описания и моделирования бизнес-процесса, и документов, которые описывают сам бизнес-процесс.

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

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

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

Несколько лет назад мне по наследству от старой команды достался волшебный пакет ГОСТовых ТЗ на продуктовые решения компании (общим объемом порядка 2000 листов). Вся пикантность ситуации состояла еще и в том, что документы эти читались заказчиками довольно часто и превратили мои рабочие дни в день сурка (много проектов -> много разных заказчиков -> много слёз). 

Когда закончилось терпение и появилось немного времени, я решила расправиться со своим наследством, покончить с ГОСТ и поработать над документом с точки зрения User Experience. Об основных приемах визуализации и восприятия, которые могут быть использованы при написании ТЗ, я и расскажу в своем докладе. 

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

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

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