2101

ПО Аналитика / Re: Платформа Эклипс. Генерация исходного кода по модели классов.

« : 19 Марта 2007, 18:53:15 »

Денис, просвяти ... PL/SQL таки объектный или объектно-ориентированный в полном смысле (с наследованием и полиморфизмом)?

Скажем так - с элементами объектов - есть инкапсуляция через методы, наследование, нет полиморфизма (или я плохо понял). См. книгу "Object-oriented Oracle": http://www.isbnonline.com/Object-Oriented-Oracle/book/9781591408109/

Ну есть там объектные фичи, но все это фигня по моему.

Выглядит как "я булгакова не читал, но считаю нужным заявить" Уж хотя бы на Кайта сослался, что-ли

Народ наверное хочет из ДК получить некую er-диаграмму, как это было сделано в Розе, а потом в код

Зачем ER? Из UML-диаграммы класса - код класса (TYPE) Oracle PL/SQL.

2102

ПО Аналитика / Re: Платформа Эклипс. Генерация исходного кода по модели классов.

« : 19 Марта 2007, 17:38:34 »

Задача: генерация кода на PL/SQL по модели классов (у классов помимо стандартных атрибутов также имеются свои собственные).

Задача интересная, я сам на такую сейчас смотрю, но пока особого смысла не вижу.

Подскажите есть ли софт способный по шаблоному языку генерить ЗАДАЧУ или же другим способом.

Не понятно, что имеется в виду под шаблонным языком.

Если нет то возможно ли написать собственную программу.

Принципиальная возможность есть всегда.

У вас есть некая приблуда для Еклипс, которая умеет рисовать ДК?

А у тебя что, нет? Ну так зайди, скачай

PL/SQL уже стал объектно-ориентированным (!) языком? Для работы с ним лучше использовать таки средства Oracle.

Да, и давно. Действительно, стоит посмотреть Oracle Designer - там наверняка уже всё есть.

2103

Конференции Семинары и Тренинги / 3-4 Апреля, МСК, Software Development Best Practices 2007

« : 19 Марта 2007, 14:20:09 »

3-4 апреля в Москве состоится конференция Software Development Best Practices Expo - http://www.sdexpo.ru/

На ней будут Брюс Экель, Бертран Мейер, Скотт Амблер, Алистер Коберн.

2104

Бизнес-анализ и Целеполагание / Re: Роль бизнес-аналитика

« : 18 Марта 2007, 20:34:59 »

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

Если ты, программист, хочешь всю жизнь заниматься исключительно техникой, то глубокие знания МЭ, законов развития общества и т.д. тебе в принципе не нужны, хотя если они будут - то это тебе поможет при каждом столкновении с бизнесом. А на самом деле столкновение происходит постоянно, т.к. если ты занимаешься не академическими работами, а работаешь на дядю, то есть определённая цепочка соответствия между задачами бизнеса и твоей работой. Один из главных тезисов в IT-бизнесе сегодня - необходимость понимания бизнеса IT-работниками.

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

Почему в России стоит учить людей широко, а не глубоко? Потому что:
а) рынок не устоялся, как на западе, где всё прозрачно распределено по специализациям,
б) вузы не могут угадывать, какая профессия будет более востребованной ближайшие 20 лет и постоянно перестраиваться. Это то, за что их постоянно ругают, но и недооценивают.

2105

Бизнес-анализ и Целеполагание / Re: Роль бизнес-аналитика

« : 18 Марта 2007, 20:23:04 »

... Возьмем методические указания Золотухиной ...

Несчитая тех опасных оплошностей, что она Business Use Case считает описанием бизнес-процесса, а Use-case - функции системы, её материал очень неплох.

Как мы видим процесс бизнес-моделирования включает как минимум три различные роли.

Вопрос кто делает эту работу? Сам заказчик? Фирма-разработчик? Или сторонний системный интегратор?

Я понимаю, что практика в России такова, что нам нужен специалист, который "коня на скаку остановит, в горящую избу войдет".

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

2106

Бизнес-анализ и Целеполагание / Re: Роль бизнес-аналитика

« : 18 Марта 2007, 19:55:15 »

Коллеги, давайте все-таки подискутируем и определимся окончательно, кто что и как понимает под понятием бизнес-анализ и бизнес-аналитик. Что это за роль , какое место она занимает, как соотносится с ИТ-проектами.

Ну, окончательно-то мы не определимся никогда, как и по поводу любого термина, всё-таки это не "треугольник", а более абстрактное понятие. Я пытался делать нечто подобное для СА: раз, два, с теми же ощибками неуказания контекста.

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

Опыта в чём? Если в поиске же путей решения проблем бизнеса, то это замкнутый круг - бизнес-аналитик не может быть бизнес-аналитиком, пока он не бизнес-аналитик.

Я очень сомневаюсь, что выпускник скажем кафедры САПР, ИС или иной "программисткой" кафедры, может стать бизнес-аналитиком.

Что значит "может-не может"? Захочет, жизнь заставит - сможет. Давай ещё скажем, что выпускник театрального училища не может стать президентом.

Вот даже среди форумчан, кто в своем послужном списке имеет такую красивую профессию как бизнес-аналитик имеет первичное или вторичное образование юриста, экономиста и т.п.

Конечно, в БА проще идти (и берут), изучив бизнес, чем системы. Но если твоё знание систем фундаментально, и ограничивается не только ИС, то можно и системному аналитику идти в бизнес, т.к. бизнес - это разновидность систем.

Давайте посморим еще раз, что пишет RUP. Возьмем методические указания Золотухиной.

Логика изумительная Что, Золотухина - представитель RUP'а на земле? "Давайте посмотрим ещё раз, что говорит Маркс. Итак, открываем Ленина...". Ты анализировал, насколько её текст соответствует настоящему РУПу?

2107

Консалтинг и Внедрение / Re: ERP обзор

« : 17 Марта 2007, 16:03:29 »

Keen_G, было бы очень здорово, если бы ты опубликовал эти обзоры в структурированном виде как открытую онлайновую базу данных на DabbleDB. http://dabbledb.com/commons/

Причём с исключением рекламы, желательно.

2108

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

« : 17 Марта 2007, 15:35:28 »

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

Обеспечивающих что?

Среди обеспечивающих подсистем обычно выделяют информационное, техническое, математическое, программное, организационное и правовое обеспечение

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

Читай основы информационных систем.

А такие есть? Дай пожалуйста ссылки.

Нужно или нет любой ИС каждое из обеспечений вопрос, конечно, спорный.

А я о чём? Нужна методика определения того, какие обеспечения нужны, а какие нет.

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

Кстати, ГОСТ, описывающий виды обеспечения, существует для АС, а не для ИС. Тебя не смущает термин "информационное обеспечение информационной системы"?

Что значит инфраструктурная? Корпоротивная сеть? Но разве там нет пользователей, админ персонала? ресурсов хранения? аппаратных и программных средств?

Например, интеграционная подсистема, построенная на основе BizTalk. Её пользователями являются другие системы, а не люди.

есть понятие ручная информационная система
автоматизированная ИС
автоматическая ИС

Нужна ли пользовательская документация? Весь вопрос в том кто пользуется. Ясно что если система делается для реализации функций людей - нужна однозначно (справка или документация не важно)
Если система полностью автоматическая - нужна документация ориентированная на обслуживающий персонал - читай теже пользователи

"Значит нужна". Понимаешь, я хочу, чтобы были не ad-hoc рассуждения, а методика определения того, какие работы и артефакты должны быть сделаны в зависимости от того, какая система создаётся (а это может быть бизнес, приложение, АС, ИС и т.д.) Сколько таких вопросов про нужность ты задашь сам себе при определении требований и работ?

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

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

2109

Бизнес-анализ и Целеполагание / Re: Формулировка цели

« : 16 Марта 2007, 10:23:11 »

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

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

Например цель системы: проводить экзамен по программирования в режиме автоматизированного тестирования
а цель анализа(моделирования): разработать правила проведения автоматизированного экзамена по программированию?

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

Конечно цели должны соотноситься!

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

2110

Системный Анализ и Требования / Re: IEEE-STD-830-1998

« : 14 Марта 2007, 19:43:07 »

А существует перевод?
Может имеет смысл взяться за эту работу?

Перевод не встречал. По сути это западный, более коммерциализированный вариант ГОСТ 34.602 (вкупе с IEEE Std 1233-1998 - Guide for Developing System Requirements Specifications), основанный на структурно-функциональном подходе к пониманию систем.

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

Но вообще идея хорошая. Хотя опять же вопросы прав.

2111

Бизнес-анализ и Целеполагание / Re: Пошаговый перевод избранных мест из BABOK

« : 14 Марта 2007, 12:45:54 »

а) - ты считаешь что материал не вменяемый? Мне он показался на первых парах очень неплохой.

Материал спорный, опять же еще неизвестно, как они его перекроят.

с) - согласен, можешь настроить систему у себя, а я сделаю на сайте url ссылку на материал. Какую будешь ставить систему? mediawiki требует рнр 5

MediaWiki начиная с версии 1.7 требует php5, но и он у меня есть. Вобщем сначала надо с правами на материал разобраться.

2112

Бизнес-анализ и Целеполагание / Re: Пошаговый перевод избранных мест из BABOK

« : 14 Марта 2007, 12:41:45 »

> б) связаться с ЗЫИИБОЙ на тему прав и их взгляда на такую деятельность
б) - не понял

What is the copyright status of the BABOK™?
The terms "Business Analysis Body of Knowledge" and "BABOK" are trademarked by the IIBA.
 
The BABOK is copyrighted by the IIBA. If you wish to excerpt content from it, you must contact the IIBA for permission. Please contact Kevin Brennan with a description of the intended usage.
 
The IIBA is in the process of developing a policy that will govern use of material from the BABOK for our Endorsed Education Providers and plans to have that policy available in February of 2007. Until this policy is available, you may request permission from us to reuse material--please include a description of the intended use with your request.
BABOK FAQs

2113

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 12:36:16 »

И ты мне теперь будешь утверждать, что твои theiiba имеют в виду именно анализ вообще бизнеса?

Нет, они берут общий термин и трактуют его в узком смысле - бизнес-анализ с целью выявления требований.

2114

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

« : 14 Марта 2007, 12:06:40 »

Вот, что я думаю по этому поводу.

Любая информационная система включает такие важные элементы как
* информационное обеспечение
* техническое обеспечение
* математическое и программное обеспечение
* организационное обеспечение
* правовое обеспечение и т.п.

Отсюда следует, что создаваемая ИС должна отвечать требованиям, которые накладываются на эти виды обеспечения.

О, ОБЕСПЕЧЕНИЕ - это один из самых дурацких терминов, всё давно хочу пройтись по нему Что такое в данном случае ОБЕСПЕЧЕНИЕ - это ОБЪЕКТ, ПРОЦЕСС, УСЛОВИЕ, ПОДСИСТЕМА? Что-то другое? Что?

По поводу "и т.д." - лингвистическое обеспечение нужно? А технологическое? А где полный перечень? Где-таки ответы на вопросы А-Г? Кто сказал, что люой системе нужно каждое это ОБЕСПЕЧЕНИЕ?

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

ВЫТЕКАЕТ - это хорошо сказано. А если системой будут пользоваться не люди, а она инфраструктурная? Т.е. мы должны иметь перечень правил формирования требований типа:
...
Правило 143.2.а Если систему будут использовать люди, ТО нужна пользовательская документация. ЕСЛИ систему не будут использовать люди, ТО пользовательская документация не нужна.
...

Система должна иметь документацию о внутреннем устройстве. Любая система как элемент содержит такую составляющую как персонал. Соотвественно данная документация направлена на обеспечение нормальной работы персонала ИС.

Почему? Тебе для того, чтобы использовать Windows, нужно иметь документацию о её внутреннем устройстве? Покажи.

Как я понимаю, ты сам прекрасно видишь ответ на свои вопросы.

У меня есть идея для метода выявления требований, но она никак не "прекрасно видима".

По моему очень скромному мнению, целостное видение системы формируется из различных моделей и артефактов.

Короче, сплошной постмодернизм. Значит, владелец системы, который сформировал концепцию системы, которой созданная система соответствует, целостным видением её не обладает?

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

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

2115

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 11:48:02 »

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

Лично я не очень понимаю твою упертость в бизнес-анализ, целеполагание и прочее.

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

Самым элегантным и нужным бизнесу решением, имхо, является устранение ПРИЧИНЫ проблемы (если речь идёт только о проблеме, а не возможностях), а не погружение в процесс производства/внедрения софта.

Не моя это область деятельности. Не я должен сам себе целеполагать.

А ты кто?

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

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

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

Ты серьёзно думаешь, что ИТ-специалист захочет обращаться к аналитику? Разве это в его интересах?