class notes5

IS 556 Fall 2003 1

IS 556 Project Management

Week 5 Project Support FunctionsReadings: On Time Within Budget - Chpt 8Software Project Survival Guide chpts: 6,7,8, 9Case: Case: HCL America Presenter Group [Group 3 - Rolling Meadows - Case: HCL America ]

Case: Concorddia Presenter Group [Group 12 - Concordia]

David Lash

http://condor.depaul.edu/~dlash/extra/IS556/GroupDetailInfo.asp?ClassID=7888&GroupID=2699

http://condor.depaul.edu/~dlash/extra/IS556/GroupDetailInfo.asp?ClassID=7888&GroupID=2755

2David LashCS 556 - Winter

Objectives:

4 major Project support functions: (include SSG 6,7,9)

Configuration Control, Change Control SQA, Testing

Some notes on Requirements (SSG chapt 8)


Project Support Functions

Major Project support functions: Configuration control Change Control Software Quality Assurance Testing

Support Group(s) are overhead to development Its size increases with project size

May be 1-2 engineers, a group or whole dept


Software Configuration Control

Configuration => combination of software components that form integrated system

Configuration control => method of managing software components to make product(s).

Supports software development activities Program code changes Requirement changes Design changes Version release changes


Software Configuration ManagementNo standards but IEEE definitions

Change control - the process of controlling software changes. (i.e., approving, evaluating, rejecting).

Version control - process of controlling software versions, (i.e., saving, documenting.)

Software Configuration control - Engineering discipline to provide methods and tools to control product configurations

Biggest Problems Lack of management plan for change control Development team ignorance of plan and

requirements on them


Configuration Control NeedsAs early as 1970s, version and change control

tools available (e.g, make, sccs)Effective change control requires:

Change control authority (need process owner/mgr) Standards, procedures, and guidelines (e.g., all

external software => change control) Need tools and resources:

CASE toolsAutomated configuration control toolsRepository (w/ daily backups, sync between sites)

Could be part of overall project plan (could be part of overall standard process)

PM responsibility to assign config management authority?


Table 1.8 - Software config mgmt plan

Its likely thereis a standard fororganization. If not would need to define.


Figure 8.3: Configuration Control Flow Chart from US DOD-Std-2167A

Change controlBoard review


A Change Request Form …

Many shops automate this process with toolsthat document/track/archive requests. (e.g., webased r-trackers)


Sft S. Guide Ch 6- IssuesChange control separate from configuration

control. On-going assessment of change requests.

Create a Change panel or board Members include representatives from key areas such

as marketing, development, SQA, project management. (might be much smaller for small projects)

Seek to fully understand change requests and decide priority.

Assess changes, lets affected areas review, and lets them now when change approved.


Advantages of Change Control

Changes systematic Customers understand change requests

will be assessed for impact. Decisions have full inputMilestones are firmed upFormal Accountability Revision and version control

Sharing of all documents


Change assessment includes ...

What is benefit of changeHow does change affect

Cost - How difficult is the change to make? Quality - Can it destabilize software Resource Allocation

Can the change be deferred?


Change Assessment Problems

PoliticsUsually not implemented or not done wellWhat products must be included?Commitment


Software Quality Assurance (SQA)

What is SQA? IEEE 1999: The degree to which a system,

component, or process meets specified requirements.

The degree to which a system, component, or process meets customer needs or expectations.


Aspects of Quality

Three aspects of Product quality Objective – measurable characteristics from

requirements Subjective – Compliance with customer

expectations Non-assessable – behavior in unforeseen

situationsTo create quality software quality move

requirements from subjective -> objective list


QA Rules

Poor quality breeds failed systemsSoftware failure can be avoidedIt is cheaper to design product correctly

than to correct it after releaseQA should be an integrated part of

development QA is ongoing from the beginning of

system design


Quality AssurancePart of project plan Old School SQA = TestingNow QA =

Testing, Planning Early detection Quality metrics, Process metrics (e.g., review)

SQA plan must be developed Committed to in writing Begin at requirements definition Separate, trained, SQA group w/ adequate funding


Example SQA Plan (Pg 174)


Software Quality Metrics

Development Quality Metrics = measurable values to help understand quality of product.

How can you measure product quality? Recoverability - MTTRReliability - MTTF - Failure rateUsability - training time required, customer

perceptionPerformance - Speed of executionDefect Reports - Failure to meet requirements

Can be used throughout product lifecycle.


Defects Need to be TrackedBegin tracking defects at the requirements levelSeparate defect reports

Emphasize importance to developers Provides valuable data to management (release

management later)Can ask questions like:

Amount of open defects Number of defects from last release Number of serious defects from last release Defects per release over time Number of defects caused per stage per release


Testing and Tech Reviews or Code Walkthrough

Technical Reviews Schedule them starting early in project Code cannot progress without review

Review points: Preparation: Record prep time.

If not enough preparation, this is logged and meeting is postponed. Need author, moderator, defect recorder. State of review is decided by team:

“re-review”, “Pass with modifications”, “Pass”Follow is required for some states.

Foster correct attitude. Record Review statistics by SQA

Results are publicIncludes: what’s been reviewed, defects, state, etc.


Software TestingOngoing process

Does software satisfy requirements? Are customer’s happy with it? Developer cannot adequately test own code

Different mindset of developer VS test engineer.

Test Types Includes: unit - developer testing of individual modules integration - modules assembled and tested subsystem - testing assembles subsys together regression - rerunning complete set of tests with integrated system to assure things still work. alpha - complete system w/o live data), beta - using live data) and acceptance testing - end user acceptance


Formal Testing Procedure

IEEE Standard 829 includes Test plan - definition of the overall test

approach, resources and schedule Test design specs - identifies specific features

to test Test cases specifications - identifies and

describes the test cases Test procedures - describes how to run tests Logs - test results Test summary - summarizes test results.


More on TestingTraceability

Each feature has a source in requirements Each requirement has a feature implemented

Full coverage – complete testing Have we tested everything that needs testing? Maintain a test coverage report to ensure cover

all requirementsTest plans begin when requirements are

known: When you write requirements have tests in mind

Use of test groups

IS 556 Fall 2003 25

Ch. 8 Requirements Development

Software Project Survival Guide


Requirements Development

What do customers need? Figure out a key set of customers Talk/interview them Formalize their needs and lead them through

processBiggest problem: users don’t always

know what they needSpecify now… save on coding and

correction later


User Spec Prototype

ID End Users

Interview

Build User Prototype(e.g. Storyboard, Wireframe)

Make Extensions

Treat Fully Extended Prototype as Baseline Spec

Remember if build user interface prototype, your supposed to through it away.


Project PlanWork Breakdown StructurePert ChartGannt ChartDealing with Human Resources

Last Week Objectives


Summary

3 major Project support functions: (include SSG 6,7,9)

config control, Change control SQA, Testing

Some notes on Requirements (SSG chapt 8) prototype


Stepwise EstimationPrototyping – Engineering orientationConstructive Cost ModelsEstimate project in 5 levels

1. Level of Personnel2. Level of complexity3. Project size4. Development Environment5. Reliability level

Range of Estimates (normal distribution)Hardware estimates - CPU, Memory, disk, resp

time

Summary

class notes5

Documents

change control sqa

change control authority

quality software quality

change control need

control separate

change control board

change panel

sccs effective change