Vous êtes sur la page 1sur 45

Software Engineering

B S Gandhi

What is Engineering and why do we need it?


Better Quality Better Price Better Turnaround times

Better Turnaround times


Software Engineering consists of
Engineering Practices Management Practices Support Practices

Engineering Practices are covered more in detail later Management Practices are about
Estimations Planning Monitoring and Control

B S Gandhi

Quality Basics
What is Quality
Meeting the specifications Meeting the requirements Fitness for use Meeting the stated, implied and legal requirements Minimum loss to the society

How do we achieve Quality?


Inspections & Testing - Quality Control Reviews, verifications, making sure that you are doing right Quality Assurance Process Approach TQM Six Sigma Quality by Design

Software Challenges
Software is developed, not manufactured Software does not wear out Software is mostly custom built Software does not contain sub-assemblies from outsiders

B S Gandhi

Challenges (contd)
Y2K problem !!! Some small programs and tools live longer than expected No visibility to decide how much is completed (during development) No proper estimation of effort and schedule

B S Gandhi

Myths
Management
We have a book containing all standards If we are behind schedule, we can add more programmers and catch up We can always decide to outsource if we do not know how to build

B S Gandhi

Myths (contd)
Customer
Basic requirements should be good enough to start coding. We can add more details of what we want later We agree that requirements continually change, but so what? Change can easily be accommodated since software is flexible

B S Gandhi

Myths (contd)
Programmer
Once we get the program to work, our job is done Until I finish coding, how do I assess the quality? The only deliverable work product is a working program Software engineering practices make us write more documents and slows down our work

B S Gandhi

Project Failure Rates Software Projects

Failed

28% 46%
Challenged

Succeeded

26%

Source: Standish Group Report (2001)

11

Process approach
What is a process A good process can deliver good output Engineering, Management and Support processes Software Development Life Cycle Phases of SDLC

B S Gandhi

Software Development
Software life cycle processes that comprise the activities of Requirements analysis Design Coding Testing Installation & Acceptance User Support

13

Software Project Management

Requirements Analysis
Requirements specification of the characteristics to be possessed by the software project or service Requirements analysis elicitation, documentation, review and approval of requirements
Software Project Management

14

Design
Design logical view of the implementation of the solution meeting customer requirements Data design data structures, data base elements Architectural design sub-systems, modules and programs Interface design user and external environment

15

Software Project Management

Coding
Coding converting the logic specified in the design in to programs as per chosen programming language

16

Software Project Management

Testing
Testing to ensure that the product is working according to the requirements Levels of testing unit, module, integration, system and acceptance
Software Project Management

17

Installation and Acceptance


Developed software to be installed on the user environment User training User acceptance
Software Project Management

18

User Support
Problem resolution Functionality enhancements Migration to new environments
Software Project Management

19

Process Architecture
For all the software development activities the process architecture defines

Entry and exit criteria Inputs and outputs Participants and responsibilities Activities to be carried out Verification and approval Standards

20

Software Project Management

Software Development Life Cycle Model


A framework containing the processes, activities and the tasks involved in the development, operation and maintenance of a software product spanning the life of the system from the definition of its requirements to the termination of its use (ISO/IEC 12207)
Software Project Management

21

SDLC Models
Waterfall model Spiral model Prototype model Iterative model Rapid application development model

22

Software Project Management

Waterfall Model
Also known as classic life cycle model, linear sequential model This model suggests a systematic and sequential approach to software development that begins at requirements analysis and progresses through all life cycle phases sequentially
Software Project Management

23

Waterfall Model (Contd)

RA

D
C T

I &A
CS

24

Software Project Management

Waterfall Model
Users Software Requirements Software Requirement Specifications High Level Design
Software Project Management

Detailed Design Coding and Unit Testing Integration Testing System Testing

Acceptance Testing

25
Warranty

V MODEL
Contract
Users Software Requirements Software Requirements Specifications

Review / Test
Acceptance Testing

Warranty

Software Development

High Level Design

Integration Testing

Quality Assurance

Detailed Design

Unit Testing

Coding

26
Project Management

Software Project Management

System Testing

Waterfall Model (Contd)


Development activities carried out sequentially Review and approval of each phase outputs Model does not permit going back and forth If any defect found, go back to the originating phase and start traversing sequentially all over again

27

Software Project Management

Waterfall Model (Contd)


Suitable for projects where Requirements are clearly defined Small and medium term duration Stable technology Familiarity with the domain and development environments

28

Software Project Management

Waterfall Model (Contd)


Advantages: Projects under control Pre-defined outputs at every phase Tracking changes is easy Early identification of slippages, if any

29

Software Project Management

Waterfall Model (Contd)


Disadvantages: In real life, customer requirements do change Customer appraisal of completed work - not feasible always Phases can not run concurrently
Software Project Management

30

Spiral Model
In a spiral model, software is developed in a series of incremental releases The spiral model is divided in to a number of framework activities or task regions
Software Project Management

31

Spiral Model (Contd)

I&A
T

32

Software Project Management

RA

Spiral Model (Contd)


Suitable for large projects with multi-location implementation

Each Spiral consists of a deliverable product


Feedback of each spiral is incorporated in the next spiral Customer can start using the system after every spiral

Each Spiral consists of a waterfall model

33

Software Project Management

Spiral Model (Contd)


Advantages: Useful for large projects Customer requirements evolve over a period Early availability of usable system Disadvantages: Total blue print should be available in the beginning Basic concepts in the underlying layer can NOT be changed

34

Software Project Management

Prototype Model
A prototype model is a representation of a real life situation, which can be evaluated by the user A prototype is developed based on the initial understanding of the customer requirements A visible working prototype helps customer to define the requirements

35

Software Project Management

Prototype model (contd)

Design Design Code Test Code Test

36

Software Project Management

Intial Requirements

Prototype Model (Contd)


Prototype model is used for eliciting customer requirements as well as identifying user machine interaction Prototype model is used in product development or for developing a new application for a customer
Software Project Management

37

Prototype Model (Contd)


Advantages :
Software Project Management

Can be used when customer is not sure about what he wants Faster way of finalising the requirements Useful for new technologies and domains

Disadvantage :
A prototype if used in a production environment, may lack quality or maintainability

38

Incremental Models

B S Gandhi

B S Gandhi

Agile Principles
Highest Priority Customer Satisfaction Welcome changing requirements Even late in the development Deliver working software frequently Business people and developers work together Build Projects around motivated individuals Most efficient method of conveying information within development teams face to face

Software Project Management

41

Agile Principles (contd)


Working software is the primary measure of progress Simplicity is essential Best performance of any individual will emerge from selforganizing teams

Software Project Management

42

Phases in Agile Models

B S Gandhi

Agile SDLC Models


SCRUM
Sprints Daily Stand-up meetings (Progress, Problems and Plan) SCRUM Master Backlog Sprints

Software Project Management

44

Agile SDLC Models


Extreme Programming
OO is the preferred development paradigm Only four phases Planning, Design, Code and Test User Stories that describe the functionality Design to follow keep it simple approach Coding - continuous refactoring and pair programming

Software Project Management

45

Vous aimerez peut-être aussi