Download Software Process and Project Management and more Exercises Project Management in PDF only on Docsity!
SOFTWARE PROCESS & PROJECT
MANAGEMENT
[R17A0539]
LECTURE NOTES
B.TECH IV YEAR – II SEM (R17)
DEPARTMENT OF
COMPUTER SCIENCE AND ENGINEERING
MALLA REDDY COLLEGE OF ENGINEERING &
TECHNOLOGY
(Autonomous Institution – UGC, Govt. of India) Recognized under 2(f) and 12 (B) of UGC ACT 1956 (Affiliated to JNTUH, Hyderabad, Approved by AICTE - Accredited by NBA & NAAC – ‘A’ Grade - ISO 9001: Certified) Maisammaguda, Dhulapally (Post Via. Hakimpet), Secunderabad – 500100, Telangana State, India
SYLLABUS
MALLA REDDY COLLEGE OF ENGINEERING AND TECHNOLOGY
IV Year B. Tech CSE - IISem L T/P/DC 4 - /-/- 4
Core Elective 6
(R17A0539)
Software Process & Project Management
OBJECTIVES:
The goals of the course are as follows:
- To learn the importance of software process maturity & understand related concepts.
- Understanding the specific roles within a software organization as related to project and process management
- Understanding the basic infrastructure competences (e.g., process modeling and measurement)
- Understanding the basic steps of project planning, project management, quality assurance, and process management and their relationships. UNIT I Software Process Maturity Software maturity Framework , Principles of Software Process Change, Software Process Assessment, The Initial Process, The Repeatable Process, The Defined Process, The Managed Process, TheOptimizingProcess.ProcessReferenceModelsCapabilityMaturityModel(CMM),CMMI, PCMM, PSP,TSP. UNIT II Software Project Management Renaissance Conventional Software Management, Evolution of SoftwareEconomics,ImprovingSoftwareEconomics,Theoldwayandthenewway.Life-Cycle Phases and Process artifacts Engineering and Production stages, inception phase, elaboration phase, construction phase, transition phase, artifact sets, management artifacts, engineering artifacts and pragmatic artifacts, model based software architectures. UNIT III Workflows and Checkpoints of process Software process workflows, Iteration workflows, Major milestones, Minor milestones, Periodic status assessments. Process Planning Work break down structures, Planning guidelines, cost and schedule estimating process, iteration planning process, Pragmatic planning. UNIT IV Project Organizations Line-of- business organizations, project organizations, evolution of organizations, process automation. Project Control and process instrumentation The seven core metrics, management indicators, quality indicators, life-cycle expectations, Pragmatic software metrics, and metrics automation. UNIT V CCPDS-R Case Study and Future Software Project Management Practices Modern Project Profiles, Next-Generation software Economics, Modern Process Transitions. TEXT BOOKS: 1. ManagingtheSoftwareProcess,WattsS.Humphrey,PearsonEducation. 2. SoftwareProjectManagement,WalkerRoyce,PearsonEducation. REFERENCE BOOKS:
- Effective Project Management: Traditional, Agile, Extreme, Robert Wysocki, Sixth edition, Wiley India,rp2011.
- An Introduction to the Team Software Process, Watts S. Humphrey, Pearson Education,
UNIT I Software Process Maturity Software maturity Framework : Fundamentally, software development must be predictable. The software process is the set of tools, methods, and practices we use to produce a software product. The objectives of software process management are to produce products according to plan while simultaneously improving the organization’s capability to produce better products. The basic principles are those of statistical process control. A process is said to be stable or under statistical control if its future performance is predictable within established statistical limits.When a process is under statistical control, repeating the work in roughly the same way will produce roughly the same result. To obtain consistently better results, it is necessary to improve the process. If the process is not under statistical control, sustained progress is not possible until it is. Lord Kelvin - “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced the stage of science.” (But, your numbers must be reasonably meaningful.) The mere act of measuring human processes changes them because of people’s fears, and so forth. Measurements are both expensive and disruptive; overzealous measurements can disrupt the process under study. Principles of Software Process Change : People: •The best people are always in short supply •you probably have about the best team you can get right now. •With proper leadership and support, most people can do much better than they are currently doing Design: •Superior products have superior design. Successful products are designed by people who understand the application (domain engineer). •A program should be viewed as executable knowledge. Program designers should have application knowledge. The Six Basic Principles of Software Process Change : •Major changes to the process must start at the top. •Ultimately, everyone must be involved. •Effective change requires great knowledge of the current process •Change is continuous
•Software process changes will not be retained without conscious effort and periodic reinforcement •Software process improvement requires investment Continuous Change : •Reactive changes generally make things worse •Every defect is an improvement opportunity •Crisis prevention is more important than crisis recovery Software Processes Changes Won’t Stick by Themselves The tendency for improvements to deteriorate is characterized by the term entrophy (Webster’s: a measure of the degree of disorder in a...system; entrophy always increases and available energy diminishes in a closed system.). New methods must be carefully introduced and periodically monitored, or they to will rapidly decay. Human adoption of new process involves four stages:
- Installation - Initial training
- Practice - People learn to perform as instructed
- Proficiency - Traditional learning curve
- Naturalness - Method ingrained and performed without intellectual effort. It Takes Time, Skill, and Money! •To improve the software process, someone must work on it •Unplanned process improvement is wishful thinking •Automation of a poorly defined process will produce poorly defined results •Improvements should be made in small steps •Train!!!! Some Common Misconceptions about the Software Process •We must start with firm requirements •If it passes test it must be OK •Software quality can’t be measured •The problems are technical •We need better people •Software management is different Software Process Assessment Process assessments help software organizations improve themselves by identifying their crucial problems and establishing improvement priorities. The basic assessment objectives are: •Learn how the organization works •Identify its major problems •Enroll its opinion leaders in the change process The essential approach is to conduct a series of structured interviews with key people in the organization to learn their problems, concerns, and creative ideas. ASSESSMENT OVERVIEW A software assessment is not an audit. Audit are conducted for senior managers who suspect problems and send in experts to uncover them. A software process assessment is a review of
Organizations at Level 1 can improve their performance by instituting basic project controls. The most important ones are •Project management •Management oversight •Quality assurance •Change control The Repeatable Process (Level 2) This level provides control over the way the organization establishes plans and commitments. This control provides such an improvement over Level 1 that the people in the organization tend to believe they have mastered the software problem. This strength, however, stems from their prior experience in doing similar work. Level 2 organizations face major risks when presented with new challenges. Some major risks: •New tools and methods will affect processes, thus destroying the historical base on which the organization lies. Even with a defined process framework, a new technology can do more harm than good. •When the organization must develop a new kind of product, it is entering new territory. •Major organizational change can be highly disruptive. At Level 2, a new manager has no orderly basis for understanding an organization’s operation, and new members must learn the ropes by word of mouth. Key actions required to advance from Repeatable to the next stage, the Defined Process, are: •Establish a process group: A process group is a technical resource that focuses heavily on improving software processes. In most software organizations, all the people are generally devoted to product work. Until some people are assigned full-time to work on the process, little orderly progress can be made in improving it. •Establish a software development process architecture (or development cycle) that describes the technical and management activities required for proper execution of the development process. The architecture is a structural decomposition of the development cycle into tasks, each of which has a defined set of prerequisites, functional decompositions, verification procedures, and task completion specifications. •Introduce a family of software engineering methods and technologies. These include design and code inspections, formal design methods, library control systems, and comprehensive testing methods. Prototying and modern languages should be considered. The Defined Process (Level 3) The organization has the foundation for major and continuing change. When faced with a crisis, the software teams will continue to use the same process that has been defined. However, the process is still only qualitative; there is little data to indicate how much is accomplished or how effective the process is. There is considerable debate about the value of software process measurements and the best one to use. The key steps required to advance from the Defined Process to the next level are: •Establish a minimum set of basic process measurements to identify the quality and cost parameters of each process step. The objective is to quantify the relative costs and benefits of each major process activity, such as the cost and yield of error detection and correction methods. •Establish a process database and the resources to manage and maintain it. Cost and yield data should be maintained centrally to guard against loss, to make it available for all projects, and to facilitate process quality and productivity analysis. Provide sufficient process resources to gather and maintain the process data and to advise project members on its use. Assign skilled professionals to monitor the quality of the data before entry into the database and to provide guidance on the analysis methods and interpretation.
•Assess the relative quality of each product and inform management where quality targets are not being met. Should be done by an independent quality assurance group. The Managed Process (Level 4) Largest problem at Level 4 is the cost of gathering data. There are many sources of potentially valuable measure of the software process, but such data are expensive to collect and maintain. Productivity data are meaningless unless explicitly defined. For example, the simple measure of lines of source code per expended development month can vary by 100 times or more, depending on the interpretation of the parameters When different groups gather data but do not use identical definitions, the results are not comparable, even if it makes sense to compare them. It is rare when two processes are comparable by simple measures. The variations in task complexity caused by different product types can exceed five to one. Similarly, the cost per line of code for small modifications is often two to three times that for new programs. Process data must not be used to compare projects or individuals. Its purpose is too illuminate the product being developed and to provide an informed basis for improving the process. When such data are used by management to evaluate individuals or terms, the reliability of the data itself will deteriorate. The two fundamental requirements for advancing from the Managed Process to the next level are: •Support automatic gathering of process data. All data is subject to error and omission, some data cannot be gathered by hand, and the accuracy of manually gathered data is often poor. •Use process data to analyze and to modify the process to prevent problems and improve efficiency. The Optimizing Process (Level 5) To this point software development managers have largely focused on their products and will typically gather and analyze only data that directly relates to product improvement. In the Optimizing Process, the data are available to tune the process itself. For example, many types of errors can be identified far more economically by design or code inspections than by testing. However, some kinds of errors are either uneconomical to detect or almost impossible to find except by machine. Examples are errors involving interfaces, performance, human factors, and error recovery. So, there are two aspects of testing: removal of defects and assessment of program quality. To reduce the cost of removing defects, inspections should be emphasized. The role of functional and system testing should then be changed to one of gathering quality data on the program. This involves studying each bug to see if it is an isolated problem or if it indicates design problems that require more comprehensive analysis. With Level 5, the organization should identify the weakest elements of the process and fix them. Data are available to justify the application of technology to various critical tasks, and numerical evidence is available on the effectiveness with which the process has been applied to any given product. Process reference models The process framework or reference model acts as an interface between the way the content is organized and the way work is performed. A uniform process model organized under a process reference model makes business modeling and systems designing much easier. Capability Maturity Model ( CMM )
approved, tailored version of the organization's standard software process for developing,testing and maintaining the application. Level Four: Managed - Management can effectively control the software development effort using precise measurements. At this level, organization set a quantitative quality goal for both software process and software maintenance. At this maturity level, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving process performance through both incremental and innovative technological improvements. At this level, changes to the process are to improve the process performance and at the same time maintaining statistical probability to achieve the established quantitative process-improvement objectives. What is CMMI? CMM Integration project was formed to sort out the problem of using multiple CMMs. CMMI Product Team's mission was to combine three Source Models into a single improvement framework to be used by the organizations pursuing enterprise-wide process improvement. These three Source Models are : Capability Maturity Model for Software (SW-CMM) - v2.0 Draft C Electronic Industries Alliance Interim Standard (EIA/IS) - 731 Systems Engineering Integrated Product Development Capability Maturity Model (IPD-CMM) v0. CMM Integration: - builds an initial set of integrated models. - improves best practices from source models based on lessons learned. - establishes a framework to enable integration of future models. Following are obvious objectives of CMMI: Produce quality products or services: The process-improvement concept in CMMI models evolved out of the Deming, Juran, and Crosby quality paradigm: Quality products are a result of quality processes. CMMI has a strong focus on quality- related activities including requirements management, quality assurance, verification, and validation. Create value for the stockholders: Mature organizations are more likely to make better cost and revenue estimates than those with less maturity, and then perform in line with those estimates. CMMI supports quality products, predictable schedules, and effective measurement to support management in making accurate and defensible forecasts. This process maturity can guard against project performance problems that could weaken the value of the organization in the eyes of investors. Enhance customer satisfaction: Meeting cost and schedule targets with high-quality products that are validated against customer needs is a good formula for customer satisfaction. CMMI addresses all of these ingredients through its emphasis on planning, monitoring, and measuring, and the improved predictability that comes with more capable processes.
The CMM Integration is a model that has integrated several disciplines/bodies of knowledge. Currently there are four bodies of knowledge available to you when selecting a CMMI model. Systems Engineering Systems engineering covers the development of complete systems, which may or may not include software. Systems engineers focus on transforming customer needs, expectations, and constraints into product solutions and supporting these product solutions throughout the entire lifecycle of the product. Software Engineering Software engineering covers the development of software systems. Software engineers focus on the application of systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software. Integrated Product and Process Development Integrated Product and Process Development (IPPD) is a systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs, expectations, and requirements. The processes to support an IPPD approach are integrated with the other processes in the organization. If a project or organization chooses IPPD, it performs the IPPD best practices concurrently with other best practices used to produce products (e.g., those related to systems engineering). That is, if an organization or project wishes to use IPPD, it must select one or more disciplines in addition to IPPD. Supplier Sourcing As work efforts become more complex, project managers may use suppliers to perform functions or add modifications to products that are specifically needed by the project. When those activities are critical, the project benefits from enhanced source analysis and from monitoring supplier activities before product delivery. Under these circumstances, the supplier sourcing discipline covers the acquisition of products from suppliers. Similar to IPPD best practices, supplier sourcing best practices must be selected in conjunction with best practices used to produce products. CMMI Discipline Selection Selecting a discipline may be a difficult step and depends on what an organization wants to improve. If you are improving your systems engineering processes, like Configuration Management, Measurement and Analysis, Organizational Process Focus, Project Monitoring and Control, Process and Product Quality Assurance, Risk Management, Supplier Agreement Management etc., then you should select Systems engineering (SE) discipline. The discipline amplifications for systems engineering receive special emphasis.
Continuous Representation Continuous representation is the approach used in the SECM and the IPD-CMM. This approach allows an organization to select a specific process area and make improvements based on it. The continuous representation uses Capability Levels to characterize improvement relative to an individual process area. CMMI Continuous Representation Allows you to select the order of improvement that best meets your organization's business objectives and mitigates your organization's areas of risk. Enables comparisons across and among organizations on a process-area-by-process- area basis. Provides an easy migration from EIA 731 (and other models with a continuous representation) to CMMI. Thus Continuous Representation provides flexibility to organizations to choose the processes for improvement, as well as the amount of improvement required. CMMI Continuous Structure The following picture illustrates the CMMI Continuous Model Structure.
Continuous vs Staged Representations Continuous Representation Staged Representation Process areas are organized by process area categories. Process areas are organized by maturity levels. Improvement is measured using capability levels. Capability levels measure the maturity of a particular process across an organization; it ranges from 0 through 5. Improvement is measured using maturity levels. Maturity levels measure the maturity of a set of processes across an organization: it ranges from 1 through 5. There are two types of specific practices: base and advanced. All specific practices appear in the continuous representation. There is only one type of specific practice. The concepts of base and advanced practices are not used. All specific practices appear in the staged representation except when a related base-advanced pair of practices appears in the continuous representation, in which case only the advanced practice appears in the staged representation.
Now we will learn the details about each maturity level. Next section will list down all the process areas related to these maturity levels. Maturity Level Details Maturity levels consist of a predefined set of process areas. The maturity levels are measured by the achievement of the specific and generic goals that apply to each predefined set of process areas. The following sections describe the characteristics of each maturity level in detail. Maturity Level 1 Initial At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment. Success in these organizations depend on the competence and heroics of the people in the organization and not on the use of proven processes. Maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects. Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes. Maturity Level 2 Managed At maturity level 2, an organization has achieved all the specific and generic goals of the maturity level 2 process areas. In other words, the projects of the organization have ensured that requirements are managed and that processes are planned, performed, measured, and controlled. The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.
At maturity level 2, requirements, processes, work products, and services are managed. The status of the work products and the delivery of services are visible to management at defined points. Commitments are established among relevant stakeholders and are revised as needed. Work products are reviewed with stakeholders and are controlled. The work products and services satisfy their specified requirements, standards, and objectives. Maturity Level 3 Defined At maturity level 3, an organization has achieved all the specific and generic goals of the process areas assigned to maturity levels 2 and 3. At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. A critical distinction between maturity level 2 and maturity level 3 is the scope of standards, process descriptions, and procedures. At maturity level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At maturity level 3, the standards, process descriptions, and procedures for a project are tailored from the organization's set of standard processes to suit a particular project or organizational unit. The organization's set of standard processes includes the processes addressed at maturity level 2 and maturity level 3. As a result, the processes that are performed across the organization are consistent except for the differences allowed by the tailoring guidelines. Another critical distinction is that at maturity level 3, processes are typically described in more detail and more rigorously than at maturity level 2. At maturity level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process, its work products, and its services. Maturity Level 4 Quantitatively Managed At maturity level 4, an organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, and 4 and the generic goals assigned to maturity levels 2 and 3. At maturity level 4, sub-processes are selected that significantly contribute to the overall process performance. These selected sub-processes are controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the processes. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance are understood in statistical terms and are managed throughout the life of the processes. For these processes, detailed measures of process performance are collected and statistically analyzed. Special causes of process variation are identified and, where appropriate, the sources of special causes are corrected to prevent future occurrences.
Maturity Levels and Process Areas Here is a list of all the corresponding process areas defined for a software organization. These process areas may be different for different organization. Level Focus Key Process Area Result 5 Optimizing Continuous Process Improvement Organizational Innovation and Deployment Causal Analysis and Resolution Highest Quality / Lowest Risk 4 Quantitatively Managed Quantitatively Managed Organizational Process Performance Quantitative Project Management Higher Quality / Lower Risk 3 Defined Process Standardization Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Mgmt (with IPPD extras) Risk Management Decision Analysis and Resolution Integrated Teaming (IPPD only) Org. Environment for Integration (IPPD only) Integrated Supplier Management (SS Medium Quality / Medium Risk
only) 2 Managed Basic Project Management Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Low Quality / High Risk 1 Initial Process is informal and Adhoc Lowest Quality / Highest Risk A capability level is a well-defined evolutionary plateau describing the organization's capability relative to a process area. A capability level consists of related specific and generic practices for a process area that can improve the organization's processes associated with that process area. Each level is a layer in the foundation for continuous process improvement. Thus, capability levels are cumulative, i.e., a higher capability level includes the attributes of the lower levels. In CMMI models with a continuous representation, there are six capability levels designated by the numbers 0 through 5. 0 − Incomplete 1 − Performed 2 − Managed 3 − Defined 4 − Quantitatively Managed 5 − Optimizing A short description of each capability level is as follows − Capability Level 0: Incomplete An "incomplete process" is a process that is either not performed or partially performed. One or more of the specific goals of the process area are not satisfied and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.
