MIS 495 -- Dr. Reithel
Chapter 5

Software Scope-- Software scope describes function, performance, constraints, interfaces, and reliability. Determining software scope is the first activity in software project planning. Function and performance allocated to software during system engineering should be assessed to establish a project scope that is unambiguous and understandable at management and technical levels.

Resources-- The second task of software planning is estimation of resources required to accomplish the software development effort. The development resources can be viewed as a pyramid, with People at the top, Reusable Software Components in the middle, and Hardware/Software Tools at the base.

Reusability-- The creation and reuse of software building blocks. There are four software resource categories that should be considered as planning proceeds:

Off-the-shelf components-- software acquired from a third party. It is ready to use and has been fully validated.
Full-experience components-- existing specs, designs, code, or test data developed for past projects that are similar to the software to be built for the current project. Modifications required for these components will be relatively low-risk.
Partial-experience components-- existing specs, designs, code, or test data developed for past projects that are related to the software to be built for the current project, but will require substantial modification. Modifications required for these components will have a fair degree of risk.
New components-- components that must be built by the software team specifically for the needs of the current project.

Software Sizing

In the context of project planning, size refers to a quantifiable outcome of the software project. Size can be measured in LOC (lines of code) when using the direct approach, and by FP when using an indirect approach. Putnam and Myers suggest four approaches to the sizing problem:

"Fuzzy-logic" sizing-- uses the approximate reasoning techniques that are the cornerstones of fuzzy logic.
Function point sizing-- the planner develops estimates of the information domain characteristics.
Standard component sizing-- the planner estimates the number of occurences of each standard component, then uses historical project data to determine the delivered size per standard component.
Change sizing-- used when a project encompasses the use of existing software that must be modified in some way as part of a project. The planner estmates the number and type of modifications that must be accomplished. Then, using an "effort ratio" for each type of change, the size of the change may be estimated.

Process-Based Estimation

This method, the most common technique for estimating a project, bases its estimate on the process that will be used. The process is decomposed into a relatively small set of activities or tasks and the effort required to accomplish each task is estimated. Problem functions and process activities are melded, then the planner estimates the effort that will be required to accomplish each software process activity for each software function. Finally, costs and effort for each function and software process activity are computed.

The COCOMO Model (also, see page 121 of the Pressman textbook)

The COnstructive COst MOdel, or COCOMO, is a hierarchy of software estimation models. The Basic COCOMO model computes software development effort (and cost) as a function of program size expressed in estimated lines of code. The Basic COCOMO equations follow: E=ab(KLOC)raised to the bb power and D=cb(E)raised to the db power. Where E is the effort applied in person-months, D is the development time in chronological months, and KLOC is the estimated number of delivered lines of code (in thousands). The remaining coefficients are listed in the table below.

Software Project	ab	bb	cb	db
organic	2.4	1.05	2.5	0.38
semi-detached	3.0	1.12	2.5	0.35
embedded	3.6	1.20	2.5	0.32

The Intermediate COCOMO model computes the software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes. This model takes the form: E=ai(KLOC)raised to the bi power x EAF, where E is the effort applied in person-months and EAF is the effort adjustment factor. The coefficients are given in the following table:

Software Project	ai	bi
organic	3.2	1.05
semi-detatched	3.0	1.12
embedded	2.8	1.20

The Make-Buy Decision

Sometimes it is more cost effective to acquire, rather than develop, computer software. This make-buy decision may be complicated by a number of options, such as: purchasing software off the shelf, buying and modifying components to meet specific needs, and custom-building software by an outside contractor.

Guidelines for make-buy decision

Develop a specification for function and performance of the desired software. Define measurable characteristics whenever possible.
Estimate the internal cost to develop and the delivery date.
Select three or four candidate applications that best meet your specification.
Select reusable software components that will assist in constructing the required application.
Develop a comparison matrix that presents a head-to-head comparison of key functions. Alternatively, conduct benchmark tests to compare candidate software.
Evaluate each software package or component based on past product quality, vendor support, product direction, reputation, and so on.
Contact other users of the software asd ask for opinions.

Outsourcing-- simply contracting software engineering activities to a third party, who does the work at lower cost.

Outsourcing Tips and Resources

Some of the more popular outsourcing companies today

Comments: reithel@bus.olemiss.edu