UNIT I

1.1 INTRODUCTION

Software is the engine that drives the business decision making. It serves as the basis for scientific investigation and
engineering problem solving. Software is embedded in all kinds of systems – transportation, medical, telecommunications,
military, industrial processes, entertainment, office products, and elementary education to genetic engineering.

Computer Software is the product that software professionals build and then support over the long term. It consists of
programs that execute within a computer of any size and architecture. Software engineering consists of process, collection of
methods and a list of tools that allow professionals to build high quality computer software. Software engineering is important
because it enables to build complex systems in a timely manner and with high quality by applying the various processes.

There are few questions of concern about the software and the manner in which it is developed. To address these
concerns we adopt Software Engineering Practices.
o Why does it take so long to get software finished?
o Why are development costs so high?
o Why can‟t we find all the errors before we give the software to customers?
o Why do we continue to have difficulty in measuring progress as software being developed?

1.1.1 Software - Definition

Software is:
(1) Instructions (computer programs) that when executed provide desired function and performance
(2) Data structures that enable the programs to adequately manipulate information
(3) Documents that describe the operation and use of the programs

1.1.2 Software Process

A Software Process is the set of activities and associated results that produce a software product. There are four
fundamental process activities that are common to all software products. They are:

1. Software specification where customers and engineers define the software to be produced and the constraints on its
operation.
2. Software development where the software is designed and programmed.
3. Software validation where the software is checked to ensure that it is what the customer requires.
4. Software evolution where the software is modified to adapt it to changing customer and market requirements.

Different types of systems need different development processes. Use of an inappropriate software process may reduce
the quality or the usefulness of the software product to be developed and/or increase the development costs.

1.1.3 Software Engineering Goals

Deliver software:
o On time
o Within budget
o With required quality
o Satisfying true needs of stakeholders

Stakeholders - customers, developers, managers and all those who are interested in a software development and
implementation.

1.1.4 Software Characteristics

Characteristics of software that make it different from other things that human beings build are:

1. Software is developed or engineered; it is not manufactured in the classical sense.

Although some similarities exist between software development and hardware manufacturing, the two activities are
fundamentally different. Both activities require the construction of a “product,” but the approaches are different.

2. Software doesn’t “wear out.”

Hardware begins to wear out over time due to environmental factors. But, software doesn‟t wear out, it does deteriorate.
The failure rate curve for software should take the form of “idealized curve”. Undiscovered defects will cause high
failure rates early in the life of a program. However, these are corrected and the curve flattens.
 Fig. 1.1 Idealized and Actual Failure Curves for Software

3. Although the industry is moving towards component-based construction, most software continues to be custom built.
The reusable components have been created so that the engineer can concentrate on the truly innovative elements of a
design, that is, the parts of the design that represent something new. A software component should be designed and
implemented so that it can be reused in many different programs.

1.1.5 Software Applications

Information content and determinacy are important factors that determine the nature of the software application.

Potential Software Applications:

o System Software
 Collection of programs written to service other programs
 Characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent
operations
 Example – Compilers, Editors, Operating System Components

o Real-Time Software
 Software that deals with real time events
 These software requires real-time responses (ranging from 1 millisecond to 1 second)

o Business Software
 Management Information System software that accesses one or more large databases that contains
business information.
 Example- Payroll, Inventory, Accounts Receivable and Payable

o Engineering and Scientific Software

 Approach is away from conventional numeric algorithm.
 Example – Astronomy, volcanology, automotive stress analysis, space shuttle, orbital dynamics,
molecular biology, automated manufacturing.

o Embedded Software
 Intelligent software that resides in read-only memory and controls products and systems.
 Example – Fuel control digital functions in automobiles, softwares in electronic items – intelligent AC,
washing machine, TV etc.

o Personal Computer Software

 Most of the available software in the market
 Example – Word processing, Spreadsheets, computer graphics, multimedia, business financial
applications, etc.

o Web-Based Software
 Web pages hosted on a browser, that has data (hypertext, visual and audio) and executable instructions.
 Example – Any software available on the NET.
 o Artificial Intelligence Software
 Software that makes use of non numerical algorithms to solve complex problems.
 These cannot be achieved through computations or straight forward analysis.
 Example – Expert Systems, Pattern recognition (image, voice), Game Playing etc.
Software Engineering is a Layered Technology.
 Quality: (Bedrock for Software Engineering)
o Organizations are committed to quality
o This leads to development of more effective approaches to software engineering
 Process: (Basis for Software Project Management)
o Defines a framework (set of tasks) for effective delivery of Software Engineering Technology.
o Technical methods applied, Work Products produced, Milestones established, Quality ensured, Change managed
 Methods: (Provides technical how-to‟s for building software – Set of Basic Principles)
o Tasks include:
 Communication
 Requirements Analysis
 Design Modeling
 Program Construction
 Testing
 Support
 Tools:
o Provide automated or semi automated support for process and methods.
o When tools integrated – information created by one tool can be used by another – Called as computer-aided
software engineering

Fig. Software Engineering Layers

Capability Maturity Model Integration - CMMI

o SEI – Software Engineering Institute measures the process maturity of an organization. This is measured in
terms of specific goals and specific processes.

 Level 0: Incomplete
o All goals not achieved
o Process is not performed
 Level 1: Performed
o Tasks to produce the required work products are being done
 Level 2: Managed
o Get tasks done by resources
o Stakeholders are actively involved
o Work tasks and products are monitored, reviewed and evaluated for conformance to process
 Level 3: Defined
o Management and Engineering Processes are Documented, Standardized and Integrated into Organization wide
Software Process
 Level 4: Quantitatively Managed
o Software Process and Products are Quantitatively understood and controlled – using measures
 Level 5: Optimizing
 o Continuous process improvement
o Quantitative feedback from process
o Testing innovative ideas

 CMMI - Measured in terms of specific goals and specific processes

 Specific Goals: Establishes required characteristics for the process to be effective.

 Specific Process: Refine a goal into a set of process-related activities.

Process Framework
 A process is a collection of activities, actions, and tasks that are performed when some work product is to be created.
 Work product – Eg., Architectural design of a software, Code of a module, Test cases for a module.
 Process is not a rigid approach – it is an adaptable approach – software team can choose the appropriate process model
for their software project.
 Intention of choosing a process is to deliver quality software on time in a cost effective manner and that satisfies the
needs of the sponsorers of the project.

Process Framework activities that are applicable for all software projects:
1. Communication
 Communicate and collaborate with the stakeholders
 Before technical work commences
 To understand stakeholders objectives for the project
 To understand requirements and define software features and functions
2. Planning
 Software Project – Complicated journey – map that guides the team for this journey
 Software Project Plan – Defines:
 Tasks to be performed
 Risks forecasted
 Resources required
 Work products to be produced
 Work schedule
3. Modeling
 Sketch of the software project to understand the big picture
 Architectural design of the software project
 Refine it further to understand the project better
4. Construction
 Code generation – manual or automatic
 Testing – to uncover errors in code
5. Deployment
 Software delivered to the client
 Customer evaluates the delivered product
 Provides feedback

 These framework activities are common for all software projects regardless of size and complexity.

Framework activities complimented by a set of umbrella activities – They are:

1. Software Project Tracking and Control
 Software team assesses progress against project plan
 Takes necessary action to maintain the schedule
2. Risk Management
 Assess risks that may affect the project outcome / project quality
3. Software Quality Assurance
 Defines and conducts activities to ensure quality
4. Technical Reviews
 Assesses work products
 To uncover and remove errors
5. Measurement
 Defines and collects process, project and product measures
 Assists in ensuring quality
6. Software Configuration Management
  Manages the effects of change to software
7. Reusability Management
 Defines criteria for work product reuse
8. Work product preparation and production
 Tasks to prepare work products

 Process Flow – Describes how framework activities, actions and tasks that occur within each framework activity are
organized with respect to sequence and time.

 Linear Process Flow – executes each framework activity in sequence.

 Iterative Process Flow – repeats one or more activities
 Evolutionary Process Flow – Executes the activities in a circular manner.
 Parallel Process Flow – Executes one or more activities in parallel with other activities – Eg. Design and Construction in
parallel.

A Software Process Framework

Process Patterns:
 Describes a process-related problem encountered during a software engineering
 Identifies the environment in which the problem has occurred
 Suggests one or more proven solutions to the problem
 Process Pattern provides a template
 Combining patterns, a software team can solve problems and construct a process that meets the project needs
 Patterns can be defined at any level of abstraction
 Process Patterns can be reused

 Process Pattern Template consists of:

o Pattern Name:
 Eg. Technical Review
o Forces:
 Issues that affects the solution
o Type:
 Stage Pattern
 Task Pattern
 Phase Pattern
o Initial Context
o Problem
o Solution
o Resulting Context
o Related Patterns
o Known Uses and Examples
Process Assessment:
 Process needs to be assessed to ensure that the process meets a set of basic process criteria

Fig. Software Process Assessment

PSP – Personal Software Process

 PSP recommends five framework activities:
o Planning
o High Level Design
o High Level Design Review
o Development
o Post-mortem
 PSP stresses on the need of each software engineer to identify errors early and to detect the type of errors.

TSP – Team Software Process

 TSP recommends five framework activities
o Project Launch
o Design
o Implementation
o Integration & System Testing
o Post-mortem
 TSP aims to build self-directed teams, who can plan & track their work, establish their own goals, process and plan.
Personal and Team Process Models
 The best software process is one that is close to the people who will be doing the work
 Software process model – developed at the organizational / corporate level
 It becomes an effective process model only if it can be changed to the needs of the software team.

 Personal Software Process (PSP):

o Every developer uses some process to build computer software
o Process may be ad-hoc, inefficient and not successful
o To change ineffective personal process – individual should move through five phases
o Each phase requires training and careful instrumentation
o PSP – Emphasizes on personal measurement of both the work product and its quality

o PSP Model defines five framework activities:

 1) Planning:
 Isolates requirements
 Develops size estimates
 Develops resource estimates
 Estimates defects
 Metrics recorded on worksheets
 Development tasks identified
  Project schedule create
 2) High-Level Design:
 Design for each component constructed
 3) High-Level Design Review:
 To uncover errors in the design
 Metrics maintained for all tasks and work products
 4) Development:
 Component-level design is refined and reviewed
 Code generated
 Code reviewed
 Code Compiled
 Code Tested
 Metrics maintained for all tasks and work products
 5) Postmortem:
 Using the collected metrics and measures – process effectiveness determined
 Process modified to improve effectiveness

o PSP – Stresses on identifying errors early, to understand types of errors likely to make
o This is done by rigorous assessment of work products
o PSP – Disciplined, metrics-based approach to software engineering – leads to cultural shock for practitioners
o PSP introduced – leads to improvement in productivity and software quality
o PSP not widely adopted in industry – due to human nature and organizational culture
o PSP – Intellectually challenging – demands a level of commitment – training costly and lengthy

 Team Software Process (PSP):

o Goal of TSP – Self-directed project team – organizes itself to produce high quality software

o Objectives for TSP:

 Build self-directed team that:

 Plan and track their work
 Establish goals
 Own processes and plans
 IPT – Integrated Product Team – 3 to 20 engineers

 Educate managers to motivate their teams and sustain peak performance

 Accelerate software process improvement by following CMM Level 5 criteria
 Provide improvement guidance to high-matured organizations
 Facilitate university teaching of industry-grade team skills

o Self-directed teams have consistent understanding of goals and objectives

o Defines roles and responsibilities of each team member
o Tracks quantitative project data
o Continuously assess risks and reacts to it
o Tracks, manages and reports project status
o TSP Model defines five framework activities:
 1) Project Launch
 2) High-Level Design
 3) Implementation
 4) Integration and Test
 5) Postmortem
o TSP makes use of wide variety of scripts, forms and standards that serve to guide team members in their work
o Self-directed team members: - set project objectives, adapt process to meet their needs, control the project
schedule, measure and analyze metrics collected
o TSP provides quantifiable benefits in productivity and quality
o Team‟s commitment and training is required

Process Technology
 Software team adapts a particular process model
 Process Technology Tools – developed to analyze a process, organize work tasks, control and monitor progress, manage
technical quality
  Builds automated model of process framework and umbrella activities
 Model is represented as network
 Network analyzed to determine workflow
 Examines alternative process structures
 Leads to reduced development time and cost
 Allocates, monitors and controls all tasks
 Develops a checklist of work tasks and work products
 Develops quality assurance activities to be conducted
 Coordinates the use of other software engineering tools

Product and Process

 Process is weak – end product will suffer
 But over reliance on process is dangerous
 Process issues leads to product issues

Product Process
Structured Programming Language Structured Analysis Methods
Data Encapsulation Capability Maturity Model
Object Oriented Methods Agile s/w development

 Software community‟s focus constantly shifts between Product and Process

 Product and Process forms a duality
 S/w artifacts cannot be understood fully if only process or product are considered
 Process is a human activity
 Reuse of product leads to human satisfaction  input for another s/w development activity
 People derive satisfaction in following the process as they get from the end product
 Artist enjoys the brush strokes as much as he enjoys the resultant art
 Writer enjoys his writing process as he enjoys the resultant article
 Duality of process and product keeps people creatively engaged as s/w engineering tasks evolve
Agile Process Models:
 What is Agility?
o It is the ability to collaborate.
o Agility is dynamic, aggressive, change and growth oriented.
o Effective response to change.
o Rapid delivery of software.
o Customer is part of the development team.

 What is an Agile Process?

o Difficult to predict which s/w requirements will not change and which will change
o Difficult to predict how customer priorities will change
o Design and construction may be interleaved
o Analysis, design, construction and testing phases are not predictable
o Agile process must be incrementally adaptable
o It requires customer feedback.
o Incremental development strategy should be used for software increments.
o It must be delivered in short time periods.

 What are the Agility Principles?

1. Highest priority is to satisfy customer
2. Welcome changing requirements, even late changes.
3. Deliver working SW frequently
4. Stakeholders and SW team must work together continuously.
5. Build around motivated individuals. Give them support and resources… then trust them to get it done.
6. Most efficient info exchange: face-to-face
7. Working SW is primary measure of progress
8. The process promotes sustainable development.
9. Continuous attention to technical excellence and good design.
10. Simplicity – the art of maximizing the amount of work NOT done.
11. Best results emerge from self-organizing teams.
12. Teams regularly review their team to become more effective.

 Politics of Agile Development:

o There are debates on the benefits and applicability of agile s/w development methods
o Traditional methodologists produce a flawless documents but not a working system that meets the
business needs
o Agile methodologists scales up their toys to an enterprise wide software
o Rational thought disappears – beliefs guides decision making rather than facts
o How to build a s/w that meets customer needs and that has quality in the long term?
o Agile concepts are adaptations of good s/w engineering concepts
o Much can be gained by considering the best of both schools
o Nothing can be gained by ignoring any one approach

 Human Factors:
o Agile team members should have the following key traits.
o 1) Competence:
 Skill and Knowledge
o 2) Common Focus:
 Each member has different tasks and different skills, but focused on one-goal.
o 3) Collaboration:
 Team members must collaborate with one another, with the customer and business managers.
o 4) Decision Making Ability:
 Team is given decision making authority for technical and project issues.
o 5) Fuzzy Problem solving Ability:
 Team must accept continuous change. Problem solving today may not be problem to be solved
tomorrow. Lessons to be learned are benefits to the team.
o 6) Mutual Trust and Respect:
 Should exhibit a „Jelled Team‟
o 7) Self Organization:
 Agile team organizes work, process and work schedule by itself. It improves collaboration and
boosts team morale.