Marketing Ans Sales From POME by Gautam Koppala VT

1
Kanaka maha lakshmi
Be bold when you loose and be calm when you

win.
"Changing the Face" can change nothing.

POME’
POME’07
Thalli
But "Facing the Change" can change everything.
1
2
2
KANAKA MAHA LAKSHMI THALLI
THIS BOOK IS DEDICATED TO THE ALMIGHTY, WHO
ALWAYS SHOWERS HER BLESSINGS ON HER
CHILDREN.
3
2007, POME, Gautam_Koppala, All Rights Reserved
PROJECTS AND OPERATIONS
MANAGEMENT EXPOSED
(POME)
Part “PROJECT MANAGEMENT FOR SOFTWARE INDUSTRY”
A COLLECTION AMELIORATED BY
GAUTAM KOPPALA V.T.
4
5
6
6
You are the only person who can revolutionise your life.
You are the only person who can influence your happiness,
your realisation and your success.
You are the only person who can help yourself.
Your life does not change, when your boss changes,
when your friends change, when your parents change,
when your partner changes, when your company changes.
Your life changes when YOU change,
when you go beyond your limiting beliefs,
when you realize that you are the only one responsible for your life.

Copyright © 2007 POME
All rights reserved. No part of this product may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopy, recording, broadcasting, or by any information storage
or retrieval system, without permission in writing from the author Gautam Koppala.
All knowledge in POME book is service marks and/or trademarks of the author Gautam Koppala.
Except as otherwise specified, names, marks, logos and the like used in the educational/teaching
content of these materials are intended to be, and to the best of Licensor’s [Gautam Koppala’s]
knowledge and belief are, fictitious. None of the names, marks, or logos used herein is intended to
depict any past or present individual or entity, or any trademark, service mark, or other protectable
mark of any individual or entity. Any likeness, similarity or sameness between any name, mark, or
logo used herein by Licensor and the name, mark, or logo of any individual or entity, past or present,
is merely coincidental and unintentional. Any such names, marks, and logos used in the
educational/teaching content of these materials are used only to provide examples for purposes of
teaching the educational content of the materials, and are in no way intended to be used in any
trademark sense or manner.
The names of actual past or present individuals, entities, trademarks, service marks, logos and the like
(other than those of Licensor used in the educational/teaching content of these materials are used only
to provide examples (including in some instances actual case studies based upon factual events or
circumstances involving the individuals, entities, marks, or logos) for purposes of teaching the
educational content of the materials. Any such names, marks, and logos used in the
educational/teaching content of these materials are intended and used solely for the purpose of
providing examples and case studies, and are in no way intended to be used in any trademark sense
or manner.
8
VITA: FROM THE AUTHOR:
Academically, I am a cum laude graduate with a Bachelor of Technology degree in Electrical and
Electronics Engineering (B-Tech E.E.E.) and a post graduate in Masters in Human Resources
Management (M.H.R.M.) and Masters of Foreign Trade (M.F.T.), all from India.
My engineering completed in a remote village in India, Srikakulam, and it’s been a long journey from
there, and journey still continues….I feel this book demonstrates my ability to maintain dedication,
motivation and enthusiasm for a project management over a long period of time. I believe that in
combination with my extensive broad-based operations work experience along with my drive,
9
resourcefulness and determination would make this book, an excellent opportunity for any
juvenile/experienced one in Projects industry.
I started my career as a small time engineer and gradually still developing in the Operations Domain.
With over nine years of Professional Experience, am a well-rounded functional Manager with excellent,
documented record of accomplishment and success in the electronic Security and Building Systems
Technology Field.
The reason behind writing this book, is that when am new to this field, I don’t have any one to say,
what is all about the projects, what to do, and when to do? Hence, the detailed information that I
gained through the ages, thought to put in an orderly fashion, so that it would be vitally milked by
future successful managers, avoiding the time lags.
Highlights of my background include Supply chain, Commercial with a magnificent experience in
Project and Operations management, technically oriented towards Automation and Security Systems in
Industrial and Building sectors.
My success in the past has stemmed from my strong commitment and sense of professionalism. I keep
high standards for my work and am known for my persistent nature and ability to follow through.
If this book facilitates you in getting adjusted and grow in this domain. I would feel really successful.
GAUTAM KOPPALA VT
10
POME Contents
Project Management for Software Industry: ....................................................................... 14
Project Management for the Re engineering Projects (Product development):Error! Bookmark
not defined.
Project Management for Pharma Industry:..................................... Error! Bookmark not defined.
Project Management for the Automotive Industry .......................... Error! Bookmark not defined.
Project Management for Construction Industry .............................. Error! Bookmark not defined.
Project Management for Entertainment Industry: .......................... Error! Bookmark not defined.
Project Management for Event Management Industry: ................... Error! Bookmark not defined.
Project Management Lessons from NASA ....................................... Error! Bookmark not defined.
Case Studies: ................................................................................. Error! Bookmark not defined.
POME Inspired From: ......................................................................................................... 132
11
12
PROJECT
MANAGEMENT
FOR SOFTWARE
INDUSTRY
13
Project Management for Software Industry:
What Project
management in software
domain does?? Is it
predicament task?
Software Project management is largely a project driven exercise. Whether the goal is to design, install
or re-engineer, technology initiatives are often driven by aggressive deadlines and periods of frequent
change. To get the job done, resources must be identified and allocated, and activities must be
properly organized and structured in accordance with business and technical requirements. But,
considering the variety of available technical solutions, applied within a diverse range of business and
professional environments, this is no easy task….
Technology projects come in many different shapes and sizes ….
14
• Feasibility Studies: involving the evaluation of technology and its use in an organization,
which may include the selection of technical solutions and recommendations for future strategies.
• Development Projects: involving the design and development of customized software
applications and related platforms and interfaces.
• Design Projects: involving the design, testing and integration of selected technical platforms
and networked solutions.
• Implementation Projects: involving the implementation of new technical platforms and
solutions, including the physical rollout of hardware and software products.
• Upgrade Projects: involving the upgrade of existing technical platforms and solutions,
including the physical upgrade of hardware and software products.
• Migration Projects: involving the replacement and/or removal of existing technical platforms
and solutions, typically replaced by different products.
• Support Services Projects: involving business initiatives where technology is a participant
and not a mechanism of change, typically including office renovations, relocations, company mergers,
training programs, and internal reorganizations.
• Systems Management Projects: relate to the improvement of systems performance and IT
service delivery, including IT process re-engineering, systems maintenance, security audits and
documentation projects.
But the list does not end here. For when technology is chosen and installed, it must also be maintained
and supported. And the fast pace of technological change mandates an ongoing cycle of systems
enhancement, upgrade and renovation. Individual support requests can easily mushroom into projects.
Systems functionality issues are often mistaken for technical problems, and the truth is only revealed
after structured investigation and analysis. To further complicate matters, a limited tolerance for
downtime can greatly complicate the implementation of platform upgrades and migrations. As such,
the traditional boundaries that exist between projects and ongoing operations tend to blur in the IT
world, creating unique management challenges.
Can POME project management be used to address those challenges? Considering the need for
consistent quality and fast delivery, any practices designed to deliver performance and productivity will
prove worthwhile, provided that the practices are not allowed to overtake the purpose.
As with any other discipline, project management must be put in proper organizational perspective. It
must be more than just theory and idealistic rhetoric.
Software Project Management Plan (SPMP):
POME had used is derived from IEEE Std 1058-1998, IEEE Standard for Software Project Management
Plans.
15
Normally, Software Production has a Poor Track Record
Example: NASA Space Shuttle Software (Year 2002)
ϖ Cost: $10 Billion, millions of dollars more than planned
ϖ Time: 3 years late
ϖ Quality: First launch of Columbia was cancelled because of a synchronization problem with the
Shuttle's 5 onboard computers.
Error was traced back to a change made 2 years earlier when a programmer changed a delay
factor in an interrupt handler from 50 to 80 milliseconds.
o The likelihood of the error was small enough, that the error caused no harm during
thousands of hours of testing.
Substantial errors still exist.
o Astronauts are supplied with a book of known software problems "Program Notes and
Waivers".
Definitions:
Definition of Project/Programs for Software Industry Management:
The definition of a program is simply managing multiple projects.
Classifications of projects are defined in three different categories, as per POME, derived from
the software project firms:
Maintenance is defined as any project that will be under 40 hours to complete.
Category 1 is defined as a project that will take at least 40 to 160 hours to complete.
Category 2 is defined as a project that will be over 160 hours to complete.
Software lifecycle modeling: Attempt to deal with complexity and change
Software lifecycle:
Set of activities and their relationships to each other to support the development of a
software system
Software development methodology:
A collection of techniques for building models - applied across the software lifecycle
Requirements Engineering Process:
16
What does Software Project Comprises of?
All technical and managerial activities required to deliver the deliverables to the client.
A software project has a specific duration, consumes resources and produces work products.
Management categories to complete a software project:
υ Tasks, Activities, Functions
17
Dependencies for Financial Software Installation Project
What does Software Project Management Plan do?
The controlling document for a software project.
Specifies the technical and managerial approaches to develop the software product.
Companion document to requirements analysis document:
υ Changes in either document may imply changes in the other document.
Components of a Software Project:
18
Project
Work Product Schedule Task Participant
A more complex model:
Equipment
Project
* Facility
Resource
Fund
* Organi-
Work zation
Breakdown des-
Structure Work
Schedule cribes Package
con- *
* * sumes *
produces Organizational
Outcome Work respon- Unit
* * sible *
plays
depends for
Role
Set of Work Work
Products Product Activity Task Participant Staff
Internal Project
Project Function Department Team
Work Product Deliverable
To practice effective project management, you must have:
• Defined policies and procedures for project selection, planning and control.
• Strong management commitment and support.
• Trained, committed staff.
• An environment that fosters teamwork and cooperation.
• Strong technical capabilities.
• An understanding of business goals and objectives.
• The right software tools sized to suit Project requirements and technical capabilities.
• The authority to enforce and update project management practices as needed.
As we have discussed, most IT organizations are multi-project environments, facing many different
types of projects, each with its own degree of urgency and business priority. Project management can
add structure and definition to this chaos, but not by accident. When project management is applied,
restrictions and boundaries impact decisions and activities. Speed, creativity and innovation must find
19
a place within an environment of standards, rules, forms and templates. This is no easy task. It goes
against the grain … the ever present need to get things done and then just move on. So, it is all really
worth the effort?
Software Project Organization:
This section specifies the process model for the project and its organizational structure.
a. Process Model
One must specify the life cycle model to be used for this project or refer to an organizational
standard model that will be followed. The process model must include roles, activities, entry criteria
and exit criteria for project initiation, product development, product release, and project termination.
b. Organizational Structure
Describe the internal management structure of the project, as well as how the project relates to the
rest of the organization. It is recommended that charts be used to show the lines of authority.
c. Organizational Interfaces
Describe the administrative and managerial interfaces between the project and the primary entities
with which it interacts. A table may be a useful way to represent this.
Project Interfaces
Organization Liaison Contact Information
Customer: <name> <name> <phone, email, etc.>
Subcontractor: <name>
Software Quality Assurance
Software Configuration Management
<etc>
Software development Project:
20
Organizational Structure Example:
Technical process:
ϖ Methods, Tools and Techniques
Specify the methods, tools and techniques to be used on the project
ϖ Software Documentation
Describe the documentation plan
ϖ Project Support Functions
Plans for (at least) the following project support functions.
υ Plan to ensure quality assurance
υ Configuration management plan (IEEE Std 1042)
υ Verification and validation plan
The plans can be included in this section or there is a reference to a separate document
Free change problem must be dealt with even in an iterative and incremental software lifecycle: time-
boxed prototyping
21
Introducing new bugs: This is a significant problem in old systems that did not use encapsulation:
Global variables, etc
ϖ Software engineering is a problem solving activity
Developing quality software for a complex problem within a limited time while things
are changing
ϖ The system models addresses the technical aspects:
Object model, functional model, dynamic model
ϖ Other models address the management aspects
WBS, Schedule are examples
Task models, Issue models, Cost models
ϖ Introduction of some technical terms
Project, Activity, Function, Task, WBS
22
d. Project Responsibilities
Identify and state the nature of each major project function and activity, and identify the individuals
who are responsible for those functions and activities. Tables of functions and activities may be used
to depict project responsibilities.
Project Responsibilities.
Role Description Person
Project Manager leads project team; <name>
responsible for project
deliverables
Technical Team Leader(s) <define as locally used> <name>
<etc.> <etc.>
Technical Process:
This section specifies the technical methods, tools, and techniques to be used on the project. It also
includes identification of the work products and reviews to be held and the plans for the support group
activities in user documentation, training, software quality assurance, and configuration management.
a. Methods, Tools, and Techniques
Identify the computing system(s), development method(s), standards, policies, procedures, team
structure(s), programming language(s), and other notations, tools, techniques, and methods to be
used to specify, design, build, test, integrate, document, deliver, modify or maintain the project
deliverables
b. Software Documentation
Specify the work products to be built for this project and the types of peer reviews to be held for those
products. It may be useful to include a table that is adapted from the organization’s standard
collection of work products and reviews. Identify any relevant style guide, naming conventions and
documentation formats. In either this documentation plan or the project schedule provide a summary
of the schedule and resource requirements for the documentation effort.
To ensure that the implementation of the software satisfies the requirements, the following
documentation is required as a minimum:
c. Software Requirements Specification (SRS)
The SRS clearly and precisely describes each of the essential requirements (functions, performances,
design constraints, and attributes) of the software and the external interfaces. Each requirement is
23
defined such that its achievement is capable of being objectively verified and validated by a prescribed
method, for example, inspection, analysis, demonstration, or test.
d. Software Design Description (SDD)
The SDD describes the major components of the software design including databases and internal
interfaces.
e. Software Test Plan
The Software Test Plan describes the methods to be used for testing at all levels of development and
integration: requirements as expressed in the SRS, designs as expressed in the SDD, code as
expressed in the implemented product. The test plan also describes the test procedures, test cases,
and test results that are created during testing activities.
f. User Documentation
Describe how the user documentation will be planned and developed. (This may be just a reference to
a plan being built by someone else.) Include work planned for online as well as paper documentation,
online help, network accessible files and support facilities.
g. Project Support Functions
Provide either directly or by reference, plans for the supporting functions for the software project.
These functions may include, but are not limited to, configuration management, software quality
assurance, and verification and validation. Plans for project support functions are developed to a level
of detail consistent with the other sections of the SPMP. In particular, the responsibilities, resource
requirements, schedules and budgets for each supporting function must be specified. The nature and
type of support functions required will vary from project to project, however, the absence of a software
quality assurance, configuration management, or, verification and validation plan must be explicitly
justified in project plans that do not include them.
24
States of a Software Project:
GoAhead ScopeDefined
Conception Start
do/FormulateIdea
do/Cost-BenefitAnalysis do/Infrastructure Setup
Definition do/Skill Identification
do/FeasibilityStudy
do/Review do/Problem Statement do/Team Formation
do/Project Kickoff
do/Software Architecture
do/Software Plan
Termination
do/Client Acceptance New Need Steady State Infrastructure Setup
do/Delivery New Technology Completed
do/Post Mortem do/Develop System && Teams
do/Controlling Assembled
do/Risk Management
System Done do/Replanning
Software Project Agreement comprises of:
ϖ Document written for a client that defines:
the scope, duration, cost and deliverables for the project.
the exact items, quantities, delivery dates, delivery location.
ϖ Client: Individual or organization that specifies the requirements and accepts the project
deliverables.
ϖ Can be a contract, a statement of work, a business plan, or a project charter.
ϖ Deliverables (= Work Products that will be delivered to the client:
Documents
Demonstrations of function
Demonstration of nonfunctional requirements
Demonstrations of subsystems
IEEE Std 1058: Standard for Software Project Management Plans (SPMP):
ϖ What it does:
25
Specifies the format and contents of software project management plans.
It provides a standard set of abstractions for a project manager or a whole organization
to build its set of practices and procedures for developing software project management
plans
Abstractions: Project, Function, Activities, Tasks
ϖ What it does not do:
It does not specify the procedures or techniques to be used in the development of the
plan
It does not provide examples.
Project Agreement, Problem Statement vs SPMP:
Client Manager Project Team
(Sponsor)
Problem
Statement Software Project
Management Plan
Project
Agreement
Software Project Management Plan:
As per IEEE Std 1058, the project management process is of:
Front Matter
26
Introduction
Project Organization
Managerial Process
Technical Process
Work Elements, Schedule, Budget
• Work Breakdown Structure (WBS)
• Dependencies between tasks
• Resource Requirements
• Budget
• Schedule
Optional Inclusions
The project scheduling process for
software industry
Project Notebook:
A Project Notebook is a physical binder with a printout of all key project documents. The purpose of a
physical hardcopy notebook is to communicate clearly and efficiently with customers during face-to-
face meetings and demonstrate strong control of large projects.
Each large project must have a notebook associated with it that contains up-to-date information
regarding the project.
27
The project notebook consists of the following:
1. The notebook should be in a three ring binder
2. The cover of the binder should include:
a. The organisation logo
b. The department name
c. The team name
d. The name of the project
e. The date the notebook was last updated
3. Tabs for the following items:
a. PROJECT STATUS
i. Contains a high level description of the latest status of the project (can be done
in a Power Point presentation)
ii. Action Log. The action log is typically a Word document containing all the
outstanding items in the project. Each items should contain:
1. Date opened
2. Who owns the issue
3. Action item description
4. Due date
5. Status (Open, WIP, Closed)
6. Date closed
b. RAILS
i. RAILS are similar to the Action Log but are more detailed and focus on the more
pressing items
ii. There should be two sheets, one for “Open Issues” and one for “Closed Issues”.
Both sheets will be in the following format:
1. R/Y/G: The first column of the document. “R/Y/G” stands for
“Red/Yellow/Green”. The cell should be colored with the appropriate
color.
2. Red: The resolution to the issue is more than 4 weeks behind schedule
3. Yellow: The resolution to the issue is less than 4 weeks behind schedule
4. Green: The issue is on schedule to be resolved.
28
iii. Action ID: An ID associated with the issue. There is no standard for this, it is up
to the discretion of the user.
iv. Date Opened
v. Issue Description
vi. Impact to the Customer
vii. Customer Point of Contact
viii. Team Point of Contact
ix. Resolution Date
x. Action/Status/Comments: A log of all the actions taken on the issue, the resulting
status and any other comments.
c. When the issue is resolved, move the row to the “Closed Issues” sheet
d. DETAILED SCHEDULE
i. A PMIS( Primavera, MS Project) document with the latest, updated Project
Schedule
e. BUSINESS REQUIREMENTS+
i. The latest Business Requirements document
f. DATA REQUIREMENTS
i. The latest Data Requirements document
g. PROJECT PLAN
i. Standard Project Plan can be used
h. WORK INSTRUCTIONS
i. The latest instructions on how to use the application from a new user’s
perspective.
ii. This may not be applicable to all projects
i. IMPLEMENTATION PLAN
i. Standard Implementation Plan can be used
j. COMMUNICATION PLAN
i. Standard Communication Plan
Any relevant emails should be included as well
29
Software Engineering:
ϖ Analysis: Understand the nature of the problem and break the problem into pieces
ϖ Synthesis: Put the pieces together into a large structure
ϖ For problem solving we use
Techniques(Methods): Formal procedures for producing results using some well-defined
notation
Tools: Instrument or automated systems to accomplish a technique
Methodologies: Collection of techniques applied across software development and
unified by a philosophical approach
ϖ Where does Management come in? When the available resources to solve the problem are
limited (time, people, budget), or if we allow the problem to change.
What is Software Engineering? The goal is to produce high quality software to satisfy a set of
functional and nonfunctional requirements. How do we do that?
First, and foremost, by acknowledging that it is a problem solving activity. That is, it has to rely on
well known techniques that are used all over the world for solving problems. There are two major parts
of any problem solving process:
Analysis: Understand the nature of the problem. This is done by looking at the problem and trying to
see if there are sub aspects that can be solved independently from each other. This means, that we
need to identify the pieces of the puzzle (In object-oriented development, we will call this object
identification).
Synthesis: Once you have identified the pieces, you want to put them back together into a larger
structure, usually by keeping some type of structure within the structure.
Techniques, Methodologies and Tools: To aid you in the analysis and synthesis you are using 3
types of weapons: Techniques are well known procedures that you know will produce a result
(Algorithms, cook book recipes are examples of techniques). Some people use the word “method”
instead of technique, but this word is already reserved in our object-oriented development language,
so we won’t use it here. A collection of techniques is called a methodology. (A cookbook is a
methodology). A Tool is an instrument that helps you to accomplish a method. Examples of tools are:
Pans, pots and stove. Note that these weapons are not enough to make a really good sauce. That is
only possible if you are a good cook. In our case, if you are a good software engineer. Techniques,
methodologies and tools are the domain of discourse for computer scientists as well. What is the
difference?
Evolutionary Development:
30
Software Engineering: Definition:
Software Engineering is a collection of techniques, methodologies and tools that help with the
development of a high quality software system with a given budget, before a given deadline while
change occurs.
Requirements for this SPMP:
Actors: Manager, Developer and Client
ϖ Introduction and Basic Concepts (SPMP, IEEE 1058)
ϖ Work Breakdown structures (Decomposition of work)
ϖ Scheduling (Project duration, critical path analysis)
ϖ Project Organization (Organization forms, team-based projects)
ϖ Software Lifecycle (Lifecycle models, IEEE 1074)
ϖ Rationale Management (Acquiring and externalizing knowledge, dealing with conflicts and
resolutions)
ϖ Configuration Management (Dealing with change, SCMP, IEEE 1042)
ϖ Methodologies
Reuse oriented development
31
Software lifecycle:
Set of activities and their relationships to each other to support the development of a software system
ϖ Typical lifecycle questions:
Which activities should I select for the software project?
What are the dependencies between activities?
Can I break these activities into more manageable parts?
How should I schedule the activities?
How do I assign people to these activities
How do I control the execution of the activities
What do I do if the activities are not proceedings as planned?
Example of Software Lifecycle Activities:
Requirements Implementation System Object Implemen- Testing
Elicitation Domain Design Design tation
Implemented
By
Expressed in Structured By
Terms Of Realized By Verified
By
class..
.
class.. ?
.
class... ?
Use Case Application Solution .
Domain Subsystems Source Test
MoTrans Domain
Objects Code Cases
Objects
32
Simple life cycle for software development:
Software development
«include» «include»
«include»
Problem definition System development System operation
Client Project manager Developer Administrator End user
Roles and Responsibilities
Project Lead
• Obtain Customer Approval for Change Request
• Provide Customer with ongoing project Status reports.
• Log project issues/status and keep customer updated of status.
• Manage Prioritization of Projects between customers
• Manage Resource Requirements
• Working w/Customers on potential future projects (long term plans)
• Provide Customer with Monthly Project Billing Status (hours/cost to date)
• Generate Monthly Metrics (4-ups, On-time Delivery, Estimating Accuracy)
• Coordinating Quarterly Ops Review Documents
• Providing Potential Customers with information related to our services
• Obtain Customer Approval for Work Request
33
• Generate/update High Level Schedule to assist in monitoring Resource Load and estimated Project
Completion dates
• Load Project Schedule into Projects
• Create and maintain Project Workbook in e-Projects (Issue Log, Risk Log, Documentation Folders,
Waivers (if needed), Turnover Log, Peer Review Document, Lessons Learned Document)
• Manage Technical Meetings w/Customer’s Technical Project Team – generate meeting minutes.
• Conduct Peer Reviews (Planning Phase, Requirements Phase, Design Phase, Development Phase,
Testing Phase, Implementation Phase)
• Keep the Projects and the associated documents updated throughout the life of project.
Monitor SEI/CMM/ six sigma/ other processes to ensure team is using properly.
Technical Lead
• Installing/upgrading Software (server level)
• Create Project Specific Configuration Management Document (if needed)
• Requesting Firewall Rule Requests (FWRR)
• Deploying Software to Server from Dimensions (Dev, Assurance & Prod Servers)
• String Testing (Dev, Assurance & Prod Servers – document testing results)
• Volume String Testing (Assurance Server – document testing results)
• Maintaining Architecture Diagram
• Monitoring Servers for space/memory requirements (proactively)
• Keeping Timesheets up to date with weekly effort.
• Updating Projects with project related documents.
• Maintain Standards/Governance/Project Related Libraries
• Manage Re-use of components
• Manage Architecture Review Board
Primary Developer
• Requirements Management
1. Create/Maintain BRD (Business Requirements Document)
2. Create/Maintain Design Doc
34
3. Updating e-Projects Documentation folder with above documents
• Developing Maps (laptop level)
• Developing Collaborations (laptop level)
• Installing Software (laptop level only)
• Configuring Adapters/Connectors (laptop level only)
• Unit Testing/End-to-end testing where possible (laptop level only- document testing results)
• String Testing (Dev server – document testing results)
• Packaging software into zip/jar files and loading them into Dimensions for deployment do
Development Server
• Keeping the Projects updated as developer tasks are started/completed
• Notify Team Lead of any changes requested by customer
Developer
• Developing Maps (laptop level)
• Developing Collaborations (laptop level)
• Installing Software (laptop level only)
• Configuring Adapters/Connectors (laptop level only)
• Unit Testing/End-to-end testing where possible (laptop level only – document testing results)
• Packaging software into zip/jar files and loading them into Dimensions for deployment do
Development Server
• Keeping e-Projects updated as developer tasks are started/completed
• Notify Team Lead of any changes requested by customer
Support Team
• Identifying bottlenecks
• Monitoring of software
• Monitoring of processes
• Monitoring of environment
35
• Long term monitoring of processes
• Generate Support related Metrics (to be defined)
Simple life cycle for software development:
Problem System System
definition development operation
activity activity activity
Another simple life cycle:
System
development
activity
System
upgrade
activity
Market
creation
activity
Testing Project Deliverables: From Concept to Production:
Testing is essential to the success of any technology project. Despite the best technical plans and
designs, problems, errors and bugs do occur. And, in the interests of all concerned, all negative impact
issues should be uncovered before a project deliverable becomes a production environment. A well
planned testing process will serve this purpose.
In the IT environment, the "testing" process fills many needs depending upon the nature of the project
at hand. On a generic level, testing serves several key goals:
• To verify that the project deliverable functions according to design.
• To verify that all identified operational requirements have been met.
• To uncover problems, bugs and errors.
36
But these goals are just the tip of the iceberg. Considering the varied nature of technology projects,
testing can be used in various ways, and at varying points in the overall project process. As such,
testing needs will change according to project timelines and circumstances, depending upon whether
the project involves coding, network design, physical hardware installation, "off-the-shelf" software
installation, and/or documentation development. As such, within any project environment, you may
need to address any or all of the following testing issues:
1. Software code testing.
2. Hardware and/or software installation testing (to validate installation procedures).
3. Hardware and/or software operational testing.
4. Documentation testing.
5. Support procedures testing.
6. Training materials testing.
As you assess and plan your testing process for any given project, three key questions must be
addressed:
• What are your testing goals and objectives?
• What testing methods will be used?
• How will your tests be planned and executed?
What are your testing goals and objectives?
In order to set effective goals and objectives for any testing process, you must have a solid grasp on
project needs and circumstances. Testing must be sized and scaled to meet primary project needs
considering business objectives and technical requirements, as well as available time, resources and
budgets. As such, the following issues and questions should be addressed as testing needs are
analyzed and planned....
Question 1: What are you trying to test?
• Hardware
• "Off-the-shelf" software
• Custom application code
• Workflows
• Documentation
• Installation procedures
Question 2: What are your testing objectives?
• To identify potential problems, bugs, errors and incompatibilities.
• To validate operational functionality.
• To verify design and/or coding quality.
• To validate functional specifications.
• To validate usability.
• To validate "proof of concept" (i.e. via a pilot installation).
37
• To verify performance and capacity.
• To simulate "real-world" operational circumstances or to "quick" test for basic functionality and
operational viability.
Question 3: What are your testing priorities considering the following variables….?
• Intended project purpose. (How will the project deliverable(s) be used within the business?)
Visible and valuable projects demand more detailed testing.
• Features and functionality. (What are the most important features and functions?) When time is
short, testing can be limited to the most important and valuable deliverable elements.
• Technical complexity. (What elements require the most testing due to the degree of technical
complexity?) More complex technical solutions will probably involve more extensive testing.
• The degree of risk involved should problems occurs in the production environment. Testing
should be designed to mitigate and minimize risks.
• Financial costs of testing versus the financial costs of problems. At some point, the cost of
extensive testing may outweigh the costs of production problems.
What testing methods will be used? Once you have identified your testing needs and priorities, you will
need to consider the available testing methodologies. Once again, accepted methodologies will vary
based on available tools and resources, as well as project needs and circumstances.
Entity-centered view of software development:
Software Development
Market survey Lessons learned
document document
System specification Executable system
document
38
Activities and products of the simple life cycle:
Activity Work product
Market survey
consumes document
Problem definition
activity
produces
Specification
document
consumes
System development
activity
produces
Executable system
consumes
System operation
activity
produces Lessons learned
document
Model of the software life cycle:
Software Life Cycle
Money
*
Process Group Time
Participant
*
Process *
Resource
*
Work Unit
consumed by
*
*
Activity Task produces Work Product
39
Process interrelationships in the IEEE 1074 standard:
40
41
V-Model of software development:
42
System
Requirements Operation
Analysis
Software
Requirements Client
Elicitation Acceptance
System
Requirements Integration
Analysis & Test
Component
Preliminary
Design
Detailed Unit
Design Test
Implementation
Time and experience have shown that effective management increases the likelihood for project
success. But what is success? Common sense dictates that projects are successful when they produce
required deliverables on time and within budget. But success is not one-dimensional. Not every project
that is completed on time, and as planned, can be considered an automatic success. Schedules and
budgets might be met, but what if related project deliverables fail to produce true business value.
What if the project team burns out under the weight of unrealistic schedules and never ending political
intrigue? Would these project circumstances still merit the mark of success? To be truly successful, IT
projects should have …
• Realistic, workable plans
• Strong management commitment
• Proper oversight and monitoring
• Effective analysis of risks
• Strong business justifications
• Controlled costs
• Sound technical designs and deployment plans
• Realistic expectations
• Strong teamwork
These are lofty goals. Obviously very few of us approach projects with failure in mind. But success may
not always happen by chance or luck. It is quite possible that projects can be completed successfully
43
just on the basis of individual staff capability or specific project circumstances. But is that a chance
you want (or need) to take?
To deliver successful results on a consistent basis, you need to develop and implement workable,
realistic standards for the management of technology projects. These standards need to be in synch
with organizational requirements, internal capabilities and project characteristics. As such, "one size
will not fit all". However, while unique variations may evolve, all standards should be grounded in
sound principles of project management.
Boehm’s spiral model (Adapted from [Boehm, 1987]):
Determine objectives, Evaluate alternatives,
alternatives, & constraints identify & resolve risks
Risk
analysis
Risk
analysis
Risk
analysis
P1
Prototype3
Prototype2
Prototype1
Requirements Concept of
plan operation Software
System
Requirements Product Detailed
Design Design
Development Requirements
plan validation
P2
Code
Integration Design Unit Test
plan validation Develop & ver ify
Plan next phase next level product
Integration & Test
Acceptance
Test
Workflows in the unified software life cycle used by Royce:
44
Managemen
Unified
Software Life
Environmen
Requirement releases
*
Desig Workflow Cycle
*
Inception
Implementatio 4
Phase Elaboration
Assessmen
* Construction
Deploymen
Artifact * Iteration Transition
The Role of the End User in Software Projects:
What role do end-users fill in Software projects?
Are they managers, customers, partners, bystanders or some combination thereof? As can be
expected, there is just one answer - it depends. End-users can fill any number of roles within a project
depending upon project type, organizational structures, and the quality of the relationship existing
between the end-user community and the Software Project organization.
There is only one certainty – the quality of the relationship between IT and the end-user community is
essential to success for most IT projects. Unfortunately, the IT/end-user relationship is not always
smooth and productive. In fact, under certain circumstances, these relationships can turn adversarial.
This may very well be the "nature of the beast", as natural territorial and political concerns rise to the
surface. IT staff may feel that their accountability is an automatic entitlement to project control and
ownership. On the other side of the equation, end-users may feel they should drive the project
process, as they hold the long term interest in final project results. This sets up a natural conflict that
must be overcome if projects are to proceed smoothly, delivering the required results.
As such, the management of the end-user relationship within the project environment is the
responsibility of the project manager.
States of a Software System called phases in the Unified Process:
45
Inception Elaboration
Transition Construction
The seven workflows in the Unified Process.
Inception Elaboration Construction Transition
Iter.#1 Iter.#2 Iter.#1 Iter.#2 Iter.#3 Iter.#1 Iter.#2 Iter.#1 Iter.#2
Management Workflow
Environment Workflow
Requirements Workflow
Design Workflow
Implementation Workflow
Assessment Workflow
Deployment Workflow
Time
46
Entity-centered life cycle view of the models of the Unified Process:
i1:Issue
status={Closed} i5:Issue
status = {Open}
i2:Issue
status = {Open} i7:Issue
status={Closed}
i3:Issue
status = {Open}
i6:Issue
status = {Open}
The waterfall model as a special case of the issue-based life cycle model. All issues that
belong to the same issue category are contained in the same UML package. In the project
status shown in the figure, all the requirements elicitation and analysis issues have been
closed; that is, the requirements elicitation and analysis activities have been completed:
47
Req. Elicitation Analysis
i1:Issue
i5:Issue
status={Closed}
status={Closed}
i2:Issue
i7:Issue
status={Closed}
status={Closed}
i3:Issue
status={Closed} System Design
i6:Issue
In a complex project state, all activities can still have some open issues, which means that
all activities need to be managed concurrently:
48
Req. Elicitation Analysis
i1:Issue
i5:Issue
status={Open}
status={Open}
i2:Issue
i7:Issue
status={Closed}
status={Closed}
i3:Issue
status={Closed} System Design
i6:Issue
Key Decisions in an Expedition:
A leader has to answer several key questions to create a successful expedition
• What mountain should be climbed?
• What process should be used?
• What types of tools should be used?
• Who should be member of the team?
• Does the expedition need a leader?
Different answers to these questions lead to different styles
• Fixed-rope Style
• Alpine Style
Key Decisions in an Software Project
• Project goals
• Schedule
• Cost
• Project organization
• Software life cycle Model
49
• Tools
• Methods
• Team members
Incremental development:
Project Context:
Project environment
• Defined by the client and by the current state of the development organization. The
environment constrains the project manager.
• Examples: Participants’ background, problem type, location of the project.
Methods
• Recipes that the project manager can select in the given environment.
• Examples: use case requirements elicitation or design pattern reuse.
Tools
• Devices or programs that support specific activities.
• Examples: modeling tools, compilers, debuggers, change tracking tools.
Software engineering methodology
• Collection of methods and tools for developing and managing a software system to
achieve a specific project goal in a given project environment.
• Specifies when methods or tools should be used, when not and what to do when
unexpected events occur.
The Software Design Process:
50
Project Environment comprises of:
Participants’ expertise
Client type (Application Domain Knowledge, Decision Power)
End user access
Technological climate
Geographical distribution
Project duration vs rate of change
End User Access:
Although clients may have deep domain knowledge, they have different stakes than the end user.
Clients are usually interested in an early delivery date, with as much functionality as possible, and low
cost. End users are interested in a system with a user interface that they are familiar with or is easy to
learn and that supports their specific task well. When the stakes of the client and the end user are
different, the project success may also depend on a usability test conducted by end users
Clients and end users usually do not have the same interests
Clients are interested in
• an early delivery date
• as much functionality as possible
• low cost.
End users are interested in
51
• a familiar user interface
• an easy to learn user interface
• A system that supports their specific task well
The project success may also depend on a usability test to be conducted by end users
Technological climate:
• Depending on the requirements expressed by the client, a project may be
constrained in the technological components it has to use. Examples:
• A project improving a legacy system deals with well-known and mature
technology. But the technology might be out of date
• A project developing a first-of-a-kind prototype based on a technology enabler
may have to deal with preliminary versions of components and immature
technology.
Geographical Distribution:
“Single room projects”: All participants are located in a single room, they can get to know each
other, much of the important coordination can occur informally.
There are situations when single-room projects are not possible or not desirable.
• The organization may have resulted from the merger or acquisition of several individual
companies with different skills.
• The organization is a consortium or a temporary alliance of several subcontractors,
located in different geographical locations.
• Some part of the development organization may need to be collocated with the client.
Geographical distribution has advantages and disadvantages:
• Increases the availability of skill and lower cost labor
• May take advantage of different time zones
• Slows communication
• Lowers awareness among teams
• Leads to loss of information between sites
Methodology Issue:
52
Methodologies provide guidance, general principles and strategies for selecting methods and
tools in a given project environment.
The key questions for which methodologies typically provide guidance include:
• How much planning should be done in advance?
• How much of the design should result from reusing past solutions?
• How much of the system should be modeled before it is coded?
• In how much detail should the process be defined?
• How often should the work be controlled and monitored? When should the project goals
be redefined?
Project duration vs Rate of Change:
Three Definitions:
PT = Project Time
TBC = Time Between Any Type of Change (Requirements, Technology)
MTBC = Mean Time Between Change
Frequency of Change determines the Choice of the Software Lifecycle Model:
Mean Time between Change >> Project Time
• Change is rare
• Choose an activity-oriented model: Waterfall model, V-Model
Mean Time between Change ≈ Project Time
• Changes occur occasionally during the project
• Choose an activity-oriented model with iterations: Boehm’s spiral model, Unified
Process
Mean Time between Change << Project Time
• Changes are normal (“Change is constant”)
• Choose an entity-oriented model: Issue-based model, Feature-driven model
Pros and Cons of Project Plans for Software Projects:
Plus
53
• Very useful to kick off a software project (to establish the goals, organize the
teams, and start with development)
• Useful also controlling a software project if the outcome is predictable or when no
major change occurs.
Con:
• Of limited value to control the project when the outcome is unpredictable or when
unexpected (“unusual”) events occur in the project that change the project
context.
Examples of unexpected events:
• Appearance of new technology which was unknown at project start.
• A visionary scenario turns out to be not implementable
• Company is merged with another one during the project
Methodology Issues:
• How much planning should be done in advance?
• How much of the design should result from reusing past solutions?
• How much of the system should be modeled before it is coded?
• In how much detail should the process be defined?
• How often should the work be controlled and monitored? When should the project
goals be redefined?
• How much Reuse?
• Reuse can significantly reduce the development effort required to deliver a
system.
How much Modeling?
Advantages of modeling:
• Modeling enables developers to deal with complexity
• Modeling makes implicit knowledge about the system explicit
• Modeling formalizes it so that a number of participants can share this knowledge.
If one is not careful, models can become as complex as the system being modeled.
54
Software Life Cycle:
♦ Software Life Cycle
Waterfall model and its problems
Pure Waterfall Model
V-Model
Iterative process models
Boehm’s Spiral Model
Entity-based models
Issue-based Development Model (Concurrent Development)
What we intend:
Requirements
Software
How it should go: Our plan of attack?
55
How it often goes?
Requirements
Analysis
D
E
L
A
Y
Vaporware
56
The Project Blame Game:
The project blame game has two players and two perspectives. The game begins as a battle over
technology project control. Team "IT" believes that end-users should not control technology projects
because they don’t understand the technology, don’t have a handle on their own requirements and
they change their minds too often. Team "end-user" believes that they should have control over
technology projects because IT places too much emphasis on technical needs, and not enough on
business needs, is largely inflexible, and is either unwilling or unable to accept or understand end-user
requirements. And so the game begins…..
Avoiding the Project Blame Game:
In order to deliver successful projects, the Software Project manager must face the "blame game"
possibilities, taking steps to overcome the conflicts. Ultimately, the primary goal is the avoid the game,
and to create one project team with the same set of goals and objectives.
Step One: Understand Project Requirement and Organizational Needs
Ultimately, the needs of the project should determine the role and extent of end-user involvement.
Some projects should be managed by the IT organization, and other projects are better managed by
the end-user community. The deciding factor may very well be the extent to which technology is the
"deliverable" or an "element" of the project outcome. For example, end-users may be better suited to
manage a relocation project, where technology is but one factor in the project result … i.e. to change
office locations. On the other hand, a project to roll-out a new e-mail system may be better served by
management run out of the IT operation. Again, it will all depend on your organizational needs and
attitudes. If the goal is to manage successful projects, then project management responsibilities
should rest with the organization best able to deliver successful results by virtue of skills, available
resources, time and capabilities.
Step Two: Consider the Possibilities
As discussed, end-user involvement will probably vary by the nature of the project at hand, but can
encompass any of these possibilities:
• End-User Project Management: End-users will assume project management responsibility, and
IT staff will act as a project team members. In the alternative, and if appropriate, IT can run its own
sub-project focusing on the technical elements of the main project, to be later integrated into the
whole.
• End-User Team Assignments: One or more members of the end-user community will take on
assigned responsibilities as active members of the project team, reporting to the Software
Projectmanager.
• End-User Project Liaisons: End-user staff can assume a coordination role within the project,
acting as a middleman between IT and the end-user community on project related issues.
57
End-users should never be eliminated from projects in entirety, even if the project is purely technical
(i.e. to swap server hardware over a weekend). While end-users may not have any specific input into
this type of project, they have a vested interest in the outcome, and should always be considered and
consulted.
Step Three: Identify Roles and Responsibilities
In order to build effective relationships, end-user roles and responsibilities should be clearly defined.
Obviously, if end-users are to manage a given project, they will the ones to define "IT" roles and
responsibilities, so these guidelines are meant to address those circumstances where project
management ownership rests with IT. In this circumstance, end-user roles and responsibilities should
be clearly defined and documented:
Essential End-User Roles & Responsibilities:
• Define business needs and requirements.
• Work with IT to specify deliverables.
• Work with IT to specify acceptance and success criteria.
• Follow established change control procedures to minimize unwarranted change requests.
• Establish communications channels to report issues and change requests.
• Participate in demonstrations and tests as needed.
• Provide feedback as needed after tests and pilots.
• Work through problems and issues without blame and finger-pointing.
Step Four: Communicate
Effective communication will be a key factor of success in avoiding the project blame game. As you
work with your end-users to define project involvement, you will need to use all your communications
skills in order to....
• Understand and acknowledge end-user concerns.
• Negotiate roles and responsibilities.
• Market Software Projectskills and capabilities, focusing on prior success stories, or, if needed,
on lessons learned from prior experiences
• Help end-users to define their needs.
• Communicate roles and responsibilities through documentation and in meetings.
Step Five: Monitor the Relationship
As your project progresses, you need continually monitor the IT / end-user relationship for signs of the
"blame game". As a pragmatic project manager, you need be on the look out for any signals
indicating potential relationship break-downs:
• Disgruntled project team members.
• Any sudden changes in team attitude or work dynamic.
58
• An increase in management complaints and reported problems
• Frequent change requests.
• Unexpected project delays.
• Negative attitudes and internal team conflicts
If these signs are apparent, you need to take quick action, including head-on, open discussions in
group settings or in one-on-one meetings. Confront problems, find causes, and take action to resolve
through negotiation, procedural changes, increased communication, or any other valid means
available. Once problems fester, they become harder to resolve and address.
Step Six: Transfer Project Responsibility
Once a project is completed, formal ownership should be transferred to the appropriate organizational
entity. Projects should close with a formal meeting to transition results, review the project and
acknowledge participation. These efforts can generate positive feelings that may very well linger on
into the next project.
Inherent Problems with Software Development:
♦ Requirements are complex
The client does not know the functional requirements in advance
♦ Requirements may be changing
Technology enablers introduce new possibilities to deal with nonfunctional requirements
♦ Frequent changes are difficult to manage
Identifying milestones and cost estimation is difficult
♦ There is more than one software system
New system must be backward compatible with existing system (“legacy system”)
Phased development: Need to distinguish between the system under development and
already released systems
♦ Let’s view these problems as the nonfunctional requirements for a system that supports
software development!
This leads us to software life cycle modeling
Software Life Cycle:
59
♦ Software construction goes through a progression of states
Conception Childhood Adulthood Retirement
Pre- Post-
Development Development
Development
Debugging Process:
Possible Identification of Software Development:
60
Requirements Analysis What is the problem? Problem
Domain
System Design What is the solution?
What are the mechanisms
Program Design that best implement the
solution?
How is the solution
Program Implementation
constructed?
Testing Is the problem solved?
Delivery Can the customer use the solution?
Activities Maintenance Are enhancements needed?
IEEE Std 1074: Standard for Software Lifecycle:
Process Group
IEEE Std 1074
Project Pre- Develop- Post- Cross-
Management Development ment Development Development
(Integral Processes)
> Project Initiation > Concept > Requirements > Installation >V&V
>Project Monitoring Exploration Analysis > Operation & > Configuration
&Control > System > Design Support Management
> Software Quality Allocation > Implemen- > Maintenance > Documen-
Management tation > Retirement tation
> Training
Processes
Testing:
Application Testing Overview
61
Following are the definitions of the various testing done in the software industry
1. Unit Testing
Testing of individual hardware or software units or groups of related units
2. Functional Testing
Testing that ignores the internal mechanism of a system or component and focuses solely on
the output generated in response to selected inputs and execution conditions
3. Integration Testing
Testing in which software components, hardware components, or both are combined and tested
to evaluate the interaction between them
4. System Testing
Testing conducted on a complete, integrated system to evaluate the system's compliance with
its specified requirements
5. Regression Testing
Selective retesting of a system or component to verify that modifications have not caused
unintended effects and that the system or component still complies with its specified
requirements
6. Load / Performance Testing
Testing conducted to evaluate the compliance of a system or component with specified
performance requirements
7. User Acceptance Testing
Formal testing conducted to determine whether or not a system satisfies its acceptance criteria
and to enable the customer to determine whether or not to accept the system
Testing Process:
There are three primary deliverables for the testing process…..
• The Test Plan: The Test Plan document lays out a roadmap for the testing process, specifying
overall goals, scope, test assumptions, logistics, risks, tasks and resource assignments.
62
• The Test Specification: The Test Specifications document details the tests to be performed
according to type, purpose, expected result, inclusions, exclusions and methodologies.
• The Test Script: The Test Script document provides a specific set of instructions to be executed
for each element of the testing process. Test scripts can be automated (for use by software
testing tools) or manual (to be executed by end-users or IT personnel as appropriate). In
addition, test scripts should always define a clear process for recording results.
Test Planning – Step by Step:
• Identify your testing requirements.
• Set your testing goals and objectives.
• Select your testing methodologies.
• Create your Test Plan and obtain approvals as needed.
• Create your Test Specifications and obtain approvals as needed.
• Build your test environment (hardware, software, infrastructure, etc).
• Create your Test Scripts and obtain approvals as needed.
• Schedule your test and obtain approvals as needed.
• Notify all participants.
• Conduct your test and record all results.
• Analyze results and apply the lessons learned to resolve identified problems and related
operational issues.
Testing Phases:
Quality Assurance:
63
The Quality Assurance (QA) group provides leadership with the appropriate visibility into any processes
being used by a project. The QA team will perform project audits to ensure that EAS teams are
meeting SEI/CMM/Client guidelines.
Formal QA
Random Quality Assurance testing will be conducted by our Quality Assurance Group.
Project Type Quality Review Timeframe
Maintenance Upon project closing
Category 1 Upon completion of a project phase.
Category 2 Upon completion of a project phase.
QA Self Assessment:
Any employee outside of our QA GROUP may conduct informal QA at any time. They must however
use the same checklist’s.
64
Category 1 Project Checklist:
This Checklist (except Reviewed By and Review Date) will be filled by the Project Team for QA Self
Assessments after completion of the project phase (at the least Requirements Phase) and also
completion of project, and by the QA group during random
Category 2 Checklist: This Checklist (except Reviewed By and Review Date) will be filled by the
Project Team for QA Self Assessments after completion of each project phase and by the QA group
during random QA audit to verify that all the required work products have been completed and all
defined business processes have been followed.
Processes, Activities and Task:
♦ Process Group: Consists of Set of Processes
♦ Process: Consists of Activities
♦ Activity: Consists of sub activities and tasks
Development
Process
Group
Process Design
Activity Design
Database
Task Make a
Purchase
Recommendation
Example:
♦ The Design Process is part of Development
♦ The Design Process consists of the following Activities
Perform Architectural Design
Design Database (If Applicable)
Design Interfaces
Select or Develop Algorithms (If Applicable)
Perform Detailed Design (= Object Design)
65
♦ The Design Database Activity has the following Tasks
Review Relational Databases
Review Object-Oriented Databases
Make a Purchase recommendation
Modeling Dependencies in a Software Lifecycle:
Problem System System
definition development operation
activity activity activity
System
development
activity
System
upgrade
activity
Market
creation
activity
Life Cycle Modeling:
Many models have been proposed to deal with the problems of defining activities and associating them
with each other. The first model proposed was the waterfall model [Royce 1970]
Life-Cycle Model: Variations on a Theme:
♦ Many models have been proposed to deal with the problems of defining activities and
associating them with each other
♦ The waterfall model
First described by Royce in 1970
♦ There seem to be at least as many versions as there are authorities - perhaps more
The Waterfall Model of the Software Life Cycle:
66
Concep
Exploratio
t
n Proces
s
Syste
Allocatio
m
n Proces
s
Requiremets
Proces
s
Desig
Proces
n
s
Implementatio
n Proces
s
Verificatio
&
n
Proces
Validation
s
Installatio
adapted from [Royce 1970] n Proces
s
Operation
Support
&
Process
Problems with Waterfall Model:
♦ Managers love waterfall models:
Nice milestones
No need to look back (linear system), one activity at a time
Easy to check progress : 90% coded, 20% tested
♦ Different stakeholders need different abstractions
=> V-Model
♦ Software development is iterative
During design problems with requirements are identified
During coding, design and requirement problems are found
During testing, coding, design& requirement errors are found
=> Spiral Model
♦ System development is a nonlinear activity
67
=> Issue-Based Model
♦ The V model and its variants do not distinguish temporal and logical dependencies,
but fold them into one type of association
♦ In particular, the V model does not model iteration
From the Waterfall Model to the V Model:
Acceptance
Requirement
s
System
Requirement
Testing
s
Integration
Testing
System Design
Unit
Testing
Object Design
Implemen-
tation
Unit
Testing
Integration
Testing
System
Testing
Activity Diagram of a V Model:
68
System Is validated by
Requirements Operation
Analysis
precedes
Software
Requirements Client
Elicitation Acceptance
System
Requirements Integration
Analysis & Test
Component
Preliminary Integration
Design & Test
Detailed Unit
Design Test
Problem with the V-Model:
Implementation Developers Perception =
User Perception
V Model: Distinguishes between Development and Verification Activities
Problems with V Model:
Client’s Understanding
Level of Detail
Developer’s Understanding
Requirements Acceptance
Elicitation Testing
Problem with V-Model:
Client’s Perception is the same as the
Developer’s Perception
Analysis System
Testing
Design Integration Testing
Object Design Unit Testing
High
Project Time
69
HP Software firm Waterfall Lifecycle
HP Software firm V- Lifecycle
70
HP Software firm Staged Lifecycle
HP Software firm Iterative Lifecycle
71
HP Software firm Rapid Application Development Lifecycle
72
Project Management Process
This section presents an overview of the steps in the process of managing projects, key deliverables
from the steps and some key conventions used to execute the process consistently.
High Level Work Flow ( Courtesy: Oracle Inc)
73
74
Project Lifecycle Matrix ( Courtesy : Oracle Inc)
The Alternative: Allow Iteration:
Spiral Model (Boehm) Deals with Iteration
♦ The spiral model proposed by Boehm is an iterative model with the following activities
Determine objectives and constraints
Evaluate Alternatives
Identify risks
Resolve risks by assigning priorities to risks
Develop a series of prototypes for the identified risks starting with the highest risk.
Use a waterfall model for each prototype development (“cycle”)
If a risk has successfully been resolved, evaluate the results of the “cycle” and plan
the next round
75
If a certain risk cannot be resolved, terminate the project immediately
Activities (Cycles) in Boehm’s Spiral Model:
Concept of Operations
Software Requirements
Software Product Design
Detailed Design
Code
Unit Test
Integration and Test
Acceptance Test
Implementation
For each cycle go through these activities
Quadrant IV: Define objectives, alternatives, constraints
Quadrant I: Evaluate alternative, identify and resolve risks
Quadrant II: Develop, verify prototype
Quadrant III: Plan next “cycle”
Note: 1. The first 3 cycles are shown in a polar coordinate system.
2. The polar coordinates r = (l, a) of a point indicate the resource spent in the project and the type
of activity
76
Spiral Model:
Spiral Model
Risk
analysis
Risk
analysis
Project P1
Risk
analysis
P1
Prototype3
Prototype2
Prototype1
System
Design Design
plan validation
P2
Code
Integration & Test
Acceptance
Test
Project P2
77
Cycle 1, Quadrant IV: Determine Objectives, Alternatives and Constraints:
78
Projec
t
Start
79
Cycle 1, Quadrant I: Evaluate Alternatives, Identify, resolve risks:
Build
Prototype
80
Cycle 1, Quadrant II: Develop & Verify Product:
81
Concept of Operation
Activity
82
Cycle 1, Quadrant III: Prepare for Next Activity:
Requirements and
Life cycle
Planning
83
Cycle 2, Quadrant IV: Software Requirements Activity:
84
Start
of Round 2
Comparing two Projects:
Risk
analysis
Risk Project P1
analysis
Risk
analysis
P1
Prototype3
Prototype2
Prototype1
System
Design Design
plan validation
P2
Code
Integration & Test
Project P3 Acceptance
Test Project P2
85
The Limitations of the Waterfall and Spiral Models:
♦ Neither of these model deals well with frequent change
The Waterfall model assume that once you are done with a phase, all issues covered
in that phase are closed and cannot be reopened
The Spiral model can deal with change between phases, but once inside a phase, no
change is allowed
♦ What do you do if change is happening more frequently? (“The only constant is the
change”)
Types of Prototypes used in the Spiral Model:
ϖ Illustrative Prototype
Develop the user interface with a set of storyboards
Implement them on a napkin or with a user interface builder (Visual C++, ....)
Good for first dialog with client
ϖ Functional Prototype
Implement and deliver an operational system with minimum functionality
Then add more functionality
Order identified by risk
ϖ Exploratory Prototype ("Hacking")
Implement part of the system to learn more about the requirements.
Good for paradigm breaks
ϖ Revolutionary Prototyping
Also called specification prototyping
Get user experience with a throwaway version to get the requirements right, then
build the whole system
ϖ Disadvantage: Users may have to accept that features in the prototype are
expensive to implement
86
ϖ User may be disappointed when some of the functionality and user interface
evaporates because it can not be made available in the implementation
environment
ϖ Evolutionary Prototyping
The prototype is used as the basis for the implementation of the final system
Advantage: Short time to market
Disadvantage: Can be used only if target system can be constructed in prototyping
language
Prototyping vs Rapid Development:
ϖ Revolutionary prototyping is sometimes called rapid prototyping
ϖ Rapid Prototyping is not a good term because it confuses prototyping with rapid
development
Prototyping is a technical issue: It is a particular model in the life cycle process
Rapid development is a management issue. It is a particular way to control a project
ϖ Prototyping can go on forever if it is not restricted
υ “Time-boxed” prototyping limits the duration of the prototype development
An Alternative: Issue-Based Development:
♦ A system is described as a collection of issues
Issues are either closed or open
Closed issues have a resolution (for example: pseudo requirement)
Closed issues can be reopened (Iteration!)
♦ The set of closed issues is the basis of the system model
87
I1:Open A.I1:Open SD.I1:Closed
SD.I3:Closed
I2:Closed I3:Closed A.I2:Open SD.I2:Closed
Planning Requirements Analysis System Design
Frequency Change and Software Lifecycle:
PT = Project Time, MTBC = Mean Time Between Change
Change rarely occurs (MTBC >> PT):
Waterfall Model
All issues in one phase are closed before proceeding to the next phase
Change occurs sometimes (MTBC = PT):
Boehm’s Spiral Model
Change occuring during a phase might lead to an iteration of a previous
phase or cancellation of the project
“Change is constant” (MTBC << PT):
Issue-based Development (Concurrent Development Model)
Phases are never finished, they all run in parallel
– Decision when to close an issue is up to management
– The set of closed issues form the basis for the system to be developed
Waterfall Model: Analysis Phase:
88
I1:Open
A.I1:Open
I2:Open I3:Open
A.I2:Open
SD.I1:Open
Analysis
Analysis SD.I3:Open
SD.I2:Open
Waterfall Model: Design Phase:
I1:Closed
A.I1:Open
I2:Closed I3:Open
A.I2:Open
SD.I1:Open
Analysis
Analysis SD.I3:Open
SD.I2:Open
Design
Waterfall Model: Implementation Phase:
89
I1:Closed
A.I1:Closed
I2:Closed I3:Closed
A.I2:Closed
SD.I1:Open
Analysis
SD.I3:Open
SD.I2:Open
Design
Implementation
Waterfall Model: Project is Done:
90
I1:Closed
A.I1:Closed
I2:Closed I3:Closed
A.I2:Closed
SD.I1:Open
Analysis
SD.I3:Open
SD.I2:Open
Design
Implementation
91
Issue-Based Model: Analysis Phase:
I1:Open
A.I1:Open
I2:Open I3:Open
A.I2:Open
Analysis:80%
SD.I1:Open
SD.I3:Open
SD.I2:Open
Design: 10%
Implemen-
tation: 10%
Issue-Based Model: Design Phase:
92
I1:Closed
A.I1:Open
I2:Closed I3:Open
A.I2:Open
Analysis:40%
SD.I1:Open
SD.I3:Open
SD.I2:Open
Design: 60%
Implemen-
tation: 0%
Issue-Based Model: Implementation Phase:
I1:Open
A.I1:Open
I2:Closed I3:Closed
A.I2:Closed
Analysis:10%
SD.I1:Open
SD.I3:Open
SD.I2:Cosed
Design: 10%
Implemen-
tation: 60%
93
Issue-Based Model: Project is Done:
I1:Closed
A.I1:Closed
I2:Closed I3:Closed
A.I2:Closed
Analysis:0%
SD.I1:Closed
SD.I3:Closed
SD.I2:Closed
Design: 0%
Implemen-
tation: 0%
Process Maturity:
Process maturity describes a set of maturity levels at which an organizations' development process
takes place. Once when the development process possesses sufficient structure and procedures
does it make sense to collect certain kind of metrics
Some people contend that maturity and excellence in project management are the same.
Unfortunately, this is not the case. Consider the following definition:
Maturity in project management is the implementation of a standard methodology and
accompanying processes such that there exists a high likelihood of repeated successes.
This definition is supported by the life-cycle phases shown in the below Table. Maturity implies that
the proper foundation of tools, techniques, processes, and even culture, exists. When projects
come to an end, there is usually a debriefing with senior management to discuss how well the
methodology was used and to recommend changes. This debriefing looks at "key performance
indicators," which are shared learning topics, and allows the organization to maximize what it does
right and to correct what it did wrong.
94
Why do we care about process maturity? Well, with increasing maturity we assume that the risk of
project failure decreases. For example,
♦ A software development process is mature
if the development activities are well defined and
if management has some control over the quality, budget and schedule of the
project
♦ Process maturity is described with
a set of maturity levels and
the associated measurements (metrics) to manage the process
♦ Assumption:
With increasing maturity the risk of project failure decreases
Capability maturity level:
1. Initial Level
also called ad hoc or chaotic
2. Repeatable Level
Process depends on individuals ("champions")
3. Defined Level
Process is institutionalized (sanctioned by management)
4. Managed Level
Activities are measured and provide feedback for resource allocation (process itself
does not change)
5. Optimizing Level
Process allows feedback of information to change process itself
95
Maturity Level 1: Chaotic Process:
We view the process maturity in concert with the types of measurements needed to help us
manage the process.
The first level of process is called initial or also chaotic. It is characterized by an ad hoc approach to
the software development process. That is the inputs to the process are ill-defined, the outputs are
expected, but nobody knows how to to do the transition from the non-existing or ill-defined inputs
to the output
ϖ Ad hoc approach to software development activities
ϖ No problem statement or requirements specification
ϖ Output is expected
but nobody knows how to get there in a deterministic fashion
ϖ Similar projects may vary widely in productivity
"when we did it last year we got it done"
ϖ Level 1 Metrics: Rate of Productivity (Baseline comparisons, Collection of data is difficult)
Product size (LOC, number of functions, etc)
Staff effort (“Man-years”, person-months)
96
ϖ Recommendation: Level 1 managers & developers should not concentrate on metrics and
their meanings,
They should first attempt to adopt a process model (waterfall, spiral model, saw-
tooth, macro/micro process lifecycle, unified process)
Maturity Level 2: Repeatable Process:
ϖ Inputs and outputs are defined
Input: Problem statement or requirements specification
Output: Source code
ϖ Process itself is a black box ( activities within process are not known)
No intermediate products are visible
No intermediate deliverables
ϖ Process is repeatable due to some individuals who know how to do it
"Champion"
ϖ Level 2 Metrics:
Software size: Lines of code, Function points, classes or method counts
Personnel efforts: person-months
Technical expertise
ϖ Experience with application domain
ϖ Design experience
ϖ Tools & Method experience
Employee turnover within project
Example: LOC (Lines of Code) Metrics:
Level 2 Metrics:
Software size: Lines of code, Function points, classes or method counts
Personnel efforts: person-months
Technical expertise
υ Experience with application domain
97
υ Design experience
υ Tools & Method experience
Employee turnover within project
Maturity Level 3: Defined Process:
ϖ Activities of software development process are well defined with clear entry and exit
conditions.
ϖ Intermediate products of development are well defined and visible
ϖ Level 3 Metrics (in addition to metrics from lower maturity levels):
Requirements complexity: Number of classes, methods, interfaces
Design complexity: Number of subsystems, concurrency, platforms
Implementation complexity: Number of code modules, code complexity
Testing complexity: Number of paths to test, number of class interfaces to test
Thoroughness of Testing:
υ Requirements defects discovered
υ Design defects discovered
υ Code defects discovered
υ Failure density per unit (subsystem, code module, class
Maturity Level 4: Managed Process:
Defect discovery: Knowing whether defects are discovered during requirements reviews, design
reviews or code walkthroughs determines the effectiveness of these activities
Even if iteration is employed, the basic activities themselves do not change.
ϖ Uses information from early project activities to set priorities for later project activities
(intra-project feedback)
The feedback determines how and in what order resources are deployed
ϖ Effects of changes in one activity can be tracked in the others
ϖ Level 4 Metrics:
Number of iterations per activity
98
Code reuse: Amount of producer reuse (time designated for reuse for future
projects?)
Amount of component reuse (reuse of components from other projects and
components)
Defect identification:
ϖ How and when (which review) are defects discovered?
Defect density:
ϖ When is testing complete?
Configuration management:
ϖ Is it used during the development process? (Has impact on traceability of
changes).
Module completion time:
ϖ Rate at which modules are completed (Slow rate indicates that the process
needs to be improved).
Maturity Level 5: Optimizing Process:
Change in management scheme: From chief programmer team to egoless programming
Change in process: Which company is doing this right now? None?
Is Level 5 achievable? Not clear!
ϖ Measures from software development activities are used to change and improve the current
process
ϖ This change can affect both the organization and the project:
The organization might change its management scheme
A project may change its process model before completion
Industry Distribution across Maturity Levels:
(State of the Software Industry in 2005)
Maturity Level Frequency
99
1 Initial 30%
2 Repeatable 15%
3 Defined < 20%
4 Managed < 35%
5 Optimizing < 1%
What does Process Maturity Measure?:
ϖ The real indicator of process maturity is the level of predictability of project performance
(quality, cost, and schedule).
Level 1: Random, unpredictable performance
Level 2: Repeatable performance from project to project
Level 3: Better performance on each successive project
Level 4: project performance improves on each subsequent project either
υ Substantially (order of magnitude) in one dimension of project performance
υ Significant in each dimension of project performance
Level 5: Substantial improvements across all dimensions of project performance.
Determining the Maturity of a Project( Level 1 and Level2):
ϖ Level 1 questions:
Has a process model been adopted for the Project?
Software size: How big is the system?
Personnel effort: How many person-months have been invested?
Technical expertise of the personnel:
υ What is the application domain experience
υ What is their design experience
υ Do they use tools?
100
υ Do they have experience with a design method?
What is the employee turnover?
Level 3 Questions:
• What are the software development activities?
• Requirements complexity:
o How many requirements are in the requirements specification?
• Design complexity:
o Does the project use a software architecture? How many subsystems are
defined? Are the subsystems tightly coupled?
• Code complexity: How many classes are identified?
• Test complexity:
o How many unit tests, subsystem tests need to be done?
• Documentation complexity: Number of documents & pages
• Quality of testing:
o Can defects be discovered during analysis, design, implementation? How is it
determined that testing is complete?
o What was the failure density? (Failures discovered per unit size)
Has intra-project feedback been used?
Is inter-project feedback used? Does the project have a post-mortem phase?
How much code has been reused?
Was the configuration management scheme followed?
Were defect identification metrics used?
Module completion rate: How many modules were completed in time?
How many iterations were done per activity?
101
Did we use measures obtained during development to influence our design or
implementation activities?
Process Excellence:
Organizations excellent in project management are those that create the environment in which
there exists a continuous stream of successfully managed projects and where success is measured
by what is in the best interest of both the company and the project (i.e., customer).
Excellence goes well beyond maturity. You must have maturity to achieve excellence.
Important Executives who always make the right decision are not making enough
decisions. Likewise, organizations in which all projects are completed
successfully are not taking enough risks and are not working on enough
projects.
The below Figure shows that once the organization completes the first four life-cycle phases in the
below Table, it may take two years or more to reach some initial levels of maturity. Excellence, if
achievable at all, may take an additional five years or more.
Figure: The growth of excellence.
The below Figure also brings out another important fact. During maturity, more successes than
failures occur. During excellence, we obtain a continuous stream of successful projects. Yet, even
after having achieved excellence, there will still be some failures.
It is unrealistic to believe that all projects will be completed successfully. Some people contend that
the only true project failures are the ones from which nothing is learned. Failure can be viewed as
102
success if the failure is identified early enough so that the resources can be reassigned to other
more opportunistic activities.
System Evolution:
Rational Unified Process( RUP):
Steps to Take in Using Metrics:
Metrics are useful only when implemented in a careful sequence of process-related activities.
1. Assess your current process maturity level
2. Determine what metrics to collect
3. Recommend metrics, tools and techniques
whenever possible implement automated support for metrics collection
4. Estimate project cost and schedule and monitor actual cost and schedule during development
5. Construct a project data base:
103
Design, develop and populate a project data base of metrics data.
Use this database for the analysis of past projects and for prediction of future
projects.
6. Evaluate cost and schedule for accuracy after the project is complete.
7. Evaluate productivity and quality
Make an overall assessment of project productivity and product quality based on the
metrics available.
Estimating Database Templates
104
Pros and Cons of Process Maturity:
ϖ Problems:
Need to watch a lot
Overhead to capture, store and analyse the required information
ϖ Benefits:
Increased control of projects
Predictability of project cost and schedule
Objective evaluations of changes in techniques, tools and methodologies
Predictability of the effect of a change on project cost or schedule
105
Shark tooth Model:
User’s Understanding
Manager’s Understanding
Client
System Prototype Prototype
Requirements Client
Elicitation Demo 1 Demo 2 Acceptance
Manager
Design System
Review Integration
& Test
Developer
Requirements
Analysis Component
Integration
& Test
System
Design
Unit
Object Test
Design
Implementation
106
Saw tooth Model:
107
Client’s Understanding
Client
Requirements Prototype Prototype Client
Elicitation Demonstration 1 Demonstration 2 Acceptance
Developer
System
Integration
& Test
Requirements
Analysis Integration
& Test
System
Design
Object Unit Test
Design
Implementation
Issue-based Modeling: Project Example:
ϖ Project Purpose:
Determine the structure of the universe
ϖ Project duration:
Start: 2000 years ago
Deadline: unknown
ϖ Project Members:
Aristoteles, Ptolemeus,
Tycho Brahe, Kopernikus,
Galileo, Pope Gregor,
Newton
Hubble
108
The issue: What is the center of the Universe?
Pope: "The earth is the center of the universe"
υ Why?
Galileo: "The sun is the center of the universe"
υ Why?
Also, "the Jupiter’s moons rotate round Jupiter, not around Earth".
Issue-Modeling:
Issue-Modeling
Issue:
What is the Resolution (1615):
Issue Reopened Center of the The church
(1998): Universe? decides proposal 1
The church is right
declares
Proposal1: Proposal2:
The earth! The sun!
Proposal 3:
There is no
Center!
Pro:
Pro:
Aristotle
Con: Copernicus
says so.
Jupiter’s moons says so.
rotate
Pro: around Jupiter, not
Change will around Earth.
disturb
the people.
An Organization with a Reporting and Decision Structure:
109
♦ The developers make local decisions and reports them via a status report to the leader
(team leader, project manager)
♦ The team leader, who has a local overview of the subsystem, can override these
decisions. She reports them to the project manager.
♦ The project manager, who has a global view of the project, can virtually override any
decision.
Management
:Team
decision decision
status status
UserInterface Control
:SubsystemTeam Database :SubsystemTeam
:SubsystemTeam
An Organization with Distinct Reporting, Decision and Communication Structures:
♦ Developers communicate with each other without having to communicate with the team
leader or project leader.
♦ Developers make local decisions and report them to the leader
The team leader, who has a local overview of the subsystem, can override these
decisions. She reports them to the project manager.
The project manager, who has a global view of the project, can virtually override any
decision.
110
Management
reports to :Team reports to
reports to reports to
reports to
communicates with communicates with Control
UserInterface
:SubsystemTeam :SubsystemTeam
Database
:SubsystemTeam
communicates with communicates with
Architecture: Documentation:
CrossFunctionalTeam CrossFunctionalTeam
Example of a Hierarchical Organization:
Chief Programmer
Assistant
Chief Programmer
Senior Programmer Librarian Administration Tester
Junior Programmer
Nonhierarchical Project Organization:
111
Project
Leader
Coaches
Subsystem Team Subsystem Team Subsystem Team
A B Team
Members
A wants to talk to B: Communication Flow
B wants to make sure A does a certain change: Decision Flow
Basis of organization:
Nonlinear information flow across dynamically formed units
A Nonhierarchical Organization:
Egoless Programming [Weinberg 1971]:
112
Analyst
Tester Programmer
Designer Librarian
Project Specific Information Definitions:
The following section defines the project team folder structure in relation to the project lifecycle.
1. Business Requirements - The purpose of this document is to provide the core list of customer
requirements to be addressed by the project to solve the customer’s business problem or help
the customer achieve a business objective and is the foundation upon which all project plans,
specifications, activities, and products are based.
Stage of Project Lifecycle - Requirements Management Stage.
– User requirements. High level goals and objectives of the system to do the following:
a. Set out the project scope and requirement.
b. Outline the business opportunity for potential providers.
c. Describe the context of the requirement.
Give interested parties sufficient information to enable them to respond with expressions of
interest.
2. Change Requests – The Change Request form captures information relating to Project Tracking
Number, Change Number, Project Name, Requestor Name, Requestor Phone Number, Request
Date, Description of Change, phase change was requested in, Impact Summary (Scope, Cost,
Schedule, Other), Impacted Items, Risk Impact, Approvals, and Capturing Cost of Poor Quality
Metric.
113
Stage of Project Lifecycle – Requirements Management Stage.
– The Change Process is:
a. Submit change request.
b. Assign change owner.
c. Perform impact analysis (impact on service and impact on current projects).
d. Review change request and impact analysis.
e. Management approval.
f. Implementation.
3. Data Requirements – Description of any data that is input or output from the product as well as
any data that are stored within the system for example in files or on disc. Stage of Project
Lifecycle - Requirements Management Stage.
4. E-mails – E-mails containing approvals, decisions, communications, scope, and scope change,
priorities, explanations, deliverables, dates, commitments and project members and audiences.
Stage of Project Lifecycle – All Stages & Project Closeout Stage.
5. Meetings – Meeting minutes.
Stage of Project Lifecycle – All Stages.
6. RAILS – Rolling Action Item ListS.
Stage of Project Lifecycle – Requirements Management Stage.
7. Technical Docs
a. Deployment Plan – A detailed subset of the project plan covering all actions above and
beyond acceptance testing required to activate the functional change in the production
system. It may include detailed checklists of setup tasks and also communication and
training tasks.
Stage of Project Lifecycle – Development-Design Stage.
b. Technical Specifications – Describes the internal implementation of the program.
Information is captured/documented pertaining to data structures, relational database
114
models, choice of programming languages and tools, algorithms. It differs from
functional specs, which state what the system is to DO, entirely from the user’s
perspective. General guidelines are:
i. System overview: Describe the overall functionality of the system and how it fits
with other key systems and business objectives.
ii. Technical Summary: Briefly describe the technical features of the system. Specify
features that are unique or require additional time or skills to implement.
iii. Resources: Record the people and their roles who will be directly involved in
building, testing, etc the system. Identify the material resources required - for
example servers or other hardware.
iv. Assumptions: List the assumptions that influence the design and deployment
decisions.
v. Programming Specifications: In this section enter the details of how resources
will build the system.
vi. Programming tools: List the programming tools, if appropriate, that are to be
used for the project.
vii. Algorithms: specify algorithms applied in the solution.
viii. System Architecture.
ix. Testing.
x. Implementation.
Performance and Recovery.
c. Test Cases – Scenarios. Test cases, test scripts and test packages are results of the
Test planning stage.
See SEI CMM Command Media Library for template (Test Data & Plan).
d. Test Plans – Test plans include information such as scope, resource requirements for the
integration test, system test, and acceptance test stages, the test schedule, test
environment, test tools, security, libraries/directories, test data, test case/requirements
traceability, test case section, test scripts, test packages and document approvals.
115
The purpose of the Test Plan Document is to define a detailed, comprehensive plan for
controlling and testing the application by organizing the testing activities during its
prototype, build, and production states. The purpose of testing is:
• to prove that the application addresses the business problems and satisfies the
user’s requirements
• to uncover any application system defect
• to ensure quality throughout the project
e. Test packages – Test packages are a result of the planning stage.
f. Turnover - At turnover milestones from one environment to the next in the waterfall
model of the lifecycle, coordination between responsible parties can be done verbally at
the Dev1 to Dev2 and Dev2 to QA stages but should be followed up with an e-mail to
the PM/PL and technical lead from the analyst and an approval e-mail from the
functional contact. The PM/PL confirms via e-mail the completion of the task to the
analyst and the technical lead. The analyst communicates the turnover to the functional
contact and relevant parties. The e-mails from the functional contact of approval,
analyst requesting the turnover from one environment to another, the approval(s) from
the technical lead/manager, the notification from the DBA/analyst that the task(s) are
completed are to be stored in the shared folder and in the project folder in e-project.
i. Dev1 to Dev2 * not required, but if done, then e-mails should be retained and
stored in the same areas that the other phases are stored.
ii. Dev2 to QA * required.
iii. QA to Prod * required.
Stage of Project Lifecycle – Implementation Stage.
Many organisations remain at either level one (initial) or level two (planned). It is emphasized that
the level of maturity relates to an organisation as a whole, rather than to ‘pockets of excellence’
within organisations.
116
Figure: Maturity levels of project management within organisations Source: Adapted by author
from Carnegie-Meillon Capability Maturity Model (CMM)
Figure: Profile of the complete project manager
PMIS – When to use / not use:
Recommendation:
Use Microsoft Project For:
All Category 1 projects, >40 and <160 (Use Micro soft_ Projects)
All Category 2 projects, >160 ( Use high PMIS)
117
MS Project Project
Planned/Re-Planning Activities Actuals
(Master Schedule)
Develop Project Schedule Update Actual dates, actual hours, %
complete
Update schedule All project documentation
Add resources (dynamic apps) Issues, risks, change
requests, etc
Configuration Management:
Clients benefit from version control by providing quick access to previous versions of the product as
they are needed for such tasks as restores and disaster recovery. The individual benefits by having
a method to save milestones in his/her coding progress. The developer and team must have
visibility to the actual development progress.
Application Development and Support
Development / Warranty Phase
ETVX Model
The development and support phases are defined through an ETVX model described below.
The ETVX model is based on:
• Entry criteria, which must be satisfied before a set of tasks can be performed
• Tasks that should be performed
• Verification and validation process to ensure that the right tasks are performed
• eXit criteria or the output of the tasks
If an activity fails in the validation check, either corrective action is taken or a change request
is ordered.
118
Development Phase
Purpose
The objectives of this phase are:
• Develop Code based on Design Specification and Standards.
• Test the code based on the Unit Test Plan.
• Review the code against Coding Standards.
Entry Criteria
• Approved Design Specification.
• Approved Unit Test Plan.
• Coding Standards.
Tasks
• Code the component based on the Design Specification.
• Follow coding standard identified for the project.
• Perform Unit Test
• Create test data to test the component / program.
• Execute test cases as per the Unit Test Plan.
• Document test results
• Perform Code Review
Verification and Validation
• QA of Code Review
• QA of Test Results
Exit Criteria
119
• Unit Tested Code
Warranty Phase
Purpose
The objective of this phase is:
• Corrective Maintenance – maintenance performed to correct faults in hardware or
software.
Entry Criteria
• User Acceptance Testing Sign Off.
• Application in Production Environment.
• Baseline Code
• Application Documents
All Documentation used for development of the application / project as listed below but
not limited to the following.
o Business Requirement Document
o Design Specifications.
o Application Prototype
o Unit Test Plan.
o Integration Test Plan
o Architecture Diagram
o Integration Diagram
o Coding Standards
• Coding Standards
Tasks
• Do Impact Analysis
• Code as per Standards
• Test for fix
• Document test results
120
• Migrate / Deploy Code
• Customer Sign Off
• Turn Over
Verification and Validation
• Quality Assurance
Exit Criteria
• Updated Project Deliverables
Security and Controls:
Export Control
Export-controlled material is any material that cannot be released to foreign nationals or
representatives of a foreign entity, without first obtaining approval or license from local
government agencies such as the U.S. Department of State for items controlled by the
International Traffic in Arms Regulations (ITAR), or the U.S. Department of Commerce for items
controlled by the Export Administration Regulations (EAR), in case of US based Software firms..
Security
Organizations intellectual property must be protected by the policies and procedures. A clear
definition of project managers’ roles and responsibilities in protecting Information Assets.
Consideration to some or all of the following should be a part of every project plan:
Firewall Protection - all external (client) connections are required to pass through at least
one firewall.
Infrastructure Service Request – to request support for Information Technology
infrastructure (ISR).
ID Management – provides tools and technologies such as LDAP to manage end user access
to applications using a centralized global authentication service.
Copyright Compliance – protects software or other copyrighted materials developed.
Software Licensing – all software should be appropriately licensed by the Information
Technology Department.
121
Project Closure:
Required Project Documents
Business Requirements Document - At the project closure stage of a project the BRD should
be updated for all the clarifications raised through Action Log so that all the requirements are
available in a single document.
Issue Logs (Rails) – Checklist
Lessons Learnt - The learning gained from the process of performing the project. Lessons
Learnt can be identified at any point in the project. This can also include all the Best Practices
followed in the project apart from the learning gained.
Lessons Learned Report
Prepared by: Date:
Project Name:
Project Sponsor:
Project Manager:
Project Dates:
Final Budget:
1. Did the project meet scope, time, and cost goals?
2. What was the success criteria listed in the project scope statement?
3. Reflect on whether or not you met the project success criteria.
4. In terms of managing the project, what were the main lessons your team
learned?
5. Describe one example of what went right on this project.
6. Describe one example of what went wrong on this project.
7. What will you do differently on the next project based on your experience
working on this project?
122
Emails
Documentation
Update Configuration Management
All business, and Technical documents, along with email approvals should be copied to Project
archives. All relevant documentation not captured already under its specific category should be
uploaded to projects archives for safe store and for easy reference and retrieval. Users guides,
implementation plans, to do lists, new process forms, project plans, schedules, lists of contacts,
communication plan, Business Requirements, System Requirements, Functional Requirements and
Technical Requirements are all examples of documents to be uploaded to E-project at time of
project closeout if they have not been uploaded already.
Executive Summary – Optionally can be used for more complex or highly visible projects.
Maintenance Projects:
Customer's approval of project completion date estimates and resource hours estimates (if
applicable)
Customer's approval of the production turnover and project completion
Category 1 Projects
applicable)
Customer's approval of BRD
Category 2 Projects
applicable)
Customer's approval of BRD
Customer’s approval of project plan and schedule
Steering Committee approval of work request
Project Team's approval of Document Design
123
Project Reporting / Metrics:
Summary of Projects / Director Meetings:
Project Manager/ leads will be required to review their projects weekly with the department
Director/ Project Sponsor/ Project Director.
124
125

4 Up Status Report:
The four up status report is used to review project progress with our customers. project managers must use this type of report
progress on projects in our quarterly operations review.
126

127

Concluding note:
While testing can take considerable time and effort, that time will be well spent if serious problems and
issues are uncovered. Effective testing should be viewed as an essential project "insurance plan",
designed for many purposes, from technical problem resolution to proof of concept validation.
Through testing you may find that your technical solution works, but fails to fill the expected
operational need. As such, testing fills an overall role of project validation and quality assurance. And,
to realize these benefits, testing must be planned, coordinated and tailored to meet the needs of the
project at hand.
At the end of the day, software projects rarely succeed or fail on technical factors alone. However,
poor relationships, power struggles, and a lack of cooperation and teamwork can doom a project from
the very start. Since IT projects depend upon the quality of the IT/end-user partnership, it is wise to
treat end-user involvement as an essential element of the project process, and to organize
accordingly, even if it means some loss of "control". The ultimate goal of any project is the successful
delivery of required results. Any steps taken to increase the odds of success will benefit all concerned.
POME Prescribe:
About the relationship between Accountability, Empowerment, Ownership and Motivation
The buck stops here: You are accountable for your task / project. However, this does not mean that you do
not delegate. Delegate work to your team members, let them know that they are accountable for their
assignment/s, and ensure that they have the resources so that they can deliver successfully. Decide the plan
of action beforehand, and decide how follow-ups will happen.
Ownership: Have an attitude of owning your work.
Minimize your supervision - Provide a sense of autonomy. Freedom is a major motivator and builds trust on
both sides. (Tip: But don’t tune out completely.)
To motivate, you have to empower. Motivation involves not only being enthusiastic and pumped up about
approaching the task, but also involves being equipped with the tools and the ability to complete the
assignment. When you delegate an assignment, convey to the team member that it is now their exclusive
responsibility that the job gets done. If it doesn't, they will be held accountable.
Accountability of Self: Take a couple of co-workers into confidence about your expectations from yourself.
Besides making your goals clearer to yourself, this helps others keep track of your progress.
POME LIGHTER VEIN:
128
© 2007, POME, Gautam_Koppala, All Rights Reserved
129
WE CAME, WE SAW, WE
COGQUERED, AGD WE
RULE
130
POME INSPIRED
FROM……………..
131
POME Inspired From:
Central Form 23-A and EPA's Appendix C-2 clauses.
[Bruegge-Dutoit 2003], Chapter 11 Project Management
[IEEE Std 1058] Standard for Software Project Management Plans
21 Code of Federal Regulations, Parts 210-211 (Current Good Manufacturing Practice), US FDA,
Rockville, MD.
9000-1: 1994 Chapter for selection and use of applicable standards
9000-2: 1993 Chapter to the application of ISO 9001/2/3
9000-3: 1991 Chapterlines for the application of ISO 9001 to the development,
supply and maintenance of software
Ahuja, H.N. and W.J. Campbell, Estimating: From Concept to Completion, Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 1987.
Akkermans, H. (2001). Emergent Supply Networks: System Dynamics Simulation of Adaptive
Supply Agents. Proceedings of the 34th Hawaii International Conference on System Sciences.
Ales, M., A. Amin, S. Datar, and R. Sarkar. (2000). Information and Incentives of Inventory in
JIT Production. Management Science, 46:12.
Ang, A.H.S. and W.H. Tang, Probability Concepts in Engineering Planning and Design: Volume I
- Basic Principles, John Wiley and Sons, Inc., New York, 1975.
Arntzen, B. C., G. G. Brown, T. P. Harrison, and L. Trafton. Global Supply Chain Management at
Digital Equipment Corporation. Interfaces, Jan.-Feb., 1995.
132
ASCE Unveils Quality Manual"-- ENR, November 5, 1987, p. 14)
Au, T. and C. Hendrickson, "Education in Engineering Planning and Management," Proceedings
of the ASCE Conference on Civil Engineering Education, Columbus, Ohio, 1985.
Au, T. and P. Christiano, Structural Analysis, Prentice-Hall, Inc., Englewood Cliffs, NJ, 1987.
Au, T. and T. P. Au, Engineering Economics for Capital Investment Analysis, Allyn and Bacon,
Newton, MA, 1983.
Au, T. Introduction to Systems Engineering--Deterministic Models, Addison-Wesley, Reading,
MA, 1973, Chapter 8.
Au, T., "Profit Measures and Methods of Economic Analysis for Capital Project Selection," ASCE
Journal of Management in Engineering, Vol. 4, No. 3, 1988.
Au, T., R.L. Bostleman and E.W. Parti, "Construction Management Game-Deterministic Model,"
Asce Journal of the Construction Division, Vol. 95, 1969, pp. 25-38.
Au, T., R.M. Shane, and L.A. Hoel, Fundamentals of Systems Engineering: Probabilistic Models,
Addison-Wesley Publishing Co., Reading MA, 1972
Baganha, M.P., and M.A. Cohen. (1998). The Stabilizing Effect of Inventory in Supply Chains.
Operations Research, 46(3 Supp.), S72-S83.
Baker, K., An Introduction to Sequencing and Scheduling, John Wiley, 1974.
Ballou, R. H. 1992. Business Logistics Management, Prentice Hall, Englewood Cliffs, NJ, Third
Edition.
Bank of International Settlements:
http://www.bis.org/
Barrie, D.S. (editor), Directions in Managing Construction, John Wiley and Sons, New York,
1981.
Barrie, Donald S. and Boyd C. Paulson, Jr., Professional Construction Management, McGraw-Hill
Book Company, 2nd Ed., 1984.
Bell, D.R., T. Ho, and C. Tang. (1998). Rational Shopping Behavior and the Option Value of
Variable Pricing. Management Science, 44(12), S145-S160.
Bierman, H., Jr., and S. Smidt, The Capital Budgeting Decision, 5th Ed., Macmillan, New York,
1984.
133
Bonny, J.B. and J.P. Frein, Handbook of Construction Management and Organization, 2nd
Edition, Van Nostrand Reinhold Co., New York, 1980.
Bourdon, C.C., and R.W. Levitt, Union and Open Shop Construction, Lexington Books, D.C.
Heath and Co., Lexington, MA, 1980.
Bourland, K., S. Powell, and D. Pyke. (1996). Exploiting Timely Demand Information to Reduce
Inventories. European Journal of Operational Research, 92(2), 239-253.
Bowker, A.H. and Liebermann, G. J., Engineering Statistics, Prentice-Hall, 1972.
Bratley, Paul, Bennett L. Fox and Linus E. Schrage, A Guide to Simulation, Springer-Verlag,
1973.
Brealey, R. and S. Myers, Principles of Corporate Finance, Second Edition, McGraw-Hill, New
York, 1984.
Breitman, R. L., and J. M. Lucas. 1987. PLANETS: A Modeling System for Business Planning.
Interfaces, 17, Jan.-Feb., 94-106.
Building Research Advisory Board, Exploratory Study on Responsibility, Liability and
Accountability for Risks in Construction, National Academy of Sciences, Washington, D.C.,
1978.
Building Research Advisory Board, Exploratory Study on Responsibility, Liability and
Accountability for Risks in Construction, National Academy of Sciences, Washington, D.C.,
1978.
Bureau of Economic Analysis:
http://www.bea.doc.gov/bea/di1.htm
C.G. Field and S.R. Rivkin, The Building Code Burden, Lexington Books, D.C. Heath and Co.,
Lexington, MA, 1975.
Cachon, G.P. and M. Fisher. (2000). Supply Chain Inventory Management and the Value of
Shared Information. Management Science, 46(8), 1032-1048.
Caterpillar Performance Handbook, 18@+(th) Edition, Caterpillar, Inc., Peoria, IL, 1987.
Census Bureau: Foreign Trade Statistics:
http://www.census.gov/
http://www.census.gov/foreign-trade/www/
Clark, A.J. and H. Scarf. (1960). Optimal Policies for a Multi-Echelon Inventory Problem.
Management Science, 6(4), 475-490.
134
Clark, F.D., and A.B. Lorenzoni, Applied Cost Engineering, Marcel Dekker, Inc., New York, 1978.
Clark, J.E., Structural Concrete Cost Estimating, McGraw-Hill, Inc., New York, 1983.
Cohen, M. A. and H. L. Lee. 1985. Manufacturing Strategy Concepts and Methods, in
Kleindorfer, P. R. Ed., The Management of Productivity and Technology in Manufacturing, 153-
188.
Cohen, M. A. and H. L. Lee. 1988. Strategic Analysis of Integrated Production-Distribution
Systems: Models and Methods. Operations Research, 36, 2, 216-228.
Cohen, M. A. and H. L. Lee. 1989. Resource Deployment Analysis of Global Manufacturing and
Distribution Networks. Journal of Manufacturing and Operations Management, 81-104.
Commission of the European Communities: The Rules Governing Medicinal Products in the
European Community. Volume IV: Chapter to Good Manufacturing Practice for Medicinal
Products. III/2244/87, REV. 3, January 1989
Construction Industry Cost Effectiveness Project, "Contractual Arrangements," Report A-7, The
Business Roundtable, New York, October 1982.
Cooper, M. C., and L. M. Ellram. 1993. Characteristics of Supply Chain Management and the
Implications for Purchasing and Logistics Strategy. The International Journal of Logistics
Management, 4, 2, 13-24.
Copacino, W.C. (1997). Supply Chain Management: The Basics and Beyond, Falls Creek, VA:
St. Lucie Press.
Cordell, R.H., "Construction Productivity Management," Cost Engineering, Vol. 28, No. 2,
February 1986, pp. 14-23.
Definitions: http://www.sei.cmu.edu/str/indexes/glossary/
Deuermeyer, B. and L. B. Schwarz. 1981. A Model for the Analysis of System Service Level in
Warehouse/ Retailer Distribution Systems: The Identical Retailer Case, in: L. B. Schwarz (ed.),
Studies in Management Sciences, Vol. 16--Multi-Level Production / Inventory Control Systems,
North-Holland, Amsterdam, 163-193.
Diekmann, J.R., "Probabilistic Estimating: Mathematics and Applications," ASCE Journal of
Construction Engineering and Management, Vol. 109, 1983, pp. 297-308.
Drucker, P.F., Innovation and Entrepreneurship: Practice and Principles, Harper and Row, New
York, 1985.
135
Dudziak, W. and C. Hendrickson, "A Negotiating Simulation Game," ASCE Journal of
Management in Engineering, Vol. 4, No. 2, 1988.
E. D'Appolonia, "Coping with Uncertainty in Geotechnical Engineering and Construction,"
Special Proceedings of the 9th International Conference on Soil Mechanics and Foundation
Engineering, Tokyo, Japan, Vol. 4, 1979, pp. 1-18.
E. D'Appolonia, R. Alperstein and D.J. D'Appolonia, "Behavior of Colluvial Slope", ASCE Journal
of Soil Mechanics and Foundations Division, Vol. 93, No. SM4, 1967, pp. 447-473.
Edwards, W.C. and J.F. Wong, "A Computer Model to Estimate Capital and Operating Costs,"
Cost Engineering, Vol. 29, No. 10, 1987, pp. 15-21.
Elmaghraby, S.E., Activity Networks: Project Planning and Control by Network Models, John
Wiley, New York, 1977.
ETVX Model:
http://www.cs.cmu.edu/~jekim/study/JiEunKim_IndependentStudy_Project_Report.doc
European Union:
http://europa.eu.int/index_en.htm
F. Moavenzadeh, "Construction's High Technology Revolution," Technology Review, October,
1985, pp. 32-39.
Fan, M., J.Stallaert, and A.B. Whinston. (2003). Decentralized Mechanism Design for Supply
Chain Organizations Using an Auction Market. Information Systems Research, 14(1), 1-22.
FDA Chapterlines on General Principles of Process Validation, May 1987.
Federal Reserve Board: Flow of Funds Data:
http://www.federalreserve.gov/releases/Z1/Current/Coded/coded.pdf
Federal Reserve Board: Research and Data:
http://www.federalreserve.gov/rnd.htm
Food and Drug Administration (FDA): Chapter to Inspection of Computerized Systems in Drug
Processing. USA, 1983
For discussions of industrialized building, see Bender, Richard, A Crack in the Rear View Mirror -
A View of Industrialized Building, Von Nostrand Reinhold Co., 1983; Nutt-Powell, Thomas, E.,
Manufactured Homes: Making Sense of a Housing Opportunity, Auburn House, 1982; or
Warzawski, A., M. Avraham, and D. Carmel, "Utilization of Precast Concrete Elements in
136
Building," ASCE Journal of Construction Engineering and Management, Vol. 110, No. CO4,
1984, pp. 476-485.
For more information on Green Buildings see the LEED website:
http://www.usgbc.org/LEED/LEED_main.asp
Fox, A.J. and Cornell, H.A., (eds), Quality in the Constructed Project, American Society of Civil
Engineers, New York, 1984.
Fox, M.S., M. Barbuceanu, and R. Teigen. (2000). Agent-Oriented Supply-Chain Management.
The International Journal of Flexible Manufacturing Systems, 12, 165-188.
G-7 Home page:
http://www.g7-2001.org/en/frames_c.htm
Gaylord, E., and C. Gaylord (Editors), Structural Engineering Handbook, McGraw-Hill Book Co.,
New York, 1979.
General Agreement on Trade and Tariff (GATT):
http://gatt.org/
Geoffrion, A., and G. Graves. 1974. Multicommodity Distribution System Design by Benders
Decomposition. Management Science, 29, 5, 822-844.
Geoffrion, A., and R. Powers. 1993. 20 Years of strategic Distribution System Design: An
Evolutionary Perspective, Interfaces. (forthcoming)
Good Automated Manufacturing Practices Forum - GAMP Chapter for Validation of Automated
Systems in Pharmaceutical Manufacture version 3.0, 1998
Graham, P.H., "Owner Management of Risk in Construction Contracts," Current Practice in Cost
Estimating and Cost Control, Proceedings of an ASCE Conference, Austin, Texas, April 1983, pp.
207-215.
Green, E.D., "Getting Out of Court -- Private Resolution of Civil Disputes," Boston Bar Journal,
May-June 1986, pp. 11-20.
H. Cross, Engineers and Ivory Towers, McGraw-Hill Book Co., Inc., New York, 1952.
Halpin, Daniel W. and Ronald W. Woodhead, Construction Management, John Wiley and Sons,
1980.
Hasagawa, Fumio et.al., "Built by Japan," John Wiley & Sons, 1988.
137
Hendrickson, C. and T. Au, "Private versus Public End Usership of Constructed Facilities," ASCE
Journal of Management in Engineering, Vol. 1, No. 3, 1985, pp. 119-131.
Hendrickson, C., "Financing Civil Works with User Fees," Civil Engineering, Vol. 53, No. 2,
February 1983, pp. 71-72.
Hodgetts, R.M., Management: Theory, Process and Practice, W.B. Saunders Co., Philadelphia,
PA, 1979.
Hot New Market Lures A-E Players to Cutting Edges,--Engineering News-Record, April 4, 1985,
pp. 30-37.
Houlihan, J. B. 1985. International Supply Chain Management. International Journal of Physical
Distribution and Materials Management, 15, 1, 22-38.
http://www.sei.cmu.edu/str/indexes/glossary/
Humphreys, K.K. (ed.) Project and Cost Engineers' Handbook (sponsored by American
Association of Cost Engineers), 2nd Ed., Marcel Dekker, Inc., New York, 1984.
IBM’s Rational Unifed Process (RUP), from IBM
International Finance Corporation:
http://www.ifc.org/
International Monetary Fund:
http://www.imf.org/
International Organization for Standardization, "Sampling Procedures and Charts for Inspection
by Variables for Percent Defective, ISO 3951-1981 (E)", Statistical Methods, ISO Standard
Handbook 3, International Organization for Standardization, Paris, France, 1981.
o ISO 9000 Quality Management and Quality Assurance Standards
J. Landis, "Why Homebuilders Don't Innovate," Built Environment, Vol. 8, No. 1, 1982, pp. 46-
53.
J.E. Diekmann and K.B. Thrush, Project Control in Design Engineering, A Report to the
Construction Industry Institute, The University of Texas at Austin, Texas, May 1986.
Jackson, M.J., Computers in Construction Planning and Control, Allen & Unwin, London, 1986.
John Collins and Maria Gini. (2001). A Testbed for Multi-Agent Contracting for Supply-Chain
Formation. Workshop on Agent-Based Approaches to B2B, May.
138
Kerzner, H. Project Management: A Systems Approach to Planning, Scheduling and Controlling.
2nd. Ed., Van Nostrand Reinhold, New York, 1984.
L. C. Stuckenbruck, "Project Management Framework," Project Management Journal, Vol. 17,
No. 3, August 1986, pp. 25-30.
Lang, J.E. and D.Q. Mills, The Construction Industry, Lexington Books, Lexington, MA, 1979.
Lange, J.E., and D.Q. Mills, The Construction Industry, Lexington Books, D.C. Heath and Co.,
Lexington, MA, 1979.
Lean Construction Institute, http://www.leanconstruction.org/
Lee, H. L., and C. Billington. 1992. Supply Chain Management: Pitfalls and Opportunities. Sloan
Management Review, 33, Spring, 65-73.
Lee, H. L., and C. Billington. 1993. Material Management in Decentralized Supply Chains.
Operations Research, 41, 5, 835-847.
Levitt, R.E., R.D. Logcher and N.H. Quaddumi, "Impact of Owner-Engineer Risk Sharing on
Design Conservatism," ASCE Journal of Professional Issues in Engineering, Vol. 110, 1984, pp.
157-167.
Levitt, R.E., R.D. Logcher and N.H. Quaddumi, "Impact of Owner-Engineer Risk Sharing on
Design Conservatism," ASCE Journal of Professional Issues in Engineering, Vol. 110, 1984, pp.
157-167.
Linnhoff, B., D.W. Townsend, D. Boland, G.F. Hewitt, B.E.A. Thomas, A.R. Guy, and R.H.
Marsland, User Guide on Process Integration for the Efficient Use of Energy, Institution of
Chemical Engineers, Rugby, Warks., England, 1982.
Maevis, A.C., "Construction Cost Control by the End Users," ASCE Journal of the Construction
Division, Vol. 106, 1980, pp. 435-446.
Management Thoughts For the Family in Business, by Pramod Batra, Vijay Batra
Masters, J. M. 1993. Determination of Near-Optimal Stock Levels for Multi-Echelon Distribution
Inventories. Journal of Business Logistics, 14, 2, 165-195.
Microsoft Solution Framework, from Microsoft
Moder, J., C. Phillips and E. Davis, Project Management with CPM, PERT and Precedence
Diagramming, Van Nostrand Reinhold Company, Third Edition,1983.
139
Moolin, F.P., Jr., and F.A. McCoy: "Managing the Alaska Pipeline Project," Civil Engineering,
November 1981, pp. 51-54.
More Construction for the Money,-- Summary Report of the Construction Industry Cost
Effectiveness Project, The Business Roundtable, New York, 1983, pg. 30.
Murray, L., E. Gallardo, S. Aggarwal and R. Waywitka, "Marketing Construction Management
Services," ASCE Journal of Construction Division, Vol. 107, 1981, pp. 665-677.
NAMUR recommendation NE-72 - Validation Support by Use of Control Systems
North American Free Trade Agreement (NAFTA):
http://www.nafta-sec-alena.org/
Nunnally, S.W., Construction Methods and Management, Prentice-Hall, Englewoood Cliffs, NJ,
2nd Ed., 1987.
O'Connor, J.T., and Vickory, C.G., Control of Construction Project Scope, A Report to the
Construction Industry Institute, The University of Texas at Austin, December 1985.
OECD National Accounts:
http://www.oecd.org/std/nahome.htm
P.J. Cassimates, Economics of the Construction Industry, National Industry Conference Board
(SBE No. 111), 1969.
Park, William R., The Strategy of Contracting for Profit, 2nd Edition, Prentice-Hall, Englewood
Cliffs, NJ, 1986.
PDRI for Building Projects Research Team, PDRI: Project Definition Rating Index for Building
Projects, Construction Industry Institute, Resource 155-2, July 1999.
Petzinger, Thomas Jr., "Upstart's Winning Bid for Offshore Platform Stuns its Older Rivals,"
Wall Street Journal, p. 1, c. 6, Nov. 20, 1985.
Peurifoy, R.L., Construction Planning, Equipment and Methods, 2nd Edition, McGraw-Hill, New
York, 1970.
PMA+, Siemens corporate method project management book
PMBOK, PMI
Pre-Project Planning Research Team, Pre-Project Planning Handbook Construction Industry
Institute, Publication 39-2, April 1995.
Prince2
140
Private Money Finances Texas Utility's Power Plant--Engineering News Record: July 25, 1985, p.
13.
Project Agency- a product of the SALTO-YOUTH UK Project Management training programme
Project Management for Construction, Fundamental Concepts for Owners, Engineers, Architects
and Builders, by Chris Hendrickson, Department of Civil and Environmental Engineering,
Carnegie Mellon University,
Project Management Institute, A Guide to the Project Management Body of Knowledge,
Newtown Square, Pennsylvania, 2000.
Quality System Standards-Chapterlines
R. Kehoe and A Jarvis, ISO 9000-3 A tool for Software Product and Process Improvement,
ISBN 0-387-94568-7, Springer-Verlag New York, 1996.Refernces:
R. M. Wideman, "The PMBOK Report -- PMI Body of Knowledge Standard," Project Management
Journal, Vol. 17, No. 3, August l986, pp. l5-24.
R.W. Jensen and C.C. Tonies (Editors), Software Engineering, Prentice-Hall, Inc., Englewood
Cliffs, NJ, 1979, p. 22.
Raiffa, Howard, The Art and Science of Negotiation, Harvard University Press, Cambridge, MA,
1982.
Rehak, Daniel R. and L.A. Lopez, Computer Aided Engineering Problems and Prospects, Dept.
of Civil Engineering, University of Illinois, 1981.
S.J. Fenves, "Computer Applications," in Structural Engineering Handbook, (Gaylord, E. and C.
Gaylord, Editors), McGraw-Hill Book Co., New York, NY, 1979.
Schwarz, L. B. 1981. Introduction in: L. B. Schwarz (ed.), Studies in Management Sciences,
Vol. 16--Multi-Level Production / Inventory Control Systems, North-Holland, Amsterdam, 163-
193.
Sections of the GAMP Guide for Validation of Automated Systems in Pharmaceutical
Manufacture – Version 3.0 (GAMP 3), Volume 1: User Guide, and Volume 2: Supplier Guide
have been reproduced in this guide with permission from ISPE.
Simon, H.A., The Science of the Artificial, Second Edition, MIT Press, Cambridge, MA, 1981.
Skibniewski, M. and Hendrickson, C., Methods to Improve the Safety Performance of the U.S.
Construction Industry, Technical Report, Department of Civil Engineering, Carnegie Mellon
University, 1983.
141
Stanley E Portny, Project Management for Dummies, Hungry Minds, 2001, ISBN 0-7645-
5283-X
Stenross, F. M., and G. J. Sweet. 1991. Implementing an Integrated Supply Chain in Annual
Conference Proceedings, Oak Brook, Ill: Council of Logistics Management, Vol. 2, 341-351.
T. Au, E.W. Parti and A.K.C. Wong, "Computer Applications for Health Care Facility Design,"
Computers in Biology and Medicine, Vol. 1, No. 4, 1971, pp. 299-316.
T.Y. Lin and B.G. Gerwick, Jr. "Design of Long Span Concrete Bridges with Special References
to Prestressing, Precasting, Structural Behavior and Economics," ACI Publication SP-23, First
International Symposium, 1969, pp. 693-704
Tatum, C.B., "Innovation on the Construction Project: A Process View," Project Management
Journal, Vol. 18, No. 5, 1987, pp. 57-67.
Tersine, R.J., Principles of Inventory and Materials Management, North Holland, New York,
1982.
The authors are indebted to E. D'Appolonia for suggesting this example.
The Business Roundtable, More Construction for the Money, Summary Report of the
Construction Industry Cost Effectiveness Project, January 1983, p. 11.
The graph is derived from data in "Value of New Construction Put in Place, 1960-1983",
Statistical Abstract of the United States, 105th Edition, U.S. Department of Commerce, Bureau
of Census, 1985, pp. 722-723, as well as the information in earlier editions.
The material in this example is adapted from A.L. Tolman, A. P. Ballestero, W.W. Beck, G.H.
Emrich, "Guidance Manual for Minimizing Pollution from Waste Disposal Sites," Report to the
Municipal Environmental Research Laboratory, U.S. Environmental Protection Agency, EPA-
600/2-78-142, August 1978.
The Quiet Revolution in Skyscraper Design, --Civil Engineering, May 1983, pp. 54-59.
These features and the following example are described in F.P. Moolin, Jr. and F.A. McCoy,
"Managing the Alaska Pipeline Project," Civil Engineering, November 1981, pp. 51-54.
Treasury: Capital Movements Bulletin:
http://www.fms.treas.gov/bulletin/b21.pdf
U.S. Department of Commerce: Export Portal:
http://www.export.gov/docTSFrameset.html
142
United States Department of Defense, Sampling Procedures and Tables for Inspection by
Variables, (Military Standard 414), Washington D.C.: U.S. Government Printing Office, 1957.
United States Department of Defense, Sampling Procedures and Tables for Inspection by
Attributes, (Military Standard 105D), Washington D.C.: U.S. Government Printing Office, 1963.
V. Fairweather, "Milan's Model Metro", Civil Engineering, December 1987, pp. 40-43.
Vollman, T. E., W. L. Berry, and D. C. Whybark. 1992. Manufacturing Planning and Control
Systems, Irwin, Homewood, IL.
Walker, N., E.N. Walker and T.K. Rohdenburg, Legal Pitfalls in Architecture, Engineering and
Building Construction, 2nd Edition, McGraw-Hill Book Co., New York, 1979.
White House: Economic Statistics Briefing Room:
http://www.whitehouse.gov/fsbr/international.html
Willis, E. M., Scheduling Construction Projects, John Wiley & Sons, 1986.
Wohl, M. and C. Hendrickson, Transportation Investment and Pricing Principles, John Wiley &
Sons, New York, 1984.
World Bank:
http://www.worldbank.org/
http://www1.worldbank.org/wbiep/trade/services_data.htm#Flows
World Trade Organization:
http://www.wto.org/
http://www.wto.org/english/res_e/statis_e/technotes_e.htm
“After you’ve worked hard to get hwat you want, find the time to enjoy it.”
143
Any Questions?
Comments? For
better
improvement
Contact:
georgegautam@gmail.com
00918912550564
144
145
Heated gold becomes ornament. Beaten copper becomes
wires. Depleted
stone becomes statue. So the more pain you get in life you
become more valuable.
But year's later collection of

mistakes is called experience,
which leads to success.
146
ing
tion
Permits
8/27/94
3
9/17/94
Legend
8/29/94
10/1/94
10/15/94
11/5/94
20
12/3/94
12/17/94
10
12/21/94
12/31/94
8
1/11/95
1/12/95
5
9
12
18
1/22/95
11
2/8/95
7
1/19/95
6
15
2/16/95
0
Lay
START
Request
Survey
Excava
Buy
Material
Founda
Build
Outside
Wall
Plumbing
Electrical
Siding
Wallboard
Roofing
Flooring
Paint
Interior
Install
Exterior
Doors
FINISH
Less
Greater
APPROVE
REJECT than
than
2.5%
-DEFER Develop
Determine
Brainstorm
Write
Establish
<<Name>>
Planning
Analysis
Design Design
•Project
A
Functio
Assets
Debt
Equity
Functi
Activit
Debt-
Shareh
Manag
Board
Task
Project
Activity
Project
Task
Each
Corpor
draft
Layou
Forec Implement
Document
[Approval
Complete
Potential
Change
Project
Notify
Select
The
Project
Net
Figure
Large
Small
Prepar
Current
Long-
Major
Curren
Long-
Fixed
Faciliti
Capac
Techn
Produ
Proce
Work
Phas
WBS
Dire
Wor
The To 1
The
Proj
Act
schedule
2.5%
Models
WBS
on
guidelines
Goals
Controll
Impleme
Plannin
Decidin
Team
Less
increase
n
holders
olders
ement
of
enough
ate
Consist
Culmin
unit
schedule
Defining
Activity
has Working
Smallest
on
y
-domain a
than
Determine
Formulate
Write
Liabilit
Curren
Shareh
Assets
Termrepo
increase
application
Initiation
Reason
Threshold
Decision
Manager
Trigger
Project
Body]
Change
activity 5%
code
of
etthan
for
tal
thas
asting
ing/
nting/
-g es
ct
ologic
schedule
Greater
Desig
Evaluates
/Wor
Hardware ity
ss
and
e
Participants
Event
Request
Determined
Identified
Rejection
Review
Point
„Buy
Net
ct
dependencies
objects
requirements
k
a
Present
duration
Capital
reduction
schedule
-Director
to
for
unit avoid of
5%
or
Bala
ect Request/
Date
of
Govern
problems
between
with Aims
form
Debt
sSoftware rt
ies
Develop
Execeut
Report
Delivery
reduction to
Decision
client
Material“
ates
work of
olders’
Liabili
Debt
Re-
Pr
tasks
into
---------------------
1ttime
ivit start
and
sSelecti
Planni
Servic
Equip
coach
Esti
-class
mapping
al
n
Assign
Establish
diagram
teams
---------------------
Finalizes
Work
micro
adequat
work
Pack
ing
and
2.0Lab
ance
visit
k
mustanCONFRONTING
oj
147

Marketing Ans Sales From POME by Gautam Koppala VT

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Marketing Ans Sales From POME by Gautam Koppala VT

Transféré par

Droits d'auteur :

Formats disponibles

1

Kanaka maha lakshmi

Be bold when you loose and be calm when you

"Changing the Face" can change nothing.

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

But year's later collection of

Vous aimerez peut-être aussi