106

UML SysML и пр. / Re: UML для эффективной эксплуатации ИС, постановки задач и понимания процессов

« : 18 Октября 2010, 10:23:58 »

Смысл UML - в диаграммах. Это не моя мысль, это из Фаулера (UML distilled). Диаграммы дают наглядное представление моделей, которого не хватает текстовому описанию. А UML предлагает их достаточно много. Поэтому все три задачи в той или иной степени UML решает, хотя формулировки, конечно. явно рекламные.

P.S. Да, я знаю, что UML создавался как язык моделирования, а диаграммы - лишь как средство отражения модели в наглядной форме. Но жизнь парадоксальна, и результат не всегда

107

Обсуждение статей / Re: Модель будущего при проектировании IT-систем

« : 18 Октября 2010, 10:12:19 »

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

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

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

108

Проектирование / Re: Можно ли вообще спроектировать и реализовать систему без архитектуры?

« : 18 Октября 2010, 09:49:02 »

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

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

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

109

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 14 Октября 2010, 22:42:44 »

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

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

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

110

Управление Проектом / Re: Дружеские отношения или жесткая корпоративная этика

« : 13 Октября 2010, 10:17:19 »

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

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

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

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

111

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 13 Октября 2010, 10:02:07 »

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

112

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 11 Октября 2010, 21:55:30 »

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

А что касается как отслеживать - по-моему всегда есть внутренние, а не внешние доки на систему. Там и написать кратко "случайно сделали такую-то фичу, в ТЗ ее нет.

113

Проектирование / Re: Постановка задачи программисту

« : 11 Октября 2010, 10:32:00 »

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

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

114

Проектирование / Re: Постановка задачи программисту

« : 08 Октября 2010, 21:30:29 »

В таком варианте - полностью согласен. Мне, кстати, тоже проще накидать диаграммы в visio, чем от руки - когда один делаю, а вот при коллективном обсуждении и проработке - наоборот, на доске проще. Так что всякий инструмент хорош к месту. А что касается форм - то я имел ввиду сложные формы, где надо располагать области и описывать взаимодействие. Тут, кстати. мне лично мне не хватает средства моделирования в котором можно было бы прикинуть форму с характерным наполнением модельными данными под разными разрешениями и размерами шрифтов, а надо бывает... Наверное, действительно можно в конечном инструменте, но слишком напоминает "модель паровоза в натуральную величину"...

115

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 19:30:07 »

1. Сопровождение "левых" фич - это в любом случае дополнительные расходы ресурсов.
2. Вопрос не в его ценности, а в рисках попасть на доп расходы по его поддержки и доработки.

Дальше я тоже читал, прежде чем ответить...

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

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

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

116

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 19:21:25 »

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

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

117

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 11:41:05 »

2 LastLegion86. Аналитики действительно работу по проектированию обычно делают лучше пользователей. Но - тут есть разные люди у заказчиков. Некоторым нравится заниматься проектированием систем, поиском решений - они отвлекаются от скучной рутины. И именно они часто становятся ответственным за проект со стороны заказчика. Ну и выдают не бизнес-прболему, а такие "полу-решения". Дальше с этим разбираешься. В нашей практике как-то так, хотя, естественно, может быть и иначе.

А в накладной (ТОРГ-12) надо печатать то, что положено по нормативам, это же официально определенная форма. Иначе придет налоговая, после чего многие окажутся без работы. Приоритет - за бухгалтерами (или директором), поскольку отвечать и проходить проверки - им. А вот Счет официально определенной формой не является. И тут бухгалтерам может быть интересно одно, чтобы сверять со своей бухгалтерией, а менеджерам - другое, чтобы видеть управленческие данные. И тут надо увеличивать число колонок. Кстати, в накладной дополнительные колонки тоже можно вводить (не запрещено), но лучше не надо - чтобы при проверках не возникало вопросов. Правда при всем этом, задача убеждения менеджеров в обоснованности идей бухгалтеров часто ложится именно на аналитика

118

Консалтинг и Внедрение / Re: Расчет эффективности

« : 08 Октября 2010, 11:30:37 »

Полностью согласен с предыдущими ораторами (Galogen, Водолей), а также Голдратом и Мартыненко.

Цели и задачи - это бизнес-задачи заказчика, которые он хочет решить за счет внедрения системы. Например, "увеличить мощность (пропускную способность) склада до X тыс. штук за сутки в течении года" (а сейчас - X/5, например). Или "обеспечить отбор по заказам 98%". Или "уменьшить среднее время ответа оператора до с 15 до 3 минут, при сохранении нынешнего уровня квалификации набираемого персонала". В общем, цели могут быть разные. И не всегда экономические. Но чтобы заказчик был доволен - достигнуть надо именно их.

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

119

Для всех / Re: Учет бланков строгой отчетности

« : 08 Октября 2010, 11:19:16 »

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

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

120

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 11:10:49 »

Резюмируя обсуждение, принципиальных вопросов, от которых зависят ваши действия два:
1) Вписался ли проект ли в сроки и бюджет? Если да, то функционал - это бонус, и в сопровождение тоже впишется.
2) Считает ли Вы дополнительный функционал настолько ценным, что отдавать без денег - жалко?
После ответа на эти вопросы действия достаточно определены, и в обсуждении варианты звучали.