Hierarchical Project Organization

February 20, 2014 CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

1

Hierarchical Project Organization

Chief Executive

First Level Manager(“Front-Line Manager”)

Project MembersA B

A wants to talk to B: complicated information flow

A wants to make sure B does a certain change: complicated control flow


2

Example: Chief Programmer Team

Chief Programmer

AssistantChief Programmer

Senior Programmer Librarian Administration Tester

Junior Programmer


3

Another Project Organization: Egoless Programming Team

Analyst

Designer Librarian

Tester Programmer


4

Another Variant:Project-Based Project Organization

Project Leader

Coaches

Team MembersA B

A wants to talk to B: simple information flowA wants to make sure B does a certain change: simple control flow

Subsystem Teams


5

Observations on Management StructuresHierarchical structures: • “Reports”, “Decides” and “Communicates-With” all

mapped on the same association• Do not work well with iterative and incremental

software development process• Manager is not necessarily always rightProject-based structures:• “Reports”, “Decides” and “Communicates-With” are

different associations• Cut-down on bureaucracy reduces development time• Decisions are expected to be made at each level• Hard to manage


6

Hierarchical Structure• High degree of certainty, stability, uniformity and

repetition• Requires little communication• Role definitions are clear

When should we use a hierarchical structure?• The more people on the project, the more need for a

formal structure• Customer might insist that the test team be

independent from the design team • Project manager might insist on a previously

successful structure


7

Project-Based Structure

• Project with degree of uncertainty• Open communication needed among members• Roles are defined on project basis

When should we use a project-based structure?• If requirements change during development• If new technology develops during project


8

Team Formation

Team Formation is done after the top level design of the project is complete.Heuristics: • one team for each subsystem,• one cross-functional task per team,• 5-7 members per teamBe prepared to iterate the team formation after system design and subsystem decomposition.


9

How do you become a good project planner?

• Establish a project plan•Start with the plan based on your experience with

the last project(s)• Keep track of activities and their duration• Determine difference between planned and actual

performance• Make sure to do a post-mortem

•Lessons learned•Ask developers for feedback•Write a document about what could have been

improved


10

Communication

In large system development efforts, you will spend more time communicating than coding.

A software engineer needs to learn the so-called soft skills:

• technical writing, • reading documentation, • communication, • collaboration, • management, • presentations.


11

Software Lifecycle Activities

SubSystems Implementatio

n Domain Objects

Structured ByImplemented

ByRealized By

Verified By

SystemDesign

Implemen-tation TestingObject

Design

Expressed in Terms Of

ApplicationDomain Objects

Test Cases

? class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

class...class...class...

SourceCode


12

Requirements Elicitation Activities

• Identify actors• Identify scenarios• Identify use cases• Identify relationships among use cases• Refine use cases• Identify nonfunctional requirements• Identify participating objects


13

System Identification

Definition of the system boundary: •What is inside, what is outside?

Requirements Process: •Requirements Elicitation: Definition of the system

in terms understood by the customer

•Analysis: Technical specification of the system in terms understood by the developer.


14

Requirements ElicitationChallenging activityRequires collaboration of people with different backgrounds:

•Users with application domain knowledge•Developers with implementation domain

knowledgeBridging the gap between user and developer:

•Scenarios: Example of the use of the system in terms of a series of interactions between the user and the system

•Use cases: Abstraction that describes a class of scenarios


15

Types of Requirements

Functional requirements: •Describe the interactions between the system and

its environment independent from implementation•Example: The watch system must display the time

based on its location.


16


Nonfunctional requirements: User-visible aspects of the system not directly related to functional behavior. Examples:

•The response time must be less than 1 second.•The accuracy must be within a second.•The watch must be available 24 hours a day

except from 2:00am-2:01am


17


Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate

Examples:• The implementation language must be COBOL. • Must interface to the dispatcher system written in 1956.


18

What is usually not in the Requirements?•System structure, implementation technology•Development methodology•Development environment•Implementation language•Reusability

It is desirable that none of these above are constrained by the client. Fight for it!However, in this course, you will implement your project in C++.Resistance is futile.


19

Requirements Validation

Critical step in the development process. •Usually after requirements engineering

(= requirements elicitation + analysis)•Also at delivery


20

Requirements ValidationRequirements validation criteria:

•Correctness: The requirements represent the client’s view.

•Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system

•Consistency: There are no functional or nonfunctional requirements that contradict each other

•Clarity: There are no ambiguities in the requirements.


21

Requirements Validation

Realism: Requirements can be implemented and deliveredTraceability: Each system function can be traced to a corresponding set of functional requirements


22

Types of Requirements ElicitationGreenfield Engineering:

•Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client

•Triggered by user needsRe-engineering:

•Re-design and/or re-implementation of an existing system using newer technology

•Triggered by technology enablerInterface Engineering:

•Provides the services of an existing system in a new environment

•Triggered by technology enabler or new market needs


23

Software Lifecycle Activities

SubSystems Implementatio

n Domain Objects

Structured ByImplemented

ByRealized By

Verified By

SystemDesign

Implemen-tation TestingObject

Design

Expressed in Terms Of

ApplicationDomain Objects

Test Cases

? class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

class...class...class...

SourceCode


24

Analysis: Object Modeling• From use cases to objects• Object modeling• Class vs instance diagrams• Attributes• Operations and methods• Links and associations• Examples of associations• Two special associations

Aggregation Inheritance


25

From Use Cases to ObjectsLevel 1 Use Case

Level 2 Use Cases

Level 3 Use Cases

Operations

ParticipatingObjects

Level 1

Level 2 Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

BA


26

Definition: Object Modeling

Main goal: Find the important abstractionsWhat happens if we find the wrong abstractions?

•Iterate and correct the model

Steps during object modeling:•1. Class identification (based on the fundamental

assumption that we can find abstractions)•2. Find the attributes•3. Find the methods•4. Find the associations between classes

(Order of steps is secondary, only a heuristic)


27

Do UML associations have direction?An association between two classes is by default a bi-directional mapping.

A B

•Class A can access class B and class B can access class A

•Both classes play the agent role.


28

Do UML associations have direction?

If you want to to make A a client, and B a server, you can make the association unidirectional. The arrowhead points to the server role:

• Class A ( the “client”) accesses class B (“the server”).

• B is also called navigable

A Baccess


29

Aggregation• Models "part of" hierarchy• Useful for modeling the breakdown of a product into

its component parts (sometimes called bill of materials (BOM) by manufacturers)• UML notation: Like an association but with a small diamond indicating the assembly end of the relationship.


30

weight

Automobile

serial numberyearmanufacturermodelcolor

drivepurchase

Aggregation

Engine

horsepowervolume

onoff

3,4

Wheel

diameternumber of bolts

2

Brakelight

onoff

Battery

ampsvolts

chargedischarge

2,4

Door

openclose


31

Inheritance• Models "kind of" hierarchy• Powerful notation for sharing similarities among classes while preserving their differences• UML Notation: An arrow with a triangle

Cell

BloodCell MuscleCell NerveCell

Red White Smooth Striate Cortical Pyramidal


32

Aggregation vs. Inheritance

Both associations describe trees (hierarchies).•Aggregation tree describes “part-of” relationships

(also called and-relationship)•Inheritance tree describes "kind-of" relationships

(also called or-relationship)

Aggregation relates instances (involves two or more different objects)

Inheritance relates classes (a way to structure the description of a single object)


33

Other Associations“Uses”:

•A subsystem uses another subsystem (System Design)“Contains”:

•Sometimes called “spatial aggregation”•... contains ...•Example: A UML package contains another UML package

Parent/child relationship: •... is father of ...•... is mother of ...

Seniority: •... is older than ...•... is more experienced than ...


34

Object Types

Entity Objects:•Represent the persistent information tracked by

the system (Application domain objects, “Business objects”)

Boundary Objects:•Represent the interaction between the user and

the system

Control Objects: •Represent the control tasks performed by the

system


35

Example: 2BWatch Objects• UML provides several mechanisms to extend the language• UML provides the stereotype mechanism to present

new modeling elements

<<entity>>Year

<<entity>>Month

<<entity>>Day

<<control>>ChangeDateControl

<<boundary>>LCDDisplayBoundary

<<boundary>>ButtonBoundary


36

Roles

• A role name is the name that uniquely identifies one end of an association.• A role name is written next to the association line near the class that plays the role.


37

Roles

When do you use role names?•Necessary for associations between two objects of

the same class•Also useful to distinguish between two

associations between the same pair of classes

When do you not use role names?•If there is only a single association between a pair

of distinct classes, the names of the classes serve as good role names


38

Example of Role

inspector repairperson

Creates WorkordersPerson Person

Problem Statement: A person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person.


39

Roles in Associations

Client Role: •An object that can operate upon other objects but

that is never operated upon by other objects.Server Role:

•An object that never operates upon other objects. It is only operated upon by other objects.

Agent Role: •An object that can both operate upon other objects

and be operated upon by other objects. An agent is

usually created to do some work on behalf of an actor or another agent.


40

QualificationThe qualifier improves the information about the multiplicity of the association between the classes. It is used for reducing 1-to-many multiplicity to 1-1 multiplicity.Example: Without qualification, a directory has many files. A file belongs to only one directory.

With qualification: A directory has many files, each with a unique name.

Directory File

DirectoryFile

filename1 *

filename 0..11

Documents

Hierarchical Project Organization