196

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

« : 22 Марта 2011, 13:05:40 »

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

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

С меня требуют описание ситуаций, например, а что будет если то то, а как система должна себя вести в случае если...
А откуда мне узнать как система должна себя вести? Откуда мне знать что будет если то то?? Самому придумать из воздуха?

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

Может быть что-то нужно проанализировать?

это все и называется "проанализировать"...

197

Управление Проектом / Re: Особенности работы с госзаказчиками

« : 22 Марта 2011, 12:59:49 »

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

198

Обсуждение статей / Re: Как померить «айтишника»

« : 21 Марта 2011, 16:37:37 »

да бред какой-то, а не статья. IMHO означенный в статье "авторитет" из не менее авторитетной компании как обычно не в теме. Пока такие, с позволения сказать, "айтишники" будут подменять удовлетворенность сервисом измерением удовлетворенности ServiceDesk'ом, да еще применяя "нестандартные шкалы", дело с места не сдвинется. При этом естественно ничего не сказано о цели измерений.

в качестве альтернативы рекомендую почитать ГОРАЗДО более полезную статью и обсуждение по следующей ссылке http://www.globalcio.ru/workshops/25/ IMHO это как минимум позиционирует в правильном направлении, в отличие от напускающей тумана исходной

199

Задачи студентов / Re: комплексный пример проектирования

« : 04 Марта 2011, 12:40:38 »

если Вы замените свой термин "изменить настройку" на другой, например: "задать тарифы на коммунальные услуги", то возможно найдете общий язык с господином Galogen'ом

P.S. по крайней мере аппарат ИВЛ не будет мерять напряжение в сети.

200

Примеры / Re: Задание на автоматизацию АЗС. Нужна помощь экспертов.

« : 28 Февраля 2011, 16:59:37 »

"бесконтактную заправку" или "бесконтактные (т.е. безналичные) расчеты"? для первого (если не считать заправку в другом месте) одного процесса мало будет :о))) а второе не спасет от недолива/перелива.

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

P.S. с участниками у Вас тоже есть определенные некорректности. в принципе они могли бы вывести Вас на "слабое звено"

201

Примеры / Re: Задание на автоматизацию АЗС. Нужна помощь экспертов.

« : 28 Февраля 2011, 16:47:45 »

дык надо эта... семь раз отмерить, а потом один раз отрезать, и переделывать ничего не придётся

202

Примеры / Re: Задание на автоматизацию АЗС. Нужна помощь экспертов.

« : 28 Февраля 2011, 16:32:28 »

а по какому принципу Вы одни прецеденты связали друг с другом, а другие нет? например: "купить товар" и "произвести оплату" связаны, а "продажа топлива" и "произвести оплату" нет.
и почему одни прецеденты "include", а другой "extend"?

203

Примеры / Re: Задание на автоматизацию АЗС. Нужна помощь экспертов.

« : 28 Февраля 2011, 16:02:38 »

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

204

Примеры / картинка в тему

« : 28 Февраля 2011, 14:01:55 »

практически ребус :о)))

205

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

« : 25 Февраля 2011, 16:57:32 »

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

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

206

ПО Аналитика / Re: "Исполнение" бизнес-процессов - это кому-нибудь нужно?

« : 25 Февраля 2011, 16:38:04 »

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

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

207

Работа / Re: 2,5 года

« : 23 Февраля 2011, 12:53:48 »

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

:о)))

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

208

Работа / Re: Собеседование в крок, ланит.

« : 22 Февраля 2011, 23:20:48 »

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

209

Системный Анализ и Требования / Re: Вопросы по некоторым пунктам ТЗ (ГОСТ 34.602-89)

« : 21 Февраля 2011, 10:26:42 »

2 Водолей:
Предприятие частное, российское.
...
Это фриланс - просто заказ на написание ТЗ, поэтому владею не всей информацией.

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

таки Вы хотите, чтобы заказчик организовывал комиссию? А у него существует подобная практика? Имеется в наличии компетентный персонал? или всё сведется к формальному "назначению" всё тех же лиц: гл.бухгалтер МарьИванна, завхоз СидорСтепаныч, замдир по общ.вопросам АристархПавлыч и т.п.? О каком масштабе системы идет речь: локальный участок для трех пользователей или всекомпанейская ERP?
Ищите заинтересованных людей, из числа тех, с кем обсуждаете требования, тех, кого они упоминают, тех, кого затронет будущая система, тех из всех них, кто реально заинтересован в системе и не боится ответственности. с такими и обсуждайте имеющиеся правила на тему приемки и ее формализации.
Если это "впервые в истории", то не надо сильно накручивать схему приемки и избыточный формализм порождать. Основа приемки - прохождение определенных тестов. В зависимости от предметной области, содержания и масштаба системы (а Вы это должны понимать, т.к. ТЗ у Вас в руках) нужно разобраться как будут проводиться тесты, какими будут их потенциальные результаты, как их продемонстрировать приемщику, как зафиксировать документально полученные результаты, что делать если они неудовлетворительные, частично неудовлетворительные, удовлетворительные и далее в том же духе. в ГОСтах довольно много всего написано на эту тему.

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

210

Для всех / Re: Сколько у вас уходит время на сбор и оформление требований?

« : 17 Февраля 2011, 20:09:02 »

Такого ответа шеф не поймет. Ему нужен ответ сколько дней, а лучше часов

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

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

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

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

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