Unit I

Software Development and

Management

W e are now in the age of information explosion. Homes, small and

large businesses, corporations, schools and governments have to
computerize their operations in order to cope with the demands of the
society. In the 1950s, the main hurdle was the hardware. Now, software
is the key to the effectiveness of any computerized system. Because of
these, the demand for new software has drastically increased and the
means to cope with such a demand has been evolving into what is now
known as software engineering.

Software engineering has emerged as a new discipline after decades of

chaos in the development of software. At present, the software engineering
community has established guidelines and standards on methods, tools
and procedures in the development and management of software. It has
provided an avenue for addressing issues on software development and
to do research on various aspects of the field.

Although the field of software engineering has gone a long way since its
early conception a few decades ago, much of the mistakes and errors in
software development and management that were committed before are
being repeated today. This is because most of the efforts are done using
trial and error. These so-called mistakes have caused millions of dollars in
loss. There is a need for formal methods and procedures for software
development. Together with this, we also need a wider effort to educate
professionals involved in software development and management.

This unit introduces the aspects of software development and

management. First is an introduction to software engineering. Then, the
next two modules discuss the two initial steps in the development, planning
and scheduling. The last module highlights management techniques in
software development.
 Module 1
Introduction to Software
Engineering

S oftware Engineering … What comes to

your mind when you first heard the term
software engineering? What does it exactly
Objectives
involve? How will the study of software At the end of this module, you
engineering concepts benefit you in your field should be able to:
of study? We shall answer these questions in
this module. Sit tight and enjoy the module 1. Define software engineering
as we go through it together. in your own words;
2. Identify and describe the
different stages of software
Overview of Software development;
3. Trace the software lifecycle
Engineering using the different paradigms;
and
What is software engineering? Different 4. Explain the importance of
authors have different definitions of software software engineering to
engineering. But all seem to agree that it is all software use and
about building good quality software systems. maintenance.

What kind of work do you expect a software

engineer to be doing? Let us take a look at the work of a civil engineer, for
instance. You will not need a civil engineer to construct a dollhouse, in
contrast to constructing a skyscraper. One programmer can develop
software for smaller applications, while large applications would require
software engineers working together with other technical people.
4 CMSC I Software Engineering

We also usually associate a civil engineer with the construction of a house,

a road, a bridge or other similar structures, isn’t it? What work is involved
in it? It requires a lot of hard work from the engineer which includes
planning, designing and building. A software engineer has to do a lot of
planning, designing and building as well, specifically, of software systems.
These software systems may also be in various forms, for instance, database
systems, accounting and payroll systems, personnel computer system, bank
systems, and so much more. Can you tell me other kinds of software
systems that we use in our daily activities, at home and at work?

Since the development of a software system is an enormous task, a detailed

plan would also have to be designed before actually working on the project
itself. Likewise, a civil engineer does not request preparation of the land
and actual construction unless a plan has been made and finalized with
the individual requesting for the software system they are developing (or
called client). The plan agreed upon by the engineer and the client, and
possibly signed by both parties, becomes a legal document against which
the final product may be counterchecked. The client can demand from
the engineer if the product is not in accordance with the specified
requirements. In some cases though, the client may not have realized the
implications of some decisions made earlier on, and may opt to revise
some portions of the initial requirements specification. They can discuss
these with the engineer, and the team can integrate the modifications as
requested.

Developing a software system really involves a lot in terms of personnel,

paper work, meetings, materials and so much more, which entail much
funds. It is clear here that the software engineer has to work with the
budget allotted for the development of a software. The detailed plan
developed will help the members of the team to work within the constraints
of the budget, and not to overspend.

Aside from monetary constraints, the engineer has to work with the time
element as well. Depending on the agreed upon time of completion between
the team and the client, the team will have to work within the specified
time. A schedule of activities will be useful to help the team meet the
deadline.

A civil engineer does not work alone, and the same is true for a software
engineer. Civil engineers have to work with the owners of the building,
the architects, the carpenters, and others. They will have to coordinate
also with the government engineers, so they can be sure that they comply
with existing government rules and regulations, both locally and
nationally. Likewise, the software engineer will have to work with the
head of the company or the client, other software engineers, computer
programmers, accountants and others. If he has to oversee the work, he

UP Open University
 Unit I Module 1 5

also needs to be equipped with managerial skills to enable him to effectively

relate and monitor the progress of the work being carried out.

What are the resources that the software engineer has to work with? Like
the civil engineer, drafting papers and pencils are needed in the design
phase, and construction materials like cement, sand, wood and others are
necessary in the construction stage. The success of the building construction
also depends on the resources used. The quality of work and the time it
will be completed will depend on the kinds of both the materials and tools
used. For instance, are they going to use high-powered saws? Will these
saws be available? Are the carpenters trained to use them? In the same
way, software tools called Computer-Aided Software Engineering tools (CASE
tools) are some of the existing tools available to aid in the development of
software systems.

Are you now overwhelmed by the whole idea of building a software

system? Don’t be! Though, it may seem to involve a lot of hard work, it’s
just really a matter of training. Obviously, the civil engineer cannot perform
the tasks at hand if the appropriate formal training was not obtained.
Similarly, the software engineer has to be trained to do the job of a software
engineer, considering all the aspects involved in building the software.
This is the reason why this course is part of the Diploma in Computer
Science. You will be equipped here to be a good software engineer.
Remember, CMSC I is one of the last courses in your Diploma in Computer
Science. Come on! You can make it ‘til the end.

Now, I’ve given you an overview of what software engineering is. You
can surely answer the Self-Assessment Question (SAQ) below. Why don’t
you try it now?

SAQ 1-1
Define software engineering in your own words. Try using not
more than 25 words. Write your answer on the space provided
below.

UP Open University
6 CMSC I Software Engineering

By the way, after you’ve answered the SAQs, you may take a look at the
Answer to Self-Assessment Questions (ASAQ) at the end of each module
so that you can check if your answer is correct or not. Remember to try
first to answer the SAQs yourself before looking at the answers.

Phases in the Software Lifecycle

What is the lifetime of a software system? From the time of the conception
of the idea of building a software to it’s eventual retirement is the lifetime
of the software. In the computer science community, the lifetime is better
known as the lifecycle of the software. This is because a software usually
repeats some previously undergone stage (or stages) during the
development.

In general, the following are considered to be the main phases of the

software lifecycle:
1. planning;
2. analysis;
3. design;
4. implementation;
5. testing and verification; and
6. maintenance.

What I will do here is just give you an overview of these stages. But don’t
worry coz in the succeeding modules, I will go into the details of each of
these stages.

The lifecycle of a software begins when an individual or a company

recognizes a need for a software system in its operations. They may
approach a developer with the request for a software and the development
organization will study the feasibility of the project. At this stage, the
problem will be identified more clearly, possible solutions will be suggested
and approximate time needed to complete the project and the
corresponding costs that it may entail will be stated. This is the planning
phase. Based on these, the client will determine whether the solutions
suggested are feasible, a detailed plan will be done by the development
team, and correspondingly proceed to the next stage.

UP Open University
 Unit I Module 1 7

The next phase is the analysis phase. Now, we will explain this by using
our previous illustration. Have you ever thought of building a house of
your own? At the beginning, you may have some ideas, made a few
architectural and interior design choices in your mind, and may have
discussed some of these thoughts with your husband or wife. The next
step for you to take is to communicate these initial ideas with your engineer
and architect before they can actually start working on the project.
Similarly, during analysis, the client will identify the requirements of the
system to the developer; this is why this stage is also commonly known as
the requirement analysis phase.

Based on these requirements, the developer will come up with a project

design. This is now part of the design phase. Using our analogy above, the
engineer and the architect will then work on the design of the house that
you wish to build based on the initial requirements that you’ve given them.

Once the design has been detailed, the next stage is the actual building of
the software which is called implementation. Implementation is the coding
of the software system and constitutes only one stage of the whole
development process. There is a misconception that most of the work in
software development is on the implementation phase. More of these will
be discussed in the next section.

Software testing is the putting together of different parts of the

implementation. To check whether the software is performing as expected,
the software is executed using several inputs. The software behavior is
checked against the initial requirements specified during the analysis stage.
If we are interested to know that the software will run for all possible
inputs, then we need to employ verification techniques. Testing and
verification usually take more time than expected. After this stage has
been acceptably done, the software product is ready for delivery to the
client. After delivery, software maintenance commences. It mainly caters
to client preferences and the development team’s compliance with such.

We mentioned earlier that, in general, the above phases constitute the

main phases of the software lifecycle. The phases that software will go
through really depends on the lifecycle paradigm that the development
team decides to use. You can know more about these paradigms in the
next section, my friend. But before proceeding, try to answer the next
SAQ.

UP Open University
8 CMSC I Software Engineering

SAQ 1-2
Identify the main phases in the software lifecycle and briefly
describe each of them. (Freely use the space provided below.)

Software Lifecycle Paradigms

As human beings, we recognize the uniqueness of the lives that we spend
here on earth. In fact, we cannot find two individuals who have done
exactly the same things and gone through the same set of experiences in
their entire lifetime. Even identical twins will testify to this fact. The same
is true about different software. Even if these software systems are similar
in some ways, no two software systems follow exactly the same lifecycle.

UP Open University
 Unit I Module 1 9

As a software engineer then, how would you determine the steps in the
development of your own software assignment? You can use one of several
existing software lifecycle paradigms (also called software lifecycle models) to
guide your development. These paradigms serve as models, maps and
guides for the effective development of good quality software. Your choice
of a model will largely depend on the nature of your project and its
appropriateness to the models available.

There are several software lifecycle paradigms that you may find in the
literature. The most common of these is the phased paradigm. This paradigm
is called phased since the stages are distinct from each other; one is
performed after the other. It is also called the waterfall paradigm since it
resembles the series of waterfalls on a river, after one stage is completed,
the next one is started. The phased paradigm follows the main phases
mentioned in the previous section consecutively, one after the other. It
clearly follows the planning, analysis, design, implementation, testing and
verification, and maintenance sequence.

Note that the phased paradigm is a simplistic view of an ideal world. The
reality is known in software development that each phase in the lifecycle
cannot be (at least, at the present time) accomplished clearly and
completely. For example, only a preliminary plan can be devised at the
onset of the project and possibly after analysis, a more detailed plan can
be made. Consequently, during implementation, the client may change or
fine tune some of the requirements of the system, and therefore, the
developer would have to redo some planning, analysis and design. These
events are common in software development; that is why other lifecycle
paradigms are presented in literature. The development of such paradigms
is still a challenging area of research in the field of software engineering.

It is important to us as software engineers to be aware of these lifecycle

paradigms discussed in literature. Therefore, Activity 1-1 is given to you
to help you find out more about these paradigms, while Activity 1-2 is to
give you an idea of how contemporary software engineers or software
developers benefit from these paradigms.

Note: Use extra sheets if the spaces provided after each activity are not
enough.

UP Open University
10 CMSC I Software Engineering

Activity 1-1
Now, you will have to look for some books on software engineering
and do some research work. Try finding the books listed in the
references at the end of this module. I’m sure you can find them in
any local bookstore and in the library.

Some of these other paradigms are the Prototyping, Spiral Model

and Fourth Generation Techniques. Identify the other lifecycle
paradigms or models that are explained in the literature. Describe
these paradigms and discuss the class of problems that they cater
to. Include illustrations to describe these paradigms. Make sure
you include a list of references where those paradigms are described.

UP Open University
 Unit I Module 1 11

Activity 1-2
For this activity, you need to talk to three people who have been
members of a software development team. If you have been in
such a team, you may include yourself. Ask them to identify the
software lifecycle paradigm that they used for their project
development, and give some major reasons why they used this
paradigm.

Person Description Paradigm and Reasons

of Software

Points to Ponder: Can you assess the level of awareness of

contemporary software engineers with regards to these paradigms?
How do you think the development of their software systems affect
their level of knowledge about existing paradigms for software
development?

UP Open University
12 CMSC I Software Engineering

Misconceptions about Software Development

There have been several misconceptions about software development that
are slowly being corrected. I am going to discuss here some of these
misconceptions.

Most programmers, like you and me, often associate software development
to sitting in front of a computer and coding a program for a particular
problem at hand. We don’t really feel that we are getting the job done
until we start programming. Much of software development is not
associated with programming alone. The truth is the sooner we begin
writing code, the longer it will take to finish the task. Software
development is not only writing code, it is only one aspect of the whole
process of software engineering. In fact, studies have shown that coding
is only about 10% of the development process.

Another misconception is that there is no way to assess the quality of a

software until we get the program running and working. During initial
stages of planning and designing, the members of the software team will
be able to, in fact, dictate the quality of the software to be produced even
before we start coding. You don’t have to wait until the programming is
over and done with before you can assess the quality of the software.

What is the deliverable of a software project? To most minds, it is but the

working program. The software project is only a part of the whole system
of deliverables which should include documents detailing the intricacies
of the software delivered. These other deliverables will help in the eventual
use and maintenance of the software.

There are other misconceptions. Can you name and discuss some of these
misconceptions that need to be corrected so we can be more effective in
delivering good quality cost-efficient software?

Software Use and Maintenance

Now, come with me and let us observe what’s going on in Company A on
Street 2000. Come in and let us both watch what is happening inside.

Well, this does not seem to be a lucky day for the employees of Company
A. They’ve been trying to call Software House Z but all the software
engineers are not available at this time. The manager of Company A is
already frantic. What’s going on? The service section of the company has
a long queue of clients outside. It’s one of those days. The software system
that Software House Z developed for Company A has crashed once again.

UP Open University
 Unit I Module 1 13

You may be wondering of the loss this company had during this time.
Errors in software systems can cause real problems for the user. Consider
applications that involve millions of dollars like the rocket carrying Mariner
I. An $18 to $20 million loss was estimated when this rocket had to be
destroyed on July 22, 1962 two hundred ninety seconds after it was launch
because of an error in the computer program.

The effect of errors in a software system to the operations of the business

of a client may not be as catastrophic and dramatic as the ones cited
above. Once an error has been detected by the client, it could be resolved
by communicating with the developer and reporting the error. The
developer then modifies the system as per complaint of the client. This
process of integrating corrections into the software is part of what we call
software maintenance.

Now, it is often the case that the members of the maintenance team are
not the same people in the developing team. How can this new set of
people maintain a software system that they are not familiar with in the
first place, since they were not the ones involved in its development? The
maintenance team will rely heavily on the documentation done by the
developing team of the software concerned to carry out maintenance of
the software. Software maintenance will be a nearly impossible task if
good documentation of the software is not available. Did the developing
team provide a precise and detailed documentation of the various stages
of the development of the software? Are the code properly documented
as well? This explains why careful documentation is extremely necessary
during software development. There are cases when it is better to build a
new software rather than try to fix an old one with no documentation.

Let us find out how much time and resources are used for software
maintenance in the past few decades. Studies show that a large portion of
the cost of existing software is on the maintenance of these software, in
contrast to software development. Surveys show that software systems
are usually developed within 1 to 3 years, while software use (and eventual
maintenance) spans from 5 to 15 years (Fairley, 1985). This means that a
shorter span of time is devoted to the development of the software
compared with the time to maintain it, with a ratio of 40/60, 30/70 or as
high as 10/90.

Since it is already a trend in previously developed software systems that

much effort and resources are used for software maintenance, the question
that we need to address is: “How do we reduce the maintenance cost?”
One way we can reduce maintenance cost is to carefully develop the
software system. In fact, software maintenance is closely linked with how
the system was developed. The next question that probably popped up in
your mind is: “What aspects in software development should we carefully

UP Open University
14 CMSC I Software Engineering

address as developers so that we can come up with software that will

entail less maintenance?” These questions will lead us to study of the details
of the events in software development that you will find in the succeeding
modules.

SAQ 1-3
Explain how software development affects the software’s use and
maintenance. In this regard, how does it determine the overall
cost of a software system? You may write your answer on the
space provided below.

Congratulations! You’ve made it to the end of Module 1. If you still have

another hour to study, why don’t you now proceed to Module 2? If not,
you may now take your break and start with Module 2 afresh.

UP Open University
 Unit I Module 1 15

References

Here is a list of possible books that you can read for further research and
more details. The set of books can be used for the whole course.

Fairley, Richard. (1985). Software engineering concepts. Mc-Graw Hill Inc:

USA.
Hawryszkiewycz, I.T. (1991). Introduction to systems analysis and design.
Prentice Hall: Australia.
Lamb, David A. (1988). Software engineering: Planning for change. Prentice
Hall: New Jersey.
Pfleeger, SL. (1991). Software engineering: The introduction of qualifty software.
McMillan Publishing Company.
Pressman, R.S. (1992). Software Engineering: A practitioner’s approach. 3rd
Ed., McGraw-Hill Int. Editions.
Sommerville, Ian. (1995). Software engineering (Fifth Edition). Addison-
Wesley:England.

UP Open University
 Module 2
Project Planning

P lanning is the first stage in software

development. It is a very important
component in the development process since it has
Objectives
a tremendous influence on the success of the At the end of this module, you
succeeding stages in the development of the should be able to:
software and of the eventual software product
delivered to the client. As the saying goes: 1. Explain the aspects of
software development
He who fails to plan, plans to fail. planning;
2. Identify software metrics on
If we fail to plan the development of software, we particular programs;
are planning to fail. 3. Identify and explain the
different models in project
There are generally two components of planning, estimation; and
namely: estimation and scheduling. We will be 4. Perform project estimation
discussing estimation in this module, and for simple projects.
scheduling in a succeeding module. Monitoring
of these during the development is discussed in
the next module entitled Software Project Management.

Components of Planning a Software Project

Planning is necessary for the successful development and management of
a software system. It involves clearly identifying the tasks to be
accomplished, the work to be done, the solution strategy, the resources
18 CMSC I Software Engineering

needed, the risks involved, the documents to be produced, the schedule to

be followed, and the monitoring of all these as the project unfolds. Each
of these components needs to be carefully considered in preparation for
the succeeding steps in the lifecycle of the software.

Communication techniques
Where do we begin the planning of the software project? We start the
project by finding out from the client about the system that he wishes to
computerize. If the client wants to computerize an existing manual system
or parts of it, then we investigate how the existing system works. We put
in writing a description of the existing system, the problems being
encountered and the environment domain. Based on these, we establish
the scope of the desired software system, and state objectives of the project.
We develop a definitive statement using the client’s terminology of the
system.

Notice that this particular stage largely depends on the effectiveness of

the communication between the client and the development team. In
general, there may be some communication barriers that need to be
addressed. Listen to what a wife is saying to her husband:

I don’t know if you understand what I think I said when you said what
I thought you said.

Such a conversation is quite common when there is a communication

problem. Communication techniques can be used to enhance better
communication between the client and the development team, and these
are discussed in the next module on Software Project Management.

Communication at this point is also largely dependent on the level of

computer literacy of the client. If the client has some level of computer
literacy, then these discussions can be straightforward. On the other hand,
the client who doesn’t have enough background in computers may have
a very vague idea of what he wants to computerize and what aspects of
the existing system can actually be computerized. The developing team
will have to assist the client in specifying the desired system.

UP Open University
 Unit I Module 2 19

Goal setting and planning

Goal setting is essential to achieve the desired software. There is a saying
that goes this way:

If you don’t have a goal, you will hit anything.

It is important to know your goal, so that you can work together with
your team towards achieving your goal. Most software teams do not
achieve anything efficiently, simply because the goals are not explicitly
stated at the beginning of the development process. We need to set goals.

Setting goals is also important to effective planning. You plan the

development to ensure that the goal (which is the software system
requested by the client) is achieved within the financial and time
constraints of the project. You identify the needed inputs to the
development so that you can come up with an estimate of the cost and
the time frame of the project. The problem at this point is how to estimate
these inputs. We will address these issues in the succeeding sections.

A solution strategy
After defining the problem, you propose a computerized system and justify
a computerized solution strategy for the problem. Ask questions such as:
Is it cost-effective, and socially and politically acceptable? Does it provide
the same or more services and information as in the old system using less
time and personnel?

Now, using the suggested solution strategy, identify the necessary resources
to build the software. There are three main resources, namely: hardware,
software and personnel. Identify four characteristics of each resource: a)
description of resource; b) statement of availability; c) chronological time
that the resource will be required; and d) duration of time that the resource
will be applied. These resources are to be used within money and time
constraints. Detailed identification of these resources and their estimated
amount necessary for the completion of the project will help you to
reasonably and accurately estimate the cost of the project and schedule a
workable timetable for the completion of the project.

UP Open University
20 CMSC I Software Engineering

Count the cost

We can learn from the words of Jesus Christ Himself that we should count
the cost of every endeavor that we go into. Taken from the New King
James Version of the Bible:

“For which of you, intending to build a tower, does not sit down first
and count the cost, whether he has enough to finish it—lest, after he
has laid the foundation, and is not able to finish it, all who see it begin
to mock him, saying, ‘This man began to build and was not able to
finish.” (Luke, Chapter 14, verses 28 and 29)

So, before we build the software system, we must count the cost, perform
an estimate of all resources involved before even starting to build it. We
must plan and learn that our software system can be accomplished when
we sit down, and carefully and systematically plan and execute every
stage of the development.

Estimation techniques
We need to employ estimation techniques to be able to estimate the needed
resources for the development of the software system. In mathematics,
you solve the unknown variable based on the known. During planning,
you only have a description of the software to be produced and you want
to know the resources needed to develop this software.

You will notice several problem areas here. One is that the two main
constraints, the cost and time frame, are quantitative in nature. You want
to measure this in terms of the software to be produced, which is
qualitative. We need ways to “quantify” software. We are now faced with
the dilemma of estimating a qualitative data using quantitative means.
This is discussed in the next section on Software Metrics.

Some aspects of the quantitative constraints, cost and time, are also
qualitative in nature. For instance, the estimated cost can be computed by
adding together the costs of all the inputs. This may not be as
straightforward as it looks. As an example, the number of programming
hours necessary to achieve the desired software is identified, and then the
number of programmers needed and the corresponding salaries of each
programmer. The estimated cost to be incurred to pay the programmers is
computed. But how do you measure the competency of each programmer
to ensure that the number of programmers is adequate to develop the
desired software on time? Yet again, this is an issue of “quantifying”
qualitative data.

UP Open University
 Unit I Module 2 21

The second problem is that what we referred to earlier as a known variable,

which is the software to be produced, is really an unknown. How are we
to estimate a software system, which does not yet exist? Where are we
going to base our estimates? These concerns are discussed further in
succeeding sections on estimation models.

Software management
A major component of software development is the management of the
whole process. During planning, estimates of resources to be used are
identified. As you proceed in the development process, close monitoring
of actual resources being used as against the estimates is essential.
Correspondingly, you adjust your estimates and schedule accordingly,
and check whether you are still working within your constraints.

One of the major resources that we need is the personnel. It is important

at the onset to identify the organizational structure, the responsibilities
and accountabilities of each member of the team, and the communication
paths among the members. We will study this further in the next module.

System definition document

Ideas are best achieved when they are put in writing. There is a saying
that goes:

The paper and pen cannot forget, but the mind can.

It is, therefore, essential that all these preliminary planning are written
and organized. They are then collected into one document to be called the
system definition document. The client and the development team agree
with this document which becomes the legal document between the two
parties. After this, you are now ready to embark on the software project
development.

In the succeeding sections and modules, we are going to discuss these

components in detail.

After discussing the different components of planning a software project,

why don’t you answer the SAQ?

UP Open University
22 CMSC I Software Engineering

SAQ 2-1
Identify the various components of software planning as discussed
in the previous section. Can you tell me other components not
mentioned here?

Software Metrics
Planning the development of a software project entails trying to measure
computer software. How are we going to do this? We will be using what
is commonly called software metrics.

As mentioned in the previous section, it’s quite natural to measure

quantitative aspects of the software like lines of code, execution speed
and memory size. These aspects are called direct measures. Other aspects
of the software such as quality, functionality, complexity, efficiency,
reliability and maintainability are not measured in a straightforward
manner. These are called indirect measures. These are captured using various
software metrics.

Software metrics can be classified as size-oriented, function-oriented or

human-oriented metrics. These different methods of measuring software
are discussed in the succeeding sections.

UP Open University
 Unit I Module 2 23

Size-oriented metrics
Size-oriented metrics provide direct measures about a software. It includes
quantitative data about the software such as:

1. lines of code (LOC) or its variants (thousand lines of code, KLOC, etc.)
2. number of programmer-months of effort (PM)
3. cost in pesos (C)
4. pages of documentation
5. number of errors

Other software attributes can be computed from the data above as follows:
1. productivity = KLOC/PM
2. quality = number of errors/KLOC
3. cost = cost in pesos/KLOC
4. documentation = pages of documentation/KLOC

Notice that size-oriented metrics largely depend on the programming

language used for the implementation of the software because of the need
to know the lines of code of the software. Another problem is how to
estimate the lines of code of software that does not yet exist. This guessing
game will have to be based on some date derived from previously
developed software. These are the reasons why this approach is not well
accepted by a large number of software engineering professionals.

Function-oriented metrics
Function-oriented metrics are used to collect indirect measures of software.
In contrast to size-oriented metrics, function-oriented metrics do not use
LOC as a basis for measuring but uses program functionality. It measures
what is called function points (FP) that are computed from countable
measures of the software’s information domain and software complexity.
Information domain values are derived from:

1. number of user inputs

2. number of user outputs
3. number of user inquiries
4. number of files
5. number of external interfaces

Each of the data representing the above parameters is multiplied with the
corresponding complexity weights and added to come up with the function
point.

UP Open University
24 CMSC I Software Engineering

Other software attributes can be computed from the data above as follows:

1. productivity = FP/PM
2. quality = number of errors/FP
3. cost = cost in pesos/FP*1000
4. documentation = pages of documentation/FP

The inherent difficulty with this approach is the need to know the software
information domains at an early stage in the development of the software,
which may highly be improbable.

For both size-oriented and function-oriented metrics methods, estimation

can be done more effectively based on previously implemented software
by the developers. Therefore, the developers can compile a historical
account of software metrics of completed projects to assist them in the
development of succeeding projects.

SAQ 2-2
Consider a software with 27,200 lines of code, developed by one
programmer in 3 months, with 25 detected errors, at a cost of
P55,000 and 200 pages of documentation; with 9.9 function point.
Compute for the following using size-oriented and function-point
oriented metrics, and write your answers in the table below:

Software Metric Size-Oriented Function-Point

Productivity
Quality
Cost
Documentation

What do you notice with the results that you got? You’re right,
they are just numbers which do not mean anything at this time.
During planning, the software developing team compiles software
metric values from previously developed software and based their
estimates on these experiences. We will discuss how we use these
metrics to do estimation in the next section on Estimation.

UP Open University
 Unit I Module 2 25

Estimation
In performing estimates on the software to be developed, several models
can be used together to come up with an accurate cost estimate for the
software. There are two main means to top-down estimation: experiential
models and empirical models. Bottom-up estimation usually involves
defining what is called a work breakdown structure.

Experiential models
Experiential models appeal to experts’ judgment in estimating the cost of
the software to be developed based on previous experience to developing
possibly similar software systems. In a sense, the experts are requested to
make educated guesses about the effort to be used for the project. Usually,
the experts are asked to make three predictions on software characteristics:
optimistic estimate, the most likely estimate and pessimistic estimate. The
final expected estimate is computed from these three predictions using
the following formula:

E = (optimistic estimate + most likely * 4 + pessimistic estimate)/6

A variation to this model is the Delphi technique. In this approach, a group

of experts makes individual estimates to the software project. The averages
are computed and presented to the group for further refinements to the
estimates.

The problem with the experiential model is the level of confidence that we
have on a computed estimate since this approach is largely influenced by
the subjectivity of the experts invited to do the estimation. The estimate
can be re-enforced and refined using other estimation models.

Static estimation models

The static estimation model uses a statistical method called regression analysis
to perform a more formal estimation of the cost of the software project.
The model can be linear or nonlinear. A linear estimation model uses an
equation of the form:

E = c0 + Σ cixi

UP Open University
26 CMSC I Software Engineering

where each variable xi represents a system characteristic that affects cost,

and each constant c i is the corresponding cost coefficient of the
characteristic. The drawback of this method is the adherent nonlinear
behavior of system characteristics. Thus, nonlinear estimation techniques
are advised using the following formula:

E = c0 + Σ cixidi

where each constant di is the corresponding cost exponent of the particular

system characteristic.

Linear and nonlinear estimation techniques can be single-variable or

multivariable models. It depends on the number of particular
characteristics the estimation model uses to capture an estimate. Most
single-variable estimation models use the variable lines of code to compute
the effort estimate for a project. Multivariable estimations include other
characteristics such as personnel and programming environment.

An example of a static single-variable model is the basic COCOMO.

COCOMO
COCOMO is the acryonym for COnstructive COst MOdel. This model is
due to Barry Boehm. He suggested that the effort applied to a software
project in terms of programmer months (E) and the development time in
months (D) are affected by the type of software being developed.

He classified software projects into three: organic mode, semi-detached and

embedded. This classification is mainly based on the premise that the
hardware and software constraints in which they have to work with will
naturally affect the cost of development. Organic mode refers to small
and simple projects, while embedded mode refers to large, complex and
with rigid hardware and software constraints. Semi-detached mode is a
software project somehow in between the first two. It is relatively
intermediate in size and complexity, and with moderate interaction with
the software and hardware environment.

The basic COCOMO is a static single-variable estimation model. It uses

the following formula to compute E and D:

E = a(KLOC)b
D = c * Ed

UP Open University
 Unit I Module 2 27

where a, b, c and d are constant based on the type of project with the
following values:

Software a b c d
Project
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

The basic COCOMO was extended into the intermediate level to include
other software development characteristics into the estimation of effort
such as product, hardware, personnel and project attributes, rather than
estimating based solely on the lines of code.

A complete list of these characteristics are given below:

1. Product attributes
a. Required software reliability
b. Size of the databases
c. Complexity of the system
2. Hardware attributes
a. Execution time constraints
b. Storage constraints
c. Virtual machine volatility
d. Computer response time
3. Personnel attributes
a. Capability of analyst
b. Capability of software engineer
c. Capability of programmer
d. Virtual machine experience
e. Programming language experience
4. Project attributes
a. Use of software development tools
b. Use of software engineering methods
c. Required development schedule

The intermediate COCOMO uses the following formula to compute the

estimated total effort E:

E = a(KLOC)b + EAF

UP Open University
28 CMSC I Software Engineering

where the values of constants a and b are derived from the following
table:

Software project a b
Organic 3.2 1.05
Semidetached 3.0 1.12
Embedded 2.8 1.20

and EAF is the effort adjustment factor which is computed from the software
attributes listed above. Each attribute affects the overall effort of the
development of the software and categorized as either very low, low,
nominal, high or very high using the following multipliers:

Tolerance Effect Multiplier

Very low Slight inconvenience 0.77
Low Losses easily recovered 0.88
Nominal Loss recoverable with moderate
difficulty 1.00
High High financial loss 1.15
Very high Risk to human life 1.40

The detailed COCOMO is an example of a dynamic estimation model.

Dynamic estimation models

The dynamic estimation model uses the same major principle as the static
estimation models but measures the requirements as a function of time.
As the development of the software progresses, the amount of resource
used vary from one step of the development to another. Three models are
mainly used: detailed COCOMO, the Putnam model and function point
models.

Detailed COCOMO

The detailed COCOMO model includes all the characteristics of the

intermediate COCOMO together with the assessment of each attribute in
relation to the various steps (e.g. analysis and design) in the development
process.

For example, the analysis of the project is more affected by the capability
of the systems analysts than the programmers of the system. The effort
adjustment factor is computed based on the effect of an attribute to the
amount of modification required on the phases of the development process.

UP Open University
 Unit I Module 2 29

For example, we measure the percentage of design to be modified in relation

to the software engineering tools used.

Putnam model

The Putnam model is another example of a dynamic estimation model. It

assumes a distribution of effort during the various phases of the
development process using the Rayleigh-Norden curve (shown in Figure 2-
1). This curve can be used to derive the following equation showing the
relationship of the lines of code (L) to the overall effort (E) and development
time (T):

L = C * E1/3 * T4/3

where C is a state-of-technology constant indicating hardware constraints,

program complexity, personnel experience levels, and the programming
environment.

Effort

Time
Figure 2-1. Rayleigh-Norden curve of effort distribution

Function-point model

Estimation models so far presented largely rely on the estimated lines of

code of the software project. Doing this makes our estimation dependent
on the programming language used in the development. Do you remember
the first time you wrote a program to output a message “Hello world!” on
the screen using an assembler? How many lines of code did you have to
include in your program? How many lines of code do you have to write if
you are using a high level language like Pascal or C? This is the basic
argument against the models presented so far, and researchers have
experimented on another approach, the function point model.

UP Open University
30 CMSC I Software Engineering

The function-point model uses the function-oriented metrics (as described

in a previous section). One such model is the Albrecht’s function point
model, which is based on functionality of software measured in terms of
requirements rather than the number of lines of code. The requirements
are listed such as data items, output screens and files, and given
corresponding weights depending whether the particular requirement of
the software project is simple, average or complex in nature.

SAQ 2-3
Using the same software project in SAQ 2-2, estimate the effort
applied in programmer-months (E) and development time (D)
using:

1. Basic COCOMO

Software Project E D

Organic

Semidetached

Embedded

2. Intermediate COCOMO (using EAF=1.2)

Software Project E D

Organic

Semidetached

Embedded

UP Open University
 Unit I Module 2 31

Work breakdown structure

The estimation methods discussed so far are top-down in nature. We are
now going to consider a bottom-up approach called the work breakdown
structure (WBS). It involves identifying a hierarchical structure of product
components of the system. Cost estimates are made on individual
components and summed upwards in the hierarchy to estimate the total
cost of the software. Consider the software IsaWika! (Roxas and Borra,
1997) that translates English sentences to equivalent Filipino sentences.
The WBS of this software is given in Figure 2-2.

IsaWika!

Input System Dictionary Syntax Translator Output System

Analyzer

Sentence Lexical Syntax Post

Grabber Analyzer Generator Editor

Figure 2-2. Work breakdown structure of IsaWika!

Cost estimates are made first on the lowest level components sentence
grabber, lexical analyzer, dictionary, syntax analyzer, syntax generator,
post editor and output sentence. Then on the input system, dictionary,
translator and output system, and eventually, on the whole system, IsaWika!

Summary
Planning is necessary for the successful development and proper
management of a software system. It ensures that the goal is realistic and
can be implemented within the constraints of the project. It minimizes
schedule slippage, overextended budgets and high maintenance costs of
the software project. It involves cost estimation, scheduling and
organizational planning.

UP Open University
32 CMSC I Software Engineering

Activity 2-1
For this activity, you need to go again to the library or browse
through your Software Engineering books. (Don’t be surprised if
in every module, I will ask you to do some research. You have
probably noticed now that software engineering is a fast advancing
field, the foundations of which are wide and still evolving.) Study
the different approaches to project planning discussed in the
different references and look into the examples they have described.
How can you apply this to any problem given to you?

Wow, congratulations! This is the end of Module 2. Relax and have a nice
meal. Start with Module 3 later.

UP Open University
 Unit I Module 2 33

References

Fairley, Richard. (1985). Software engineering concepts. Mc-Graw Hill Inc:

USA.
Lamb, David A. (1988). Software engineering: Planning for change. Prentice
Hall: New Jersey.
Pfleeger, SL. (1991). Software Engineering: The introduction of quality software.
McMillan Publishing Company.
Pressman, R.S. (1992). Software Engineering: A practitioner’s approach. 3rd
Ed., McGraw-Hill Int. Editions.
Roxas, R.E. O. and A.B. Borra. (1997). A machine translation from english to
filipino: IsaWika! Institute of Computer Science, UPLB.

UP Open University
 Module 3
Scheduling

S cheduling is the next stage in software

planning. After identifying the basic tasks
to accomplish our goal, we plan how much
Objectives
time is going to be spent on each task. At the end of this module, you
Scheduling a software project is not very should be able to:
different from the scheduling of other
development projects. This is why 1. Perform project scheduling
development methods and techniques used to using the critical path
schedule these projects can be applied to method; and
software development. In this module, we will 2. Evaluate a project using the
consider two of them: the critical path program evaluation and
method, and the program evaluation and review technique.
review technique.

It will be ideal to be able to follow such a schedule set at the beginning of

the development. But this is not always the case. There will always be
problems during the software development that will definitely alter our
cost estimates and schedules. We will have to decide at these times, which
among alternative options (or called risks) are we going to choose? We
will look into what is called risk management.
36 CMSC I Software Engineering

Let us say that during the next school break, your family is going for a
summer vacation. First of all, you have to decide at the beginning (at least
just vaguely) the following things:

1. How much money can be allocated to spend for this trip?

2. How long will the trip be?
3. Where do you want to go? Overseas or within the country?
4. Who are coming?
5. What preparations do you have to make before the scheduled trip?

The first two things above, the money and the duration of the trip, will
determine the other things, the where, who and what questions; or vice
versa. If you don’t have much money and time to spare, you will have to
limit the kind of vacation that you will have. You first check the amount
that you can afford to spend and the time that you can take off from the
office, and then you can decide where you can go based on your money
and the time that you can spare. The process could have been the other
way around. There may be times that you first thought of making a vacation
somewhere, then you calculate the amount that you will spend and the
duration of the trip. Refinements and readjustments will have to be made
on either the nature of the trip or the resources that you have.

These scenarios somehow illustrate software planning. Cost estimation

and scheduling are two major constraints in planning software projects.
Cost estimation considers the financial resource (discussed in the previous
module). In this module, we will have a look at scheduling which considers
the time constraints.

In our analogy above, you have two options in scheduling your vacation.
The first option is to determine the duration of your vacation based on
your own availability. Now you clearly identify when you want to go and
when you are coming back from the trip. Then you plan what you want
to do during the trip, the places you want to see, the friends you want to
visit; in general, the events that will take place within the specified time. It
may be that you have to add, delete or replace intended events due to
time and monetary constraints.

The second option is that you just determine roughly each event in your
trip and decide later the specific dates. In software development, it is usually
the case that the client requests for a software package that the company
wishes to use at a specific date. Therefore, the first option is usually
applicable for the development of software projects.

After setting the duration of a project, how do we proceed with the

scheduling? There are certain scheduling methods that we can use to
perform scheduling which are discussed in the next section.

UP Open University
 Unit I Module 3 37

Scheduling Methods
Scheduling starts with the identification of the phases involved during
the software development, which can be represented using a work
breakdown structure (WBS). Do you remember this from the previous
module? Let us have a look again at the WBS of our example (IsaWika!)
from the previous module (also given in Figure 3-1).

IsaWika!

Input System Dictionary Syntax Translator Output System

Analyzer

Sentence Lexical Syntax Post

Grabber Analyzer Generator Editor

Figure 3-1. Work breakdown structure of IsaWika!

From this WBS, we identify the major components of IsaWika! as follows:

Component 1: Input System

Component 2: Dictionary
Component 3: Syntax Analyzer
Component 4: Translator
Component 5: Output System

In scheduling, the components are further subdivided into specific steps.

In IsaWika!, the syntax analyzer (Component 3) can be subdivided into
the following steps:

Step 3.1: Design syntax analyzer

Step 3.2: Implement syntax analyzer

Steps are further subdivided into activities. In our example, the design of
the syntax analyzer (Step 3.1) can be subdivided into the following
activities:

Activity 3.1.1: Compile general grammar of English sentences

Activity 3.1.2: Identify grammar of English sentences to be accepted
Activity 3.1.3: Identify formalism to represent English sentences

UP Open University
38 CMSC I Software Engineering

Activity 3.1.4: Develop data structure of English words

Activity 3.1.5: Develop data structure of English sentence
Activity 3.1.6: Define algorithm for syntax analyzer

There are several limitations to this hierarchical approach. One of these is

that it does not provide interdependence information about these activities.
If one activity is dependent on another, it means that the former can only
be undertaken after the latter has been performed. In other words, the
order in which the activities are to be accomplished is not captured in this
approach. Design steps in the component Translator cannot be done unless
Activities 3.1.1 to 3.1.3 are performed. We cannot design how the
translation from English to Filipino can be performed without first
designing the grammar (Activities 3.1.1 to 3.1.2) and the formalism for
the English sentences (Activity 3.1.3).

Secondly, possible concurrency of activities is also not captured in the

hierarchical presentation. In most systems development, there are usually
more than one person working on the project. It is therefore, important to
identify which activities can be done simultaneously, and consequently,
which can be assigned to different members of the team. In IsaWika!, the
identification of the grammar of the English sentences (Activity 3.1.1) can
be done simultaneously with the identification of the grammar of the
Filipino sentences (an activity in the syntax generator, of Component 4).

Due to these limitations, the approach is extended to capture the

interrelationships of various activities. An activity graph (or task network)
is used to illustrate the flow from one activity to another. An example of
which is presented in Figure 3-2. An activity graph provides a graphical
representation of activities of the software development, where the nodes
represent the various milestones of the development (or particular
“landmarks” in the software development), the edges represent activities
and labels of edges represent the estimated duration of the accomplishment
of each activity. An activity path shows the order of accomplishment of
activities in that path. The length of a path is computed by adding the
label of the edges, thus, adding the duration of each activity on the path.
An activity path with the start node as the first node and the finish node
as the last node is a start-to-finish path. The length of the longest start-to-
finish path gives the duration of the whole software development process.
(Note that there may be more than one path from start to finish.)

UP Open University
 Unit I Module 3 39

4 3
C D E

3 1
START

5 3 2 7 1
A B H I J K

8 1 FINISH

2
F G

Figure 3-2. Activity graph for a project

In the example in Figure 3-2, the edges are labeled with the duration of
each activity in days. Thus, the activity represented by the edge CD can
be completed in 4 days. We will follow the convention that the
chronological order of the milestones follows an alphabetical order,
meaning, milestones D, H and G must first happen before I, and milestones
E and I before J. This therefore captures interdependence information
among activities. For instance, activities represented by edges DI, HI and
GI are necessary before milestones I is achieved and before activity IJ can
be accomplished. There are three start-to-finish paths in this example:
ABCDEJK, ABHIJK and ABFGIJK, with durations 17 days, 15 days and
24 days, respectively. Can you try to compute these durations yourself?

Based on this activity graph that shows the different activities to be

performed, how do we now estimate the completion time of the project?
Two methods are presented here: the critical path method, and the
program review and evaluation method.

Critical path method

Critical path method (CPM) provides a quantitative tool to calculate the
completion time for each activity and eventually for the entire project.
From the activity graph, the critical path is determined to establish the
estimated time to complete the entire project. The critical path of an activity
graph is the start-to-finish path with the longest length.

UP Open University
40 CMSC I Software Engineering

Using CPM, we identify the following parameters:

1. activity duration. The time duration to complete a specific activity.

2. earliest start time. This is the time for activity initiation when all
preceding activities are completed in the shortest possible time.
3. latest start time. This is the time for activity initiation when all preceding
activities are completed with possible delays incorporated.
4. earliest finish time. This is the time for activity completion when all
preceding activities are completed in the shortest possible time. This is
derived from the sum of the earliest start time and activity duration.
5. latest finish time. This is the time for activity completion when all
preceding activities are completed with possible delays incorporated.
This is derived from the sum of the latest start time and activity
duration.
6. slack (or float). This is the additional time allowed in scheduling activities
but still within scheduled completion.

In some cases, two activities (or series of activities) can be performed

concurrently. Although these activities may be done simultaneously, it
does not necessarily mean that they will finish at the same time. In fact, in
most cases, they may have the same start times but different finish times.
Using the diagram below, let us say that Path A has duration time TA,
while Path B requires time TB.

Path A

Path B

If TA>TB, then the finish times of Path B is described as follows:

earliest finish time = earliest start time + TB

latest finish time = earliest start time + TB + slack

where slack is computed as: TA – TB. The latest finish time of Path B can
also be computed from its earliest finish and slack times, which will yield
the same value:

latest finish time = earliest finish time + slack

The critical path is the longest start-to-finish path, which contains the
chain of activities that dictate the duration of the project. The critical path
achieves milestones with no slack times.

UP Open University
 Unit I Module 3 41

Consider the activity graph in Figure 3-3. To compute the estimated time
to accomplish the project, we determine first the critical path. We find the
critical path by computing the length of each of the start-to-finish paths.
These paths are:

ABCDHIJ
ABGHIJ
ABEFHIJ

with lengths 28, 33 and 27, respectively. This means that the critical path
is the second one above.

Figure 3-3. Activity graph for another software project

Since the duration of the project is determined by the critical path ABGHIJ,
then we can determine at this point the start and finish times of the
activities on this path, namely: AB, BG, GH, and IJ (shown in Table 3-1).
Since activity AB is the first activity, we set the start time to zero. The
earliest and latest (start or finish) times of each activity on the critical path
are the same and the slack value is always set to zero. The start time of an
activity is the finish time of the previous one in the critical path. The finish
time is computed as the sum of the start time and the duration of the
activity. Fill-in the table in the order of the activities in the critical path.
Make sure that the finish time of the last activity (IJ) is the length of the
critical path. In our example, it should be 33 days.

What is the significance of the length of the critical path? The critical path
is the sequence of events that bottlenecks the schedule of the project. It
identifies the accomplishment of activities that are crucial so project
completion will be within the original schedule. In our example, 33 days
is the duration of the project.

UP Open University
42 CMSC I Software Engineering

Activity Duration Earliest Latest Earliest Latest Slack

Start Start Finish Finish
Time Time Time Time
AB 10 0 0 10 10 0
BC 3
CD 4
DH 3
BG 9 10 10 19 19 0
GH 6 19 19 25 25 0
BE 5
EF 2
FH 2
HI 5 25 25 30 30 0
IJ 3 30 30 33 33 0

Table 3-1. Computation of start and finish times for a project

Now, we want to know the start and finish times of the other activities
(computed values for our example are shown in Table 3-2). To do this, we
need to consider the paths BCDH and BEFH. These paths have earliest
start times 10 since they commence after activity AB has been
accomplished. It’s easy to fill-in the earliest start times of each milestone
in these paths. For illustration purposes, let us consider path BCDH first,
which has activities, namely: BC, CD and DH. From milestone B, just
compute the earliest start and finish times of BC, CD and DH consecutively.
From the earliest finish time of AB, we compute the earliest start and
finish times of BC as follows:

earliest start of BC = earliest finish time of AB

earliest finish of BC = earliest start time of BC + duration of BC

The earliest time of an activity is the earliest finish time of the previous
activity. Thus, the earliest start and finish times of activities CD and DH
are computed in the same way.

The same procedure is followed to compute for the earliest start and finish
times of the activities in the path BEFH, namely: BE, EF and FH. Table
3-2 shows these values.

UP Open University
 Unit I Module 3 43

Activity Duration Earliest Latest Earliest Latest Slack

Start Start Finish Finish
Time Time Time Time
AB 10 0 0 10 10 0
BC 3 10 13
CD 4 13 17
DH 3 17 20
BG 9 10 10 19 19 0
GH 6 19 19 25 25 0
BE 5 10 15
EF 2 15 17
FH 2 17 19
HI 5 25 25 30 30 0
IJ 3 30 30 33 33 0

Table 3-2. Computation of start and finish times of concurrent activities

Now, have a look at the activity graph in Figure 3-3. Notice that milestone
H can only be achieved after we accomplish activities DH, GH and FH.
The earliest and latest finish times of GH (which is an activity in the critical
path) are 25, while the activities DH and FH finish ahead of time,
specifically only after 20 and 19 days, respectively (highlighted in Table
3-2). This shows that activity DH has 5 days in excess and FH has 6 days.
These days are the activities’ slack times. This slack time is also applicable
to the other activities in the concurrent or parallel paths.

How do we interpret these results? Consider the activities in the concurrent

paths, BCDH and BEFH. The latest start time of each activity is computed
from the earliest start time of activity and slack time of concurrent path as
follows:

latest start time = earliest start time + slack time (of concurrent path)

The actual values are shown in Table 3-3.

UP Open University
44 CMSC I Software Engineering

Activity Duration Earliest Latest Earliest Latest Slack

Start Start Finish Finish
Time Time Time Time
AB 10 0 0 10 10 0
BC 3 10 15 13 5
CD 4 13 18 17 5
DH 3 17 22 20 5
BG 9 10 10 19 19 0
GH 6 19 19 25 25 0
BE 5 10 16 15 6
EF 2 15 21 17 6
FH 2 17 23 19 6
HI 5 25 25 30 30 0
IJ 3 30 30 33 33 0

Table 3-3. Computation of latest start and slack times of concurrent activities

Again, the corresponding latest finish times are computed from the sum
of the latest start time of particular activity and the duration of the activity.
The final values are given in Table 3-4.

Note that the latest finish times of the activities DH, GH and FH are the
same, specifically, 25 days. Milestone H is only reached after the three
said activities are accomplished, then activity HI can commence after day
25.

Activity Duration Earliest Latest Earliest Latest Slack

Start Start Finish Finish
Time Time Time Time
AB 10 0 0 10 10 0
BC 3 10 15 13 18 5
CD 4 13 18 17 22 5
DH 3 17 22 20 25 5
BG 9 10 10 19 19 0
GH 6 19 19 25 25 0
BE 5 10 16 15 21 6
EF 2 15 21 17 17 6
FH 2 17 23 19 25 6
HI 5 25 25 30 30 0
IJ 3 30 30 33 33 0

Table 3-4. Final schedule of activities using CPM

Now, why don’t you take your pencil and try solving the next SAQ?

UP Open University
 Unit I Module 3 45

SAQ 3-1
Consider the following activities represented as edges in an activity
graph for a project:

Activity Duration (days)

AB 5
BC 3
CD 4
DE 3
DI 1
EJ 2
BH 3
HI 2
BF 8
FG 2
GI 2
IJ 7
JK 1

1. Draw the activity graph for this project and label the edges.

2. What is (are) the critical path (or paths) of this project? How
long is the duration of the project?

UP Open University
46 CMSC I Software Engineering

SAQ 3-1 continued

3. Complete the table below by filling in the missing start and

finish times, and the slack time.

Activity Duration Earliest Latest Earliest Latest Slack

Start Start Finish Finish
Time Time Time Time

AB 5
BC 3
CD 4
DE 3
DI 1
EJ 2
BH 3
HI 2
BF 8
FG 2
GI 2
IJ 7
JK 1

Program evaluation and review technique

Program evaluation and review technique (PERT) is a popular CPM. It
integrates statistical methods in establishing most likely time estimates for
individual tasks.

In our discussion of CPM, we assumed that the developing team knows

exactly how long each activity will take to accomplish. But this is not
always the case. We may have an idea of a range of time it will take to
undertake these activities. Consider our summer vacation analogy in the
previous section. We can only estimate the land travel time from one city
to another, but it may not be possible to be exact in determining this. We
need to consider the traffic, possible stop-overs, and so on. Naturally, we
can identify an interval of the possible time to accomplish an activity.

In PERT, this interval (or call “window”) for each activity can be computed
by identifying the following:
1. expected (or probable) duration of an activity; and
2. variance of the duration.

UP Open University
 Unit I Module 3 47

The expected duration is a particular point in the time interval, and the
variance describes the width of this interval. From these values, the critical
path can be calculated and the activities on this critical path are identified.
These activities are probable bottlenecks in the schedule of the project
development.

This is all we want to discuss here. Now, go and read the next activity for
you, then schedule a time to go over your books or a trip to the library.

Activity 3-1
Other planning tools are gantt charts and histograms. Can you
find out what these are and what information about software
planning they capture? You can use the space below to outline
your findings.

UP Open University
48 CMSC I Software Engineering

Risk Analysis
After making our initial schedule for the software project, it will be ideal
to be able to follow such a schedule. But, as we have mentioned earlier,
this is not always the case. There will always be problems during the
software development that will definitely alter our cost estimates and
schedules. We will have to decide at these times, which among alternative
options (or called risks) are we going to choose? How do we manage such
risks during the software development?

During planning, we are already taking some risks that we may not be
aware of. There are several options from which we can go, and we
eventually make some choices that are actually called risks in software
development. For example, are you going to hire new programmers for
the project? If so, how can you assess the adequacy of their level of training
for the nature of the project at hand?

Risk analysis involves risk identification, projection, assessment,

management and monitoring. We have to identify risks, be able to
anticipate certain risks during the development, assess the impact of such
risks on the development, plan risk management during development and
monitor risks during the development. For more information on risks, please
read Pressman (1992).

Summary
Scheduling is a very important aspect of project planning. It is setting
goals for the time duration of the project. In every undertaking, we must
set our goals and plan to achieve those goals. If we don’t have a goal for
time completion of our project, the development will not eventually get
completed. Together with cost estimation, the role of scheduling in software
development cannot be overemphasized. You need to do this each time
you embark on developing a software project.

References

Fairley, Richard. (1985). Software engineering concepts. Mc-Graw Hill Inc:

USA.
Pressman, Roger. (1992). Software engineering: A practitioner’s approach.
3rd Edition. Prentice Hall: New Jersey.

UP Open University
 Module 4
Software Project
Management

S oftware development is a complex task

that requires software, hardware,
manpower, procedures and tools within time
Objectives
and financial constraints. For any software At the end of this module, you
development project to be successfully carried should be able to:
out, we need management tools, which we
started to discuss in the previous modules. In 1. Identify the number of
this module, we will focus on the management communication paths in an
of one particular resource that we need for organizational set-up; and
software development, that is, the personnel 2. Identify and explain the
(or called manpower). Personnel management different project structures
requires experience, training and appropriate and team organizational
tools because of its adherent dynamism and structures that can be
complexity. implemented in a project.
In this module, we will consider the
components of personnel management,
communication project roles, project structure and organization.

Personnel Management
Another aspect of planning involves organizing and planning personnel.
After outlining the tasks necessary for the project and the time allotment
for each task, we now identify the personnel profile needed to accomplish
these tasks and their organization, which is collectively referred to as
personnel management.
52 CMSC I Software Engineering

Personnel management is a very important component of the project

development. Have you worked in a group or led a group in which
members didn’t seem to have the right “chemistry”? This may be due to
several factors, some of which are as follows:

1. personality
2. ability to communicate
3. training to perform the work
4. experience in working in a group

Differences in the above factors may cause problems to the successful

delivery of the intended software project. These factors need to be
addressed even during planning, so plans can be refined and adjusted to
improve effectiveness of the development process. The first two factors
above, the personality differences and various levels of communication
skills of personnel, are further discussed in the section Communication Paths.

The latter two factors, lack of training and experience to perform tasks by
members of the project development team must be a real concern and
must also be studied at the beginning of the development. We identify
possible differences between the expected personnel profile and the actual.
These issues are discussed further in the section Project Roles.

We also need to decide on the organizational structure, which will govern

the implementation of the project. We will further discuss this in the section
Project Organization.

Communication Paths
A very important aspect of the whole development process is the effective
communication of all individuals concerned beginning with the client (see
Module 2 for an introduction), together with the members of the
development team. How can the members be able to communicate
effectively with one another?

The communication necessary between two members of the development

team is called a communication path. The communication paths among the
members can be identified at the beginning of the project development.
Let us say that every member needs to communicate with all the other
members of the team (illustrated in Figure 4-1). Note that using graph
theory terminology, this scenario can be represented as a complete graph
with the members represented as nodes and the communication paths as
edges. (Can you remember this from your CMSC A?) You will notice from
the figure that as the number of people involved increases, the number of
communication paths correspondingly increases. In general, if there are

UP Open University
 Unit I Module 4 53

N members of the team, then we have N(N-1)/2 communication paths

between members.

Figure 4-1. Communication paths in a software project

Let us examine this set-up. Because of the inherent difficulties in

communication, we intend to find a scheme to lessen the communication
paths necessary. Let us check whether it is really necessary for every
member of the development team to have a communication path to every
other member. Probably, we can form several smaller teams, where each
team member only communicates with members within the same team
(which is considerable smaller than the whole development group), and
only a small amount of communication paths between teams will have to
be added. How does this improve the number of communication paths?

For instance, if you originally have 10 members with everyone having a

communication path with every other member, then there will be 45
communication paths computed as follows:

communication paths = N*(N-1)/2

UP Open University
54 CMSC I Software Engineering

Since N = 10 members, then

communication paths = 10*(10-1)/2 = 10*9/2 = 90/2 = 45

If we form two small teams from these 10 people, with 5 members each,
how many communication paths are we going to have? Using the same
formula above, each team of 5 (with N=5) will have communication paths
computed as follows:

communication paths = 5*(5-1)/2 = 5*4/2 = 20/2 = 10

Communication paths for the whole development team is computed as

follows:

communication paths of group 1 +

communication paths of group 2 +
communication path between groups 1 and 2
= 10+10+1 = 21.

This is graphically presented in Figure 4-2.

Group 1 Group 2

Figure 4-2. Communication paths in a team of 5

This example illustrates the large improvement in the number of

communication paths when groups are formed. In this case, there was a
more than 50% improvement (from 45 to 21 communication paths).

UP Open University
 Unit I Module 4 55

Let us suppose that we are interested to find out the group membership
combinations based on the original number of members and the number
of groups that we want. For example, if we have 6 members and we are
forming 3 groups from these members, find the group membership
combination that will give the least number of communication paths. We
enumerate all the possible combinations for the number of members for
groups 1, 2 and 3, respectively: 1,1,4; 1,2,3; 1,3,2; 1,4,1; 2,1,3; 2,2,2; 2,3,1;
3,1,2; 3,2,1; and 4,1,1.

Notice that some of the combinations are only permutations of each other;
like 1,1,4 is a permutation of 1,4,1 and 4,1,1, meaning, these three will
yield the same group sizes, two teams with one member each and one
team with 4 members. We remove these permutations and compute the
number of communication paths for the rest of the groupings. We derive
the following:

Number of Members in Group Number of

Group 1 Group 2 Group 3 Communication Paths
1 1 4 0+0+4*3/2+3 = 9
1 2 3 0+1+3*2/2+3 = 7
2 2 2 1+1+1+3 = 6

where the number of communication paths (CP) of the whole team is

computed as:

CP of group 1 + CP of group 2 + CP of group 3 + CP of the 3 groups

The third combination of membership (2,2,2) gives the least number of

communication paths (6) for this problem.

Wasn’t that a good mental exercise?

The next concern will be on how to determine the groupings of the

development teams. This will have to be determined by the tasks to be
performed, the project roles needed to accomplish these tasks, and the
organization set-up to be employed. These are discussed in the succeeding
sections.

Let us try to answer on SAQ now. Go ahead and try to answer this SAQ.
You can check the procedure that we followed in this section to answer
this one.

By the way, after you’ve answered the SAQ, you may take a look at the
ASAQs at the end of the module so that you can check if your answer is
correct or not. Remember, try to answer the SAQ yourself before looking
at the answers.

UP Open University
56 CMSC I Software Engineering

SAQ 4-1
A software development team has 10 members. Perform the
following:

1. Enumerate all the possible membership combinations if three

subgroups are to be formed. You can write your answers in
the space provided.

2. Remove all permutation combinations in the list and write the

new list below:

UP Open University
 Unit I Module 4 57

SAQ 4-1 continued

3. Compute the CPs of all the groupings formed from #2 above

and write your results in the table below:

Number of Members in Group Number of

Group 1 Group 2 Group 3 Communication Paths

The number of rows may not be exact. Remove or add rows

whenever necessary.

4. Which among the group combinations above creates the least

number of CPs? Draw the graph representation of this group
combination in the space provided below to confirm your
answer.

UP Open University
58 CMSC I Software Engineering

Project Roles
In a stage play production, we form different groups to perform different
roles. We have the cast who will act on the stage, the stage and props
committee, the lightsmen, the musicians, scriptwriter, director and others.
Some people can take on two or more roles, depending on the nature of
the roles. For example, one person can be the scriptwriter, director and a
member of the cast. For some obvious reasons through, it will not be possible
for one person to simultaneously take on two roles. For example, one
cannot be both a lightsman and a musician during the play performance
(unless of course, he has three hands and two brains!).

In this analogy, we followed two steps: identification of roles and nature

of these roles, and identification of members who are taking on the roles
identified. In a similar manner, software development follows such steps.
Project rules are identified generally in two ways: phases in the lifecycle
and function tasks in the development. These two are discussed in this
module.

The second step is to identify the members who are taking on the roles in
the development process. This may involve putting these members into
groups to fulfill particular responsibilities during the development. We
will further discuss this in the next section.

Phase roles
The software development process involves several phases of the software
lifecycle. Can you still recall these phases from Module 1? Let me help you
recall them. We have the following phases:

1. planning
2. requirements analysis
3. design
4. implementation
5. testing
6. maintenance

Each of these phases has different tasks that may require various skills
and preparations from the participants involved. Thus, personnel profile
necessary at these various phases of the development will have to be
identified at the beginning of the development process. For example, during
the planning stage, the members will have to be equipped with managerial
skills and trained in using estimation and scheduling techniques (discussed
in Modules 2 and 3). Specific programming environments to be used in

UP Open University
 Unit I Module 4 59

the implementation will also determine the necessary personnel profile or

the additional training needed to equip the programming staff.

Functional roles
Recall that during planning, we identify the different tasks to be performed
based on the phases of the development process. We also determine the
functional tasks or activities that are to be accomplished to obtain the
intended software. Now these tasks and activities will have to be analyzed
against the personnel profile.

Let us consider our IsaWika! project example. Do you remember this

example that we used in the previous module? Let me refresh your
memory. IsaWika! is a software that translates English sentences to Filipino.
Some of the functional tasks require certain domain-specific knowledge
or skills. For instance, members of the design team of the syntax analyzer
and the translator will have to be acquainted with the syntactic and
grammatical rules of the language English, for the former, and both English
and Filipino, for the latter.

Project Organization
Once we establish the project roles and the personnel that we need, it is
also necessary to plan how to put these people together. How do we
organize our personnel so that the work can progress efficiently and
effectively? We need to determine the project structure and team
organization.

Project structure
Project structure determines the who’s who in the development process. It
dictates how a member is to be involved in the development during the
whole process. There are several formats that we can follow, and three
are presented here: project format, functional format and matrix format.

In the project format, all the members of the development team are involved
from the beginning of the development until the end. It appeals to the
advantage of diversity during the different phases of the software lifecycle.
One problem with this format is that fewer people may be necessary at
various phases of the lifecycle. Therefore, we need to carefully plan how
to keep everyone involved and busy at any time during the development.
One option may be to overlap phase implementations.

UP Open University
60 CMSC I Software Engineering

The functional format is based on the fact that various phases in the
development require different skills and knowledge, thus, may require
different sets of personnel. It appeals to the functional tasks to be
accomplished at various phases of the development, thus, assigning a group
of individuals to perform one specific task. In this case, the personnel can
specialize, improve and develop a particular skill or skills in one area or
field of study. For example, a group that performs software testing only
will be able to enhance their craft and improve on their skills, and be used
more effectively in future software projects. It will also be advantageous,
say for instance, to be performing testing on a software that another group
has developed, avoiding partialities.

A disadvantage with this approach is the backlog time (or orientation time)
that is involved in passing on to the next team in the development. We
need to minimize the necessity of passing on large amounts of information
to another group of people, to further minimize possible errors into the
system development. To address this problem, we can form component
teams as follows:

1. analysis
2. design and implementation
3. testing and maintenance

The third format is called matrix format. The matrix format specifically
caters to organizations that are working on several software development
projects at the same time. It uses the functional format but creates subgroups
within component teams, each one handling the component of one
software project. There is one disadvantage with this approach though.
A team working on a component of a software project has two managers,
one is the component team leader and the other is the software project
manager. There may be some confusion as to the line of responsibility and
must be settled early in the development.

We can find out how we can organize these teams in the next section.

Team organization
Individuals are grouped into teams and these teams must be run using
certain standards and protocols. There are two general approaches: the
egoless or democratic team, and the chief programmer team.

UP Open University
 Unit I Module 4 61

Egoless team
The egoless (or democratic) team is a team structure where all members of
the team are “equals”, and the team leader is only the first among “equals”.
For example, an egoless team with 5 members follows the management
structure given in Figure 4-2.

Figure 4-2. Management structure of an egoless team

This structure implies that decisions are made by team consensus and
leadership is by rotation. Each member of the team can freely communicate
with the other members without feeling intimidated if the member is the
team leader, or has a higher rank or position. This loose structure allows
for creativity, flexibility and dynamism in the development. The problem
with this set-up is the absence of a fixed leader. All members of the team
would have to be highly motivated and directed towards the goal, as
should be provided by a good leader. An alternative structure, the chief
programmer team, addresses this need.

Chief programmer team

In the chief programmer team, the chief programmer of a team carries out
the management of the team. This approach is hierarchical in nature,
where the chief programmer directs the work descriptions, assignments
and schedules, and the other members consist of technical staff, support
staff and a librarian (shown in Figure 4-4). The chief programmer takes
on the responsibility and authority in the development process. Other
members of the team are directly responsible to their chief programmer.
All members will have to communicate with the other members for

UP Open University
62 CMSC I Software Engineering

coordination purposes. Every programmer member of the team, about

two to five in number, performs implementation, documentation and unit
testing on individual assignments.

Chief Programmer

Technical Staff Librarian Support Staff

Figure 4-4. Management structure in a chief programmer team

Try to answer the next SAQ before I give you a summary of the module.

SAQ 4-2
Identify and explain the different project structures and team
organization that can be implemented in a software team.

UP Open University
 Unit I Module 4 63

Activity 4-1
Now it’s time for you to do some research work again! Try to find
the other aspects of software project management that we need to
consider. Have fun!

Summary
Effective software project management determines the successful
development of a software project. It largely depends on the project roles
necessary in the development and the corresponding personnel profile to
occupy such roles. Project and organizational structures are also important
for effective performance of functions and communication.

Congratulations! You’ve made it to the end of Module 4, and also the end
of Unit 1. Now, you are advised to review the whole unit so you can
refresh your memory of the initial tasks in project development and
management. Give yourself a treat for completing this unit! Why don’t
you get yourself a nice dinner, seat back and relax. Start with Unit 2
tomorrow!

UP Open University