The emerging Software Engineering Body of Knowledge (SWEBOK) is more appropriate than the Project Management Body of Knowledge (PMBOK) as a course of study for potential project managers of software projects. PMBOK has a tendency to emphasize scope management and task decomposition, while SWEBOK focus on requirements analysis and architectural design. Recent developments in Object-Oriented software engineering assert that an emphasis on requirements rather than scope, and on architecture rather than tasks leads to superior software development processes.
Specifically, organizations should not demand detailed fixed scope, cost and schedule plans at the beginning of a significant software development effort. There is a lesson to be learn from the building industry, which allocates up to half of the overall development time to architectural design, and does not create a controlled project environment until the construction phase.
When developing e-commerce applications, requirements analysis and system architecture remain critical, but they should be expanded to a broader context. The business plan replaces a project plan in e-commerce; marketing (and even sales) drive requirements analysis; and architectural design should be broadened to include infrastructure design. E-commerce system design encompasses system-wide issues, including hardware, networks, purchased components and partnerships, as well as interfaces with back-end fulfillment and collection capabilities.
1. Introduction
The Minneapolis Star/Tribune [17] recently reported that after an international search, the Walker Art Center has selected a Swiss architect for a $50 million, 110,000 square foot expansion project. “Design details still are scarce to nonexistent…. The site plan, scheduled to be announced in four to six months, calls for a two-year design phase followed by three years of construction.”
A recent issue of Computerworld [9] reported that a grocery chain’s announcement of plans for a four-year, $250 million systems overhaul sent its stock “into a tailspin”.
Computerworld [8] also noted that a managed care organization has finally recovered from a financial disaster caused by “major computer system problems”. The company showed its first profit since 1997; posting a loss of almost $20 million last year, including $5 million spent to fix the problems.
People are confident that Minneapolis will have a spectacular new art center in five years; after all, we know how to design and build buildings. Unfortunately, announcements of new information systems do not generate the same level of confidence. After 40 years of software development, a cloud of skepticism continues to hang over promises of new and improved systems
2. Software Engineering Processes
Many, many attempts have been made to bring discipline and predictability to the software development process. There is no doubt that software engineering can benefit from a disciplined process. However, utilizing the wrong software development process can interfere with discovering and applying truly beneficial software engineering processes.
2.1 Legacy Processes – Emphasis on Scope
It is well known that in the fast moving software world, legacy systems have a tendency to prevent a company from responding rapidly to new opportunities. The limited number of large company successes in the dot-com world is but one example of this commonly held belief. This paper contends that legacy processes can be much a problem as legacy systems in developing truly extraordinary information systems.
This is not to say that software engineering should proceed in the absence of a process. But a mature software engineering process that is the wrong process can be significant handicap to producing excellent software systems. Let’s look at a hypothetical case.
To reach process capability level three, an organization determines that it is important for software project managers to have a common approach to project management. Casting about for a project management process, the organization decides that PMI (Project Management Institute) has both a Project Management Body of Knowledge (PMBOK) [19] and a certification process which can be used for all types of projects, including software development.
The organization decides that all software project managers should either hold or work toward PMP (Project Management Professional) certification. The message sent throughout the organization is that projects must be managed using processes found in PMBOK.
There are many good processes in PMBOK, but it has a significant flaw when applied to software project management. Although PMBOK claims to be independent of lifecycle, an examination of the body of knowledge indicates otherwise. With its roots in government contracting, PMBOK places very strong emphasis on determining scope, decomposing tasks into a Work Breakdown Structure, and managing each element of that structure to the scope it represents.
Here are some quotes from PMBOK to emphasize this point:
“When properly defined, the scope of the project – the work to be done – should remain constant.” (Chapter 1)Chapter 5 goes on to champion the Work Breakdown Structure (WBS) and the associated work decomposition as the tool to use to establish and manage scope. The clear message is that a project without a Work Breakdown Structure is a poorly managed project indeed.
“Core planning processes….include:“A written scope statement is necessary for both projects and sub-projects…. Proper scope is critical to the project’s success.” (Chapter 5)
- Scope Planning
- Scope Definition
- Activity Definition
- Activity Sequencing
- Activity Duration Estimating
- Schedule Development
- Resource Planning
- Cost Estimating
- Cost Budgeting
- Project Plan Development” (Chapter 3)
2.2 A Lesson from the Building Industry
Let’s return to the Minneapolis Art Museum and the 40% of the project which constitutes the design phase. In this project, the cost and schedule are fixed, as is the size of the expansion and its purpose (to make the art center a “gathering place”). So a vision exists, and the architect is expected to select a design and materials to realize the vision. However, during the design phase – a significant portion of the project – neither scope management nor a Work Breakdown Structure are critical to the overall success of the project. In fact, this phase is dedicated to understanding requirements and establishing the building architecture. The scope is not going to deviate significantly from the 110,000 square foot $50 million building. Beyond that, scope management and work decomposition are not dominant issues during the design phase.
It is also clear that the ultimate success of the new museum depends largely on the insightfulness of the requirements analysis and the brilliance of the architectural design. An extensive search process has already taken place to select an architect who can be trusted to be insightful when gathering requirements and brilliant when designing the building. Adding the search time to the project, note that the first half of the allotted time is spent focusing on the building’s architecture.
For the first two years, the architect will be expected manage the project, including gathering requirements and delivering the final design. A ‘project manager’ will be assigned about the time the project goes out for bids, although the architect will provide oversight and retain responsibility throughout the project.
2.3 Toward a Modern Process – Emphasis on Requirements Analysis and Architecture
Consider the developing SWEBOK (Software Engineering Body of Knowledge) document [12]. Here the primary planning process is software requirements engineering rather than scope definition. This may seem like a similar activity, but it is different in that requirements analysis is a discovery, elaboration and negotiation process that occurs throughout the lifecycle of a project.
Consider the following quotes from the Software Requirements Engineering Knowledge Area in the Iron Man version of SWEBOK: “In practice, many things conspire to make requirements engineering one of the riskiest and most poorly understood parts of the software lifecycle….All of these things mitigate against the ideal of having a requirements baseline frozen in place before development begins. Requirements will change, and this change must be managed by continuing to ‘do’ requirements engineering throughout the life-cycle of the project.”
The same document [12] notes that “The maturity of most software development organizations’ requirements engineering processes lags well behind that of their down-stream life-cycle processes.” It further notes:
“Software engineers … cannot be expected to take a list of user requirements, interpret their meaning and translate them into a configuration … that satisfies the user requirements. In most cases … user requirements are elaborated … into a number of more detailed requirements that more precisely describe what the system must do. This usually entails deploying engineering skills to construct models of the system in order to understand the logical partitioning of the system, its context in the operational environment and the data and control communications between the logical entities. A side effect of this is that new requirements … will emerge as a conceptual architecture of the system starts to take shape. It is also likely to reveal problems with the user requirements … which have to be resolved….”
The bottom line is that SWEBOK recognizes that requirements are gathered, refined, negotiated, and modified throughout the entire project, with particular emphasis on flexibility during the design phase. On the other hand, studying for PMBOK certification will give an novice project manager the impression that the waterfall lifecycle is in fact the only ‘rational’ life cycle for a software development project.
To quote from Cantor [4], “…much of the overall project management literature is better suited to construction projects than software. The science of project management was developed as a tool to aid the construction manager to plan and tract the required schedule, budget, and resources…. Building a bridge is an exercise in dependency management, managing software is primarily an exercise in content management…. Bringing the construction management mentality to software development leads to a waterfall lifecycle: …taking this rigid approach appropriate to construction adds risk to the projects.”
2.4 The Waterfall and the Project Office
The classic “Waterfall” lifecycle (see Figure 1) does not make a lot of allowances for continuing requirements analysis throughout the development cycle. The on-going nature of requirements analysis has been embodied in virtually every software development life cycle except the “Waterfall” lifecycle. (See chapter 7 of [16] for a comparison of ten lifecycle models.)
 |
| Figure 1: The Waterfall Lifecycle |
Computerworld [7] reported in an article titled The Y2K Dividend, “The big winner, most Y2K veterans say, has been project management. … An important side effect of the new emphasis on project management has been the project office, which in many cases began as the Y2K office.” If, however, new projects which require in-depth user understanding and careful architectural design are subjected to a Y2K style of project management, these projects are could be at risk.
2.5 Object-Oriented Processes
In 1986, Dave Parnas [18] equated a ‘rational’ design process to a ‘waterfall’ lifecycle, and suggests that even though such a process is impossible to follow, perhaps we should ‘fake it’. Some years later, Booch [3] proposed that a two-dimensional set of processes is a good way to ‘fake it’. On the macro level, we manage the project using the phases that management expects, while on the micro level, and different process is going on. Booch’s motto for the macro process is “Make it so.” (from Star Trek), while his motto for the micro process is “Just do it.” (from Nike®).
 |
| Figure 2:The Unified Lifecycle |
In [15], Leffingwell hints that IEEE 830: Standard for Software Requirements Specification (1994) might need updating. In its place, he recommends using a “Modern Software Specifications Package,” which is a “logical structure” that flows from the vision document and contains an “elaboration of the various requirements for the system.” The Modern Software Specification contains a fairly detailed system design, and is produced at about the 30-40% point of a project.
The software development process is beginning to look like the one used for our art center building. Recall that from the start, there was a vision (110,000 square feet, $50 million, 5 years). In a couple of years, we can expect detailed architectural drawings and specs to go out for bids.
It is time to admit that it is not ‘ideal’ or even ‘rational’ to start with a detailed requirements definition at the beginning of a software development process; the requirements specification should be developed as on-going part of the project. If we want a good system, we must allocate a significant portion of the total time for the really important activities of the project, namely requirements definition and architectural design. Scope management and work decomposition are simply not important during this fairly large phase of the project. In fact, if they are emphasized, they will tend to impede the important work that needs to be done to lay the groundwork for an excellent system.
2.6 Developing the Architecture
Although the analogy to designing a building has been followed thus far, there are a significant differences between building software and buildings. In both fields, a model is often used to demonstrate concepts, help gather requirements, and prove the architectural design. However, while scale models of a building are throw-away items, it is common to build usable portions of a software system as part of the design process.
In fact, the iterative approach used in Object-Oriented projects recommends designing, coding, and testing architecturally significant portions of the system during the design process. This is not throwaway code; it is a usable, tested implementation of a select set of requirements. The reason for implementing portions of a system during the requirements gathering and design process is to provide design feedback and customer verification that the system architecture is sound.
Further, accepted OO project processes call for continued incremental implementation throughout the project. The second iteration incrementally refines the architecture and functionality of the first iteration. Subsequent iterations add new features and elaborate on the capability of already implemented features. Each iteration is implemented and tested and then used to provide development and customer feedback.
Leffingwell [15] notes: “It is worth pointing out that use case elaboration is not system decomposition. That is, we don’t start with a high-level use case and decompose it into more and more use cases. Instead, we are searching for more and more detailed actor’s interactions with the system. Thus, use-case elaboration is more closely aligned with refining a series of actions rather than hierarchically dividing actions into sub-actions.”
Similarly in refining the system through incremental iterations, the core system is not decomposed, but instead it is broadened. For instance, early iterations might implement the most common paths through a system, while subsequent iterations might address increasingly less likely deviations from the general flow.
2.7 Iterative Construction
When building a building, the construction phase is generally though of as the start of ‘traditional’ project management. At this point, drawings and specifications define the scope, and contractors bid on this well-defined scope. However, it is quite difficult to divorce design from implementation when using an iterative approach to software. In fact, as was mentioned earlier, requirements analysis and design continue at some level throughout the project.
However, after one or two iterations, the architecture is largely established, and the focus shifts to refining and implementing the requirements. In an OO project, the requirements are generally captured in use cases, and the process focus shifts during construction to iterative use case realization.
Iterations are not the same as phases in a ‘classic’ project. PMBOK [19] notes, “The conclusion of a project phase is generally marked by a review of both key deliverables and project performance…. These phase-end reviews are often called phase exits, stage gates, or kill points.” The deliverables are usually presumed to be complete at the end of a phase.
On the other hand, the end of an iteration is marked by acquiring enough information to move on to broader elaboration. Work products (artifacts) produced by an iteration will continue to evolve. The end of an iteration marks a change in focus, perhaps an elevation of formerly subordinate goals to a higher level, or turning attention to details that were previously tabled.
Project iterations are generally released according to a planned schedule. The scope included in an iteration usually may be modified (if necessary) to meet the schedule. Since subsequent iterations provide a mechanism for recovering scope, and since a functional system results from each iteration, OO projects tend to be managed to meet time commitments rather than scope commitments.
The iterative approach is not a new or unique concept. Most software project lifecycles employ some form of iteration. (See [16].) The problem is, many people still consider the waterfall lifecycle to be an ‘ideal’, if unattainable goal. It’s time to recognize that the software development process is fundamentally iterative, and stop trying to ‘fake it’.
3. E-COMMERECE
There is another change shaking the software world which is perhaps more profound than the evolution of software project management processes. Internet startup companies have been springing up like wildfire for the past couple of years, challenging the foundations of existing corporate systems and software development practices. A new dot-com company can generate an idea, get financing, implement a massive hardware and software system and be generating an enormous amount of business, all in the span of a few months.
How do they do it? They don’t seem to spend much time gathering and analyzing system requirements; they seem to know going in what they want to do. The startup company’s system seems to be build on purchased components and rapidly formed partnerships; internal development appears to be limited. Change is constant, from the content of the web site to the products and services offered to the infrastructure used to deliver the goods.
How is an established organization with mature software development processes supposed to compete with these upstarts? Perhaps the only way is to examine and adopt the best parts of the software development processes used in a dot-com company.
In the previous section, a case was made that requirements analysis and architectural design are the key ingredients for successful software projects. In this section, we look at the equivalent of these processes in the dot-com software development model: marketing and infrastructure design.
3.1 Practices in a Startup Company
Taking a step back, consider the mechanism through which a startup company obtains funding: the business plan. This is much more than the vision document of a project plan. The business plan starts out by identifying a market need, then makes the case that the company will be able to satisfy that need through a set of products or services which will (eventually) generate profits.
Business plans are usually quite detailed and always carefully reviewed by potential investors. They are scrutinized, questioned, refined and revised by venture capitalists, boards of directors and potential partners. Few software project plans are as thoroughly reviewed as a startup’s business plan.
It is a mistake to think that startup companies have not done requirements analysis. However, since their stakeholders are customers, they do it with marketing. Marketing is a well known discipline, and there are plenty of marketers available. A key difference between marketing and requirements analysis is the strong element of sales that is associated with marketing. If a customer doesn’t appreciate a product, there is always a sales function to foster that appreciation.
Any existing company that wants to ‘get into’ e-commerce should realize that e-commerce means selling products or services to customers. Therefore, marketing and sales are key elements of e-commerce. However, the synergy between marketing and the software development team must be high. If marketing simply tosses a laundry list of requirements at the development team, we have the worst embodiment of the waterfall process.
In a startup company, the founder (who perhaps hired the system developers) will be a very persuasive product champion. The requirements analysis process is fast and effective because it is closely linked to both the business plan and to the software development team’s motivation (eg. to their paychecks). Moreover, a startup company will generally use a Design-to-Tools lifecycle [16] for all except the unique core of the system. When coupled with an Evolutionary Delivery Lifecycle [16] this strategy allows fast initial implementation and provides a learning environment.
3.2 From Architecture to Infrastructure
The previous section hypothesized that the architectural design is the second critical success factor in a software system. This sections proposes that infrastructure is the equivalent of architecture in e-commerce environment. Successful e-commerce is dependent not only on a solid software architecture, but also on the ability to expand hardware and network capacity aggressively, and the ability to mesh seamlessly with an effective order-fulfillment and revenue collection infrastructure. How do dot-com companies come up with a workable infrastructure in just a few months?
The first thing to note is that designing exceptional infrastructures and architectures does not take lot of people, it requires a few exceptional people. This is why the Walker Art Museum did an international search for its architect. Venture capitalists will tell you that their investment decisions are based almost exclusively on the management team of a company, not the proposed product. Why is this?
In lieu of detailed project plans, investors in startup companies are looking for people who have already proven that they know how to develop a similar product or service, market it, and establish excellent operations. Since an investor is unlikely to be able to evaluate a project plan in any case, all they have to go on is the quality of the management running the business.
In a fast-moving e-commerce project, there is a great need for top notch design of the entire infrastructure, including hardware, response time under volume, and scalability; to say nothing of the software architecture. A recent Computerworld article [6] suggested that corporations can be at a significant disadvantage when designing web-based systems, because the complete infrastructure design is often not in the domain of a single person. One function may be responsible for the network while another handles servers, a third does the software development, and so on. This pigeonholing of responsibilities tends to create components that are individually optimized, to the detriment of system-wide optimization.
A further difference between dot-com infrastructure design and corporate system infrastructure design comes from the dot-com’s limited resources. A startup company is does not have the resources to develop software when an existing tool will do the job. Whether it’s a survey capability or a link to MapQuest, if the solution exists, it is not re-developed. Partner and purchase is the name of the game. On the other hand, as noted in [6], these companies are not going to shell out a lot of money for software licenses. And of course, a dot-com must develop a core capability if the company is to have any uniqueness and staying power. But dot-com companies know instinctively that re-inventing an existing wheel will sap valuable resources at best and result in an inferior wheel at worst.
So how does an established organization compete against the dot-com’s when designing the system infrastructure? First, work from a business plan rather than a project plan. Second, search for and retain top-notch infrastructure and system architects. Then be sure their charter is broad enough to allow a holistic system view. Be sure they have the charter to rapidly purchase and partner where practical. Be sure the project is adequately funded and has proper organizational sponsorship (the equivalent of venture funding). Be sure the architects and marketers are synchronized. Finally, a tight timeframe (as opposed to prescribed scope) tends to inspire creativity in the Internet environment.
3.3 Rapid Implementation
What about implementation? The pattern for rapid development of dot-com systems is well known. First, a limited deployment model is developed. For instance, the business model may be tested in a limited geographic area; or a limited number of products may be offered for sale; or a limited audience may be engaged. This ‘limited edition’ is debugged, along with its supporting infrastructure. Once the offering is stabilized, it is rapidly scaled up to the full intended audience.
The tendency to ‘go live’ to a limited audience is analogous to the beta testing common to with all software products. Since beta testing is such a common and effective practice for software products, it is a wonder that it has not been more widely adopted as a standard practice in software development projects. In fact, the Unified lifecycle of incremental iterations embodies both successive ‘builds’ and the moral equivalent of beta releases. In addition, since the early iterations are aimed at risk reduction, this process is similar to the model-then-scale implementation strategy of the dot-com’s.
4. SUMMARY AND CONCLUSION
Software projects should begin with a ‘Vision Document’ that states in general terms what the system should do and what it’s boundaries are. The vision document should clarify the business purpose of the system, along with the overall cost and timeframe which is justified and required by the business objective.
The next step is to choose the architect(s), a small group of people with proven credentials . The architectural team coordinates requirements engineering, system modeling, and architectural design. They will require significant input from users (sometimes represented by business analysts). They also need a configuration management system to tracks requirements as they are defined, elaborated, and realized. An iteration or two of the system should be developed to help define the architecture and address key risks.
This initial phase of the project should be expected to take perhaps 40% of the allotted timeframe. At it’s conclusion, a fairly detailed set of system requirements should be available. At this point, a project manager can add staff and begin to manage scope. More important, the project manager should pace the project through frequent, planned iterations that are managed to schedule.
If this seems like a risky lifecycle, consider the risks in a legacy software lifecycle. We would not consider erecting a large building without an architect. We probably wouldn’t launch a large advertising campaign without careful design by an agency. So why would we consider developing a large software system without chartering an architect to analyze the user requirements, establish a system architecture, and oversee its construction?
______________
REFERENCES
[1] Ambler, Scott, Process Patters, Building Large-Scale Systems Using Object Technology, Cambridge University Press, 1998
[2] Booch, Grady, Object-Oriented Analysis and Design with Applications, Second Edition, Benjamin/Cummings, 1994
[3] Booch, Grady; Object Solutions, Managing the Object-Oriented Project, Addison-Wesley, 1996
[4] Cantor, Murray, Object-Oriented Project Management with UML, Wiley Computer Publishing, 1998
[5] Cockburn, Alistair; Surviving Object-Oriented Projects, A Manager’s Guide, Addison-Wesley, 1998
[6] Computerworld, 1/31/2000, Dot-coms’ Newest Secret Weapon Doesn’t Have a Name
[7] Computerworld, 2/7/2000, The Y2K Dividend
[8] Computerworld, 3/13/2000, Oxford Rebounds From IT Disaster
[9] Computerworld, 3/20/2000, A&P’s 250 M IT Plan Shunned by Wall Street
[10] Fowler, Martin and Scott, Kendall, UML Distilled, Second Edition, A Brief Guide to the Standard Object Modeling Language, Addison Wesley, 2000
[11] IBM Object-Oriented Technology Center, Developing Object-Oriented Software, An Experience-Based Approach, Prentice Hall PTR, 1997
[12] IEEE Computer Society and ACM; Guide to the Software Engineering Body of Knowledge (SWEBOK), download free from web site: www.SWEBOK.org
[13] Jacobson, Ivar; Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, 1992
[14] Jacobson, Ivar, Booch, Grady and Rumbaugh, James; The Unified Software Development Process, Addison-Wesley, 1999
[15] Leffingwell, Dean and Widrig, Don; Managing Software Requirements, A Unified Approach, Addison-Wesley, 1999
[16] McConnell, Steve; Rapid Development, Taming Wild Software Schedules, Microsoft Press, 1996, Chapter 7
[17] Minneapolis Star/Tribune, Wednesday, March 22, 2000, B Section, Page 1.
[18] Parnas, David L. and Clements, Paul C.; A Rational Design Process: How and Why to Fake It, IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February, 1986
[19] PMI (Project Management Institute), Project Management Body of Knowledge (PMBOK), download free from web site: www.PMI.org
[20] Schneider, Geri and Winters, Jason, Applying Use Cases, A Practical Guide, Addison-Wesley, 1998
Screen Beans Art, © A Bit Better Corporation
No comments:
Post a Comment