Should a process be rigid or flexible.What is the best among these two?Thanks in advance
The situation you find yourself in should determine the processes used, I would personally favor the building in of risk management in such a way that deviations from expected outcomes is assessed and reacted to appropriately. It can depend on a few things though. If you are in a level 1 CMM organisation, the priority is establishing a procedure that everyone follows. It is hard to improve a process when you haven't got one!!!
Neither - but it should work!
There are three golden rules for a good process:
1) There is a process (there is always a process)
2) The process is understood
3) The process is followed
If it is not understood it cannot be followed. If it inhibits the creative freedom of talented individuals it is unlikely to be followed.
If you are working for an existing software company then there is some way that you have been producing software.
I suggest you start by working out how to describe the process you already have then start making careful step-wise refinements. Always be prepared to prove your self wrong.
If you wish to know how to assess you process here are 16 critical elements of a good process. You can base a 'Develpoment process testplan' on these :-
1) Process road map. Where am I? Where am I going? Where in the development process is the product or component? Where is it going? Should be answerable at any point for any person, deliverable or component.
2) Process control. Does each individual have the feedback, education and opportunity to improve those parts of the process with which they are most directly concerned?
3) Quantification of metrics. Do you have them? Do you know the limits of their accuracy? Do they have a defined purpose? Can you tell if they are actually fulfilling that purpose?
4) Configuration control. About any product of our labour we must strive to be able to answer the following: Who? What? When? Where? Why and how?
5) Requirements. What are we building? Does everybody know? Does everybody understand the same thing?
6) Requirements Traceability. Where did the requirements come from? Can requirements be mapped onto software and vice versa?
7) Strategic mores. Beyond mere utility (functionality), what does our software do? Enhance reputation for quality and delivery? Go faster than the opposition? Keep your data safer than our competitors. Which of the hundreds of potential strategic mores do we, as an organisation, prioritise?
8) Requirement Validation Criteria. What are the objective satisfaction criteria associated with each and every requirement?
9) Responsibility. Who is responsible for what and when?
10) Exit Criteria. How do we know when a given fruit of our labour is ready to go to the next stage of the development process? What are the tangible, objective signs of completion?
11) Entry Criteria. Not the reverse of exit criteria. For a specification, there are different entry criteria for customer sign-off, development and testing. The Exit criteria is the aggregate of all entry criteria.
12) Analysis. The engineering process by which a design evolves that fulfils requirements. Is this process formally and unambiguously communicated to all?
13) Design. Do we put design first? Paper errors are cheaper than code errors.
14) Design Validation. Not the same as validating the implementation of the design (thatís software testing). How do we know if a design will work if we have never built this before? Is this done by modelling? By prototyping? Or by design inspection?
15) Programming. The practice of coding a design then testing it to see that you have built what you intended to build. How do we know what our programmers have tested?
16) Testing. Required because people are involved (and people make mistakes). Do we test everything that could introduce a defect at any stage? Or do we just test the software?
All this is adapted from the works of Boris Beizer who I highly reccomend reading.
Softly, Softly catchee monkey...
Processes should also be made to be people/tool independant and should be dependant on roles. My last company did the same mistake .. they made to tool specific processes and it become a big hassle later!
Well the process should be flexible and should be tailor made at any point of time or depend upon the type of project.
It should be easily understandble to the enduser. If end user doesnot understand ur process easily, its hard to implement and incorporate quality system. in ur org.
So Process should be Flexible and easily understandble. Main thing is, it should be tailor made at any point of time/ or project
I go for the best bcoz. i am the best.
I think the most important thing is to determine whether it needs to be flexible or rigid... when a brand new process is implemented, you will sometimes have to be rigid in order to get the point across and get people used to using it. When releases are coming at noon on Friday for Saturday AM deployment, you need to be rigid.
However, when defects are effecting user functionality, or there are good, necessary reasons for being more flexible, even if temporarily, you sometimes have to bend the rules to get what's needed, and keep the project on track.
As someone else pointed out recently - the best response to most SQA questions is "It Depends".
"I realize it's an error, but no one is going to try to do that!" From "Top 10 Stupid Comments from Developers"
Something shamelessly stolen from the STQe-Letter for today...as I think it is somewhat relevent to the discussion at hand:
"When it comes to testing, I doubt if it is ever useful to be 100 percent systematic or 100 percent free form. It's probably not even possible. The question is to "just
know" (intuitively?) the best mix for a given exercise.
While testing involves systematic procedures, it may also benefit from free form testing--trying to imagine anything
that a user might do. Exploratory Testing can include a lot of systematic exercises. As James Bach has noted, it's a matter of HOW exploratory one's approach is, and
where it's used in the process. Free form "banging on the software" is primarily exploring with intuition--putting yourself in the shoes of diverse users. Many testers with the "magic touch" who can "break anything" have developed this intuition. Here are three questions: 1. Do you think
this intuitive free form testing is a valuable supplement to more systematic testing? 2. Do you view yourself as more systematic or more free form? 3. Does it depend on the project?"
My two bits...adjusted for inflation.
"The single biggest problem in communication is the illusion that it has taken place."
-George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950