My company needs an Issue Tracking System. There are a lot of tools available on the internet and I have tried some (JIRA, Asana, Bugzilla to name a few). Most of them are great in the job they do. But we have a specific requirement that none seem to cater to. We need to implement a hierarchy in which certain users would have access to only certain parts of the system. Could you please suggest me a tool that could do what we want. May be the tools I tried do enable us to implement this hierarchical structure and couldn't figure out how to do it. In that case could you guide me as to how this could be done using the tools I have tried. It would be highly preferable not to develop the system ourselves owing to the time that would be consumed.
Thank you!
The hierarchy would be as follows:
P.S. - We are not an IT-based company. Hence, 'Site' does not refer to 'website'. Site is a geographic area which comprises of smaller units called locations where facilities are located. These facilities have certain resources that at times break down, a situation which needs to be efficiently tracked and be dealt with. Employees on-site would report issues which would be assigned to maintenance teams who would take care of the issue. The progress of the process of resolving the issue should also be tracked.
I believe you could accomplish your goal using Bugzilla. Although Bugzilla doesn't have hierarchical security groups per se, you could create groups with obviously hierarchical names, one for each node in your graph, e.g. site1, site1-location1, site1-location2, site1-location1-resource1, etc. You could then assign each employee every group in the chain from the lowest to highest, e.g. (following your graph again), a user might have the groups site2, site2-location1, site2-location1-resource3. Then you can assign each bug a group according to how many people should be able to access it; e.g. site2 if's a site-wide issue, or site2-location1 if it's a location-wide issue, and so on.
It's a bit tedious but you could write some scripts to automatically give those security groups to each employee based on their most specific permission level.
Related
I have recently been tasked to look into Workflow Foundation. The actual goal would be to implement a system in which the end users can define custom workflows in the deployed application (and of course, use them). Personally I have never used WF before (and reading around here on SO people are very doubtful about it - so am I reading those questions/answers), and I am having a hard time finding my way around it given the sparse learning resources available.
Anyway, there are some questions, for example, this, which mention something they call dynamic or user-defined workflows. They point out that WF makes it possible to "rehost" the designer, so that end-users can define their own new workflows after the application is deployed (without developer intervention (?), this is the part I am not really sure about).
I have been told by fellow employees that this way we could implement an application in which once this feature is implemented we would no longer have to keep modifying the application every time a new workflow is to be implemented. However, they also pointed out that they just "heard it", they don't have firsthand experience themselves either.
I have been looking around for samples online but the best thing I could find was a number guess app - barely more than a simple hello world. So not much that would point me to the right direction of how this user-defined workflow feature actually works and how it can be used, what its limitations are etc.
My primary concern is this: it is alright that one can define custom workflows but no workflow is worth a penny without the possibility of actually inputting data throughout the process. For example, even if the only thing I need to do is to register a customer in a complaint management system, I would need the customer's name, contact, etc. If the end user should be able to define any workflow the given toolset makes possible then of course there needs to be a way to provide the workflow consumers with a way of inputting data through forms. If the workflow can be of pretty much any nature then so needs to be the data - otherwise if we need to implement the UIs ourselves then this "end-user throws together a workflow" feature is kind of useless because they would still end up at us requiring to implement a form or some sort of data input for the individual steps.
So I guess that there should be a way of defining the "shape" of the data that needs to be filled at any given user interaction phase of the workflow which I can investigate and dynamically generate forms based on the data. So for example, if I found that the required data was made up of a name and a date of birth, then I would need to render a textbox and a datepicker on the page.
What I couldn't really figure out from the Q&As here and elsewhere is whether this is even possible. Can I define and then later "query" the structure of the data to be passed to the workflow at any point? If so, how? If not, how should this user-defined workflow feature even be used, what is it good for?
To clarify it a little, I could imagine something as specifying a complex type, which would be the view model (input model) in a regular MVC app, and then I could reflect over it, get the properties and render input fields based on that.
Windows Workflow Foundation is about machine workflows, not business workflows. True, it is the foundational tool set Microsoft created for building their business workflow products. But out of the box WWF does not have the components you need to quickly and easily build business workflows. If you want to send an email in a workflow, you have to write that from scratch. Just about anything you can think of doing from a business point of view you have to write from scratch.
If you want to easily create business workflows using Microsoft products check out the workflow stuff in SharePoint. It is the easiest of the Microsoft products to work with (in my experience.) If that does not meet your needs there are other products like BizTalk.
K2 is another company with a business workflow product that uses WWF as their base to more easily build business workflows, the older K2 products actually create web pages automatically to collect the data from the user.
WWF is very low level, arguably it lost traction after they re-wrote the whole thing in 4.0. While not publically stated by Microsoft, my personal opinion is Service Fabric (from Microsoft) achieves the goals WWF originally tried to solve which was a "more robust programming environment."
I know that some website are applications, but not all websites are applications (albeit maybe just a brochure viewing site)
Is there an in depth dummy use case for a brochure type site which would be beneficial to use.
When it comes to a corporate front facing website for example I suffer from feature blindness, although for an actual database driven application (for example a purchase order system) I feel within my element.
Is there any resources that can help me view "brochure" sites in the same light than I do with a pro bono database driven applications.
This is really useful thread. I have always battled with use cases for brochure sites, despite totally espousing the use of UML... I often feel caught between UX agency outputs & trying to ensure the whole Requirements Spec ties together, especially when agencies tend not to use UML.
There are several use cases that do apply beyond view menu / view brochure page - site functionality like print page, search site etc, sometimes accept a cookie to view specific content - but not much on classic brochure-ware. (All that ties well into user journeys / personas without having to restate the UX deliverables)
However, once using a system eg a CMS to create the website content - then I think the use cases get properly useful (as per comments above), as there are not only (usually) several actors inc the system, but also varying cases per content type so you can reference those UX deliverables without duplication and start filling in the gaps, plus tie up content strategy type deliverables (eg workflow & governance) by looking into the business processes and the system / user interactions. At the end of the modelling & specifications, you can get useful test matrices this way; plus class diagrams that relate objects to taxonomies (more agency deliverables to tie together in Functional Rqmts / Specs stage).
That's the way I'm trying to tackle it these days.
Use Cases can be used to model requirements of a system. System is a structure with input and output mappings. So if you have a static web page, you cannot interact with it in a other way than to view it.
As discussed in comments, if you think you did not understood the goals of stakeholders (what that word document sent by your boss ment...), you have to ask more and find them, use cases are a good technique for this.
In a cycle, discover actors (systems and roles interacting with the system you have to develop) and use cases (what needs of those actors the developed system should ssatisfy). Every time you find an actor, you may ask what other needs (possible use cases) he has and when you find an use case, you should ask who will participate in it and who is interested in it (who is the next actor and who are the stakeholders). Then you can define the scope boundaries and prioritize...
There is Ruby on Rails (1.8, 2.3.2) project. First version of project was made by some organisation. I will implement next versions of this project without any help from this organisation. I will be able to talk with developers from previous development team during meeting (1-3 hours).
Project statistics: ~10k LOC, 1.0/0.6 code to test ratio, rspec
What questions about project can you recommend to ask?
First review the entire project and to figure out as much as possible so you have context and can actually understand what they tell you.
Ask
If you can record the conversation
For an architectural overview
Why they made certain architectural decisions over another
A complete list of dependencies (if you can't figure that out on your own)
What the biggest problems are
Which parts of the projects are always / never being fixed
What the Achilles' Heel of the project is
What will cause the biggest headaches
What security issues are there and what the constraint is to fixing it
What would you do next if you were me?
What you should know that you didn't ask (most important question)
Also, don't be judgemental, you want them to reveal any problems they know about. There are probably tons of things wrong with the app that they are embarassed about, which you need to know sooner rather than later. They're not going to open up to you if they don't trust you.
I would ask for a code walkthrough. Not line-by-line, but more for the overall structure of the project, relationships between individual modules, etc.
Find out the Why's. How is easy enough to see in the codebase, but the why is sometimes impossible to figure out, and will bite you in the ass.
For instance...
Which parts of the application were the biggest performance issues? Which of those issues were resolved? Which are still issues?
Why did you opt for pattern / tool / library x? What other things did you consider? Why?
This will hopefully. (Hit some wood.) Help keep you from having to trudge through the same learning curve and mistakes that the first team had to deal with, and should give you good insight into where the first team actually made a poor choice, instead of making a choice based on factors you have not accounted for yet.
Ask if the new features will cause any major changes to the existing code (architecturally) and what the implication of that will be with other dependent parts of the application.
Also get their emails, as you will have more questions.
One of the most important things, in my opinion, is to get as much technical documentation as you can prior to meeting with them. You should try to go into the meeting as informed as possible, so that you not only know what areas you need to focus on the most, but also to have a preexisting knowledge of how some of the subsystems relate to each other.
Also, do not be afraid to ask what they would have done differently, if given the chance. Some of the best ideas come too late in the development process to be implemented - be it from library availability, change in requirements, change in team, etc.
Bring cookies (or pizza, beer, or wine as appropriate); you will want them to have positive memories of you for when you call with questions.
Edit: to put my answer in the form of a question: "May I offer you a home-baked cookie?"
Perhaps you have done this already, but I would make sure you can:
Checkout the latest version
Run all the migrations
Run all the tests
Deploy (even if to a staging server)
Run the application locally
Before you go to the meeting, so you can make sure you can by the time it is over.
Other things that might be useful
data model
UI wireframes
bug tracker data / issue tracker data
who are the customers / people representing customers
development environment configuration
source control locations, etc.
explanation of special configuration settings
Wow! All great answers, right down to the cookies.
My contribution assumes that this is your one and only chance to access the old dev team, therefore you need to kick it up a notch:
Agenda. Split the meeting into several parts, for instance:
A quick (15 min) introduction and arch overview
One on one with team members.
Design review as a group, etc.
Positive Energy. Especially if the relationship is inherently difficult, keep a positive focus by postulating: what improvements would you put into the next version - (rewrite is not an option, right Joel) - capture every nuance, and drill down past their comfort level only nearer the end.
Facilitator. Use a trained design meeting facilitator. They can help prep for the meeting, conduct pre-meeting interviews, design the agenda. During the meeting they can drive the intensity, and keep the focus. They can also suggest forms of capturing what can be a fair amount of information.
Also, I would try to id all design artifacts beyond the code, if any, and come to an understanding of how accurate it is. This may include doing design reviews of key elements of these documents vis a vis the as-built system.
Don
For example team A and team B are working on different applications that need to implement a similar feature. The feature in question relies on a database and the database is under the control of team B. Even though the user interfaces of the two applications are based on different technologies, the functionality is supposed to be roughly the same. Both teams have their own requirements and design documents. The functionality can be changed based on feedback from either team but then both teams have to update their requirement and design documents.
The teams are geographically distributed and members of each team itself are also geographically distributed. Both teams work with the same client entity but different people. Each team has their own business analyst (requirements specialist).
I am trying to make the technical communication between the teams more formal than email so that we can avoid misunderstandings.
How do you make sure that if team B changes the database and or the feature functionality, the other team gets properly notified about it? Do you use some formal text based documents such as interface contracts? Can you share any templates for those? Or do you use some other mechanism?
A couple of things from my own experience (which sounds very similar to yours)
You should try and have a single design document for the database part of the solution which as djna suggests should be posted on a wiki or similar, with a defined public contract for interaction with the data. This is a good step in the right direction, as it will give everybody a kind of 'shared vision' which helps people converge towards doing the right thing. The contracts should try to ensure that the data access is done in a standardised way.
However, from experience, the code does not always follow the spec exactly, so i would also assign a single owner from one of the teams, whose responsibility is the integration of both systems to the database.
i would then implement a continuous nightly build process with tests, and this build should include the database. This will hopefully flag any issues earlier in the process.
From the project i worked on, you may still have occasional disagreements and breakdowns, eventually we merged both teams. This was the best solution of all for us!!
Hope this helps a little
What about having a Team site (both as one team) or a Wiki so that both teams are aware of the change.
Regular stand-up meetings. Via a conference call. Stand-up == brief, highly focused, information centered. Delegate discussion to individual discussion outside meeting, reporting back at next.
There does need to be an overall authority though, to mediate where agreement cannot be reached and to ensure overall solution integrity.
I agree with Wiki or other collaborative site for publishing the current reality.
I know there is a lot of talk about BPM these days and I am conscious that some may see it to be a craze rather than a fundamentally important piece of software.
As someone from what most would call 'The Business', I have been doing my best to learn about BPM to ensure we continue to make decisions that not only make sense to the business, but IT as well.
I have noticed while reading that mention is made to application workflow when sometimes discussing BPM. I hadn't given this much thought until recently.
Therefore, what is the difference? When would you use one and not the other?
BPM is about the process and improving it, which takes into account users and potentially more than one application,e.g. an ERP system may have more than one application to it, though there may be other uses of the term. Note that the process could be viewed without what applications or technologies are used.
Application workflow is how an application is used to go from a to b. Here it is a specific set of code that is used and what happens over the course of an application getting from a to b. In this case, the application is front and center rather than the process.
Does that provide an answer? Another way to think of it is that multiple application workflows can make up a system which is used in a process that can have BPM applied to it.
Late to the game, but workflow is to database as BPMS is to DBMS. (Convenient how the letters line up, huh?)
IOW, BPM(S) is traditionally meant to refer to a particular framework/application that allows you to manage business processes: defining them, storing them, versioning them, measuring them, etc. This is similar to how a DBMS manages databases.
Now, a workflow is a definition, much like a database is a definition. In the former case, it is a definition of operations/work (Fufill Order), steps thereof (Send Invoice) and rules/constraints on the work (If no stock, send notice). In the latter, similar case, it is a definition of data structure (CREATE TABLE) and constraints (InvoiceTotal must be > $0.00).
I think this is a potentially confusing subject, particular as some development environments use a type of process flow model to generate user facing applications (I'm thinking about Outsystems here, for example).
But, for me, the distinction is crystal clear. Application workflow, as people talk about it, refers to a user's path through an application, i.e. the pages they complete/visit, the data they enter, etc. on their way to completing a transaction of some sort. Application orkflow is a poor term for this though, I think application flow would be more meaningful.
BPM on other hand, is about modelling and executing a workflow process. By workflow, in this context, I mean a series of discrete steps (or tasks) that have to be completed (either programmatically or via human interaction) in a certain order to complete a process. These tasks can be implemented as individual application modules (each with their own "application workflow", see above). The job of the workflow engine is to make sure that these separate steps are assigned to the right people (of groups of people) in the right sequence, and that overall the process completes in an orderly way.
I don't think there's a clear answer to this at all. These are words, as opposed to theoretical concepts. If you add the word "checklist" into the mix - that just turns out to be a linear version of a process (but you can have conditionals in checklists - making them a workflow).
I am not sure how to help in reframing this question, but it's almost as if no answer can ever be possible. My own thoughts are at https://tallyfy.com/improving-efficiency-workflow-vs-business-process-management/