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

×


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

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


Сообщения - bas

3061
Юра,

Можешь раскрыть - что ты конкретно понимаешь под "формальный процесс управления изменениями (в отношении требований в данном случае)"??

3064
Да уж, СУПЕРФИНАЛ!

Наши выиграли заслужено, Канадцы без удалений были ничто.

РОССИЯ - ЧЕМПИОН


3065
Обновились ссылки в статье на другие отчеты.

3066
Первые три пункта понял :)

Юра,

Под EA ты видимо имел в виду - Enterprise Аrchitecture

В общем, в данном случае относительно требований надо продумать политику (регламент) их изменения + построить первоначальный репозиторий требований, так?

Цитировать
3. Создать единый репозиторий требований на базе некого тула и загонять все туда. При необходимости давать доступ туда подрядчикам, чтобы сами вколачивали требования.
Ну тут как раз и очень вероятна рассинхронизация, если не давать доступ к тулзе подрядчикам. Или при изменении требований подрядчики должны оповестить что и где поменялось??

3067
29 мая 2008 г. в 18:00 пройдет Семинар – круглый стол «Как заставить регламенты работать и приносить пользу»

Место проведения: Центр обучения Люксофт

Регистрация: на сайте livents.ru. Указывайте свое ФИО в профиле вашего логина на livents.ru, иначе Вы не пройдете на Семинар

Условие участия: БЕСПЛАТНО

Предисловие к представленному анонсу
Для систем автоматизации, в которых задействовано много пользователей с различными ролями написание хорошего ТЗ (работа системного аналитика) недостаточно для обеспечения работоспособности системы.
В многопользовательской системе необходима работа бизнес-аналитика, результатом которой будет, как минимум, схема процесса TO BE для написания ТЗ. В реальности большую многопользовательскую систему невозможно внедрить без регламентации деятельности людей вокруг системы. Львиная доля рисков внедрения системы для групповой работы сосредоточена именно в процессе создания регламентов (если угодно, технологии применения средств автоматизации), а так же в процессе внедрения созданных регламентов. Технические риски в таких проектах отходят на второй план, работоспособность или не работоспособность принятой (и зафиксированной в системе) организационной схемы полностью решает дальнейшую судьбу ИТ системы.
Семинар раскрывает сторону, которую ИТшники вообще никогда не считали своими activity, на деле же, из за отсутствия этих вещей терпят крушение многие проекты внедрения больших систем. При этом часты случаи, когда акты закрытия этапов подписаны, система пуско-налажена, но никто в ней не работает.

Целевая аудитория:
1.   Бизнес-аналитики.
2.   Системные аналитики.
3.   Руководители проектов внедрения ПО.
4.   Любой другой заинтересованный сотрудник любой Компании.

Что дает семинар:
Теоретические и практические знания по:
1.   определению критичных для описания бизнес-процессов;
2.   моделированию бизнес-процессов разного уровня;
3.   формированию текстов регламентов на основе схем бизнес-процессов;
4.   быстрому и неформальному согласованию регламентов;
5.   построение мотивации сотрудникам, участвующих в бизнес-процессах.

Уровень подготовки: понимание необходимости регулярного управления с помощью разработки и поддержания в актуальном состоянии бизнес-процессов Компании.

План:
1.   Вводная часть. Цели регламентации с учетом автоматизации деятельности. Основные определения.
2.   Взаимоотношения бизнес-аналитика и программиста при автоматизации деятельности.
3.   Технология регламентации деятельности с учетом автоматизации
Теоретическая часть:
Технология регламентации деятельности через моделирование бизнес-процессов.
Определение приоритетных мест для моделирования процессов.
Построение схем бизнес-процессов и поиск мест для автоматизации.
Создание ТЗ (форма, ответственность за составление и исполнение, сроки исполнения тестирование).
Построение регламента понятного для разработчика и исполнителя.
Создание документа для пользователя.
Внедрение процесса с учетом введения нового/измененного программного обеспечения. Эксплуатация и решения проблем при введении регламента с учетом автоматизации деятельности.
Как часто необходимо изменять созданные регламенты, в случае наличия изменений?
Практическая часть:
Отработка технологии построения регламентов.
Создание регламентов для пользователя на 1 странице?
4.   Построение мотивации на основе построенных бизнес-процессов
Теоретическая часть:
Взаимосвязь результатов процесса и мотивации персонала. Определение ключевых показателей деятельности сотрудников, участвующих в процессе.
Практическая часть:
Совместная работа по определению мотивации для участников процесса (для данной работы берется уже сформированный регламент, см. п. 3).

Длительность: Семинар – круглый стол рассчитан не более 4 рабочих часа. 1 перерыв на 15 минут.

3068
1. Ситуация не похожая. В вашем случае Вы зависите от Клиентов, они вас могут и вправе послать вас ... заполнять самим эти шаблоны. Тут же наоборот - мы диктуем что хотим, а подрядчики исполнят
2. На счет обучения и следования правил. Да ты прав, тут надо как минимум писать регламенты и инструкции
3. Про ГОСТ - это ты зря, выкидываем что не нужно и заполняем действительно ценные разделы, как например цели и задачи :)

3069
28 июня 2008 года в Москве пройдёт первая конференция, посвященная обучению в области разработки программного обеспечения - Training Labs 2008.

Интересуетесь обучением в области Software Engineering?
Ищете куда отправить сотрудников на обучение?
Являетесь учебным центром или независимым тренером в данной области?

Тогда это мероприятие — для вас!

Формат: тренинговый марафон, 8 секций, в каждой из которых по 4 мини-тренинга/мастер-класса длительностью 1.5 часа каждый.

Цель мероприятия: сблизить заказчиков и провайдеров обучения.

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

К тому же, мы все будем просто общаться на волнующие нас темы в данной области. Приходите, будет интересно!

Мы с нетерпением ждем:
    * учебные центры и независимых тренеров провести мини-тренинг/мастер-класс по одной из 8-ми тем;
    * спонсоров и инфо-спонсоров, готовых взять на себя часть наших расходов и поведать миру о нашем начинании;
    * и конечно же, участников, ради которых все это и организовывается.

Регистрируемся

Подробнее про конференцию

3070
Представим себе ситуацию. Есть компания, большая компания, бизнес которой связан или не связан с ИТ, типа Лукойла, Роснефти, МТС, Люксофт и т.д.
Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.

Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??

Есть три варианта:
1. Принимать ТЗ и складировать их у себя в проектных папках. Но тогда встает вопрос про связывание требований, их синхронизации и прав доступа
2. Принимать ТЗ из вне и тупо перебивать их в СУТ (система управления требований). Тогда быстро произойдет рассинхронизация
3. Заставить подрядчиков работать во внутренней СУТ. Вариант хороший, но какие есть подводные камни??


3071
По сити, его семинар наверное был сделан по книжке?! Надо просто ее прочитать

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

3072
Ира,

1. Так какие ключевые рецепты Йордон предлагает, чтобы завершить проект in time, in budget and with proper quality?
2. Что он говорит про наши любимые дисциплины - анализ и проектирование?

3073
А у меня вообще такой вопрос - а причем тут СРМ? СРМ, как я всегда представлял, - это управление отношением с клиентами. Причем тут "закпки, склад, продажи и т.д." ??? Это уже больше похоже на решении ERP.
А вообще ща начался второй этап автоматизации, это не просто автоматизация каждодневных операций, а автоматизация управления и принятия решений. А это уже BI.

3074
Модели могут отличаться или не отличаться, это как сделаешь. Но скорее всего нотация, реализованная в Арисе и ЕА будет отличаться, т.е. на основе нотации в ЕА можно, например, построить более богатую диаграмму Классов и Состояний.

3075
Скорее всего обе эти Системы поддерживают нотацию UML, предложенную OMG в спецификации. Версию поддерживаемой нотации UML нужно уточнять в каждом конкретном случае.
Так же возможно, что каждая из тулзовин дополняет нотацию своими фичами.