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

×


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

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


Сообщения - SALar

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
46
Там отличная атмосфера, тихо, прекрасный чай. Да и тема вроде неплохая.
Регистрация нужна, чтобы понимать, какой столик нам понадобится: https://sergey-martynenko.timepad.ru/event/manage/440493/

PS. Там ходят в носках.

47
Помучал препода, сказала что 1 и 2  ;D Спасибо за ответы!
IMHO. Самых важных в тесте нет. Читайте Деминга.

48
Sparx / Re: Нужны примеры описания API в UML
« : 31 Декабря 2016, 15:42:59 »
Всем доброго дня .. интересует вопрос, как выполнить описание API в UML .. есть некий ресурс .. который предоставляет набор инструментария по определенным внешним запросам .. задача описать эти запросы ... в UML
1. Часто используют диаграмму последовательности + еще какой-то вариант (json, XML, табличный метод) описания запроса /ответа.
2. Зачем вам EA?! На начальном этапе "ставят руку". Инструмент выбирать можно будет лет через 5. Попробуйте https://www.draw.io/ На начальном этапе более чем достаточно. Есть плагин для конфлюенса.


49
На эту тему я делал доклады на конфетке, SQADays 15 и 18 и т.д. Со временем я понял, что материал сложный и та концентрированная подача, которую я делал не подходит для широкой аудитории. Особенно высока концентрация была на конфетке.
Но я продолжил работать  с этим материалом. Сильно упростил подачу, добавил вводный материал и работу с аудиторией.
 
Тренинг построен как семинар. Включает работу у доски, теоретический материал, групповую работу аудитории, игры и т.д. Время тренинга увеличено. Также за счет подводящего материала кардинальна уменьшена сложность восприятия, при сохранении глубины.
Отзыв одного из участников (не тестировщика):
Цитировать
Для меня Ваш семинар был полезен, я действительно узнал и запомнил для себя новое. Приятно, что будучи не тестировщиком, я понимал и даже знал некоторые участки материала. Большое Вам спасибо!

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

Тренинг пройдет в антикафе Кочерга (Москва), месте встречи рационалистов. Это место само по себе интересно.
 
Если Вы планировали начать осваивать планирование тестирования, не откладывайте это в долгий ящик.
 
Посмотреть описание и программу тренинга
 
PS. На тренинге отдельно рассмотрим почему и как опытный аналитик может использовать стратегию "Синдром стажера" http://blog.shumoos.com/archives/326 , для выявления требований, которые очень сложно выявить иными способами.

50
Кстати. "Сказка на ночь" про экспертов: http://u-96.livejournal.com/2507992.html

51
Вот тут я всеми руками против. Это как начинать знакомство с человеком с результатов его аутопсии, причем без медицинского образования.

Там же "боди оф ноледж", без интерфейсов для его понимания. Интерфейсы должен иметь читающий, и достаточно развитые для правильного понимания прочитанного.

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

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

Если хотите изображать из себя бизнес аналитика - может быть BABoK и подойдет.
А вот если хотите быть им, то читать - это просто терять время. С тем же успехом можно читать Карнеги или "Ментальные ловушки" Куклы. В книге по ссылке нет ничего о бизнес анализе. Или почти ничего.

Что читать: "Управленческие дилеммы", "ГОСТ Р 50779.42-99 Основы контрольных карт Шухарта", "Цель" и прочие книги Голдратта, "Пространство доктора Деминга". И в довесок работы Щедровицкого, lesswrong.ru и еще кучу книг.

PS. Во вложении небольшой список литературы. Был бы крайне признателен, если бы кто-то взялся его дополнить.

52
Новая версия да нужно создавать, как вариант. Новая версия - это результат сопоставлений должна быть наверное. Т.к. поступает разного (и неполного) объема информация с разных объектов. Пример:

С сервера №2 поступает  на сервер №1 сведения:
ООО Маяк
Количество сотрудников: 690
Дата получения информации: 10.10.2016

С сервера №3 поступает на сервер №1 сведения:
ООО Маяк
Месторасположение: Россия
Дата получения информации: 11.10.2016

С сервера №4 поступает на сервер №1 сведения:
ООО Муяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек
Дата получения информации: 10.10.2016

В итоге на сервере должно быть запись (результат сопоставлений и т.д.):
ООО Маяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек

Накапливать изменения можно примерно в такую базу:

ID обьекта
ID атрибута обьекта
Значение атрибута
ID источника (Номер сервера)
DateStamp (время изменения)
Нет, нет и нет. Коллеги, не изобретайте велосипед. Просто делайте, как написано в книге.

В итоге на сервере должно быть не менее трех записей. Примерно так:
ЧисленностьместоположениеКоординатыStartDateEndDate
69010.10.2016 11:12:4311.10.2016 05:17:55
690Россия11.10.2016 05:17:5612.10.2016 08:19:55
12.10.2016 08:19:56
01.01.2200 00:00:00

Таблицы на форуме глючат, смотрите книгу.
Есть ли она на русском - мне про то ничего неизвестно.

53

Проблема: При получении из другого сервера данные по умолчанию сливаются в БД (т.е. происходит замена существующих данных на поступившую). Но если сервер не найдет присланные данные об объекте в текущем сервере создаст новый объект (возможно будет дубль данных)

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

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

Но если понял, то она решена и описана много-много лет назад. К сожалению, об этой книге почти никто не знает. Книга: "Developing Time-Oriented Database Applications in SQL" от дремучего 2000 года. На хабре утверждают, что сейчас она раздается бесплатно. https://habrahabr.ru/post/191312/

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

55
Я писал варианты такого документа. А еще посмотрите http://www.trackstudio.ru/ В системе очень неплохо реализована возможность настройки прав доступа. На сайте есть несколько статей и пример ТЗ на настройку.

56
Сейчас это все делается в Excel.
Но может быть есть какое-то более удобное ПО для этого?

Ну и еще попутный вопрос:
как правильно называется роль человека в проекте, который выполняет такую работу?
Excel для этого очень удобен. И ничего другого не надо.

А еще. Купите, займите, украдите... убейте, если придется, но достаньте книгу "Сколько стоит программный проект" Стив Макконнелл http://www.ozon.ru/context/detail/id/3115179/

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

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

58
Не хотите быть уволенным - не занимайтесь выявлением бизнес целей.

59
Не могу согласиться.
Для какого-нибудь тяп-ляп проекта, где "и так сойдет", может быть и подойдут люди, умеющие всё понемногу.
Однако, если говорить о серьезном enterprise, то успешно выполнять проекты можно только имея команду именно специалистов, т.к. требуется глубокая компетенция в каждом вопросе.
1. Очень сложно (почти невозможно) иметь "глубокую компетенцию" в конкретном вопросе, не имея смежных специальностей.

2.
Цитировать
Спорно, очень спорно. Она невыгодна в небольших коллективах, где нет возможности надежно закрыть участки узкими специалистами. Вот там да, там многорукие шивы в почете и на коне. Если же ресурса достаточно, как непосредственно производственного, так и управленческого, в качестве основных "производственных мощностей" лучше иметь узких специалистов.
Есть некоторые области, в которых не надо полагаться на здравый смысл и ощущения. К таковым, например,  относятся хирургия, изготовление взрывчатки и управление. По моим ощущениям тоже "как только объемы работ требуют от 5-ти человек - становится возможным принимать узких специалистов и загружать их по профилю", но...
Прорывным решением фирмы Тойота был отказ от узкой специализации и переход на кроссфункциональность для обычных трудяг. Если что, автомобильный гигант это немного больше 5 человек. Не изобретайте. Смотрите статистику.
 
"Каждый тестировщик должен уметь программировать."
А так же проектировать пользовательские интерфейсы и базы данных, писать спецификации требований и руководства пользователей, управлять звездолетом и менять пеленки. Специализация - удел насекомых.

60
Для полного счастья в обязанностях не хватает пункта вроде:
N. Отличное знание Java, разработка как новых систем, так и модулей к уже существующим...

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »