UNIT-II

UNIT-IIPROJECT SCHEDULINGPROJECT SCHEDULINGScheduling is an inexact process in that it tries to predict the future. While it is not possible to know with certainty how long a project will take, there are techniques that can increase your likelihood of being close. If you are close in your planning and estimating, you can manage the project to achieve the schedule by accelerating some efforts or modifying approaches to meet required deadlines.

PROJECT SCHEDULINGIn order to schedule the project activities, a software project manager needs to do the following:

Identify all the tasks needed to complete the project.Break down large tasks into small activities.Determine the dependency among different activitiesEstablish the most likely estimates for the time durations necessary to complete the activities.Allocate resources to activities.Plan the starting and ending dates for various activities.Determine the critical path.

PROJECT SCHEDULING-WORK BREAK DOWN STRUCTUREWBS is used to decompose a given task set recursively into small activities. WBS provides a notation for representing the major tasks needed to be carried out in order to solve a problem.

PROJECT SCHEDULING-WORK BREAK DOWN STRUCTUREThe WBS should be designed with consideration for its eventual uses. Your WBS design should try to achieve certain goals:

Be compatible with how the work will be done and how costs and schedules will be managed,Give visibility to important or risky work efforts,Allow mapping of requirements, plans, testing, and deliverables,Foster clear ownership by managers and task leaders,Provide data for performance measurement and historical databases, andMake sense to the workers and accountants.

PROJECT SCHEDULING-ACTIVITY NETWORKS AND CRITICAL PATH METHODPERT and CPM have similarities in terms of concepts and methodology, a basic difference exists between the two techniques. PERT is useful for analysis project scheduling problem in which the completion time of the different activities, and therefore the whole project, is not certain. On the other hand CPM is most appropriately used in projects in which the activity durations are known with certainty. This technique is basically concerned with obtaining the tradeoffs between the project duration and cost. Thus, whereas variation in the project time is inherent in the projects where PERT is used, the time is systematically varied where CPM is employed. In essence, then while PERT is probabilistic in nature and as such is used more in research and development projects, the CPM is a deterministic technique.PERT and CPM are suitable for any situation where:The project consists of well-defined collection of activities or tasks.The activities can be started and terminated independently of each other, even if the resources employed on the various activates are not independent.The activities are ordered so that they can be performed in a technological sequence.

PROJECT SCHEDULING-PERT - CPM

PROJECT SCHEDULING-PERT - CPMSNNODESEARLIEST TIME (Emax)LATEST TIME(Emin)SLACK1TA0002TB4403TC91014TD9905TE161606TF262607TG232418TH29290PROJECT SCHEDULING-PERT - CPM

PROJECT SCHEDULING-GANTT CHARTSA Gantt chart is a horizontal bar or line chart which will commonly include the following features: activities identified on the left hand side; time scale is drawn on the top (or bottom) of the chart; a horizontal open oblong or a line is drawn against each activity indicating estimated duration; dependencies between activities are shown; at a review point the oblongs are shaded to represent the actual time spent (an alternative is to represent actual and estimated by 2 separate lines); a vertical cursor (such as a transparent ruler) placed at the review point makes it possible to establish activities which are behind or ahead of schedule.

Sample Intranet Organized by Phase

Intranet WBS in Tabular Form1.0 Concept1.1 Evaluate current systems1.2 Define Requirements1.2.1 Define user requirements1.2.2 Define content requirements1.2.3 Define system requirements1.2.4 Define server owner requirements1.3 Define specific functionality1.4 Define risks and risk management approach1.5 Develop project plan1.6 Brief Web development team2.0 Web Site Design3.0 Web Site Development4.0 Roll Out5.0 SupportINTRANET PROJECT WITH GANTT CHART

STAFFINGOnce the effort required to develop a software has been determined, it is necessary to determine the staffing requirement for the project. Putman was the first to study the problem of what should be a proper staffing pattern for software projects. He extended the work of Nordon who earlier investigated the staffing pattern of general research and development type of projects. In order to appreciate the staffing pattern of software projects, we must first understand Nordons and Putmans result.STAFFING- Nordons workAccording to Nordon the equation of rayleigh curve is as follows:E = K/td2 * t * e t2/2td2

Where E is the effort required at time t. E is an of the number of developers at any particular time during the duration of the project. K is the area under the curve. And td is the time at which the curve attains its maximum value.

But this equation is applicable for R&D type of project.STAFFING- Putmans workPutman derived the following expression:L=CkK1/3td4/3

Where K is the total effort expended in the product development and L is the product size in KLOC.Td corresponds to the time of system integration and testing. Therefore, td can be approximately considered as the time required to develop the software.Ck is the state of technology constant and reflects constraints that impede the progress of the programmer. Typical values of Ck = 2 for poor development environment, poor documentation etc. Ck = 8 for good and Ck = 11 for an excellent one.

Putman suggested that optimal staff build-up on a project should follow the Rayleigh curve. Software Quality AssuranceA planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements. IEEE STD 610.12-1990Software Quality AssuranceSQA is the function that (through measurement and analysis) works to continually improve process, methods, procedures, and standards so that management can be assured that when their staff follows those methods, procedures and standards they will be able to consistently deliver products that both meet requirements and are fit for use.

Provides management with appropriate visibility into the process being used and the products being builtVerifies compliance with project requirementsInvolvesReviewing or auditing products and processesProviding appropriate visibility to affected groups and Senior ManagementIdentifying, documenting, and tracking noncompliance issuesBased on a documented plan and processes

Software Quality AssuranceQuality is a management responsibility and SQA provides visibility for senior /project management and customers into the processes being used by the software projects to assure high-quality deliverable products.Each project is responsible for assuring the delivery of high-quality technical products and services. The activities for validating and verifying the technical correctness of software products is the project management and development teams responsibility.This is realized by conducting peer reviews, management reviews, thorough testing before product release, etc. SQA also helps the project team understand the quality requirements for following the defined project processes.

Who should be concernedPeople involved in planning and implementing SQA within their project or area of responsibility, specifically:

Project Managers, Project Software Managers, and Task Leaders who evaluate, plan and implement SQA within their project, as well as:Software Engineers and Testers who work with the SQA group SQA engineers and members of related software groups.SQA FunctionsEnsures SQA activities exist for all software development and maintenance projectsObjectively and independently verifies that all software products and activities adhere to the applicable standards, procedures, and requirementsSeeks to resolve non-compliance issues with the software projectFor issues not resolvable within the software project, the SQA function escalates the issue to an appropriate level of managementActs in an advisory role in clarifying and understanding applicable software procedures and practices

Barriers to SQALack of understanding of the role of SQALack of buy-in to the concept that SQA adds valueLack of process makes it impossible for SQA to verify complianceLack of training in SQA functionsMisconception that SQA is responsible for quality

SQA and Successful ProjectsDevelop a process focus.Formulate an agreement with Senior Management to establish an informed, independent SQA group.In order to be successful QA must:Operate within the scope of the project and respect the confidentiality of the workgroups that you support.Have unrestricted access to project information, activities, results andProvide visibility to Senior Management as to process capability (CMM), process compliance and product quality.

SQA Key Process Areas GoalsSoftware quality assurance activities are plannedAdherence of software products and activities to the applicable standards, procedures, and requirements is verified objectivelyAffected groups and individuals are informed of software quality assurance activities and resultsNoncompliance issues that cannot be resolved within the software project are addressed by Senior Management

Instructions1Establishment of SQA2Planning SQA3Software Engineering Activities Evaluations4Software Engineering Work Products Evaluations5Reporting SQA Activities 6Corrective Action System7Measuring SQA Status8Review of SQA Program

261 - Implementations SQANotes to Instructor:1 - Establishment of SQASQA group is established and fully integrated with project activitiesSQA group has independent reporting chain to Senior Management for non-conformance or non-compliance issuesSQA group has authority to take oversight action272 - Planning SQANotes to Instructor:2 - Planning SQASQA group shall plan the project SQA activities Plan reviewed by affected groupsPlan is managed and controlledSQA activities conducted in accordance with the planSQA group participates in reviewing projects plans, standards, and proceduresCompliance with Company policyCompliance with externally imposed standards/requirementsStandards appropriate for project useTopics required in Software Development Plan (SDP)Other project directed issues

28SQA Planning ProcessNotes to Instructor:AnalyzeRequirementsUnderstandDevelopmentMethodologyUnderstandProjectOrganizationAnalyze PlanContent/FormatRequirementsPlan byIdentifying applicable activitiesIdentifying applicable proceduresScheduling activitiesDocument/update planning in quality plan and other standardsDistribute quality plan forPeer reviewProduct Assurance management reviewDevelopment manager reviewResolveCommentsObtain sign-offImplement planned activitiesNoComments?YesSQA Planning Process293 - Software Engineering Activities EvaluationsNotes to Instructor:3 - Software Engineering Activities EvaluationsSQA group verifiesCompliance with the SDP, and the designated standards and proceduresResults are documented and a summary of the evaluation is providedDeviations are identified, corrective actions are assigned, and tracked to closure304 - Software Engineering Activity and Work Products AuditsNotes to Instructor:4 - Software Engineering Work Products EvaluationsVerify plans, standards, procedures are in place and can be used to review and audit the projectEvaluate designated work productsDeliverable software products are evaluated prior to customer deliverySoftware engineering work products are evaluated against designated standards and contractual requirements. Software engineering work products are produced in accordance with the applicable proceduresThe results of the evaluations shall be documented so that a summary of the evaluations is provided and deviations are identified, corrective actions are assigned and tracked to closure.31SQA Process/Product EvaluationNotes to Instructor:PerformProcessEvaluationPerformProductEvaluationDocument findings and anomaliesShipping recommendation for deliverablesOriginator Resolves AnomaliesElevate IssuestoManagementNoNeed toElevateIssues?YesUsing detailed checklistsUsing detailed checklistsSQA Reviews Updates and ChangesYesNon-concurrenceissues exist?NoShip or Release ProductDocument complianceSQA Process/Product Evaluation325 - Reporting SQA ActivitiesNotes to Instructor:Time 1:205 - Reporting SQA ActivitiesFindings from evaluations are reported SQA activities and their status are reviewed with the PMAt a minimum, the following is reported:A summary of the results of the evaluations performed since the last reviewThe measurements described in Instruction 7SQA issues and concerns336 - Corrective Action SystemNotes to Instructor:6 - Corrective Action SystemVerify corrective action system in closed-loopDeviations are identified, documented, assigned, and tracked to closureMonitor deviationsDeviations resolved at project team levelEscalation of noncompliance to Senior Management34Corrective Action System (CAS)Notes to Instructor:Time 1:257 - Measuring SQA StatusSQA group measures its performance and reviews with project managementMeasurements tracked against the planCompletion of SQA milestonesSQA work completed (effort and funds expended)Number of product audits and activity evaluations completed358 - Review of SQA ProgramNotes to Instructor:Time 1:308 - Review of SQA ProgramSQA group conducts periodic reviews with customers SQAExperts independent of the projects SQA evaluate effectiveness of that projects SQA function on an annual basis in accordance with:The results of this evaluation are distributed to the project manager, the project software manager, and senior management within the Group.36Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisk is defined as "The possibility of suffering harm or loss; danger.

Risk management is the planned control of risk. It involves monitoring the success of a project, analyzing potential risks, and making decisions about what to do about potential risks.37Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisks in Software Project ManagementDr. Barry W. Boehm in his article "Software Risk Management: Principles and Practices lists the following top 10 software risk items:Personnel ShortfallsUnrealistic schedules and budgetsDeveloping the wrong functions and propertiesDeveloping the wrong user interfaceGold-platingContinuing stream of requirements changesShortfalls in externally furnished componentsShortfalls in externally performed tasksReal-time performance shortfallsStraining computer-science capabilities38Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTHow to ManageDr. Boehm describes risk management as being comprised of the following activities:Risk Assessment (figuring out what the risks are and what to focus on)- making a list of all of the potential dangers that will affect the project - assessing the probability of occurrence and potential loss of each item listed - ranking the items (from most to least dangerous) Risk Control (doing something about them)- coming up with techniques and strategies to mitigate the highest ordered risks - implementing the strategies to resolve the high order risks factors - monitoring the effectiveness of the strategies and the changing levels of risk throughout the project 39Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTHow to Manage general concept

40Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisk Identification:The project manager needs to anticipate the risks in the project as early as possible so that the impact of the risks can be minimized by making effective risk management plans. There are three main categories of risks which can affect a software project as follows: Project Risk: Project risks concern various forms of budgetary, schedule, personnel and customer related problems. Technical Risk: Technical risks concern potential design, implementation, interfacing, testing, and maintenance problems. It also include ambiguous specification, incomplete specification, changing specification, technical uncertainty and obsolescence.Business Risk: This type of risk include risks of building and excellent product that no one wants, losing budgetary or personnel commitments.41Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisk Assessment/Analysis:The objective of risk assessment is to rank the risks in terms of their damage causing potential. For risk assessment, first each risk should be rated in tow ways:The likelihood of a risk coming true(r)The consequence of the problems associated with that risk (s).

Based on these two factors, the priority of each risk can be computed.p=r*sWhere p is the priority with which the risk must be handled, r is the probability of the risk becoming true, and s is the severity of damage caused due to the risk becoming true. If all identified risks are prioritized, then the most likely and damaging risks can be handled first and more comprehensive risk abatement procedures can be designed for these risks.42Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisk Assessment/Analysis:

43Data from Audits and ReviewsNotes to Instructor:

RISK MANAGEMENTRisk Assessment/Analysis:RISK MANAGEMENTRisk Containment/Planning:After all the identified risks of a project are assessed, plans must be made to first contain the most damaging and the most likely risks. There are three main strategies to plan for risk containment.

Avoid the risk: Risks can be avoided in several ways, such as discussing with the customer to change the requirements to reduce the scope of the work, giving incentives to the developers to avoid the risk of the manpower turnover.

Transfer the risk: This strategy involves getting the risky component developed by a third party, buying insurance cover and so on.

Risk reduction: This involves planning ways to contain the damage due to a risk. The most important thing to do in addressing technical risks is to build a prototype that tries out pieces of the technology that you are trying to use.45Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisk Containment/Planning:

46Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENTRisk Containment/Planning:

47Data from Audits and ReviewsNotes to Instructor:RISK MANAGEMENT Risk monitoring :Assess each identified risks regularly to decide whether or not it is becoming less or more probable.

Also assess whether the effects of the risk have changed.

Each key risk should be discussed at management progress meetings.48Data from Audits and ReviewsNotes to Instructor:RISK INDICATORS