ZeePedia buy college essays online


Software Project Management

<<< Previous Requirements Elicitation for Software Next >>>
 
img
Software Project Management (CS615)
LECTURE # 14
2. Software Development Fundamentals
Technical Fundamentals
2.11
Requirements Management
Requirements Analysis
·
Evaluation and Synthesis
Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more solutions.
To begin, the data objects processing functions and behavior of the
system are defined in detail. Once this information has been
established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does
the software to support this architecture fall within the scope
outlined in the Software Plan? A database management system
would seem to be required, but is user/customer's need for
associativity justified? The process of evaluation and synthesis
continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development
steps.
Throughout evaluation and solution synthesis, the analyst's
primary focus is on "what, not "how." What data does the system
produce and consume what functions the system must perform.
What behaviors do the system exhibit, what interfaces, are defined
and what constraints apply?
·
Models
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software.
·
Specification
96
img
Software Project Management (CS615)
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software. The customer may be unsure of precisely what is
required. The developer may be unsure that a specific approach
will properly accomplish function and performance. For these, and
many other reasons, an alternative approach to requirements
analysis, called Prototyping, may be conducted.
·
Concerns for Review
The customer may be unsure of precisely what is required. The
developer may be unsure that a specific approach will properly
accomplish function and performance. For these, and many other
reasons, an alternative approach to requirements analysis, called
Prototyping, may be conducted.
For example, an inventory control system is required for a major
supplier of auto parts. The analyst finds that problems with the
current manual system include:
(1) Inability to obtain the status of a component rapidly,
(2) Two- or three-day turn- around to update a card file,
(3) Multiple reorders to the same vendor because there is no way to
associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what
information is to be produced by the new system and what data
will be provided to the system. For instance, customer desires a
daily report that indicates what parts have been taken from
inventory and how many similar parts remain. The customer
indicates that inventory clerks will log the identification number of
each part as it leaves the inventory area.
Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more solutions.
To begin, the data objects, processing functions, and behavior of
the system are defined in detail. Once this information has been
established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does
the software to support this architecture fall within the scope
outlined in the Software Plan? A database management system
would seem to be required, but is the user/customer's need for
97
img
Software Project Management (CS615)
associativity justified? The process of evaluation and synthesis
continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development
steps.
Requirements Elicitation for Software
Before requirements can be analyzed, modeled, or specified they must be
gathered through an elicitation process. A customer has a problem that
may be amenable to a computer-based solution. A developer responds to
the customer's request for help.
Communication has begun. But, as we have already noted, the road from
communication to understanding is often full of potholes.
1. Initiating the Process
The most commonly used requirements elicitation technique is to
conduct a meeting or interview. The first meeting between a
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 [GAU89] 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 that is desired, and the
effectiveness of the first encounter itself. The first set of context-
free, questions focuses on the customer, the overall goals, and the
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 that you need?
These questions help to identify all stakeholders who will have
interest in the software to be built. In addition, the questions
identify the measurable benefit of a successful implementation and
possible alternatives to custom software development.
98
img
Software Project Management (CS615)
The next set of questions enables the analyst to gain a better
understanding of the problem and the customer to voice his or her
perceptions about a solution:
­ How would you 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 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 your
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 successful analysis.
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 replaced by a
meeting format that combines elements of problem solving,
negotiation, and specification.
2. Facilitated Application Specification Techniques
Too often, customers and software engineers have an unconscious
"us and them" mind-set. 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 doesn't work very well.
Misunderstandings abound, important information is omitted, and
a successful working relationship is never established.
It is with these problems in mind that a number of independent
investigators have developed a team-oriented approach to
requirements gathering that is applied during early stages of
99
img
Software Project Management (CS615)
analysis  and  specification.  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
solution requirements.
FAST has been used predominantly by the information systems
community, but the technique offers potential for improved
communication in applications of all kinds.
Many different approaches to FAST have been proposed. Each
makes use of a slightly different scenario, but all apply some
variation on the following basic guidelines:
­ A meeting is conducted at a neutral site and attended by both
software engineers and customers.
­ Rules for preparation and participation are established.
­ An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the free
flow of ideas.
­ A `facilitator' (can be a; customer, a developer, or an outsider)
controls the meeting.
­ A "definition mechanism" (can be work sheets, flip charts, or
wall stickers or an electronic bulletin board, chat room or
virtual forum) is used.
The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a preliminary
set of solution requirements in an atmosphere that is conducive to
the accomplishment of the goal.
To better understand the flow of events as they occur in a typical
FAST meeting, we present a brief scenario that outlines the
sequence of events that lead up to the meeting, occur during the
meeting, and follow the meeting.
Initial meetings between the developer and customer occur and
basic questions and answers help to establish the scope of the
problem and the overall perception of a solution. Out of these
initial meetings, the developer and customer write a one- or two-
page "product request." A meeting place, time, and date for FAST
are selected and a facilitator is chosen. Attendees from both the
100
img
Software Project Management (CS615)
development and customer/user organizations are invited to attend.
The product request is distributed to all attendees before the
meeting date.
3. Quality Function Deployment
A quality management technique that translates needs of customers
into technical requirements of software.
i.
Normal Requirement: meeting objectives & goals stated for a
product or system during meeting
i.
Expected Requirement: Implicit to products / system and may
be so fundamental that customer does not explicitly state them
i.
Exciting Requirement: Features beyond customer's expectation
and prove to be very satisfying when present
4. Use Cases
As requirements are gathered as part of:
·
Informal meeting
·
FAST or QFD
SW Engineer can create a set of scenario that identify a thread of
usage for system to be constructed; providing a description of how
system will be used.
5. Analysis Principles
A variety of modeling notations are developed by investigators.
Each analysis method has a unique point of view. However all
analysis methods are related by a set of operational principles like:
­ The information domain of a problem must be represented and
understood.
­ The functions that the software is to perform must be defined.
­ The behavior of the software (as a sequence of external events)
must be represented.
­ The models that depict information function and behavior must
be partitioned in a manner that uncovers details in a layered (or
hierarchical) fashion.
101
img
Software Project Management (CS615)
­ The analysis process should move from essential information
toward implementation detail.
6. Software Prototyping
Analysis should be conducted regardless of the SW engineering
paradigm. (Various approaches apply)
In some cases it is possible to apply operational analysis principles
and derive a model of SW from which a design can be developed.
In other situation Requirement Elicitation (FAST, QFD etc) is
conducted and a model is built, called Prototype.
102
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration