Sakshi Education
Introduction of Models:
“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:
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?
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
Example:
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.
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:
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.
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:
Waterfall model:
The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.
Advantages of waterfall model:
Disadvantages of waterfall model:
When to use the waterfall model:
Very less customer enter action is involved during the development of the product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from document till the logic.
Program design comes first:
Insert a prelim¬inary program design phase between the software requirements generation phase and the analysis phase. By this technique, the program designer assures that the software will not fail because of storage, timing, and data flux (continuous change). As analysis proceeds in the succeeding phase, the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences. If the total resources to be applied are insufficient or if the embryonic(in an early stage of development) operational design is wrong, it will be recognized at this early stage and the iteration with requirements and preliminary design can be redone before final design, coding, and test commences. How is this program design procedure implemented? The fol¬lowing steps are required:
Begin the design process with program designers, not analysts or pro¬grammers.
Design, define, and allocate the data processing modes even at the risk of being wrong. Allocate processing functions, design the database, allo¬cate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define pre¬liminary operating procedures.
Write an overview document that is understandable, informative, and current so that every worker on the project can gain an elemental under¬standing of the system.
Document the design
The amount of documentation required on most software programs is quite a lot, certainly much more than most program¬mers, analysts, or program designers are willing to do if left to their own devices. Why do we need so much documentation? (1) Each designer must communicate with interfacing designers, managers, and possibly custom¬ers. (2) During early phases, the documentation is the design. (3) The real monetary value of documentation is to support later modifications by a separate test team, a separate maintenance team, and operations personnel who are not software literate.
Do it twice
If a computer program is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations are concerned. Note that this is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort. In the first version, the team must have a special broad com¬petence 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.
Plan, control, and monitor testing
Without question, the biggest user of project resources-manpower, computer time, and/or management judg¬ment-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 recommenda¬tions 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:
Involve the customer
For some reason, what a software design is going to do is subject to wide interpretation, even after previous agreement. 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 follow¬ing requirements definition where the insight, judgment, and commitment of the customer can bolster the development effort. These include a "prelim¬inary software review" following the preliminary program design step, a sequence of "critical software design reviews" during program design, and a "final software acceptance review".
To overcome the drawbacks of waterfall models we have another modules introduced in the software engineering or project management process
Conventional Software Management performance.
Conventional software management practices are sound in theory, but practice is still tied to archaic technol¬ogy and techniques. Conventional software economics provides a benchmark of performance for conventional software manage¬ment principles. The best thing about software is its flexibil¬ity: 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
Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective characterization of the state of software development.
The Principles of Conventional Software Engineering
There are many descriptions of engineering software "the old way." After years of software development experience, the software industry has learned many lessons and formulated many principles. This section describes one view of today's software engineering principles as a benchmark for introducing the primary themes discussed throughout the remainder of the book. The benchmark I have chosen is a brief article titled "Fifteen Principles of Software Engineering" [Davis, 1994], The article was subsequently expanded into a book [Davis, 1995] that enumerates 201 principles. Despite its title, the article describes the top 30 principles, and it is as good a summary as any of the conventional wisdom within the software industry. While I endorse much of this wisdom, I believe some of it is obsolete. Davis's top 30 principles are quoted next, in italics. For each principle, I comment on whether the perspective provided later in this book would endorse or change it. I make several assertions here that are left unsubstantiated until later chapters.
1. Make quality #1. Quality must be quantified and mechanisms put into place to motivate its achievement.
a Defining quality commensurate with the project at hand is important but is not easily done at the outset of a project. Consequently, a modern process framework strives to understand the trade-offs among features, quality, cost, and schedule as early in the life cycle as possible. Until this understanding is achieved, it is not possible to specify or manage the achievement of quality.
2. High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people.
a This principle is mostly redundant with the others.
3. Give products to customers early. No matter how hard you try to learn users' needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it.
a This is a key tenet of a modern process framework, and there must be several mechanisms to involve the customer throughout the life cycle. Depending on the domain, these mechanisms may include demonstrable prototypes, demonstration-based milestones, and alpha/beta releases.
4. Determine the problem before writing the requirements. When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and don't be blinded by the obvious solution.
a This principle is a clear indication of the issues involved with the conventional requirements specification process. The parameters of the problem become more tangible as a solution evolves. A modern process framework evolves the problem and the solution together until the problem is well enough understood to commit to full production.
4. Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an "architecture" simply because it was used in the requirements specification.
1. Evolution of Software Economics
2.1 SOFTWARE ECONOMICS
Most software cost models can be abstracted into a function of five basic parameters: , size, process, personnel, environment, and required quality.
Effort = (Personnel) (Environment)( Quality)( Size process)
One important aspect of software economics (as represented within today's software cost models) is that the relation¬ship 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:
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 pre¬dominant practice: The software project manager defines the target cost of the soft¬ware, 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 fund¬ing, 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 neces¬sary to analyze the cost risks and understand the sensitivities and trade-offs objec¬tively. 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:
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.
“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?
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
Example:
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.
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.
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.
- 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
Waterfall model:
The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.
Advantages of waterfall model:
- This model is simple and easy to understand and use.
- It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
- In this model phases are processed and completed one at a time. Phases do not overlap.
- Waterfall model works well for smaller projects where requirements are very well understood.
Disadvantages of waterfall model:
- Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
- No working software is produced until late during the life cycle.
- High amounts of risk and uncertainty.
- Not a good model for complex and object-oriented projects.
- Poor model for long and ongoing projects.
- Not suitable for the projects where requirements are at a moderate to high risk of changing.
When to use the waterfall model:
- This model is used only when the requirements are very well known, clear and fixed.
- Product definition is stable.
- Technology is understood.
- There are no ambiguous requirements
- Ample resources with required expertise are available freely
- The project is short.
Very less customer enter action is involved during the development of the product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from document till the logic.
Program design comes first:
Insert a prelim¬inary program design phase between the software requirements generation phase and the analysis phase. By this technique, the program designer assures that the software will not fail because of storage, timing, and data flux (continuous change). As analysis proceeds in the succeeding phase, the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences. If the total resources to be applied are insufficient or if the embryonic(in an early stage of development) operational design is wrong, it will be recognized at this early stage and the iteration with requirements and preliminary design can be redone before final design, coding, and test commences. How is this program design procedure implemented? The fol¬lowing steps are required:
Begin the design process with program designers, not analysts or pro¬grammers.
Design, define, and allocate the data processing modes even at the risk of being wrong. Allocate processing functions, design the database, allo¬cate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define pre¬liminary operating procedures.
Write an overview document that is understandable, informative, and current so that every worker on the project can gain an elemental under¬standing of the system.
Document the design
The amount of documentation required on most software programs is quite a lot, certainly much more than most program¬mers, analysts, or program designers are willing to do if left to their own devices. Why do we need so much documentation? (1) Each designer must communicate with interfacing designers, managers, and possibly custom¬ers. (2) During early phases, the documentation is the design. (3) The real monetary value of documentation is to support later modifications by a separate test team, a separate maintenance team, and operations personnel who are not software literate.
Do it twice
If a computer program is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations are concerned. Note that this is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort. In the first version, the team must have a special broad com¬petence 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.
Plan, control, and monitor testing
Without question, the biggest user of project resources-manpower, computer time, and/or management judg¬ment-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 recommenda¬tions 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:
- Employ a team of test specialists who were not responsible for the original design;
- 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);
- Test every logic path;
- Employ the final checkout on the target computer.
Involve the customer
For some reason, what a software design is going to do is subject to wide interpretation, even after previous agreement. 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 follow¬ing requirements definition where the insight, judgment, and commitment of the customer can bolster the development effort. These include a "prelim¬inary software review" following the preliminary program design step, a sequence of "critical software design reviews" during program design, and a "final software acceptance review".
To overcome the drawbacks of waterfall models we have another modules introduced in the software engineering or project management process
Conventional Software Management performance.
Conventional software management practices are sound in theory, but practice is still tied to archaic technol¬ogy and techniques. Conventional software economics provides a benchmark of performance for conventional software manage¬ment principles. The best thing about software is its flexibil¬ity: 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
- Software development is still highly unpredictable. Only about 10% of software projects are delivered successfully within initial budget and sched¬ule 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.
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:15.
- 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 sys¬tems) cost 9 times as much.
- Walkthroughs catch 60% of the errors 80% of the contribution comes from 20% of the contributors.
The Principles of Conventional Software Engineering
There are many descriptions of engineering software "the old way." After years of software development experience, the software industry has learned many lessons and formulated many principles. This section describes one view of today's software engineering principles as a benchmark for introducing the primary themes discussed throughout the remainder of the book. The benchmark I have chosen is a brief article titled "Fifteen Principles of Software Engineering" [Davis, 1994], The article was subsequently expanded into a book [Davis, 1995] that enumerates 201 principles. Despite its title, the article describes the top 30 principles, and it is as good a summary as any of the conventional wisdom within the software industry. While I endorse much of this wisdom, I believe some of it is obsolete. Davis's top 30 principles are quoted next, in italics. For each principle, I comment on whether the perspective provided later in this book would endorse or change it. I make several assertions here that are left unsubstantiated until later chapters.
1. Make quality #1. Quality must be quantified and mechanisms put into place to motivate its achievement.
a Defining quality commensurate with the project at hand is important but is not easily done at the outset of a project. Consequently, a modern process framework strives to understand the trade-offs among features, quality, cost, and schedule as early in the life cycle as possible. Until this understanding is achieved, it is not possible to specify or manage the achievement of quality.
2. High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people.
a This principle is mostly redundant with the others.
3. Give products to customers early. No matter how hard you try to learn users' needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it.
a This is a key tenet of a modern process framework, and there must be several mechanisms to involve the customer throughout the life cycle. Depending on the domain, these mechanisms may include demonstrable prototypes, demonstration-based milestones, and alpha/beta releases.
4. Determine the problem before writing the requirements. When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and don't be blinded by the obvious solution.
a This principle is a clear indication of the issues involved with the conventional requirements specification process. The parameters of the problem become more tangible as a solution evolves. A modern process framework evolves the problem and the solution together until the problem is well enough understood to commit to full production.
4. Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an "architecture" simply because it was used in the requirements specification.
1. Evolution of Software Economics
2.1 SOFTWARE ECONOMICS
Most software cost models can be abstracted into a function of five basic parameters: , size, process, personnel, environment, and required quality.
- 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
Effort = (Personnel) (Environment)( Quality)( Size process)
One important aspect of software economics (as represented within today's software cost models) is that the relation¬ship 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:
- Conventional: 1960s and 1970s, craftsmanship. Organizations used cus¬tom 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.
- Transition: 1980s and 1990s, software engineering. Organiz:1tions used more-repeatable processes and off-the-shelf tools, and mostly (>70%) cus¬tom 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.
- Modern practices: 2000 and later, software production. This book's philos¬ophy 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
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 homo¬geneous 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 partic¬ular interest here:
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 homo¬geneous 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 partic¬ular 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
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 pre¬dominant practice: The software project manager defines the target cost of the soft¬ware, 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 fund¬ing, 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 neces¬sary to analyze the cost risks and understand the sensitivities and trade-offs objec¬tively. 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.
Published date : 03 Nov 2015 11:43AM
