cse 7315 - sw project management / module 8 - software development plans part 2 copyright ©...
Post on 19-Jan-2016
222 Views
Preview:
TRANSCRIPT
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 1
CSE7315M08
January 10, 2001
SMU CSE 7315 / NTU SE 584-NPlanning and Managing a
Software Project
Module 08Software Development Plans
Part 2
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 2
CSE7315M08
Objective of This Module
• To discuss some of the specific contents of a software development plan
Note that subsequent modules discuss other material that goes into a software development plan
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 3
CSE7315M08
Outline
• Project Information– Methods and Tools– Facilities and Staffing
• Process Information– Software Development Process– Documentation Plans– Reviews and Audits
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 4
CSE7315M08
January 10, 2001
Selecting Methods and Tools
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 5
CSE7315M08
Reliable,Proven
Tools andMethods
Innovative,Improved
Toolsand Methods
vs
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 6
CSE7315M08
Programmers Usually Want the Latest and Greatest
• They want to keep up to date in a field that changes rapidly
• They want to improve how they do their jobs
• They expect the newest tools and methods to give them higher performance and greater job satisfaction
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 7
CSE7315M08
But Newer Tools and Methods Can Mean Higher
Risk• New tools and methods may not integrate well with other tools and methods used on the project
• Training is necessary• It takes time to learn
a new tool or method• Mistakes are inevitable• Proficiency is not instant
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 8
CSE7315M08
Sometimes Your Customer or Program Manager May
Intervene• They may insist on a new and risky
approach because they heard good things about it
• Or they may resist using more recent but well established techniques because of fear of the unfamiliar
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 9
CSE7315M08
• Give the issues some thought• Do trade studies • Get input from previous users of
the new methods and tools• Consider using newer techniques
on small, prototype efforts before applying to major projects
Your Job is to Deliver the Software On Time and On Budget
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 10
CSE7315M08
Pragmatic Issues• Cost & availability of tools and methods• Long term viability of vendors• Availability of support• What computers the tools run on• Compatibility with other tools & methods• What training is required• How long you will need to maintain the
software you are developing– will the tools still be available?
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 11
CSE7315M08
The Plan Should Document ...
• The tools and methods to be used for each step of the process
• Purpose of each tool and method• Where the tools will be acquired
(especially if they are proprietary)• Brief rationale for each tool and
method– Can refer to trade studies and such
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 12
CSE7315M08
A Typical Tool Chart in a Software Development Plan
Phase Tool Vendor Purpose
Design OOPlus Objectco OO Design
Coding J avaXBugout
Maxisof tWefi xit
ProgrammingDebugging
Testing Testgen Maxisof t Test Gen.
… … … …
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 13
CSE7315M08
January 10, 2001
Facilities and Staffing Plans
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 14
CSE7315M08
You Must Plan Reasonable Staff Acquisition and Use
Patterns
0
20
40
1 2 3 4 5 6
Unrealistic
0
10
20
1 2 3 4 5 6
More Realistic
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 15
CSE7315M08
Your job is to remove obstacles to their effectiveness ...
… not to have them take burdens off of you!
People Cost Money --Make Them Productive!
• Adequate training• Adequate facilities• Avoid excessive interruptions
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 16
CSE7315M08
Make Sure the Facilities Fit the Job to be Done
• Enough computers, copiers, etc.
• Enough work space
• Reliable networks and utilities
• People who work closely together should be located closely together
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 17
CSE7315M08
The Software Development Plan ...
… should describe the facilities needed and planned (at a high level)
… and the overall staffing plans– Numbers– Skills required
… and the plans for managing any risks related to these– Backup staffing plans– Alternate facilities options
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 18
CSE7315M08
January 10, 2001
Process Information
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 19
CSE7315M08
January 10, 2001
The Tailored Software Process
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 20
CSE7315M08
Document the Process
• You should document the process so that everyone has the same roadmap of what to do– A generic model that your
organization can use as a starting point for tailoring
– Your specific, tailored process, so people on the program know what to do
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 21
CSE7315M08
Software Process DefinitionConvert the steps of the software lifecycle model, identified during the environment analysis, into a detailed process
Integration & TestDesign CodingRequirements
Unit TestWrite
Test CodeWrite Code
CodeWalkthrough
Lifecycle (Top
Level of SW
Process)
More Detailed Software Process
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 22
CSE7315M08
The Process Definition Concept
All Possible Software Lifecyclesand Processes
High Level Process(Software Lifecycle)
Specific Software Process
Define/tailor the process
Initial Planning
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 23
CSE7315M08
Process Tailoring
• Start with a standard process or an otherwise-selected process model
• Delete unnecessary artifacts and tasks– e.g., for a prototype that is not deliverable,
delete formal tests or documents
• Change the scope of artifacts and tasks– e.g. incremental development lifecycle
might require delivering the design specs only once
– With a “clean room” process, reduce testing
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 24
CSE7315M08
Risks of Tailoring• Deleting a task and failing to
determine who depends on its outputs• Deleting an artifact and failing to
determine who uses it and why• Deleting something because you don’t
know why it is there– If you don’t know why, you don’t know
what damage you may do by deleting– This is a difference between level 1 and
level 3 maturity
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 25
CSE7315M08
Avoiding Risks in Process Tailoring
• Organizational process documentation should indicate – WHY a task is there and who depends on it– WHY an artifact is there and who needs it– List the risks of deleting or modifying a task
or an artifact– Suggest tailoring approaches for specific
situations• e.g. “If you are doing non-deliverable software,
this formal inspection might be replaced by an informal walkthrough”
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 26
CSE7315M08
Document YourTailoring Decisions
• Why each change was made• Additional risks that must be
monitored as a result of tailoring– Example: we removed the design
review due to short program schedule and good design defect experience on the previous project• we must monitor defects during coding to
validate that this did not cause trouble
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 27
CSE7315M08
Example of Tailoring Documentation
Tailoring ChecklistStep Tailoring Rationale... ... ...Design Review Do Incrementally Iterative ProcessWalkthrough None NA... ... ...Artifact Tailoring Rationale... ... ...Design Spec Do On-Line More Accurate, Lower $Test Report Summary Only Non-deliverable SW... ... ...
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 28
CSE7315M08
January 10, 2001
See Appendix A ...
… for hints and suggestions on documenting a process
Also see SOW for SDP (assignment 5)
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 29
CSE7315M08
January 10, 2001
Documentation Plans
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 30
CSE7315M08
Artifacts vs Documents
• An artifact is anything produced by a process
• A document is a particular kind of artifact, consisting of a permanent, human readable record, generally in paper or word processor form
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 31
CSE7315M08
Sample Non-document Artifacts
• Object code
• Requirements model
• The design of the system
In order to comprehend all that the process does, you need to define it
in terms of artifacts, not just documents
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 32
CSE7315M08
Some Artifacts are Not Suitable for Paper
Documents• Many artifacts change dynamically– Designs– Some plans– Test results– etc.
• Others are not suitable for paper or human-readable form– Object code– CASE tool internal artifacts
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 33
CSE7315M08
Limitations of Paper Documents
• Paper documents represent a “snapshot”, at a point in time
• If the documented item is frequently changing, the paper document is soon out of date and incorrect
• Creation, storage and maintenance of paper documents can be expensive and may not contribute to the project goals
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 34
CSE7315M08
Advantages of Paper Documents
• Permanence may be a benefit– Assures consistency when there are
multiple users– Documents typically outlast the project,
thus providing historical information that might benefit future projects
– (in some cases, it might be seen as archaeological!)
• Documents are human readable– Documentation forces one to clarify intent
in a way that other humans can read it
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 35
CSE7315M08
Documentation for Softwareis like Documentation for
Plans• During development, it is a snapshot of status
• Because requirements and designs are always being revised, specifications must be treated as having very short “half life”
• Many contemporary software development organizations generate specifications and such “on line” and keep it dynamic (no printed versions)
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 36
CSE7315M08
Your Documentation Plan is Part of your SW Development
Plan• It should explain the artifacts to be
produced, their origins, and their uses• And what form they will appear in– Paper documents (in what format?)– Computer files (how they can be read
and edited)
• And how they will be maintained – Who controls changes??
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 37
CSE7315M08
Sample Table of Artifacts
Artif act Producedby
Used by Controlledby
Format
RqmtsSpec
AnalyzeSW Rqmts
DesignSW
SW SystemEngineering
Paper
…
SourceCode
Code SW TestSW
SW CM TextFiles
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 38
CSE7315M08
Documentation is Part of the Configuration
Documentversion 3.5
Softwareversion 3.5
Documentversion 3.4
Softwareversion 3.4
You must keep them synchronized
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 39
CSE7315M08
What Artifacts are Produced by a Project?
• Artifacts that are needed for later project phases need to be updated when new software versions or releases are produced
• See Appendix B for examples of software project artifacts
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 40
CSE7315M08
Planning Reviews and Audits
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 41
CSE7315M08
ReviewsPurpose:– To learn the status of the project
Performed by:– Managers or Peers
Method:– Practitioners report on the status and
plans of their projects, following specified formats and reporting on specific metrics
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 42
CSE7315M08
Reviews (continued)
Typical Duration:– A few hours to several days
Achieves:– Uncovers problems (or, at least, symptoms)
Drawbacks:– Does not always identify solutions– May motivate hiding of problems• Avoid punishing the messenger if you want to
get an accurate message
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 43
CSE7315M08
Advantages of Reviews
• Reviews are relatively inexpensive– Standardize how they are done so
people know exactly what to prepare– Make it easy to prepare for a review
by making normal work products a natural part of the review
• Reviews tend to get everyone back on the same track
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 44
CSE7315M08
Three Categories of Reviews1) Phase or Milestone Reviews (Gates)– Held at major milestones– Ensures that the project is ready to move to
the next phase
2) Status Reviews– Held periodically, frequency driven by risk • Typically 1-week to 4-month intervals
– Ensures that everyone knows current status
3) Peer Reviews and Inspections– Designed to evaluate a specific development
artifact
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 45
CSE7315M08
Phase or Milestone Reviews (Gates)
• Provide a forum to understand– the state of the project and product– at a point where the direction can be
altered or refined
• A quality control checkpoint for the project team and organization
• Typically attended by senior management and external organizations and maybe the customer
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 46
CSE7315M08
Topics Covered in a Phase Review
• Major accomplishments and plans• Actions needed for phase completion• Variances from estimates and plans• Problems that are impacting quality,
cost and the schedule • High-risk areas that need attention• Problems or lessons learned that
could impact later phases
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 47
CSE7315M08
Status Reviews• A team progress review• Provide a forum to identify and raise
issues and problems (technical and schedule) as early as possible
• Focused on near-term issues and actions (perhaps sensitive ones)
• Typically attended mostly by the people working directly on the software project
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 48
CSE7315M08
Topics Covered in aStatus Review
• Accomplishments since previous review• The original plan vs actual performance• The critical path of the project• High-risk areas that need attention • Problems that are impacting quality, cost
and the schedule • Status of action items (open & closed)
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 49
CSE7315M08
Topics Covered in a Status Review - For the Next Period
• The plan– Possibly revised during the review
• New action items– Assignments– Dates due– Who will track to closure
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 50
CSE7315M08
Peer Reviews and Inspections
• Provide a way to evaluate specific artifacts– designs, code, test code, etc.
• Typically attended only by peers of the person whose work is being evaluated
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 51
CSE7315M08
Why Only Peers?
• This approach is designed to foster free and open discussion– The supervisor’s presence tends to
inhibit open discussion, often in ways that are not evident to participants
• Often a facilitator or quality assurance representative will participate– To keep everyone focused and to
record findings and action items
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 52
CSE7315M08
Issues Regarding Peer Reviews & Inspections
• You must foster a culture where people actively participate in the reviews and inspections of others– Include this in how you evaluate them– Include time in the schedule– Don’t count their work done until they
have participated in others’ peer reviews
• There are many methods available– Select methods that fit your team
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 53
CSE7315M08
January 10, 2001
Audits
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 54
CSE7315M08
AuditsPurpose:– To study a project in detail and find
problems that may not be evident
Performed by:– Independent technical experts, often
outsiders
Method:– Experts question practitioners and
examine artifacts of their process to determine what is happening
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 55
CSE7315M08
Audits (continued)Typical Duration:– Several days to several weeks
Achieves:– Uncovers problems not seen by insiders– Informs staff that management cares about
the results
Advantages:– Tends to uncover real problems– Tends to confirm or disprove suspected
problems
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 56
CSE7315M08
You don’ttrust us!
Drawbacks of Audits
• More expensive than reviews• Do not usually identify solutions• May motivate hiding of problems• Can generate hostility and lack of
cooperation or de-motivation• Outsiders often do not
understand subtle issues– even if they do, they are not
always believed
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 57
CSE7315M08
When and How to Plan for Audits
• Use audits at points when verification and validation are important– Such as before shipping a product or
after making substantial progress
• Use audits sparingly, but regularly– An audit should not be viewed as a sign
that you suspect trouble– It should be treated as a normal part of
doing a high quality job• Like a regular medical checkup
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 58
CSE7315M08
Get the Practitioners Involved• Have the practitioners identify the
right times for audits– Use them as a way to validate their
work– Remind them that athletes and artists
rely on coaches and critics
• Have practitioners participate in audits of other projects– Let periodic audits become part of the
culture
• Don’t punish people for problems found during audits
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 59
CSE7315M08
Summary• There are many possible topics to
be covered in a software development Plan
• We have covered some of the more common ones here
• But there may be many others• Base your Plan on what your project
needs
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 60
CSE7315M08
END OFMODULE 08
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 61
CSE7315M08
January 10, 2001
Appendix A
Examples and Considerations for Defining a Process
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 62
CSE7315M08
Examples of Process Definitions
A computer program documents a process for a computer to carry out
» declarations define inputs and outputs
» executable statements define activities and tasks
» ordering of statements, sequence and control statements define the relationships
FUNCTION X(A,B)REAL A; INTEGER BIF A < 2.3 THEN B = B + 1ELSE B = 0ENDIFRETURN
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 63
CSE7315M08
Flow Charts» Boxes define tasks» arcs and diamonds define relationships,
sequencing» circles sometimes show external inputs and
outputs, although flowcharts are deficient in showing internal artifacts
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 64
CSE7315M08
Data Flow Diagrams
DesignWalkthrough
Design
Specification
DesignSoftware
errors
CMLibrary
» Boxes and circles define tasks» arcs and data boxes define artifacts, data flow» ordering defines relationships, dependencies
(Note parallelism)
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 65
CSE7315M08
Considerations forProcess Documentation
• Who will use the process description?– You may need several different
formats for different classes of users
• Highly formal process descriptions (e.g., petri-nets) tend to be poor for practitioners but good for doing analysis of processes
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 66
CSE7315M08
Considerations forProcess Documentation
• Who will use the process description?– You may need several different formats
for different classes of users
This is probably the single most important consideration when deciding
how to document a process.
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 67
CSE7315M08
Considerations (continued)• What supplementary information is
needed? Some common information includes:– A data dictionary to supplement a data
flow diagram– An artifact trace to show the complete
history of each specific artifact– An input/output cross reference to
show where each input comes from and where each output is used
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 68
CSE7315M08
Considerations (continued)• Processes tend to be large and complex–At the detail level, you need to discuss
subsets and views of the process–This is like using “cross sections” of a large,
complex molecule to understand its chemistry–Consider highlighting the parts of the
process that are under discussion–Or consider using different colors for parts of
the process that different groups are responsible for
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 69
CSE7315M08
Considerations (continued)
• Give examples of process documentation in proposals, plans, etc.• Processes focus on WHAT, not
HOW–You may need to supplement with
“how to” details for practitioners
CSE 7315 - SW Project Management / Module 8 - Software Development Plans Part 2Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved
Slide 70
CSE7315M08
January 10, 2001
Appendix B
Artifacts Typically Generated during Software Development
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 71
CSE7315M08
We will Examine the Process in terms of Artifacts
We will describe some of the most commonly used artifacts, may of which are generally produced as paper or electronic documents
These will be sort of generic -- inspired by the DOD standards and the IEEE standards
Student exercise - consider which artifacts are best represented as paper documents and which are better represented in non-paper
form.
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 72
CSE7315M08
Artifacts Commonly Used during Software DevelopmentPossible Inputs to Software Development
-- Statement of Work - what work is supposed to be done and what deliverables are expected - the requirements for the project and the process
-- System Requirements - what is the system supposed to do (functions, performance, standards met, etc.) - the requirements for the product
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 73
CSE7315M08
Artifacts Commonly Used during Software
Development (continued)Possible Inputs to Software Development -- System Design Specification - what are
the parts of the system, how do they interact, and what requirements are
allocated to each-- System Test Requirements - how the
system will test or verify that it meets its requirements
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 74
CSE7315M08
Notes
1) Often in a complex system, you have separate design specifications for different parts
2) In that case, you need some document that ties it all together (in DoD contracts, this is called the “system/segment design document” or SSDD)
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 75
CSE7315M08
Notes (continued)
3) This “tie it together” document is redundant but important -- sort of like the WBS is redundant but important for understanding all of the work to be done
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 76
CSE7315M08
Artifacts (continued)Artifacts Produced by Software Requirements
Analysis -- SW Requirements Specification - what the
software is supposed to do -- Interface Requirements - how the
software is supposed to interface with everything else– Hardware– Users– Operators– Other Software
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 77
CSE7315M08
Artifacts (continued)Artifacts Produced by Software
Requirements Analysis -- Software Test Requirements -- Algorithm Descriptions (for
embedded and scientific applications)
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 78
CSE7315M08
Artifacts (continued)
Artifacts Produced by Software Design -- Software Design Description– Usually a separate one for each product
or major part of the software
-- Interface Design Description– How the parts fit together and interface
with each other– How the software interfaces with the
outside world
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 79
CSE7315M08
Artifacts (continued)
Artifacts Produced by Software Design
-- Software Test Plan– Test cases and methods to be used
-- Software Development Files– Informal notes by designers on
alternatives tried, rationale for specific decisions, etc.
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 80
CSE7315M08
Artifacts (continued)Artifacts Produced by Implementation
-- Software– Source Code, Source Listings, Object Code,
etc.
-- Test Procedures and Code– Source and object code of Tests and Test
Data– Procedures for carrying out the Tests
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 81
CSE7315M08
Artifacts (continued)Artifacts Produced by Implementation -- Test Reports– Results of tests, showing what actually
happened
-- End User Documentation– User’s guides, operator’s guides, etc.Consider doing early and making these
part of the requirements specification
January 10, 2001
CSE 7315 - SW Project Management / Module 8 - Software Development Plans
Part 2Copyright © 1995-2001, Dennis J. Frailey,
All Rights Reserved
Slide # 82
CSE7315M08
Artifacts (continued)
Artifacts Produced by Software Integration
-- More Test Procedures and Code -- More Test Reports -- Installation Guides -- Maintenance Documentation -- Support Documentation -- etc.
top related