se 325/425 principles and practices of software engineering autumn 2008

James Nowotarski23 October 2008

SE 325/425Principles and

Practices of Software Engineering

Autumn 2008

2

Topic Duration Guest speaker 45 minutes Assignment 2 recap 15 minutes

*** Break Current events 15 minutes Software development environments 90 minutes

Today’s Agenda

Pothole Tracking and Repair System (PHTRS)

Analysis Modeling ExerciseAssignment 2

4

Use case description – narrative

“If I’m at a remote location, I can use any PC with appropriate browser software to log on to the SafeHome Products Web site . . . “

Use-case: Activate the system

5

Use case description – ordered sequence

1. The homeowner observes . . . 2. The homeowner uses the keypad . . 3. The homeowner selects and keys in

stay or away . . . 4. When activation occurs . . .

Use-case: Activate the system

6

Use case description – additional elements Should be primarily for users’ benefit

(secondarily for developers’) Elements of a use case

Name (Potential process on L1 DFD; should relate to users’ goal)

Description Trigger (external, temporal) Major inputs & outputs (Potential data flows) Major steps (Potential processes on L2 DFD) Pre- and post-conditions (no post-condition for an inquiry)

7

Identify actors

Model their interactions with the system.

Through elicitation fully explore all the ways each actor may interact with the system.

Banking Software Product

Withdraw Money

Customer Teller

Use Case Diagram

8

Use Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

9

Level 0 DFD

L0 DFD (aka “Context” diagram)Shows the context into which the business

process fitsShows the overall process as just one

processShows all “external entities” that contribute

information to or receive information from the system

No data stores (unless external)

Context Diagram Example

11

Level 1 DFD for SafeHome security function

Controlpanel

Interactwithuser

Processpassword

Configuresystem

Activate/deactivate

system

MonitorsensorsSensors Telephone

line

Alarm

Controlpanel

display

User commands & data

Password

Configurerequest

Start /stop

A/dmsg

Valid ID msg

Sensorstatus

Configuration information

Configuration data

Configuration data

Sensorinformation

Configurationdata

Displayinform-ationDisplay

messages& status Alarm

type

Telephone number tones

MonitorsensorsSensor

status

Sensorinformation

Alarmtype

Telephone number tones

Configurationdata

12

Transform mapping

data flow model

"Transform" mapping

ab

c

d e f g h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j

13

Transaction Mapping

a

b

t

g

h

d

e

f

i

k

j

l

m

n

Data flow model

x1

b

a

t

x2 x3 x4

d e f g h x3.1 l m n

i j

k

mapping

program structure

14



Today’s Agenda

15



Today’s Agenda

1616

Software Engineering Body of KnowledgeSoftware requirementsSoftware designSoftware constructionSoftware testingSoftware maintenanceSoftware configuration managementSoftware engineering managementSoftware engineering processSoftware engineering tools and methodsSoftware quality

Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.org

What is SE?

tonight

http://www.swebok.org/

17

Anatomy of the technology in a software development environment

1. Process management2. Information

management (repository)

3. Quality management QFD Statistical process ctl Continuous improvmnt

4. System development Analysis & Design Construction Testing

5. Environment mgmt System mgmt Change &

configuration mgmt Service mgmt

6. Program/project mgmt Plan/Estimate Schedule Track Report

7. Personal productivity8. Teamware9. Training/eLearning

18

Thin spread of application domain knowledge

Fluctuating and conflicting requirements

Communication and coordination breakdowns

Three critical factors in development environments when designing large software systems

Source: Kurtis, B., Krasner, H., & Iscoe, N. (1988, November). A field study of the software design process for large projects. Communications of the ACM, 31(11), 1268-1287.

19

“CIOs are shifting their emphasis from technical knowledge to business knowledge, from specialization to versatility, from IT expertise centralized in the IT organization to IT expertise diffused throughout business areas and regions.”

-- Gartner Group, April 2008

Experience is the best way to acquire application domain expertise

20

Extremely familiar with the application domain

Skilled at communicating their vision to their colleagues

Consumed with the performance of their projects

Three characteristics distinguish exceptional designers

21

An exceptional designer represents a crucial depth and integration of knowledge domains

Knowledge domains involved in systems building

Crucial

22





23





24





Closely related

25

Layered behavioral model

26

The art of coordinating software changes to minimize confusion

SCM activities: Identification Change control Version control Configuration auditing Reporting

Software configuration management (SCM)

27

The SCM Process

identification

change control

version control

configuration auditing

reporting

SCIs

Software Vm.n

28

SRSSRS

SRSSRS

SRSSRSTest

cases

SRSSRS

SRSSRS

SRSSRS

Code

SystemSpec

SRS

Projectplan

SRSSRS

SRSSRS

SRSSRSDesign

Documents

WBS RMMM

Change creates complexity because we have multiple versions of each SCI.

Software configuration items (SCIs)

29

SCIs

SCIs SCIs

SCIs

modified

approved

extracted

SCIs

stored

Project database

Formaltechnicalreviews

Softwareengineering

tasks

SCM controls

Baselined SCI’s

30

IEEE Std. 610.12-1990 defines a baseline as:

A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

Baselines

31

Change requests

Change driversUsersBusiness EnvironmentTechnology

Impact analysisWhere-UsedRequirements traceability

32

“Requirements traceability is the ability to describe and follow the life of a requirement, in both a forward and backward direction, i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases.”Gotel and Finkelstein, 1994.

Requirements traceability

33

Why traceability?

34

Requirements validationValidating that all requirements have been fulfilled. Impact analysisAssessing the impact of a proposed change(Existing or new requirements) Regression testingTest selection following a change.Requirements MonitoringMeasuring system’s ongoing ability to meet systemic requirements.Recording RationalesProviding a history

Why traceability?

35

Req No. Description Traces ToU2 Users shall be able to process retirement claims S10, S11, S12

U3 Users shall be able to process survivor claims S13

S10 The system shall accept retirement data U2

S11 The system shall calculate the amount of retirement U2

S12 The system shall calculate point-to-point travel time U2

S13 The system shall calculate the amount of survivor annuity.

U3

Entities U2 U3 S10 S11 S12 S13U2 X X X

U3 X

S10 X

S11 X

S12 X

S13 X

Traceability matrix

36

An alternate and probably more common representation.

Traceability matrix

http://castalia.cstcis.cti.depaul.edu:8080/Poirot

http://castalia.cstcis.cti.depaul.edu:8080/Poirot

Poirot Web Client

Poirot Engine

ProcessQuery()UpdateTerms()

WorkFlow System

UpdateRoutine()UpdateMR(MRName)

ResourceMgr

RegisterMR()RemoveMR()

MR(ManagedResource)

GetHierarchy()GetModuleTerms()DisplayArtifact()

ConcreteMR(Ex: DOORS)

ConcreteMR(Ex: Rat Rose)

ConcreteMR(Ex: Java Code)

Poirotdata

DOORS Rational Rose Java Code

The idea is that this is the part of Poirot+ that will be change. We want to be able to add managed resources dynamically at runtime, or change their location. We have considered a broker architecture – but that may be a bit of an overkill because we have a specific ‘service’ that will manage each resource. We may need each Concrete MR to have a local and distributed part. Anyway MRs will register themselves with the ResourceMgr so that they become managed resources of the project.

1. Poirot Web Client is the interface for the user to issue trace queries. The user issues a query, the query is sent to Poirot Engine where it is serviced and results are returned to Poirot WebClient.

Currently the webclient talks directly to the Poirot Engine, however maybe it should talk to the WMS instead and have the WMS forward requests. (This is an additional complication though)

2. When a user is evaluating a query, they have the option of asking for more information about the artifact. If this occurs then we need to ask the MR (Managed Resource) to display the artifact. If this function is non-supported by the MR, we need to retrieve the additional data and display it ourselves. This is why we have a link from Client to WMS. The WMS will get the data through the Resource Manager.

COLOR KEY:Green = Activities that occur each time a trace query is issued.

Yellow = Batch activities to maintain term frequencies in Poirot

Blue = Project setup activities.

For Version 1.0 of Poirot+ we will update terms on a batch basis (nightly or upon request). The Workflow Manager will check which of the managed resources have changed. It will then update hierarchical data and term frequency data in Poirot. It will call upon the services of the resource manager to locate MR. The concreteMR class will interface with the API of the 3rd party tool to actually obtain the data.

39

Control the Change1. Need for change is

recognized2. Change request is

submitted as a “request for change” (RFC)

3. Developer evaluates4. Change report is

generated5. Change control

authority makes a decision to either: Proceed Deny request.

6. Request if queued for action. ECO is generated(Engineering Change Order).

7. Individuals assigned to configuration objects.

8. Objects checked out and change made.

9. Change audited.10. Objects checked in.11. Baseline established.

SQA activities performed.

12. Rebuild & distribute.

40

Sam

ple

RFC

form

from

: ht

tp://

ww

w.n

ws.n

oaa.

gov/

oso/

oso1

/oso

11/o

so11

2/dr

g/dr

grc.

htm

41

Basic version control techniques

Maintain ONLY the most recent version and a history of changes. Earlier versions are recreated through

“subtractions” from the recent version Maintain full copies of ALL versions.

More space required

42

Before and after baselining an object may change many times.

These changes can be represented in an evolution graph.

Obj1.0

Obj1.1

Obj1.2

Obj1.3

Obj1.4

Obj2.0

Obj2.1

Obj1.1.1

Obj1.1.2

How does the developer reference all modules, documents, and test cases for version 1.4?How does the marketing department know what customers currently have version 2.1?How can we ensure that changes to 2.1 source code are properly reflected in corresponding documentation?

Version control

43

Check-in/Check-out

Most version control tools in widespread use employ the checkout-edit-checkin model to manage the evolution of version-controlled files in a repository or codebase.

http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html

44

Serial development with exclusive checkouts.

In a strictly sequential development model, when a developer checks-out a file, the file is write-locked:

No one may checkout the file if another developer has it checked-out. Instead, they must wait for the file to be checked-in (which releases or removes the write-lock).

This is considered a pessimistic concurrency scheme which forces all work to take place on a single line of development.


45

Concurrent development using branches

Branching is a common mechanism to support concurrent software development.

Allows development to take place along more than one path for a particular file or directory.

When the revision on the new branch is modified and checked-in, the two lines of development will have different contents and will evolve separately


46

Merging is the means by which one development line synchronizes its contents with another development line.

The contents of the latest version on a child branch are reconciled against the contents of the latest version on the parent branch (preferably using a 2-way or 3-way file differencing or comparison tool).


Synchronizing using merges

47

Read Pressman Chapters 21, 25 Current event reports

For October 30