Computer Program: A list of instructions,
written in a specific programming language
(Java, C, Fortran, etc.), which a computer
follows in processing data, performing an
operation, or solving a logical problem.
Software :
 Computer programs
 Configuration files used to set up these
programs
 User documentation explaining how to use the
software
 Support service
 System documentation describing the structure
of the software
Software is Abstract and Intangible
Advantage:
No physical limitations on its potential.
Disadvantage:
Since there are no physical constraints,
software can easily become extremely complex
and difficult to understand.
Software and Hardware over time
Software- Early Years Software Engineering vs Computer Science
 Quite small programs Computer science is concerned with theory and
 Written by one person fundamentals; software engineering is
 Written and used by experts in the concerned with the practicalities of developing
application area concerned and delivering useful software.
 Emphasis was on expressing known Software Engineering and System Engineering
algorithms efficiently in some programming System engineering is concerned with all
language aspects of computer-based systems
Software- Today development including hardware, software and
 often very large process engineering.
 developed by teams that collaborate over Software engineering is part of this process
periods spanning several years concerned with developing the software
 developers are not the future users of the infrastructure, control, applications and
system they develop and they have no expert databases in the system.
knowledge of the application area
Types of Software
Generic Products: Stand-alone systems
produced by an organization and sold on the
market
Bespoke (or customized) products: Products
developed specifically for a customer by a
contractor.
Engineering:Repeatable and predictable
approach to ensure meeting requirements,
budget, schedule and quality.
Software Engineering: Software engineering is
an engineering discipline that is concerned
with all aspects of software development
Process: ”a series of actions or operations
taken in order to achieve a particular end”
Software Process: “A structured set of
activities that leads to the production of a
software product.”
ISO/IEC12207 Software Life Cycle Processes
Software Development Process
It is a roadmap that helps you create a timely,
high-quality software
It describes the structure within which
software engineers operate
Software development process is a subset of
processes that a software organization perform
Activities in a software development process:
 System requirements analysis
 System architectural design
 Software requirements analysis
 Software architectural design
 Software detailed design
 Software coding and testing
 Software integration
 Software qualification testing
 System integration
 System qualification testing
 Software installation
 Software acceptance support
The steps in development of a software product Maintenance
 Requirements analysis and specification Covers any changes to the product after it has
 Design been tested
 Implementation Corrective maintenance
 Testing and Integration Removal of residual errors in the software
 Maintenance Adaptive maintenance
Requirements analysis and specification Adjusting the software to changes in the
Software Requirements Specification environment
Requirements analysis Perfective maintenance
client conceptualizes a product Changing software to improve some of its
concept exploration by developers qualities
Goal is to develop a complete, consistent,
unambiguous specification of the requirements
System requirements (includes hardware
requirements),
Functional requirements for software,
Quality requirements
Design
Design specification
Design techniques: Hardware vs Software
Object-Oriented design Hardware requires manufacture, whereas software
Design by contract does not
Design patterns HW: Focus on manufacture
Specification of Object-Oriented designs SW: Focus on Design & Code
Class-Responsibilities-Collaboration(CRC) card Hardware has physical models to use in evaluating
UML class diagrams design decisions
Specification of detailed design Hardware is composed of parts that wear out,
Pseudo code, Program Design Language (PDL) whereas software does not degrade from use
UML activity diagrams HW Reliability: a measure of failure of components
Implementation SW Reliability: a measure of number of remaining defects
Source Code Software Development Process Model
The code should be correct, maintainable, determine the stages (and their order) involved
traceable and efficient. in software development and evolution
Testing and Integration establish the transition criteria for progressing
Test cases and test plan from one stage to the next
Goal is to check that the product meets the specifications
Used to show presence of errors not their absence!
Code inspections (reviews, walk-throughs)
Module testing, Integration testing
Black-box vs. white box testing
Coverage metrics: statement coverage, branch coverage
Automated verification, Specification based testing
Code and Fix
Basic model used in earliest days of software
development, more lack of a model
It is only suitable for short programs, which
do not require maintenance, individual
programmers; it is unsatisfactory for large
projects and teams
Advantages
All that is required if the effort is sufficiently
small and if the final product is to be used by
the one who built it
Most customers are happy to pay, since effort
in both steps directly contributes to the
product.
Disadvantages
After several fixes the code becomes poorly
structured (a design phase is necessary)
Frequently, a well-designed code is a poor
match to the customers needs (when customer
is not involved) (a requirements phase is
necessary)
Code is expensive to fix because of poor
preparation for modification and testing
(testing and maintenance phases have to be
planned)
Waterfall (linear sequential model)
Advantages
There is iteration with the preceding and
succeeding steps but rarely with the more
remote steps
The change process is divided into
manageable units
After the requirements step is complete
there exist a firm baseline
Maximize the extend of early work
Why extended documentation ?
Verbal record is too intangible for
management decisions
Written description forces to provide
tangible evidence for completion
Prevents “I am 90% complete” syndrome
In early phases, design=documentation and
specification=documentation
Permits effective redesign and shared
understanding of the project
All derivatives of the Waterfall model in
effect transforms an abstract need to a
successively less abstract product
Disadvantages
Testing phase occurs at the end of the
development cycle. Errors might signal
major redesign.
If the product is totally original, some
experimental tests might be required before
building the system.
What software is going to do is subject to
wide interpretation even after previous
agreement.
Emphasis on documentation as completion
criteria
Inflexible partitioning of the project into
distinct stages (Difficult to respond to
changing customer requirements)
A working model of the software is not
available until late in the project life-span.
Because of the restricted feedback loops,
waterfall model is essentially sequential.
There are many other feedback points
beside the end of the phase
Redoing the whole phase is an enormous
piece of work
Influence from other phases or events are
not considered.
Prototyping Incremental
Evolutionary
Especially useful for interactive Functionality grows with increments
Evolutionary models are iterative
applications Once the development of an increment is started,
Development starts with the parts of the
After an initial requirements analysis, a its requirements are frozen. But the requirements
system which are understood
quick design is developed for later increments can continue to evolve.
An initial system is developed according to
This quick design should focus on aspects Advantages
outline requirements
of the software that will be visible to the Most important requirements are satisfied without
Evolve the system through multiple
user such as input/output formats waiting for the delivery of entire system
versions by customer feedback
The quick design is used to construct a Most important features receive the most testing
Specification, development, and validation
prototype Use of each increment clarify the requirements for
activities are carried out concurrently
The prototype is reviewed by the customer the next increment
Objective: Work with the customer to
and/or user to refine the requirements for Risk of overall project failure is reduced
explore their requirements and deliver a
the software to be developed Increments can be planned to manage technical
final system
Prototype serves as a mechanism for risks
Advantages
identifying software requirements Disadvantages
Enables users to better understand their
Disadvantages It may be difficult to map the requirements onto
needs
The quick and possibly poor choices made increments of the right size
Problems are detected earlier
in the design and the implementation of the
Suitable for small or medium sized systems
prototype may influence the real product
and short-lifetime systems
After seeing a prototype customer may
Parts of the larger system which are
demand a working product fast
difficult to specify (such as user the
The prototype becomes the requirements
interface) may be developed using
specification. Since requirements
evolutionary development
specification serves as a contract between
Disadvantages
customer and developer, a prototype may
The quick and possibly poor choices made
not be a good contract
in the design and the implementation of the
prototype may influence the real product
After seeing a prototype customer may
demand a working product fast
The prototype becomes the requirements
specification. Since requirements
specification serves as a contract between Evolutionary vs Incremental
customer and developer, a prototype may In evolutionary model, some badly defined
not be a good contract component may become core components of the final
Progress is not visible product and make it difficult to change.
Software deteriorates as changes are made The specifications evolve in the evolutionary model,
Special tools/techniques (e.g. 4GL) and however, for the incremental model, the
skilled personnel are required specifications are frozen once the development of
that increment starts. (Specifications of other
increments may change).
Hybrid Clean Room
Large systems are usually made up of several Develop and certify a pipeline of software
sub-systems increments that accumulate into the final
The same process model need not be used for system
all subsystems Continuous system integration and
Spiral functionality grow with the addition of
a risk driven model successive increments
a hybrid process model Correctness is achieved through formal
consists of iterative cycles specification, design, and verification
Focus on defect prevention rather than defect
Each loop represents a phase of the project removal.
(system feasibility, requirements def., system It is based on:
Rapid Application Development
design, etc.) Incremental development;
A type of incremental model
Formal specification;
High speed adaptation of waterfall model
Each loop is split into 4 sectors Static verification using correctness arguments;
Uses component based construction
Sector 1: Objective setting Statistical testing to determine program
If requirements are well understood, creates a
Sector 2: Risk assessment and reduction reliability.
fully functional system in couple of months.
Sector 3: Develop and validate Characteristics
Phases:
Sector 4: Planning Formal specification using a state transition
Business modelling
Advantages model.
Data modelling
It can accommodate different software models Incremental development where the customer
Process modelling
Risk-driven approach might avoid potential prioritizes increments.
Application generation
difficulties Structured programming - limited control and
Testing and turnover.
Considers alternatives early abstraction constructs are used in the program.
Concurrent Development
It focuses on eliminating errors early Static verification using rigorous inspections.
Activities such as analysis, prototyping, design,
•Does not involve separate approaches for Statistical testing of the system.
testing, etc occur concurrently
software development and software Advantages
At a given time, each activity is in one of the
maintenance Reliability improvement due to the strict usage
states: None, under development, awaiting
Disadvantages of formal methods
changes, under revision, under review, baselined,
Does not suit for contract software Productivity improvement
done
Rely on subjective risk assessment expertise Statistical quality control embedded into the
Component Based Development
process
Similar to spiral model
Certification of reliability
Based on object-oriented technologies
Disadvantages
This model depends on reusability of classes
Requires expertise in formal methods
Beneficial if a robust component library exists.
Might be time consuming
Component assembly leads to a 70 percent
Strict pipelined process have similar difficulties
reduction in development cycle time; an 84
of the waterfall model.
percent reduction in project cost
Agile Methodologies 12 principles of Agile
Agile methods are a family of software development
processes for teams facing unpredictable or rapidly changing
requirements.
 Extreme Programming (XP)
 Agile Modeling
 Adaptive Software Development (ASD)
 Crystal Clear and Other Crystal Methodologies
 Dynamic Systems Development Method (DSDM)
 Feature Driven Development
 Lean software development
 Agile Unified Process (AUP)

Manifesto for Agile Software Development

“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Agile vs Plan driven

Extreme Programming (XP) Extreme Programming (XP) Rules
The most popular agile software development Planning Coding
methodology. User stories are written (by the customer) The (expert) customer is always available
Places a higher value on adaptability than on Release planning creates the schedule prioritize the stories, make decisions,
predictability Make frequent small releases. detail the stories
Target: Small to medium sized teams (<10 members) The Project Velocity is measured. Code must be written to agreed standards.
building software with vague or rapidly changing The project is divided into iterations Code the unit test first.
requirements Short and constant length (for All production code is pair
Risky projects with dynamic requirements are good measurement) programmed.
candidates for XP. Iteration planning starts each iteration Only one pair integrates code at a time
5 Values Move people around. Integrate often (every few hours if
 Communication (with customer and within the team) Everyone should know enough about every possible)
"XP programmers communicate with their customers part Use collective code ownership.
and fellow programmers. " A stand-up meeting starts each day (short Do not optimize until the end.
 Simplicity: Keep design simple and clean meetings) No overtime.
Fix the XP process when it breaks.
 Feedback: Get feedback by testing the software starting
on day one Designing Testing
 Courage: Deliver the system to the customers as early Simplicity. All code must have unit tests.
as possible and implement changes as suggested. Feel Keep things as simple as possible as long as A release have both code and its unit tests
comfortable with refactoring or modifying or deciding topossible Unit test: tests one module in isolation
throw code away never add a functionality before it is All code must pass all unit tests before it
"With this foundation XP programmers are able to scheduled can be released.
courageously respond to changing requirements and Choose a system metaphor. When a bug is found tests are created to
technology. " a simple story of how the system works guard against it coming back
 Respect: (the latest value) respect others and their To name the classes and methods Acceptance tests are run often and the
work consistently score is published.
E.g. never commit change that break compilation Use CRC cards for design sessions. Tests that have to pass in order to show
Create spike solutions to reduce risk. the customer that you have met their needs
The XP methodology has 12 practices. Build a system which only addresses the At each iteration plan, user stories
The Planning Game problem under examination and ignore all translated to acceptance test
Small releases other concerns. No story is finished until the acceptance
Metaphor No functionality is added early. tests of that story passes 100%
Simple Design Refactor whenever and wherever possible. Sprint ??
Spike ??
Testing When not to try XP remove redundancy, eliminate unused
Refactoring functionality
When it is not supported by the company culture
Pair programming Without changing
More than 10 or 20 programmers (now,the functionality
he claims the opposite)
Collective ownership Project too big for regular complete integration
Continuous integration Where it inherently takes a long time to get feedback
40-hour week Where you can not realistically test
On-site customer When the physical environment is wrong
Coding standards
Requirement : (1) a condition or capability
needed by a user to solve a problem or achieve
an objective; (2) a condition or capability that
must be met or possessed by a system ... to
satisfy a contract, standard, specification, or
other formally imposed document.
The requirements for a system are
descriptions of the services provided by the
system and its operational constraints.
What are the uses of SRS?
 For customers it is a specification of the
product that will be delivered, a contract
 For managers it can be used as a basis for
scheduling and measuring progress
 For the software designers it provides a
specification of what to design
 For coders it defines the range of acceptable
implementations and the outputs that must be
produced
 For quality assurance personnel it is used
for validation, test planning, and verification
Software Requirement Process
The requirements engineering process can be
described in five distinct steps
 Requirements elicitation
 Requirements analysis and negotiation
 Requirements specification
 System modeling
 Requirements validation
Problem analysis :
Purpose: expansion of information and better
understanding of the problem and the purpose
of the software.
Activities: brainstorming, interviewing people
to gather domain knowledge, identifying
constraints.
Requirements specification :
Purpose: organize ideas, resolve conflicts,
eliminate inconsistencies, describe what is to
be built precisely by capturing the results of the
problem analysis
Activities: make decisions, prepare documents
describing system behavior.
Requirements definition
Includes user needs,
understandable by client and contractor
management, system procurers and users.
Requirements specification
Includes product behavior,
understandable by procurer and software
designer.
Software Requirements Specification (SRS)
A document that specifies the requirements for
a system or component. Includes:
 Functional and capability specifications, …
 Interfaces external to the software item;
 Qualification requirements;
 Safety specifications, …
 Security specifications, ….
 Human-factors engineering, …
 Data definition and database requirements;
 Installation and acceptance requirements…
 User documentation;
 User operation and execution requirements;
 User maintenance requirements.
Goal of SRS
 Understand precisely what is required of the
software
 Communicate the understanding of what is
required to all the parties involved in the
development
 Provide a means for controlling the
production to ensure that the final system
satisfies the requirements (including managing
the effects of changes), traceability
Essential difficulties in achieving goals of SRS
Comprehension: People do not know what
they want. They may not have a precise and
detailed understanding of what the output
must be for every possible input, how long each
operation should take, etc.
Communication: Software requirements are
difficult to communicate effectively. The fact
that requirements specification has multiple
purposes and audiences makes this problem.
Control: It is difficult to predict the cost of
implementing different requirements. Frequent
changes to requirements make it difficult to
develop stable specifications
Inseparable concerns: Requirements must
simultaneously address concerns of developers
and customers. There may be conflicting
constraints, which may require trade-offs,
compromises.
Accidental difficulties in achieving goals of SRS
Written as an afterthought
Confused in purpose: Since there are multiple
audiences for the requirements specification its
purpose may get confused.
Not designed to be useful: If requirements
specifications is rushed, written just to please
management, and poorly designed it will be
ineffective.
Lacks essential qualities: Stated
requirements may lack essential qualities such
as consistency and completeness.
Classification of Requirements Non-behavioral Requirements
Functional requirements: Defines the overall qualities or attributes to be
Describe the behavior of the system or system exhibited by the system during system service:
services. in terms of properties, restrictions or
Defines fundamental transformation that constraints.
should be performed on inputs to produce  Portability: The degree of ease to port a
outputs software running on one system
Nonfunctional requirements: environment to another one.
Defines the constraints on the system services.  Reliability: Ability of software to behave
Domain requirements: consistently in an acceptable manner.
Requirements that come from the application Calculate the number of bugs:
domain of the system and reflect characteristics
of the domain (can be functional or
nonfunctional) Monte Carlo Fallacies
Standards to comply with, security issues, etc.  Not all bugs have equal consequences
IEEE Std 830-1998 – SRS Outline  Existence of one bug may hide the presence
1.Introduction of another
1.1 Purpose  Not all bugs can be found equally easily
1.2 Scope  Fixing bugs often creates other bugs
1.3 Definitions, acronyms, abbreviations
1.4 References  Efficiency: The level at which software uses
1.5 Overview system resources.
2. Overall description  Capacity
2.1 Product perspective  Degredation of service
2.2 User characteristics  Timing
2.3 Product functions  Memory
2.4 Constraints  Usability
2.5 Assumptions and dependencies  Maintainability
2.6 Apportioning of Requirements
3. Specific requirements
Characteristics of a Good SRS
3.1 External interface requirements
3.1.1 User interfaces
 Correct
3.1.2 Hardware interfaces  Unambiguous
3.1.3 Software interfaces  Complete
3.1.4 Communication interfaces  Consistent
3.2 Functional requirements  Ranked for importance and/or stability
3.3 Performance requirements  Verifiable
3.4 Logical database requirements  Modifiable
3.5 Design constraints  Traceable
3.6 Software system attributes
3.7 Domain requirements
4. Appendices
Prototyping Conventional Approach Prototyping difficulties
Prototyping is the technique of constructing a Evolutionary prototyping difficulties
partial implementation of a system. Same as the difficulties of evolutionary
Purpose of Prototyping development model
As a source of new knowledge
Better understanding the poorly understood Throwaway prototyping difficulties
systems  Technical
SW and HW Prototyping  Managerial
HW prototypes are developed to validate the  Procurement
system design.
As the production is the most expensive phase
in HW systems prototypes are used to
minimize the cost of this phase.
SW prototype are usually build to Throwaway Prototyping
 validate the requirements
 explore the range of solutions possible
 determine the required interactions
Concrete Benefits
 Misunderstandings between software
developers and customers are identified
 Missing user services are detected
 Confusing user services are identified
 Requirements inconsistencies are identified
 Demonstration of feasibility and usefulness
of the application is possible
 The prototype creates a base to refine
specifications
Schools of prototyping Evolutionary Prototyping
 Throwaway prototyping
A quick and dirty software is constructed as a
prototype to satisfy its purpose. The prototype
is discarded after the desired knowledge is
gained.
 Evolutionary prototyping
A prototype is build, analyzed and adapted and
re-adapted to satisfy the better understood
needs. This process repeats until the desired
system is obtained.
 Operational prototyping
A combination of the two above.