1

Lecture 21

Final Exam Preparation

CS 4310: Software Engineering

2

Final Exam Details

• Final Exam is 15% of your grade for the class• Same format as the Midterm Exam• Short answer, multiple choice• Should take about an hour to complete but you

will have the full 2 hours if you need it.• Comprehensive exam covering the entire course• NO diagramming required

3

Pre-Midterm Review

• Lecture 12 Slides – Midterm Review• Weeks 1-5 in the midterm review

The lecture 12 slide set reviews the course notes for the midterm exam.

4

Week Six

• Risk Management

5

What is Risk Management?

The proactive approach to reacting to project change:

(1)Risk Identification

(2)Communicate Risks

(3)Monitor Risks

(4)Risk Mitigation

(5)Risk Contingency Planning

6

Types of Risks

Page 82 and 83 of the class notes

• Predictable Risks

• Strategic Risks

• Financial Risks

• Project Management Risks

• Technology Risks

7

Managing Risk

Manage projects to avoid risk:

• Open and visible software process

=> Avoid surprises

• Continual review of requirements

• Willingness to modify or cancel projects

8

Risk Mitigation, Monitoring and Management

• Mitigation — how can you avoid the risk?

• Monitoring — what factors can you track that will enable you to determine if the risk is becoming more or less likely?

• Management — what contingency plans do we have if the risk becomes a reality?

9

Risk Management Plan

Pages 84-87 in the class notes.

Read the example in the course notes. This is a good example for what goes into a Risk Management Plan and how one is created.

10

Week Seven

• GUI and Prototype Design

11

Analysis leads to Design

goals of the system scenarios properties of interest

Analysis

Design

identify the main events, actions and interactions

identify and define the main processes

identify and define the properties of interest

structure the processes into a design architecture

check properties of interest

12

Design leads to the Design Document

Design

Design Documen

t

identify the main data design (structures)

identify component-level design

identity software interface design

identity user interface design

13

Design leads to Source Code

Design

Java

identify the main active entities

identify the main (shared) passive entities

structure the classes as a class diagram

14

Software Design Strategies

FUNCTIONAL OBJECT-ORIENTED DECOMPOSITION DESIGN

The solution is expressed

in terms of objects

(self-contained entities

composed of data and

operations on that data) that

interact by sending messages

to one another.

The problem is divided into

more easily handled

subproblems, the solutions

of which together create a

solution to the overall

problem.

15

Object-Oriented Design

A technique for developing a program in which the solution is expressed in terms of objects -- self- contained entities composed of data and operations on that data.

TextField

setText. ..

getText

Private dataand

methods

setLayout

add

pack. ..

show

Frame

Private dataand

methods

TextField Frame

16

What is a Prototype?

• Prototypes should exhibit and make vivid and comprehensible the essential features of the system that is being designed, and of its style of user interface, i.e., its look and feel.

• Prototypes should suggest what the application will do, what its essential characteristics are, what it will look like, and how it is to be used.

17

Prototypes are Used for Envisions

• Prototypes are used to help one visualize things that do not yet exist

• Prototypes are used for– Designing media, systems, and interfaces– Pre-testing media, systems, and interfaces– Presenting interface ideas

18

Envision in Design

• Visualizing concepts• Exploring alternatives• Resolving feature details• Developing interaction scenarios

– Visually showing your USE CASE scenarios

19

Envision in Pre-testing

• Can you read or interpret this?• Can you follow this?• Can you make this work?• Do you understand what is going on?• Is this the way you would do this?• Does this suggest alternate approaches to you?

20

Envision for Presentation and Discussion

• To interface designers, for discussion• To programmers, to guide implementation• To marketing and management, to guide

product design and marketing decisions• To users, to get early feedback

21

Practical prototyping…

• Remain flexible– Remember that your first prototype will not be

your last. If your design is to progress, you must be willing to iterate the idea over and over again.

• Materials/Implementation– Choose materials that are easy to manipulate,

ones you feel comfortable using. – Make something that is pleasant to look at.– Allow for strength, create prototypes that can

handle a lot of use. Reject ideas that are too fragile and complicated, whenever possible simplify.

22

Use Prototyping to Animate Benefits

• Easy to discover problems for end-user– Suggest how the requirements may be improved

• May be used to develop system tests– Used later in the system validation process– Executable prototypes may be used for back-to-

back testing with the final system• May serve as a stop-gap system

– When delaying in implementing final system• Reveals requirements inconsistencies and

incompleteness

23

Test the prototype

• Scenarios and role-playing are no substitute for user testing.

• Test with users with similar backgrounds to your target users.

• Doing the design will give you a large set of expectations about what users will do with the design.

• Testing will reinforce or contradict your expectations. You learn from that process.

24

Benefits of Testing

• Testing will expose problems• You can then attack those problems in order of severity - and

work on features in order of value• Beware of interactions between design elements - fixing one

may break another

Design

Prototype

Evaluate

25

Week Eight

• Software Metrics• Quality Assurance• Configuration Management

26

Software Measurement and Metrics

• Software measurement is concerned with deriving a numeric value for an attribute of a software product or process

• This allows for objective comparisons between techniques and processes

• Although some companies have introduced measurement programs, the systematic use of measurement is still uncommon

• There are few standards in this area

27

What is a Software Metric?

• Quantitative measure of the quality of software.• Measure of the difficulty of testing, understanding, or

maintaining a piece of software• Measure of ease of using software

Software complexity is measure of human performance

Computational complexity is a measure of program performance (Algorithm complexity)

28

Uses of Software Metrics

1. Identify parts of program most likely to be hard to work with (e.g. test, maintain, understand, ...)

2. Aid in allocation of testing and maintenance resources

3. Predictors of size of effort or number of bugs

4. Feedback to programmers

29

Classification of Software Metrics

1. Size Metrics

2. Logical Structure Metrics

3. Data Structure Metrics

4. Interconnection Metrics

5. Object-Oriented Metrics

6. Function Points

30

Size Metrics

The larger the more complex – There are many ways to define size of a program

Lines of Code (LOC)

Standard definition of LOC

– Count number of lines and data definitions– Do not count comment lines– Count a line containing both a statement or part of

a statement and a comment as an executable line.

31

Problems with LOC

• Lack of a Standard definition for line of code.• Counting types of lines.

– Executable lines– Data definition– Comments– Blank line

• Application written in multiple language.• Size variation due to individual programming

style.

32

Size Metrics

Function Count -- Coarse measure of program size.– Function count is the number of functions in the

program.– Attempts to define size in terms of the number of

tasks the program performs.

Problems with function count

What is a function?

Function count depends on how problem broken up

Function count can be padded or made very small

33

Function Points

Weighted sum of following:

1. External inputs - provided by user that describe distinct application-oriented data (e.g. file names)

2. External outputs - items provided to user that generate distinct application-oriented data (e.g. reports)

3. External inquiries - interactive inputs requiring a response

4. External files - machine readable interfaces to other systems

5. Internal files - logical master files in the system

34

Function Point Example

Read the Function Point Example that starts on page 93 of the course notes. You don’t have to read or know how to apply complexity adjustment factors.

You do need to know how to calculate the base function point count that is explained on pages 93-96.

35

Quality Assurance & Management

• Concerned with ensuring that the required level of quality is achieved in a software product

• Involves defining appropriate quality standards and procedures and ensuring that these are followed

36

What is Quality?

• Quality means that a product should meet its specification

• This is a problem for software systems– Tension between customer quality

requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.)

– Some quality requirements are difficult to specify in an unambiguous way

– Software specifications are usually incomplete and often inconsistent

37

Quality Management Activities

• Quality assurance– Establish organizational procedures and

standards for quality• Quality planning

– Select applicable procedures and standards for a particular project and modify these as required

• Quality control– Ensure that procedures and standards are

followed by the software development team

38

• Standards are the key to effective quality management

• They may be international, national, organizational or project standards

• Product standards define characteristics that all components should exhibit e.g. a common programming style

• Process standards define how the software process should be enacted

Quality Assurance and Standards

39

Quality Control

• Checking the software development process to ensure that procedures and standards are being followed

• Two approaches to quality control– Quality reviews– Automated software assessment and

software measurement

40

• A group of people examine part or all of a software system and its associated documentation.

• Code, designs, specifications, test plans, standards, etc. can all be reviewed.

• Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management.

Quality Reviews

41

Source Code Management

• Also known as Configuration Management

• Source Code Managers are tools that:

– Archive your development files– Serve as a single point of entry/exit when

adding or updating development files

42

How Configuration Management Works

• Central database of source code, documentation, build tools

• Each file stored only once - all other versions are temps of that one copy

• To Make a Change– Check out the latest version of a file– Make the changes– Update the database

43

Version Control

• Companies ship several products from the same source base

• When tracking down bugs you want to examine the code as it was when the product shipped

44

Version Trees

• Each file in the database has a version tree• Can branch off the version tree to allow

separate development paths• Typically there is a main path (trunk) for the

next major version and the branches off of it are shipped versions for maintenance

45

Week Nine

• Software Maintenance

46

• Modifying a program after it has been put into use

• Maintenance does not normally involve major changes to the system’s architecture

• Changes are implemented by modifying existing components and adding new components to the system

Software Maintenance

47

Why Maintenance?

• Software maintenance represents 67- 80 % of the total software costs

• Maintenance activities are divided into four classes:• Adaptive – changes in the software

environment• Perfective – new user requirements• Corrective – fixing errors (21% of all changes)• Preventive – prevent problems in the future.

48

Code Decay

• Positive feedback between – the loss of software architecture coherence– the loss of the software knowledge

• less coherent architecture requires more extensive knowledge

• if the knowledge is lost, the changes will lead to a faster deterioration

• Loss of key personnel = loss of knowledge• Challenge: eliminate or slow code decay

49

Servicing

• The program is no longer evolvable– it either decays or managers decide not to

support evolution• Changes are limited to patches and wrappers

– less costly, but they cause further deterioration

• Process is very different from evolution– no need for senior engineers– programmer is assigned only part of the

software to support– the process is stable

50

• Usually greater than development costs (2* to 100* depending on the application)

• Affected by both technical and non-technical factors

• Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult.

• Ageing software can have high support costs (e.g. old languages, compilers etc.)

Maintenance costs

51

Problems of Waterfall

• Requirements volatility• Requirements may change during

development by 30% or more• This is the direct result of the team’s

learning process • Maintenance phase is not uniform

• Frequency of the changes in long lived systems peaks, then declines

52

Extending Waterfall

• If changes can be anticipated at design time– They can be built in by a parameterization,

encapsulations, etc.– Waterfall model still can be used

• However experience confirms:– Many changes cannot be anticipated by the

original designers – Inability to change software quickly and

reliably means that business opportunities are lost

53

Evolutionary Software

Rather than think of separate development and maintenance phases, evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime

54

Spiral Maintenance Model

55

Project Conclusion

• Prototype Deliverable Options• Disk Files (floppy or CDROM)• Email Files (compressed)• Provide URL information• Other? I’m flexible.