136

Вакансии / Re: Москва, Системный аналитик (мобильные проекты)

« : 11 Февраля 2014, 11:06:43 »

"скрупулезный" и "ТЗ за 1 день".... хм... да еще и с "противным" клиентом.... хм хм.... хотел бы я на это посмотреть:)

137

Для всех / Re: Разработка ИС для строительной компании.

« : 29 Января 2014, 09:52:29 »

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

Добрый день!
Если речь идет об оптимизации бизнес-процессов, значит какие-то процессы уже есть, но чем-то они не устраивают.
Для начала надо сделать описание процессов "as is", как они выглядят сейчас. А потом уже думать как и где их оптимизировать.

138

Примеры / Re: Полный комплект UML диаграмм

« : 27 Января 2014, 14:17:58 »

Маленький оффтоп.
Жизненный опыт подсказывает, что порядка 2/3 личного состава команд разработки (от тестировщика до руководителя проекта) именно этим и занимаются.

Печально, если так!
Хорошо, я уточню формулировку:)
Никто не заказывает коммерческое ПО просто так, ради опыта или использования крутых технологий.

139

Тестирование / Re: Проверка алгоритма программистом

« : 27 Января 2014, 11:19:33 »

Системный аналитик заведомо считает, что ему сдается качественный код...

Без обид, но по моему это допущение граничащее с наивностью:)
В любом сдаваемом коде заведомо есть ошибки, если это не программа уровня "Hello world!"
Если отталкиваться от такого допущения, то все сразу встанет на свои места. Т.к. тестировщика нет, то кроме как вам, разработчику некому сдавать свой код с ошибками:)

По хорошему, конечно, когда не тестировщика, лучше работать по TDD, но сам я не знаю российских компаний где эта практика хорошо развита, по этому это скорее пожелание чем совет:)

140

Примеры / Re: Полный комплект UML диаграмм

« : 27 Января 2014, 10:57:35 »

Хм. Вот эти "документы" мне бы и разработать. Только с Ваших слов мне не совсем ясно как и что именно входит в каждый.
Говоря о слонах... До начала обсуждения на этом форуме я его и видел. А теперь передо мной стадо слонов. И каждого надо есть по частям... 

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

Ясно. Буквоедство плохо. Понимание реалий, живых тенденций хорошо.

Воистину так!

С какой стороны начать?... Вот в программировании, условно скажем, в начале изучаются лексические основы языке, далее структуры обработки информации (линия, ветвление, цикл) и т.д. Вот что мне именно отрезать у слона и съесть первым?

Теперь о главном.
Вот картинка из книги Вигерса, которую я стащил откуда-то. Ей сто лет в обед, но она не теряет актуальности.


1. Функционал всегда отталкивается от бизнеса. Никто не разрабатывает коммерческое ПО просто так, ради опыта или использования крутых технологий.
2. Самое первое - надо понять что будет делать ПО. Т.е. какую глобальную бизнес-потребность оно будет удовлетворять.
3. Как раз эти бизнес-требования и записываются в видение проекта в документ "об образе и границах проекта".
4. Когда такой документ создан, следующий шаг - определение функционала, который удовлетворит бизнес-цель.
5. Для того чтобы определить весь нужный функционал, надо общаться с заинтересованными лицами. Можно использовать например диаграмму вариантов использования из UML. А можно и не использовать:)
6. Когда функционал определен, он разбивается на задачи. Под каждую задачу пишется ТЗ. Разработчики разрабатывают, тестеры тестируют. Дальше уже дело техники.

И последнее. То что сейчас нужно - просто влезть в дело с головой. Как только начнешь делать что-то на практике, появится прогресс, появятся конкретные вопросы по конкретным процессам. Пойдет дело:)

141

Примеры / Re: Полный комплект UML диаграмм

« : 24 Января 2014, 16:51:42 »

Может я и заблуждаюсь. 
Тогда какая альтернатива? Не именно UML, а вообще для упрощения разработки "большого" проекта.

Как говорится, слона надо есть по частям.
Ключ к успеху крупного проекта - грамотная декомпозиция задач.
Сначала делается общее видение проекта (аналитиком или ПМом), в котором охвачены все границы проекта. Этот документ - охватывает весь проект.
В нем упор идет на бизнес-цель и бизнес-процессы. Видение как раз подходящий документ для красивых и больших картинок, которые так любят руководители:)

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

Правда это все к аналитике имеет весьма опосредованное отношение:)

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

142

Примеры / Re: Полный комплект UML диаграмм

« : 24 Января 2014, 15:19:55 »

Без UML он будет долгим, сложным для понимания извне (сторонними людьми, новыми членами команды), а со временем возможно и изнутри (собственно самой командой).
Потеряет целостную структуру, единое видение.
Проблему наглядности в основном - чтобы можно было легко понять в каком именно блоке следует искать недочёт, в какой именно блок правильнее сделать дополнение и т.д.

Добрый день!
Мне кажется в этом моменте самое главное заблуждение.
С чего вы взяли что с UML он станет проще для понимания? Для этого необходимо, чтобы все ( все кто участвует в проекте) знали UML  не хуже вас. Подумайте сами, так ли это?

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

Ну и само собой картинки и диаграммы - это не самоцель. Без грамотного сопроводительного текста - они бесполезны.

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

143

Системный Анализ и Требования / Re: Cценарии версионирования/бейсланирования документов требований

« : 15 Января 2014, 13:09:30 »

Для документов которые читает заказчик используем SVN.
Сделал версию -> коммит -> заказчику.
Этап согласования прошел -> коммит -> заказчику.

Для внутренней переписки добавляем циферку в конце документа, т.е. _1, _2 и т.д.

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

144

Проектирование / Re: Archimate: примеры использования

« : 13 Января 2014, 15:58:20 »

Большинство предпочитает вообще с этим не связываться

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

145

Примеры / Re: Нужна помощь, срочно

« : 19 Декабря 2013, 15:49:30 »

Ах, какой я молодец!

146

Примеры / Re: Нужна помощь, срочно

« : 18 Декабря 2013, 16:58:25 »

Добрый день!
Если Вам так нужна помощь сообщества, то попробуйте сделать сами хоть одну диаграмму. К счастью они любезно перечислены в конце задания, так что можно прямо открывать википедию по названию диаграммы и делать.
Потом выложите ее тут.  Затем и обсудим:)

147

Примеры / Re: СКУД в школе

« : 25 Ноября 2013, 10:57:42 »

Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?

А вот это как раз совершенно не важно, почему доступ не получен.
А вдруг клиент приложил к считывателю ботинок, а не карту? Это совершенно лишняя, мусорная, информация, которая усложнит восприятие.
и отображаться она не должна, т.к. сам ВИ "use swipe card" уже предполагает что клиент приложил нужную карту.
Что клиент прикладывал к ридеру до этого (проездной от метро или ботинок) не имеет значения, т.к. НЕ на карту ридер не сработает.

148

Примеры / Re: СКУД в школе

« : 20 Ноября 2013, 09:58:58 »

Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.

Конечно зря:)
Судя по постановке задания, отчеты отправляются в какие-то там другие отделы. Их анализ не происходит в рассматриваемой системе, так что и юз кейс "Analyze report data" и эктор "Analyst" лишние.
Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"

149

Задачи студентов / Re: Вариант использования Создать меню

« : 15 Ноября 2013, 09:09:21 »

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

Я бы в ВИ написал не
"1. Менеджер меню делает запрос на создание меню на определенную дату."
а
"1. Менеджер меню делает запрос на создание меню на определенную дату в пределах допустимых дат."
и все, потоки 10.1 и 10.2 уже не нужны:)

Мне сказали, что реализовано полностью согласно описанию ВИ.

ВИ писал один человек, а реализовывал другой?

И еще вопрос по пункту 5. Там речь идет о типе меню всего меню, или о типе меню в котором находится блюдо выбранной категории?
Если не уточнить этот вопрос, может показаться, что есть два вида "типов меню", один тип меню у каждого блюда, и один тип меню у всего меню, в которые входят блюда, каждое со своим типом меню:)
Зачем вообще все так переусложнять с типами меню? Это было озвучено в задаче или так решил создатель ВИ?

150

Примеры / Re: СКУД в школе

« : 14 Ноября 2013, 15:02:59 »

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