Projects vs Departments
Hello,
When we first installed RQM 1.0.1 we started with the idea of each "Project" being a department/product.
Ex:
IT
ProductA
ProductB
But in the latest release, it seems to offer a Project Timeline for your project to fill in. This seems to make the concept of "Project" to be this instead:
Ex:
IT-Helpdesk Application
IT-Office 2007 Deployment
ProductA - FP1.0
ProductA - FP1.0.1
ProductB - FP1.0
ProductB - FP2.0
Is this your take on the new setup?
When we first installed RQM 1.0.1 we started with the idea of each "Project" being a department/product.
Ex:
IT
ProductA
ProductB
But in the latest release, it seems to offer a Project Timeline for your project to fill in. This seems to make the concept of "Project" to be this instead:
Ex:
IT-Helpdesk Application
IT-Office 2007 Deployment
ProductA - FP1.0
ProductA - FP1.0.1
ProductB - FP1.0
ProductB - FP2.0
Is this your take on the new setup?
2 answers
Hi,
I think it all depends on the access/visibility level required in your organization. There are two levels where you can control visibility of test assets:
* Project Area
* Test Plan
The concept of project area was introduced in RQM to help isolate the test assets of one ro more projects from being visible to other teams. This could be very helpful if it is required to restrict the projects of one department or product to the team assigned to these projects.
A project area may correspond to a project, product, or department. If it is required to isolate the test assets of each project from other project teams, then you can create a project area for each project. This is similar to the second exmplae you mentioned.
If it's not required to isolate the test assets of projects that belong to one product/department (possible because the same team would be working on all these projects), you can create one project area per product/department. For each project of this product/department, you can create a separate test plan. Having all projects of a product (or department) included in one project area, you can use the dashboard to get overall test progress status info, something you can't get if you separate your projects in different project areas. You can also use of "categories" to make sure created test assets are linked to the proper projects/test plans.
Regards,
Sari
I think it all depends on the access/visibility level required in your organization. There are two levels where you can control visibility of test assets:
* Project Area
* Test Plan
The concept of project area was introduced in RQM to help isolate the test assets of one ro more projects from being visible to other teams. This could be very helpful if it is required to restrict the projects of one department or product to the team assigned to these projects.
A project area may correspond to a project, product, or department. If it is required to isolate the test assets of each project from other project teams, then you can create a project area for each project. This is similar to the second exmplae you mentioned.
If it's not required to isolate the test assets of projects that belong to one product/department (possible because the same team would be working on all these projects), you can create one project area per product/department. For each project of this product/department, you can create a separate test plan. Having all projects of a product (or department) included in one project area, you can use the dashboard to get overall test progress status info, something you can't get if you separate your projects in different project areas. You can also use of "categories" to make sure created test assets are linked to the proper projects/test plans.
Regards,
Sari