Рассмотрим принципы современной организации процесса разработки, в большей степени присущие современным гибким (Agile) методологиям, чем «водопаду» (Waterfall).

Возможно, при этом будет определенный акцент на критике, но не стоит на ней зацикливаться. Скорее, это сравнительный обзор: каждый из подходов имеет свои плюсы и минусы.
Данный пост является продолжением предыдущих публикаций (часть 1, часть 2).

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

1. Аналитики создают модель предметной области в своих терминах, разработчики программируют ее в своих (в той или иной парадигме программирования).
Нужно, чтобы кто-то «наводил мосты» между первыми и вторыми.

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

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

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

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

К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:

Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:

• класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
• класс/таблицу вида «Список машин»;
• класс/таблицу вида «Машина».

Далее с помощью механизмов ООП и реляционной модели «подсущности» связываются между собой.

Причем термины «сущность» и «подсущность» применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины «метасущность» и «сущность» соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.

А далее следуют ожидаемые проблемы:

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

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

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