Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
376
и вообще можно с калашниковым (из первой ссылки связаться) и многое узнать

377
Цитата: tomman
Нет у меня ни одного знакомого товарища с ТЭЦ или ГРЭС, где вся эта байда работает

не в обиду, но один ищет способ, а другой - причины :о))) позвоните в ТГК, какой поближе и спросите у их айтишников, не знают ли они чего про такую штуку.


Цитата: tomman
А позиция - системный аналитик, не могу сказать, что если я скажу свое "фи" - от системы откажутся, но уверена, что аргументированный ответ позволит сделать нужные выводы и принять нужное решение.

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


378
вспомнился анекдот про автоматическую парикмахерскую - "это только в первый раз головы у всех разные"

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

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

380
это какая-такая система Компас? знаю про САПР. яндеск выдает кучу систем с таким названием.
нашел ссылку http://m-kalashnikov.livejournal.com/189364.html, там внутри есть еще ссылки.

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

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

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


381
Цитата: Galogen
формализация часто важна даже не во взаимоотношении заказчика и разработчика, а порой гораздо важнее внутри организации заказчика.

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

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


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

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

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

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

понятно?

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

386
не знаю уж в какой мере мой опыт является best practice, да и не отношу я себя к великим... хотя..... :о)))

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

на ваши вопросы однозначных ответов сейчас дать нельзя, т.к. ситуации описаны довольно абстрактно, поэтом возможно и так и эдак решать в каждом конкретном случае, например:
1. если Х относится к ядру, но не используется в других проектах (т.е. один частный случай), то "ядерщики" могут взять на себя либо делегировать реализацию проектной группе с последующим контролем качества и интеграцией с основным продуктом
если используется в проектах, то ответственность на "ядерщиках"
если от частного случая переход к обширной практике, то "ядерщики" должны взять себе соответствующую фичу, забрав ее у соответствующей проектной группы. при этом должен контролироваться стандарт документирования.
в общем я бы назвал это "схемой, похожей на осьминога" :о)))
2. однозначно, что взаимозависимости должны контролироваться "ядерной" группой управления, т.к. одна проектная группа может ничего не знать о содержании работ другой п/г (хотя может и знать). при большом количестве проектов за счет этого достигается значительная экономия на ресурсах п/г, занимающихся перекрестной поддержкой друг друга. от этого нужно уходить вплоть до создание специальной централизованной группы при значительном росте количества проектов.
3. на уровне ТЗ для заказчика неважно, как и где будет реализовываться фича Z*, поэтому, не зная деталей, я бы предложил разделить ответственность: за Z отвечает "группа ядра", за довесок и за Z* в целом перед заказчиком - п/г

при желании подробности можно обсудить в личке.

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

P.S. Могу посоветовать заглянуть в книжку Фатрелла (Фатрелл, Шафер, Шафер Управление программными проектами). К тому же есть опыт разработки и поддержки платформ (у той же 1С - в свое время про это много писалось, как сейчас не в курсе)

387
2 Михаил Курбасов: Вам нужно решение "как организационно управлять требованиями" или "какие технические/программные средства использовать"?

388
Цитировать
Цитировать
сразу вопрос навскидку: это бизнес-процесс или технологический процесс?
А что есть технологический процесс? Наверное, если рассматриваемый процесс - только раскрутка автомобиля отвёрткой бригадой работников, то наверное, это технологический процесс.

ну, а какой еще-то?
из Википедии
Цитировать
Технологический процесс, сокр. техпроцесс — последовательность технологических операций, необходимых для выполнения определенного вида работ. Технологические процессы состоят из технологических (рабочих) операций, которые, в свою очередь, складываются из рабочих движений (приёмов). В зависимости от применения в производственном процессе для решения одной и той же задачи различных приёмов и оборудования различают типы техпроцессов.
Технологический процесс, согласно ГОСТ 3.1109-82, это «часть производственного процесса, содержащая целенаправленные действия по изменению и (или) определению состояния предмета труда.»

вооооот, а теперь возвращаясь к основной теме топика, что здесь было бы объектом автоматизации?

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »