The Software Engineering Process

Alan Sexton

Based on “UML Distilled”, Fowler & Scott, Addison Wesley 1999

Context

• We know Java

• We have a client who wants a Java program

• Need to make sure the program we write is the program the client wants:– functionality, correctness, usability, efficiency,

on time, on budget, ...

(Simplified) Rational Process

• One of many possible processes– ranging from Jackson Design Methodology to

Extreme Programming

• Possibly the most popular of the modern processes

• Evolved to tight coupling with UML and CASE tools

• Aimed at tackling risk early to minimise costs

4 Phases

• Inception

• Elaboration

• Construction

• Transition

Inception

• Initial high level project description: what is it?

• Business case: is it worth doing?

• Feasibility studies: is it practical?

• Result: Project Description (Project Proposal)– compare to project proposal for MSc Summer

Project

Elaboration

• High level analysis and design• Result: Conceptual Model

– Description of concepts involved and relationships between concepts

– Use Cases: captures the processing required (functional requirement)

– Conceptual Model: captures the software architecture (objects required and relationships between them

Construction

• Centered on Use Cases from Elaboration Phase• Broken into iterations: each contains subphases:

– analysis– design– implementation– testing

• Each iteration produces a fully tested, documented, piece of functionality

Transition

• Beta testing

• Performance tuning

• User documentation

• Training

Elaboration Phase Details

• Precisely what will be built and how to build it

• Get risk factors under control– Requirements Risks– Technological Risks– Skills Risks– Political Risks

Requirements Risks

• Problems with project descriptions:– Ambiguities– Implicit Assumptions– Inconsistencies

• Main tool: Use Cases– typical interactions between agents– understandable by non-programmers– captures requirements

Requirements Risks cntd.• Activity Diagrams

– what activities have to be performed to execute a use case and in what order

• Dynamic Model– Objects that perform the activities and the messages

that they send to each other: Collaboration, Sequence and State Diagrams as required

• Conceptual Class Diagram– relationships between classes of objects in the

dynamic model

Use Case*

Main Success Scenario

1. Reservation Maker asks to make a reservation

2. Reservation Maker selects, in any order, hotel, dates and room type

3. System provides price to Reservation Maker

4. Reservation Maker asks for reservation

5. Reservation Maker provides name and postcode

6. Reservation Maker provides email address

7. System makes reservation and allocates tag to reservation

8. System reveals tag to Reservation Maker

9. System creates tag and sends confirmation by email

Name: Make a reservationInitiator: Reservation MakerGoal: Reserve Rooms at a Hotel

* This use case example was taken from “UML Components”, John Cheesman & John Daniels, Addison Wesley, 2000

Use Case Cntd.

Extensions

3. Room not available

a. System offers alternatives

b. Reservation Maker selects from alternatives

3b. Reservation Maker rejects alternatives

a. Fail

4. Reservation Maker declines offer

a. Fail

6. Customer already on file (based on name and postcode)

a. Resume 7

Conceptual Class Diagram

TimetableScheduledTrain

StationVisit

Station

Reservation

Passenger

0..*

0..*

1

1..*

1..*

1 1

1..*

1..*

1

1

2

Technological Risks

• Are the technologies we intend to use appropriate and sufficient?– Software tools and libraries

• sufficiently bug free and reliable?

• handles all issues required?

– Algorithms meet all necessary situations– Hardware appropriate and sufficient

Technological Risks cntd.

• Main approach: Prototype– Simple, throwaway systems that exercise the

technology– Proves suitability of technology without investing

large amount of resources

Skills Risks

• Do the staff have the necessary skills?– Identify skills needed– Obtain the skills

• Training/Study

• Hiring new staff

• Hiring consultants

– Verify that skills have been mastered• build simple prototypes

Prototypes

• Mostly for technological and skill risks, can be helpful for requirements risks too.– Throwaway: code not used in final project

• Staff learn practical aspects of technology without worry about design quality

– Experience teaches how complex approach is• Necessary to be able to predict development time

required

Political Risks

• Requirements changes

• Budget cuts

• Staff cuts

• Public Relations problems

• Personnel problems

End of Elaboration Phase

• Clear estimates of how long it will take to implement each use case

• All significant risks identified

• Major risks understood well enough– i.e. you already know how you will deal with them.

Construction Phase

• Starts with Planning

• Proceeds in iterations– each iteration is a mini-project– usually implements 1 or more use case– If a use case is to large:

• implement a number of scenarios from the use case

Construction Planning

• Categorize use cases by risk and value to project– High risk means something that is difficult or has large

impact on system design– High value means something without which the system

would be of little use

• Estimate the time each use case will take– Large proportion of time on high risk use cases means

not enough done in Elaboration Phase

Construction Planning cntd.

• Iteration length of 2-4 weeks for Java development (less for inexperienced developers)

• Figure out how many iterations needed

• Assign use cases to iterations– High risk/value cases should go early

• Produce a release plan showing iterations, use cases and date of completion planned for each iteration

Construction Iteration

• Analysis– Micro version of requirements risk analysis applied to

single use case

• Design– Refine conceptual into specification class diagrams

• Coding– Code from specification classes and use case: if

problems in design arise, go back to design and update

Construction Iteration cntd.

• Testing– Collect tests as you go– After each new piece of functionality, rerun old tests

(regression testing)– Test individual pieces of code (unit testing)– Test functionality of the integrated system (end-to-

end testing)– Use cases are primary source of test cases

Construction Iteration cntd.

• Integration– Add new code to full system and test whole system

• Documentation– Rarely necessary to give implementation class diagram

(JavaDoc is better for this level)

– Specification class diagram is appropriate

– Activity diagrams or state diagrams should be added for the more complex algorithms or control structures.

Transition Phase

• Optimisation

• Deployment and Integration with final environment

• Some bug fixing can occur but most should have been completed in Construction

• Some tidying up/minor modifications allowed but no new features should be added

Time• 20%-40% of time in Elaboration Phase

• 10%-35% of time in Transition Phase– Lower end for basic software development project– Higher end for complex distibuted systems with special

hardware/legacy system interconnections, real time constraints etc.

• Contingency Factor:– Add 10%-20% of construction time (depending on risk

assessments) at end of transition phase– Plan to deliver without contingency time– Commit to deliver by end of contingency time