The first activity in software project planning is the determination of software scope. Function and performance allocated to software duri...
The first activity in software project planning is the determination of software scope. Function and performance allocated to software during system engineering should be assessed to establish a project scope that is unambiguous and understandable at the management and technical levels. A statement of software scope must be bounded.
Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability. Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful. Performance considerations encompass processing and response time requirements. Constraints identify limits placed on the software by external hardware, available memory, or other existing systems.
Obtaining Information Necessary for Scope
Things are always somewhat hazy at the beginning of a software project. A need has been defined and basic goals and objectives have been enunciated, but the information necessary to define scope (a prerequisite for estimation) has not yet been delineated. The most commonly used technique to bridge the communication gap between the customer and developer and to get the communication process started is to conduct a preliminary meeting or interview. The first meeting between the software engineer (the analyst) and the customer can be likened to the awkwardness of a first date between two adolescents. Neither person knows what to say or ask; both are worried that what they do say will be misinterpreted; both are thinking about where it might lead (both likely have radically different expectations here); both want to get the thing over with; but at the same time, both want it to be a success.
Yet, communication must be initiated. Gause and Weinberg suggest that the analyst start by asking context-free questions; that is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution desired, and the effectiveness of the first encounter itself.
The first set of context-free questions focuses on the customer, the overall goals and benefits. For example, the analyst might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution?
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution?
The next set of questions enables the analyst to gain a better understanding of the problem and the customer to voice any perceptions about a solution:
• How would you (the customer) characterize "good" output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the environment in which the solution will be used?
• Will any special performance issues or constraints affect the way the solution is approached?
The final set of questions focuses on the effectiveness of the meeting. Gause and
Weinberg call these "meta-questions" and propose the following (abbreviated) list:
• Are you the right person to answer these questions? Are answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
Weinberg call these "meta-questions" and propose the following (abbreviated) list:
• Are you the right person to answer these questions? Are answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions (and others) will help to "break the ice" and initiate the communication that is essential to establish the scope of the project. But a question and answer meeting format is not an approach that has been overwhelmingly successful. In fact, the Q&A session should be used for the first encounter only and then be replaced by a meeting format that combines elements of problem solving, negotiation, and specification.
Customers and software engineers often have an unconscious "us and them" mindset. Rather than working as a team to identify and refine requirements, each constituency defines its own "territory" and communicates through a series of memos, formal position papers, documents, and question and answer sessions. History has shown that this approach works poorly. Misunderstandings abound, important information is omitted, and a successful working relationship is never established.
With these problems in mind, a number of independent investigators have developed a team-oriented approach to requirements gathering that can be applied to help establish the scope of a project. Called facilitated application specification techniques (FAST), this approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of requirements.
Feasibility
Once scope has been identified (with the concurrence of the customer), it is reasonable to ask: “Can we build software to meet this scope? Is the project feasible?” All too often, software engineers rush past these questions (or are pushed past them by impatient managers or customers), only to become mired in a project that is doomed from the onset. Putnam and Myers [PUT97a] address this issue when they write:
. . . not everything imaginable is feasible, not even in software, evanescent as it may appear to outsiders. On the contrary, software feasibility has four solid dimensions: Technology— Is a project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application’s needs? Finance—Is it financially feasible? Can development be completed at a cost the software organization, its client, or the market can afford? Time—Will the project’s time-to-market beat the competition? Resources—Does the organization have the resources needed to succeed?
For some projects in established areas the answers are easy. You have done projects like this one before. After a few hours or sometimes a few weeks of investigation, you are sure you can do it again.
Projects on the margins of your experience are not so easy. A team may have to spend several months discovering what the central, difficult-to-implement requirements of a new application actually are. Do some of these requirements pose risks that would make the project infeasible? Can these risks be overcome? The feasibility team ought to carry initial architecture and design of the high-risk requirements to the point at which it can answer these questions. In some cases, when the team gets negative answers, a reduction in requirements may be negotiated.
Meantime, the cartoon people [senior managers] are drumming their fingers nervously on their large desks. Often, they wave their fat cigars in a lordly manner and yell impatiently through the smoke screen, “Enough. Do it!”
Many of the projects that appear in the newspapers a few years later as whopping failures got started this way.
Putnam and Myers correctly suggest that scoping is not enough. Once scope is understood, the software team and others must work to determine if it can be done withinthe dimensions just noted. This is a crucial, although often overlooked, part of the estimation process.
