Table of Contents

1 SDLC process: (Software Development Life Cycle).....................................2 2 Software Development Models.................................................................2

2.1 2.2 2.3 2.4 2.5 2.6 Big Bang.......................................................................................................2 Code and Fix..................................................................................................3 Waterfall.......................................................................................................3 Spiral...........................................................................................................4 Agile.............................................................................................................6 V Model.........................................................................................................7

3 STLC process (Software Testing Life Cycle)...............................................9 4 Bug Life Cycle.........................................................................................10 5 Product Life Cycle...................................................................................11

Viraj

Page 1 of 11

SDLC process: (Software Development Life Cycle)

The Software Development Life Cycle relates to models or methodologies that people use to develop systems, generally computer systems. A number of system development life cycle (SDLC) models have been created: Waterfall, Fountain, Spiral, Build and Fix, Rapid Prototyping, Incremental, and Synchronize and Stabilize. There is not a definitive correct model, but the steps can be characterized and divided as follows:

1. Project planning, feasibility study, Initiation:

To generate a high-level view of the intended project and determine the goals of the project The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding Projects are typically evaluated in three areas of feasibility: economical, operational, and technical. (Post & Anderson, 2006)

2. Requirements gathering and Systems Analysis:

Analyses project goals, breaking down functions that need to be created, and attempts to engage users so that definite requirements can be defined

3. Systems design: Functions and operations are described in detail, including screen layouts, business
rules, process diagrams and other documentation The output of this stage will often be the technical specification

4. Build, development, coding:

The program code is written in this stage

5. Testing:
The code is tested at various levels Unit, system and user acceptance testing are often performed This is a very gray area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs

6. Installation, Implementation or Deployment:

The final stage of a project or the initial development, where the software is put into production and is used by the actual business

7. Maintenance, Business as Usual:

The life of the system which includes changes and enhancements before the decommissioning or sunset of the system

Software Development Models

1. 2. 3. 4. 5. 6. Big Bang: Code and Fix: Water Fall: Spiral: Agile: V Model:

2.1 Big Bang

A huge amount of matter (money and people) is put together and a lot of energy is expended and outcomes the perfect software project or a question mark.
Viraj

Page 2 of 11

It is very simple Little planning or scheduling or formal development process Project requirements arent well understood and release date is completely flexible

2.2 Code and Fix

Very little planning and documentation Long repeating cycle of coding, testing and fixing bugs Works very well for prototypes and demos

2.3 Waterfall
1. 2. 3. 4. 5. 6. Requirements gathering Analysis Design Develop Test Final product

Everything is carefully and thoroughly specified There is no overlap. There is no way back up!

The waterfall model is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements specification" they set in stone the requirements of the software. When and only when the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow this design should be a plan for implementing the requirements given. Page 3 of 11

Viraj

When and only when the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.

Thus the waterfall model maintains that one should move to a phase only when its proceeding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them. Advantages of waterfall model: 1. Time spent early on making sure that requirements and design are absolutely correct is very useful in economic terms (it will save your much time and effort later). 2. Some prefer the waterfall model for its simple and arguably more disciplined approach. The model itself progresses linearly through discrete, easily understandable and explainable "phases" and is thus easy to understand; it also provides easily markable "milestones" in the development process. 3. The two big advantages of the pure waterfall model as producing a "highly reliable system" and one with a "large growth envelope" Disadvantages of the waterfall model: 1. The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. 2. For example, clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. 3. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested into "Big Design Up Front". 4. Designers may not (or, more likely, cannot) be aware of future implementation difficulties when writing a design for an unimplemented software product. 5. The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. 6. The idea behind those who object to the waterfall model may be "time spent in reconnaissance is seldom wasted".

2.4 Spiral
1. 2. 3. 4. 5. 6. Determine objectives, alternatives, and constraints. Identify and resolve risk. Evaluate alternatives. Develop and test the current level. Plan the next level. Decide on the approach for the next level.

Viraj

Page 4 of 11

The spiral model, also known as the spiral life cycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. The steps in the spiral model can be generalized as follows: The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages: 1. Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the (nearly inevitable) changes that software development
Viraj

Page 5 of 11

generally entails. 3. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

2.5 Agile
Agile model promotes development iterations throughout the life cycle of the project It minimizes risk by developing software in a shorter span of time Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation Each iteration may not add enough functionality to guarantee the release but to ensure defect free release (with limited functionality) The team then again re-evaluates the project objectives

Viraj

Page 6 of 11

Advantages: 1. This type of method is more suitable for a product based organization where the requirements are emergent and rapidly changing. 2. Fewer staff with higher level of competency. 3. Agile methods are suitable for the projects having shorter teams Disadvantages: 1. Lack of structure and necessary documentation 2. Only works with senior-level developers 3. Incorporates insufficient software design 4. Requires too much cultural change to adopt 5. Can lead to more difficult contractual negotiations 6. Can be very inefficient -- if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan was there to be followed, a single area of code is expected to be written once. 7. Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements 8. Drastically increases the chances of scope creep due to the lack of detailed requirements documentation 9. Agile method emphasizes on face to face communication over written documents and hence always results in criticism of being undisciplined.

2.6 V Model
The V methodology is mostly associated with software testing. It develops two processes: one for building the system and one for testing the system. The two processes are then interrelated as a V methodology. The V shows development on one side and testing on other side. For example during the requirements stage of development, the software acceptance testing side is developed. The V methodology assumes that approximately one half of the total development effort will be spent on testing. The V then integrates testing so that testing is more effective and defects are uncovered earlier in the developmental process.

Viraj

Page 7 of 11

The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. Verification Phase:

1. Requirements analysis:
In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). The users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the systems functional, physical, interface, performance, data, security requirements etc as expected by the user. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

2. System Design:
System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase

3. Architecture Design:
This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase. Page 8 of 11

Viraj

4. Module Design:
This phase can also be called as low-level design The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module The unit test design is developed in this stage

Validation Phases 1. Unit Testing: In the V-model of software development, unit testing implies the first stage of dynamic testing process It involves analysis of the written code with the intention of eliminating errors Testing is usually white box It is done using the Unit test design prepared during the module design phase. This may be carried out by software testers, software developers or both 2. Integration Testing: In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components Testing is usually black box as the code is not directly checked for errors It is done using the integration test design prepared during the architecture design phase Integration testing is generally conducted by software testers 3. System Testing: System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing. 4. User Acceptance Testing: To determine whether a system satisfies its acceptance criteria or not. To enable the customer to determine whether to accept the system or not. To test the software in the "real world" by the intended audience. Benefits: The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

STLC process (Software Testing Life Cycle)

Software testing life cycle identifies what test activities to carry out and when (what is the best time) to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle. Although variations exist between organizations, there is a typical cycle for testing

1. Requirements analysis: Testing should begin in the requirements phase of the software
development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests work.

Viraj

Page 9 of 11

2. Test planning: Test strategy, test plan, testbed creation. A lot of activities will be carried
out during testing, so that a plan is needed.

3. Test development: Test procedures, test scenarios, test cases, test scripts to use in
testing software.

4. Test execution: Testers execute the software based on the plans and tests and report any
errors found to the development team.

5. Test reporting: Once testing is completed, testers generate metrics and make final

reports on their test effort and whether or not the software tested is ready for release. with the client, in order to decide what defects should be treated, fixed, rejected (i.e. found software working properly) or deferred to be dealt with at a later time.

6. Test result analysis: Or Defect Analysis, is done by the development team usually along 7. Retesting the resolved defects. Once a defect has been dealt with by the development
team, it is retested by the testing team.

8. Regression testing: It is common to have a small test program built of a subset of tests,
for each integration of new, modified or fixed software, in order to ensure that the latest delivery has not ruined anything, and that the software product as a whole is still working correctly.

Bug Life Cycle

1. When a new bug is found its status is set to NEW. 2. Then the Team Lead or the development lead changes the status to OPEN if he finds that
the bug is a valid bug. status to ASSIGNED.

3. The development team lead assigns the bug to an appropriate tester, and changes the 4. If the developer does find that the assigned bug is not a bug he changes the status to
REJECTED with appropriate reason.

5. If the bug is going to be fixed in the next release its status is changed to DEFFERED. 6. The developer fixes the bug and sets its status to TEST so that the tester can test it. 7. The tester retest the bug and checks whether its been fixed or not and changes its status 8. 9.
to VERIFIED. If the bug is still open its status is changed to OPEN again and it is reassigned to some developer. If not then the bug status is changed to CLOSED
N E W

O P E N R E J E C T E D

A S S IG N E D

D T E S T

E F F R

E D

O P E N

V E R IF IE D

Viraj

L O S E D

Page 10 of 11

Product Life Cycle

The product life cycle goes through many phases, involves many professional disciplines, and requires many skills, tools and processes. Product life cycle (PLC) has to do with the life of a product in the market with respect to business/commercial costs and sales measures; whereas product lifecycle management (PLM) has more to do with managing descriptions and properties of a product through its development and useful life, mainly from a business/engineering point of view. To say that a product has a life cycle is to assert four things: 1) that products have a limited life, 2) product sales pass through distinct stages, each posing different challenges, opportunities, and problems to the seller, 3) profits rise and fall at different stages of product life cycle, and 4) products require different marketing, financial, manufacturing, purchasing, and human resource strategies in each life cycle stage. The different stages in a product life cycle are: 1. Market introduction stage Cost high Sales volume low No/little competition - competitive manufacturers watch for acceptance/segment growth losses Demand has to be created Customers have to be prompted to try the product 2. Growth stage Costs reduced due to economies of scale Sales volume increases significantly Profitability Public awareness Competition begins to increase with a few new players in establishing market Prices to maximize market share

3. Mature stage
Costs are very low as you are well established in market & no need for publicity. Sales volume peaks Increase in competitive offerings Prices tend to drop due to the proliferation of competing products Brand differentiation, feature diversification, as each player seeks to differentiate from competition with "how much product" is offered Industrial profits go down

4. Decline or Stability stage Costs become counter-optimal Sales volume decline or stabilize Prices, profitability diminish Profit becomes more a challenge of production/distribution efficiency than increased sales

Viraj

Page 11 of 11