106
Поздравления / Re: Поздравляем Иру Сурову с Днем Варенья!
« : 21 Февраля 2011, 19:42:50 »
Всего самого наилучшего! Счастья и успехов!
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
107
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 21 Февраля 2011, 00:08:30 »
нашел вот такую штуку: http://habrahabr.ru/blogs/webdev/70424/ посмотрю (английский текст занимает много времени.. хотя на русском я не нашел трудов, но пока ограничусь хабром).
108
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 20 Февраля 2011, 16:31:14 »
Мы делали доменную модель с текстовым описаниемм.. То есть, эмиссия акций может быть сделана только после их объявления, мы не можем выпустить больше акций чем было объявлено, мы можем разом выпустить все акции, которые были объявлены в различных локументах.
Как-то так. Вообщя я больше люблю доменные модели, но использую их в самом начале проекта (в текущем проекте, например, она перестала поддерживаться из-за нехватки времени).
Как-то так. Вообщя я больше люблю доменные модели, но использую их в самом начале проекта (в текущем проекте, например, она перестала поддерживаться из-за нехватки времени).
109
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 19 Февраля 2011, 23:19:51 »Нужно ли указывать в требованиях (ТЗ) в каком поле какой интерфейсной формы эти расчетные показатели должны отображаться? И если да, то не должно ли описание интерфейса с приложением интерфейсных форм отнесено в документы технического проекта (если он документируется по ГОСТ)? У Вас тогда будет время продумать дизайн интерфейса и согласовать его с Заказчиком позже, при утверждении (технической) проектной документации.
Если же Заказчику важен, например, размер полей печатной формы отчета в зависимости от объема и содержания представленной в отчете информации - то это компетенция СА. Но это, наверное, не Ваш случай?
/quote]
Да, нужно.
И это как раз мой случай из предыдущего проекта - заказчику было интересно юзабилити, причем зачастую он принимал решения по реализации интерфейса, считал лишнии клики и тп. Ещё, например, сколько строк делать в поле -1 или 5..
По второй части - Мы просто связывали функциональные требования, описанных текстом, к элементам интерфейсов. Я понимаю, что Юз-кейсы важны, но мне на них времени не дают... То есть, я должен предоставить результат, по результату смотрят мои затраты по времени с прашивают - нафига так много? Если я говорю, что рисовал юз-кейсы, то спрашивается - зачем? их достаточно продумать и как мне угодно зарисовать, но не оформлять и прочее.
Только вот всё равно волнует - один документ или много...?
110
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 18 Февраля 2011, 23:10:16 »
Shur, спасибо большое за развернутый ответ и пищу для размышлений. Один нюанс - предаставитель заказчика отчасти выступал как БА, то есть он формулировал свой бизнес процесс, но ещё и интересовался СА - сам, например, описывал формулы расчета некоторых полей.
Не могу сказать, что проект был не по ГОСТу...
А вот про разработку систему от функций я наслышан, но практических примеров не видел.. Нет ничего такого, прочитать или хотя бы на пример посмотреть?
Не могу сказать, что проект был не по ГОСТу...
А вот про разработку систему от функций я наслышан, но практических примеров не видел.. Нет ничего такого, прочитать или хотя бы на пример посмотреть?
111
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 17 Февраля 2011, 00:22:57 »
Читал, но лично для меня на этом вопрос снят не был. RUP и, можно сказать, госзаказчик с водопадом (которому бегом нужен итог с прототипами, а не юз-кейсы, которые он не хочет читать) у меня вообще не стыковались, как не крутить.
Тут мне больше Леффингуелл помог, но на текущий вопрос однозначного ответа все равно у меня нет.
Тут мне больше Леффингуелл помог, но на текущий вопрос однозначного ответа все равно у меня нет.
112
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 16 Февраля 2011, 22:37:07 »
Большой пост не лезет и тормозит... выложил на блоге:
http://akiselev87.wordpress.com/2011/02/16/%d1%82%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%be%d0%b4%d0%b8%d0%bd-%d0%b4%d0%be%d0%ba%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d0%b8%d0%bb%d0%b8-%d0%bc%d0%bd%d0%be%d0%b3%d0%be/
Основное сюда сумел впихнуть...
http://akiselev87.wordpress.com/2011/02/16/%d1%82%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%be%d0%b4%d0%b8%d0%bd-%d0%b4%d0%be%d0%ba%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d0%b8%d0%bb%d0%b8-%d0%bc%d0%bd%d0%be%d0%b3%d0%be/
Основное сюда сумел впихнуть...
113
Системный Анализ и Требования / Описание требований. Много документов или один
« : 16 Февраля 2011, 22:34:09 »
Всегда задачался вопросом, работая на стыке БА и СА - писать требования одним документом, или же отдельными постановками, подумал над этим вопросом, мысли записал...
Надеюсь на конструктивную критику
Введение
На моей практике я успел поработать в компаниях, которые писали требования как в рамках одного документа, так и в рамках отдельного документа на каждый объект создаваемой системы. В данном случае, под объектом я буду рассматривать один или несколько элементов доменной модели (а это ещё могут быть нефункциональные требования и тп), которые являются в системе либо справочником, либо документом (карточкой, страницей, кто как называет), но не на каждое или группу ФТ (функциональное требование). На основании этого документа ведется разработка и тестирование (в частности), его же подписывает и заказчик.
Один большой документ на всем протяжении проекта
Изначально при работе с заказчиком мы собираем требования, формируем ТЗ (которые в моей практике зачастую выглядят как требования разработчикам, так что тут ТЗ=постановки на реализацию), а после чего нам необходимо этот документ подписать.
В каком случае мы можем работать с одним документом? Такая ситуация может возникнуть, если над проектом работает один аналитик, а так же один или множество заказчиков. При работе с множеством заказчиков в одном документе потребуется хорошо планировать работу, чтобы проверку требований и реализации заказчики осуществляли поочередно. Это очень тяжело, так что я всегда вел требования каждого заказчика в отдельном документе, а после согласований их объединял. В данном случае, если заказчиков множество, то придётся распараллелить их работу по согласованию документа, что скажется на сроках проекта.
В написании требований одним документом есть следующие преимущества:
Сквозная нумерация разделов (которая, правда, может поехать при обновлении формул, но ведь гораздо удобнее написать - делай ФТ12.1.13, чем делать ФТ*************** ******* ******** ****** (****** ******)
- Сквозная нумерация полей (и формул), требований в системе.
- Описание формул при помощи ссылок на их уникальные номера. Согласимся, что написать в формуле расчета: 546/32, если 96>12 будет гораздо быстрее, чем писать, что итог =поле *** справочника ***, деленное на поле *** справочника ***, вкладки ***, при условии, что поле *** документа *** больше поля *** справочника ***. И это ещё не самая изощрённая формула...
- Удобство поиска (ищем в одном документе, а не перебираем множество существующих)
Соответственно, при работе с одним заказчиком одного аналитика эффективнее работать в рамках одного документа. Но тут можно заметить, что эти плюсы более существенны при передаче проекта - в одном документе проще ориентироваться при погружении в проект, в то время, как автор, обычно, помнит, где и что написано.
Проблем с обновлением быть не должно - новые поля нужно вносить с уникальным номером (добавлять список ниже), а вообще, лучше вести их в отдельном ексель-файле, а в ТЗ давать только ссылки на номер поля в ексельнике.
Много документов и мы можем эти документы по отдельности подписать
Если проект автоматизирует какую-либо большую область, то тут уже требуется работа нескольких аналитиков, особенно, если объемный проект следует выполнить за более короткий срок, чем если его будет вести один аналитик.
Мне, например, гораздо эффективнее и комфортнее работать как минимум в паре, постоянно критикуя каждое требование и идею друг друга, а потом фиксируя решение. При такой организации работы можно осуществлять тестирование требований, обсуждать их и спокойно уходить в отпуск, не боясь звонков и вопросов. Однако работа в команде сразу говорит о том, что у вас не получится писать ТЗ в одном документе.
Значит, такое случается, если аналитиков много, а каждый из них пишет свою часть (либо аналитик не сумел распараллелить заказчиков). Либо одна часть будет равна тому объему работы, который взял на себя аналитик, либо, документ будет реализован на каждую фичу (я так никогда не работал, рассмотрю это в следующий раз), либо на каждый объект в системе. В итоге все это нам подписывает один человек и он согласен на кучу документов.
Подход
Кучу мелких доков писать несколько дольше с той точки зрения, что мы не можем использовать нумерацию полей, либо же потребуется использовать префикс в каждом документе (кстати, читай - интерфейсе), а формула будет выглядеть например так “=БС13/(ПС42 - КОП56)”. Можно писать все текстом, здесь есть плюсы и минусы - с одной стороны, при переименовании поля - не надо его же переименовывать во всех документах, с другой, без открытия дополнительных файлов можно узнать что считает формула, а так же нет трудностей при изменении местоположения поля, если их номера соответствуют порядку отображения (что логично).
Большим минусом могу выделить поиск по документам и необходимость держать в голове все формулы, где используется данное поле, чтобы апдейтить другие документы. Возможно, проблему решит матрица трассировки, но в ней будет мало конкретики, если привязывать документ к документу.
Опять же можно выделить отдельно ексельник с формулами (можно вообще пойти по пути создания прототипов в каком-нибудь Axure и екселе с формулами на него).
Либо мы можем объединить все мелкие доки в один большой, а писать его в 3 руки в гугл доках (пока всемирное торможение гугл дока не поглотит проект странице к 30-й).
Мы можем подписать только один документ, а у нас их множество
Если руководитель заказчика крайне занятой и высокопоставленный, то однозначно придётся готовить один документ. Тогда, очевидно, это опять ексельник для хранения полей, либо же все формулы и тп будут описаны текстом. При обновлении я бы рекомендовал забыть про слитый док, оставить его заказчику, а сами апдейтить изначальные поделенные документы... Мусолить частями старый документ я не вижу смысла. Есть некоторая проблема - если требуется показать какие именно поля и описания были изменены..
Если заказчик настаивает, что это новый проект и он не хочет подписывать новое ТЗ (постановки на реализацию), а вести только изменения на каждый элемент интерфейса, то тогда, при написании новых документов или правке каждый аналитик будет готовить список новых полей и измененных, а так же новые документы. Потом переносить это в один сводный документ и опять подписывать. Лишняя работа у нас будет по переносу новой информации. Как входной материал можно использовать не весь документ, а сразу браться за доки, которые мы мержили для подписи. Очевидная проблема - как писать формулы, если часть нумерации в старом ТЗ, а часть в новом (лазить туда-сюда и давать ссылки на старый док, чтобы показать заказчику, а потом сносить в общий ексельник, актуальный по системе).
В любом случае, самый лучший вариант - все поля вывести в отдельный Excel-файл, соблюдать там единую нумерацию (с этим не должно быть трудностей), апдейтить маленькие доки, а новые объекты вносить под новыми последующими номерами.
Надеюсь на конструктивную критику
Введение
На моей практике я успел поработать в компаниях, которые писали требования как в рамках одного документа, так и в рамках отдельного документа на каждый объект создаваемой системы. В данном случае, под объектом я буду рассматривать один или несколько элементов доменной модели (а это ещё могут быть нефункциональные требования и тп), которые являются в системе либо справочником, либо документом (карточкой, страницей, кто как называет), но не на каждое или группу ФТ (функциональное требование). На основании этого документа ведется разработка и тестирование (в частности), его же подписывает и заказчик.
Один большой документ на всем протяжении проекта
Изначально при работе с заказчиком мы собираем требования, формируем ТЗ (которые в моей практике зачастую выглядят как требования разработчикам, так что тут ТЗ=постановки на реализацию), а после чего нам необходимо этот документ подписать.
В каком случае мы можем работать с одним документом? Такая ситуация может возникнуть, если над проектом работает один аналитик, а так же один или множество заказчиков. При работе с множеством заказчиков в одном документе потребуется хорошо планировать работу, чтобы проверку требований и реализации заказчики осуществляли поочередно. Это очень тяжело, так что я всегда вел требования каждого заказчика в отдельном документе, а после согласований их объединял. В данном случае, если заказчиков множество, то придётся распараллелить их работу по согласованию документа, что скажется на сроках проекта.
В написании требований одним документом есть следующие преимущества:
Сквозная нумерация разделов (которая, правда, может поехать при обновлении формул, но ведь гораздо удобнее написать - делай ФТ12.1.13, чем делать ФТ*************** ******* ******** ****** (****** ******)
- Сквозная нумерация полей (и формул), требований в системе.
- Описание формул при помощи ссылок на их уникальные номера. Согласимся, что написать в формуле расчета: 546/32, если 96>12 будет гораздо быстрее, чем писать, что итог =поле *** справочника ***, деленное на поле *** справочника ***, вкладки ***, при условии, что поле *** документа *** больше поля *** справочника ***. И это ещё не самая изощрённая формула...
- Удобство поиска (ищем в одном документе, а не перебираем множество существующих)
Соответственно, при работе с одним заказчиком одного аналитика эффективнее работать в рамках одного документа. Но тут можно заметить, что эти плюсы более существенны при передаче проекта - в одном документе проще ориентироваться при погружении в проект, в то время, как автор, обычно, помнит, где и что написано.
Проблем с обновлением быть не должно - новые поля нужно вносить с уникальным номером (добавлять список ниже), а вообще, лучше вести их в отдельном ексель-файле, а в ТЗ давать только ссылки на номер поля в ексельнике.
Много документов и мы можем эти документы по отдельности подписать
Если проект автоматизирует какую-либо большую область, то тут уже требуется работа нескольких аналитиков, особенно, если объемный проект следует выполнить за более короткий срок, чем если его будет вести один аналитик.
Мне, например, гораздо эффективнее и комфортнее работать как минимум в паре, постоянно критикуя каждое требование и идею друг друга, а потом фиксируя решение. При такой организации работы можно осуществлять тестирование требований, обсуждать их и спокойно уходить в отпуск, не боясь звонков и вопросов. Однако работа в команде сразу говорит о том, что у вас не получится писать ТЗ в одном документе.
Значит, такое случается, если аналитиков много, а каждый из них пишет свою часть (либо аналитик не сумел распараллелить заказчиков). Либо одна часть будет равна тому объему работы, который взял на себя аналитик, либо, документ будет реализован на каждую фичу (я так никогда не работал, рассмотрю это в следующий раз), либо на каждый объект в системе. В итоге все это нам подписывает один человек и он согласен на кучу документов.
Подход
Кучу мелких доков писать несколько дольше с той точки зрения, что мы не можем использовать нумерацию полей, либо же потребуется использовать префикс в каждом документе (кстати, читай - интерфейсе), а формула будет выглядеть например так “=БС13/(ПС42 - КОП56)”. Можно писать все текстом, здесь есть плюсы и минусы - с одной стороны, при переименовании поля - не надо его же переименовывать во всех документах, с другой, без открытия дополнительных файлов можно узнать что считает формула, а так же нет трудностей при изменении местоположения поля, если их номера соответствуют порядку отображения (что логично).
Большим минусом могу выделить поиск по документам и необходимость держать в голове все формулы, где используется данное поле, чтобы апдейтить другие документы. Возможно, проблему решит матрица трассировки, но в ней будет мало конкретики, если привязывать документ к документу.
Опять же можно выделить отдельно ексельник с формулами (можно вообще пойти по пути создания прототипов в каком-нибудь Axure и екселе с формулами на него).
Либо мы можем объединить все мелкие доки в один большой, а писать его в 3 руки в гугл доках (пока всемирное торможение гугл дока не поглотит проект странице к 30-й).
Мы можем подписать только один документ, а у нас их множество
Если руководитель заказчика крайне занятой и высокопоставленный, то однозначно придётся готовить один документ. Тогда, очевидно, это опять ексельник для хранения полей, либо же все формулы и тп будут описаны текстом. При обновлении я бы рекомендовал забыть про слитый док, оставить его заказчику, а сами апдейтить изначальные поделенные документы... Мусолить частями старый документ я не вижу смысла. Есть некоторая проблема - если требуется показать какие именно поля и описания были изменены..
Если заказчик настаивает, что это новый проект и он не хочет подписывать новое ТЗ (постановки на реализацию), а вести только изменения на каждый элемент интерфейса, то тогда, при написании новых документов или правке каждый аналитик будет готовить список новых полей и измененных, а так же новые документы. Потом переносить это в один сводный документ и опять подписывать. Лишняя работа у нас будет по переносу новой информации. Как входной материал можно использовать не весь документ, а сразу браться за доки, которые мы мержили для подписи. Очевидная проблема - как писать формулы, если часть нумерации в старом ТЗ, а часть в новом (лазить туда-сюда и давать ссылки на старый док, чтобы показать заказчику, а потом сносить в общий ексельник, актуальный по системе).
В любом случае, самый лучший вариант - все поля вывести в отдельный Excel-файл, соблюдать там единую нумерацию (с этим не должно быть трудностей), апдейтить маленькие доки, а новые объекты вносить под новыми последующими номерами.
114
Обучение / Re: Системный аналитик курсы
« : 16 Февраля 2011, 22:16:21 »
Идите стажером, вакансии есть, например: http://moikrug.ru/feed/756429963/
Можете связаться со мной или с Дмитрием.
Можете связаться со мной или с Дмитрием.
115
Для всех / Re: Сколько у вас уходит время на сбор и оформление требований?
« : 16 Февраля 2011, 22:12:31 »
а ещё вы можете обнаружить останки предыдущего внедрения )))))) Что за проект оцениваете хоть?
116
ПО Аналитика / Re: Первые шаги аналитика. ПО, книги, советы
« : 11 Февраля 2011, 00:02:11 »Благодарю! Очень интересно! Инфы мне на долго хватит.
"User Stories Applied by Mike Cohn" и ""Agile Testing by Lisa Crispin"" на русском есть?
А вы что выбрали для СУТ?
у вас ссылка http://habrahabr.ru/blogs/agile/107484/#habracut - доступ к ней закрыт.
Мде, доступ действительно закрыли, но самое интересное я обычно копипастю или комментирую..
На все интересные книги на русском я стараюсь давать ссылки, переводов у меня нет.
По поводу СУТ - что выбрало начальство, тем и пользуемся... Начальство выбрало документы в ворде
Так что их надо грамотно трассировать, тогда все вполне нормально. Вообще - инструмент это не главное, надо понять что происходит и как сделать происходящее лучше. Некоторым вполне хватает екселек, например.В свое время смотрел реквизит - он не подходит при работе с внешним заказчиком, который безбожно правит документы.
117
ПО Аналитика / Re: Первые шаги аналитика. ПО, книги, советы
« : 07 Февраля 2011, 20:28:36 »
посмотри у меня в блоге (ссылка снизу), по крайне мере по названию беспатных нагуглишь
118
О Сайте и Форуме / Re: Правила работы на форуме uml2.ru
« : 05 Февраля 2011, 23:49:35 »
да, я тоже пару раз мучался.. Спасибо!
119
Обучение / Re: ReqLabs 2011 Киев
« : 03 Февраля 2011, 23:39:06 »
ну круглый стол это не так критично.. Доклад про тестирование требований или театр начинается с вешалки я уже слушал в позапрошлом году Или он был одноименным. Конечно, если бы было в Москве, то я бы пошёл, а вот с Киевом думаю..
А доклады уже все расхватали - бесплатно не удастся, я поздно спохватился...
Или он был одноименным. Конечно, если бы было в Москве, то я бы пошёл, а вот с Киевом думаю.. А доклады уже все расхватали - бесплатно не удастся, я поздно спохватился...
120
Обучение / ReqLabs 2011 Киев
« : 03 Февраля 2011, 00:04:10 »
Добрго времени суток!
Никто пока поездку в Киев не планировал? И бюджет не считал?
Планирую приехать к пятнице, потом до воскресенья погулять по Киеву и в Москву..
Поездка на поезде самый дешевый сидячий вариант примерно 900 р в одну сторону вроде как (смотрел по осени + всё равно я в нем спать не могу), само участие 7200р, наверное ещё тысяч 7-10 на все про всё (гостиница+еда+экскурсия какая по городу)... Но я ни разу не был на Украине и порядок цен не знаю.
Никто пока поездку в Киев не планировал? И бюджет не считал?
Планирую приехать к пятнице, потом до воскресенья погулять по Киеву и в Москву..
Поездка на поезде самый дешевый сидячий вариант примерно 900 р в одну сторону вроде как (смотрел по осени + всё равно я в нем спать не могу), само участие 7200р, наверное ещё тысяч 7-10 на все про всё (гостиница+еда+экскурсия какая по городу)... Но я ни разу не был на Украине и порядок цен не знаю.