Upload
allyson-strickland
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Software Development ProcessGuidelines for Project Managers
Dr. Moshe Gotesman, PMP<>
CSM CIS 680 Software Project Management 2
Organization Software Engineering
Techniques Processes
Software Product Life Cycle Software Development Life Cycle (SDLC)
CSM CIS 680 Software Project Management 3
Software engineering Software Engineering deals with
the software product as an engineering effort.
Software engineering has two main components: Techniques Processes
CSM CIS 680 Software Project Management 4
Software Engineering Techniques
Programming languages Programming paradigm Databases Graphical user interfaces Programming tools Libraries Design languages Patterns Processes and methodologies Platforms Other Practices Other tools
CSM CIS 680 Software Project Management 5
Software Engineering Processes
In order to develop software products as an engineering feat, there must be processes
High level processes define the Software Product Life Cycle (SDLC)
CSM CIS 680 Software Project Management 6
Software Product Life Cycle
There are many different SDLC strategies but they all roughly cover the same basic activities:
Marketing Requirements Document Product development approval Project planning Requirements Analysis Functional Specification Design and Architecture Coding Testing Documentation Training Release/Integration Maintenance
CSM CIS 680 Software Project Management 7
Software Development Process
The software development process cover those parts of the SDLC that actually develop the product.
MRS Product development approval Project planning Requirements Analysis Functional Specification Design and Architecture Coding Testing Documentation Training Release/Integration Maintenance
CSM CIS 680 Software Project Management 8
Software Product Life Cycle
SDLC models defer in how that arrange and combine the various activities.
Most SDLC models fall into the following main types: Predictive Adaptive
CSM CIS 680 Software Project Management 9
Predictive Life Cycle Models The waterfall model has well-defined, linear
stages of systems development and support The spiral model shows that software is
developed using an iterative or spiral approach rather than a linear approach
The incremental release model provides for progressive development of operational software
The prototyping model is used for developing prototypes to clarify user requirements
The RAD model is used to produce systems quickly without sacrificing quality
CSM CIS 680 Software Project Management 10
Adaptive Life Cycle Models Extreme Programming (XP): Developers
program in pairs and must write the tests for their own code. XP teams include developers, managers, and users
Scrum: Repetitions of iterative development are referred to as sprints, which normally last thirty days. Teams often meet every day for a short meeting, called a scrum, to decide what to accomplish that day. Works best for object-oriented technology projects and requires strong leadership to coordinate the work
CSM CIS 680 Software Project Management 11
Linear Sequential Model (waterfall)
Iterative development (RUP)Incremental Model
Agile Programming
Many others (not popular)
Software Life Cycle Models
CSM CIS 680 Software Project Management 12
Classic Life Cycle Model
or Waterfall ModelAdvantages -- documentation -- easy to maintainDisadvantages -- rarely followed in real projects -- often difficult for the customer to state all requirements explicitly -- must with patience in customers -- leading to “block states”
Linear Sequential ModelLinear Sequential Model
CSM CIS 680 Software Project Management 13
Iterative Life Cycle Model
Advantages -- FlexibleDisadvantages -- Complex
Iterative Development - Iterative Development - RUP ModelRUP Model
CSM CIS 680 Software Project Management 14
Core Product
Incremental ModelCombining the elements of linear sequential model with iterative
prototyping
CSM CIS 680 Software Project Management 15
Advantages -- delivering an operational product with each increment -- useful when staffing is unavailable for a complement implementation -- with better plans to manage technical tasks
Disadvantages -- build-and-fix danger -- invalid when the project deadline is tight or when the customers cannot accept the phased deliverables
Incremental Model
CSM CIS 680 Software Project Management 16
Activity Specific Processes Each of the activities/phases in
the SDLC model is controlled by its own specific processes.
Project Manager must be knowledgeable and familiar with these practices and processes.
CSM CIS 680 Software Project Management 17
Documentation Regardless of the lifecycle model, it is
important to produce some documentation during the software development period
(note: Agile development models prefer communication over documentation but I disagree. Long term, documentation is unavoidable).
The important issue here is not “do we need documentation?” but “What and how much documentation do we need?”
No documentation is a call for trouble.
CSM CIS 680 Software Project Management 18
Documentation That does not mean
documentation has to be heavy. Even light-weight documentation
can go a long way.
CSM CIS 680 Software Project Management 19
Documentation If you work in an environment which does
not have a “documentation culture”: Insist on establishing the culture Start with something
Incomplete is better than nothing Must be official but does not have to be formal It’s OK to move to the next step before the doc is
perfect. Update regularly (as necessary) Make sure there is a (simple) process to:
Make changes Review and approve Freeze Control Version/Revision
CSM CIS 680 Software Project Management 20
Documentation Each document should have
A sponsor One and only one owner Contributors (optional) Reviewers
Mandatory (approvers) Optional
CSM CIS 680 Software Project Management 21
Documentation Sponsor – executive level
responsibility/authority Owner – execution responsibility
and liability Contributors – help the owner by
providing some of the material
CSM CIS 680 Software Project Management 22
Documentation Mandatory reviewers
Must review the document Document cannot be approved without Are given a due date for completing the
review Not responding by the due date implies
no comments (= agree with all the content)
Let then know about these rules (process)
CSM CIS 680 Software Project Management 23
Documentation Optional reviewers
Are not a condition for signing-off Are “nice to have” Document owners is not required to
accept their comments Have the same due date as the
mandatory reviewers but it’s only suggested.
CSM CIS 680 Software Project Management 24
Documentation Approvers
Usually the mandatory reviewers. Obtain formal approval in the form
of sign-off Signature on hard copy Email approval Electronic signature
CSM CIS 680 Software Project Management 25
Documentation An approved (signed-off)
document is Frozen !! Committing
Any changes must go through a new update-review-approve cycle
CSM CIS 680 Software Project Management 26
The Software Documentation Chain
A typical documentation set will include: Requirements Specification Functional Specification Architecture/design Detailed design Test Plan Test Specification Test Reports
CSM CIS 680 Software Project Management 27
The Requirements Specification
The Requirements Specification is the most important document in the software development documentation.
If nothing else, insist on a Requirements Specification.
The Requirements Specification is the beginning of everything.
Who uses the Requirements Specification?
CSM CIS 680 Software Project Management 28
The Requirements Specification
Who uses the Requirements Specification? Customer Product manager Engineers Testing
CSM CIS 680 Software Project Management 29
The Requirements Specification
The Requirements Specification must be approved by the customer and usually becomes a part of the contract.
CSM CIS 680 Software Project Management 30
The Requirements Specification
The Requirements Specification describes the “feature set” of the product
From the (non-technical) customer and end-user perspective
If the (non-technical) customer and/or end-user can experience it, it has to be in the Requirements Specification
CSM CIS 680 Software Project Management 31
The Requirements Specification
Do not include items that the (non-technical) customer and/or end-user cannot experience, unless they explicitly require them. Performance Quality/stability Interoperability …
CSM CIS 680 Software Project Management 32
The Requirements Specification
Don’t confuse with design! Say what it does, not how it does it No tech lingo and details (unless
explicitly required by the customer) File system DB Programming language Communications protocols
CSM CIS 680 Software Project Management 33
The Requirements Specification
Requirements should be short, clear, individual, testable
Use a numbering system! Very easy and very useful
CSM CIS 680 Software Project Management 34
The Functional Specification
If you don’t have a Requirements Specification, how will you be able to have a Functional Specification?
The Functional Specification Describes how each Requirement should
be implemented. Is a high level guideline to the SW
architects/implementers on how to write the code
Yes, it’s technical Internal document. Not to share with
customer
CSM CIS 680 Software Project Management 35
The Functional Specification
Use a numbering system Reference each entry back to the
corresponding entry in the Requirements Specification
A single requirement can generate multiple entries in the Functional Specification.
CSM CIS 680 Software Project Management 36
The Architecture/Design Document
If you don’t have a Functional Specification, how will you be able to have a Architecture/Design?
The Architecture/Design Describes the high level items of the SW:
Main components/modules Interfaces Communications protocols
Internal document. Not to share with customer
CSM CIS 680 Software Project Management 37
The Architecture/Design Document
Common designs: Client-server Distributed computing Peer-to-peer Blackboard Implicit invocation Monolithic system Three-tier model Service-oriented architecture
CSM CIS 680 Software Project Management 38
The Architecture/Design Document
Reference each entry back to the corresponding entry in the Requirements Specification and/or Functional Specification.
CSM CIS 680 Software Project Management 39
The Detailed Design Document
Full details of each component, module, API, interface, data structure, algorithm
Down to the level of function signature
CSM CIS 680 Software Project Management 40
Test Plan Describes everything about the testing
except the individual tests themselves. Testing procedure Requirements traceability Tested items Testing schedule Test recording procedure HW/SW requirements Test types (unit, integration, release, etc.) Release criteria
CSM CIS 680 Software Project Management 41
Test Specification The recipe book of all the tests Step-by-step instructions for each
test Test # %%%
Start by doing this Then do this Then do this …
CSM CIS 680 Software Project Management 42
Test Report Details the results of a testing
activity What was done How did it go What were the results
CSM CIS 680 Software Project Management 43
Software Configuration Management
Software Configuration Management handles the changes of software artifacts over time. Code Documents
CSM CIS 680 Software Project Management 44
Version Numbers We need to track the versions of
Code Documents
CSM CIS 680 Software Project Management 45