1

Analysis IAnalysis I

2

Analysis

Identify the parts

People

Methods

Points of View

Validation

Verification

Tools

do

use

use use

Carry out

Carry out

dependson

3

Verification vs Validation

Verification

Are we building the thing right?

(compared to other products)

among models

Validation

Are we building the right thing?

(regarding stakeholders/users desire)

Between the UofD and a Model

4

Analysis

• Identify the parts– How is it organized?– How is it stored?– traceability

• Verification– formal – reuse domains– inspections

5

Analysis

• Validation– Close to the users/stakeholders– informal– prototyping (mock up, storyboard)

6

problems?problems

model

communication

Facts gatheringcommunication

model

Analysis LoopUofD

*

**

* modeling** identifying the parts

yes

No

7

Identification of the parts

• Depends on how the models are organized and stored

• Linked to modelling and elicitation

• 90% of the problems is in 10% do system

8

Validation

• Are we building the right product?

• We have to compare the UofD with users/stakeholders expectations

• Run Scenarios (Reading them in meetings)

• Prototype

9

Validation Strategies

• Informal corroboration

• storyboards

• prototypes

10

Validating through scenarios use• As many times as possible

• The earliest the better– If possible validate the candidate scenarios list

• Scenario Validation goal: elaborate the DEO list( Discrepancies, Errors and Omissions)

• Users’ commitment is essential

11

Title

Goal

Actors

Resources

Episodes

12

Validation Through Scenarios

– Gradual confirmation of scenarios parts (objective, actors, resources)

– Feedback for LEL

– Tag scenarios where doubts arise

– Make notes of discrepancies, errors or omissions

13

Main stream

• Validate scenarios with users using semi-structured interviews

• Strategies:– Read scenarios aloud together with users

– Ask if they have anything to add or change

– Ask Why

14

Storyboard [Leffingwell & Widrig]

• Elicit reaction such as “Yes, but…”

• Passive, Active or iterative

• Identify actors, explain what happens to them and describe how it happens

• More effective to projects with innovative or unknown content

15

Storyboard

• Pros:– cheap– User friendly, informal and iterative– Allow to criticize system interface early in the

project– Easy to create and modify

16

Types of storyboard• Passive

– Static screens– Business rules– Reports

• Active– Presentation (As in PowerPoint)– animation– simulation

• Iterative– demo ( free browsing)– Iterative presentation

17

Storyboard

screen

Business Rules

reports

presentation

animation

simulation

demo

Iterative Presentation

passive active iterative

prototype

Complexity and cost

18

Prototype

• Prototypes are partial implementation to help stakeholders, users and developers to better understand system requirements

19

Prototypes

• Also helps to elicit reactions such as “ Yes, but…”

• Help to clarify fuzzy requirements – Requirements that are known but not well defined or

not well understood

• Help elicit reactions such as “Now that I can see it working it comes to me that I also need…..”

• Availability of tools that help to build fast and cheap prototypes

20

Types of Prototypes [Davis]

• Throw away– It has to work – Use any means to implement the desired result (it does not

care for quality code)– Once the requirements are elicited the prototype is deleted

• Evolving– Implemented using the same architecture being used in the

system– The system may be an evolution of this prototype

21

Prototype

Vertical X Horizontal

• Horizontal– Implements a large portion of the functionality

• Vertical– Implement a few functions– Better quality

22

Verification

• Are we building the product correctly ?

• Use of Models– representations/languages

• Use of formalisms

• Informal Techniques

23

Use of formalisms

• Formal Proofing of a model– Theorem proofing

• Detection of discrepancies between the model and the meta models– Model Proofing

24

Techniques

• Inspection A formal evaluation technique in which artifacts are examined in detail by a person or group other than the author to detect errors, violations of development standards, and other problems. Formal, initiated by the project team, planned, author is not the presenter.

• Walkthrough A review process in which a developer leads one or more members of the development team through a segment of an artifact that he or she has written while the other members ask questions and make comments about technique, style, possible error, violation of development standards, and other problems. Semi-formal, initiated by the author, quite frequently poorly planned.

25

Walk through

• ad hoc preparation

• Meeting (author(s), evaluator(s), secretary)

• Reading– author reads– Evaluators hear– Evaluators point out problems (questions)– Secretaries write down problems

• List of problems

26

Inspections• Create in 1972 by Fagan, at IBM, to improve

quality of code• Currently they are used to check any type of

artefact used in the software development process• Inspection can detect between 30% and 90% of

existing errors• Reading techinique applied to an artefact aiming

at detecting errors in the artefact according to a pre-stablished criterea

InspectionsFormal

Initiated by the project team

Planned meeting with fixed roles assigned to all the members involved

Reader reads the product code. Everyone inspects it and comes up with defects.

Recorder/Secretary records the defects

Moderator has a role in making sure that the discussions proceed on the productive lines

27

28

Inspections in requirements– based on check lists:

• Inspectors use a list with the itens to be checked• Each artifact has an specific list (req. Document, Use cases,

Lexicon, Scenario, DfD, Class diagram ...)• Defects are anotated in the artifact being analysed• After reviewing, a meeting is carrried out to communicate the

problems found to developers

– Defects that can be found:• Incorrect sintax in the artifacts(Definition of a term, measrument

units ...)• Incosistent information among artifacts (ex: Use cases and Glossary)• NFRs not explicited• Actors or resources incomplete or in excess• No Pre-conditions (Use Case and Scenarios) • No exceptions in scenarios

29

DFD• Checklist DFD

– The documentation should contain:• Date, numbered pages, list of topics, change and

version control

– Process represented by a numbered circle– Identifier should begin with a verb– Maximum number of processes should be 7 +- 2

30

OO• Checklist OO:

– Are all classes represented using rectangles with 1, 2 or 3 compartments?

– Are there two classes with the same name?

– Are there classes without defined relationships?

– Are the attributes and methods for each class adequate?

– All the Use Cases have corresponding Sequence Diagrams ?

– Coupling and Cohesion are adequate ?

31

• N-Fold Inspection– Many teams– Each one carries out an independent inspection

process– Compare results– Final Report

32

Figura N-fold

User

Moderator

Leaders

Team 1 Team 2 Team 3

Each document is revised by n teams where each team uses the inspection process to find errors

33

Parallel is better• Multiple inspection teams find more defects than

one single bigger team

• The teams tend to find sub sets of different defects

• The combination of the various results from the different teams tends to sum instead of being redundant

• Follow up– Release the document– Owner and moderatorKey lessons in achieving widespread inspection use - Grady & Slack - IEEE

Software, July1994, pp.46-57

34

Challenges from inspections

• Big Requirements Document– Informal and incremental revisions during the

development of specification– Each inspector starts from a different point– Divide into many small teams – each team

inspects a specific part of the document

35

• Large inspection teams– Difficult to schedule meetings– Parallel conversation– Difficult to get an agreement

• What to do?– Be sure the participants are there to inspect and

not to “spy” the specification or to keep a political status

Challenges from inspections

36

• Large inspection teams– Understand which point of view (client, user,

developer) the inspector is using and keep only one to each interested part

– Establish many small teams and carry out the inspection in parallel. Combine the lists and remove redundancies.

Challenges from inspections

37

• Geographical distance between inspectors– videoconference, teleconference, e-mail, web

• Difficult to observe corporal language and expressions,

• Difficult to moderate

– 25% reduction on the effectiveness • [Wiegers98] - The seven deadly sins of software

reviews - Software Development -6(3) pp.44-47

Challenges from inspections