I made pretty much clear about why i entered into blogger, in my first blog "My first blog!". I want to learn while sharing my thoughts with others, please correct me if i am wrong in future. Here I can remember the saying "Learn by our own mistakes" this carries weight-age which everyone call it by their experience. you will agree upon me or not?
I told in my last blog "What is software testing? why its necessary?" i am going to write upon the SQA and SDLC life cycle.
let me choose the first one which is SQA.
SQA - stands for the Software Quality Assurance. Every company will have team called SQA or QA team.
Quality assurance life cycle includes the whole process of checking the quality of the software being tested from the planning phase of the development process till the product is deployed to the clients.
The phases which includes
1. Initial Phase:- This phase includes the collecting the Business requirement and analyzing, project planning which inturn includes the resource and time management other stuffs (Budget and others).
2. Analysis:- Collected Business requirements need to analyzed and come up with technical document which is called SRS- software requirement Specification which inturn should be approved by the customer.
3. Design:- This phase includes the High level design/low level designs for the project to develop.
4. Coding:- The coding is done as per the design by the developer team and do the integration with other modules.
5. Testing:- this phase tester will receive the product/modules to test. Tester have to verify and validate the product functionality as per the requirement (SRS).
6. Delivery/Maintenance:- After completion of the development and testing activities the product should to deployed or delivered to the client. If client wants the service from the product maintenance he can acquire, the company will give the service for the client. Maintenance phase may include the new features to the existing and any new features can added. This again will include the SQA life cycle.
SQA decides the which software life cycle is suitable for the organization, based on the experience of the SQA team over a period of successful projects. There will be a continues process improvement based the last project learning's.
SQA key role is improve, maintain the quality tag for the organization by auditing the project managements.
The project management includes the SDLC, which will define the phases of the software development life cycle.
There are many software models which are proposed and practiced by the organization are listed as below.
1. Waterfall model
2. V - model
3. Iterative model
4. Prototype model
5. Spiral model
now we are hearing new models which are practiced in current projects which includes
6. Agile software development model
and so on..
Now we will dig one by one in details...
- Waterfall model:
The simplest softwar
e development life cycle model is the waterfall model, which states that the phases are organized in a linear order. A project begins with analyzing the requirement and freezing it. On the successful completion of the analysis phase the requirements are analysed and project planning begins.
The design phase starts after the requirements analysis. And coding begins after the design is done. Once the programming is completed, the code integration and testing is done. On successful completion of testing, the system is ready of the release. After this the regular operation and maintenance of the system takes place.
Disadvantage of waterfall model:
Waterfall model has linear ordering of phases, which is after each phase is completed and its outputs are certified, these outputs become the inputs to the next phase and should not be changed or modified. However, changing requirements cannot be avoided and must be faced.
- V-model:
In V model SDLC the first and far-most the Business requirements are collected by the Business analysts or a business manager who has a direct interact with the client/customer. So collecting the business requirements and base-lined by the business analyst. After collecting/writing the business requirement specification (BRS) the Lead or few team member (Team of development and testing) involve in analyzing the requirement the phase will called Discovery phase. The output of the discovery phase will be a complete SRS (Software requirement spec) document, Project plans from the Project manager, test plan from the test lead/manager to continue the testing phases.
All the above documents should be Reviewed/approved by the client before team going for next task in V model.
The SRS/project plan/Test plan: these are the documents which are the sources for the developer and tester to execute (i.e., work) the product with the proper plan.
Note: Project Plan and test plan documents are alive till end of the project.
The left-side of the V-model
The next level at the left side of the V-model is to convert all BRS to SRS. and each software requirement is drilled down to the system specification, next design the system design (like DB Design for the particular project, designing the architecture which is suitable for the project to complete). Then divide the system design into the system design in to components and modules (like Bit/byte level or low level design). Then the developer will code the components or modules as per the low level designs to bring the component/module working.
The right-side of the V-model
The testing team will also involved at the same time as developer team is involved.
User acceptance level the test team will prepare the User acceptance plan as per the BRS. later drilled down to SRS. Test lead/manager will prepare this document which will be alive till end of the project. this document should be reviewed and approved by the client.
In next level which is called acceptance testing, in this phase a group of testing team will involved in writing the test cases for the acceptance, which includes the high level (highly recommends real time users scenario's) test cases or may be collected from the client based on their experience in the industry(clients will help based on particular industry, they know what their users will use more, functionality in the product).
Next level the testing team will involve in writing the system test cases after analyzing the system (this like real users scenario's) which will cover the high level system requirements. The system testing team later execute the application by applying the system level test cases to complete the system testing phase.
Next level the testing team involve in writing the test cases for the functionality between the components/modules which is called integration testing phase. where the interface requirement are converted to test cases. when this team will get a integration build they apply the integration test cases and complete the integration testing phase.
Next level component/module testing, this is also called with most popular name "Unit testing or component testing" where the tester will be involved in component testing and developer involved in Unit testing.
The actual flow will be a writing 'V' in English i.e., drawing a slant line from top Left to bottom right and from that point to slant line will continue from bottom left to top right. :)
- Iterative model
The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented. At each step extensions and design modifications can be made. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model.
Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available. The process involved in iterative enhancement model is shown in the figure below.
The project control list guides the iteration steps and keeps track of all tasks that must be done. The tasks in the list can be include redesign of defective components found during analysis. Each entry in that list is a task that should be performed in one step of the iterative enhancement process, and should be simple enough to be completely understood. Selecting tasks in this manner will minimize the chances of errors and reduce the redesign work.
- Prototype model
Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.
Please find the below figure shows the prototype model
- Spiral model
The Spiral model is followed where the requirements are changed quicker and there is no clear requirement. As the name suggests, the activities in this model can be organized like a spiral.
The spiral consists of many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. The structure of the spiral model is shown in the figure given below. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints.
The development spiral consists of four quadrants as shown in the figure above
Quadrant 1: Determine objectives, alternatives, and constraints.
Quadrant 2: Evaluate alternatives, identify, resolve risks.
Quadrant 3: Develop, verify, next-level product.
Quadrant 4: Plan next phases.
Although the spiral, as depicted, is oriented toward software development, the concept is equally applicable to systems, hardware, and training, for example. To better understand the scope of each spiral development quadrant, let’s briefly address each one.
Quadrant 1: Determine Objectives, Alternatives, and Constraints
Activities performed in this quadrant include:
1. Establish an understanding of the system or product objectives—namely performance, functionality, and ability to accommodate change.
2. Investigate implementation alternatives—namely design, reuse, procure, and procure/ modify
3. Investigate constraints imposed on the alternatives—namely technology, cost, schedule, support, and risk. Once the system or product’s objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.
Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks
Engineering activities performed in this quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. Boehm describes these activities as follows:
. . . This may involve prototyping, simulation, benchmarking, reference checking, administering user
questionnaires, analytic modeling, or combinations of these and other risk resolution techniques.
The outcome of the evaluation determines the next course of action. If critical operational and/or technical issues (COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if the alternative chosen is “operationally useful and robust enough to serve as a low-risk base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) . . . the option of writing specifications would be addressed but not exercised.” This brings us to Quadrant 3.
Quadrant 3: Develop, Verify, Next-Level Product
If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs, activities to develop, verify, next-level product are performed. As a result, the basic “waterfall” approach may be employed—meaning concept of operations, design, development, integration, and test of the next system or product iteration. If appropriate, incremental development approaches may also be applicable.
Quadrant 4: Plan Next Phases
The spiral development model has one characteristic that is common to all models—the need for advanced technical planning and multidisciplinary reviews at critical staging or control points. Each cycle of the model culminates with a technical review that assesses the status, progress, maturity, merits, risk, of development efforts to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral.
Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations.
End of each SDLC will have the following minimum output documents and forms.
- Requirement document (SRS)
- Project plan
- System design document
- Detailed design document
- Test plan, test cases and test/bug report
- RTM - Requirement traceability matrix
- Final code
- Software manuals (user manual, installation manual etc.)
- Review reports
