software development process guidelines for project managers dr. moshe gotesman, pmp

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)


Software engineering Software Engineering deals with

the software product as an engineering effort.

Software engineering has two main components: Techniques Processes


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


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)


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


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


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


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


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


Linear Sequential Model (waterfall)

Iterative development (RUP)Incremental Model

Agile Programming

Many others (not popular)

Software Life Cycle Models


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


Iterative Life Cycle Model

Advantages -- FlexibleDisadvantages -- Complex

Iterative Development - Iterative Development - RUP ModelRUP Model


Core Product

Incremental ModelCombining the elements of linear sequential model with iterative

prototyping


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


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.


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.


Documentation That does not mean

documentation has to be heavy. Even light-weight documentation

can go a long way.


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


Documentation Each document should have

A sponsor One and only one owner Contributors (optional) Reviewers

Mandatory (approvers) Optional


Documentation Sponsor – executive level

responsibility/authority Owner – execution responsibility

and liability Contributors – help the owner by

providing some of the material


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)


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.


Documentation Approvers

Usually the mandatory reviewers. Obtain formal approval in the form

of sign-off Signature on hard copy Email approval Electronic signature


Documentation An approved (signed-off)

document is Frozen !! Committing

Any changes must go through a new update-review-approve cycle


The Software Documentation Chain

A typical documentation set will include: Requirements Specification Functional Specification Architecture/design Detailed design Test Plan Test Specification Test Reports


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?



Who uses the Requirements Specification? Customer Product manager Engineers Testing



The Requirements Specification must be approved by the customer and usually becomes a part of the contract.



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



Do not include items that the (non-technical) customer and/or end-user cannot experience, unless they explicitly require them. Performance Quality/stability Interoperability …



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



Requirements should be short, clear, individual, testable

Use a numbering system! Very easy and very useful


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


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.


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



Common designs: Client-server Distributed computing Peer-to-peer Blackboard Implicit invocation Monolithic system Three-tier model Service-oriented architecture



Reference each entry back to the corresponding entry in the Requirements Specification and/or Functional Specification.


The Detailed Design Document

Full details of each component, module, API, interface, data structure, algorithm

Down to the level of function signature


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


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 …


Test Report Details the results of a testing

activity What was done How did it go What were the results


Software Configuration Management

Software Configuration Management handles the changes of software artifacts over time. Code Documents


Version Numbers We need to track the versions of

Code Documents

software development process guidelines for project managers dr. moshe gotesman, pmp

Documents

software project management

software products

project managersdr

popularcsm cis

predictiveadaptivecsm

techniquesprocessescsm

pmpcsm cis

workcsm cis