L-1

NEED FOR S/W ENGG

ISSUES IN DESIGN OF LARGE SOFTWARE
S/W LIFE CYCLE MODELS

Recommended Books:
1. Roger S. Pressman R., “Software Engineering, A Practitioner’s Approach”, McGraw Hill International.
2. Ian Sommerville , Software Engineering, Addison-Wesley Publishing Company.
3. Rajib Mall, “Fundamentals of Software Engineering”, PHI
4. Software Engineering by K.K. Aggarwal Er. Shweta Rajput
• S/W: in day today life.
• Many application areas: Engg.,architecture,e-commerce,science
• s/w becomes large,complex.(GUI,client-server architecture,distributed)
• Run on 2 or more processors, under different OS and on geographical distributed machines.

• Urgent need to adopt s/w engg. concepts,strategies,practices to improve s/w development

process in order to deliver good quality, maintainable s/w in time and within budget.
• S/W process: way in which we produce s/w, differs from organization to organization.

Er. Shweta Rajput

Software Engineering:
• systematic, scientific and disciplined approach to the development,
functioning, and maintenance of software
• It’s study of and practice of engineering to build, design, develop and
maintain software
• s/w Process + Management
• Means producing good quality, efficient, maintainable s/w on time,
within budget.
• Main focus: On both quality of product and on process used to
develop product.

Er. Shweta Rajput

 S/W Engg.
Engineering approach to develop software.
Analogy:
Let you want to build a small wall, you need some bricks, cement etc. You will easily succeed in developing small wall.
But,if you are asked to build a complex Shopping Mall consisting of multistoried large buildings like 50 floors.
Then your basic intuition about construction will not work here.
If you actually get started, your building may collapse or never complete or may be of poor quality etc.
Same thing is with respect to software.
If somebody is asked to write a small program 10 -50 LOC he will be able to do it based on basic intuition.
But Let us consider, developing s/w which is 1000 KLOC to 5000 KLOC.
Now, he will face lot of issues now.
Solution:
Engineering approach to develop software based on some techniques, methodologies, guidelines and tools.
It's systematic collection of past experience which has resulted in various techniques, methodologies, guidelines and tools.

Er. Shweta Rajput

Why study software engineering?
1.To acquire skills to develop large programs.
Handling exponential growth in complexity with size.

2. Learn systematic techniques of developement process, specifications, design

and testing.

3. To acquire skills to be a better programmers.

Higher productivity, better quality programs.
4.Helps in solving large projects.

Er. Shweta Rajput

• Program vs S/W:
• s/w project development is different from program development that we
develop as a student. We develop it, compile and use it and then throw it.
• But now want project-long term + testing + maintenance.

Program Documentation

Operating Procedures

• Documentation: diff. types of manuals(SRS,SDD,DFD,Flowcharts,ER diagrams

etc).
• Operating Procedures: instructions to set up and use software system and
Er. Shweta Rajput
failures(Beginner guide,Installation guide etc).
 WHY software Engineering??
• It’s a systematic approach to design, develop, test and maintain software that ensures that the end product is of high quality,
reliable, and meets the needs of the users.
• Basic objective of software engineering is to develop methods and procedures for software development
that can scale up for large systems and that can be used consistently to produce high-quality software at low cost and with a
small cycle of time.

• An Engg. approach consist of developing s/w which meets specifications efficiently, cost effectively and at the same time
they ensure quality.

• Engg. Approach means: well defined, managed, repeatable and predictable approach.
• Large projects will benefit by systematic approach.
• If we are successful once, then same approach, same methodology can also be used in another approach, in another project
and we will have very high probability of success.
• Quality, control,standards,planning and management are important in engineering approach.

Engineering approach: other discipline example:

• Big engineering projects like Building bridges, dams, power plants, aircraft, missile(involve diff. types of people): successfully
completed.
• we need to learn from them and apply the same for developing s/w.
Er. Shweta Rajput
 Need for s/w Engineering
1. Attempt to estimate cost/effort/time: It will save a lot of time if you are developing software using a software engineering technique.
2. Plan and schedule work: programmers plan everything and reduce all those things that are not required.
3. Involve users in defining requirements: so that software meets the needs of the users.
4. Identify stages in development
5. Handling Big Projects: software engineering methodology aids to handle large projects without any issues.
6. Reliable software: It is the company’s responsibility to deliver software products on schedule and to address any defects that may exist.
7. Effectiveness: Effectiveness results from things being created in accordance with the standards.
8. Reduces complexity: Large challenges are broken down into smaller ones and solved one at a time in software engineering. Individual solutions
are found for each of these issues.
9. Productivity: Because it contains testing systems at every level, proper care is done to maintain software productivity.
10. Define clear milestones so that progress can be measured.
11. Schedule reviews both for control and quality
12. Define deliverables(SRS,SDD).
13. Plan extensive testing: Another important aspect of software engineering is testing and quality assurance. Software engineering provides a
variety of testing methods and tools to ensure that the software meets its requirements and is free of bugs. This includes unit testing,
integration testing, and acceptance testing etc.
14. Well-documented, reliable and maintainable software.
15. Use resources optimally: software development project typically involves many people with different roles and responsibilities. Software
engineering provides a way to manage the resources, schedule, and budget of the project, and to ensure that the team is working together
effectively. Update tools/methods/trainings/techniques with time.
16. To manage Risks
Er. Shweta Rajput
Er. Shweta Rajput
Er. Shweta Rajput
 Issues in design of large s/w:

1. Effort intensive( manpower, hardware, software, and the other support resources).
2. High cost involved
3. Long development time required
4. Understanding large and complex system requirements is difficult
The word ‘large’ represents 2 aspects:
(i) Large constraints in terms of security, etc. due to a large number of users.
(ii) Large number of functions to be implemented.
Partitioning the system suitably to reduce complexity
More complex and large projects(require more partitioning) can sometimes be broken down into small modules/functionalities which are then handled by
separate teams. It needs to be ensured that the partitions are non-overlapping and independent of each other.
5. Customers/Stakeholders are not clear about their needs(happen when they have a very basic idea about their needs)
6. Changing needs of users
7. Conflicting requirements
8. Changing technologies
9. High risk of failure and user acceptance
10. Performance
11. Maintainability: maintaining agility and efficiency
12. s/w projects may not always been successful.
13. Lack of Resources
14. Feasibility
15. Undefined system boundaries
There might be no defined set of implementation requirements. Customer may go on to include several unrelated and unnecessary functions besides the
important ones, resulting in an extremely large implementation cost which may exceed the decided budget.
16. Lack of adequate training Er. Shweta Rajput
17. Skill shortage
 Reasons for s/w failures:
1. Schedule –slippage means s/w is not ready in time.
2. Cost over-runs(too costly to complete project, it may be abandoned).
3. Doesn’t solve user’s problem(s/w development completed but user does not find it useful. It’s failure).
4. Poor quality of s/w.
5. Poor Maintainability.

Reasons for such Failures: adhoc, non-engineering approach to s/w development

1. No planning or development work(no milestone defined).
2. Poor understanding of user requirements
3. No control or review(control s/w development systematically and review progress systematically).
4. Technical incompetence of developer.
5. Poor understanding of cost and effort by both developer and user.
6. Outdated technology
7. Security attacks: virus#malware
8. Poor efficiency, performance
Er. Shweta Rajput
S/W Life Cycle Models
• Abstraction that represents s/w life cycle.
• Model is an abstraction where we focus on relevant issues and ignore
irrelevant details.
1. Build and fix
2. Waterfall
3. Prototyping
4. Iterative enhancement model
5. Spiral model
6. RAD(Rapid Application development)
Er. Shweta Rajput
 Build
1. Build and fix code

fix

• Developer simply build product that’s reworked as many times as necessary to satisfy client.
• Adhoc approach: not well defined.
• It’s 2 phase model:
Phase 1: is to write code.
Phase 2: is to fix it(fixing means error correction or addition of further functionality).
• Suitable for small programming exercises 100 or 200 LOC but not for large s/w.
• Code soon becomes unfixable and unenhanceable.
• Development cost: high as compared to cost of properly specified and carefully designed
product.
• Maintenance can be difficult without specification or design documents.
Er. Shweta Rajput
• Early programmers used build and fix style as there were no other
techniques.

• This style is fine for small size projects.

• But as program size increases,
• Effort, time and cost
• All increases exponentially.

Er. Shweta Rajput

Er. Shweta Rajput
2. Waterfall Model
5 phases: top-down approach
1. Requirements analysis and specification
2. Design
3. Implementation
4. unit testing, Integration and system testing
5. Operation and maintenance

Phases always occur in this order and don’t overlap.

Developer must complete each phase before next phase begins.
1st step takes i/p from it’s previous step and gives its output to next step.
• Called so as its diagrammatic representation resembles a cascade of waterfalls.
• Sequential model
Er. Shweta Rajput
Requirements
analysis and
specification

Design

Implementation
(Coding)
unit testing,
Integration and
system testing

Operation and
maintenance
Er. Shweta Rajput
 Phase 1: Requirements analysis and specification

Aim:
1. to understand exact requirements of customer and to document them properly.
2. To develop SRS(software requirement specification) document, User involvement required
to design efficient end product.
3. SRS document: act as contract b/w developer and customer.
written in natural language, contains description of “What system will do without describing
how it will be done?”
4. Techniques: Brainstorming, questionnaire, GD, Survey, Interview etc.

Er. Shweta Rajput

 Phase 2: Design
• Activity following requirements specification and done before programming.
• SRS Document produced in previous phase contains exact requirements of customer.
• Here aim: is to transform SRS into a structure that’s suitable for implementation in some programming language.

• Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and
implementation.

• software design may be as simple as a flow chart or text describing a planned sequence of events(pseudocode/algorithm).
• uses design methods like UML(Unified Modeling Language), ER and DFD.
• output of software design process is design documentation, pseudo codes, detailed logic diagrams, process diagrams, and detailed description of all
functional or non-functional requirements.

• Software design : process of defining software methods, functions, objects, and the overall structure and interaction of your code so that the resulting
functionality will satisfy your users requirements.
• sequence of steps that enables the designer to describe all aspects of the software for building.
• Here, overall s/w architecture is defined and high level and detailed design work is performed and this work is documented in form of SDD(s/w design
document).
• Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements.
• if errors get unnoticed till later phases, it becomes more difficult to correct them.
Er. Shweta Rajput
Phase 3: Implementation
• Here design is implemented.
• If SDD is complete, coding phase proceeds smoothly (as all info.
needed by s/w developer is contained in SDD).

• – Software design is a creative activity in which you identify software

components and their relationships, based on a customer’s
requirements.
• – Implementation is the process of realizing the design as a program.

Er. Shweta Rajput

Phase 4: unit testing, Integration and system testing
• During testing, major activities are centred around examination and modification of code.
• Aim of unit testing: is to determine that each independent module is correctly
implemented.
• Initially, small modules are tested in isolation from rest of s/w product.
• Effective testing will contribute to delivery of higher quality s/w products, more satisfied
users, lower maintenance cost and more accurate and reliable results.
• Expensive activity( AFTER CODING) and consumes 1/3 to ½ of cost of development project.
• Aim of Integration testing: to check that interface b/w module is also correct.
• System Testing: involve testing of entire system. It is a high level testing always performed
after integration testing.
• conducted on a complete, integrated system to evaluate the system's compliance with its
specified requirements.
Er. Shweta Rajput
Phase 5:Operation and maintenance
• Release of s/w inaugurates operational and maintenance phase of life cycle.
• Important and challenging task: that includes error correction, enhancement of
capabilities, deletion of obsolete capabilities and optimization.
• Aim: to preserve s/w value over time.
• This phase may span for 5 to 50 years whereas development may be 1 to 3 years.
4 types of maintenance:
1. Corrective(fixing errors found in day-today system functions)
2. Adaptive (To make s/w adaptable to new environment such as to run the s/w on a new operating system/Hardware/rules)
3. Perfective (adding new functionalities as per the users' changing needs, enhancing both function and efficiency of code)
4. Preventive(assures optimal working conditions and conserves the life span of s/w)
Er. Shweta Rajput
Corrective maintenance:
• deals with repair of faults or defects or errors(fixing errors) found in day-today system functions, when s/w is in use.
Adaptive maintenance :
• change in software that takes place to make s/w adaptable to new environment such as to run the s/w on a new operating system.
• changes in the environment such as the hardware or the operating system.
• Term environment in this context refers to conditions and influences which act (from outside) on system. For example, business rules, work
patterns, and government policies have a significant impact on the software system
Perfective maintenance:
• change in the software that occurs while adding new functionalities in the software.
• making functional enhancements to system: To increase the system's performance
• deals with implementing new or changed user requirements.
• This includes enhancing both function and efficiency of code and changing the functionalities of the system as per the users' changing needs.
• Example: modifying payroll program to incorporate a new union settlement and adding a new report in the sales analysis system.
Preventive maintenance
involves implementing changes to prevent the occurrence of errors.
• It tends to reduce the software complexity thereby improving program understandability and increasing software maintainability.
• It comprises documentation updating, code optimization, and code restructuring.
• Documentation updating involves modifying the documents affected by the changes in order to correspond to the present state of the system.
• Code optimization involves modifying the programs for faster execution or efficient use of storage space.
• Code restructuring involves transforming the program structure Er.
forShweta
reducing
Rajputthe complexity in source code and making it easier to understand.
Waterfall model :
easy to understand based on “define before design ” and “design before code”.

Merits:
1. Useful when requirements are well understood.
2. Same type project: If an organization has experience in developing accounting system then building new
accounting system based on existing design could be easily managed with waterfall model.

Limitations:
3. It expects complete and accurate requirements early in the process which is unrealistic. It assume all
requirements can be clearly defined during analysis phase.
4. Linear model, real projects are rarely sequential.
5. Assume requirements are stable, don’t change with time.
6. Documentation-heavy as too much documentation is being produced as part of project.
7. Working s/w is not available until late in process, so delaying discovery of serious errors.
8. Not covering risk-assessment.
9. Not suitable for accommodating any change(phase sequence can’t be altered).
Er. Shweta Rajput
 3. Prototyping model
• Disadvantage of waterfall model:
Working s/w is not available until late in process, so delaying discovery of serious errors.
• Here aim is to 1st develop working prototype of s/w instead of developing actual s/w.
• Working prototype is developed as per current available requirements.
• Prototype: has limited functional capabilities, low reliability and untested performance.
• Developers then use this prototype to remove uncertainties in requirements , to refine requirements and
prepare clear, final specification document.
• Since working prototype has been reviewed and evaluated by customer so resulting SRS will be correct.
• Prototype may be usable program but code for prototype is thrown away(or sometimes reworked) as it’s
not suitable as final s/w product.
• Experience gained from developing prototype helps in developing actual system.
• Development of prototype might involve extra cost but overall cost might turn out to be lower than that of
an equivalent system developed using any other model like waterfall.
Er. Shweta Rajput
Aim: to determine customer’s real needs.
Prototype should be developed as early as possible to speed up s/w development process.
• After finalization of SRS document, prototype is discarded and actual system is then
developed using waterfall approach.
• Produces maintainable and good quality s/w
Disadv:
Requires extensive participation and involvement of customer which is not always possible.

Er. Shweta Rajput

 Requirements

Quick Design
(Prototype)

Implement Refinement of requirements as

per suggestions.

Customer Evaluation Not accepted by customer

Accepted by customer

Design

Implementation and
unit testing

Integration and System

Testing

Operation and Maintenence

Er. Shweta Rajput
4. Iterative Enhancement Model
• Has same phases as waterfall model but with fewer restrictions.
• Phases occur in same order as in waterfall model but these may be conducted in several cycles.
• Useable product is released at end of each cycle, with each release providing additional
functionality.
• During 1st requirement analysis phase, customer and developer prepare SRS document,
prioritize requirements.
• Developer implement specified requirements in 1 or more cycles of design, implementation and
test based on defined priorities.
• Model does deliver an operational quality product at each release but 1 that satisfies only a
subset of customer’s requirements.
• Complete product is divided into releases and developer delivers product release by release.
• 1st release may be available within few weeks or months and customer is able to do some useful
work after 1st release.

Er. Shweta Rajput

• Here, we define initial scope and try to build product which will meet initial scope that
was identified and then release it quickly to get customer feedback.
• Here we are developing a product whose functionality may not be clearly known or
there may be too many features that we may want to provide. But we would rather
release product quickly, capture the market and get customer feedback. So this is
situation ideal for iterative development.
• here development phase takes place in multiple iterations and many versions of s/w
may be released.
• Latest version represents additional features which have been added from previous
version based on requirements as perceived or based on customer feedback.

Er. Shweta Rajput

 Implementation Integration Operation
Requirements Design And and system (Install)
Unit testing testing Release-1

Implementation
Integration and Operation
Design And
system testing (Install)
Unit testing
Release-2

Implementation Integration and Operation

Design And system testing (Install)
Unit testing
Release-3

Iterative Enhancement Model

Er. Shweta Rajput

 5. Spiral Model
• Traditional models don’t deal with uncertainty/RISK which is inherent to s/w projects.
• Important s/w projects failed: As project risks were neglected and nobody was prepared when
something happened.
• In this model, project risk factor is incorporated in s/w life cycle.
• It’s a combination of iterative enhancement model and waterfall model.
• It allows incremental releases of product or incremental refinement through each iteration
around spiral.
• Radial dimensions of model represents cumulative costs(refers to the accumulated cost).
• Each path around spiral is indicative of increased costs.
• Angular dimension represents progress made in completing each cycle.
• Each loop of spiral from x-axis clockwise through 360 degree represents 1 phase.
Er. Shweta Rajput
In spiral model, we go through development in cycle and
each cycle is divided into 4 quadrants(4 sections of major activities).

In 1st quadrant, starting point, we define objectives, alternatives, what are constraints?
Then we evaluate those alternatives and clearly identify the risks.
Based on these risks in 3rd quadrant of cycle, work on implementation, build development and
then in 4th quadrant, we will plan subsequent cycles after customer feedback.
1. Planning: determination of objectives, alternatives and constraints.
2. Risk Analysis: Analyse alternatives and attempts to identify and resolve risks involved.
Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management
risks, such as schedule slippage and cost overrun.
3. Development: product development and testing product.
4. Assessment: Customer evaluation.

Er. Shweta Rajput

• During 1st phase,
planning is performed, risks are analysed, prototype are built and customer evaluate prototype.

• During 2nd phase, more refined prototype is built, requirements are documented and validated after refinements and
customer are involved in accessing new prototype.

• By the time 3rd phase begins, risks are known.

• Here focus on identification of problems and classify them into different levels of risks.
• Aim: to eliminate high risk problems before they threaten s/w operation or cost.

• Each phase is completed with review by people concerned with project.

• This review consist of review of all products developed up to that point and include plans for next cycles.
• These plans may include partition of product in smaller portion for development that are implemented by individual
groups or persons.
• If plan for development fails, then spiral is terminated. Else, it terminates with initiation of new or modified s/w.
• So, development is going on in cycles.
• AS we go through cycles, different risk issues are addressed and more refinements are done to our strategies, to the
functionalities.
• Spiral model basically identify risks at every step and it identifies ways of addressing those risks either by following
prototyping methods or carrying out benchmarking.
• If performance are well understood, then risk may be just development risk(go for coding, risk free). Then we follow
Er. Shweta Rajput
waterfall model.
Er. Shweta Rajput
Er. Shweta Rajput
Er. Shweta Rajput
 Typical uses of Spiral model:
1. budget constraint and risk evaluation is important.
2. For medium to high-risk projects.
3. Good for Long-term project commitment because of potential changes to priorities as
the requirements change with time.
4. Customer is not sure of their requirements which is usually the case.
5. Requirements are complex and need evaluation to get clarity.
6. New product line which should be released in phases to get enough customer
feedback.
7. Significant changes are expected in the product during the development cycle.

Er. Shweta Rajput

ADV:
1. it’s risk driven. Risk analysis and validation steps eliminate errors in early phases of development.
2. It incorporated s/w quality objectives into s/w development.
3. It allows for elements of the product to be added in when they become available or known. This
assures that there is no conflict with previous requirements and design.
4. It is consistent with approaches that have multiple software builds and releases and allows for
making an orderly transition to a maintenance activity.
5. Another positive aspect is that the spiral model forces early user involvement in the system
development effort.

Disadvantages of Spiral model:

• Difficult to follow strategy for small projects.
• Not much useful for low risk projects.
• Need more experience resources as process is bit complex.
• Large documentation.

Er. Shweta Rajput

Er. Shweta Rajput
 6. RAD(Rapid Application Development)
• By IBM
• Here user involvement is essential from requirement phase to delivery of product.
• Continuous user participation: in preparation of SRS and SDD documents.
• Firstly rapid prototype is designed and given to user for evaluation.
• User feedback is obtained and prototype is refined.
• Process continues till requirements are finalized.
• SRS and SDD documents are prepared with association of users.

Er. Shweta Rajput

 With active participation of users

Requirements Construction
User description Cut-Over
Planning

Er. Shweta Rajput

1. Requirements Planning
Here requirements are captured using any group elicitation technique. User involvement is necessary
for understanding the project.

2. User description:
Joint team of developers and users are constituted to prepare, understand and review requirements.
Team may use automated tools to capture information from other users.

3. Construction:
It combines detailed design, coding and testing phase of waterfall model. Here we release product to
customer. It may use code generators, screen generators and other types of productivity tools.

4. Cut-Over:
It incorporates acceptance testing by users, installation of system and user training.
Er. Shweta Rajput
Advantages:
1. User involvement may increase acceptability of product.
2. Development time of product may be reduced due to use of
powerful development tools. It may use CASE tools and framework
to increase productivity.
3. Quick initial views about product are possible due to delivery of
rapid prototype.
4. Highly specialised and skilled developers are expected.

Er. Shweta Rajput

• Selection of suitable model is based on foll. characteristics:

1. Requirements
2. Development team
3. Users
4. Project type and associated risks.

Er. Shweta Rajput

Requirements

1. If requirement are easily defined and understandable?

Waterfall, RAD

2. Change requirements
Prototype, Spiral

3. Requirements indicate that system is complex.

Prototype, Spiral, iterative enhancement model

Er. Shweta Rajput

Development team

4.If development team has less experience on similar project.

Prototype, Spiral

5. If development team has less domain knowledge(new technology)

spiral, iterative enhancement

6. If development team has less experience on tools to be used.

Spiral
Er. Shweta Rajput
Users
7. User involvement in all phases.
Prototype, RAD ,spiral

8. Limited user participation.

Waterfall, iterative enhancement model

9. User have no previous experience of participation in similar project.

Prototype, spiral, iterative enhancement model

10. Users are expert of problem domain.

RAD, Prototype, iterative enhancement model
Er. Shweta Rajput
Project type and associated risks.
11. Project is enhancement of existing system
RAD, iterative enhancement model

12. Funding is stable for project

waterfall, prototype, RAD

13. High reliability requirements

spiral, iterative enhancement model

14. Tight project schedule:

spiral, iterative enhancement model, RAD, Prototype

15. Use of reusable components.

Prototype,spiral,RAD

16. Resources(time,money,people etc) less? Er. Shweta Rajput