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

×


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

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


Сообщения - Denis Beskov

1621
Это диаграмма компонентов - http://www.intuit.ru/department/pl/umlbasics/12/

Только вы не правы в том, что это будет ВСЯ архитектура ИС.

По современным представлениям архитектура многоаспектна и отображается в виде 4 + 1 видов архитектурных представлений (4 + 1 View Architecture) в самом простом случае (для архитектуры ПО):


То, о чём говорите вы - взаимосвязь программных модулей - это Implementation View, представление реализации, представление уровня разработки. См. http://www.intuit.ru/department/itmngt/entarc/9/3.html

Есть также другие фреймворки, имеющие большую область охвата, например:
  • Архитектура бизнеса
  • Информационная архитектура
  • Архитектура приложений
  • Технологическая архитектура
, такие как
  • DODAF
  • MODAF
  • TOGAF
  • Zachman framework
  • Federal Enterprise Architecture
  • RM-ODP

Подробнее см.: http://www.intuit.ru/department/itmngt/entarc/

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

Имеет ли смысл говорить о типах вариантов использования?
Обычно говорят не о типах, а об уровнях.

Цитировать
По крайней мере, различают ВИ уровня бизнеса и уровня системы или системные варианты использования.

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

Т.е. если клиент-покупатель идет в магазин, то с его позиции бизнес-система магазин должна Продать нужный ему товар (цель клиента купить что-то, а задача системы продать это что-то). Или клиент банка желает получить кредит в банке, это означает, что с его точки зрения банк как бизнес-система должна ПРЕДОСТАВИТЬ кредит. Надеюсь я правильно расставляю акценты? То есть если описывать ДВИ этого уровня, то варианты использования должны формулироваться с позиции того, что бизнес-система должна (или что ожидает клиент) сделать для внешней сущности.
Да, всё так. Только не сущности, а агента. Сущность не имеет интересов, даже наведённых (как прочие системы).

Цитировать
Если затем мы рассматриваем варианты использования системного уровня (подразумевая в этом случае систему автоматизации некоторой деятельности), то они также должны формулироваться в терминах того, что данная система автоматизации должна делать для уже пользователя системы автоматизации.

Т.е. если клиент желает КУПИТЬ товар, то  магазин должен ПРОДАТЬ его, а система учета продаж должна ЗАРЕГИСТРИРОВАТЬ продажу. Возможно вариант использования уровня бизнеса может реализовываться, обеспечиваться набором вариантов использования системного уровня (имея в виду систему автоматизации).

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

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

Цитировать
Можно ли сказать, что задачи бизнес-системы, которые мы предполагаем автоматизировать есть features системы автоматизации или все-таки это уже системные варианты использования, т.е. задачи системы автоматизации?

Для усиления момента рассмотрим такой пример.

Цель клиента снять номер гостиницы. Задача гостиницы  этом случае предоставить номер или обслужить клиента. Если мы пытаемся автоматизировать этот процесс, то варианты системного уровня могут быть: осуществить поиск свободных номеров, зарегистрировать заказ номера, вести учет оказываемых услуг, произвести расчет клиента?
Ты сам всё показал, а если бы показал детальнее, было бы ещё понятнее. Почему ты не позаимствуешь структурированный стиль изложения у Boatman'а?

Отношение между фичами и пользовательскими задачами в общем случае - многие-ко-многим.
Фича может звучать как "Управление заказами", "Управление ЖЦ заказов", а пользовательская задача - "Зарегистрировать заказ". Кстати, формулировка "Осуществить поиск" у тебя не правильная, не целевая. Ну осуществил я поиск, цель достигнута? Не факт. И таким образом, формулировка фичи и пользовательской задачи в общем случае не совпадает, даже если соответствует 1-к-1.

1623
Возможно, речь всё-таки идёт о Use Case Driven Object Modeling with UML: Theory and Practice, которая есть на pdfchm.com, авторы Розенберг и СТИВЕНС

1624
Это ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ (ТЭО)
Только без технической части, как пишет та же википедия.

1625
Работа / Re: Начало карьеры
« : 24 Января 2008, 23:40:42 »
что по-вашему нужно, чтобы с большей вероятностью стать полноценным архитектором?
Получить соответствующее техническое образование и пройти путь разработчика.

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

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

1626
RUP EUP AUP OpenUP / Re: Как Agile вытесняет RUP
« : 23 Января 2008, 15:34:33 »
Обращает на себя внимание, что "Agile вытесняет RUP", прежде всего, в Индии. По остальным странам картинка, мягко говоря, другая.
Я также посмотрел данные только по США http://www.google.com/trends?q=RUP%2C+Agile&ctab=0&geo=US&date=all&sort=0
на мой взгляд, очень похоже.

По другим странам статистика в чистом виде не выдаётся. Вы о чём тогда?

1627
RUP EUP AUP OpenUP / Re: Как Agile вытесняет RUP
« : 23 Января 2008, 13:43:41 »
Это объясняет соотношение, но не динамику графиков.

1628
Работа / Re: Начало карьеры
« : 23 Января 2008, 02:01:55 »
Вообще, для того чтобы устроиться помощником аналитика, сейчас нужно не так много:
  • базовое образование не менее 4-го курса вуза в области бизнес-информатики, ИТ, на худой конец - маркетинга с опытом в программировании
  • хороший русский язык
  • коммуникабельность
  • представление о ЖЦ ПО/ИС, функциональном/объектном моделировании
  • устойчивый интерес к работе аналитика

Отдельный вопрос - как выбрать место работы, чтобы действительно получить развитие.

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

1629
Москва, м. Охотный Ряд/Тверская/Чеховская, Столешников переулок, за памятником Долгорукому, напротив мэрии.

Буду рад пообщаться с соседями в обеденное время.

1630
Боцман букву пропустил.

1631
Место тестирования в процессе разработки ПО - центральное. Мы должны быть ответственны за качество поставляемого продукта.
Странно, "Му-му" Тургенев написал, а мы анализ и проектирование обсуждаем.

1632
Ща в моде модульное тестирование. Читал пару статей про него и често ничего не понял - что такое и с чем едят.
Саша, с тобой всё в порядке? Я конечно понимаю, что у тебя, как и у меня, образование не чисто программерское, но то, что ты говоришь - ужасно.

Цитировать
Вернее что-то понял, но понял явно не все, т.к. кажется, что оно очень тяжеловесное и не применимо во всех случаях.
Дайте плиз хорошие ссылки на статейки, желательно с примерами.
Неофитские провокации надо разводить из-под неофитских эккаунтов :-)

Цитировать
И еще хотелось бы сравнить Модульное вс Автоматизированное тестирование.
Первое название - о том, что тестировать, второе - как.

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

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

Итак, напоминаю, что для того, чтобы осуществлять собственно проектирование системы, необходимо получить:
1. Модель предметной области (структура, процессы, переходы состояний).
2. Требования (функциональные и нефункциональные).

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

1634
А у кого есть книга в электронном виде?
Эд, ты не поверишь - у Гугла.

1635
В тему - глава "О пользе чертежей" из нового курса "Визуальное моделирование: теория и практика": http://www.intuit.ru/department/se/vismodtp/1/