Qastation

Tailoring Vs Waivers / Exceptions

qastation — Wed, 13 Apr 2011 10:32:32 +0000

S.No	Tailoring	Exceptions / Waivers
1	Accounting of an SDLC activity in an alternate method.	Justification and approval for required SDLC activities to not be performed on a project.
2	Allows the standard guidelines to be modified to fit the need of the individual project. Provides flexibility in standard processes.	A formal exemption from the specific activities beyond standard guidelines. Allow software development processes to be adapted to meet the needs of individual projects.
3	Example of Process tailoring Project request document is not documented in the standard SDLC template, instead documented in project inventory repository or part of the scope document.	Example of process waivers Unit test plans and cases will not be documented for the project. Team accepts the risk of not documenting the test plans and cases.

Business Requirements Vs System Requirements

qastation — Sat, 12 Mar 2011 03:23:28 +0000

S No	Business Requirements	System Requirements
1	Business requirements are criteria in order for the software to be successful in meeting the user needs. Generally they focus on the “what” not the “how”.	System requirements address the “how” associated with the business requirements (the “what”).
2	Business requirements concern the business.	Software requirements concern the software solution to the “problem” stated in the business requirements.
3	Business requirements defined as benefits of the business desires.	Software requirements define what the solution must do (or be) to assure the business requirements.
4	Business Requirements are goals and targets the business wants to achieve. Examples: No: 1 jobs consultancy company	System Requirements are technical goals Example: Implement web based job portal.

Benefits of traceability Matrix

qastation — Sat, 12 Mar 2011 02:37:53 +0000

Demonstrate the relationship between the requirements to the system.
To ensure the design is based on established scope, business requirement or functional requirements.
To ensure that the design documents are appropriately verified, and that functional requirements are appropriately validated.
To track the requirements changes and their impact to the system
To demonstrate the system built met the functionality of the customer, end users needs and expectations.
At faster rate can trace back to the functionality/design/test cases, if there is means of any defect/changes to the system.

Mapping SCRUM Methodology with ISO 9001:2008 standard

qastation — Fri, 03 Sep 2010 09:58:33 +0000

There is always a question in the forum, is it SCRUM methodology practices can be mapped to ISO 9001:2000 standard. The answer to the question is yes, we can. The mapping of the SCRUM Methodology to ISO 9001:2008 is as below (please correct me if am wrong in the mapping):

Role	Duties	Artifacts	ISO 9001:2008
Product Owner	Sprint Planning Sprint Review	Product Backlog User stories	*Clauses*: 4.2.3, 4.2.4, 5.2, 7.1, 7.2, 8.3, 8.5.2 & 8.5.3
SCRUM Master	Sprint Planning Daily Standup Meeting Sprint Review Retrospective Meeting	Sprint Backlog Burn-down Chart	*Clauses*: 4.2.3, 4.2.4, 5.5.1 5.5.3, 7.1, 7.3.5, 8.2.1, 8.2.3,8.2.4, 8.3, 8.4 & 8.5
SCRUM Team	Sprint Planning Daily Standup Meeting Sprint Review Retrospective Meeting	Sprint Backlog Burn-Down Chart	*Clauses*: 4.2.3, 4.2.4, 5.5.3, 7.1, 7.3, 8.2.1, 8.2.3, 8.2.4, 8.3, 8.4, 8.5.2 & 8.5.3

How Risk Management is implemented or managed in SCRUM?

qastation — Fri, 03 Sep 2010 05:07:40 +0000

For any management (Project, Configuration, Change and etc…) to implement in any methodology we need to identify during the initiation of the project. Same thumb rule is applied here in SCRUM.

Majority of the projects are failed due to the poor understanding of the requirements. Communication between the client and development team is missing in the traditional methodology i.e. effective communication. Interim the client won’t involve in the development process at all once he/she had given the requirements. This is flaw in the methodology is overcame in the SCRUM. That’s the success key of the SCRUM.

Also during the SPRINT planning meeting, the team gets clear view of what they need to develop and what are the acceptance criteria to fulfill the requirements? Details study of the requirement is done during the initial discussions, which leads effective estimation. So the misunderstanding of the requirements and acceptance criteria, the greater risk is addressed in well to do manner.

As we said in the earlier post, the Assumptions, Constraints, Dependencies, Communication, Reviews, Plans are well established and executed in the systematic manner. This leads to quality product.

Also if the team faces any issues during the execution, he/she may raise it during the daily standup meeting and logged as impediments. It’s responsibility of the SCRUM master to address this issues / impediments before they turn as risk for the project.

How SCRUM Methodology is different from the traditional methodology?

qastation — Thu, 02 Sep 2010 12:13:21 +0000

This is most frequent question we hear in the arena of SEPG. Will try to address it in the forum to the best and appreciate the viewer’s response.

As part of the engineering position SCRUM is no different from normal traditional methodology of SDLC (Iterative method), but the way the project management is implemented in the SCRUM is interesting and appreciable.

In the traditional methodology the managerial position is done by managers, whereas is in SCRUM it is responsibility of SCRUM team to do that. For example in traditional, estimation is done by head or manager where as in SCRUM it is done by team in conjunction with product owner and SCRUM Master during the SPRINT Planning Meeting.

Assumptions, Constraints and dependencies (ACD) are documented by manager but the implementation rate is very low, whereas it is plugged or enable in the SCRUM through the channel of Daily standup meeting.

Communication Plan / Escalation plan is documented in the traditional methodology but the usage of the same is minimal whereas it is implemented effectively through daily standup meeting here in SCRUM.

Sprint Review meeting is the channel through which the acceptance criteria for the product is met in the SCRUM methodology. Also it’s the responsibility of the SCRUM team to demonstrate the product to the product owner and prove that things are done according to the definition of Done (DOD). We mean to say SCRUM team defines the boundary of acceptance criteria during the Sprint Planning, whereas in the traditional methodology no where the team which is going to develop the product involved to define the criteria for acceptance.

Changes during the SCRUM are not allowed is the Thumb rule in SCRUM.

Configuration Management should be take care during the Zero sprinting or during the Sprint Planning a line item, need to be addressed.

Lessons learned during the project are not documented in formal or informal manner in the traditional whereas here it is reported through retrospective meeting in SCRUM.

Implementation of the Risk Management in the SCRUM will post later.

Requirement Management Vs Requirement Development

qastation — Tue, 20 Jul 2010 11:35:03 +0000

S.No	Requirement Management	Requirement Development
1	An Engineering process area at Maturity Level 2	An Engineering process area at Maturity Level 3
2	REQM is to “manage” the requirements of the project’s products and product components.	RD is to “produce” customer, product, and product component requirements.
3	REQM identifies inconsistencies between requirements and project’s plans/work products	RD analyzes the customer, product and product component requirements.
4	Deals with communication between Requirements analysts and customer. RM is customer management oriented.	Deals with communication between PM, domain and functional architect, designer and his team. In object oriented domain, it relates to defining services.
5	Specific GoalSG 1 Manage Requirements	Specific GoalSG 1 Develop Customer Requirements SG 2 Develop Product Requirements SG 3 Analyze and Validate Requirements
6	GP 2.3 REQM uses requirements tracking tools, traceability tools and bi-directional matrix to manage requirement changes	GP 2.3 RD uses requirements specification tools, simulators, modeling/ prototyping tools, scenario definition and management tools.
7	GP 2.5 REQM training includes:Application domain, Requirements definition, analysis, review, Configuration management and RM tools, Negotiation and conflict resolution	GP 2.5 Examples of RD training includes :Application domain, Requirements definition, analysis and requirements elicitation, Requirements specification, modeling and tracking
8	GP 2.6 REQM deliverables placed under configuration management are requirements and requirements traceability matrix.	GP 2.6 RD deliverables placed under configuration management are customer requirements, functionalArchitecture, product and product-component requirements and Interface requirements.
9	GP 2.9 Work products reviewed include requirements and requirements traceability matrix.	Work products reviewed include product and product-component requirements, Interface requirements and functional architecture.

Establishment of QMS or ISMS or integration of both at your budget

qastation — Sun, 23 May 2010 09:37:52 +0000

Dear friends,

Hereby we are happy to say that we happy to help you in establish the Quality Management System or Information Security Management System or integration of both.

We can help you to define, implement and assessment of the process at your budget. We do for small and middle firms, around the globe.

We have experts in traditional methodology as well as Agile in align with ISO and CMMI standards.

Approach us for your queries to qastation@gmail.com

Audit Vs Assessment

qastation — Sun, 10 Jan 2010 10:33:16 +0000

Audit Vs Assessment

S.No	Audit	Assessment
1	To verify the conformance of an entity to a given standard. It consists in gathering evidence of conformance or nonconformance.	Evaluates the efficiency and/or effectiveness of an entity and results in a measure of its performance with regard to the scope of the assessment.
2	Verification and inspection are synonyms of audit.	Appraisal and evaluation are synonyms of assessment.
3	An audit might explicitly point at specific people or groups of people as the cause for noncompliance (attribution).	An assessment does not evaluate individuals (non-attribution). Of course, the result of an assessment might still be used to infer responsibility for failure or low scores
4	Example of audit: Verify all the practices established in the organization is followed or not.	Example of assessment: Evaluate the CMMI level of an entity.
5	An audit results in a success or a failure	An assessment usually provides a score that does not express success or failure

Implementation of QMS (Part4)

qastation — Sat, 03 Oct 2009 07:08:17 +0000

Learn From Others & Share Your Experiences

As it was trail or test ride, implement the same across the organization at full fledge, since the procedures / process is matured one now. For implementation of the procedures / process to the full fledge the existing team which is already had used, need to spend time to share their experience with others and help them to get learned.

Quality is a team work rather than individual one.