UNIT- I

DAY- 4
-K. Indhu
 GOALS
1. The software development process

2. Building high-quality software

3. Object-oriented systems development

4. Definition of Use-Case

5. Use-case driven systems development

13-DEC-13 K. INDHU 2
 SOFTWARE DEVELOPMENT PROCESS
• The software development process can be divided into smaller,
interacting sub-processes.

• The software development process can be viewed as-

– a series of transformations, where the output of one transformation becomes
the input of the subsequent transformation.

• Transformation-1 (Analysis):- translates the user’s needs into system

requirements and responsibilities.
• Transformation-2 (Design):- begins with a problem statement and ends
with a detailed design that can be transformed into an operational
system.
• Transformation-3 (Implementation):- refines the detailed design into
the system deployment that will satisfy the user’s needs.

13-DEC-13 K. INDHU 3
 SOFTWARE DEVELOPMENT PROCESS
• The essence of the software process is the
transformation of
– Users’ needs to
– The application domain into
– A software solution.
• For example, you have a requirement to create a
presentation for the Seminar
– User’s need to prepare a Presentation
– Use Microsoft PowerPoint application tool
– Prepare the end product PPT Presentation for Seminar.

13-DEC-13 K. INDHU 4
 SOFTWARE DEVELOPMENT PROCESS

13-DEC-13 K. INDHU 5
 WATERFALL MODEL APPROACH
• An example of the software development process is the waterfall
approach.
• WATERFALL APPROACH is the traditional software development model.

• It starts with deciding what is to be done- means what is the problem

statement.
• Once the requirements have been determined, we decide how to
accomplish them.
• This is followed by a step in which we do it, whatever is been required
to do.
• We then must test the result to see whether we have satisfied the
user’s requirements.
• Finally we use what we have done.

13-DEC-13 K. INDHU 6
 WATERFALL MODEL APPROACH

13-DEC-13 K. INDHU 7
 WATERFALL MODEL APPROACH
• The waterfall model has limited utility.
• DIS-ADVANTAGE:-
– In the software real world, the problems are not always well-
defined.
– When there is uncertainty regarding what is required or how it can
be built, the waterfall model fails.
– It neither emphasizes nor encourages software re-usability.
• IT’s APPLICABILITY:-
– This model assumes that the requirements are well-known before
the design begins, which is a very rare scenario in software.
– The waterfall model is the best way to manage a project with a
well-understood product.

13-DEC-13 K. INDHU 8
 WATERFALL MODEL APPROACH
• Merits:-
– Suited for well defined projects and well-understood
problems

• Demerits:-
– Problems are not always well defined in real world.
– It does not support software reusability

13-DEC-13 K. INDHU 9
 BUILDING HIGH QUALITY SOFTWARE
• It is mandate to develop a Software with high quality.

• WHY?- The ultimate goal of building high-quality software is to meet

USER’S NEED & EXPECTATION and to achieve USER SATISFACTION.

• For example,
– you order a washing-machine.
– The product is made and delivered to you.
– But the washing machine has few repair problems due to which it doesn’t serve
the purpose.
– WILL YOU SATISFIED with the quality of product?

• That’s why, SOFTWARE QUALITY & SOFTWARE TESTING is VERY VERY

important.

13-DEC-13 K. INDHU 10
 SOFTWARE QUALITY
• There are two basic approaches to systems
testing:-
• We can test a system according to how it has been
built.
– We can test a new built house by checking whether
good-quality cement has been used, iron steel is used.
• Alternatively, we can test the system with respect
to what it should do.
– We can test a new built house by checking whether it
serves the purpose, that is whether it provides shelter
for long duration.

13-DEC-13 K. INDHU 11
 SOFTWARE QUALITY MEASURES
• Any software product can evaluated in terms of
four measures:-
– CORRESPONDENCE:-
• Measures how well the delivered system matches the
needs of the operational environment.
– VALIDATION:-
• It is the task of predicting correspondence.
– CORRECTNESS:-
• Measures the consistency of the product requirements with
respect to the design specification.
– VERIFICATION:-
• It is the exercise of determining correctness.

13-DEC-13 K. INDHU 12
 SOFTWARE QUALITY MEASURES
• Verification is to predict the correctness.
• Validation is to predict the correspondence.
• Verification->
– Am I building the product right?
• Validation
– Am I building the right product?

13-DEC-13 K. INDHU 13
HAPPY LEARNING!!!