Project ManagementSoftware development involves many peopleCost,quality,schedule objectives and resources have to be allocated to each activity of the projectProj.mgmt begins with planning,monitoring,control and termination analysisDuring planning,the major activities are cost estimation,schedule and milestone determination ,project staffing,quality control plans and controlling and monitoring plans

Project MonitoringProject monitoring and control phase of mgmt process is the longest in terms of duration;it encompasses most of development processThe basic reason for performing termination analysis is to provide info.about development process and learn from project in order to improve the process.

Job Responsibilities of Project Manager• Project manager responsibilities range from invisible activities like building up team morale to highly visible customer presentations– Project proposal writing– Project cost estimation – Project scheduling– Project staffing– s/w process tailoring– Project monitoring and control– s/w config.mgmt – Report writing– Risk mgmt– Interfacing with clientsProject Planning• Project planning consists of following activities:-– Estimating some basic attributes• Cost- how much will it cost to develop proj?• Duration- how long time to make development?• Effort- how much effort will be required?– Scheduling man power– Staff organization and staffing plansRole of Project Manager

Proj mgmt is organizing and directing the people to achieve a planned result within a predetermined schedule and budgetThe prj.mgmt defines and executes a proj.mgmt risksProj mgr has to be proactive in self improvementThe prj.mgmt establishes the team’s structure so that work can be accomplished:-

Identify project tasks and build a work breakdown structureDevelop proj.schedule Recruit and train team membersAssess project risksMonitor and assess proj. deliverables

Major External Deliverables(for a project manager)Report proj’s status and progressEstablish good working relationship with those who are needed for systemWork directly with the client and other stakeholders

Identify resource needs and obtain resources

The effective project management focuses on the four P’s People, Product, Process and Project

PeopleThe people management maturity model defines the key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization, work design and team/culture development.ProductBefore a project can be planned, product objectives and scope should be established, alternative solutions should be considered , and technical & management constraints should be identified. Without this information, it is impossible to define reasonable estimates of the cost, an effective assessment of the risk or a manageable project schedule which provides meaningful indication of progressProcessA software process provides the framework from which a comprehensive plan for s/w development can be established. A small number of framework activities are applicable to all s/w projects, regardless of their size or complexity. Project

to avoid project failure, A s/w project mgr and the s/w engineers who build the product must heed a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning monitoring and controlling the project. Where project management is used?Project management Knowledge Areas

Proj scope mgmt:-defining and controlling functions that are to be included in the system,as well as the scope of the work done by project teamProj Time Mgmt :- Building a detailed schedule of all project tasks and then monitoring progress of proj against given datesProj cost mgmt:- calculating initial cost/benefit analysis and later includes monitoring expenditures as the proj progressesProj Quality Mgmt:- establishing comprehensive plans for ensuring quality,includes quality-control activitiesProj Human Resource Mgmt:- recruiting and hiring proj team members for training,motivating and team buildingProj communication mgmt:-Identifying all stakeholders and communicating with them and following schedulesProj risk mgmt:- removing potential risks for failure and developing plans to reduce these risksProj procurement mgmt:-developing requests for proposals, writing contracts , evaluating bids and then monitoring vendor performanceProj integration mgmt:- integrating all other knowledge areas into one seamless(flawless)whole

Managing Changes in Requirements Changes in requirements can come at any time during the life of a projectProj.mgr should be prepared to handle change requests as they comeUncontrolled changes can have a very adverse effect on cost, schedule and quality of project

The change mgmt process defines set of activities performed when there are new requirements or changes to existing requirements

Steps in Change Management ProcessLog the changesPerform impact analysis on the work productsEstimate impact on effort and scheduleReview impact with concerned stakehoders Rework work products

Change Request DescriptionA change request log is maintained to keep track of change requestsEach entry in the log contains a change req.no ,a brief description of change ,the effect of the change and the status of the change request and key datesThe effect of change request is is assessed by performing impact analysis.It involves identifying work products and configuration items that need to be changed and evaluating the quantum of change to each; reassessing the proj risks by revisiting the risk mgmt plan; evaluating the overall implication of the changes for the effort and schedule estimates Once a change is reviewed & approved; it is implementedEven though change is not large in itself, in the overall life’s prj the cumulative impact of the changes is largeFor such growing changes, the change log is used

The change management process in systems engineering is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a system. It has two main goals: supporting the processing of changes and enabling traceability of changes.

Change management is an important process, because it can

1. Delivers vast benefits (by improving the system and thereby satisfying "customer needs"), 2. Furthermore, at least for the Information Technology domain, more funds and work are put into

system maintenance (which involves change management) 3. Hinley describes two of Lehman’s laws of   software   evolution : the law of continuing change (i.e.

systems that are used must change or automatically become less useful) and the law of increasing complexity (i.e. through changes the structure of a system becomes ever more complex and more resources are needed to simplify it).

ActivitiesThere are six main activities, which jointly form the change management process. They are: Identify potential change, Analyze change request, Evaluate change, Plan change, Implement change and Review and close change.

Role Description

Customer The customer is the role that requests a change due to problems encountered or new functionality requirements; this can be a person or an organizational entity and can be in- or external to the

company that is asked to implement the change.

Project manager

The project manager is the owner of the project that the CHANGE REQUEST concerns. In some cases there is a distinct change manager, who in that case takes on this role.

Change committee

The change committee decides whether a CHANGE REQUEST will be implemented or not. Sometimes this task is performed by the project manager as well.

Change builder

The change builder is the person who plans and implements the change; it could be argued that the planning component is (partially) taken on by the project manager.

Activity descriptions for the change management process

Activity Sub-activity Description

Identify potential change

Require new functionality[5] A customer desires new functionality and formulates a REQUIREMENT.

Encounter problem[5]

A customer encounters a problem (e.g. a bug) in the system and this leads to a PROBLEM REPORT.

Request change A customer proposes a change through creation of a CHANGE REQUEST.

Analyze change request

Determine technical feasibility

The project manager determines the technical feasibility of the proposed CHANGE REQUEST, leading to a CHANGE TECHNICAL FEASIBILITY.

Determine costs and benefits

The project manager determines the costs and benefits of the proposed CHANGE REQUEST, resulting in CHANGE COSTS AND BENEFITS. This and the above sub-activity can be done in any order and they are independent of each other, hence the modeling as unordered activities.

Evaluate change

Based on the CHANGE REQUEST, its CHANGE TECHNICAL FEASIBILITY and CHANGE COSTS AND BENEFITS, the change committee makes the go/no-go decision. This is modeled as a separate activity because it is an important

process step and has another role performing it. It is modeled as a sub-activity (without any activity containing it) as recommended by Remko Helms (personal communication).

Plan changeAnalyze change impact

The extent of the change (i.e. what other items the change effects) is determined in a CHANGE IMPACT ANALYSIS. It could be argued that this activity leads to another go/no-go decision, or that it even forms a part of the Analyze change request activity. It is modeled here as a planning task for the change builder because of its relationship with the activity Propagate change.

Create planning

A CHANGE PLANNING is created for the implementation of the change. Some process descriptions (e.g. Mäkäräinen, 2000) illustrate that is also possible to ‘save’ changes and process them later in a batch. This activity could be viewed as a good point to do this.

Implement change

Execute changeThe change is ‘programmed’; this activity has a strong relationship with Propagate change, because sometimes the change has to be adapted to other parts of the system (or even other systems) as well.

Propagate change

The changes resulting from Execute change have to be propagated to other system parts that are influenced by it. Because this and the above sub-activity are highly dependent on each other, they have been modeled as concurrent activities.

Test changeThe change builder tests whether what (s)he has built actually works and satisfies the CHANGE REQUEST. As depicted in the diagram, this can result in an iterative process together with the above two sub-activities.

Update documentation

The DOCUMENTATION is updated to reflect the applied changes.

Release change A new SYSTEM RELEASE, which reflects the applied change, is made public.

Review and close change

Verify change

The implementation of the change in the new SYSTEM RELEASE is verified for the last time, now by the project manager. Maybe this has to happen before the release, but due to conflicting literature sources and diagram complexity considerations it was chosen to model it this way and include this issue.

Close change This change cycle is completed, i.e. the CHANGE LOG ENTRY is wrapped up.

Software MetricTwo types: - Product and Process MetricsProduct metrics are measures of the software product at any stage of its development, from requirements to installed system. Product metrics may measure the complexity of the software design, the size of the final program (either source or object code), or the number of pages of documentation produced. Process metrics, on the other hand, are measures of the software development process, such as overall development time, type of methodology used, or the average level of experience of the programming staff.

Role of Software Metric

s/w metrics are quantifiable measures that could be used to measure characteristics of a s/w system or development process. There are 2 types:- product and process metricsProduct metrics:- they are used to quantify characteristics of the product being developedProcess metrics:- are used to quantify characteristics of the process being used to develop the s/w.

Its aim is to measure productivity, cost and resource requirements, effectiveness of quality measures and the effect of development techq and tools.

Role of software MetricSoftware metrics deals with the measurement of the software product and the process by which it is developed.Good metrics should facilitate the development of models that are capable of predicting process or product parameters, not just describing them. Thus,

• simple, precisely definable—so that it is clear how the metric can be evaluated• objective, to the greatest extent possible;• easily obtainable (i.e., at reasonable cost);

Good Metric Parametersvalid—the metric should measure what it is intended to measure; androbust—relatively insensitive to (intuitively)

insignificant changes in the process or product.It has been observed that the fundamental qualities required of any technical system are:-

functionality—correctness, reliability, etc.;performance—response time, throughput, speed, andeconomy—cost effectiveness.Software metrics may be broadly classified as either

• product metrics or process metrics.• Product metrics are measures of the software product at any stage of its development,

from requirements to installed system. • Product metrics may measure the complexity• of the software design, the size of the final program

(either source or object code), or the number of pages of documentation produced. Process metrics are measures of the software development process, such as overall development time, type of methodology used, or the average level of experience of the programming staff.

For product metrics, the size of the product measured in lines of code (LOC) is an objective measure.when programming languages at different levels involved, these metrics may obscure overall productivity and quality improvements by systematically yielding lower defect per LOC and cost per defect values for lower-level languages, even though total defects and costs are actually higherSize Metric :- A number of metrics attempt to quantify software “size.” The metric that is most widely used, LOC suffers from the obvious deficiency that its value cannot be measured until after the coding process has been completed. Function points have the advantage of being measurable earlier in the development process—at least as early as the design phase, and possibly earlier.A. Lines of Code :- Lines of code (or LOC) is possibly the most widely used metric for program size. It would seem to be easily and precisely definable; however there are a number of different definitions for the number of lines of code in a particular program. These differences involve treatment of

Blank lines and comment lines, non-executable statements, multiple statements per line, and multiple lines per statement, as well as the question of how to count reused lines of code.

The most common definition of LOC seems to count any line that is not a blank or comment line, regardless of the number of statements per lineLOC has been theorized to be useful as a predictor of program complexity, total development effort, and programmer performanceB. Function point :- Albrecht has proposed a measure of software size that can be determined early in the development process. The approach is to compute the total function points (FP) value for the project, based upon the number of external user inputs, inquiries, outputs, and master files.

The value of FP is the total of these individual values, with the following weights applied: inputs: 4, outputs: 5, inquiries: 4, and master files: 10. Each FP contributor can also be adjusted within a range of ± 35% for specific project complexityFunction points are intended to be a measure of program size and, thus, effort required for developmentFunction point can be used as a means for measuring the functionality delivered by a systemFP metric can be used to 1)estimate the cost or effort required to design, code and test the software 2)predict the number of errors that will be encountered during testing 3)forecast the number of components and/or the number of projected source lines in the implemented system

Data collection parameters for FPNo.of external inputs(EI):- each external I/p originates from a user or is transmitted from another application and provides distinct application oriented data or control informationNo. of external outputs(EO):-each external o/p is derived data within the application that provides info.to the user.external o/p refers to reports,screens,error messageNo.of external inquiries(EQ):-an external inquiry is defined as online i/p that results in the generation of some immediate s/w response in the form of an online o/pNo.of internal logical files(ILF):- each internal logical file is a grouping of data that resides within application’s boundary and is maintained via external i/p(s)

No.of external interface files(EIF):-it is a logical grouping of data resides external to the application but provides info that may be of use to the applicationOrganizations that use FP method, to compute FP, the following relationship is used:-FP=count total*[.65+.01* /summation of Fi where count total is the sum of all FP entries

c. Cyclomatic Complexity

For a computer program, one can draw its control flow graph, G, wherein each node corresponds to a block of sequential code and each arc corresponds to a branch or decision point in the program. The cyclomatic complexity of such a graph can be computed by a simple formula from graph theory, as v(G) = e - n + 2, where e is the number of edges, and n is the number of nodes in the graph. McCabe proposed that v(G) can be used as a measure of program complexity and, hence, as a guide to program development and testing

d. Defect MetricsThe number of defects in the software product should be readily derivable from the product itself thus, it qualifies as a product metric.since there is no effective procedure for counting the defects in the program, the following alternative measures have been proposed:-

Number of design changesNumber of errors detected by code by inspectionsNumber of errors detected in program testsNumber of code changes required

All these alternative measures are dependent upon both the program and the outcome of some phase of development cycle

e. COCOMO Co nstructive Cost Model

This model estimates the total efforts in terms of person-monthsThe steps are :-

Obtain an initial estimate of the development effort from the estimate of thousands of delivered lines of source code(KLOC)Determine a set of 15 multiplying factors from different attributes of the projectAdjust the effort estimate by multiplying the initial estimate with all the multiplying factorsThe initial estimate is called as nominal estimate determined by an equation of the form used in static single variable models using KLOC as a measure of the size

To determine initial effort Ei in person months Ei=a * (KLOC)b

The value of the constants a and b depend on the project typeThis is probably the best known and most thoroughly documented of all software cost estimating models. It provides three levels of basic, intermediate, and detailed. Boehm identifies three modes of product development— organic, semidetached, and embedded—that aidin determining the difficulty of the project.developmental effort equations are all of the below form :-

E = aSb m , where a and b are constants determined for each mode and model level;

S is the value of source LOC; and m is a composite multiplier, determined for 15 cost-driverattributes

Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and so on. Organic projects - "small" teams with "good" experience working with "less than rigid" requirements §Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than rigid requirements §Embedded projects - developed within a set of "tight" constraints (hardware, software, operational, ...)

System a bOrganic 3.2 1.05Semidetached 3.0 1.12Embedded 2.8 1.20The values for a cost model are found out from past data and they are dependent on process.

There are 15 different attributes, called cost driver attributes, they determine multiplying factor. These factors are dependent on product, computer, personnel and technology attributes(project attributes)

The basic COCOMO equations take the form Effort Applied = ab(KLOC)b

b [ man-months ] Development Time = cb(Effort Applied)d

b [months]People required = Effort Applied / Development Time [count] The coefficients ab, bb, cb and db are given in the following table.

Software

project

ab bb cb db

Organic 2.4

1.05

2.5

0.38

Semi-detache

d

3.0

1.12

2.5

0.35

Embedded

3.6

1.20

2.5

0.32

Organic: A development project can be considered of organic type, if the project deals with developing a well understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar types of projects. Semidetached: A development project can be considered of semidetached type, if the development consists of a mixture of experienced and inexperienced staff.

Team members may have limited experience on related systems but may be unfamiliar with some aspects of the system being developed. Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational procedures exist. Estimation of development effort

For the three classes of software products, the formulas for estimating the effortbased on the code size are shown below:Organic : Effort = 2.4(KLOC)1.05 PMSemi-detached : Effort = 3.0(KLOC)1.12 PMEmbedded : Effort = 3.6(KLOC)1.20 PM

Estimation of development timeFor the three classes of software products, the formulas for estimating thedevelopment time based on the effort are given below:Organic : Tdev = 2.5(Effort)0.38 MonthsSemi-detached : Tdev = 2.5(Effort)0.35 MonthsEmbedded : Tdev = 2.5(Effort)0.32 Months

Go thru the ppt of workshop once , refer Pressman 7th edition and type remaining

Project Scheduling Scheduling is the process of deciding:

In what sequence a set of activities will be performed. When they should start and be completed.

Tracking is the process of determining how well you are sticking to the cost estimate and schedule

Steps in project scheduling Identify phases/activities/tasks in project(use SDLC as guide) Estimate the size of the task Determine sequence for identified tasks Schedule tasks

Discussing the details of a project schedule 3 terms: task, activity and phase Phase is made up of a group of related activities, an activity is made up of group of

related tasks, a task is the smallest piece of work that is identified and scheduled. Activities are also identified, named and scheduled.

Within the design phase,identify the activities such as Design user interface,design and integrate the database, complete the application design.

During project planning phase,it may not be possible to schedule every task in the entire project because it is too early to know all of the tasks that will be necessary. One of the requirements of the project planning phase is to provide estimates of the time to complete the project and total cost of the project. Project cost is payment of salaries to project team, estimate of the time and labor to complete the project becomes critical. The development of the project schedule is divided into two steps:-

Develop a WBS(work breakdown structure)

Build a PERT/CPM chartProject Scheduling Process

Establishing a project schedule determines the time ordering of tasks, helps identify potential resource conflicts, and provides assurance about completion time.

A well defined schedule is also a very useful tool for monitoring progress. Developing a project schedule includes the following steps:

Establish the detailed WBS Determine the task dependence or precedence Identify time lags Roll-up time estimates from bottom level WBS Assign resources (i.e. people) to tasks & resolve conflicts Identify milestone dates Implement trade-off if schedule is not acceptable

Factors Affecting the Schedule Is the WBS complete?

Undefined tasks or time lags can disrupt the planned schedule How accurate is the work package time estimate?

Uncertainty in the times for the lowest WBS level will propagate upward during roll-up

What is the level of task dependency? Dependent tasks can only be accomplished in sequence rather than in parallel.

Thus, increasing the number of personnel will not necessarily reduce the time required to complete the tasks.

What is the availability of personnel resources? An individual can not focus on more than one task at a time. Thus, without

sufficient personnel independent tasks will need to be done sequentially. What is the effectiveness of the personnel?

What is the percentage of time per week that personnel can be “on task”?Essential Schedule Information

A complete WBS provides the first order schedule organization All major tasks, subtasks and milestone events should be identified The WBS units will usually already be in some kind of time ordering

Determine which tasks require the results from some previous task (i.e. task precedence)

Determine which tasks can be accomplished in parallel For example, you can build multiple copies of the same design at the same time.

Identify milestone events and determine if any of these events require a fixed dateBuilding WBS

Company owners and project managers use the Work Breakdown Structure (WBS) to make complex projects more manageable.

The WBS is designed to help break down a project into manageable chunks that can be effectively estimated and supervised.

Some widely used reasons for creating a WBS include: Assists with accurate project organization

Helps with assigning responsibilities Shows the control points and project milestones Allows for more accurate estimation of cost, risk and time Helps explain the project scope to stakeholders

Constructing WBS To start out, the project manager and subject matter experts determine the main

deliverables for the project. Once this is completed, they start decomposing the deliverables they have identified,

breaking them down to successively smaller chunks of work. Predetermined “rule” should govern the size and scope of the smallest chunks of work. Two weeks rule says that, where nothing is broken down any smaller than it would take

two weeks to complete. You can also use the 8/80 rule, where no chunk would take less than 8 hours or longer

than 80 hours to complete. The two most common ways to communicate a WBS is either a hierarchy diagram or a

table of contents (TOC) layout. In some cases both formats are used to gain understanding and define the work to be

performed. Typically, complex projects with a large number of internal and external stakeholders respond better to a hierarchy diagramWBS

Common approaches to Developing the WBS The two most common approaches to developing the WBS are the top down approach

and the bottom up approach. Top-Down Approach:- The top down approach uses a predefined product development

lifecycle This approach involves using a model and reviewing the major project

deliverables which have been subdivided into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project phases (planning, executing, controlling, and closing).

Bottom Up Approach:- The bottom up approach uses a planning group to brainstorm the work elements that are needed to deliver the major deliverables of the project.

A planner then groups the output from the brainstorming sessions into phases, activities and tasks.

The bottom up approach involves using a small group of people (5-6) who have some subject matter expertise to plan the project.

The technique uses the brainstorming method to identify the work needing to be performed to deliver a specific thing.

PERT/CPM –project Evaluation & Review Techq. CPM stands for Critical Path Method. Actually, they are two distinct techniques but recently they have been merged into a single scheduling techq. PERT /CPM is a diagram of all the tasks identified in the WBS, showing the sequence of dependencies of the tasks. Search Diagram. by showing which tasks can be done concurrently, a

PERT chart also assists in assigning staff. It is always a juggling act to balance the availability and workload of the team members with the dependent and independent tasks.Building the PERT/CPM begins with the list of activities and tasks developed in WBS. The WBS is analyzed , including the duration and expected resources for each task, to determine the dependencies. For each task, the chart identifies all the immediate predecessor tasks and the successor tasksThe critical path is the longest path through the PERT/CPM diagram and contains all the tasks that must be done in the defined sequential order. It is called as critical path because if any tasks on the critical path is delayed, the entire project will be completed late will be completed late. Project managers usually monitor the tasks on the critical path v.carefully.

Configuration Management

• It is the stream systematically controlling the changes that take place during development

• IEEE defines SCM as the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of the items change requests, verifying the completeness and correctness of items

• Changes may occur due to –• Evolution of the work products as proj proceeds• Changes due to the defects(bugs) being found and then fixed• Changes due to requirements changes• All these are reflected in files containing source,data or documentation

• SCM directly controls the products of the process and only directly influences the activities producing the product

• It is essential to satisfy one of the basic objective of the project– delivery of a high quality s/w product to the client

• Software which is delivered to the client contains various source or object files and associated documentation

• During the course of the project,the files change, leading to diff.versions

Configuration Management functionality• Requirements of project from its config.mgmt process depends on nature of the project

—– Give latest version of pgm:- suppose the program has to be

modified,modification has to be carried out in the latest copy of that program otherwise changes made earlier may be lost

– Undo a change or revert back to a specified version:- a change is made to a pgm, but later it would be a need to undo change request

– Prevent unauthorized changes or deletions:-a programmer may decide to change some pgms, only to discover that change has adverse side effects. The CM must allow this to happen smoothly

– Prevent unauthorized changes/deletions:- a programmer may decide to change some programs,only to discover that the change has adverse side effects. The CM process ensures that unapproved changes are not permitted

– Gather all sources,docs,and other info from current system:-all sources and related files are needed for releasing the product. The CM process must provide this functionality. All sources and related files of a working system are needed for reinstallation

CM Mechanism• The mechanism used to provide necessary functionality include:-

– Config.identification and baselining – Version control or version mgmt– Access control– A s/w config.item(SCI) or item is a document or an artifact that is placed under

configuration control and can be regarded as a basic unit for modification– Configuration management (CM) is a field of management that focuses on

establishing and maintaining consistency of a system's or product's performance – its functional and physical attributes with its requirements, design, and

operational information throughout its life– SCM defined by Pressman is—– “set of activities designed to control change by identifying the work products

that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”

Software Configuration Management• As the proj proceeds hundreds of changes are made to these config.items hence

baselines are established• A baseline once established,captures logical state of the system and forms the basis of

change thereafter• A baseline also forms a reference pt. in the development of a system• SCIs(s/w config item) are being managed by SCM are not independent of one another• An SCI x is said to depend on another SCI y, if a change to y might require a change to

be made to x for x to remain correct or for the baselines to remain consistent• A change request might require the changes to be made to some SCIs, the dependency

of other SCIs on the ones being changed might require that other SCIs also need to be changed

• Dependency among SCIs is to be properly understood and documented

Software Configuration Items• As the proj proceeds hundreds of changes are made to these config.items hence

baselines are established• A baseline once established,captures logical state of the system and forms the basis of

change thereafter• A baseline also forms a reference pt. in the development of a system

• SCIs(s/w config item) are being managed by SCM are not independent of one another• An SCI x is said to depend on another SCI y, if a change to y might require a change to

be made to x for x to remain correct or for the baselines to remain consistent• A change request might require the changes to be made to some SCIs, the dependency

of other SCIs on the ones being changed might require that other SCIs also need to be changed

• Dependency among SCIs is to be properly understood and documented

Version Control• Key issue for CM• Many tools are available to help manage the various versions of programs• Without such a mechanism,many of the reqd CM functions cannot be supported• Version control helps preserve older versions of the programs whenever pgms are

changed• Commonly used CM systems are :- Source Code Control System, a method of controlling

software versions• Others are CVS,VSS

CM Process• CM process defines the set of activities need to be performed to control change• 1st stage in CM process is planning• Then process has to be executed,using some tools• CM plan requires discipline from project personnel in terms of storing items in proper

locations, making changes properly, monitoring the status of config.items and performing CM audits

• Planning for config mgmt involves identifying the config items and specifying the procedures to be used for controlling and implementing changes to these config items

• Examples of config items include requirement specification,design docs, source code,test plans, test scripts, test procedures,test data,stds used in the project, acceptance plan,docs such as CM plan and project plan, user documentation such as user manual, training material, contract docs,quality records(review and test records) and CM records(release records,status tracking records)

• Any customer supplied products or purchased items that will be the part of the delivery are also config items

• To facilitate proper naming of configuration items, the naming convention for CM items are decided during the CM planning stages

• In addition to naming std,version numbering must be planned. When a config item is changed,the old item is not replaced with the new copy instead the old copy is maintained and a new one is created

• This approach results in multiple versions of an item• If CM tool is used , it handles the version numbering otherwise has to be done explicitly

in the project• The config controller/project manager do the CM planning, it is begun only when the

project is been initiated and the operating environment and requirements specifications are clearly documented. The o/p of this is CM plan

• The config controller is responsible for implementation of CM planning• For CM to work well,to avoid mistake in SCI(s/w config item), auditing and regular

checking of SCI is done• The audit may also check that changes to SCIs due to change requests have been done• Refer

http://ptgmedia.pearsoncmg.com/images/0321117662/samplechapter/hassch01.pdf

CMM—Capability Maturity Model• CMM provides roadmap for process improvement• Software process capability describes the range of expected results that can be achieved• The process capability of an organization determines what can be expected from the

organization in terms of quality and productivity. The goal of process improvement is to improve the process capability

• A maturity is a well defined evolutionary plateau towards achieving a matured s/w process

• CMM (Capability Maturity Model) is a model of process maturity for software development - an evolutionary model of the progress of a company’s abilities to develop software.Development of this model was necessary so that the U.S. federal government could objectively evaluate software providers and their abilities to manage large projects.

• Many companies had been completing their projects with significant overruns in schedule and budget. The development and application of CMM helps to solve this problem.

• The key concept of the standard is organizational maturity. A mature organization has clearly defined procedures for software development and project management.

• These procedures are adjusted and perfected as required. • In any software development company there are standards for processes of

development, testing, and software application; and rules for appearance of final program code, components, interfaces, etc.(refer diag.)

Risk Management

• Risk mgmt is an attempt to minimize the chances of failure caused by unplanned events• The aim of risk mgmt is not to avoid doing such projects where there is a risk but to

minimize the impact of risks in the projects which are undertaken• Risk is defined as an exposure to the chance of injury/loss

• In the context of s/w project, risk may have an adverse effect on cost, quality and schedule

• Risk mgmt is the area to ensure that the impact of risks on cost, quality and schedule is minimal

• Risk management has to deal with identifying the undesirable events that can occur,the probability of their occurring and the loss if an undesirable event occurs

• Once this is known, the strategies for either reducing the probability of risk or reducing the effect of risk materializing are formulated

• Risk assessment and risk control are two imp aspectsRisk assessment• Risk assessment is undertaken at the time of project planning• This involves identifying the risks, analyzing them and prioritizing them on the basis of

analysis• Risk identification is the first step,identifies all different risks for a particular project.

These risks are project dependents• Methods that can aid risk identification include checklists of possible risks,surveys,

meetings and brainstorming and reviews of plans, processes and work products• Based on surveys of experienced project managers, Boehm has produced a list of 10 risk

items likely to compromise the success of s/w project• 1) personal shortfalls—having good knowledge in specific skills in specific areas;

adequate training may reduce the risk• 2)unrealistic schedules and budget—high level mgmt imposes the schedule, may not be

based on the characteristics of project and hence may be unrealistic• 3)developing wrong s/w functions- due to lack of correct SRS• 4)Developing wrong user interface• 5)Gold plating– adding features to s/w which are marginally useful,adds unnecessary

risk to the project as it consumes resources and indirectly the time• 6)Continuing the stream of requirement changes – incremental development or info

hiding• 7)Shortfalls in externally furnished components• 8)Shortfalls in externally performed tasks• 9)Real time performance shortfalls• 10)Straining computer science capabilities– if a project relies on technology that is not

well developed, then project may fail• Risk identification identifies undesirable events that might take place during the project

i.e. enumerates “unforeseen” events that might occur• Hence the next tasks are risk analysis and prioritizationRisk Analysis• In risk analysis, the probability of occurrence of risk has to be estimated, along with the

loss that will occur if the risk does materialize• If the cost models are used for cost and schedule estimation, the same can be used to

assess the cost and schedule risk• In COCOMO cost model,the cost estimate depends on rating of diff cost drivers,

• Risk analysis can be done by estimating the worst case value of size and all the cost drivers and then estimating the project cost from these values

• The other approaches for risk analysis include studying the probability and the outcome of possible decisions(decision analysis),understanding task dependencies to decide critical activities and probability and cost of their not being completed on time(n/w analysis),risks on various quality factors like reliability and usability(quality factor analysis) and evaluating the performance(performance analysis)

Risk Exposure• Once the probabilities of risks materializing and losses due to the same have been

analyzed,they can be prioritized. • RE=Prob(UO) * Loss(UO) àundesirable outcome • Prob(UO)– is the probability of risk materializing• Loss(UO)- total loss incurred due to unsatisfactory outcome• The loss is not only direct financial loss but in terms of credibility,future business and

loss of property/life• RE is an expected value of loss due to particular risk• The higher the RE the higher the priority of the risk itemRisk Control

• The main objective of risk mgmt is to identify top few risk items and focus on them• Knowing the risks of value, then one can prepare the plan so that their consequences

are minimal– basic goal of risk mgmt• For most risks, risk mitigation steps are performed• They are either reducing probability of risk materializing or reduce the loss due to risk

materializing• the commonly occurring risks are maintained in a table• Even risk monitoring is also carried out, which monitors the status of various risks and

their control activities• One simple approach of risk monitoring is to analyze the risks afresh at each major

milestone and change the plans as needed