Файл: Автоматизация учёта кадров на предприятии.docx

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 10.01.2024

Просмотров: 141

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

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

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

Определим сущность для разрабатываемого приложения. В данном случае в качестве актера выступает «Сотрудник» кадрового агентства, который имеет варианты взаимодействия с приложением (Рисунок 1).


Рисунок 1 – Use case диаграмма автоматизации учета кадров на предприятии.

1.2 Требования к разрабатываемой системе


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

Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт—менеджера об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.


Функциональные требования, как правило, состоят из :

  1. User story;

  2. Use cases;

  3. Wireframes.

Сосредоточимся на User story и Use cases.

Пользовательская история, или User Story — это описание функций продукта простым языком, составленное с точки зрения пользователя. Она помогает понять, какую пользу клиенту принесет функционал приложения, еще на этапе аналитики проекта. Пользовательские истории служат неким контекстом для разработчиков: те понимают, чего хочет от продукта конечный пользователь, и работают более целенаправленно. Эти истории состоят из нескольких предложений и не углубляются в детали: они отражают суть и фокусируются на главном.

Пользовательские истории помогают сосредоточиться на потребностях пользователя: как он будет использовать приложение? Чего он ждет от продукта? Как поведет себя в той или иной ситуации? Таким образом, ответы на эти вопросы помогут создателям продукта решать настоящие проблемы клиентов. Вот несколько главных задач, для которых необходимо использовать User Stories:

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

  2. Cохранить фокус на пользователе. Конечно, разработка включает себя десятки сложных задач, связанных с техническими, финансовыми и другими вопросами. Однако User Story — это постоянное напоминание команде о тех, для кого этот продукт создается, и направляют их работу в нужное русло;

  3. Сплотить команду. Несмотря на то, что у каждого есть свои задачи, каждый понимает конечную цель и видит себя частью целого. Только работая сообща, можно достичь нужного пользователю результата, и пользовательские истории дают четкое понимание этого аспекта работы;

  4. Найти свежие решения. Команда старается придумать самый приятный и интересный способ решить задачу пользователя. Часто это приводит к появлению новых интересных идей и их воплощению. Результат — полезный и уникальный продукт.

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



  1. Заголовок – краткое описание истории;

  2. Я как – роль;

  3. Желания или требования – функционал;

  4. Для того, чтобы облегчить или улучшить – польза.

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

На основе данных требований, можно составить следующие user stories для разрабатываемого приложения:

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

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

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

  4. Я как сотрудник хочу просматривать журнал для того, чтобы не было каких – либо недочётов или конфликтных ситуаций с посетителями;

  5. Я как сотрудник хочу просматривать имеющиеся данные в журнале для того, чтобы своевременно предоставлять её посетителю и руководству предприятий;

Use case (также use case, сценарий использования) – это сценарий взаимодействия пользователя или пользователей с программным продуктом для достижения конкретной цели.

Use case содержат следующие сведения:

  1. кто использует сайт или приложение;

  2. что пользователь хочет сделать;

  3. цель пользователя;

  4. шаги, которые делает пользователь, чтобы совершить определенное действие;

  5. описание того, как сайт или приложение реагируют на действия пользователя.

Use case не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

В use case описывается не каким образом программа делает что—либо, а что именно она делает. Именно этого подхода и нужно придерживаться, создавая use case.

В отличие от user story, которая излагается от имени какого—то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:


  1. запрос страницы браузером (браузер – веб—сервер);

  2. отправка ‘письма по электронной почте (отправитель – почтовый клиент).

  3. обращение спортсмена к тренеру (игрок – тренер).

Use case могут содержать следующие элементы. Их количество зависит от сценария:

  1. Актер (actor) — тот, кто использует систему. Если взять за пример онлайн—магазин, там может быть несколько акторов: покупатели, продавцы, компании, занимающиеся доставкой, компании, проводящие платежи;

  2. Стейкхолдер (stakeholder) — тот, кто заинтересован в определенном поведении системы. Зачастую это не конечный пользователь, а кто—то, получающий выгоду от функционирования системы. В случае с онлайн—магазином это может быть партнер — платежная платформа;

  3. Первичное действующее лицо (primary actor) — человек или система, чьи цели достигаются при помощи нашего продукта. В онлайн—магазине это может быть основной дистрибьютор, чьи товары продаются на этой онлайн—платформе;

  4. Предусловия и постусловия — что должно быть в наличии или должно произойти до и после запуска сценария использования;

  5. Триггеры — события, запускающие use case;

  6. Успешный сценарий — use case, при котором все идет по плану, без ошибок и неожиданностей;

  7. Альтернативные пути — вариации основного успешного сценария на случай, если что—то пойдет не так на уровне системы, путём нарушения алгоритмов.

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

Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде use case.

1.3 Разработка диаграмм деятельности.


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


База данных aknp состоит из следующих сущностей (таблиц): "Сотрудники", "Должности", "События" и "Журнал". Сотрудник напрямую работает с клиентами, в его обязанности входит регистрация данных клиента перед подачей их предприятию. После каждой смены сотрудник создает и помещает общую базу журнала.

Кадровое агентство – предоставляет услуги по благоприятному трудоустройству.

Сотрудник:

  1. записать данные клиента, создать предварительно событие;

  2. записать выбранную должность клиентом;

  3. дописать событие и о принятие на работу клиента;

  4. сохранить событие и данные клиента;

  5. занести все данные в журнал.


Клиент:

  1. дать разрешение на обработку своих персональных данных;

  2. выбрать выгодную для себя должность;

  3. заключить договор с предприятием;

  4. приходить в кадровое агентство для возможности изменения своей должности.



1.4 Разработка схемы базы данных


Схема связей базы данных aknp, показывает какие сущности соединены между собой и по каким атрибутам.

Схема «сущность–связь» (также ERD или ER–диаграмма) — это разновидность блок–схемы, где показано, как разные «сущности» (люди, объекты, концепции и так далее) связаны между собой внутри системы. ER–диаграммы чаще всего применяются для проектирования и отладки реляционных баз данных в сфере образования, исследования и разработки программного обеспечения и информационных систем для бизнеса. ER–диаграммы (или ER–модели) полагаются на стандартный набор символов, включая прямоугольники, ромбы, овалы и соединительные линии, для отображения сущностей, их атрибутов и связей (ПРИЛОЖЕНИЕ В).

Эти диаграммы устроены по тому же принципу, что и грамматические структуры: сущности выполняют роль существительных, а связи — глаголов.

Каждая таблица необходима для выполнения конкретных функций.


Рисунок 2 – Описание таблицы «События»