View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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
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)
3David LashCS 556 - Winter
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
4David LashCS 556 - Winter
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
5David LashCS 556 - Winter
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
6David LashCS 556 - Winter
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?
7David LashCS 556 - Winter
Table 1.8 - Software config mgmt plan
Its likely thereis a standard fororganization. If not would need to define.
8David LashCS 556 - Winter
Figure 8.3: Configuration Control Flow Chart from US DOD-Std-2167A
Change controlBoard review
9David LashCS 556 - Winter
A Change Request Form …
Many shops automate this process with toolsthat document/track/archive requests. (e.g., webased r-trackers)
10David LashCS 556 - Winter
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.
11David LashCS 556 - Winter
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
12David LashCS 556 - Winter
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?
13David LashCS 556 - Winter
Change Assessment Problems
PoliticsUsually not implemented or not done wellWhat products must be included?Commitment
14David LashCS 556 - Winter
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.
15David LashCS 556 - Winter
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
16David LashCS 556 - Winter
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
17David LashCS 556 - Winter
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
19David LashCS 556 - Winter
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.
20David LashCS 556 - Winter
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
21David LashCS 556 - Winter
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.
22David LashCS 556 - Winter
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
23David LashCS 556 - Winter
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.
24David LashCS 556 - Winter
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
26David LashCS 556 - Winter
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
27David LashCS 556 - Winter
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.
28David LashCS 556 - Winter
Project PlanWork Breakdown StructurePert ChartGannt ChartDealing with Human Resources
Last Week Objectives
29David LashCS 556 - Winter
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
30David LashCS 556 - Winter
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