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

×


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

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


Сообщения - div

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
31
существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
...
 никогда не будет одного документа, эффективно читаемого как заказчиком, так и разработкой
Согласен, если есть много денег, много времени, и необходимо строго, однозначно и формально фиксировать все факты принятия проектных решений и моменты передачи ответственности за них, то без всего этого не обойтись.  Потому что в процессе такой разработки, кроме продукта, должны появиться и документы, на основании которых прокурор мог бы подписать постановление, если не дай бог, применение продукта принесет кому-либо существенный вред (например, потерю серьезных денег, что возможно в банковских системах, не говоря уже про военные приложения и АСУ).
Но мне кажется полезным всегда помнить, что заказчику нужен в первую очередь работающий продукт, а порождение разнообразных документов является неизбежным злом, которое нужно стараться минимизировать, настолько, насколько это возможно в данном конкретном случае.
а что до взаимных обвинений в кривомозгости, то я с вами не соглашусь - в ЛЮБОМ сложном проекте с внешним заказчиком, наступает момент таких обвинений.
Вы же помните из курса логики, что для опровержения логического утверждения с квантором общности ("ЛЮБОЙ") достаточно единственного примера обратного? :)
У меня каждый второй примерно проект с внешним заказчиком обходился без  "взаимных обвинений в кривомозгости", в том числе и достаточно сложные, дорогие, и с непростыми госзаказчиками ... тут скорее дело в индивидуальном стиле общения.

32
Боюсь, если проект добрался до стадии обоюдных обвинений в 'кривомозгости', и эта тенденция охватила большинство участников, этот самый проект уже неживой. :)
Да, спасибо за четкую формулировку, именно на это я и хотел обратить внимание коллег Ida и Elf, которые в данном топике, по сути, обсуждают проблему "Каким способом лучше перевесить ответственность за провал проекта с аналитика на кого-нибудь еще". А топикстартер задавал несколько другой вопрос :)

33
А при чем тут релиз?
Если программисты криворукие (или кривомозгие), это не ваша ответственность
Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.
В противном случае, нет шансов достичь главного критерия качества работы аналитика, о котором упомянул Salar:
Главная проверка - если заказчик сказал "Вах, это то, что я хотел" два раза: один читая документ, второй - после работы с программой, - то есть шанс, что документ был неплох.
Другими словами, если ваша работа не привела к выходу продукта ожидаемого качества -- значит вы делали не то, что нужно. Независимо от того, много ли вы работали, насколько устали, и кого считаете виноватым в провале.
Программисты, вообще говоря, en masse люди довольно образованные. Если у вас есть основания считать какого-то из своих программистов кривомозгим, попросите заменить его на другого, предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.

34
Владимир, системные аналитики в IT не занимаются "системным анализом и управлением"!

35
По всем количественным характеристикам похоже на то, что оптимально будет сделать табличку в Excel, или "чуть более защищенную табличку, не в Excel, но очень близко".
И похоже, что "Похоже так и будет решаться задача" :)

А если бизнес пойдет, то года через 2 придут спрашивать, как перенести данные из Excel в 1С:.

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

37
У меня была мысль сделать на ЛАФ доклад "Почему системные аналитики не занимаются системным анализом", как раз на тему что обычно ожидают от системного аналитика и что он на самом деле может дать проекту. Но в этом году не сложилось приехать...
Насчет обязаностей - с моей точки зрения самое правильное определение дает (как это не смешно) Википедия: http://en.wikipedia.org/wiki/System_analyst:
Цитировать
A systems analyst researches problems, plans solutions, recommends software and systems, and coordinates development to meet business or other requirements.
Это, как бы, отличительное качество системного аналитика, присущее роли.
А дальше, в разделе "Чем может заниматься аналитик", можно найти все из вышеперчисленных занятий:
Цитировать
...
 * Interact with customers to learn and document requirements that are then used to produce business requirements documents.
 * Write technical requirements from a critical phase.
 * Help programmers during system development, ex: provide use cases, flowcharts or even Database design.
...
...
 * Document requirements or contribute to user manuals.
 * Whenever a development process is conducted, the system analyst is responsible for designing components and providing that information to the developer.
...
 

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

39
голову сломал с приблудой TeamSpec - специализированная надстройка в ворде для управления требованиями в ТФС.
это конечно ад, с ней работать,
В рамках проекта миграции на TFS всего департамента разработки, мы проводили исследование разных средств интеграции для TFS, в том числе пробовали применять TeamSpec.
В результате TeamSpec был признан непригодным.
С другой стороны, кто-то с ним работает ведь... (я правда лично не знаю никого, кто бы его успешно внедрил).

40
Елена, мне было бы интересно попробовать порешать ваше задание.
Можете прислать на почту в профиле или в личку?

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

42
работа достаточно простая по сути - собрать требования с клиента и записать их.
-"Ээээ, ну этаааа..., ну мне надо, чтобы было круто, ну так... по нормальному!"
-"ОК, ваше требование записано!"

43
Попробуйте гуглить Ассоциативный класс вместо Класс ассоциации, и информация сразу найдется :)

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

45
Я знаю Ирину и Григория как профессионалов высокого класса и рекомендую клуб, особенно для тех, кто не живёт в МСК.
Я бы подчеркнул - как профессионалов, практикующихся на проектах мирового уровня. Пользы участникам должно быть на два порядка больше, чем от семинара Atlantic Systems Guild ;)

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »