136

Вакансии / Re: Требуется "Аналитик"

« : 04 Марта 2011, 13:27:52 »

Несколько вопросов:
1. Где территориально.
2. Какая страховая система, какие задачи закрывает на каких технологиях решениях построена (поскольку еще и постановку осуществляет возможно необходимы знания по конкретной системе)
3. Что подразумевается под "работа с  БД Oracle"?
Спасибо.

137

Примеры / Re: Задание на автоматизацию АЗС. Нужна помощь экспертов.

« : 28 Февраля 2011, 16:18:47 »

Теперь по порядку 2.3.1 Описать все биснес процессы с помощью UML. Вот что получается.

Для описания бизнес процессов используйте диаграмму бизнес вариантов использования.
Для этого необходимо выделить business-actor (потребители), это клиент.
business-worker, это сотрудники компании обеспечивающий выполнение бизнес процессов.
Бизнес-варианты использования это те которые имеют ценность для потребителя и связаны с деятельностью "акторов".
В вашем случае для клиента могут быть выделены такие бизнес-варианты использования:
"заправка топливом","пользование услугами АЗС", "оплата услуг АЗС", "покупка товаров на АЗС" и т.п.
Почитайте например
http://www.iworld.ru/attachment.php?barcode=978531800358&at=exc&n=0
http://www.intuit.ru/department/pl/umlbasics/3/umlbasics_3.html

138

Sparx / Re: FAQ - Sparx Enterprise Architect

« : 18 Февраля 2011, 16:35:55 »

Подскажите пожалуйста, как на диаграмме компонентов отобразить элемент База данных?

Как вариант использовать стереотип FC_Storage или добавить свой стереотип DataBase

139

Проектирование / Re: помогите с документирование CRM

« : 18 Февраля 2011, 16:11:22 »

Начните со сбора функциональных требований, в быту ТЗ. После написания ТЗ переходите на проектирование информационной системы, используя различные диаграммы UML. Когда дойдете до классов - станет понятно на чем в итоге вы будете писать ту или иную функциональность. Если я конечно правильно понял ваш вопрос.

Вообще-то, в профессиональном сообществе, функциональные требования это - ФТ.

140

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

« : 18 Февраля 2011, 11:09:23 »

У меня в функциональных требованиях указано, что система должна строить график N. Это график расчитывается по формуле Y. Где мне указать эту формулу? В том же требовании или как? Как будет правильно? Формула нужна будет архитектору и лучше ее где то указать, а не устно передать.

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

141

Обучение / Re: Системный аналитик курсы

« : 14 Февраля 2011, 13:07:05 »

Всем привет!!!!Очень нужен совет.
 Хочу устроиться на работу в банк системным аналитиком. Пробежавшись по вакансиям понял, что поскольку у меня нет опыта работы, а образование техническое(МФТИ) и никаких знаний в этой области у меня нет, то никто меня на эту должность пока не возьмет.
В общем прошу совета о том на какие курсы идти в первую очередь.

Мои рекомендации
0. Во первых изменить свое отношение к "тупой, рутинной работе", вы хотите "блюдечко с голубой каемочкой"?
На любых проектах и в любой работе часть - рутина и иногда кажется тупой. А у системного аналитика иногда и тупее вдвойне поскольку нужно маневрировать между непонятными "хотелками", низкой квалификацией бизнес-экспертов, и как то их увязывать в существующими процессными и технологическими ограничениями.
Если вы не готовы пахать для достижения поставленной цели, то никто вас обучать и брать в серьезные проекты не будет за "красивые глаза" и "красивый сертификат".
1. Закончить краткосрочные курсы по какой либо из CASE систем, выберите те что наиболее востребованны: Rational Rose, Aris, "BPWin". Получите представление об инструментарии, что позволит на первых порах выполнять чисто технические задачи в проектах.
2. Устроиться стажером на системного-аналитика в компанию которая использует обозначенное в первом пункте CASE-средства.
Или пытаться применять полученные знания в рамках текущей деятельности. Это позволит приобрести навыки СА в реальных проектах и освоить какую-либо предметную область.
Не обязательно устраиваться именно аналитиком, можно попробовать разработчиком или техническим писателем, или даже специалистом по поддержке. На данном этапе важно получить опыт работы в реальных проектах на реальных системах. На этих проектах у вас при вашем желании будет возможность увидеть специфику СА и получить опыт взаимодействия с СА.
3. Через два-три года пойти учиться на "серьезный курс" по направлению бизнес-аналитик или системный аналитик в какой либо авторитетный ВУЗ. Например см. www.itmane.ru (но это обучение на срок не меньше года).


 

142

Для всех / Re: Создание отдела реинжиниринга бизнес-процессов

« : 01 Февраля 2011, 17:56:18 »

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

Все зависит от того где вы проведете границу.
Если вы бизнес-аналитик так наверно надо начать с того чтобы описать в первую очередь деятельность своего подразделения (часть которой возможно идентифицируете как бизнес-процесс).
Определить границы процесса и контекст, классифицировать процесс и подпроцессы, ролевую модель, цели, технологии и т.п.
Если подходить к деятельности подразделения которое выполняет "реинжиниринг бизнес процессов" (который в принципе возможен только для компаний с уровнем зрелости процессов не ниже 3-го уровня "Established"), то как правило результатом процесса является не только схемы БП но и:
- план мероприятий внедрения БП или изменений
- инструкции и регламенты по технологии процесса
- обученный персонал, являющийся исполнителем по процессу

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

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

Насчет "типовых обязанностей" БА есть много статей и дискуссий в сети по этому поводу.
Как пример
http://livehh.ru/fedorovia/entry/klassicheskiy-primer-biznes-analitika-sherlok
http://livehh.ru/fedorovia/entry/biznes-vs-sistemnyy-analitik-podborka

Удачи.

 

143

Идеи и мозговой штурм / Re: Я - заказчик, но мне нужно написать ТЗ на создание БД...

« : 14 Января 2011, 12:13:46 »

текущая программа,в которой мы собственно и работает, кого-то не устраивает...

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

1. Опишите в общем виде какие функции ваш отдел выполняет в текущей системе.
Сильно зависит от деятельности которую выполняет ваш отдел
Например для отдела снабжения:
Работа со справочной информацией.
  Ведение справочника Поставщиков (контрагентов)
  Ведение справочника Номенклатура
...
Работа с "транзакциями" (фиксирование фактов и различных событий деятельности и т.п.)
  Регистрация плана поставок
  Регистрация заявок поставщикам
  Регистрация приходных накладных
...
Отчеты
  Формирование отчета по не выполненным заявкам
  Формирование отчета по остаткам на складах
...
Сервисные функции
  Печать комплекта документов по поставке
  Расчет средних цен по поставщикам
  Расчет показателей подразделения

и т.п.

2. Формулируете требования к функциональности системы (пока в общем виде, без серьезных уточнений)
Например:
В системе должно быть предусмотрены следующие возможности
Ведение справочной информации.

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

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

144

Sparx / Re: EA - скрытие наследуемых атрибутов, операций объектвов на диаграме?

« : 30 Ноября 2010, 20:25:13 »

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

Добрый день, коллеги.
Нашел еще один способ которым можно скрыть атрибуты или операции родительского класса после того как установлен флаг Inharited Features \ ShowAttributes.
Шаг 1. Для атрибутов или методов которые хотим скрыть при выводе списка на дочерних диаграммах необходимо установить стереотипы например добавить пользовательский стереотип "HideOnChild".
Шаг 2. На форме Feature Visibility в поле Hide Stereotyped Features добавляем идентификаторы стереотипов которые нужно скрыть на этом классе или объекте. Причем это правило распространяется не только на атрибуты или свойства родительского класса, но и на все атрибуты и свойства помеченные стереотипом перечисленном в поле.

Минус этой схемы в том что на родительской диаграмме для атрибутов будут выводится названия стереотипов и группировка атрибутов по стереотипам. Возможно что это отображение также можно регулировать.
Удачи.