91

Бизнес-анализ и Целеполагание / Re: Расчетно-технологическая карта

« : 31 Октября 2010, 23:22:44 »

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

Да, если речь идет об ИТ-компании, аутсорсящей вычислительные мощности и хранение, то там эти расходы тоже надо возлагать на стоимость услуги, измеряя процессорное время и гигабайты на винчестерах, с учетом амортизации оборудования. И нужна соовтествующая статистика (которая ведется). Тут сложность в квантовании: если у нас есть 1 процессор, который один месяц использовали 3 клиента в разных долях, а другой - только два, получается, что себестоимость выросла в 1.5 раза. А это не слишком хорошая модель получится.

92

Бизнес-анализ и Целеполагание / Re: Документ об образе и границах проекта

« : 31 Октября 2010, 23:13:27 »

maksiq, дайте плс ссылку на пример более полезного, на ваш взгляд, формата и содержания концепции

Ссылку - не дам. Потому что не видел. Но если говорить о концепции, то в этом документе у Вигерса весьма неплохое оглавление, которое определяет набор вопросов. Если к нему добавить жесткое ограничение в 5-7 страниц, которое требовать для большой системы - то будет то, что надо. Просто у Вигерса на кафетерий - те же 7 страниц,а это - явно маленький проект. Хотя, тут может быть эффект масштаба - есть некоторый минимум, ниже которого нельзя опуститься.

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

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

93

Обучение / Re: Дисциплина "Технология обработки информации"

« : 31 Октября 2010, 22:56:49 »

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

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

P.S. Извиняюсь, если не совсем по теме. Или я не понял, и речь идет о разработке ФГОС?

94

Бизнес-анализ и Целеполагание / Re: Расчетно-технологическая карта

« : 31 Октября 2010, 22:46:52 »

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

Что нужно делать, если информация есть? Берем суммарное время человека за месяц, делим пропорционально его зарплату (с учетом коэффициента года - отпуска, болезни) - получаем стоимость в зарплате. К зарплате добавляем связанные с ней расходы - ЕСН, НДС. Потом берем аренду и инфраструктуру, их правильно делить пропорционально людям (человеко-часам)  на каждую услугу без учета зарплаты, если только дорогой сотрудник не занимает сильно больше места, например, отдельный кабинет, но с учетом личного коэффициента фиксации - если один сотрудник зафиксировал в месяц 100 часов, а другой - 130, то рабочее место оба занимали целый месяц. Собственно, после этого получаем себестоимость.

Считается в Excel, специальные системы не нужны (кроме time tracker, но это для первичных данных).

95

Обсуждение статей / Re: КС

« : 31 Октября 2010, 22:32:09 »

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

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

96

Бизнес-анализ и Целеполагание / Re: Документ об образе и границах проекта

« : 31 Октября 2010, 21:53:43 »

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

P.S. Если Заказчик балдеет от таких документов и хочет их иметь в этом виде - не вопрос. Но если он просто ждет реальной работы над решением своих проблем - то этот шаблон от Вигерса - не лучший способ.

97

ПО Аналитика / Re: Лучше рисовать диаграммы на бумажке или в CASE?

« : 31 Октября 2010, 21:37:30 »

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

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

В качестве средства рисования для простых схем использую встроенные средства MediaWiki (мы ведем постановки в wiki). А для более сложных - сразу в MS Visio, шаблон UML (только не родной, а с http://softwarestencils.com/uml), если речь идет о формальной области, или набор из нескольких шаблонов, адекватных задаче.

По поводу добавления в ТЗ. Все понимают, что диаграммы и картинки могут изменяться. Но они являются очень эффективным средством получения общей картины, в том числе - согласования ее с заказчиком. Так что у нас - предъявляются ему сразу, обсуждаются и согласуются. Особенно vision на новые части или изменения. Другое дело, что при работе с некоторыми заказчиками надо различать формальное ТЗ и реальные обсуждения. Но обсуждения должны быть, и картинки - эффективный инструмент для этого.

98

Обучение / Re: Программист

« : 31 Октября 2010, 14:09:16 »

Про изучение UML: Мартина Фаулера - UML distilled - это обязательно. Эта книга объясняет сложившуюся практику использования - для проектирвоания, и проходится по основным диаграммам. И всего около 100 страниц, в которых много диаграмм-примеров, что важно.

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

Книгу уже рекомендовали выше, но "пони бегают по кругу"...

99

ПО Аналитика / Re: [Посчитаемся] Какие CASE средства с поддержкой UML вы используете?

« : 27 Октября 2010, 18:16:24 »

Мы используем Visio для рисования UML и всего остального. Только для uml надо использовать не родные template, которые требуют заполнять кучу всего, а шаблоны из http://softwarestencils.com/uml/index.html которые ориентированы на изображение именно схем-картинок (единственное, мы брали версию пару лет назад, что там сейчас - не знаю). Плюс простые картинки (мало кружочков и стрелочек) можем рисовать "подручными средствами".

100

Обучение / Re: Подскажите придумать тему для диплома!

« : 26 Октября 2010, 21:39:37 »

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

101

Методологии / Re: оформление требований в виде набора таблиц в вордовом документе

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

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

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

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

И, наконец, формируя шаблон для требований посмотрите, что будет в режиме исправлений и как будет срабатывать объединение и сравнение версий. Напишите несколько требований, поправьте от разных пользователей, объедините. Могут быть чисто word-заморочки в этом процессе, связанные с нюансами форматирования (таблица/не таблица и т.п.). И еще могут быть заморочки с версиями Word - MS же с каждой версией его улучшает, и если автор и читатели-референты пользуются разными версиями, могут быть неприятные сюрпризы. Этот пункт чисто технический, просто лучше это все заранее проверить и сделать устойчивый в этом смысле шаблон оформления требования.

А в целом - способ рабочий, если заказчик хочет ТЗ на 800 страниц (есть такие заказчики, я знаю).

102

Обсуждение статей / Re: ИТ -стандарт 2010

« : 22 Октября 2010, 21:19:52 »

На SECR кто-то из корифеев про SOA начал про проблему стандартов с большого многодневного пожара в 19 веке в штатах, когда выяснилось. что пожарные рукава нельзя соединить в один длиный, а если вода далеко - то это нужно. Заметим, что это интересно, когда пожарные команды есть и функционируют. А если их нет - стандартизация носит виртуальный смысл. А, по мнению автора - ИТ-бизнес в России - в жопе "по причине некомпетентного руководства отраслью". Ну и причем здесь стандарты? Или стоит их принять - и тут же бурный рост будет?

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

103

О Сайте и Форуме / Re: Кто и зачем использует ресурс ?

« : 22 Октября 2010, 21:10:10 »

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

104

Обсуждение статей / Re: Описание бизнес-процессов: стремление к простоте

« : 22 Октября 2010, 21:06:10 »

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

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

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

P.S. А что в описаниях и диаграмах надо стремиться к простоте - это классика. Фаулер, UML distilled.

105

Проектирование / Re: Проектирование БД. Логический уровень

« : 20 Октября 2010, 00:06:40 »

Кейс-средствами проектирования БД мы не пользуемся (причины могу рассказать отдельно, так сложилось, в свое время - использовали ErWin). Однако описание логической структуры БД в виде UML-диаграммы классов - активно используем при проектировании и сопровождаем по мере изменений в системе, обычно рисуем в Visio. Это именно логическая структура, на которой скрыто большое количество служебных классов, служебных атрибутов, ограниченно прописана типизация. Структура представляется и активно обсуждается с заказчиком, обычно мы взаимодействуем с его IT-подразделениями.