16

Варианты Использования (Use Case) / Re: Пользовательские Сценарии или как уйти о&

« : 18 Октября 2009, 12:37:57 »

По поводу нужности UC.

IMHO UC - это не просто артефакт, а способ мышления и работы. Они заставляют продумать и зафиксировать, что нужно actor'у, и как он будет это делать с помощью системы, а потом поделиться этим пониманием, и, как уже сказал Денис, строить и учитывать работу по UC. Это способ связать ответы на вопросы "зачем", "что" и "как". Вне зависимости от кол-ва actor'ов.

Наверное, если взаимодействие с пользователем - очень простое, а разработчики уже многократно делали подобные вещи "в лучшем виде" (и их, разработчиков, немного), то детально фиксировать взаимодействие с пользователем не обязательно, но вот цель этого взаимодействия - всё равно нужно. Тем более, что сложность взаимодействия с пользователем имеет свойство увеличиваться в следующих версиях. Пример - утилиты командной строки в unix/linux.

Про UC для MS Word: IMHO это ничего себе задача. Тех же actor'ов там много. Только из первичных - навскидку, оператор, VBA-программист, OLE. И целая серия вторичных, от clipart на узле MS до получателя электронной почты mail merge. И каждый раздел стандартного ribbon'а - это минимум один низкоуровневый UC, типа "настроить шрифт текста" или "CRUD таблицу".

17

Для всех / Re: Контроль доступа и учёт рабочего времени

« : 06 Октября 2009, 00:29:33 »

<...>
что дальше делать

Если это та система, в которой многофакторная аутентификация и электронные замки - то:

- если есть деньги и хотите хорошего быстрого результата - напишите, что можете, и запросите по написанному коммерческие предложения у пары-тройки крупных системных интеграторов, которые занимаются ИБ; они вам всё под ключ могут поставить, в т.ч. "лучшую практику" или какой-нибудь официальный стандарт

- если есть деньги и хотите много разного опыта - делайте, как сказал bas, затем нанимайте пару программистов, пару инженеров по системам ИБ, и вперёд; хотя, если честно, результат не гарантирован

- если денег нет - тогда, пожалуй, лучше и не браться, а нанять пару сторожей с  журналом прихода/ухода и ключами под расписку: автоматизированная ИБ - это не дёшево, да и перед начальством обосновать трудно, если до этого из офиса ничего ценного не своровали .

18

Примеры / Re: Система, регулирующая работу аквариума

« : 20 Сентября 2009, 17:48:08 »

Где цели и требования к системе? Аквариумистов опрашивали? А производителей и продавцов аквариумов и расходных материалов для них? А биологов-ихтиологов? А дизайнеров интерьеров? А форумы читали? Изучили ли рынок аквариумов и существующие на нём продукты? У вас есть свой аквариум?

Где границы системы? Вы хотите сделать контроллер домашнего аквариума, офисного, для зоомагазина или для океанариума в зоопарке? Простого, тропического или арктического? Глубоководного? Обслуживание роботизированное? Или универсальный обновляемый компьютеризированный контроллер для всего этого?

---

Динамику - варианты использования, границы и способы настройки, логику, алгоритмы, бизнес-правила работы - описали? Где я могу сказать: "у меня в аквариуме - 3 золотых рыбки, пиранья и два Dromia enythopus, задать оптимальные условия"? Где калибровка системы на аквариум?

---

Где стереотипы, паттерны, design mechanisms? Например, стратегии "ввод аквариума", "поддержка аквариума", "чистка аквариума"?

Свойства - не описаны. Методы - странные, названия не говорят об их предназначении.

Зачем Heater<<Boundary>>, Light<<Boundary>>, Pump<<Boundary>>, WaterLevelSensor<<Boundary>>, WaterTemperatureSensor<<Boundary>> "знать" об EnvironmentController<<Control>>?

Где Owner<<Entity>>, Fish<<Entity>>, Aquarium<<Entity>>?

Зачем выделять ButtonON и ButtonOFF?

Где кормушка? Где alarm, которая сообщит владельцу приятным женским голосом, что пора чистить, или что, например Heater и Pump не отключаются, и горячий суп из рыбок по $1k за штуку сейчас начнёт заливать его паркет из красного дерева, и продублирует это по email и по SMS?

---

Где Component и Deployment?

---

Даже - и особенно - учебные задачи требуют серьёзного подхода. Иначе не научитесь. А в целом - правильной дорогой идёте .

---

Из-за того, что архитекторы проектируют системы с точностью "что-то сделать в общих чертах как-то так, ОБЯЗАТЕЛЬНО, СРОК - ВЧЕРА!!!", кодерам приходится становится специалистами в предметной области и программистами экстра-класса .

19

Обсуждение статей / Re: Класс системного аналитика. Разработка п&

« : 20 Августа 2009, 12:05:31 »

Вот бы увидеть статистику по проектам, в которых преподаватель, дфмн Михаил Иванович Кумсков, участвовал как системный аналитик. Время проведения, объёмы (LOC, $$$), сроки (абсолютные, в % от первоначальных), прибыль и прибыльность, предметная область, краткие описания систем.

Потому что теория и знание инструментов - это замечательно, но чтобы сохранять актуальность своих знаний, нужно постоянно практиковаться. Я совершенно уверен, что Михаил Иванович сможет замечательно рассказать о том, как быть хорошим тренером и консультантом, но вот хочется не теоретических курсов, а "hands-on" по тому, как быть хорошим системным аналитиком.

20

Бизнес-анализ и Целеполагание / Re: [Подтема] Средства автоматизации для разработки регламентов

« : 19 Августа 2009, 13:09:41 »

Не работает у меня таким способом. Только по пакетам. Чтобы работать с элементами диаграммы я подключаю базу.

Очень странно, потому что я проверял, у меня работает.
1) у меня EA 7.5.844
2) я настроил template так (см. прикреплённую картинку)

21

Бизнес-анализ и Целеполагание / Re: [Подтема] Средства автоматизации для разработки регламентов

« : 18 Августа 2009, 17:17:16 »

Определяющее значение имеет однократное описание акторов и последовательное применение ОДНОКРАТНО описанных акторов на всех диаграммах.
Ну плюс еще десяток тонкостей

Про использование одного и того же элемента на нескольких диаграммах - да, можно, при перетаскивании нужно выбрать "as simple link".

Про построение отчётов не элементам в пакете, а по элементам на диаграмме - да, можно, Documentation->RTF Report->Edit Template, выбираете в дереве разделов Diagram, Element, Connector, Messages. Дальше набираете те поля, которые хотите видеть в разделах отчёта (напр. Name, Alias, Notes), сохраняете, запускаете отчёт - и вуаля.

Про десяток тонкостей - опишите, посмотрим, что можно сделать.

22

Системный Анализ и Требования / Re: Опрос: что такое системное мышление

« : 18 Августа 2009, 12:57:20 »

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

23

Системный Анализ и Требования / Re: Опрос: что важнее для системного аналитик

« : 18 Августа 2009, 12:40:16 »

Неужели в уставе так и будет написано для роли аналитика:
- отвечает за принятие решений о включении требований (в том числе и ключевых) в рамки проекта;

IMHO да. А кто же ещё в этом разбирается лучше аналитика?
Менеджер проекта разбирается в планах, оценках, отчётах, организации работы, ресурсах и человеческом факторе.
Менеджер продукта - в маркетинге (своём и конкурентов), отстройке, продающих факторах, PR, а также в заказчиках, фичах и сроках "с высоты птичьего полята".
Архитектор - в архитектуре.
Инвестор -  в том, сколько денег (человек, оборудования, места в офисе) на какой срок он готов дать и когда ему нужно эти деньги "отбить".

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

- отвечает за ключевые архитектурные решения.

Я бы сказал, что ответственность за архитектурные решения такая (по убыванию):
1) Архитектор - что система будет целостной, и будут обеспечены минимально возможные затраты на изучение, поддержку и расширение; он отвечает за доведение этой работы до результата
2) Системный аналитик - что с помощью этой архитектуры можно будет выполнить требования Заказчика, и что она будет соответствовать вариантам использования
3) Менеджер проекта - что переход к такой архитектуре и её использование не пойдёт в разрез со сроками и трудозатратами
4) Программисты - что они будут писать код, который соответствует этой архитектуре.

Получается, что вся ответственность проекта на аналитике... При этом всем в чем тогда ответственность руководителей проекта и архитекторов.

Аналитик - не единственный и не первый, кто отвечает за сроки и за деньги. Сроки и деньги - коллективная ответственность всей команды, но спрашивают за это с менеджера проекта.

24

Системный Анализ и Требования / Re: Требования и критерии приемки к творческ&

« : 16 Августа 2009, 02:02:56 »

К 3ем вариантам AlexTheRaven, можно еще добавить:
4. В Договоре прописать и на словах озвучить заказчику, что затраты на доработки по дизайну вы делите 50 на 50 с ним

Проблема, обычно, в том, что у заказчика и у исполнителя разные взгляды на то, что считать устранением дефекта, а что - доработкой. А брать за исправление выявленных дефектов деньги могут позволить себе только монополисты наподобие Microsoft или Oracle. Так что нужно это чётко описывать, что является дефектом, а что - нет. Например (упрощённо), дефект - отсутствие возможности получить доступ к размещённой на сайте информации в соответствии с утверждённым ТЗ (структурой, деревом навигации, функциональностью CMS).

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

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

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

IMHO, как совершенно верно подмечено, графический дизайн вещь субъективная, его качество и соответствие целевой аудитории трудно проверить (хотя в некоторых случаях можно привлекать для этого внешнюю комиссию или сообщество бета-тестеров). Графический дизайн - предмет доверия исполнителю, его репутации и портфолио. Его не следует описывать в ТЗ - получаются сплошные ошибки типа "удобный интерфейс" и "эстетичное сочетание цветов". Эскиз дизайна, в т.ч. стили и цветовую схему, нужно разрабатывать и утверждать отдельно от ТЗ. Может быть, хорошая идея - включить в договор пункт о том, что дизайн сайта в обязательном порядке должен стать первым скриншотом публичного портфолио исполнителя не менее чем на полгода с момента сдачи проекта.

25

Системный Анализ и Требования / Re: Требования и критерии приемки к творческим продуктам (например, дизайн сайта)

« : 13 Августа 2009, 19:19:28 »

Тут может быть 2 подхода:
1) закладывать предполагаемое время на доработку и согласование в цену, с запасом
2) если последующие этапы более прибыльны и покроют превышение трудозатрат на дизайн - списывать превышение на пресейл
3) определённый объём доработок гарантировать после сдачи проекта, в рамках тех. поддержки.

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

26

Системный Анализ и Требования / Re: Опрос: что важнее для системного аналитики

« : 12 Августа 2009, 15:48:23 »

Про картинку применительно к системному аналитику, я бы отдельно вывел
- умение вести "делопроизводство", связанное с требованиями
- умение обобщать потребности клиентов и возможности конкурентов.

27

Системный Анализ и Требования / Re: Опрос: что важнее для системного аналитик

« : 12 Августа 2009, 15:05:18 »

2Boatman

Я считаю, что с обязанностями и знаниями системного аналитика связаны все описанный мной пункты.

Заказчик по вопросам, связанным с доработкой и исправлением продукта, работает в первую очередь с аналитиком, а не PM'ом. Управление требованиями предусматривает второй (оценка) и третий (принятие решений) пункты, чтобы включать или не включать требования 1) в рамки продукта 2) в рамки конкретного релиза (+ влияние на сроки и т.д.). Даже если аналитик не может сделать это самостоятельно, а только совместно с PM'ом - устраняться от этого он IMHO не должен.

Требования связаны с архитектурой (в т.ч. её изменениями и ограничениями), когда принимается решение о требовании - часто принимается и архитектурное решение. Поэтому системный аналитик должен уметь принимать решения относительно архитектуры - опять же, не самостоятельно, а с архитектором, PM'ом и ведущими разработчиками, но должен.

А решение - это всегда риски и ответственность.

Да, многие PM'ы, архитекторы и разработчики страдают (или наслаждаются ) авторитаризмом. Но будучи вовлечёнными в исполнение и не владея в полной мере системным подходом (в т.ч. пониманием того, что нужно клиентам, преимуществ, рыночного окружения, в т.ч. элементарных истин, что продукт - это не только код, что он - один из инструментов решения проблем, что [вне ex-СССР] деньги берутся только от продажи нужных клиентам решений, и т.д.), они не всегда могут принимать правильные решения. К счастью, даже если сами они этого не понимают - это часто понимают их руководители, поэтому такая работа зачастую приветствуется ими.

28

Системный Анализ и Требования / Re: Опрос: что важнее для системного аналитик

« : 07 Августа 2009, 16:54:40 »

IMHO важно умение справляться с чужим "геморроем", связанным с
- сортировкой и упорядочиванием чужих турбулентных потоков сознания
- циничной оценкой стоимости разработки функциональности и принятием решений о её целесообразности, в т.ч. со словами "нет", "руки прочь от разработчиков", "пятилетки за 3 года не бывает", "нет денег и времени - нет доработки и исправления", "вопль СРОЧНО!!! не заменяет обоснования" и т.д.
- принятием решений, рисков и ответственности
- обсуждением и протоколированием принятых решений
- написанием, методничным согласованием со всеми интстанциями и доведением до разработчиков требований.

29

Системный Анализ и Требования / Re: Как подготовить детальные требования в с&

« : 07 Августа 2009, 13:49:05 »

<...>

Всё понятно, согласен, но как бы так сформулировать...

Когда описывают процессы "как есть" - их всё равно почти всегда описывают их "идеализированными". В них редко учитывают человеческий фактор и устранение вызванных этим фактором проблем. В частности - исправление и подпись документов "задним числом", отмена и повтроное выполнение проводок, "списывание" со cклада.

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

Если реализовать систему по таким "идеализированным" процессам, придётся потом (ещё раз) в авральном режиме делать для неё все мелкие "доработки" и "примочки", которые есть у старой системы.

Т.е. старая система - один из важнейших источников информации о бизнес-процессе и требованиях к новой системе. А из GUI не всегда можно понять алгоритм работы (в частности, способы расчёта, бизнес-правила) - старая система часто становится чёрным ящиком.

30

Системный Анализ и Требования / Re: Как подготовить детальные требования в с&

« : 06 Августа 2009, 19:30:23 »

См. обратная разработка (обратный инжиниринг, реверс-инжиниринг; англ. reverse engineering), начиная отсюда http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0.

Если коротко и упрощённо, то следует
1) тщательно описать бизнес-процессы, в которых задействована старая система
2) абстрагировать функциональность старой системы из деталей её реализации (да-да, больше неоткуда; придётся основательно изучить эту систему, в т.ч., возможно, "с изнанаки"; хорошо, если экстрактор ресурсов и дизассемблер в руки брать не придётся)
3) написать требования для новой системы на основе функциональности старой
4) разбить требования на этапы, спректировать точки интеграции
5) найти (вплоть до грязных хаков с чтением и записью ОЗУ старой системы во время её работы ) места, в которых со старой системой можно было бы интегрироваться при переносе.

Делать (2) нужно, если на старую систему нет актуальной документации (что чаще всего так и бывает).

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