Lecture Materials > JNTU College of Engineering, Hyderabad ISO 9001  SPPM Digital Notes IT LECTURE NOTES ON SOFTWARE PROCESS AND PROJECT MANAGEMENT

Document Content and Description Below

JNTU College of Engineering, Hyderabad ISO 9001  SPPM Digital Notes IT LECTURE NOTES ON SOFTWARE PROCESS AND PROJECT MANAGEMENT IV B. Tech I semester (CS734PE) Prepared by Mrs. RASH... MI Assistant Professor DEPARTMENT OF INFORMATION TECHNOLOGY   SYLLABUS 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, The Optimizing Process. Process Reference Models Capability Maturity Model (CMM), CMMI, PCMM, PSP, TSP). UNIT - II Software Project Management Renaissance Conventional Software Management, Evolution of Software Economics, Improving Software Economics, The old way and the new way. 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 breakdown 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, 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. Managing the Software Process, Watts S. Humphrey, Pearson Education 2. Software Project Management, Walker Royce, Pearson Education REFERENCES: 1. An Introduction to the Team Software Process, Watts S. Humphrey, Pearson Education, 2000 Process Improvement essentials, James R. Persse, O’Reilly, 2006 2. Software Project Management, Bob Hughes & Mike Cotterell, fourth edition, TMH, 2006 3. Applied Software Project Management, Andrew Stellman & Jennifer Greene, O’Reilly, 2006. 4. Head First PMP, Jennifer Greene & Andrew Stellman, O’Reilly, 2007 5. Software Engineering Project Management, Richard H. Thayer & Edward Yourdon, 2 nd edition, Wiley India, 2004. 6. Agile Project Management, Jim Highsmith, Pearson education, 2004. Course Objective : • To acquire knowledge on software process management • To acquire managerial skills for software project development • To understand software economics Course Outcomes : • Gain Knowledge of software economics, phases in the life cycle of software development, project organization, project control and process instrumentation. • Analyze the major and minor milestones, artifacts and metrics from management and technical perspective • Design and develop software product using conventional and modern principles of software project management COURSE OUTCOMES MAPPING WITH PROGRAM OUTCOMES Course PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 Outcome CO1    CO2    CO3     CO4     CO5    INDEX S.NO TITLE PAGE NO UNIT – I 1.1 Software Process Maturity Software maturity Framework 1 1.2 Principles of Software Process Change, 14 1.3 Software Process Assessment 16 1.4 Process Reference Models Capability Maturity Model (CMM), 21 1.5 CMMI 23 1.6 PCMM 25 1.7 PSP 29 1.8 TSP 33 UNIT – II 2.1 Conventional Software Management 35 2.2 Evolution of Software Economics 42 2.3 Improving Software Economics 46 2.4 Life-Cycle Phases 55 2.5 Engineering and Production stages 55 2.6 Inception phase 57 2.7 Elaboration phase 57 2.8 Construction phase 58 2.9 Transition phase 59 2.10 Artifact of the process 60 2.11 Engineering Artifacts and Pragmatic Artifacts 69 2.12 Model based software architecture 72 UNIT - III 3.1. Workflow of the process 76 3.2 Iteration workflows 80   3.3 Major milestones 82 3.4 Minor milestones 85 3.5 Periodic status assessments 86 3.6 Process Planning Work breakdown structures 89 3.7 Planning guidelines 92 3..8 Cost and schedule estimating process 93 3.9 Iteration planning process 95 3.10 Pragmatic planning 96 UNIT - IV 4.1. Project Organizations Line-of- business organizations 97 4.2 Project organizations, 98 4.3 Evolution of organizations 102 4.4 Process automation 103 4.5 Project Control and process instrumentation The seven-core metrics 113 4.6 Management indicators 114 4.7 Quality indicators 116 4.8 Life-cycle expectations 117 4.9 Pragmatic software metrics – Metrics automation 118 UNIT - V 5.1 CCPDS-R Case Study 121 5.2 Future Software Project Management 122 5.3 Modern Project Profiles 124 5.4 Next-Generation software Economics 127 5.5 Modern Process Transitions 130 ASSIGNMENT QUESTION 132 TUTORIAL QUESTIONS 133 UNIT WISE QUESTIONS 134 OBJECTIVE QUESTIONS 136 EXTERNAL PAPERS 144 REFERENCES, E-LINKS, WEBSITES 147 Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 1 UNIT - I Software Process Maturity Software maturity Framework Introduction to Software Project Management “Project Management is the discipline of organizing and managing resources (e.g. people) in such a way that the project is completed within defined scope, quality, time and cost constraints. A project is a temporary and one-time endeavor undertaken to create a unique product or service, which brings about beneficial change or added value.” The goal of software project management is to understand, plan, measure and control the project such that it is delivered on time and on budget. This involves gathering requirements, managing risk, monitoring and controlling progress, and following a software development process. Software project management requires trained and experienced Software Engineers in order to increase the likelihood of project success because software development for large projects is extremely complex and following strict engineering principles will help reduce the risks associated with the project. Software project management is extremely important for the following reasons:  Software development is highly unpredictable: [as of 2007?] only about 10% of projects are delivered within initial budget and on schedule.  Management has a greater effect on the success or failure of a project than technology advances.  Too often there is too much scrap and rework. The entire process is very immature, not enough reuse. According to the 10th edition of the annual CHAOS report from The Standish Group, only 34% of projects are completed successfully. While this actually represents a huge improvement, there is obviously still room for more! Why have things started to get better? Standish Chairman Jim Johnson says, The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward. Project failure in itself is not the only reason why software management is so important. When a project fails, not only is a product not delivered, but all the money invested in the product is also lost. Without proper software management, even completed projects will be delivered late and over budget. Take a look at some of these examples of expensive software failures. The 2004 CHAOS report, entitled CHAOS Chronicles,• found total U.S. project waste to be $55 billion, made up of $38 billion in lost dollar value and $17 billion in cost overruns. Total project spending was found to be $255 billion in the 2004 report. Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 2 In 1994, The Standish Group estimated U.S. IT projects wasted $140 billion $80 billion of that from failed projects” out of a total of $250 billion in project spending. If the risk of failure and loss of money is not enough to convince you of the importance of proper software management, consider that some software will also put the lives of people at risk. Go read Software Horror Stories or History’s Worst Software Bugs to see some examples. failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. So why does software fail anyways? Here is the list from the IEEE Spectrum Unrealistic or unarticulated project goals Inaccurate estimates of needed resources Badly defined system requirements Poor reporting of the project’s status Unmanaged risks Poor communication among customers, developers, and users Use of immature technology Inability to handle the project’s complexity Sloppy development practices Poor project management Stakeholder politics Commercial pressures Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don’t aim to fail. When a commercial plane crashes, investigators look at many factors, such as the weather, maintenance records, the pilot’s disposition and training, and cultural factors within the airline. Similarly, we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures. THE PILOT’S ACTIONS JUST BEFORE a plane crashes are always of great interest to investigators. That’s because the pilot is the ultimate decision-maker, responsible for the safe operation of the craft. Similarly, project managers play a crucial role in software projects and can be a major source of errors that lead to failure. Bad decisions by project managers are probably the single greatest cause of software failures today. Poor technical management, by contrast, can lead to technical errors, but those can generally be isolated and fixed. However, a bad project management decision such as hiring too few programmers or picking the wrong type of contract can wreak havoc. Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 3 Project management decisions are often tricky precisely because they involve tradeoffs based on fuzzy or incomplete knowledge. Estimating how much an IT project will cost and how long it will take is as much art as science. The larger or more novel the project, the less accurate the estimates. It’s a running joke in the industry that IT project estimates are at best within 25 percent of their true value 75 percent of the time. Poor project management takes many other forms, including bad communication, which creates an inhospitable atmosphere that increases turnover; not investing in staff training; and not reviewing the project’s progress at regular intervals. Any of these can help derail a software project. Another problem which distinguishes software engineering from other engineering fields is the fact that software is not concrete. There is a common misconception that software can be easily changed to do anything no matter which stage the project is currently at. If construction on a building or bridge is nearly complete, people understand that it is too late to make significant changes to the architecture or design. However with software, clients tend to have the impression that making changes are always easy even though the end result could be the equivalent to tearing down a nearly completed building! A common misconception is that developing software means writing code, which is definitely not the case. Code writing itself only counts for about 40% of software development. There are many other important steps such as requirements, configuration, deployment and maintenance. The main goal of software project management is to try and reduce the risks involved with a project such that the project can then finish on budget and on time with all of the features desired by the clients. Project management helps us achieve the following  Estimate the budget needed to complete the project before it starts and to monitor the progress so that at any given time we know how much a project has cost and how much more it will cost.  Estimate the time needed to complete at project before it starts and to monitor the progress so that at any given time we know how much time is left before completion.  Estimate which features can be developed in the given time and cost frame.  Monitors the project progress and so we know which features have been completed and which ones will be completed before the end of the project.  Software delivered must provide all the features specified in the requirements (feature complete). Project management therefore helps project managers re-negotiate features and requirements. Software users are among the worst treated customer in engineering. It is taken for granted without much complaint that software has bugs, crashes from time to time, doesn’t work occasionally and is too complicated to install and use. Quality must be a given part of the scope; the completed features must be of high quality. Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 4 Many companies are applying the ideas of quality or process improvement across their organization. Software process improvement is the application of these concepts to software development. 1. Plan- Define the problem State improvement objectives 2. Do- Identify possible problem causes Establish baselines Test changes 3. Check- Collect data Evaluatedata 4. Act-Implement system change Determine effectiveness Shewart’s Plan-Act-Check-Do paradigm is the basis for the SEI process improvement program. Shewart’s paradigm, applied to both the software product and process, generally consists of the following activities: Plan The SEI capability maturity model is a general framework or plan for developing five increasingly improved levels (initial, repeatable, defined, managed, and optimizing) of software process maturity . Because the CMM is designed to be generic, each organization must customize i t s process improvement plan for i t s own application(s), environment, and company organization. The five levels are designed as a logical progression, so each level must be achieved, in order, from one to five. I t is not possible to skip levels. Act Because software is not produced by a manufacturing process, software designers must both strive to meet the users’ functional requirements for the product and design for correct implementation and easy maintainability. There will usually be many examples of process improvements that are needed. Efforts should focus on high-leverage points, and action plans to correct the defects must be evaluated for effectiveness. Software tools to automate and standardize the process may aid in institutionalizing improvements, but tools are not a cure-all. Check Software inspections and peer reviews are the major product control mecha- nism used. Quantifiable inspections results such as change requests provide the foun dation for measurable process control and improvement. Audits are the most usual process verification process. Auditors need to examine not only whether the standards, procedures, and tools are adequate, but they also to see how well the project is following the prescribed process plans. Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 5 Do Software quality control is often specified both by the customer acceptance criteria in the contract or requirements specification and by whether the software product meets written standards. Software measures are used to measure product quality in a quantifiable way. The SEI has already published a core set of measures which can be used as a basis and enhanced by the organization as needed, though these measures are s till under active development. The most common process quality control approach is tracking actual against expected performance. Causes for significant deviation from the plan are found and corrected. In the later stages of the maturity model, the organization strives to actively prevent problems and errors rather than to wait to detect them in the later phases of the software development project. 2.The Software Engineering Institute Capability Maturity Model Since project management is so important, we need to be able to rank organizations in terms of their software capability and maturity. We use the Capability and Maturity Model (CMM) to achieve this. CMM ranks the software development process of a firm by using 5 levels of maturity Level 1 – Initial At maturity level 1, processes are usually ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes. In spite of this ad hoc, chaotic environment, 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 again. Level 1 software project success depends on having high quality people. Level 2 – Repeatable [Managed] At maturity level 2, software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule. Process discipline helps 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. Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks). Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates. Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 6 Level 3 – Defined The organization set of standard processes, which are the basis for level 3, are established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization set of standard processes according to tailoring guidelines. The organization management establishes process objectives based on the organization set of standard processes and ensures that these objectives are appropriately addressed. A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At 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 level 3, the standards, process descriptions, and procedures for a project are tailored from the organization set of standard processes to suit a particular project or organizational unit. Effective project management system is implemented with the help of good project management software. Level 4 – Quantitatively Managed Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Organizations at this level set quantitative quality goals for both software process and software maintenance. Sub processes are selected that significantly contribute to overall process performance. These selected sub processes are controlled using statistical and other quantitative techniques. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable. Level 5 – Optimizing Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization set of standard processes are targets of measurable improvement activities. Process improvements to address common causes of process variation and measurably improve the organization processes are identified, evaluated, and deployed. Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. Software Process and Project Management Dept. of CSE Malla Reddy Engineering College for Women(Autonomous Institution – UGC, Govt. of India) Page 7 The organization ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process [Show More]

Last updated: 2 years ago

Preview 1 out of 169 pages