REPORT ON PROJECT MANAGEMENT

7/29/2019 REPORT ON PROJECT MANAGEMENT

http://slidepdf.com/reader/full/report-on-project-management 1/21

CASE STUDY REPORT

ON

PROJECT MANAGEMENT



INDEX

Sr. No. Topic Name

1. Conventional Software Management

Conventional Software Management Performance

Evolution of Software Economics

2. Principles of Modern Software Management

Artifacts of The Process

3. Workflow of The Process

Iterative Process Planning

4. Project Organizations & Responsibilities

Line of Business Organizations

Project Organizations

Process Automation

5.Project Control & Process Instrumentation

Seven Core Metrics of Software Project

Metrics Automation

Tailoring The Process

6.Future Software project management

Modern Project profiles

Next generations Software Economics



I. Conventional software managementConventional software management practices are sound in theory, but

practice is still tied to archaic technology and techniques. Conventionalsoftware economics provides a benchmark of performance for conventionalsoftware management principles.

Three important analyses of the state of the software engineering industry are

1. Software development is still highly unpredictable. Only about 10% of software projects are delivered successfully within initial budget andschedule estimates.

2. Management discipline is more of a discriminator in success or failurethan are technology advances.

3. The level of software scrap and rework is indicative of an immature process.

THE WATERFALL MODEL

Most software engineering texts present the waterfall model as the source of the "conventional" software process.

Fig. Waterfall Model

Five necessary improvements for waterfall model are:-

1. Program design comes first: Insert a preliminary program design phase

between the software requirements generation phase and the analysis



phase.Begin the design process with program designers, not analysts or pro-grammers.

2. Document the design: The amount of documentation required on most

software programs is quite a lot, certainly much more than most programmers,analysts, or program designers are willing to do if left to their own devices.

3. Do it twice:If a computer program is being developed for the first time,arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as criticaldesign/operations are concerned.

4. Plan, control, and monitor testing: Without question, the biggest user of

project resources-manpower, computer time, and/or management judgment-isthe test phase. This is the phase of greatest risk in terms of cost and schedule.

5. Involve the customer: For some reason, what a software design is going todo is subject to wide interpretation, even after previous agreement. It isimportant to involve the customer in a formal way so that he has committedhimself at earlier points before final delivery.

It is useful to summarize the characteristics of the conventional process as ithas typically been applied, which is not necessarily as it was intended. Projects

destined for trouble frequently exhibit the following symptoms: Protracted integration and late design breakage

Late risk resolution

Requirements-driven functional decomposition

Adversarial(conflict or opposition) stakeholder relationships

Focus on documents and review meetings

1.1CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE:

Barry Boehm's "Industrial Software Metrics Top 10 List” is a good,

objective characterization of the state of software development.1. Finding and fixing a software problem after delivery costs 100 times more

than finding and fixing the problem in early design phases2. You can compress software development schedules 25% of nominal,

but no more.3. For every $1 you spend on development, you will spend $2 on maintenance4. Software development and maintenance costs are primarily a function

of the number of source lines of code



5. Variations among people account for the biggest differences in software productivity

6. The overall ratio of software to hardware costs is still growing. In 1955 itwas 15:85; in 1985, 85:15.

7. Only about 15% of software development effort is devoted to programming.8. Software systems and products typically cost 3 times as much per

SLOC as individual software programs. Software-system products(i.e., system of systems) cost 9 times as much.

9. Walkthroughs catch 60% of the errors

10. 80% of the contribution comes from 20% of the contributors.

1.2 EVOLUTION OF SOFTWARE ECONOMICS

1.2.1SOFTWARE ECONOMICS:

Most software cost models can be abstracted into a function of five basic parameters: size, process, personnel, environment, and required quality.

1. The size of the end product (in human-generated components), whichis typically quantified in terms of the number of source instructions or the number of function points required to develop the requiredfunctionality.

2. The processused to produce the end product, in particular the ability of

the process to avoid non-value-adding activities. (rework, bureaucraticdelays, communications overhead)

3. The capabilities of software engineering personnel ,and particularlytheir experience with the computer science issues and the applicationsdomain issues of the project.

4. The environment , which is made up of the tools and techniquesavailable to support efficient software development and to automate the

process.

5. The required qualityof the product, including its features, performance,reliability, and adaptability.

The relationships among these parameters and the estimated cost can bewritten as follows:

Effort = (Personnel) (Environment)( Quality)( Sizeprocess

)

The three generations of software development are defined as follows:



1) Conventional:1960s and 1970s, craftsmanship. Organizations used cus-tom tools, custom processes, and virtually all custom components builtin primitive languages. Project performance was highly predictable inthat cost, schedule, and quality objectives were almost alwaysunderachieved.

2) Transition: 1980s and 1990s, software engineering. Organiz:1tions usedmore-repeatable processes and off-the-shelf tools, and mostly (>70%) cus-tom components built in higher level languages. Some of the components(<30%) were available as commercial products, including the operatingsystem, database management system, networking, and graphical user interface.

3) Modern practices: 2000 and later, software production. This book's philosophy is rooted in the use of managed and measured processes,integrated automation environments, and mostly (70%) off-the-shelf components. Perhaps as few as 30% of the components need to becustom built Technologies for environment automation, size reduction,and process improvement are not independent of one another.

1.2.2 PRAGMATIC SOFTWARE COST ESTIMATION:

One critical problem in software cost estimation is a lack of well-documented case studies of projects that used an iterative developmentapproach.

Software industry has inconsistently defined metrics or atomic unitsof measure, the data from actual projects are highly suspect in terms of consistency and comparability.

There are several popular cost estimation models (such as COCOMO,

CHECKPOINT, ESTIMACS, KnowledgePlan, Price-S, ProQMS, SEER,

SLIM, SOFTCOST, and SPQR/20), CO COMO is also one of the most open

and well-documented cost estimation models. The general accuracy of

conventional cost models (such as COCOMO) has been described as "within

20% of actuals, 70% of the time."

A good software cost estimate has the following attributes:

It is conceived and supported by the project manager, architecture team,development team, and test team accountable for performing the work.

It is accepted by all stakeholders as ambitious but realizable.

It is based on a well-defined software cost model with a credible basis.

It is based on a database of relevant project experience that includessimilar processes, similar technologies, similar environments, similar quality requirements, and similar people.



II.Principles of Modern Software Management:

Royce Walker describes tens principles of modern softwaremanagement ([Royce, Walker 1998]). The principles are in priority order:

1. Base the process on anarchitecture-first approach: This requires that ademonstrable balance be achieved among the driving requirements, the

architecturally significant design decisions, and the life-cycle plans beforethe resources are committed for full-scale development.

2. Establish an iterative life-cycle process that confronts risk early: Withtoday’s sophisticated software systems, it is not possible to define the

entire problem, design the entire solution, built the software, then test theend product in sequence.

3. Transition design methods to emphasize component-based

development: Moving from a line-of-code mentality to a component-basedmentality is necessary to reduce the amount of human-generated sourcecode and custom development.

4. Establish a change management environment: The dynamics of iterativedevelopment, including concurrent workflows by different teams workingon shared artifacts, necessitates objectively controlled baselines.

5. Enhance change freedom through tools that support round-tripengineering:Round-trip engineering is the environment support necessaryto automate and synchronize engineering information in different formats(such as requirements specifications, design models, source code,executable code, test cases).

6. Capture design artifacts in rigorous, model-based notation: A model- based approach (such as UML) supports the evolution of semantically richgraphical and textual design notations.



7. Instrument the process for objective quality control and progress

assessment:Life-cycle assessment of the progress and the quality of allintermediate products must be integrated into the process.

8. Use a demonstration-based approach to assess intermediate artifacts: Transitioning the current state-of-the-product artifacts (whether theartifact is an early prototype, a baseline architecture, or a beta capability)into an executable demonstration of relevant scenarios stimulates earlier convergence on integration, a more tangible understanding of designtradeoffs, and earlier elimilation of architectural defects.

9. Plan intermediate releases in groups of usage scenarios with envolvinglevels of detail: It is essential that the software management process drivetoward early and continuous demonstrations within the operationalcontext of the system, namely its use cases.

10. Establish a configurable process that is economically scalable: Nosingle process is suitable for all software developments. A pragmatic

process framework must be configurable to a broad spectrum of applications.

2.1 Artifacts of the Process

Each Rational Unified Process activity has associated artifacts, either required as an input or generated as an output. Some artifacts are used to directinput to subsequent activities, kept as reference resources on the project, or generated in a format as contractual deliverables.

Models:

Models are the most important kind of artifact in the Rational UnifiedProcess. A model is a simplification of reality, created to better understand thesystem being created. In the Rational Unified Process, there are a number of models that collectively cover all the important decisions that go intovisualizing, specifying, constructing, and documenting a software-intensivesystem.

1. Business use casemodel

Establishes an abstraction of the organization

2. Business analysismodel Establishes the context of the system



1. Business use casemodel

Establishes an abstraction of the organization

3. Use case model Establishes the system's functional requirements

4. Analysis model(optional)

Establishes a conceptual design

5. Design model Establishes the vocabulary of the problem and its solution

6. Data model(optional)

Establishes the representation of data for databases andother repositories

7. Deploymentmodel

Establishes the hardware topology on which the system isexecuted as well as the systems concurrency andsynchronization mechanisms

8. Implementationmodel

Establishes the parts used to assemble and release the physical system

Other Artifacts:

The Rational Unified Process's artifacts are categorized as either management artifacts or technical artifacts. The Rational Unified Process'stechnical artifacts may be divided into four main sets.

1. Requirements set: Describes what the system must do

2. Analysis and designset:

Describes how the system is to be constructed

3. Test set: Describes the approach by which the system isvalidated and verified

4. Implementation set: Describes the assembly of developed softwarecomponents

5. Deployment set: Provides all the data for the deliverable configuration

Requirements Set: This set groups all information describing what the systemmust do. This may comprise a use case model, a nonfunctional requirementsmodel, a domain model, an analysis model, and other forms of expression of theuser's needs, including but not limited to mock-ups, interface prototypes,regulatory constraints, and so on.

Design Set: This set groups information describing how the system is to beconstructed and captures decisions about how the system is to be built, taking



into account all the constraints of time, budget, legacy, reuse, quality objectives,and so forth. This may comprise a design model, a test model, and other formsof expression of the system's nature, including but not limited to prototypes andexecutable architectures.

Test Set: This set group’s information about testing the system, includingscripts, test cases, defect-tracking metrics, and acceptance criteria.

Implementation Set: This set groups all information about the elements of thesoftware that comprises the system, including but not limited to source code invarious programming languages, configuration files, data files, softwarecomponents, and so on, together with the information describing how toassemble the system.

Deployment Set:This set groups all information about the way the software isactually packaged, shipped, installed, and run on the target environment.

Fig.Major artifacts of the Rational Unified Process and the information flow between them.



III. Work Flows of the Process

Main Workflow Techniques:

Based on the method used for process modelling, Workflow ManagementSystems are divided into three main categories, as follows:

· Communication-based techniques: Which reduce every action in a workflowof four phases based oncommunication between a customer and a performer;

preparation; negotiation; performance andacceptance.

· Activity-based techniques: Which focus on modelling the tasks involved in a process and theirdependencies.

· Hybrid techniques: This can be considered as a combination of thecommunication-based and the activity-based techniques.

3.1 Iterative Process Planning:

Like software,a plan is an intangible piece of intellectualproperty towhich all the same concepts mustbe applied. Plans have an engineering stage,during which the plan is developed, and a production stage, when the plan isexecuted.

3.1.1 WORKBREAKDOWN STRUCTURES:A good work breakdown structure and its synchronization with the processframework are critical factors in software project success.

A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks. A WBS provides the following information

structure:• A delineation of all significant work .• A clear task decomposition for assignment ofresponsibilities.• A framework for scheduling, budgeting, and expenditure tracking.

3.1.2 PLANNING GUIDELINES:

Software projects span a broad range of application domains. It isvaluable but riskyto make specific planning recommendations independent of

project context.

3.1.3 THE COST AND SCHEDULE ESTIMATING PROCESS:



It starts with an understanding of the general requirements andconstraints,derives a macro-level budget and schedule, then decomposes these elementsintolower level budgets and intermediate milestones.

From this perspective, thefollowing planning sequence would occur:1. The software project manager (and others) develops a characterization of the overall size, process, environment, people, and quality required for the

project.2. A macro-level estimate of the total effort and schedule is developed using asoftware cost estimation model.3. The software project manager partitions the estimate for the effort into atop-level WBS using guidelines. The project manager also partitions theschedule into major milestone dates and partitions the effort into a staffing

profile using guidelines.4. At this point, subproject managers are given the responsibility for decomposing each of the WBS elements into lower levels using their top-levelallocation, staffing profile, and major milestone dates as constraints.

3.1.4 THEITERATION PLANNING PROCESS:

Planning the content and schedule of themajor milestones and their intermediate iterations is probably the most tangible formof the overall risk management plan. Iteration is used to mean a complete synchronizationacrossthe project, with a well-orchestrated global assessment of the entire

projectbaseline.

Inception iterations: The early prototyping activities integrate the foundationcomponents of a candidate architecture and provide an executable framework for elaborating the critical use cases of the system.Elaboration iterations: These iterations result in architecture, includinga complete framework and infrastructure for execution.Construction iterations: Most projects require at least two major constructionsiterations: an alpha release and a beta release.

Transition iterations: Most projects use a single iteration to transition a beta release into the final product.

3.1.5 PRAGMATIC PLANNING:

Even though good planning is more dynamic in an iterative process,doing it accurately is far easier. While executing iteration N of any phase, thesoftware project manager must be monitoring and controlling against a plan thatwas initiated in iteration N – 1 and must be planning iteration N + 1.

The art of good project managementis to make trade-offs in the current

iteration plan and the next iteration plan based onobjective results in the currentiteration and previous iterations.



IV. Project Organizations and Responsibilities

Software lines of business and project teams have different motivations.Software lines of business are motivated by return on investment, new businessdiscriminators, market diversification, and profitability.

4.1 Line of Business Organizations:

The main features of the default organization are as follows:Responsibility for process definition and maintenance is specific to a cohesive

line of business, where process commonality makes sense.

Responsibility for process automation is an organizational role and is equal inimportance to the process definition role.

Organizational roles may be fulfilled by a single individual or severaldifferent teams, depending on the scale of the organization.

Business Organization:

The Organization Manager has four managers reporting to them (SEPA,PRA, SEEA, and the Infrastructure Manager), along with some number of

project managers.

1. Software Engineering Process Authority (SEPA):

The SEPA is a necessary role in any organization. The SEPA could be a singleindividual like the general manager or a team of representatives.

2. Project Review Authority (PRA):

PRA is the single individual responsible for ensuring that a

software project compiles with all organizational and business unit software policies, practices and standards.

3. Software Engineering Environment Authority (SEEA):

SEEA is the person or group responsible for automating theorganization's process, maintaining the organization's standard environment,training project teams to use the environment and maintaining organization-wide reusable assets.

4. Infrastructure:



The components of the organizational infrastructure include projectadministration, engineering skill centers and professional development. Projectadministration includes timeaccounting system, contracts, pricing, terms andconditions.

4.2 PROJECT ORGANIZATIONS:The main features of default organization are

The project management team is an active participant, responsible for producing as well as managing the plan.

The architecture team is responsible for real artifacts and for the integrationof components.

The development team is responsible for component construction andmaintenance activities.

The assessment team is separate from development.

4.3 PROCESS AUTOMATION:

Automation means the loss of many organization jobs. Automation needsgrowthdepending on the scale of the effort. Process automation is critical to aniterative process.

There are many tools available to automate the software development process. The mapping of the software development tools to the processworkflows is shown below:

Workflows Environment tools and process automation

1. Management Workflow automation, metrics automation

2. Environment Change management, document automation

3. Requirementsmanagement

4. Designvisualmodelling

5. Implementation Editor-compiler-debugger

6. Assessment Test automation, defect tracking

7. Deployment Defect tracking



V. Project Control & Process InstrumentationSoftware Metrics:

Software metrics are used to implement the activities and products of thesoftwaredevelopment process. Hence, the quality of the software products andthe achievements in thedevelopment process can be determined using thesoftware metrics.

Need for Software Metrics:

1. Software metrics are needed for calculating the cost and schedule of asoftware productwith great accuracy.2. Software metrics are required for making an accurate estimation of the

progress.3. The metrics are also required for understanding the quality of the software

product.

Indicators:An indicator is a metric or a group of metrics that provides an

understanding of thesoftware process or software product or a software project. Two types of indicators are:(i) Management indicators.(ii) Quality indicators.

5.1 Seven Core Metrics of Software Project:

Software metrics instrument the activities and products of the softwaredevelopment/integration process. Metrics values provide an important

perspective for managingthe process.

Seven core metrics related to project control:

Management Indicators

Work and ProgressBudgeted cost and expendituresStaffing and team dynamicsChange traffic and stabilityBreakage and modularityRework and adaptabilityMean time between failures (MTBF) and maturity



1. Work and progress:

This metric measure the work performed over time. Work is the effort to beaccomplished to complete a certain set of tasks. The default perspectives of this metric are:

Software architecture team: - Use cases demonstrated.Software development team: - SLOC under baseline change management,SCOs closedSoftware assessment team: - SCOs opened, test hours executed and evaluationcriteria meet.Software management team: - milestones completed.

2. Budgeted cost and expenditures:

This metric measures cost incurred over time. Budgeted cost is the planned expenditureprofile over the life cycle of the project.

3. Staffing and team dynamics:This metric measure the personnel changes over time, which involves

staffing additionsand reductions over time.

4. Change traffic and stability:This metric measures the change traffic over time. The number of

software change ordersopened and closed over the life cycle is called changetraffic.

5. Breakage and modularity:

This metric measures the average breakage per change over time.Breakage is defined asthe average extent of change, which is the amount of software baseline that needs rework andmeasured in source lines of code,function points, components, subsystems, files or other units.

6. Rework and adaptability:This metric measures the average rework per change over time. Rework

is defined as theaverage cost of change which is the effort to analyze, resolveand retest all changes to softwarebaselines.

7. MTBF and Maturity:

This metric measures defect rater over time. MTBF (Mean Time BetweenFailures) is theaverage usage time between software faults.

5.2 METRICS AUTOMATION:Many opportunities are available to automate the project control activities

of a softwareproject. A Software Project Control Panel (SPCP) is essential for managing against a plan. Thispanel integrates data from multiple sources to



show the current status of some aspect of theproject. The panel can supportstandard features and provide extensive capability for detailedsituation analysis.SPCP is one example of metrics automation approach that collects,organizesand reports values and trends extracted directly from the evolving

engineering artifacts.

SPCP:

To implement a complete SPCP, the following are necessary.Metrics primitives - trends, comparisons and progressionsA graphical user interface.Metrics collection agentsMetrics data management server Metrics definitions - actual metrics presentations for requirements progress,

implementation progress, assessment progress, design progress and other progressdimensions.

Actors - monitor and administrator.

5.3 TAILORING THE PROCESS:In tailoring the management process to a specific domain or project, there

are two dimensions of discriminating factors: technical complexity andmanagement complexity.Aprocess framework is not a project-specific process implementation with a

well-defined recipefor success. The process discriminants are organized aroundsix process parameters - scale,stakeholder cohesion, process flexibility, processmaturity, architectural risk and domainexperience.

1. Scale:

The scale of the project is the team size which drives the processconfiguration more than any other factor. There are many ways to measurescale, including number of sources lines of code, number of function points,number of use cases and number of dollars. The primary measure of scale is the

size of the team. Five people are an optimal size for an engineering team.

2. Stakeholder Cohesion or Contention:

The degree of cooperation and coordination among stakeholders (buyers,developers, users, subcontractors and maintainers) significantly drives thespecifics of how a process is defined. This process parameter ranges fromcohesive to adversarial. Cohesive teams have common goals, complementaryskills and close communications.

3. Process Flexibility or Rigor:



The implementation of the project's process depends on the degree of rigor, formality and change freedom evolved from projects contract (visiondocument, business case and development plan).

4. Process Maturity:The process maturity level of the development organization is the key

driver of management complexity. Managing a mature process is very simpler than managing animmature process. Organization with a mature process have ahigh level of precedent experience in developing software and a high level of existing process collateral that enables predictable

planning and execution of the process.

5. Architectural Risk:

The degree of technical feasibility is an important dimension of defininga specific projects process. There are many sources of architecture risk. Theyare (1) systemperformance which includes resource utilization, response time,throughout and accuracy, (2)robustness to change which includes addition of new features & incorporation of new technologyand (3) system reliability whichincludes predictable behaviour and fault tolerance.

6. Domain Experience:The development organization's domain experience governs its ability to

converge on an acceptable architecture in a minimum no of iterations.



VI. Future SoftwareProject Management:

6.1Modern Project Profiles:

Continuous Integration Early Risk Resolution Evolutionary Requirements Teamwork Among Stakeholders

Top 10 Software Management Principles Software Management Best Practices

1. Continuous Integration:The continuous integration inherent in an iterative development

process enables better insight into quality trade-offs.Systemcharacteristics that are largely inherent in the architecture (performance,fault tolerance, maintainability) are tangible earlier in the process, when

issues are still correctable.

2.Early Risk Resolution:Conventional projects usually do the easy stuff first,modern

process attacks the important 20% of the requirements, use cases,components, and risks.The effect of the overall life-cycle philosophy onthe 80/20 lessons provides a useful risk management perspective.

3.Evolutionary Requirements:Conventional approaches decomposed system requirementsinto

subsystem requirements, subsystem requirements intocomponentrequirements, and component requirements intounit requirements.

4. TeamworkAmong Stakeholders:Many aspects of the classic development process cause stakeholder

relationships to degenerate into mutual distrust,making it difficult to balancerequirements, product features and plans.

5. Top 10 Software Management Principles:

1. Base the process on an architecture-first approach – rework rates remain stable over the project life cycle.



2. Establish an iterative life-cycle process that confronts risk early.3. Transition design methods to emphasize component-based

development.4. Establish a change management environment – the dynamicsof

iterative development, including concurrent workflows by different teamsworking on shared artifacts, necessitate highly controlled baselines

5. Enhance change freedom through tools that support round-tripengineering.

6. Capture design artifacts in rigorous, model-based notation.7. Instrument the process for objective quality control and progress

assessment.8. Use a demonstration-based approach to asses intermediate

artifacts.9. Plan intermediate releases in groups of usage scenarios with

evolving levels of detail.10. Establish a configurable process that is economicallyScalable.

6.Software Management Best Practices:

There are nine best practices:1. Formal risk management

2. Agreement on interfaces

3. Formal inspections

4. Metric-based scheduling and management 5. Binary quality gates at the inch-pebble level 6. Program-wide visibility of progress versus plan 7. Defect tracking against quality targets 8. Configuration management 9. People-aware management accountability

6.2 Next-Generation Software Economics:Software experts hold widely varying opinions about software

economics and its manifestation in software cost estimation models.It will be difficult to improve empirical estimation models while the project datagoing into these models are noisyand highly uncorrelated, and are basedon differing process and technology foundations.

Two major improvements in next-generation software cost estimationmodels:

Separation of the engineering stage from the production stagewill forceestimators to differentiate between architectural scale and implementation

size.



Rigorous design notations such as UML will offer an opportunitytodefine units of measure for scale that are more standardized and thereforecan be automated and tracked.

REPORT ON PROJECT MANAGEMENT

Documents

Transcript of REPORT ON PROJECT MANAGEMENT