СИСТЕМЫ И АНАЛИЗ
Записки о проектировании информационных систем - на основе моих работ и лучших мировых практик. Для аналитиков, системных инженеров, разработчиков и менеджеров ИТ
Общие вопросы системной инженерии
Системный и бизнес-анализ - это про интеллектуальный труд над системами, тем, что ими действительно является. Мы НЕ работаем с тем, что НЕ система - не состоит из связанных объектов и существует бесцельно
Подробнее
Суть нашей работы - документировать жизненный цикл ИТ-решений. Артефакты - результаты такого документирования
Подробнее
Стандарты не ограничивают инновации - наоборот, они призваны помогать сообществам профессионалов работать вместе, накапливать и использовать опыт разработки и внедрения ИТ ко всеобщему благу
Подробнее
Результаты сотрудничества специалистов разных стран и организаций помогут усилить компетенции, предложат эффективные инструменты и свежий взгляд на привычную работу
Подробнее
Как извне, так и в самой АИС на протяжении её жизненного цикла возникают и действуют разные факторы, определяющие границы автоматизации. Их называют требованиями к системе
Подробнее
Важно, чтобы программист мог взять постановку и понять, какие данные и как обрабатывать, чтобы выдать результат на экран, и в каком сценарии эта обработка нужна пользователю
Подробнее
Мифотворчество, разумеется, характерно для всего, что за гранью реальности, и поскольку ИТ работают с виртуальными сущностями, мы с вами где-то возле Олимпа профессиональных легенд
Подробнее
АИС, как и любая система, существует во множестве измерений: ресурсы для обработки, инфраструктура, данные, алгоритмы, целевые показатели, пользователи - и, конечно, время
Подробнее
Мы начинаем с анализа требований, формулируем границы проекта, строим функциональные модели, описываем схемы и потоки данных, включая интеграцию, участвуем в разработке архитектуры и т. д.
Подробнее
С чего начать хотя бы просто думать в сторону модели некой реальной картины мира, когда, к примеру, раньше работал в финтехе, а теперь надо переключиться на незнакомую сферу производства?
Подробнее
Мы говорим об одних и тех же запросах стейкхолдеров, однако эти модели отрабатывают их с различных позиций и используются на разных стадиях проектирования
Подробнее
Слышу такой вопрос всё чаще, и на собеседованиях, и от младших коллег. Кажется, ответ прост - он есть в ГОСТ Р 59793, но...
Подробнее
Цифровые инструменты нужно использовать не молотком по пальцам, а от слова "польза"
Подробнее
Бизнес-модель описывает существующие схемы и правила выполнения тех или иных рабочих процессов, а также может включать рекомендации по их изменению. Что это даёт?
Подробнее
Вопрос, казалось бы, вполне прозаический, однако далеко не праздный, а ответ не очевиден. Главное - не форма артефакта, а его содержание и, следовательно, польза для проекта
Подробнее
В графической модели, как и в любой схеме, следует стремиться к лаконичности по смыслу - и по форме, и не множить сущности без необходимости. Но что значит такой минимализм?
Подробнее
Реинжинирингу нужны смыслы - ради чего мы меняемся и куда идём. Их называют критериями (мерой) оптимизации
Подробнее
Анализ - один из фундаментальных методов научного познания и мировоззрения, рассматривающий систему как множество составляющих или некий объект как часть системы со всеми их проявленными свойствами
Подробнее
Проектная документация
Мы хотим принимать правильные решения. Обоснованность выводов не гарантирует верность, но является необходимым условием мудрого выбора. Поэтому нужна полезная информация, которой мы можем доверять
Подробнее
Советую вначале сосредоточиться на трёх вопросах - что, кому и зачем вы собираетесь предложить
Подробнее
Документ по шаблону из ГОСТа - или не все так просто?
Подробнее
Технико-экономическое обоснование (ТЭО) - важная и во многих случаях даже обязательная часть документации ИТ-проекта, включая ТЗ по ГОСТ 34.602.
Подробнее
Графика говорит на языке абстракций, минуя посредников - прежде всего, текст: такую информацию гораздо легче воспринимать
Подробнее
Программная документация - по ГОСТ 34.201 и как правило - разрабатывается на стадиях эскизного и/или техно-рабочего проектов
Подробнее
Терминология должна быть единообразной во всех артефактах проекта, в соответствии с законодательством, ГОСТами и отраслевыми нормами
Подробнее
Оба артефакта создаются по мере работы со стейкхолдерами и отражают их требования. В целом они обрисовывают границы проекта со стороны внешнего окружения системы
Подробнее
Что делать, когда начальство такое: "тыжаналитик" - вот иди и напиши нам аналитическую справку, надо для шефа / министру / на сайт / акционерам?
Подробнее
Чтобы программисты смогли понять, какое требование и как должно быть закодировано так, что входящие данные обрабатываются в исходящие с нужным результатом.
Подробнее
Оно должно отражать ожидания целевых пользователей от возможностей системы в части человеко-машинного взаимодействия
Подробнее
Как сделать нестыдное описание программного продукта
Подробнее
в описании сценария использования или бизнес-процесса
Подробнее
Способ проверить, насколько правильно сформулированы требования к показателям функционирования системы (минимальным показателям назначения)
Подробнее
Оценка эффективности ИТ
Каждый заказчик ожидает, что расходы на автоматизацию позволят, как минимум, сократить издержки, а в идеале - увеличить доходы, то есть будут эффективны
Подробнее
Есть ощущение, что разговоры о недостаточной или сомнительной эффективности ИТ - от неумения её посчитать
Подробнее
Хорошо и плохо - совсем не бихевиористские понятия, это вполне живые квалиметрические величины, которыми оперирует сознание заказчика
Подробнее
Трудозатраты часто измеряют в человеко-часах - величина показывает, сколько времени в среднем необходимо middle-специалисту для выполнения всего объёма работ
Подробнее
Предлагаю подробнее рассмотреть критерии и шкалу оценки для результативности ИТ-проектов - одного из 3 параметров их системной эффективности
Подробнее
Управление ИТ-проектами
Подробнее
Заинтересованные стороны, или стейкхолдеры, в проекте автоматизации - это любые люди, организации или институты, кто пользуется его результатами и может на них влиять.
Подробнее
Оценка рисков и меры предотвращения приводятся в отчете об обследовании заказчика, ТЭО или пояснительной записке к техно-рабочему проекту
Подробнее