The Software Process. Software Process Activities. Functional Specification

The Software Process

• Step and procedures executed by a software

organization during the development of

software

• Not a linear sequence of steps

• Many activities occur simultaneously or in

random order

• Organizations often continually improve

and change their software processes

Software Process Activities

• Requirements Analysis and Definition

• System Design

• Prototyping

• Implementation and Coding

• Unit Testing

• Integration Testing

• System Testing (Alpha)

• Acceptance Testing (Beta)

• Help and Manual Generation

• Release

• Maintenance

Functional Specification

• Formal document generated after a requirements

analysis.

• Contains a detailed list of the functionality required for

the system being built.

• Is a contract between the client and developers which

states what functionality the end system will have.

• Only technical with respect to domain knowledge

Sample Requirements

• Delivery Schedule

• Performance

• Deployment

•

Configurability/Adapt-ability

• Portability

• Reliability

• Usability (User

Interface Features)

– User Interface

Standards

• System Functions

• Maintainability

– Coding Standards

Functional Specification

• There should be no coupling between the

functional specification and the design

specification.

– The functional spec should be concerned with

describing the functionality.

– Functional specification should decouple details

of how the system is to be implemented.

– In the functional specification phase the

customer should not think in “design” terms.

Design Specification

• Formal document which describes how the

features described in the functional specification

document are to be implemented.

• Design Phases

– High level architectural design

– Detailed Design (Decomposition)

• object or module based

– Interleaved Design testing

Computer Aided Software

Engineering (CASE) Tools

• (File) Version Management Tools

– Aka Source Code Control

– Supports multiple developers working on same code

base

– Supports ability to track a module through it’s

development

– Supports software releases by tagging file versions

– Most tools store differences between file versions.

– Web interfaces

Version Management Tools

• Rational ClearCase

• PVCS Version Manager

• Microsoft Visual SourceSafe

• CVS - Concurrent Versions System

• See this link:

http://www.iac.honeywell.com/Pub/Tech/C

M/CMTools.html

Software Engineering Tools

• Feature Tracking Tools

– Track System Requirements

– Track System Change Requests (Critical

Incidents, aka “bugs”)

– Can associate issue with source files, classes

(integration with version management tools.)

– Responsibility for software requirements can be

assigned to specific team members

Feature Tracking Tools

• Any database

• Intersolv: PVCS Tracker

• Rational: ClearQuest

• Elsinore: Visual Intercept

– Integrates with Microsoft SourceSafe

Specification/Design Tools

• Allow for system modeling and design

• Support diagramming in a standard notation

such as UML

• Support code generation from models

Specification/Design Tools

supporting UML


      !" #%$'&()+*+,-.(+/0 123,45 1& #76* 88)9::<;';';=(?>@+(5 -<1>2<;=-3A+BC:3D FE
GHI JK 3LM N!" #7OA>+1+/1& #76* 88)9::<;';';=-.(2<1;G,2<1=-<ABC:<D FEK JPJ!"

#%Q'R.S1 -38T1(BPU$G&A+V5 >+WNA&X?23UT1+&&(+,5 #76* 88)9::<;';';=-.( Y15+5 1 2<AZ8=-<ABC:<D [H  \PN  N!"

#7] ( 2<Y]+^M] ( 2<YQG_`<] aT #76* 88)9::<;';';=1 238,=-<ABC:<D F!EcbedfE LJgh+<i!"

#7j1 (>+2<8(+&8Ua(8(/Y23,2 #76* 88)9::<;';';=,-<A5 -<ABI)=-<ABG:3D

Specification/Design Tools

supporting UML

F!+Eg!" #7k3,@1O'A >1+/+l+mnP^ :3oN] >,8,A5 #76* 88)9::<;';';=,5?81+//,-<A&)=-<ABG:3D F!dccHpcbeq?rs!"

#tm //1 4&,2el1&,12<Um )+)+O'(2.81&c0123,45 1& #76* 88)9::<;';';=,5?81&2<A+/@=-<ABC:<D [q  ?uv w I!"

#7]+&;x,5

#76* 88)9::<;';';=/A4,-<;GA+&X?2 =-<ABG:3D [yq?
!dCz'{|Ki"

#7n k.mT}~ Osn3(&( >,4B€n /V2 #76* 88)9::<;';';=)/(8,5VB=-<ABG:3D [ygwJM  K 3LM N!"

#l+Y+2<81B‚m&-?*,81 -38Ulm: _n^N(5 > #l+m:3Q'R.S1-<8 m &-?*+,81-.8 #76* 88)9::<;';';=) A) X ,5=-3A+BC:3D

Specification/Design Tools

supporting UML

ƒp . Egc" #7^(8,A5 (+/^A2<1„ZA&…,2?V(/_(23, -#76* 88)9::<;';';=&( 8,A5 (+/=-<ABC:<D ƒpcJ ME gc"

#7jQcW

#76* 88)9::<;';';=&,@+1&8A5=-<ABC:<D †Hq+HE icPN  N!"

#l]+k3] aTM]+5 81&)+&,2<1 #76* 88)9::<;';';=2.1/1?-382.8=-<ABC:<D

†LM ‡<dCˆ G!+ L\.JK ?LM I!" #%aAB„5,8YP… ,23V(+/‰ &(BP1?;GA&X

#76* 88)9::<;';';=2?5,ŠV2<(=-<ABG:3D †.‹ #7]+5 (+R+/1& #76* 88)9::<;';';=2<AZ8/(R+5 (=-<ABC:3D

Specification/Design Tools

supporting UML

Œ

lAZ8;G(&1„Q'5 1Ik<8>= %Ž <‘’“3”•– —<•C˜.™+š+› œ+ž˜ Ÿ .‘‘¡+¢££’’’¤¥.‘’ “3”• ¦3¤§3¨£.©

Œ

l81+&/,5 4NlAZ8;G(+&1P}5 -= ª ˜.«¢¬x?”­® ”3¯3¡ Ÿ .‘‘¡+¢££’’’¤­•.°¤¥‘•?”±²—3® ¤§3¨£.© Œ l+YR (2<1„}5 -= ³..’•3”¥.‘Ž+´µ•<¥²® —<3” Ÿ .‘‘¡+¢££’’’¤¡3.’•?”¥.‘¤§3¨£.© Œ

T1 ¶+( 2x}5 2<8&VBP15?82elAZ8;G(+&1 %š ?¨G¡3<¥•3”

Ÿ .‘‘¡+¢££’’’¤‘²¤§3¨£¥.‘’ “3”•£.©

Œ

… ,23,A5„lAZ8;'(&1xTAA/2x}5 -= ¸·²¥²3—x¹¯3²±º3•3” Ÿ .‘‘¡+¢££’’’¤»?²¥²3—3´¥.‘¤§3¨£.© Œ … ,23,A„aA&)= ¸·²¥²C³3”.•<¥¥²3—3“?± Ÿ .‘‘¡+¢££’’’¤»?²¥²?¤§3¨£.©

Popular Design Tools

• Support UML notation

– Rational Rose

– Microsoft Visual Modeler

– Microsoft Visio

UML Overview

• A standard notation for

– Views

• Diagrams

– Model elements

» General mechanisms

Views

• Used to describe a system

– A single graph can’t describe all the different

aspects.

• Functional

– Structure, interaction between components

• Nonfunctional

– Performance, reliability, deployment

• Organizational

Views

• Use-case view

– System as perceived by the end users

• Logical view

– Structural description

• Component view

– Division of work, dependencies between code modules

• Concurrency view

– For describing synchronization and communication

aspects of a system

• Deployment view

– Describing how a system is deployable

Diagrams

• Use-Case Diagram

• Class Diagram

• Object Diagram

• State Diagram

• Sequence Diagram

• Collaboration Diagram

• Activity Diagram

• Component Diagram

• Deployment Diagram

Other Software Tools

• Automated testing tools

– Segue Quality Works

• Make/Build tools

• Metrics tools

A Basic Software Process

Requirements

Analysis and

Definition

System Design

and Prototyping

Implementation

System

Testing

Software Process Models

• Waterfall Model

• Rapid Prototyping Model

• Spiral Model

• Build and Fix Model

• Incremental Model

Waterfall Model

• Requirements Gathering

• Functional Specification

• Design Specification

• Implementation (coding)

• Unit/Integration Testing

• System and Acceptance Testing

• Delivery and Maintenance

Rapid Prototyping Model

• Develop Prototype

• Functional Specification

• Design Specification

• Implementation (coding)

– Often involves extending the prototype instead of

recoding

• Unit/Integration Testing

• System and Acceptance Testing

• Delivery and Maintenance

Spiral Model

Incremental Model

• Requirements Gathering

• Functional Specification

• Design

• Implementation

• Unit/Integration Testing

• System Acceptance Testing

• Software Release

Software Processes

and your Career

• As good Software Engineers you should

strive to:

– Seek employment at organizations with higher

process maturity

• Gaining experience at such organizations can help

you understand how to build a quality process

– Seek to improve the maturity of the software

process employed by your organization

Software Processes

and your Career

• Organizations with poor Software Processes

will fail to deliver quality software on time.

• Example: Internet Startups

– Just because these companies are working in

“internet time”, doesn’t mean that they can

ignore the rules of software development. If

startups fail to have a mature software process

they will fail.

Capability Maturity Model

(CMM)

• Software Engineering Institute (SEI),

Carnegie-Mellon University

• Method for categorizing the maturity and

quality of a software process used by

software development organizations

Capability Maturity Model

(CMM)

• Level 1: Initial Level

– Ad hoc process

• Level 2: Repeatable Level

– There is an informal process

– Code Versioning

– Feature Tracking

• Level 3: Defined Level

– Process is clearly defined, and documented.

– Efforts made to improve process

– Specification and Design Tools Used

Capability Maturity Model

(CMM)

• Level 4: Managed Level

– Process is clearly defined and documented and

measured.

– Metrics used

• Dr. Henry’s expertise

– Productivity and Quality Goals set, and adhered to.

• Level 5: Optimizing Level

– Process is defined, measured and optimized after each

project iteration

What CMM Levels have

you experienced?