Software Project Management
[R15A0543]
LECTURE NOTES
B.TECH IV YEAR –II SEM(R15)
(2018-19)
DEPARTMENT OF
COMPUTER SCIENCE AND ENGINEERING
Chaudhary Charan Singh University Meerut
(Formerly, Meerut University) | NAAC A++ Accredited
1
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Efficient Project Management Software, Lecture notes of Software Project Management
The software encompasses a range of features aimed at optimizing project management processes. It covers areas such as task assignment, progress monitoring, resource allocation, deadline tracking, and team collaboration. Additionally, it offers reporting and analytics tools to provide insights for informed decision-making. The software also includes functionalities for risk assessment and mitigation, as well as communication tools for seamless team coordination. Overall, it serves as a comprehensive solution for efficiently managing software projects from initiation to completion.
Typology: Lecture notes
2022/2023
1 / 79
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Efficient Project Management Software and more Lecture notes Software Project Management in PDF only on Docsity!
Software Project Management
[R15A0543]
LECTURE NOTES
B.TECH IV YEAR – II SEM(R15)
DEPARTMENT OF
COMPUTER SCIENCE AND ENGINEERING
Chaudhary Charan Singh University Meerut
(Formerly, Meerut University) | NAAC A++ Accredited
IV Year B. Tech. CSE – II Sem L T/P/D C 4 - /- / - 4 (R15A0543) SOFTWARE PROJECT MANAGEMENT (Core Elective-VI) Objectives: 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 Conventional Software Management : The waterfall Model, Conventional Software Management Performance, Evolution of Software Economics : software Economics. Pragmatic Software Cost Estimation. Improving Software Economics : Reducing Software Product Size, Improving Software Processes, Improving Team Effectiveness, Improving Automation, Achieving Required Quality, Peer Inspections. UNIT-II Conventional and Modern Software Management : Principles of Conventional Software Engineering, Principles of Modern Software Management, Transitioning to an interactive Process. Life Cycle Phases : Engineering and Production Stages Inception, Elaboration, Construction, Transition phases. UNIT-III Artifacts of the Process : The Artifact Sets. Management Artifacts, Engineering Artifacts, Programmatic Artifacts. Model Based Software Architectures : A Management Perspective and Technical Perspective. UNIT-IV Flows of the Process : Software Process Workflows. Inter Trans Workflows. Checkpoints of the Process : Major Mile Stones, Minor Milestones, Periodic Status Assessments. Interactive Process Planning: Work Breakdown Structures, Planning Guidelines, Cost and Schedule Estimating. Interaction Planning Process, Pragmatic Planning. UNIT-V Project Organizations and Responsibilities: Line-of-Business Organizations, Project Organizations, and Evolution of Organizations. Process Automation: Building Blocks, the Project Environment. Project Control and Process Instrumentation : Server Care Metrics, Management Indicators, Quality Indicators, Life Cycle Expectations Pragmatic Software
INDEX
UNIT NO TOPIC PAGE NO
I
Conventional Software Management 01 - 06 Evolution of Software Economics 07 - 10 Improving Software Economics 10 - 18 II Conventional and Modern Software Management 19 - 23 Life cycle phases 24 - 28 III Artifacts of the process 29 – 39 Model based software architectures 40 – 42 IV Work Flows of the process 43 – 47 Checkpoints of the process 48 – 52 Iterative Process Planning 52 – 60 V Project Organizations and Responsibilities 61 – 63 Process Automation 64 – 69 Project Control and Process Instrumentation 69 - 75
UNIT – I
Conventional Software Management: The waterfall model, conventional software Management performance. Evolution of Software Economics: Software Economics, pragmatic software cost estimation. Improving Software Economics : Reducing Software product size, improving software processes, improving team effectiveness, improving automation, Achieving required quality, peer inspections.
1. Conventional software management Conventional software management practices are sound in theory, but practice is still tied to archaic (outdated) technology and techniques. Conventional software economics provides a benchmark of performance for conventional software manage- ment principles. The best thing about software is its flexibility : It can be programmed to do almost anything. The worst thing about software is also its flexibility : The "almost anything" characteristic has made it difficult to plan, monitors, and control software development. Three important analyses of the state of the software engineering industry are 1. Software development is still highly unpredictable. Only about 10% of software projects are delivered successfully within initial budget and schedule estimates.
- Management discipline is more of a discriminator in success or failure than are technology advances.
- The level of software scrap and rework is indicative of an immature process. All three analyses reached the same general conclusion: The success rate for software projects is very low. The three analyses provide a good introduction to the magnitude of the software problem and the current norms for conventional software management performance. 1. T H E WAT E R FA L L M O D E L Most software engineering texts present the waterfall model as the source of the "conventional" software process. 1. IN THEORY It provides an insightful and concise summary of conventional software management Three main primary points are
- There are two essential steps common to the development of computer programs: analysis and coding. Waterfall Model part 1: The two basic steps to building a program.
- In order to manage and control all of the intellectual freedom associated with software development, one must introduce several other "overhead" steps, including system requirements definition, software requirements definition, program design, and testing. These steps supplement the analysis and coding steps. Below Figure illustrates the resulting project profile and the basic steps in developing a large-scale program. Analysis and coding both involve creative work that directly contributes to the usefulness of the end product. Analysis Coding
that is relatively small with respect to the overall effort. In the first version, the team must have a special broad competence where they can quickly sense trouble spots in the design, model them, model alternatives, forget the straightforward aspects of the design that aren't worth studying at this early point, and, finally, arrive at an error-free program_._
4. Plan, control, and monitor testing. Without question, the biggest user of project resources-manpower, computer time, and/or management judgment-is the test phase. This is the phase of greatest risk in terms of cost and schedule. It occurs at the latest point in the schedule, when backup alternatives are least available, if at all. The previous three recommendations were all aimed at uncovering and solving problems before entering the test phase. However, even after doing these things, there is still a test phase and there are still important things to be done, including: ( 1 ) employ a team of test specialists who were not responsible for the original design; ( 2 ) employ visual inspections to spot the obvious errors like dropped minus signs, missing factors of two, jumps to wrong addresses (do not use the computer to detect this kind of thing, it is too expensive); ( 3 ) test every logic path; ( 4 ) employ the final checkout on the target computer. 5.Involve the customer. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. There are three points following requirements definition where the insight, judgment, and commitment of the customer can bolster the development effort. These include a "preliminary software review" following the preliminary program design step, a sequence of "critical software design reviews" during program design, and a "final software acceptance review". 2. IN PRACTICE Some software projects still practice the conventional software management approach. It is useful to summarize the characteristics of the conventional process as it has typically been applied, which is not necessarily as it was intended. Projects destined for trouble frequently exhibit the following symptoms: Protracted integration and late design breakage. Late risk resolution. Requirements-driven functional decomposition. Adversarial (conflict or opposition) stakeholder relationships. Focus on documents and review meetings. Protracted Integration and Late Design Breakage For a typical development project that used a waterfall model management process, Figure 1 - 2 illustrates development progress versus time. Progress is defined as percent coded, that is, demonstrable in its target form. The following sequence was common: Early success via paper designs and thorough (often too thorough) briefings. Commitment to code late in the life cycle. Integration nightmares (unpleasant experience) due to unforeseen implementation issues and interface ambiguities. Heavy budget and schedule pressure to get the system working. Late shoe-homing of no optimal fixes, with no time for redesign. A very fragile, unmentionable product delivered late.
In the conventional model, the entire system was designed on paper, then implemented all at once, then integrated. Table 1 - 1 provides a typical profile of cost expenditures across the spectrum of software activities. Late risk resolution A serious issue associated with the waterfall lifecycle was the lack of early risk resolution. Figure 1. 3 illustrates a typical risk profile for conventional waterfall model projects. It includes four distinct periods of risk exposure, where risk is defined as the probability of missing a cost, schedule, feature, or quality goal. Early in the life cycle, as the requirements were being specified, the actual risk exposure was highly unpredictable.
The following sequence of events was typical for most contractual software efforts:
- The contractor prepared a draft contract-deliverable document that captured an intermediate artifact and delivered it to the customer for approval.
- The customer was expected to provide comments (typically within 15 to 30 days). 3.The contractor incorporated these comments and submitted (typically within 15 to 30 days) a final version for approval. This one-shot review process encouraged high levels of sensitivity on the part of customers and contractors. Focus on Documents and Review Meetings: The conventional process focused on producing various documents that attempted to describe the software product, with insufficient focus on producing tangible increments of the products themselves. Contractors were driven to produce literally tons of paper to meet milestones and demonstrate progress to stakeholders, rather than spend their energy on tasks that would reduce risk and produce quality software. Typically, presenters and the audience reviewed the simple things that they understood rather than the complex and important issues. Most design reviews therefore resulted in low engineering value and high cost in terms of the effort and schedule involved in their preparation and conduct. They presented merely a facade of progress. Table 1 - 2 summarizes the results of a typical design review. 2. CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective characterization of the state of software development.
- Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases.
- You can compress software development schedules 25% of nominal, but no more.
- For every $1 you spend on development, you will spend $2 on maintenance.
- Software development and maintenance costs are primarily a function of the number of source lines of code.
- Variations among people account for the biggest differences in software productivity.
- The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85 ; in 1985, 85:.
- Only about 15 % of software development effort is devoted to programming.
- Software systems and products typically cost 3 times as much per SLOC as individual software programs. Software-system products (i.e., system of systems) cost 9 times as much.
- Walkthroughs catch 60 % of the errors 10. 80 % of the contribution comes from 20 % of the contributors.
2.EvolutionofSoftwareEconomics
1. SOFTWARE ECONOMICS Most software cost models can be abstracted into a function of five basic parameters: size, process, personnel, environment, and required quality. 1. The size of the end product (in human-generated components), which is typically quantified in terms of the number of source instructions or the number of function points required to develop the required functionality
- The process used to produce the end product, in particular the ability of the process to avoid non- value-adding activities (rework, bureaucratic delays, communications overhead)
- The capabilities of software engineering personnel , and particularly their experience with the computer science issues and the applications domain issues of the project
- The environment , which is made up of the tools and techniques available to support efficient software development and to automate the process
- The required quality of the product, including its features, performance, reliability, and adaptability The relationships among these parameters and the estimated cost can be written as follows: Effort =(Personnel) (Environment) (Quality) ( Sizeprocess) One important aspect of software economics (as represented within today's software cost models) is that the relationship between effort and size exhibits a diseconomy of scale. The diseconomy of scale of software development is a result of the process exponent being greater than 1. 0. Contrary to most manufacturing processes, the more software you build, the more expensive it is per unit item. Figure 2 - 1 shows three generations of basic technology advancement in tools, components, and processes. The required levels of quality and personnel are assumed to be constant. The ordinate of the graph refers to software unit costs (pick your favorite: per SLOC, per function point, per component) realized by an organization. The three generations of software development are defined as follows: 1) Conventional: 1960 s and 1970 s, craftsmanship. Organizations used custom tools, custom processes, and virtually all custom components built in primitive languages. Project performance was highly predictable in that cost, schedule, and quality objectives were almost always underachieved. 2) Transition : 1980 s and 1990 s, software engineering. Organiz: 1 tions used more-repeatable processes and off- the-shelf tools, and mostly (> 70 %) custom components built in higher level languages. Some of the components (< 30 %) were available as commercial products, including the operating system, database management system, networking, and graphical user interface. 3) Modern practices : 2000 and later, software production. This book's philosophy is rooted in the use of managed and measured processes, integrated automation environments, and mostly (70%) off-the-shelf components. Perhaps as few as 30% of the components need to be custom built Technologies for environment automation, size reduction, and process improvement are not independent of one another. In each new era, the key is complementary growth in all technologies. For example, the process advances could not be used successfully without new component technologies and increased tool automation.
2. PRAGMATIC SOFTWARE COST ESTIMATION
One critical problem in software cost estimation is a lack of well-documented case studies of projects that used an iterative development approach. Software industry has inconsistently defined metrics or atomic units of measure, the data from actual projects are highly suspect in terms of consistency and comparability. It is hard enough to collect a homogeneous set of project data within one organization; it is extremely difficult to homog- enize data across different organizations with different processes, languages, domains, and so on. There have been many debates among developers and vendors of software cost estimation models and tools. Three topics of these debates are of particular interest here:
- Which cost estimation model to use?
- Whether to measure software size in source lines of code or function points.
- What constitutes a good estimate? There are several popular cost estimation models (such as COCOMO, CHECKPOINT, ESTIMACS, Knowledge Plan, Price-S, ProQMS, SEER, SLIM, SOFTCOST, and SPQR/ 20 ), CO COMO is also one of the
most open and well-documented cost estimation models. The general accuracy of conventional cost models (such as COCOMO) has been described as "within 20 % of actuals, 70 % of the time." Most real-world use of cost models is bottom-up (substantiating a target cost) rather than top-down (estimating the "should" cost). Figure 2 - 3 illustrates the predominant practice: The software project manager defines the target cost of the software, and then manipulates the parameters and sizing until the target cost can be justified. The rationale for the target cost maybe to win a proposal, to solicit customer funding, to attain internal corporate funding, or to achieve some other goal. The process described in Figure 2 - 3 is not all bad. In fact, it is absolutely necessary to analyze the cost risks and understand the sensitivities and trade-offs objectively. It forces the software project manager to examine the risks associated with achieving the target costs and to discuss this information with other stakeholders. A good software cost estimate has the following attributes: It is conceived and supported by the project manager, architecture team, development team, and test team accountable for performing the work. It is accepted by all stakeholders as ambitious but realizable. It is based on a well-defined software cost model with a credible basis. It is based on a database of relevant project experience that includes similar processes, similar technologies, similar environments, similar quality requirements, and similar people. It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed. Extrapolating from a good estimate, an ideal estimate would be derived from a mature cost model with an experience base that reflects multiple similar projects done by the same team with the same mature processes and tools.
3. ImprovingSoftwareEconomics Five basic parameters of the software cost model are 1.Reducing the size or complexity of what needs to be developed. 2. Improving the development process. 3. Using more-skilled personnel and better teams (not necessarily the same thing). 4. Using better environments (tools to automate the process). 5. Trading off or backing off on quality thresholds.
3.1.1 LANGUAGES
Universal function points (UFPs^1 ) are useful estimators for language-independent, early life-cycle estimates. The basic units of function points are external user inputs, external outputs, internal logical data groups, external data interfaces, and external inquiries. SLOC metrics are useful estimators for software after a candidate solution is formulated and an implementation language is known. Substantial data have been documented relating SLOC to function points. Some of these results are shown in Table 3 - 2. Languages expressiveness of some of today’s popular languages LANGUAGES SLOC per UFP Assembly 320 C 128 FORTAN77 105 COBOL85 91 Ada83 71 C++ 56 Ada95 55 Java 55 Visual Basic 35 Table 3 - 2
2. OBJECT-ORIENTED METHODS AND VISUAL MODELING Object-oriented technology is not germane to most of the software management topics discussed here, and books on object-oriented technology abound. Object-oriented programming languages appear to benefit both software productivity and software quality. The fundamental impact of object-oriented technology is in reducing the overall size of what needs to be developed. People like drawing pictures to explain something to others or to themselves. When they do it for software system design, they call these pictures diagrams or diagrammatic models and the very notation for them a modeling language. These are interesting examples of the interrelationships among the dimensions of improving software eco- nomics.
- An object-oriented model of the problem and its solution encourages a common vocabulary between the end users of a system and its developers, thus creating a shared understanding of the problem being solved.
- The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without destabilizing the entire development effort_._
- An object-oriented architecture provides a clear separation of concerns among disparate elements of a system, creating firewalls that prevent a change in one part of the system from rending the fabric of the entire architecture. (^1) Function point metrics provide a standardized method for measuring the various functions of a software application. The basic units of function points are external user inputs, external outputs, internal logical data groups, external data interfaces, and external inquiries.
Booch also summarized five characteristics of a successful object-oriented project.
- A ruthless focus on the development of a system that provides a well understood collection of essential minimal characteristics.
- The existence of a culture that is centered on results, encourages communication, and yet is not afraid to fail.
- The effective use of object-oriented modeling.
- The existence of a strong architectural vision.
- The application of a well-managed iterative and incremental development life cycle. 3. REUSE Reusing existing components and building reusable components have been natural software engineering activities since the earliest improvements in programming languages. With reuse in order to minimize development costs while achieving all the other required attributes of performance, feature set, and quality. Try to treat reuse as a mundane part of achieving a return on investment. Most truly reusable components of value are transitioned to commercial products supported by organizations with the following characteristics: They have an economic motivation for continued support. They take ownership of improving product quality, adding new features, and transitioning to new technologies. They have a sufficiently broad customer base to be profitable. The cost of developing a reusable component is not trivial. Figure 3 - 1 examines the economic trade-offs. The steep initial curve illustrates the economic obstacle to developing reusable components. Reuse is an important discipline that has an impact on the efficiency of all workflows and the quality of most artifacts.
In a perfect software engineering world with an immaculate problem description, an obvious solution space, a development team of experienced geniuses, adequate resources, and stakeholders with common goals, we could execute a software development process in one iteration with almost no scrap and rework. Because we work in an imperfect world, however, we need to manage engineering activities so that scrap and rework profiles do not have an impact on the win conditions of any stakeholder. This should be the underlying premise for most process improvements.
3. IMPROVING TEAM EFFECTIVENESS Teamwork is much more important than the sum of the individuals. With software teams, a project manager needs to configure a balance of solid talent with highly skilled people in the leverage positions. Some maxims of team management include the following: A well-managed project can succeed with a nominal engineering team. A mismanaged project will almost never succeed, even with an expert team of engineers. A well-architected system can be built by a nominal team of software builders. A poorly architected system will flounder even with an expert team of builders.
Boehm five staffing principles are
- The principle of top talent: Use better and fewer people
- The principle of job matching: Fit the tasks to the skills and motivation of the people available.
- The principle of career progression: An organization does best in the long run by helping its people to self-actualize.
- The principle of team balance: Select people who will complement and harmonize with one another
- The principle of phase-out: Keeping a misfit on the team doesn't benefit anyone Software project managers need many leadership qualities in order to enhance team effectiveness. The following are some crucial attributes of successful software project managers that deserve much more attention: 1. Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the right job seems obvious but is surprisingly hard to achieve. 2. Customer-interface skill. Avoiding adversarial relationships among stakeholders is a prerequisite for success. Decision-making skill. The jillion books written about management have failed to provide a clear definition of this attribute. We all know a good leader when we run into one, and decision-making skill seems obvious despite its intangible definition. Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas, transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a team direction. Selling skill. Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements against objectives. In practice, selling requires continuous negotiation, compromise, and empathy 4. IMPROVING AUTOMATION THROUGH SOFTWARE ENVIRONMENTS The tools and environment used in the software process generally have a linear effect on the productivity of the process. Planning tools, requirements management tools, visual modeling tools, compilers, editors, debuggers, quality assurance analysis tools, test tools, and user interfaces provide crucial automation support for evolving the software engineering artifacts. Above all, configuration management environments provide the foundation for executing and instrument the process. At first order, the isolated impact of tools and automation generally allows improvements of 20 % to 40 % in effort. However, tools and environments must be viewed as the primary delivery vehicle for process automation and improvement, so their impact can be much higher. Automation of the design process provides payback in quality, the ability to estimate costs and schedules, and overall productivity using a smaller team. Round-trip engineering describes the key capability of environments that support iterative development. As we have moved into maintaining different information repositories for the engineering artifacts, we need automation support to ensure efficient and error-free transition of data from one artifact to another. Forward engineering is the automation of one engineering artifact from another, more abstract representation. For example, compilers and linkers have provided automated transition of source code into executable code. Reverse engineering is the generation or modification of a more abstract representation from an existing artifact (for example, creating a visual design model from a source code representation). Economic improvements associated with tools and environments. It is common for tool vendors to make rela- tively accurate individual assessments of life-cycle activities to support claims about the potential economic impact of their tools. For example, it is easy to find statements such as the following from companies in a particular tool. Requirements analysis and evolution activities consume 40% of life-cycle costs. Software design activities have an impact on more than 50% of the resources. Coding and unit testing activities consume about 50% of software development effort and schedule.