91

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 01 Марта 2016, 23:14:43 »

Я таки прошу посторонних вещей в форуме не писать под угрозой расстрела всякого товарища с лишением прав.

Пожалуйста, не переходите на личности и не опускайтесь до оскорблений.

92

Для всех / Re: Прошу покритиковать ТЗ (небольшое тестовое задание)

« : 10 Февраля 2016, 18:54:31 »

А автору топика крайне рекомендую пройти полный курс по проектированию АС и разработке ТЗ
http://saturs.ru/index.php?r=eduprograms/viewprogram/id/148

<<Вы слышите глухие удары: тук! тук! тук! Это бьется сердце космонавта, прибывшего на нашу планету. Внимание, внимание! Говорит доктор Шприц. Мой адрес: Холерная улица, дом пятнадцать. Прием больных ежедневно с девяти утра до шести вечера. Помощь на дому. Вызовы по телефону. Прием в ночные часы оплачивается в двойном размере. Вы слышите удары космического сердца. Имеется зубоврачебный кабинет...>>

93

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 09 Февраля 2016, 11:41:20 »

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

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

94

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 08 Февраля 2016, 23:29:36 »

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

95

Идеи и мозговой штурм / Re: Мотивация аналика

« : 05 Февраля 2016, 19:53:10 »

Вот мне интересно, почему это знаете Вы и не знают акционеры? Обязательно в компании идет волна внедрения kpi. Ни раз ничем не закончилась на моей практике. Но деньги вбухивают не хилые. 

Может быть, у акционеров другая точка зрения? Для сотрудников "ничем не закончилось", а у они по каким-то своим показателям решают, что хорошо закончилось.

96

Идеи и мозговой штурм / Re: Анализ и разработка или разработка и сопровождение.

« : 02 Февраля 2016, 14:28:38 »

Если отсутствие контакта с аналитиками - осознанная проблема, то её решать поначалу можно административно. Просто сделать обязательным участие аналитика в обработке запроса клиента. Это можно решить на уровне системы обработки запросов (у вас ведь есть такая?)


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

imho чем ближе документация к коду и чем меньше лишних движений должен совершать разработчик для её написания, тем больше шансов получить что-то полезное. Нужно либо разрабатывать какую-то технику встраивания документации в код (я пользовался javadoc / doxygen - сейчас для этого наверняка есть какие-то новые инструменты), либо вводить практику обязательных содержательных комментариев к коммиту при выкладывании кода. И реализовывать публикацию этих комментариев в ту систему, в которой ими будут пользоваться (например, wiki с продуманной структурой и хорошим поиском). В любом случае требуются энтузиасты и контролёры, само не взлетит.


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

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

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

97

Идеи и мозговой штурм / Re: Анализ и разработка или разработка и сопровождение.

« : 01 Февраля 2016, 17:37:26 »

Вижу слово "вопрос", но не нашёл ни одного вопросительного знака.
Универсального решения нет, конечно. Мне в предложенной схеме, например, непонятно, почему тестирование ушло в сопровождение.

У вас вообще какого рода клиенты (корпоративные? массовые пользователи?) и сколько их?

98

Вакансии / Re: Ищем инновации, идеи и аналитиков

« : 14 Января 2016, 14:32:48 »

Как известно успех зависит от новизны идеи.

Как известно, не зависит.

Наш инновационный подход можно прочитать по ссылке в виде питча

Гугл-транслейтом эту фразу переводили?

99

Варианты Использования (Use Case) / Re: Как отобразить на ВИ требования к вариантам развертывания?

« : 12 Января 2016, 18:06:19 »

Кстати, на счет пожарного датчика - все таки склоняюсь к тому, что окружающая среда в данном случае будет актором
По аналогии с обсуждаемым тут: http://www.uml2.ru/forum/index.php?topic=1082.0

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

С учётом всего написанного в дополнение.

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

Но быстро выяснилось, что на место людей можно поставить и другие системы, отчего стройная концепция модели ВИ начала немного размываться.

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

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

У базы данных теоретически может быть цель, если она рассматривается в роли клиента. Но в большинстве случаев ВИ, в которых БД назначена актором, просто неграмотно разработаны.
Я видел ВИ, в которых актором выступала банковская карта. Отвратительные ВИ, надо сказать - они ничего не добавляли к пониманию системы, а только всё запутывали.

Мне трудно представить себе "сеть" в роли актора. Возможно, вы вкладываете в это слово какой-то другой смысл. Какую цель может преследовать сеть по отношению к системе?
Нет цели - нет ВИ.
Есть цель - ищите того, кто её преследует.

100

Варианты Использования (Use Case) / Re: Как отобразить на ВИ требования к вариантам развертывания?

« : 11 Января 2016, 19:40:22 »

Впервые пишу ВИ, поэтому столкнулся с вопросом, с которым не могу справиться самостоятельно.
Система имеет в целом несколько вариантов развертывания (в т.ч. клиент-сервер). Требования к системе представляются целиком. Т.е. нет отдельного клиента, отдельного сервера и т.п. При этом сервер также является и клиентом.
Как представить в ВИ хотя бы данный вариант?
Как в виде актора будет выступать сеть? Банальное "актор: сеть, ВИ: передача данных", думаю, не самый удачный вариант.
Заранее спасибо за помощь!

Вы с помощью ВИ сценарии взаимодействия описываете? Можете привести пару примеров?

101

Для всех / Re: Создание гибкого ролевого доступа

« : 16 Декабря 2015, 12:57:46 »

В данный момент занимаюсь написанием документации по функционалу ролевого доступа в админке: есть менеджеры, их можно объединить в группы, создаются роли с установкой вручную галочек к чему будет доступ, а к чему нет. Возможен вариант установки "может если является членом группы".
Главный вопрос в том, как нарисовать диаграмму high-level flow для всего этого процесса, что она будет в себя включать. С диаграммами я на вы. Буду благодарна любой помощи.

Если оставить пока за скобками flow, а говорить об упомянутой здесь диаграмме вариантов использования, то в этом случае, на первый взгляд, видны варианты использования вроде таких: Создать роль, Настроить доступ для роли, Назначить роль пользователю (менеджеру?).
Не совсем понятно, чем роли отличаются от групп, но если отличаются, то для групп появляется свой набор вариантов использования (ВИ).

Кто будет выполнять все эти настройки? Если только админ, то у вас на диаграмме появляется единственный человечек - Администратор. Если в процессе настройки участвует кто-то ещё, то, как минимум, у них с администратором будет разный набор доступных ВИ (иначе нет смысла их разделять).

Документация для разработчиков: Functional Specification Document
Делаю по образцу компании, в которую недавно пришла. Самым первым пунктом во всех спеках у них идет схема под насванием High-level flow, которая в общем описывает функцию, для которой создана спека: создание какой-то сущности, к примеру или предоставление.

А от вас требуют делать только по такому образцу? Или вы сами решили, что это необходимо? В таких случаях лучше спросить у руководителя.

102

Для всех / Re: Создание гибкого ролевого доступа

« : 15 Декабря 2015, 19:42:28 »

Всем добрый день!
Возможно, кто-то подскажет, есть такой вопрос.
В данный момент занимаюсь написанием документации по функционалу ролевого доступа в админке: есть менеджеры, их можно объединить в группы, создаются роли с установкой вручную галочек к чему будет доступ, а к чему нет. Возможен вариант установки "может если является членом группы".
Главный вопрос в том, как нарисовать диаграмму high-level flow для всего этого процесса, что она будет в себя включать. С диаграммами я на вы. Буду благодарна любой помощи.

Это пользовательская документация или внутренняя?
Почему рисование диаграммы - это "главный вопрос"? И какой смысл вы вкладываете в слово "flow" (это слово обычно подразумевает описание какой-то последовательности действий)?

103

Примеры / Re: Нужна помощь в построении use case и class diagr за материальное вознаграждение

« : 02 Декабря 2015, 11:56:46 »

О, сезон хвостатых студентов открылся. Значит, скоро Новый год.

104

Для всех / Re: Выбор UML диаграммы

« : 12 Ноября 2015, 22:56:57 »

Но в данном конкретном случае я готов бодаться довольно долго.
Задача находится на уровне BPMN, ну или Activity-диаграммы UML. Там просто всё для этого есть.

Дуэль на картинках?
Просим топикстартера дать более подробное описание задачи и предлагаем варианты?

105

Для всех / Re: Выбор UML диаграммы

« : 12 Ноября 2015, 20:19:23 »

Кстати, в lucidchart можно на дорожки класть любые элементы - там это очень удобно сделано.