Software Engineering

56
CHAPTER 4 
Understanding the Software Project Environment
management instruments must be properly developed, monitored, and adjusted to 
reflect the ambiguity inherent in task estimation. Initial planning forecasts of antici-
pated productivity, performance, and results must account for project uncertainty. 
The level of confidence toward achieving project objectives involves understanding 
the assumptions that were involved in generating project plans and the probable out-
comes if the assumptions prove flawed or inaccurate. The software engineering team 
can control the project’s destiny by understanding the impact assumptions and deci-
sions may have on project plans and anticipating the recovery strategy when pro-
gress is slowed or impeded by unforeseen circumstances.
Project plans, schedules, and budgets are simply restraining devices that are 
used to corral the project team toward product delivery in a timely and cost-effec-
tive manner. Initial plans are never accurate since there are too many unknowns 
concerning the software product to be developed. Additionally, it may not be pos-
sible to predict future or unexpected events. The number of stakeholders involved 
with the software development project makes it almost impossible to establish an 
accurate project plan. Therefore, the most important motive for employing software 
engineering practices is to fill in the gaps of understanding concerning the software 
product. This, in turn, helps refine the technical and project plans, schedules, and 
budgets so that the project can be successfully executed.
Software development projects are established with the aim of delivering a 
“new” software product to one or more customers. Therefore, until the software 
product definition is relatively complete, the project plans will always be impre-
cise. This implies that the project plans, schedules, and budgets are simply tools that 
direct the project team toward the definition, design, implementation, testing, docu-
menting, and delivery of a software product. The dilemma faced by the project team 
is determining how to define the software product in such a manner that the project 
goals and objectives can be satisfied. Inherent in this situation is the fact that project 
plans, schedules, and budgets are simply a means to an end to the successful delivery 
of a software product on time (according to schedule) and without exceeding author-
ized funding thresholds (according to budget). As long as the project team can define 
and deliver an acceptable software product by the delivery date and does not expend 
more resources than authorized, the project should be deemed successful.
Within the project environment there exists a variety of decision points that rep-
resent opportunities to maintain the project scope so that goals and objectives can 
be attained. Software engineering practices and tools are structured to recognize 
when the definition of the software product presents an opportunity to revisit the 
project plan. At each opportunity, a decision must be made on which way to pro-
ceed among alternative approaches. Making proper architectural design decisions 
involves the following factors: