Sunteți pe pagina 1din 76

Evolution of Software

• 1950 – Mid 1960 • Mid 1960 – Mid 1980


– Batch Orientation – Multi user, multi
– Limited Distribution session, multitasking
– Custom Software – Real time processing
– In house development – Database connectivity
– Product software
Evolution of Software
• Mid 1980 – Mid 1990 • Mid 1990 – Present
– Distributed Systems – Powerful PCs
– Embedded Systems – Internet
– Low cost hardware – Client-server
– Consumer Impact environment
– Object oriented
environment
– ……
Evolution of Software Engineering
• 1950 –1960 : Early days
– The term coined during this period
– First two international conferences sponsored
by NATO in 1968 and 1969
• Developing software product is far more complex
than developing standalone programs
• Principles of engineering design should be applied
to the task of developing large software product
• Fritz Bauer : Coined the term “Software
Engineering”
Evolution of Software Engineering
• 1970 – Mid 1980 : Software Crisis
– Cost and budget overrun
– Property damage
– Life and Death
– Brooks (1976)
• IBM 360 OS
• The Mythical Man Months
– Boehm (1981)
• Software Engineering Economics
Evolution of Software Engineering
• Mid 1980 – Presents : No silver bullets
– Software paradox
• Tools, formal methods, process and
professionalism
– Cost of Hardware
– Process and methodology
• Humprey (1989), Paulk(1991-1995)
• Capability Maturity Model
– Object Oriented Analysis and Design
• Rumbaugh et al. (1998)
– Emergence as a profession
Nature of Software Engineering
• Mathematics
• Science
• Engineering
– Manufacturing
– Industrial Engineering
– Project Management
• Computer Science
• !! Finding its own identity
Changes in software
development style
• Early computer programming
– Slow Computers, small programs, assembly level programming
– Exploratory programming style
• High-level language programming
– Semiconductor technology and compilers
– High level languages like COBOL, FORTRAN, ALGOL
• Control flow-based design
– Stress on control structures
• The sequence of program instructions
– Flow charting technique
– Structured programming methodology
• Avoidance of goto
• Single entry – single exit structures
• Sequence, selection and iteration
– PASCAL, MODULA, C
Changes in software
development style (Contd.)
• Data structure-oriented design
– ICs
– More importance to data structure
– Jackson’s structured programming, Warnier-Orr methodology
• Data flow-oriented design
– VLSI
– Complex software products
– Data flow oriented techniques
• Identification of major data items
• Flow of data between the processes
• Object-oriented design
– Objects
– Relationship among the object
Software Engineering
Course Content
• Software design techniques
• Software development processes
• Project management techniques
• Testing techniques
• Debugging techniques
• Quality Assurance techniques
• Software metrics
Books:
Software Engg-A practitioner's approach
R.S. Pressman
Software Engg – Sommerville
Fundamentals of SE – Prof. Rajib Mall
Defining Software
• New Webster Dictionary (1981)
– Software is the program and programming support
necessary to put a computer through its assigned
tasks, as distinguished from the actual machine
• Blum (1991):
Software is the detailed instructions that control
the operations of a computer System. Its
functions are to
– Manage the computer resources of the organization
– Provide tools for human beings to take advantage of
these resources.
– Act as an intermediary between organizations and
locate information
Levels of Software
Hardware 1. Machine Micro logic
Logic
System 2. Supervisors or Executives
Software 3. Operating Systems
4. Language Translators
5. Utility Programs
Application 6. Inquiry, File, and Database software
Software 7. High level and assembly language
programs
End-user 8. 4GLs
Software
Program Vs. Software Product
• Program • Software Product
– Personal use – Multiple developer
– Limited life – Multiple user
– a good interface – Longer Life span
– No need for – Thorough testing and
documentation careful implementation
– ……. – Good user interface,
user manual
– Maintainable - Good
documentation support
Defining Software Engineering
• Fritz Bauer
Software Engineering is the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines
• IEEE (IEE93)
Software Engineering: (1) The application of a
systematic, disciplined, quantifiable approaches to the
development, operation and maintenance of software;
that is, the application of engineering to software. (2)
The study of the approaches in (1).
• The discipline of software engineering discusses
systematic and cost-effective approaches to
develop good quality software.
Nature of Software Engineering
• Mathematics
• Science
• Engineering
– Manufacturing
– Industrial Engineering
– Project Management
• Computer Science
• !! Finding its own identity
A Comparison With Traditional
Engineering Discipline
• Problem domain can be anything
• Abstract Design to Concrete Product
– Abstract Design to More Abstract Code
• Product Standardization for reduced cost
– Process Standardization
• Unlimited number of domain- and
application specific notions
– Limited but universally accepted principle
Software Characteristics
• Developed or engineered, not manufactured in a
classical sense

– The concept of ‘raw material’ is nonexistent here. It is better


visualized as a process rather than a product.
– The ‘human element’ is extremely high in software development,
compared to manufacturing
– The development productivity is highly uncertain, even with
standard products, varying greatly with the skill of the developer.
– Development tools, techniques, standards, and procedures vary
widely across and within an organization.
– Quality problem in software development are very different from
those in manufacturing.
Software Characteristics (Contds.)
• Software Development presents a job-shop
environment.

– Here the product is custom built hence unique.


– It cannot be assembled from existing components.
– All the complexities of the job shop (viz. The problem
of design, estimating, and scheduling is also present
here.
– Human skill, the most important element in a job
shop, is also the most important element here.
Software Characteristics (Contds.)
• Time and effort for software development are
hard to estimate.
– Interesting work gets done at the expense of the dull
work.
• documentation, being a dull work, gets the least priority
– Doing job in a clever way tends to be more important
consideration than getting it done adequately; on
time, at reasonable cost.
– Programmers tend to be optimistic, not realistic and
their time estimate for the task completion reflects this
tendency.
– Programmers have trouble communicating.
Software Characteristics (Contds.)
• User requirements are not often conceived
well enough; therefore a piece of software
undergoes many modifications, before it is
implemented satisfactorily.
• There is virtually no objective standards or
measures by which to evaluate the
progress of software development.
• Testing a software is software is extremely
difficult, as well as expensive.
Software Characteristics (Contds.)
• Software does not wear out.
– will not lose its functionality with use.
– may lose its functionality due to change in
user requirements.
– Defects are removed by rewriting the relevant
code, not by replacing with the available code.
– When defects are removed it is very likely that
new defects are introduced.
Software Characteristics (Contds.)
• Hardware has a physical model to use in evaluating
design decisions. Software design evaluations, are on
the other hand, rests on judgment and intuition.
• Hardware because of its physical implementation has a
practical bound on complexity, software on the other
hand, can be highly complex and still confirms to almost
any set of needs.
• There are major differences between the management of
a hardware and software project.
– May be counter productive. Ex: Reporting 100% completion in
terms of LOC may be highly misleading.
Evolution of a Programming
System Product
• A program
– Complete in itself
– Run by the author
– Run on a m/c where it is developed
• A programming product
– Can be run, tested, repaired and extended by
anybody.
– Must be thoroughly tested, and well documented.
– Costs three times as much as the corresponding
program.
Evolution of a Programming
System Product (Contds.)
• Programming System
– A collection of interacting program
– User interface
– Consistent in memory usage
– Must be tested with other components in all expected
combinations.
– Costs three times as much as a standalone program.
• A programming System Product
– All the features of a programming product and a
programming systems a product.
– Costs three times as much as a stand-alone program
of the same function
Software Crisis
• Software cost outstripping hardware cost.
• S/W maintenance cost has surpassed the hardware
cost.
• Time and cost overrun
• Lack of transparency and hard to maintain
• S/W is often less than adequate
• Often does not satisfy the end user
• Productivity of s/w people has not improved with the
demand for their services.
• Progress on software development is difficult to
measure.
• Standardization not possible due to lack of data
• How a person works during software development is not
yet understood
Myths that prevail in S/W industry
• Management Myth
– standards and procedures for building s/w, newest hardware,
state-of-the-art software development tool will increase the
productivity of people.
– If project is running behind the people add more people.
• Customer Myth
– A general statement on objective is sufficient to begin writing the
program. We can fill in the details latter.
– Software are flexible hence changes can be easily
accommodated.
• Practitioner’s Myth
– Once we write the program and get it work our job is done.
– Until I get the program running, I have no way to assess its
quality
– Only deliverable for a successful project is a working program
System Development Life Cycles
• Cycle: A succession of events repeated regularly
within a given period of time
• Life Cycle: A sequence of events or patterns that
reveals themselves in the life cycle of an
organism
• System Development Life Cycles:
– Pattern that is observed in the lifetime of a s/w
product
– Its recognition hold the key to successful software
development
Software Process Models
• Code and fix model
• Classical waterfall model
• Evolutionary model
• Prototyping
• Spiral models
Classical Waterfall Model
Feasibility
Study

Requirements
Analysis

Design and
Specification

Coding and
unit testing

Integration and
system testing

Maintenance
Feasibility study
• Systems Engineering and Information
Engineering
• Abstract definition of the problem
• Formulation of alternative strategies
• Examination of alternatives
– Resources required and available
– Development cost and time
– Cost-benefit analysis
Requirement Analysis
• Requirement Analysis
– Interviews and discussions
– Incomplete views
– Ambiguities and contradictions
• Requirements Specification
• User manual
• System test plan
• End product - SRS Document
Design
• Translation of SRS into a structure that is
suitable for implementation
• Traditional design approach
– Structured Analysis – DFD
– Architectural design
– Detailed design
• Object oriented design
– Identification of objects and relationships
– Detailed design
• End product – A set of design documents
Coding and Unit Testing
• Translation of designs to source code
• Testing each program module
• End product – a set of program modules
that are individually tested.
Integration and Unit Testing
• Partial integration and testing
• System testing
– Alpha testing
– Beta testing
– Acceptance testing
Maintenance
• Corrective
• Perfective
• Adaptive
Variations of waterfall model
(Royce, 1970)
Requirements
Analysis

Design and
Specification

Coding and
unit testing

Integration and
system testing

Maintenance
Variations of Waterfall Model
Feasibility Study
Validation (Boehm, 1981)
Software Plans and
Requirements Analysis
Validation

Product Design
Verification

Detailed Design
Verification

Coding
unit testing

Integration
Product Verification

Implementation
System Test

Maintenance
Revalidation
Waterfall Model (Pressman, 2005)
Communication
project initiation
requirements gathering

Planning
Estimating
scheduling
tracking

Modeling
Analysis
Design

Construction
code test

Deployment
delivery,
support
feedback
Assumptions of waterfall model
• Unidirectional flow of control among the phases
• Downward flow of primary information and
developmental effort.
• Work can be divided according to phases
among different classes of specialists.
• It is possible to associate a goal for each phase
(the exit condition)
• Output of one phase is used as input to the next
phase after review, verification and validation
(Limited iterative flow)
Assumptions of waterfall model
• Output of each phase is frozen.
– Baseline – check point
– Configuration management
• It is possible to create different
development tools suitable to the
requirements of each phase
• Phases provide the basis for management
and control
Economic rationally Behind
Waterfall Model (Boehm)
• All phases and their associated goals are
necessary
• Any different ordering of the phases will
produce a less successful software.
Usefulness of the waterfall model
• Complete specification of the system before it is
built
• Understanding interaction of the components
before coding
• More accurate tracking of the project and early
discovery of the schedule slippage
• Documentation for ease of testing and
maintenance
• Reduced development and maintenance cost
• More structured and manageable system.
Shortfalls of Waterfall Model
• Protracted Integration and Late Design Breakage
– Blocking state of developers
– Working version takes long time to come up
– Non-optimal-fixes, little time for redesign, late delivery of a non-
maintainable product
• Late Risk Resolution
– Risk: the probability of missing cost, schedule, feature, or quality
goal
– High at the requirement phase
• Requirement driven Functional decomposition
– customers must state all requirements explicitly
– All the requirements are equally important and do not change over
the SDLC
– Decomposition of requirements to functions and sub functions
• Adversarial stakeholder relationship

As a result
Real projects rarely follow this model
A Critique of the Waterfall Model
• rigid
• monolithic
• Heavily document driven hence
bureaucratic
As a result
Many refinements are proposed
• Incremental Model
• Evolutionary Model
• Spiral Model
The Incremental model
• Applying linear sequence in a staggering
manner
• First increment is the core product
• Focuses on the delivery of an operational
product
• Useful when staffing is inadequate
• Technical risk can be handled
The Incremental model
Communication

Planning
Software Functionality and Features

Modeling

Construction

Deployment

Calendar Time
The RAD Model
(Rapid application development)

• Fully functional system in a short time


(60 –90 days)
• Phases
– Communication
– Planning (for multiple teams)
– Modeling (Business, Data, Process)
– Construction (Use of Components, Automatic
Code generation)
– Deployment (Integration, Delivery, Feedback)
The RAD Model contd.
Team #1

Communication
• Shortfalls Modeling

– Sufficient and efficient


Construction
manpower Team #2

Modeling
– Commitment of the

Deployment
team members
Construction
– Appropriate Team #n

modularization Modeling

Planning
– Not suitable for high
Construction
technical risk projects
Component Based Models
-Software Reuse
Requirements Detail Design of the
Remaining
Components
Design of
Architecture
Coding and Unit of
the Remaining
Components
Component
Specification

Search for reusable


Integration
components

Delivery
Advantages of Software Reuse
• Increases system reliability
• Reduces overall project risk due to less
uncertainty in cost estimates
• Effective use of specialists in developing generic
components than in a wide array of variety of
products
• Embodiment of organizational standards in
reusable components, such as user interface
and error handling procedures
• Reduction of software development time.
Guideline for Software Reuse
• Generalized
– Names, operations, exceptions
• Documented
• Availability of test cases
Common Problems of
Software Reuse
• Portability
– Transportation
– Adaptation
• Customization
Cleanroom Software Development
• Suitable for the systems that have stringent
safety, reliability and security requirements.
• Formal specification of the requirements
• Incremental development strategy
• Structured programming
• Static verification of the individual build using
mathematically based correctness argument
• Statistical testing with the help of reliability
growth models
The Prototyping Model
• Iterative in nature
• Customers are unsure of Communication
their requirement
• Developers are unsure of Quick Plan
the development
environment Deployment,
delivery and
• Can be applied with any feedback
other paradigm Modeling and
• Evolutionary or quick design
throwaway Construction of
the Prototype
Evolutionary Vs. Throwaway
Prototyping
• Both types assume that at the outset some abstract,
incomplete set of requirements has been specified.
• Both allows user feedback
• Evolutionary prototype is delivered to the customer with
minimal changes.
• Throwaway prototype is used just to collect user
requirements. Hence the actual deliverable is developed
afterwards.
• Evolutionary prototype is difficult to maintain
• Throwaway prototype is not suitable for testing non-
functional requirements
Benefits of Prototyping
• Resolves communication gap and misunderstanding between
software developer and users.
• Missing user services may be detected
• Difficult to use or confusing user services may be identified
and refined
• Resolves inconsistencies and incompleteness in the users’
requirements
• Helps in gaining user confidence
• Helps in writing specifications
• Correct specifications of the requirements reduces
requirements-related errors and therefore overall
development cost
• Training user before delivering the product
• Test cases developed during prototyping can be used for
testing the final product.
Guidelines for developing the
prototype
• Objective of the prototype must be explicitly
stated to the user
– Validate functional requirement
– Validate user interfaces
• Requires cost
– Non-functional features can be ignored
– Need not maintain error handling routines
– Need not adhere to the quality and reliability standard
– Suitable tools or development languages may be
used
• Usable components
• Executable specification language – z specification language
• Forth generation language – SQL
• Very high-level language – Smalltalk, Prolog or Lisp
Shortfalls of Prototyping

• Customers wishes to have it as the


working product
• Developers makes compromises to make
it the working product
The Spiral Model (Boehm, 1998)
• Iterative in nature
• Each loop represents a phase in the software
process
• Each loop is broken into 4 sectors
• Sophistication increases with each version
• Risk analysis is a must in planning phase
Shortfalls
• Difficult to convince the customer
• Needs Risk Assessment Expertise
Quadrant – 1: Formulation Quadrant – 2: Analysis
Identify need, objectives, Identify alternatives and
Constraints, & alterable risks

Risk Analysis

Risk Analysis
P4
Risk Analysis
P3
Operational
Risk Analysis P2 prototype
P1
Final Dev, s/w dev s/w Req Lifecycle Mgmt Detailed
Intgr & plan plan Control Plan Control Plan Design
Test Plan
Reqts
Validations Code

Design Validation Unit


and verification Test
Integrate
Acceptance and Test
Quadrant – 4: Interpretation Implem test
entation
Quadrant – 3: Interpretation
Plan for the next phase of the
spiral life cycle Develop and Evaluate
Comparison of Alternative Software
Development Life Cycle Models
• Waterfall Model
– Sequence of phases
– Limited feedback
– Iteration between phases
– Document based
• Prototype Model
– Many iterations
– Feedback on partial builds
– User based
• Incremental Development
– Addition of functionality to the initially built kernel
• Spiral Model
– Risk based
– Incremental/prototyping is followed to eliminate risk, establish user
requirement, and detailed software design before taking final coding,
testing and implementation
Five metric for comparison
• Shortfall
– A measure of how far the software is, at time t from meeting the
actual user requirement.
• Lateness
– a measure of the time delay between the appearance of a new
requirement and its satisfaction
• Adaptability
– The rate at which a s/w solution can adapt to new requirements,
a measured by the slop of the solution curve
• Longevity
– The time a system solution is adaptable to change and remains
viable (Time from creation to replacement)
• Inappropriateness
– A measure of the behavior of the shortfall over time.
Software Productivity Metrics

User Need
Conventional Approach

Shortfall
Inappropriateness

Lateness

Adaptability

t0 t1 t2 t3 t4
Longevity
Phasewise distribution of effort
• 40-20-40 rule
– Analysis & Design (40%)
– Coding and Debugging (20%),
– Testing and Checkouts (40%)
• Wolverton (1974)
Requirements Analysis – 8%
Preliminary Design – 18% 46%
Interface Definition – 4%
Detailed Design – 16%
Code and debug – 20%
Development testing – 21% 34%
Validation testing – 13%
Phasewise distribution of effort
• Thibodeeau and Dodson (1984)
– Analysis & Design (37%)
– Coding and Debugging (20%),
– Testing and Checkouts (43%)
• Fagan (1986)
– Snail Shaped Curve Coding
Planning
Requirements

Design Testing
Lifecycle Phase Interrelationships
Time

Analysis

Design

Person-Hour
Coding and Unit Testing
Loading

Planned Integration and


unit testing
Actual
Maintenance
Project Curve (Putnam, 1978)
Project Curve
Man-Year/ Year

Test and
Validation
Extensions
Design
and
Coding
Modification

Plan Functional
Maintenance
Spec

Time
Unified Process Model
• Ivar Jacobson, Grady Booch, and James
Rumbaugh (1999)
– Use-case driven
– Architecture centric
– Iterative and Incremental
– Static and dynamic models
Phases of Unified Process Model
Inception Phase
Vision Document, Elaboration Phase
initial use-case
Use-case model,
model,
Supplementary
initial project
Requirement Construction Phase
glossary,
including non-
Design Model ,
Initial business functional Analysis
case, model, Software Components,
Initial risk Software architecture Integrated software
assessment, description, increment,
Project plan – Executable test plan and
Phases and architectural procedure,
iterations prototype,
Test cases,
Preliminary design
Support Transition Phase
model,
documentation – user
Project Plan, manual, Delivered software
Preliminary user’s increment,
installation manual,
manual Beta test reports,
description of the
current increment General user
feedback
The Agile View of the Process
(Beck, 2001)

• Individual and interactions over processes


and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a
plan
Principles to Achieve Agility
• Early and continuous delivery of valuable
software.
• Harness change for customer’s competitive
advantage.
• Preference to shorter timescales.
• Motivated individual
• Face-to-face conversation.
• Working software
• Sustainable development.
• Continuous attention to technical
excellence and good design.
• Simplicity
• Self organizing teams
• Introspection at regular intervals
Characteristics of agile process
• Change in customer’s requirements and
priorities
• Interleaved design and construction
• Unpredictable analysis, design and testing
from planning point of view.
Agile Process Models
• Extreme Programming (XP)
• Adaptive software development
• Dynamic system development method
• Scrum
• Crystal
• ….
Extreme Programming
• Assumes object oriented development paradigm
• Encompasses a set of rules and practices that occur
within the context of four framework activities – Planning,
design, coding and testing
• Planning
– Use stories by customer
– Value (priority) by customer
– Cost (developmental, in terms of development weeks) by
designer
– Breaking of stories if required
– Project velocity (no of stories to be implemented with each
increment)
– Addition, modification and deletion of stories by the customer at
any time
Extreme Programming
• Design
– Keep it simple
– CRC Card (class-responsibility-collaboration)
– Spike solution (immediate creation of an operational prototype)
– Refactoring
• Coding
– Refactoring
– Pair programming
– Unit and integration testing
• Testing
– integration testing
– Acceptance testing
SCRUM
Scrum Meeting:
Progress,
Obstacle, Plan

Backlog item
expanded by
Sprint team
member
Sprint
Backlog 30 Days
Demo

Product Prioritized Product Features


Backlog as desired by the customer

S-ar putea să vă placă și