The Software Development Process

Chapter 2

Best Practices

2

Software Development Activities

• DEFINE the Requirements

• ANALYSE Requirements

• DESIGN the Solution

• DEVELOP the Software

• TESTING the Software

• DEPLOY the Software

• MAINTAIN & MANAGE the Software

3

Traditional Software Development Life Cycle

4

The Waterfall model

5

Disadvantages of Linear developments

• Rigidity

• Sometimes impractical

6

Incremental Development

• Incorporates customer interaction• Repetitive process that progresses in incremental stages• Maintains focus on manageable tasks• Earlier stages successful before later stages attempted• Spiral model• Prototype – working model of the intended system (or

part of it) – useful to explore an idea• Possible for prototype to develop into the actual

solution over time

7

Roles of Prototypes

• Evolutionary– software adapted gradually as requirements becomes clearer– prototype gradually evolves into end product

• Experimental– Used for evaluating a possible solution e.g. assessing

performance, effectiveness– prototype discarded after evaluation

• Exploratory– Used to help clarify user requirements– Prototype discarded

8

Incremental Development Process using a prototype

9

Software Development Methods

• Further divides each stage of the SDLC into a set of steps and rules– Indication detail, nature and order of tasks– Documents needed as input / produced at each stage

• RAD – Rapid Application Development aim:– To shorten development life cycle– Produce systems quicker to respond to rapidly changing

business requirements

• Relies on user involvement & extensively use prototypes to capture requirements

10

Agile Methods

• Philosophy:– Individuals and interactions over processes and

tools– Working software over comprehensive

documentation– Customer collaboration over contract

negotiation– Responding to change over following a plan

• Example RAD

11

Extreme Programming (XP) agile SW development method

• Customer team member

• User stories• Short cycles• Pair Programming• Test-driven

development• Collective ownership

• Continuous integration• Sustainable pace• Open workspace• The planning game• Simple design• Refactoring• Metaphor

12

Choosing a Development Approach

• Avoid a linear (or sequential) approach unless:– requirements are well determined

– design is straightforward and well understood

– development team familiar with area

– project poses little risk

– Project has long-term predictability

– A ‘longer’ delivery time is acceptable

– Cost of changing requirements, design and code is high

13

Choosing a Development Approach

• Incremental (or iterative) development:– Requirements not well understood / unstable

– A need exists to demonstrate feasibility of an idea

– Design is complex and/or challenging

– Development team unfamiliar with area

– Lot of risk

– Long-term predictability NOT important

– Cost of changing requirements, design & code is low

– System evolves in response to developers perception

14

Formal methods- Serious Disadvantages -

• Represents the designer’s understanding of requirements

• Encourage specialization, which lead to poor communication, wasted effort, isolated progress

• Lacks the ability to illustrate a system’s dynamic & adaptable nature

15

Requirements Engineering

• Requirements elicitation– Developer determines client’s needs

• Requirements specification– Developer records requirements

• Requirements validation– Developer checks that requirements are

correctly described and understood

16

“Don’t gather requirements – dig for them!”Hunt & Thomas, 2000

17

Examples of Requirements

• An employee record may be viewed only by a certain group of people.

• A computer-generated identifier must be used to identify each employee.

• The cylinder-head temperature must not exceed the critical value, which varies by engine

• The editor will highlight keywords, which will be selected according to the type of the file being edited.

18

Examples of Requirements

Instead of:• Only personnel can view an employee record

– “requirement” contains an embedded policy– Policies change regularly & should not be hardwired into

requirements– Separate the policy from the requirement

Rather change to:• “Only authorized users may access an employee

record”– Implement access control system where authorized users or

groups can be selected and / or changed

19

Examples of Requirements

• We need a list box to select the loan term– Is it absolutely necessary to use a list box, or– Is a list box used as an example– Discover why they do it rather than it just being

the way that they do it

20

Helpful practices for requirement elicitation

• Become a user – Observe– Build trust– Encourage communication

• Document the requirements– Capture all requirements– Construct use cases and use case diagrams

21

22

23

Helpful practices for requirement elicitation

• Don’t overspecify

• Maintain a glossary

• Look to the future

• Manage “feature creep”

• Validate the requirements

24

Helpful practices for requirements change control

• Formal change control board

• Formal change control requests

• Automated change control tools

• JAD (Joint Application Design) sessions

• Requirements inspection for major changes

• Application feature planning

25

Change control considerations

• Evaluate change requirement carefully– Is it merely a nice feature – Does it offer business value

• Ensure everyone knows the cost of changing requirements

• High volume of change request indicates inadequate designs

• Some approaches accommodate changing requirements– Evolutionary-type approaches, e.g. prototypes

26

27

Using CASE Tools

• Choose carefully

• Consider the expense

• Consider the learning curve

28

Changeover to the New System

• Direct changeover– Minimized duplication or work– Thorough planning is required– There are no comparable results

• Parallel Running– Risk is reduced– Results can be compared– Workload is increased

29

Changeover to the New System

• Pilot Running

• Phased Implementation– The System can be released sooner– Client feedback can be obtained– Reduces pressure on the developer– Eases the burden of training-

30

Review and Maintenance

• How satisfied are the clients, with the hardware and software supplied?

• Were the clients happy with their degree of involvement in the development of the system?

• How are staff of the client organization reacting to the new system?

• To what extent does the system fulfill the original client requirements?

• Etc. …

31

Maintenance and Support Guidelines

• Implement change control procedures

• Test and document all changes

• Provide telephone or on-line maintenance support

• Provide on-site maintenance support

32

Team-Oriented Principles and Practices

• Quality is a team issue• A team should communicate effectively and

as one personality• A team should have an identity• Don’t duplicate work.• Monitor the environment for changes• Organize teams around functionality not job

functions

33

Further Principles and Practices

• Define the problem

• Use the appropriate development process

• User appropriate methods

• Provide project leadership

• Manage the project well

• Etc. …