Software Engineering

UNIT -I:
Introduction to Software Engineering: The evolving role of software,
Changing Nature of Software, Software myths.
A Generic view of process: Software engineering- A layered technology, a
process framework, The Capability Maturity Model Integration(CMMI )
Process models: The waterfall model, The spiral Model, Agile
methodology.
Intoduction to Software Engineering
 Software Engineering is the process of designing, developing, testing, and

maintaining software. It is a systematic and disciplined approach to software

development that aims to create high-quality, reliable, and maintainable

software.

 The main goal of Software Engineering is to develop software applications for

improving quality, budget, and time efficiency.

Software Characteristics:

• Software is developed or engineered, it is not manufactured

• Software doesn’t “wear out”.
• Software is custom built.
• Failure rate curve for Hardware Failure rate curve for software

Hardware: Worn out hardware components can be replaced.

Software: Software maintenance requires changing the design and or code.

The Nature of Software/Evolving role of Software
Software takes on a dual role.
•It is i) A product
and at the same time
• ii) The vehicle (for delivering product)

S/w is a product : Produces, manages and displays the information

S/w is a vehicle for delivering the product (process)
As a vehicle what does it do?
1. It supports or directly provides system function
2. Controls other program (eg:os)
3. Effects communicaton (eg:n/w)
4. Helps in building other software (eg: S/w tools)
Changing Nature of Software
According to evolution of technology software keeps on changing
• There are seven broad categories of computer software having different forms, uses and
challenges to software engineers.

System Software: System software is a collection of programs written to service other programs. e.g.
compilers, editors, operating system components, drivers, networking software etc.
Application Software: Application software is a standalone programs that solve a specific business need.
Applications software like data processing applications, point of sale transaction processing, real time
manufacturing process control helps in managing and controlling business function.
Engineering and Scientific Software: Engineering and scientific software have been
characterized by number “crunching" algorithms. Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated
manufacturing
• Embedded Software: Embedded software resides in read-only memory and is used to control
products. Eg. Keypad control for a microwave oven, digital functions in an automobile such as fuel
control, dashboard displays, and braking systems.
• Product-line software: Product line software designed to provide a specific capability for
use by many different customers.
• Web Applications: The Web pages retrieved by a browser are software that incorporates
executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext and a
variety of visual and audio formats.
• Artificial Intelligence Software: Artificial intelligence (AI) software makes use of non
numerical algorithms to solve complex problems that are not amenable to computation or
straightforward analysis. Eg. Expert systems or knowledge based systems, pattern recognition
(image and voice), artificial neural networks, theorem proving, and game playing.
Participants in software development
• Software Manager : Manages Budget, Monitor progress against project plan, always
look at time to market without compromising
• Customers : Users
• Practitioners : Developers, Testers.

•Software Issues:
• Problems associated with software development are not just restricted to software that
doesn’t function but it also includes
– How we develop software?
– How we support a growing volume of existing software?
– How we keep pace with a growing demand for more software?
Legacy Software:
• Older (Sometimes very much) software covering any one of the seven
application domains are refered as “ Legacy S/W”.
• Developed decades ago and have been continually modified to meet
changes in business requirements and computing platforms.
• Costly to maintain and risky to evolve (especially for large industries).
• In Extendible design(can’t extend design)

• No- documentation

• Can’t meet needs of new technology

Poor Quality:
Legacy S/W suffer from one or more of these issues

 Inextensible designs

 Convoluted code

 Poor or Non - Existent documentation

 Test cases and Results that were never archived

 Poorly managed change history

Reasons to evolve:

 Adapted – Software should be adapted to meet new computing environment &

Technology.(eg:2G,3G)

 Enhancing Nature- software should be improved to meet new business

requirements

 Extendible design – to make it interoperability with other systems

 Re-architected – software must be re-architected to make it viable within a network

environment.
SOFTWARE MYTHS:
Manager’s Myths
 We have documented set of standards and procedures to build software.

 We have state-of-art software development tools

 We can add more programmers and catch up if we are behind schedule

 Outsource a software project to a 3rd party

In Reality: A simple ‘No’. Questions to be answered or issues to be understood up-front:

– Are the standards up-to-date?
– Are the standards being followed?
– Are the practitioners aware of the standards?
– Do the standards in place help speed up development time, reduce development cost, and improve
quality?
– Are the tools being used effectively?
– Is the staff trained to use the tools effectively?
– Most often than not, adding more people to a delayed project delays it further as the new people need to
be trained by the current project staff for them to be productive
– Organizations have to understand how to manage and control software projects internally when
Customer Myths:
It is sufficient to begin developing a system with a general statement of objectives. Details can be
filled in later.

Requirement Changes can be easily accommodated as software is flexible

In Reality: A simple ‘No’. Questions to be answered or issues to be understood up-

front
– Majority of software projects fail due to lack of up-front detailed definition –
including function, behavior, performance, interfaces, assumptions etc
– Every change impacts the delivery date and the impact is significantly large as
the project is nearing completion.
Practitioner Myths:
Once we write a program and get it to work our job is done
Until I get the program running I have no way of assessing its quality
The only deliverable for a successful product is a working program
Software Engineering will make us create voluminous and unnecessary
documentation which slows us down.
In Reality: A simple ‘No’. Questions to be answered or issues to be understood up-
front
– The sooner you begin coding the longer it takes to complete
– 60-80% of effort expended on a project is after it is delivered to the customer
– Formal reviews at various stages of a software development cycle help assess
the quality of the system being implemented
– Documentation provides a guidance for maintaining and supporting the
software built
– Software Engineering is about building good quality systems. Documentation
helps accomplish that objective.
A Generic View of Software
• Software Engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation and
maintenance of software; i.e., the application of engineering to
software.
Quality:
– Any Engineering approach rests on organizational commitment to quality
– Bed rock that supports Software Engineering
• Process:
• Defines a framework for a set of Key Process Areas (KPAs) for effective delivery
of software
• To manage software development,
• establish milestones,
• determine the work products to produce,
• manage quality and change
• –
– Include tasks such as
• analysis,
• design,
• program construction,
• Testing,
• • support
– Support the process and the methods
– Could be automated or semi-automated
– e.g., Computer Aided Software Engineering (CASE) Tool
Software Process/Process frame work
•process framework activities:
1. Communication: This framework activity involves heavy communication and
collaboration with the customer and encompasses requirement gathering etc.
2. Planning: This activity establishes a plan for the technical tasks to be conducted,
the risks that are likely to be occurred, the resources that will be required, the
work products to be produced and a work schedule.
3. Modeling: This activity encompasses the creation of models and the design that
will achieve the requirements.
4. Construction: This activity combines code generation and and the resting that is
required to uncover errors in the code.
• Deployment: The software is delivered to the customer who evaluates the
delivered product and provides feed back
•

1. Software project tracking and control: allows the software team to asses the progress
against the project plan and take necessary action to maintain schedule.
2. Risk Management: assesses risks that may effect the outcome of the project or the
quality of the product.
3. Software quality assurance: defines and conducts the activities required to ensure
software quality.
4. Formal technical reviews: is an effort to uncover and remove errors before they are
propagated to the next action or activity.
5. Measurement: defines and collects process, project and products measures that assist the
team in delivering software that meets customer’s needs.
6. Software configuration management: manages the effects of change throughout the
software process.
7. Reusability management: defines and establishes to achieve reusable components.
8. Work product preparation production: encompasses the activities required to create
•
work products such as models, documents, logs, forms and lists.
Capability Maturity Model Integration (CMMI)
• The CMM is a methodology used to develop and refine an
organizations software development process
• The CMMI is like a ISO 9001, one of the ISO 9000 series of standards
specified by the international organization standardization
• To develop a software using the SDLC process, CMMI standards must
be followed.
• CMMI defines 5 levels of process maturity based on certain KPAs.
• Each maturity level provides a layer in the foundation for continuous
improvement.
1.Maturity level 1 : Initial
1. processes are basic and poorly managed or controlled.
2. unpredictable outcomes of processes involved.
3. Not Well defined and Immature
4. No KPAs (Key Process Areas) defined.
5. Lowest quality and highest risk.

2.Maturity level 2 : Repeatable

It mainly focus on establishing basic project management policies
• requirements are managed.
• processes are planned and controlled.
• projects are managed and implemented according to their documented plans.
• This risk involved is lower than Initial level, but still exists.
• Quality is better than Initial level.
3.Maturity level 3 : Defined
1. processes are well characterized and described using standards, proper procedures, and methods, tools,
etc.
2. Medium quality and medium risk involved.
3. Focus is process standardization.
4. Documentations are done
5. Peer review
6. Inter group communication
4.Maturity level 4 : Managed
7. quantitative objectives for process performance and quality are set.
8. quantitative objectives are based on customer requirements, organization needs, etc.
9. process performance measures are analyzed quantitatively.
10.higher quality of processes is achieved.
11.lower risk
5.Maturity level 5 : Optimizing
12.continuous improvement in processes and their performance.
13.Feedback is collected
14.improvement has to be both incremental and innovative.
15.highest quality of processes.
16.lowest risk in processes and their performance.
 Process Models
Waterfall Model:

• The classical waterfall model is the basic software development life cycle model.
It is very simple but idealistic. Earlier this model was very popular but nowadays
it is not used. However, it is very important because all the other software
development life cycle models are based on the classical waterfall model.
• It was first introduced by Winston W. Royce in 1970.
• It is also known as Linear /Sequential Model or Classic Life Cycle.
• Oldest model &Works well with small projects
• Low budget project
• Features of the SDLC Waterfall Model
1.Sequential Approach: The waterfall model involves a
sequential approach to software development, where each phase
of the project is completed before moving on to the next one.
2.Document-Driven: The waterfall model relies heavily on
documentation to ensure that the project is well-defined and the
project team is working towards a clear set of goals.
3.Quality Control: The waterfall model places a high emphasis
on quality control and testing at each phase of the project, to
ensure that the final product meets the requirements and
expectations of the stakeholders.
4.Rigorous Planning: The waterfall model involves a rigorous
planning process, where the project scope, timelines, and
deliverables are carefully defined and monitored throughout the
project lifecycle.
•Communication: This framework activity involves heavy communication and
collaboration with the customer and encompasses requirement gathering etc.
•Planning: This activity establishes a plan for the technical tasks to be conducted, the risks
that are likely to be occurred, the resources that will be required, the work products to be
produced and a work schedule.
•Modeling: This activity encompasses the creation of models and the design that will
achieve the requirements.
i) Analysis
– Provide a clear definition of the required functionality, performance and interface. Focus is
on Software.
– Documented and Reviewed with the Customer.
ii) Design
a. Translates requirements into a representation of software e.g., data structures, algorithms, interfaces etc.
b. Documented and Reviewed.
c. Serves as a quality check point before coding begins.
•Construction: This activity combines code generation and and the resting that is
required to uncover errors in the code.

• Code Generation
– Translation of the design into machine executable code
– Could be mechanized
• Testing
a. Check that all functional requirements are met.
b. Ensure that defined input will produce results that agree with required results.
c. Focus is on the logical internals of the software
•Deployment: The software is delivered to the customer who evaluates the
delivered product and provides feed back.
•Drawbacks or Issues:
 Requires that the customer state all requirements clearly
 Difficult to accommodate changes in mid-stream as changes have to
wait till the end of the current cycle.
• No reverse directions
• No customer involvement
Spiral Model
• An evolutionary model which combines the best feature of the classical
life cycle and the iterative nature of prototype model.
• i.e It is a iterative model which comes under evolutionary model
• Include new element : Risk element. Starts in middle and continually
visits the basic tasks of communication, planning, modeling,
construction and deployment.
• i.e it is mainly used for risk handling.
• The spiral with the loop will continue until customer satisfies.(repetitive
activities will be performed)
• Suitable for larger projects.
• It is flexibile
• Complex and time consuming.
• Radius of the spiral increases cost also increases
Agile Model
• In earlier days, the Iterative Waterfall Model was very popular for
completing a project. But nowadays, developers face various problems while
using it to develop software. The main difficulties included handling customer
change requests during project development and the high cost and time
required to incorporate these changes. To overcome these drawbacks of the
Waterfall Model, in the mid-1990s the Agile Software Development model
was proposed.
Importance
• Mostly used model in todays digital era.
• Agile means The ability to respond to changes from requirement,
technology and people
• It is a combination of incremental and iterative process of s/w
development.
Working:
• Divide requirements in to multiple iterations
• Delivers multiple s/w req’s
• Each iteration runs for at least 2-3 weeks
• Direct interaction with customers
• Rapid project development.
• Time span of traditional model is more when compared to agile model
Traditional VS Agile Model
When to use Agile model?

• When frequent changes are required.

• When a highly qualified and experienced team is
available.
• When a customer is ready to have a meeting with a
software team all the time.
• When project size is small.
Principles
Advantages of Agile Method:

1.Frequent Delivery
2.Face-to-Face Communication with clients.
3.Efficient design and fulfils the business requirement.
4.Anytime changes are acceptable.
5.It reduces total development time.
Disadvantages of Agile Model:

1.Due to the shortage of formal documents, it creates

confusion and crucial decisions taken throughout
various phases can be misinterpreted at any time by
different team members.
2.Due to the lack of proper documentation, once the
project completes and the developers allotted to
another project, maintenance of the finished project can
become a difficulty.