61

О Сайте и Форуме / Re: Новости Cайта

« : 07 Июня 2009, 13:05:40 »

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

Если реально - то в процессе неконтролируемого и неограниченного удовлетворения Заказчика можно загнать проекты разработки и внедрения в глубокий минус. Да, будет улучшена репутация, но не всегда её можно быстро монетизировать - а з/п разработчикам и внедренцам хочется получать всё время. Заказчик может быть великолепно удовлетворён, а компания от такого проекта может обанкротиться. Какой же в этом успех?

Так что при капитализме [единственный универсальный] критерий успеха - чистая прибыль. Т.е. сделать подешевле, продать подороже. Только Заказчикам об этом не говорите .

Управление требованиями включает ещё одну дисциплину, о которой не принято говорить - умение говорить Заказчику слова "будет через полгода", "будет когда-нибудь", "будет только за отдельные деньги", "не будет никогда" и "ура! вы просили - и вот оно появилось!".

62

Управление Проектом / Re: Управление изменениями в реальной практ&#

« : 31 Мая 2009, 23:28:16 »

А у нас всё завязано на деньги, и потому довольно просто.

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

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

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

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

63

Работа / Re: Худшие практики (антипаттерны) в работе ан

« : 31 Мая 2009, 21:53:34 »

В этом что-то есть Правда и на солнце пятна

+1
IMHO у аналитиков из тестировщиков - пунктик на профайлинге, логировании и тестабилити. А у бывших инженеров из внедрения и поддержки - на сборе статистики, простоте установки, защите от дурака, zero administration и утилитах командной строки. Всё это, конечно, важно и нужно, но когда "пунктики" приводят к тому, что у системы "проседает" пользовательская функциональность, ради которой её покупают - всем становится плохо. Кроме того, и тестировщики, и инженеры обычно привыкают быть "в контре" с разработчиками. А если аналитик не дружит с разработчиками - они не идут к нему за уточнением требований, да и вообще реализовывают требования на оценку "отстаньте".

64

MDA / Re: UML в качестве редактора универсального брk

« : 31 Мая 2009, 17:10:49 »

Лет пять назад раз я тоже похожий фреймворк (на PHP ) сделал. В нём достаточно было объявить структуру данных в подключенной БД - и автоматически появлялась возможность просматривать и искать их в табличном виде, добавлять и редактировать в детальном, переходить между связанными записями. Выполнять действия над записями (и добавлять их, описывая логику на том же PHP ), планировать задачи. С учётом авторизации и полномочий пользователей. Были также заготовки для "документов" и "сложных объектов".

БД использовалась только для хранения и поддержки целостности при этом, никакой неестественной логики в триггерах и хранимых процедурах не было. Поэтому генерировалась она из "логической" ER-диаграммы (через "физическую") на PowerDesigner. Собственно, к "физической" можно было переходить и от UML, но тогда я не чувствовал в этом надобности. Поэтому, кстати, поддерживались 2 очень разные СУБД - PostgreSQL для "штатного" использования, и SQLite для демонстрации "с флешки" (тогда она у меня была, как помню, объёмом 32 Мб USB 1.0, поэтому не быстрая).

Реализовать прототип системы оценки и сертификации санаторно-курортных организаций на этом фреймворке заняло 3 мес. (включая доработку самого фреймворка). Впрочем, работа с БД была далека от совершенства, в некоторый момент пришлось оптимизировать запросы по отдельности, выделять слой доступа к данным, строить хитрые индексы, и красота MDD от "логической" модели стала пропадать - пришлось "логическую" и "физическую" ER-диаграммы держать в связанном виде. Потом стал вводить в описание структуры данных для системы разные "хинты" для автоматического построения форм в более "красивом виде". В общем, "субъективные бантики", которые нужны Заказчикам, портят всю красоту MDD, а предугадывание "бантиков" - задача длительного исследования и построения сложного ИИ .

Потом пару раз пробовал этот фреймворк для разного использовать: сделать системку для управления разработкой при SCRUM'е заняло 1 нед., инвентаризатор ресурсов в локальной сети - тоже 1 нед. В какой-то момент хотел выложить фреймворк в GPL на sourceforge - но увидел, что там несколько таких уже есть, и что в моей поделке есть много dirty code, "вычищать" который у меня уже не было времени и желания (в тот момент я как раз перешёл на работу "специализированным" системным аналитиком в совсем другой предметной области).

65

Работа / Re: Худшие практики (антипаттерны) в работе аналитика

« : 23 Мая 2009, 15:05:39 »

Хотите ещё антипаттенов?

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

2. (со стороны аналитика) Когда-то мы делали систему... Вот это было да... Система была с облаком сервисов, метаданными и общей шиной, её можно было сконфигурировать как угодно. А давайте система будет сложной и гибкой!

3. (со стороны аналитика) Мне так нравится программировать и копаться в технике... Давайте мы будем делать в продукт для гуру и гиков, и чтобы там можно было делать всякие разные эксперименты, менять поведение, встраивать свои скриптики, использовать части системы в своих поделках.  Заказчики, клиенты... Я уверен, в глубине души они хотят того же!

66

MDA / Re: UML в качестве редактора универсального браузера

« : 23 Мая 2009, 13:33:11 »

Сам являюсь таким "ленивым соотечественником". Поэтому задаю вопросы:

1) Чем не устраивает MS Access с его мастером форм? Сначала тщательно описываете таблицы, а затем - практически одной кнопкой генерируете для них формы. Согласен, сама MS Access поддерживает MDA/MDD только на базе своих ER-диаграмм, весьма своеобразных. Но никто не мешает использовать для генерации БД другие инструменты. В том же Sybase Power Designer можно через цепочку последовательных преобразований дойти до SQL от "UML Class".

Если не устраивает тем, что M$ и проприетарщина - так есть и FOSS фреймворки с похожей функциональностью.

2) На самом деле, есть языки, на которые ближе к описанию правил, по которым ведётся бизнес. См. BPMN/BPEL, ARIS, IDEF0. Не хочется сделать BPMS?

3) Насколько я понял, Вы хотите автоматизировать и исключить (полностью!) работу программиста. Ну допустим, в Ваше приложение пришло такое "ТЗ" полностью на UML (см. прикреплённые файлы). Неполное, не везде корректное. В таком случае приложение начинает задавать вопросы: уточните то, уточните это, укажите типы данных, а какие состояния относятся к каким документам, а какого типа формы кому показывать и т.д. В результате надо наполнить модель деталями, комментариями и конкретикой настолько, что... IMHO проще и удобнее будет описать всё то же самое на языках программирования. И даже выучить по такому случаю эти языки.

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

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

Хотя, конечно, уже почти 10 лет как 21-й век на дворе. Давно пора перестать переливать интеллектуальную работу туда-сюда и делать её неотделимой от рутины, а написать действительно искусственный интеллект, который возьмёт на себя всю рутину и как минимум часть интеллектуальной работы.

67

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

« : 17 Мая 2009, 18:21:12 »

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

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

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

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

68

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

« : 17 Мая 2009, 15:09:42 »

1. Можно ли говорить о критериях этапа выявления требований и нужно ли? Под критерием понимается некий признак, на основании которого производится оценка этапа выявления (сбора информации).
2. Покрывает ли этап анализа требований оценку этапа выявления?
3. Что вы скажете, если использовать следующие критерии:
- внутренняя согласованность и непротиворечивость;
- системность;
- объективность;
- историзм.
<...>

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

Считаю, что критерии успешности сбора требований:

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

5. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?

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

69

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анкетирование

« : 05 Апреля 2009, 02:12:47 »

Заказчики бывают потенциальные и существующие.

Какие вопросы задавать потенциальным заказчикам - лучше расскажут менеджеры по продажам и люди, проводящие маркетинговые исследования. В любом случае,
- при интервьюировании вопросы надо задавать скромно, по существу, ориентируясь на целевую аудиторию, чтобы ненавязчиво заинтересовать (для "бизнес"-людей - "а вы знаете, что есть такая возможность?", "а вы знаете, что у многих в вашей отрасли такая проблема?", для технических - "вы знаете, есть софт/железо/..., у которого такие клёвые фичи?")
- анкетирование в стиле "100 вопросов перед тем, как вам позволят посмотреть наши маркетинговые материалы или скачать демо-версию: сколько людей в вашей компании - от 1000, ниже нам неинтересно, сколько доход вашей компании - от $100M, ниже нам неинтересно, сколько вы готовы дать нам сразу - от $10M, меньше нам неинтересно, кто вы - директор, если ниже, то нам неинтересно" ОЧЕНЬ вредно. Лучше в стиле "чтобы вы хотели видеть" с ОЧЕНЬ разумными вариантами и "прикидкой коммерческого предложения", формулирующемого по результатам интервью человеком (и никаких "ну, у меня нет полномочий обсуждать с вами коммерческие вопросы") или генерируемого в ответ на анкету автоматически. Хотя тут некоторые сейлы могут меня "расстрелять": действительно, в пьяной задушевной беседе после успешной "работы печенью" иногда можно продать на порядок дороже.

Существующему заказчику что в интервью, что в анкете задаю 2 вопроса: "Вы бы порекомендовали наше решение другу?" и "Почему?"

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

70

Бизнес-анализ и Целеполагание / Re: Примеры работы отдела разработки(нацеленность на поддержку)

« : 03 Апреля 2009, 23:43:59 »

Нацеленность на поддержку у нас - такая же, как и на развитие.
Ветку опишу только реактивную, не проактивную.
Если  поддержка - то исключительно исправление ошибок. Реализацию пожеланий выношу в проактивную ветку - её в договоре о поддержке не обещаем. Много тут кто чего желает, обобщая - "канарейку за копейку, чтобы пела. СРОЧНО!!!".

1) Заказчик оформляет заявку на дефект.
2) Инженеры проверяют дефект, и понимают, где дефект: в настройках, которые они сделали (тогда сами виноваты), в ПО, или в руках и голове заказчика (считаю, что писать это слово с большой буквы в середине предложения - показуха). Если в ПО - то 3), если нет - то инженеры устраняют и объясняют сами, на своём уровне, или привлекают менеджера по работе с эти клиентом.
3) Если инженеры нашли пути обхода - то ветка а); если инженеры не нашли пути обхода или ошибка не позволяет внедрить и получить деньги - то б)

1а) Инженеры вводят ошибку - normal или меньше
2а) Тестировщики проверяют ошибку
3а) Если ошибка воспроизводится - то аа), иначе аб)

1аа) Ошибка учитывается
2аа) Ошибка исправляется - рано или поздно, через план и возмущение "чего этот enchancement уже второй год висит? да вся разработка просто бездельники!"

1аб) Тестировщики возвращают ошибку инженерам
2аб) goto 2

1б) Инженеры вводят ошибку - major или выше
2б) Тестировщики проверяют ошибку
3б) Если ошибка воспроизводится и её нельзя обойти - то 1ба), если воспроизводится и её можно обойти - то 1аа), если не воспроизводится - то 1аб)

1ба) Ошибка исправляется сверх плана. По крайней мере один программист вплотную занимается исправлением этой ошибки. Разработчики устают и/или планы, в т.ч. исправление менее важных ошибок, сползают на "пессимистичные" даты.

Упрощённо - так. Хотя бывают разные "исключительные ситуации".

71

Бизнес-анализ и Целеполагание / Re: Роль бизнес-аналитика

« : 16 Ноября 2008, 19:16:57 »

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

Что же до цены ошибки BA vs DBA, то ошибка BA - ошибка концептуального проектирования, а ошибка DBA - ошибка поддержки. И сравнивать их, по-моему, некорректно. Хоть RUP и говорит, что первое всегда дороже второго, но платят за это разные люди, т.к. ошибка DBA связана с непрерывностью бизнеса, а в некоторых случаях (напр. БД аэропорта или АЭС) - с непрерывностью жизни. В противном случае при нормальном DBA это - потеря результатов работы в системе за 0,25-0,5 часа, и частичная остановка бизнеса на это время, что всегда закладываемая в риски.

72

Sparx / Re: Анализ влияния в EA и Raquest

« : 08 Ноября 2008, 11:13:10 »

Я знаю такой способ: просто "вытащить" оба требования на одну модель и визуально создать связь между ними, нужного типа. Как ни странно, это довольно удобно, помогает думать. Древовидную структуру требований можно дублировать связью "aggregation", зависимость одного от другого изображать в виде "dependency", дублирование - "association".

73

Книги, статьи и ресурсы / Re: Software Requirement Patterns

« : 05 Ноября 2008, 00:50:11 »

Книгу не читал - буду восполнять.

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

А "отображать сообщения, как в Thunderbird", "сделать настройку прокси, как в Firefox", "сделать настройку регулярных задач, как регулярных встреч в Outlook", "сделать отчёты, как в Rational SoDA" я бы всё-же не стал называть паттернами: банальное списывание заведомо работающих (хотя и не обязательно лучших) решений. И то, такое описание - лишь чуть лучше, чем "TBD".

74

Системный Анализ и Требования / Re: Выбор ПО для управления требованиями (PLM)

« : 05 Ноября 2008, 00:35:28 »

Мне нравится wiki для  бизнес-требований и наоборот, идей из области архитектуры.

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

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

А фиксировать системные требования и генерировать документы для их согласования, сведения в рамки релизов, и передачи, я предпочитаю с помощью Enterprise Architect.

75

Системный Анализ и Требования / Re: Как правильно трассировать?

« : 05 Ноября 2008, 00:16:58 »

Правильнее трассировать от Пользовательских Требований к Бизнес Требованиям или наоборот?
Т.е. меня интересует направление трассировки!

IMHO направление трассировки не имеет значения. Раз бизнес-требование как-то связано с системным - понятно, что бизнес-требование является источником системного.

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