This document discusses modern project profiles and principles for software management. It summarizes that modern project profiles emphasize integration early in the life cycle to resolve risks. A key approach is continuous integration supported by executable demonstrations of primary scenarios. Additionally, it notes that an architecture-first approach helps resolve late risks by elaborating high-leverage elements early. Finally, it states that modern processes focus on demonstrable results throughout the life cycle rather than documents and reviews.
This document discusses modern project profiles and principles for software management. It summarizes that modern project profiles emphasize integration early in the life cycle to resolve risks. A key approach is continuous integration supported by executable demonstrations of primary scenarios. Additionally, it notes that an architecture-first approach helps resolve late risks by elaborating high-leverage elements early. Finally, it states that modern processes focus on demonstrable results throughout the life cycle rather than documents and reviews.
This document discusses modern project profiles and principles for software management. It summarizes that modern project profiles emphasize integration early in the life cycle to resolve risks. A key approach is continuous integration supported by executable demonstrations of primary scenarios. Additionally, it notes that an architecture-first approach helps resolve late risks by elaborating high-leverage elements early. Finally, it states that modern processes focus on demonstrable results throughout the life cycle rather than documents and reviews.
This document discusses modern project profiles and principles for software management. It summarizes that modern project profiles emphasize integration early in the life cycle to resolve risks. A key approach is continuous integration supported by executable demonstrations of primary scenarios. Additionally, it notes that an architecture-first approach helps resolve late risks by elaborating high-leverage elements early. Finally, it states that modern processes focus on demonstrable results throughout the life cycle rather than documents and reviews.
• In modern project profiles, positive and negative trends will be more tangible early in the life cycle. • Integration that occurs early and continuously serves as the verification activity of the design artifacts. • Most of the critical risks will be resolved by the end of the elaboration phase. The construction and transition phases, during which there is generally the most cost risk, should be free of surprises. • Major milestones focus on demonstrated results. A modern process framework exploits several critical approaches for resolving these issues: 1. Protracted integration and late design breakage are resolved by forcing integration into the engineering stage. This is achieved through continuous integration of an architecture baseline supported by executable demonstrations of the primary scenarios. 2. Late risk resolution is resolved by emphasizing an architecture-first approach, in which the high-leverage elements of the system are elaborated early in the life cycle 3. The analysis paralysis of a requirements-driven functional decomposition is avoided by organizing lower level specifications along the content of releases rather than along the product decomposition (by subsystem, by component, etc.). 4 Adversarial stakeholder relationships are avoided by providing much more tangible and objective results throughout the life cycle. 5 The conventional focus on documents and review meetings is replaced by a focus on demonstrable results and well-defined sets of artifacts, with more- rigorous notations and extensive automation supporting a paperless environment. • Modern TOP 10 SOFTWARE MANAGEMENT PRINCIPLES The top 10 software management principles were introduced as a back- drop to the software process framework and its underlying tenets To summarize a modern project profile, the following paragraphs revisit each of these principles and describe the project expectation associated with the successful application of each principle. In essence, the list provides a concise, top-level description of the features and benefits of a modern process as viewed by a software project manager. 1. Base the process on an architecture-first approach. An early focus on the architecture results in a solid foundation for the 20% of the stuff (requirements, components, use cases, risks, errors) that drives the overall success of the project. Getting the architecturally important components to be well understood and stable before worrying about the complete breadth and depth of the artifacts should result in scrap and rework rates that decrease or remain stable over the project life cycle. 2. Establish an iterative life-cycle process that confronts risk early. A more dynamic planning framework supported by an iterative process results in better risk management and more predictable performance. Resolving the critical issues first results in a predictable construction phase with no surprises, as well as minimal exposure to sources of cost and schedule unpredictability. 3. Transition design methods to emphasize component-based development. The complexity of a software effort is mostly a function of the number of human-generated artifacts. Making the solution smaller reduces management complexity. • 4. Establish a change management environment. The dynamics of iterative development, including concurrent workflows by different teams working on shared artifacts, necessitate highly controlled baselines. • 5. Enhance change freedom through tools that support round-trip engineering. Automation enables teams to spend more time on engineering and less time on overhead tasks. • 6. Capture design artifacts in rigorous, model-based notation. An engineering notation for design enables complexity control, objective assessment, and automated analyses. • 7 Instrument the process for objective quality control and progress assessment. Progress and quality indicators are derived directly from the evolving artifacts, providing more-meaningful insight into trends and correlation with requirements. • 8. Use a demonstration-based approach to assess intermediate artifacts. Integration occurs early and continuously throughout the life cycle. Inter- mediate results are objective and tangible. • 9 Plan intermediate releases in groups of usage scenarios with evolving levels of detail. Requirements, designs, and plans evolve in balance. Useful software releases are available early in the life cycle. • 10. Establish a configurable process that is economically scalable. Methods, techniques, tools, and experience can be applied straightforwardly to a broad domain, providing improved return on investment across a line of business. From numerous perspectives, the software project manager's paramount objective is to maintain the proper balance of emphasis across the 10 principles. Figure 15-4 summarizes this balance theme in the context of the fundamental software Next-generation software economics • Next-generation software economics should reflect better economies of scale and improved return on investment profiles. These are the real indicators of a mature industry • Further technology advances in round-trip engineering are critical to making the next quantum leap in software economics. • Future cost estimation models need ! to be based on better primitive units defined from well- understood software engineering notations such as the Unified Modeling Language. • Some of today's popular software cost models are not well matched to an iterative software process focused on an architecture-first approach. Despite many advances by some vendors of software cost estimation tools in expanding their repertoire of up-to-date project experience data, many cost estimators are still using a conventional process experience base to estimate a modern project profile. • A next-generation software cost model should explicitly separate architectural engineering from application production, just as an architecture-first process does The cost of designing, producing, testing, and maintaining the architecture baseline is a function of scale, quality, technology, process, and team skill. There should still be some diseconomy of scale (exponent greater than 1.0) in the architecture cost model because it is inherently driven by research and development-oriented concerns. • When an organization achieves a stable architecture, the production costs should be an exponential function of size, quality, and complexity, with a much more stable range of process and personnel influence. The production stage cost model should reflect an economy of scale (exponent less than 1.0) similar to that of conventional economic models for bulk production of commodities. Figure 16-1 summarizes an hypothesized cost model for an architecture-first development process. • Next-generation software cost models should estimate large-scale architectures with economy of scale. This implies that the process exponent during the production stage will be less than 1.0. the larger the system, the more opportunity there is to exploit automation and to reuse common processes, components, and architectures. Modern transition shifts The transition to modern software processes and technologies necessities several cultural shifts that will not be always easy to achieve. Several culture shifts must be overcome to transition successfully to a modern software management process. For some of these adjustments, it will be difficult to distinguish between objective opposition and stubborn resistance. Nevertheless, there are general indications of a successful transition to a modern culture. This section discusses several of the rough indicators to look for in order to differentiate projects that have made a genuine cultural transition from projects that have only put up a facade. Lower level and mid-level managers are performers. There should be no "pure managers" in an organization or suborganization with 25 or fewer people. The need for pure managers arises only when personnel resources exceed this level. Hands-on management skills vary, but competent managers typically spend much of their time performing, especially with regard to understanding the status of the project firsthand and developing plans and estimates. Above all, the person managing an effort should plan it. This does not mean the manager should approve the plan; it means the manager should participate in developing it In independent project assessments I have performed, a good indicator of trouble ahead is a manager who did not author the plan nor take ownership of it. The stakeholders affected by this transition are software project managers. Requirements and designs are fluid and tangible. The conventional process focused too much on producing documents that attempted to describe the software product and focused too little on producing tangible increments of the products themselves. Major milestones were defined solely in terms of specific documents. Development organizations for large contractual projects were driven to produce tons of paper in order to meet milestones and receive progress payments, rather than spend their energy on tasks that would have reduced risk and produced quality software. An iterative process requires actual construction of a sequence of progressively more comprehensive systems that demonstrate the architecture, enable objective requirements negotiations, validate the technical approach, and address resolution of key risks. Ideally, all stakeholders would be focused on these "real" milestones, with incremental deliveries of useful functionality rather than speculative paper descriptions of the end-item vision. The transition to a less document-driven environment will be embraced by the engineering teams; it will probably be resisted by traditional contract monitors. Ambitious demonstrations are encouraged. The purpose of early life-cycle demonstrations is to expose design flaws, not to put up a facade. Stake holders must not overreact to early mistakes, digressions, or immature designs. Evaluation criteria in early release plans are goals, not requirments. If early engineering obstacles are overemphasized, development organizations will set up future iterations to be less ambitious. On the other hand, stakeholders should not tolerate lack of follow-through in resolving issues. If negative trends are not addressed with vigor, they can cause serious downstream perturbations. Open and attentive follow-through is necessary to resolve issues. The management team is most • Good and bad project performance is much more obvious earlier in the life cycle. In an iterative development, success breeds success, and early failures are extremely risky to turn around. Real- world project experience has shown time and again that it is the early phases that make or break a project. It is therefore of paramount importance to ensure that the very best team possible performs the planning and architecture phases. If these phases are done right and with good teams, projects can be completed successfully by average teams evolving the applications into the final product. If the planning and architecture phases are not performed adequately, all the expert programmers and testers in the world probably will not achieve success. No one should resist early staffing with the right team. However, most organizations have scarce resources for these sorts of early life-cycle roles and are hesitant to make the necessary staff allocations. • Early increments will be immature. External stakeholders, such as custom- ers and users, cannot expect initial deliveries to perform up to specification, to be complete, to be fully reliable, or to have end-target levels of quality or performance. On the other hand, development organizations must be held accountable for, and demonstrate, tangible improvements in successive increments. The trends will indicate convergence toward specification. Ob- jectively quantifying changes, fixes, and upgrades will indicate the quality of the process and environment for future activities. Customers and users will have difficulty accepting the flaws of early releases, although they should be impressed by later increments. Management and the develop- ment team will accept immaturity as a natural part of the process. • Artifacts are less important early, more important later. It is a waste of time to worry about the details (traceability, thoroughness, and completeness) of the artifact sets until a baseline is achieved that is useful enough and stable enough to warrant time-consuming analyses of these quality factors. • Real issues are surfaced and resolved systematically. Successful projects recognize that requirements and designs evolve together, with continuous negotiation, trade-off, and bartering toward best value, rather than blindly adhering to an ambiguous contract statement. On a healthy project that is making progress, it should be easy to differentiate between real and apparent issues. Depending on the situation, this culture shift could affect almost any team. • Quality assurance is everyone's job, not a separate discipline. Many organizations have a separate group called quality assurance. I am generally against the concept of separate quality assurance activities, teams, or arti- facts. Quality assurance should be woven into every role, every activity, every artifact. True quality assurance is measured by tangible progress and objective data, not by checklists, meetings, and human inspections. The software project manager or designee should assume the role of ensuring that quality assurance is properly integrated into the process. The traditional policing by a separate team of inspectors is replaced by the self-policing teamwork of an organization with a mature process, common objectives, and common incentives. Traditional managers and quality assurance person- nel will resist this transition. Engineering teams will embrace it. • Performance issues arise early in the life cycle. Early performance issues have surfaced on almost every successful project I know of. These issues are a sign of an immature design but a mature design process. Stakeholders will usually be concerned over early performance issues. Development engineers will embrace the emphasis on early demonstrations and the ability to assess and evaluate performance trade-offs in subsequent releases. • Investments in automation are necessary. Because iterative development projects require extensive automation, it is important not to underinvest in the capital environment. It is also important for stakeholders to acquire an integrated environment that permits efficient participation in an iterative development. Otherwise, interactions with the development organization I will degenerate to paper exchange and many of the issues of the conventional process. • Good software organizations should be more profitable. In the commercial software domain, this is not an issue. In most of the software contracting domain, especially government contracts, it is definitely an issue. As part of the adversarial nature of the acquisition and contracting process, there is considerable focus on ensuring that contractor profits are within a certain acceptable range (typically 5% to 15%). Occasionally, excellent contractor performance, good value engineering, or significant reuse results in poten- tial contractor profit margins in excess of the acceptable initial bid. As soon as customers (or their users or engineering monitors) become aware of such a trend, it is inevitable that substantial pressure will be exerted to apply these "excess" resources to out-of-scope changes until the margin is back in the acceptable range. • As a consequence, the simple profit motive that underlies commercial transactions and incentivizes efficiency is replaced by complex contractual incentives (and producer- consumer conflicts) that are usually suboptimal. Very frequently, contractors see no economic incentive to implement major cost savings, and certainly there is little incentive to take risks that may have a large return. On the other hand, contractors can easily consume large amounts of money (usually at a small profit margin) without produc- ing results and with little accountability for poor performance.For the software industry to prosper, good contractors should be rewarded (more profit) and bad contractors should be punished (less profit). A customer who gets a good product at a reasonable price should be happy that the contractor also made a good profit. Allowing contractors who perform poorly to continue doing so is not good for anyone. This is one area in which the commercial domain is far more effective than the government contracting domain.