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

×


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

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


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

2086
Публикую презентацию к семинару в форматах PowerPoint и OpenOffice Impress.

2087
в словарной статье ничего про "неделимость" не вижу в упор. Целостность, полноту - да. См. слово "entirety". "Целостность, законченность, полнота"  - в смысле не нужно больше ничего добавлять, а не то, что нельзя делить на части. Нельзя делить на части - это элементарность.

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

2088
Сейчас будет жесточайшая :)

Почему статья в разделе по UML, а не в требованиях?

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

Зря не приведены исходные английские термины, например, я не уверен, что именно вы имели в виду под "пользовательскими сценариями".

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

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

Более нормативным в английском языке является раздельное написание термина Use Case.

Кстати, издательство "Питер" название книги Локвуд и Константайна настолько жульнически перевело, что имхо его надо непрестанно сопровождать оригиналом.

С вашим с bas'ом и Эдуардовским определением прецедента как "неделимой последовательности..." не согласен категорически. Если в сценарии ясно различимы отдельные шаги, то термин "неделимый" здесь неуместен.

Разделение сценария на 2 дорожки по Вирфс-Брок я бы не стал называть "методологией". На диаграмме деятельности стоило эти 2 дорожки показать, если уж она идёт сразу после Вирфс-Брок.

Ничего не понял про "исходный вид вариантов использования". Исходный - это который?

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

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

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

2089
"Почему не предлагают" - боюсь, этого пообещать не могу. Предположим, наука и промышленность не смогли до определённого момента предложить нечто недорогое и безопасное, позволяющее людям передвигаться с помощью мускульной тяги со скоростью от 10 до 30 км/ч. И тут некто изобретает велосипед. Так вот акцент внимания изобретателя будет на:
а) как оно работает в принципе
б) как заставить его работать
в) как его использовать, чему оно может помочь
г) какие границы применимости у изобретения
д) какие недостатки

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

Про то, каким оно должно быть я в основном и буду показывать и рассказывать :)

2091
29 марта, в 7 часов вечера
UML2.ru при поддержке компании Luxoft проводит семинар на тему

"Разработка требований и состава работ - Холистический подход"

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

Традиционные и достаточно современные подходы к определению требований к системе и состава работ, изложенные в BABOK, PMBOK, SWEBOK и специализированной литературе (Вигерс, Коберн, Лефингвел), несмотря не свои очевидные достижения, не предлагают метода формирования целостного и взаимоувязанного представления о создаваемой системе, и следовательно, требований к её внешним и внутренним свойствам, а также работ, необходимых для её создания, и, что исключительно важно, эффективной эксплуатации.

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

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

Чтобы попасть на семинар, пришлите свои ФИО на rq_workshop (o) beskov.ru

Адрес проведения семинара: метро Октябрьское Поле, 1-й волоколамский проезд, д.10 строение 3

Путь от метро: первый вагон из центра, выход по подземному переходу направо, потом сразу налево, далее проходите около 50 метров вперед на остановку 105 и 800. Вам необходимы автобусы NN 105, 800, следующие до остановки "1-й Волоколамские проезд". Автобус останавливается напротив первой проходной.

Либо пешком от метро, идти минут 10.

2092
Интересно, аренда ПО будет популярна?
А что именно ты имеешь в виду под арендой?
Software Leasing
Application Service Providing
Software as a Service
Software On Demand
?

Последние построены на телекоммуникациях, когда клиент и сервер разделены - примеры этого все я думаю видели - Хостеры CMS, Zoho.com, MS Office Live и т.д.

CASE, IDE и ALM вообще требуют определённой инфраструктуры, которой в вебе пока нет, хотя переход на HTTP-протоколы и XML способствует их интеграции в веб.

2093
Консалтинг и Внедрение / Re: ERP обзор
« : 22 Марта 2007, 19:32:45 »
Я кое-что сварганил: http://cybrarian.dabbledb.com/publish/erp

2094
Понятно.
Будем ждать выпуска очередной версии.
Что-то у них там с английским не ахти :)

2095
Эдуард, ты ещё забыл, что в ряде вузов "Программная инженерия" уже читается как отдельная дисциплина, ране читалось как "Технология программирования". Не смотрел только, насколько это вписывается в ГОСы - может, как региональный компонент?
http://www.csin.ru/curricula/se

По поводу сравнения проблем на западе и в России см. SE2004:
http://old.osp.ru/os/2006/10/064.htm

2096
Опубликовал 1-ю часть отчёта о семинаре - пока только формулировка кейса + краткие рекомендации.

Развернуть, почему именно такие рекомендации, как и на что они должны повлиять - пока не удалось :)

2097
Насчет логики приложения на клиенте. Если следовать классической архитектуре клиент-сервер, тогда на стороне клиента обычно размещают  средства представления, логику представления, бизнес-логику, логику управления данными.
Из классического определения "Клиент-сервер", да из самих терминов следует, что "клиент" - это тот, кто запрашивает и воспольуется результатами, а сервер - кто выполняет запрошенную задачу (обработка, сохранение, whatever). В тех же Оракловых технологиях традиционной реализацией такой архитектуры например, для банковских систем, является помещение бизнес-логики и логики приложения на сервер БД, тесно интегрируя их с БД, тебе Саша подтвердит.

Тему можно перенести в соотв. раздел.

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

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

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

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

2099
Денис, а что бизнес-логику разве нельзя внедрять в БД? Мне казалось, что довольно часто это делается: и через validation rules и через целостность, да сама метамодель чем не бизнес-логика, а триггеры, хранимые процедуры?
WikiPedia говорит:
Цитировать
Business logic comprises:
    * business rules that express business policy (such as channels, location, logistics, prices, and products); and
    * workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.
Т.е. состоит из бизнес-правил и потоков работ, с чем я вобщем согласен, если добавить процессы, события, состояния и семантические отношения. Бизнес-моделирование в IT - это структурная модель ПрОбл+Бизнес-Логика, если первую можно более или менее удачно положить в РБД, то вторую - далеко не всегда.
Цитировать
В твоих словах просматривается такой тезис БД - просто средства хранения фактов? Т.е. правила их формирующие,  ограничение целостности и другое - все это что-то другое?
Целостность конечно является частью бизнес-логики, только к сожалению в большинстве случаев её слишком мало, т.к. бизнес-правила нетривиальны. Если в данном конкретном приложении хватало бы "базовой бизнес-логики", то никто бы про PL/SQL не заикался.

Твоей фразы про "скриптовый язык PL" не понял. PL/SQL - это компилируемый язык. Его можно использовать в интерактивном режиме, но это имеет смысл только для задач администрирования, но не работающих кусков приложения.

Опять же "логика приложения скорее на клиенте" не понял, сейчас обычно логикой приложений занимается сервисный слой, см. Фаулера. Что такое "метамодель" тоже не понял.

2100
Ну Вы батенька ту не правы - читал я его. Да, не применял, т.к. задач таких не было.

И считаю, что практически все можно реализовать на РБД, и оптимально, а если что-то нельзя, то скорее Вы проектировщик хреновый ...
Саша, объектный PL/SQL - это про реализацию бизнес-логики и логику приложения - при чём тут БД?