I want to build a timesheet application where employees fill theirs daily tasks in .
I have build this diagram and I need some help if it is correct .
The role is either Scrum master, developer, Product owner, ...
The task_type are like: production, meeting, tests, ...
An agent can have different role based on the project he is affected
A daily timesheet can include different project, for example : an agent can work 1h in project A and 2h in project B
Does the diagram meet your requirements?
Let's verify:
There's a Role with a name that can be "Scrum master", "Developer", "Product owner" or whatever role you invent in the future.
There's a Task_type with a name that can be "production", "meeting", "tests" or what ever type of activities you may be interested in in the futre
An Agent is associated with an Affectation which is associated at the same time to a Project and a Role. An agent can therefore have different roles based on the project, if the multiplicity of the association-end on the side of the assignment is 0..*
An Agent can be associated with a daily Timesheet, the date of which is specified by date. The association-end would be 0..* on the side to Timesheet, to allow several time sheets for the same agent.
A Timesheet is associated with a Timesheet_line which is associated with a Project. The duration is indicated by time at the level of Timesheet_line. You may therefore "include" different timings on different projects for the same date if the multiplicity is 1..* between Timesheet and Timesheet_line at the latter end.
So yes, your diagram seems to fulfil the requirements.
There are however some ambiguities in your requirements:
Can Agent have several Role for the same Project, or shall the agent have a single role on a project? In the latter case, more work is needed (e.g. a constraint on the affectation).
Can Agent have several Timesheet for the same date or not? If not, more work is needed (e.g. a constraint)
Can the same Timesheet have several times the same Project (e.g. 1 hour meeting and 7 hours development) or even several time the same project for the same task type? If not, more work is needed.
In absence of a property type, is time the start time, a time interval, or a duration? I assume the latter and would then recommend going for renaming this property duration
Some more thoughts
Interestingly, your diagram allows an Agent to have time on the Timesheet for activities (Task_type) that do not belong to the assigned role, or even for projects to which the agent is not assigned. This may seem weird at first, but is in fact a valid way to allow to cope with historical data in case of change of assignments (the Affectation does not have a validity interval, so if someone changes role, the old role will be lost) which is not incomaptible with timesheet records entered before this change.
Agent and Admin seem to be both specializations of a more generic User. The question is then to know whether an Admin can also take the role of an Agent and enter time sheets, or if the role of Admin is incompatible with that of Agent.
Passwords should be unknown in the system and no object should know it. The accepted practice is to keep a private saltedPasswordHash property, and have a checkPassword() method which compare the hash corresponding to a user input to the hash kept with the object.
The next step in you rater data driven approach, would be to think carefully about every multiplicity at every end of every association, to have an unambiguous understanding of the relationships, and then complete the picture with behaviors.
Related
I am trying to model a situation in which a customer is added by either sales or an administrative assistent. They both have their own lane. I think using an OR or a 'AND' (paralel) gate would not really accurately reflect the situation.
How would you model this?
It would be great if there was an optional (either or) parallel gate but I don;t know if that exists.
I assume that you mean, whoever comes first will work on this activity. Therefore, a gateway cannot be the solution. It would need to have a condition, that is evaluated before one of the two activities get enabled.
This is what I would do: Create a new lane "customer admin" and specify somewhere else, that sales and adminstrative assistants are "customer admins".
If you duplicate "add customer" to show it in both lanes, you also have to model how one activity gets revoked, as soon as the other role starts working on it. If you want to model this, it gets really complicated. Of course, maybe a simple note could be sufficient, but I guess you are looking for a solution in BPMN.
If this activity would be the first in a process with empty start event, there is a simpler solution: Just use two empty start events and let the starter of the process decide, which one is to be used.
I'm trying to follow the DDD (Domain-Driven Design) approach in my project. My domain is a barbershop and the use case that I want to implement is - book an appointment.
The problem that I have is how to correctly organize boundaries around my aggregate that should help to handle this use cases (book an appointment).
Let's say I have a barber. Barber has working days. Working day has working hours (e.g. 09:00 - 20:00), breaks, and other booked appointments.
Schematically it would look like this
Barber
- WorkingDay
- 09:00-20:00 <- working hours
- Breaks
- 13:00-14:00
- 18:00-19:00
- Appointments
- 09:00-10:00
- 12:00-13:00
- WorkingDay
...
- WorkingDay
...
Rules to be considered:
New appointment must not overlap existing breaks
New appointment must not overlap existing appointments
New appointment must be within working hours
Working day must exist
Working day must not be in the past
I have two ideas of how to implement this:
Create WorkingDay aggregate which will contain all related breaks and appointments.
Pros:
All rules can be satisfied within WorkingDay aggregate
Single WorkingDayRepository repository
Cons:
Possibly large aggregate*
Create WorkingDay, Break, Appointment aggregates and verify rules in domain services
Pros:
Small aggreages
Cons
Multiple repositories (e.g. WorkingDayRepository, BreakRepository, AppointmentRepository)
Business logic is split between aggregates/domain-services
What other option can be used? Or what approach to follow in my case?
You could model this by using the concept of a Schedule. Schedule is your worker's workdays (or calendar) with appointments. It could be a decent aggregate - schedule has to be always valid.
Then you could have AddAppointment method on the Schedule which will check the invariants.
If you need to track changes, I'd suggest using Domain Events that could be fired and then logged.
To avoid concurrency problems with bookings, i.e. when 2 users are trying to book the same slot, you can:
Organise the DB in the way that it will not be possible to double-book, ie in your bookings table you will have a unique constraint on <time slot id>, <barber id> and when the second user is trying to book (insert a booking into the table) they will fail with unique constraint violation. Not sure how your db is structured but hope you get the idea.
use DB transactions. Both will try and update the row with time slot, only one should succeed.
put booking requests for the same barber into a queue.
So, not really sure if this is the right place for this but I have this current Context level data flow diagram for the bellow specification extract and I have never done one before so I was wondering if it was correct or if it needs fixing? any help appreciated
This is a link to a screen of my current one http://i.imgur.com/S4xvutc.png
SPECIFICATION
Currently the office staff operate the following processes:
Add/Amend/Delete Membership
This is run on-demand when a new membership application is received or when a member indicates that he/she wishes to make amendments to their details. It is also run in those rare instances when a membership is terminated at the discretion of the manager. A new member has an ID number allocated (simply incremented from the previous membership accepted). A membership balance is also maintained for accounting purposes.
Another process operates in a similar fashion on data associated with transfer partners.
Monthly Maintenance
This is run on the last day of each month to issue requests and reminders for subscriptions due, and to remove memberships where fees remain outstanding. Standard letters are also generated. Membership balances are updated as appropriate.
Payment Updates
This is run prior to the Monthly Maintenance, with membership balances being updated accordingly.
Payments to partners are also disbursed at this time.
New Member Search
This is run whenever a new member has been added to the database. The partners are partitioned in terms of vehicle category and location. Normally, there is a limited choice of partner in a particular location (if, indeed, there is any choice) but for some popular destinations, several partners are involved in providing the airport transfer. Thus, a search is then made through the appropriate section for potential matches in the following manner:
A search is then made on the grounds of sex (many female passengers in particular prefer a driver of their own sex, especially if travelling alone or in couples).
Matches are then selected according to factors such as cost (if available), availability of extra requested facilities (such as child seats, air-conditioning etc.)
Existing Member - Additional Searches
These are run on-demand in the same fashion as for a new member's search. Members may of course request any number of such searches, but a separate payment is due for each.
All financial transactions (payments) are also posted to the separate Accounts file, which also stores other financial details relating to running costs for the consideration of the firm's accountants at the end of the financial year.
Thanks for any help, regarding this level 0 Context only DFD
It needs some fixing.
The most obvious flaw is that you use verbs in your dataflows. In some cases this can be fixed easily by just discarding the verb. Return balance and status is not a datflow, but balance and status is.
In others cases it is not so easy. Check Balance, is it outstanding? sounds more like a Process than a dataflow. It looks like Accounting is responsible for doing that job. So will Accounting produce a list of outstanding balances? Or will it return a single balance and status, and if so, based on what input? Will your Airpot Transport System send a list of balances to check to Accounting?
Take for example Monthly Maintenance. What matters is that you want
requests and reminders for subscriptions due
Standard letters
These need to be visible in your DFD
The fact that you want to remove memberships where fees remain outstanding, probably has not place in the toplevel diagram, because that looks like an internal affair.
In general, focus on what the System produces. Maintaining internal state is secondary, is is a necessity to produce the desired output.
I've been a JIRA and Bugzilla admin in past jobs, and have quite often had users ask for the ability to have more than one assignee per issue.
I know this is possible in JIRA, but to my mind it never makes sense; an issue should represent a piece of work, and only one person can do a piece of work (at least in software, I've never used an issue tracker for a 2-man bobsled team ;-)) A large piece of work will obviously involve more than one person, but I think in that case it should be split into subtasks to allow for accurate status reporting.
Does anyone have any use cases where it's valid to have multiple assignees ?
The Assignee field means many things to many people. A better name might be "Responsible User". There are three cases I discuss with my clients:
A. number of assignees = 0
JIRA has an Allow Unassigned issues option but I discourage use of that because if a work item isn't owned by anyone it tends to be ignored by everyone.
B. number of assignees = 1
The default case
C. number of assignees > 1
Who is responsible for the work item represented by the issue? The best case I've seen for this is that when an issue can be handled by any one person in a team, so before triage the issue is assigned to everyone in that team. I think a better approach is to create a JIRA user with an email address that sends to the whole team, and assign it to that user. Then a member of the team can have the issue assigned to them in particular.
Changing the one assignee case has the history recorded in the History tab. Nothing is lost in that case.
I'll often have a story / feature that can be split across multiple developers. They will have individually assigned subtasks but it would make sense to assign the parent to all involved, unless there's a lead developer. I wasn't actually aware that I could do multiple assignments, so thanks for the tip!
The other case I can think of is pair programming.
I hit upon this question while looking for solutions to doing this. Since I want to do this, I'm guessing my use case counts as an answer to your question: I only really want one assignee in the sense of someone currently working on a problem, but I want to track the whole lifecycle of an issue. For us, that can mean:
A support person receives a report from a customer, creates an issue
An issue-wrangler reviews the issue to make sure it's valid, not duplicated, has all appropriate details, etc.
A developer implements/fixes the issue
A tester performs whatever tests are appropriate (in our case, mostly extending our automated testsuite to additionally test the feature/fix)
An operations person rolls out the new version to a test environment
A support person informs the customer, who does his own tests with the new version in the test environment
An operations person rolls out the new version to production
Not all issues necessarily go through all steps. Some issues have more steps (e.g. a code review between step 3 and 4). Many issues will also move backwards among the steps (developer needs more information, we go from step 3 to 1 or 2; tester spots a problem, we go from 4 to 3).
At each stage, only one person is actually responsible for whatever's got to be done. Nevertheless, there are a whole bunch of people who are associated with the issue. Tracking systems we've used are happy to offer easy changes to previous owners of the issue (shown as a list), but I'd ideally like to go a step further, with the owner automatically reverting to the correct prior owner depending on the issue's status. At step 6, the original support person from step 1 should ideally contact the customer. At step 7, the ops person from step 5 would ideally be the assignee.
In other words, while I don't want multiple assignees for a given step, I do want there to be a "support assignee", a "developer assignee", a "testing assignee", etc.
We can do this with subtasks and we can do it by manually selecting previous owners when changing statuses, but neither is ideal and I think the situation above is one where multiple assignees would make sense.
In my company, we have a similar workflow to Nikhil. We work in a scrum model, with developers, testers and a technical writer on each team.
The workflow of a development task is
Development -> Developer review -> QA testing -> PO Acceptance -> Done
The workflow of a QA task is
QA writes test case / automated test -> QA review -> Done
We had a tool which JIRA replaced that allowed us to assign multiple people to a task, which we found very useful for our workflow. On a QA task, I could easily see if the other tester on my team had already done work and I needed to do the next step.
Without this, I am finding it difficult to quickly identify tasks written by the other tester on my scrum team which are ready for me to review (versus the ones I wrote which they need to review).
So many people have asked for the ability to have multiple assignees since at least 2007. They have varying, valid use cases. I was disappointed that the JIRA development team unilaterally said they won't implement this and would ask them to reconsider.
https://jira.atlassian.com/browse/JRA-12841
While pair-group working (pair programming etc..) it would be nice to assign both persons to the issue.
Tasks move through different steps through development (example: Development, review, testing). Different persons can be responsible for each step. Even though the task may be in review or testing, the reviewer will have stuff fore the developer to fix. Having different roles to assign to would help organizing the work.
In our team we usually develop 1 or 2 persons together.
Then the code is reviewed by around 2-5 persons in individually or in pairs
Then it is tested by 1-2 persons initially, finally tested by the whole team.
Currently our system allows us to assign a single person at a given time. That limits our ability to follow who is working on what without looking through the log for the issue. The benifits of beeing able to assign multiple persons would be good for us.
What happens if John is assigned a task and cannot finish it, and it is moved to Jane's list because John was a slacker?
Are you OK with losing history of who it was originally assigned to, and the hours that were spent / billed on it?
In an e-Learning scenario, it makes sense to have an issue assigned to multiple users.
Here is what I want to do:
I have a storyboard which I want to assign to 3 people at the same time - the animators, the recording artists and the graphic designers. Once these people finish their tasks, they will pass it on to a common reviewer, who will review and close the issue.
Graphically it would look something like this:
Storyboard
/ | \
graphics animator recording
\ | /
reviewer
|
done
The three job roles depend only on one storyboard. The compilation of the three have to go to a reviewer. I'm racking my brains to get this working on redmine. Haven't found a solution yet.
Got this answer from an Atlassian partner https://www.isostech.com/solutions/
and then later from Atlassian
Objective:
Want to set who does the works for each step on an issue
Summary:
Use a plugin to copy values from custom fields into the assignee field whenever the issue transitions to a new step.
How:
1. Install the Suite Utilities plug-in:
This plug-in adds a bunch of new functionalities to workflows.
You will use the plug-in to copy the value of a custom field to the assignee:
Create a custom field as single user picker for each role i.e., dev, tester, reviewer to be assigned at different steps in the issue
Add these fields to the issue type's screen
Modify the post-function on the workflow transition between each step
Add a "Copy Value From Other Field" post function and set it to copy the value from the appropriate user custom field into the assignee field.
I have a set of User Stories and I have a set of business rules (primarily laws binding my requirements to be compliant). In Agile SDLC I'm not sure where these "rules" are attached to my user stories.
For example, a user story like:
As a doctor I want to add patient information in order to create a new patient file.
And a rule like:
The following information must be entered in the record of each patient:
(a) patient:
(i) name and given name;
(ii) address;
(iii) date of birth; and
(iv) sex;
These two clearly come together, but how can I link them? As test acceptance definitions in my user story? Another user story?
There are a few different ways I've seen this handled:
An artifact is created to hold the business rule and is stored in some central repository of all the rules so this is known throughout the development team and a storehouse of knowledge is maintained. This can get ugly as there can be hundreds of rules within just a few years of building out an application.
The rules may be put onto separate cards within the user story. Thus, while the user story is that one line, there may be 6-8 cards that make up all the tasks for that story to be completed. For example, there has to be a new patient form created, validation on the form, etc. Thus, it isn't hard to see this crop up down the line on a card as a way to track the requirement that way. This is the most natural to my mind though this isn't where the specific list is going to be 100% written down either as the card could be "ensure some fields on the form are mandatory."
There isn't an explicit link but rather the rule is something for QA or a BA to note for the user to verify that the form does enforce this rule. This is similar to one but the question is what is the responsibility of the developer in this. In this case, it is something for QA to track rather than developers possibly.
The user story is intended to start a discussion, not be a comprehensive list of the requirements. The rule is something that should come up when the developer discusses with the user what does it take to create a new patient file to my mind.
I like the idea of hanging on to cards for a few sprints after the story was done, but I do see the point that the cards will ultimately be destroyed. At the same time, there should be code somewhere that implements the rules in its proper area. To use the example you posted, it may be that in a few places the list of required fields would be noticed as there is the UI layer that has to show the fields and probably an error message but also there should be some Business Logic Layer that has this logic to see that some fields were specifically completed before trying to create a new patient file. The system being built will also house the rules in some form or other, too.
As acceptance criteria. After all these are rules that can be executed as tests. Definitely not new stories, that would just be wrong as there is no deliverable goal.