4531

Примеры / Моделирование кадровых процессов

« : 18 Декабря 2007, 13:05:45 »

Уважаемая публика,

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

Попытка описать бизнес-процесс в нотации BPMN (тут картинка)



Далее описание процесса Прием на работу  в стиле ВИ

Номер:   1

Название:   Принять на работу сотрудника

Автор:   Эдуард Галиаскаров   Последнее обновление:   

Дата создания:   17.12.07   Дата обновления:   

Уровень:   Бизнес-процесс

Область действия:   Отдел кадров

Действующие лица:   Кандидат – лицо, принимаемое на работу
                                 Сотрудник отдела кадров

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

Предусловия:   1.   Имеется вакантная ставка
                       2.   Кандидат имеет подписанное руководителем подразделения и ректором заявление

Постусловия:   1.   На нового сотрудника заводится личная карточка и личное дело
                       2.   Приказ подписан, копия приказа передана в расчетный отдел бухгалтерии
                       3.   Трудовой договор оформлении подписан

Основной поток:   
1.   Поступило подписанное заявление кандидата.
2.   Сотрудник отдела кадров вызывает каким-то образом кандидата.
3.   Кандидат приходит в отдел кадров, возможно имея при себе необходимые документы или их копии:
         a.   Паспорт
         b.   Страховое свидетельство государственного пенсионного страхования
         c.   Дипломы об образовании
         d.   Трудовая книжка
         e.   Военный билет
4.   Сотрудник отдела кадров выдает кандидату контрольный лист и направляет его на инструктаж по охране труда в отдел охраны труда.
5.   Кандидат проходит инструктаж по охране труда
6.   Кандидат возвращается с подписанным контрольным листом и сдает его сотруднику отдела кадров
7.   Сотрудник отдела кадров проверяет наличие необходимых документов, заполняет личную карточку на основании копии документов кандидата, принимает трудовую книжку и заводит личное дело сотрудника
8.   Сотрудник отдела кадров помогает кандидату составить типовой трудовой договор
9.   Сотрудник отдела кадров на основании заявления создает приказ на прием на работу установленного образца, присваивает приказу номер и регистрирует его в журнале регистрации приказов
10.   Сотрудник отдела кадров передает приказ и трудовой договор на подпись начальнику отдела кадров и передает их в канцелярию на подпись и согласование руководством
11.   При получении подписанного приказа сотрудник отдела кадров вносит в личную карточку запись о приеме на работу с указанием номера приказа.

Альтернативные потоки:   

Исключения:   
1.   (шаг 4) Кандидат принимается на работу с производственной вредностью
1.1.   Сотрудник отдела кадров выдает бланк медицинской справки с указанием ФИО кандидата, типом производственной вредности и стажа работы
1.2.   Кандидат проходит медицинский осмотр
1.3.   Переход на шаг 5 основного потока
2.   (шаг 4) Кандидат имеет инвалидность
2.1.   Сотрудник отдела кадров просит предъявить справку ВТК
2.2.   Кандидат предъявляет справку
2.3.   Переход на шаг 5 основного потока
3.   (шаг 7) Кандидат военнообязанный
3.1.   Сотрудник отдела кадров направляет кандидата в военно-учетный стол вуза
3.2.   Кандидат встает на учет
3.3.   Переход на шаг 8 основного потока
4.   (шаг 2) Кандидат – сотрудник, принимаемый по совместительству
4.1.   Переход на шаг 8 основного потока

Включает:   нет

Приоритет:   высокий

Частота использования:   ежедневно

Бизнес-правила:   БП-1. Дата приказа не должна превышать дату приема на работу более 3 дней

Особые требования:   

Допущения:   

Замечания и вопросы:   

4532

Управление Проектом / Re: укрощение EPF Composer

« : 17 Декабря 2007, 17:39:29 »

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

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

Методология - это учение об организации деятельности.    Новиков А.М. Новиков Д.А.

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

4533

Идеи и мозговой штурм / Re: Тесные ассоциации третьего рода

« : 16 Декабря 2007, 11:03:51 »

Анна Васильевна, картинку-то так и не нашли? Или до дома так и не добрались?

Насчет ассоциации информатики и компьютеров

Информатика не более наука о компьютерах, чем астрономия — наука о телескопах.

Эдсгер Дейкстра

4534

О Сайте и Форуме / Re: ФАНТАСТИКА

« : 16 Декабря 2007, 10:49:57 »

BAS, за одну ошибку и сразу двойка?
Бедные ученики, которые будут учиться у такого учителя русского языка как ты

4535

О Сайте и Форуме / Re: ФАНТАСТИКА

« : 15 Декабря 2007, 23:48:09 »

З.Ы. двойка по русскому.

Это почему?

За пропущенную запятую в предложении: "Лично у меня сегодня был день семьи"? Хотя, это еще вопрос
Или "За весь день не одного сообщения!" Надо было "ни одного"?

BAS, приятное чувство - месть? 

4536

О Сайте и Форуме / ФАНТАСТИКА

« : 15 Декабря 2007, 21:21:32 »

За весь день не одного сообщения!

Либо народ активно отдыхает, либо готовится к НГ, либо ничего завораживающего на форуме нет.

Лично у меня сегодня был день семьи . Весь отдался семейным делам

4537

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

« : 14 Декабря 2007, 17:55:16 »

По содержанию документа есть замечания и пожелания по дальнейшему развитию:
- источник требований не один Gevorg, но и обсуждения и результаты с форума,

Да, можно поправить. Тем более это же черновой вариант.

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

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

- смарт-карта, описанная в документе - это несколько другое, отличное от того, что я изначально имел в виду и что было подхвачено Greesh-ей.
Скрэтч-карта намного более примитивная вещь, но она имеет секретный код, которого касается одно из интересных для нас в поучительном плане требование.

Моя ошибка, сложно понять почему самрт-карты а не скрэтч.

Нужны следующие ближайшие доработки документа:
исправить глоссарий:
- заменить описание смарт-карты на описание скрэтч-карты от Greesh-ы (2 варианта скрэтч-карт)

Заменю

- добавить описание скрэтч-кода.

Добавлю

- добавить результаты обсуждения требований хотя бы в виде вопрос-ответ.

попробую

- добавить варианты ПЕРЕформулировок, предложенных Вами.

Я что-то переформулировал? Поправлю

сорри, что перегружаю эту работу на Вас, я ещё неделю буду очень стеснён временем.

С Вас арманьяк

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

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


Ссылка для просмотра файлов проекта (RaQuest и MS Word). Участники проекта думаю могут вносить все нужные изменения.

В RaQuest я создал новую команду и троих участников Galogen, Gevorg, Greesha. Все требования внесены от лица Galogen, кроме 16, которое внесено от лица Greesha, т.е. автора.

4538

Сообщество Аналитиков / Re: [Проект] Статьи от студентов (Подготовка)

« : 14 Декабря 2007, 17:17:26 »

А я предупреждал. Такие вещи нужно объявлять в начале семестра. Ну ничего, посмотрим еще

4539

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

« : 14 Декабря 2007, 10:57:46 »

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

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

Такая возможность есть  и она широко применяется на практике

2. Для каждого типа атрибута задать некоторые коэффициенты (вербальные или числовые).
   Например. Атрибут "возможность реализации" имеет значения "возможно реализовать",
   "не возможно реализовать", "возможно, но не полностью" и тд.

Именно так и делается

3. Человек, согласующий ТЗ, для каждого требования выбирает значение атрибутов качества
    и добавляет комментарий (замечание, предложение и др.).
    Разные люди (заказчик, системный архитектор) могут выставлять значения для разных атрибутов.

По поводу 1 это так, второе предложение тоже возможно, но оно будет заменять текущее значение на значение выставляемое проверяющим, и конечно будет отражать мнение этого проверяющего

4. После того, как все атрибуты описаны, с помощью допустим алгоритмов нечеткой логики
    или других механизмов обработать результаты полученных данных и для каждого требования
    определить некий показатель качества. Например, требование UC234Регистрация
    пользователя имеет показатель качества "70%" и выводы почему + комментарии.

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

5. Аналитик может за меньшее время оценить результаты и сделать выводы и если нужно внести
    изменения.

Думаю это возможно через обратную связь

4540

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

« : 13 Декабря 2007, 20:31:56 »

некоторые итоги

4541

Системный Анализ и Требования / Re: Писать ли статью про ТЗ по ГОСТ 34.602?

« : 13 Декабря 2007, 15:35:55 »

Денис, а где ты это уже сказал. Насчет ГОСТов?

Насчет RUP. Я конечно не его знаток, я только учусь.

Но вот смотрю книгу Лармана Применение UML 3-е издание (стр.65) - характерный рисунок дисциплин унифицированного процесса (2.7) и (2.. Видно, что львиная доля бизнес-моделирования приходится на стадию Развития.
Идем далее. стр. 68. Таблица примерный набор инструментов (Development Case {не удачный перевод, имхо})
и видим Бизнес-моделирование - артефакт: Модель предметной области. Фаза Развитие - начало. Тогда как артефакты требований начинаются на стадии Начало.
Реально, конечно, все идеть паралелльно и зависит от проекта.

4542

Работа / Re: Что такое корпоративный дух?

« : 13 Декабря 2007, 13:22:52 »

Один мой коллега из США, сказал мне, правда не по поводу КД, что получение з/п акциями проекта или компании сильно мотивирует сотрудника на конечный результат. Более того, если сотрудник не берет акции, а предпочитает деньги, значит он не видит будущее с компанией ии не верит в успех проекта, а значит и не будет работать так, чтобы он был на 100% успешным.

Я, конечно, думаю, что он прав, но только отчасти. Лично мне не интересно получать акции компании, которая находится за тридевять земель

4543

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

« : 13 Декабря 2007, 13:16:28 »

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

4544

Варианты Использования (Use Case) / Re: И все таки вариант использования - это функция :P

« : 13 Декабря 2007, 08:16:40 »

Юра, ты думаешь все это выпускают из виду?

4545

Системный Анализ и Требования / Re: Писать ли статью про ТЗ по ГОСТ 34.602?

« : 13 Декабря 2007, 08:03:09 »

В любом случае я согласен с Денисом, что в чистом виде описание БП не должно быть в ТЗ, тем более по ГОСТ 34. Т.к. эту работу нужно было делать еще на этапе формирования требований к АС, проводя соответствующий НИР по изучению процессов организации и выпуская отчет по НИР.

Я тоже согласен, что моделирование БП не должно отражаться в ТЗ. Если посмотреть множество примеров вот здесь:http://projects.economy.gov.ru/pms/public/, то можно обнаружить, что бизнес-моделирование есть часть технического проекта.
Если обратится к RUP, то бизнес-моделирование происходит на стадии Развития, после формирования первой версии Концепции, важных прецедентов и спецификации дополнительных требований.

Ясно и то, что процесс в общем случае цикличен.

Так все-таки когда и кто делает бизнес-моделирование. Где место моделям бизнес-процессов?