Part Five

Management
and Evolution
The final part of the Worktext is concerned with the evolution of
software systems after they have been delivered to the customers. The
topics discusses general problems of software maintenance and explains
why this in an expensive process. This is also concerned with the
management of people involved in the software process. Other topics are
concerned with quality management, quality improvement and how to
deliver the system.

Contents
1. Managing People
2. Quality Management
3. System Delivery
4. Software Maintenance

Part Five Management and Evolution

Objectives:

 To emphasize the importance of people in the software engineering process.

 To explain why the working environment of software engineers affects their
productivity.
 To describe factors which affect group working and group organization for software
development
 To introduce the essentials of quality management and the ISO 900 quality
assurance standard.
 To explain how standards may be used in the quality management process.
 To identify the influence of software process factors on software quality and the
productivity of software developers.
 To discuss possible improvement strategies for different types of software process.
 To describe different types of software maintenance and explain the difference
between them.
 To explain why data re-engineering is a particularly complex and expensive process.
 Develop honesty and cooperation.

5.1 Managing People

The people working in a software organization are its greatest assets. They
represent intellectual capacity and it is up to software managers to ensure that the
organization gets the best possible in return on its investment in people.

Effective management is therefor about managing the people in an organization.

Project managers have to solve technical and non-technical problems by using the people
in their team in the most effective way possible. They have to motivate people, plan and
organize their work and ensure that the work is being done properly.

This part discusses the management of people on cognitive and social factors.

Cognitive Fundamentals

 Memory organization

Software systems are abstract entities and engineers must remember their
characteristics during the development process. The retention of information in the
memory depends on the memory structure. This seems to be hierarchical with three
distinct, connected areas as shown in Figure 5.1.1.

From senses

Introduction to Software Engineering | For CICT Classroom Use Only

75
 Short-term memory

Short-term memory

Figure 5.1.1
Human
Long-term memory
memory
(Large capacity, slow access
organization

1. A limited capacity, fast-access, short-term memory. Input from the senses is

received here for initial processing. This memory is comparable with registers in
computers; it is used for information processing and not information storage.
2. A large capacity, working memory area. This memory area has no longer
access time than short-term memory. It is used for information processing but
can retain information for longer periods than short-term memory.
3. Long-term memory. This has a large capacity, relatively slow access time and
unreliable retrieval mechanisms. This is used for the ‘permanent’ storage of
information. To continue the analogy, long-term memory is like disk memory on
a computer.

 Knowledge modeling

Information enters short-term memory and is processed before being stored

in long-term memory. The knowledge acquired during software development and
stored in long-term memory falls into two classes:

1. Semantic knowledge. This is the knowledge of concepts such as the operation of

an assignment statement, the notion of a linked list, how a hash search technique
operates and how organizations are structured. This knowledge is acquired
through experience and learning and is retained in a representation
independence fashion.

2. Syntactic knowledge. This is detailed representation knowledge such as how to

write a function declaration in C, what standard functions are available in a
programming language, whether an assignment is written using an ‘=’ or a ‘:=’
sign and so on. This knowledge seems to be retained in an unprocessed form.

 Motivation

Introduction to Software Engineering | For CICT Classroom Use Only

76
 One of the roles of project managers is to motivate the people who work for
them. Maslows (1954) suggested that people are motivated by satisfying their needs
and that need can be arranged in a series of levels as shown in Figure 5.1.2.

Self
Figure 5.1.2
reali
Human needs zati
hierarchy on
need
s
Esteem needs

Social needs

Safety needs

Physiological needs

In a psychological study, Bass and Dunteman (1963) classified professionals

into three types:

1. Task-oriented who are motivated by the work they do. in software engineering,
they are technicians who are motivated by the intellectual challenge of software
development.
2. Self-oriented who are principally motivated by personal success and
recognition. They are interested in software development as a mean achieving
their own goals.
3. Interaction-oriented who are motivated by the presence and actions of co-
workers. As software development becomes more user-centered, interaction-
oriented individuals are becoming more and more involved on software
engineering.

Management implications

Software engineers and project managers should be aware of how cognitive

processes affect software management, design and development. Devising and writing a
program is a problem-solving process. The software engineer must understand the
problem, work out a solution strategy then translate it into a program (Figure 5.1.3).

Introduction to Software Engineering | For CICT Classroom Use Only

Problem Partial solution
77
 Solution

New knowledge
Working memory
Existing knowledge

Figure 5.1.3
Problem Long-term memory
solving

 Training

People are motivated by opportunities to develop their skills. Training,

therefore, is not simply a way of ensuring that engineers have the necessary skills to
work on a particular project. It is also a way of demonstrating that an organization is
interested in the personal development of its staff. However, if training is not
designed for the trainees, it can have the opposite effect. People are demotivated
and do not benefit from the organizational investment in developing their skills.

 Motivating people

To motivate their staff, managers have to recognize that there are three
factors to be considered. These are the satisfaction of needs, the development of a
cohesive group and the organization of work so that people are assigned task
according to their skills and abilities.

In terms of the needs hierarchy, social, esteem and self-realization needs

must be satisfied. Being a member of a cohesive group is highly motivating to most
people. Therefore, managers should promote ’team building’ so that all members of
a team feel that they are respected and have a role to play.

Project staffing

One of the roles of a project manager is to choose staff to work on the project. In
exceptional cases, project managers can appoint the people who are the best suited to be
job irrespective to their other responsibilities or budget considerations.

Introduction to Software Engineering | For CICT Classroom Use Only

78
 If a manager has some choice of staff who can work on the project, there are a
number of factors which may be used to influence the decision who to appoint (Table
5.1.1).

Table 5.1.1
Factor Explanation Factors that
Application domain For a project to develop a successful system, influence the
experience the developers must understand the decision on
application domain. selecting staff
Platform exercises May be significant if low-level programming
is involved. Otherwise, not usually a critical
attributes.
Programming Normally only significant for short-duration
language experience projects where there is insufficient time to
learn a new language.
Educational May provide an indicator of the basic
background fundamentals which the candidate should
know and of their ability to learn. This factor
becomes increasingly irrelevant as engineers
gain experience across a range of project.
Community ability Very important because of the need for
project staff to communicate orally and in
writing with other engineers, managers and
customers.
Adaptability Adaptability may be judge by looking at the
different types of experience which
candidate have had. This is an important
attribute but often very difficult to assess.
Personality Again, an important attribute but difficult to
assess.

The decision on who to appoint to a project is usually made using three types of
information:

1. Information provided by candidates about their background and experience (their

resume or CV).
2. Information gained by interviewing candidates.
3. Recommendations from other people who have worked with the candidates.

Group working

The image of programmers presented in the media is an individualistic one. They

are often shown as technology-mad teenagers, who are inherently anti-social and who are
most interested in hacking into other computers.

Introduction to Software Engineering | For CICT Classroom Use Only

79
 In reality, most software engineers work in teams which vary in size from two to
several hundred people. In a study undertaken by IBM (McCue, 1988), the proportion of
time spent in various activities is shown in Figure 5.1.4.

Non-Productive activities
20%

Interaction with other

people
50%
Working alone
30%

Figure 5.1.4
Distribution of a software engineer’s time.
 Group composition

Most software engineers are motivated primarily by their work. Software

development groups, therefore, are likely to be composed of individuals who have
their own idea on how technical problems should be solved.

A group which has complementary personalities may work better as a team

than a group which has been selected in technical ability. People who are motivated
by the work are likely to be the strongest technically. People who are self-oriented
will probably be best at pushing the work forward to finish the job.

Leaders are normally appointed and report to the overall project manager.
However, the appointed leader may not be the real leader of the group as far as
technical matters are concerned. The group members may look to another group
member for leadership. He or she may be the most technically competent engineer
or may be a better motivator than the appointed group leader.

 Group cohesiveness

In a cohesive group, members think of the group as more important than the
individuals in it. Members of a well-led, cohesive group are loyal to the group. They
identify with group goals and with other group members. They attempt to protect

Introduction to Software Engineering | For CICT Classroom Use Only

80
 the group, as an entity, from outside interference. This makes the group robust and
able to cope with problems and unexpected situations. The group can cope with
change by providing mutual support and help.

Specific advantages of a cohesive group are:

1. A group quality standard can be developed.

2. Team members work closely together.
3. Team members can get to know each other’s work
4. Egoless programming can be practiced.

Cohesive groups, however, can sometimes suffer from two problems:

1. Irrational resistance to leadership change.

2. Groupthink

 Group communication

Effective communication among the members of a software development

group is essential if the group is to work efficiently. Factors which affect the
effectiveness of intra-group communications include:

o The size of the group

o The structure of the group
o The status and personalities of the group
o The physical work environment of the group

The number of potential communication links between individual members

increases as the square of the group size. The following describes some factors that
also affect communication within a group.

o Status of group members

o Personalities in the group
o Sexual composition of group
o Communication channels

 Group organization

Software engineering team sizes should normally have no more than eight
members. When small teams are used, communication problems are reduces.
Complex communication structures are not required.

For a big project which cannot be tackled by a single team in the time
available, multiple teams must be used. They should work independently with each
team tackling a significant part of the project in an autonomous way.
Introduction to Software Engineering | For CICT Classroom Use Only

81
Working environment

The workplace has important effects on the performance of people. Psychological

experiments have shown that behavior is affected by room size, furniture, equipment,
temperature, humidity, brightness and quality of light, noise and the degree of privacy
available. Group behavior is affected by architectural organization and telecommunication
facilities.

There is a real and significant cost in failing to provide good working conditions.
When people are unhappy about their working conditions, staff turnover increases. More
costs must therefore be expended on recruitment and training. Software projects may be
delayed because of lack of qualified staff.

5.2 Quality Management

Quality management involves defining appropriate procedures and standards and
checking that these are followed by all engineers. Software quality is a multi-dimensional
concept that is not easy to define in a simple way.

Quality management is not therefore just concerned with ensuring that software is
developed without faults and conforms to its specification.

Software quality managers are responsible for three kinds of activity:

1. Quality assurance. They must establish organizational procedures and

standards which lead to high-quality software.
2. Quality planning. They must select appropriate procedures and standards and
tailor them for a specific software project.
3. Quality control. They must ensure that procedures and standards are followed
by the software development team.

 Process quality assurance

Quality of the development process directly affects the quality of delivered

products. In automated mass production systems once an acceptable level of
process quality has been attained, product quality naturally follows. Figure 5.2.1
illustrates the approach on quality assurance.

Define process Develop product Assess product

quality
Introduction to Software Engineering | For CICT Classroom Use Only

82
 Improve process No
Quality
OK?

Yes

Figure 5.2.1 Standardize

Process-based quality process

Process quality is particularly important in software development. Quality

improvement focuses on identifying good quality products, examining the
processes used to develop these products then generalizing these processes so that
they may be applied across a range of projects. However, the relationship between
software process and software product quality is complex. Changing the process
does not necessarily lead to approved product quality.

Quality managers must ensure the quality of the software process that is
used. This involves:

1. Defining process standards such as how reviews should be conducted, when

reviews should be held and so on;
2. Monitoring the development process to ensure that the standards are being
followed;
3. Reporting the software process to project management and to the buyer of
the software.

 Quality reviews

Reviews are the principal method of validating the quality of a process or

product. They involve a group of people examining part or all of a software process,
system or its associated documentation to discover potential problems. The
conclusions of the review are formally recorded and passed to the author or
whoever is responsible for correcting the discovered problems. Table 5.2.1 shows
that there are several different types of review.

Table 5.2.1
Introduction
Types of to Software Engineering | For CICT Classroom Use Only
review 83
 Review type Principal purpose
Design or program To detect detailed errors in the design or
inspection code and to check whether standards have
been followed. The review should be driven
by a checklist of possible errors.
Progress reviews To provide information for management
about the overall progress of the project.
This is both a process and a product review
and is concerned with costs, plans and
schedules.
Quality reviews To carry out a technical analysis of product
components or documentation to find faults
or mismatches between the specification and
the design, code or documentation. It may
also be concerned with broader quality
issues such as adherence to standards and
other quality attributes.

Quality review has three functions:

1. A quality function in that they are part of the general quality assurance
procedures used in the organization.
2. A project management function whereby they provide information to
management about progress.
3. A training function in that engineers explain their design and justify their
design decisions.

The process of setting up and holding a review is illustrated in Figure 5.2.2. A

quality review is distinct from a design or code inspection in that the system may
not be described in detail. The review need not examine individual system
components but may be more concerned with the validation of components
interactions and with conformance to user’s requirements.

Selecting review Complete review

team forms

Introduction to Software Engineering | For CICT Classroom Use Only

84
Arrange place
and time
 Hold review

Figure 5.2.2 Distribute

The review process documents

On the completion of the review, the actions are noted and forms recording
the comments and actions are signed by the designer and the review chairman. All
comments should be considered along with other written submissions to the review
team. Comments should be classed under one of three categories:

1. No action. Either the comment was factually incorrect or the review decided
that the cost of rectifying the problem was unjustified.
2. Refer for repair. The review detected a problem and asked the document
originator or designed to fix that problem.
3. Reconsider overall design. The best way to solve an identified problem is to
change the overall design of the system or process.

 Software standards

One of the most important roles of the quality assurance team is the
development of product and process standards. Product standards define
characteristics that all product components should exhibit; process standards
define how the software process should be conducted.

Standards are important for a number of reasons:

1. They provide an encapsulation of best, or at least most appropriate,

practice.
2. They provide a framework around which the quality assurance may be
implemented.
3. They assist in continuity where work carried out by one person is taken
up and continued by another.

Software engineers sometimes consider standards to be bureaucratic and

irrelevant to the technical activity of software development. This is particularly
likely when the standards require tedious form-filing and work recording.
 Documentation standards

Introduction to Software Engineering | For CICT Classroom Use Only

85
 Documentation standards in a software project are particularly important as
documents are the only tangible way of representing the software and the software
process. Documents produced according to appropriate standards have a consistent
appearance, structure and quality. Documents make the software process visible so
must be consistent and readable.

Three types of documentation standards:

1. Documentation process standards. These standards define the process

which should be followed for documents production.
2. Document standards. These are standards which govern the documents
themselves.

Examples of document standards which may be developed are:

1. Document identification standards. As large projects

typically produce thousands of documents, each documents
must be uniquely identified.
2. Document structure standards. Each class of document
produced during a software project should follow some
standard structure. Structure standards should define the
sections to be included and should specify the conventions
used for page numbering, page header and footer information,
and section and sub-section numbering.
3. Document presentation standards. Document presentation
standards define a ‘house style’ for documents and they
contribute significantly to documents consistency.
4. Document update standards. As a document is change to
reflect changes in the system, a consistent way of indicating
these changes should be used.

3. Document interchange standards. It is increasingly important to

exchange copies of documents via electronic mail and to store documents
in databases.

5.3 System Delivery

We are nearing to the end of the system development. In this chapter, we investigate
two issues in the successful transfer of ownership from developer to user; training and
documentations. As a system is designed, we plan and develop aids that help users to use
the system. Accompanying the system is documentation to which the user refers for
problem solving or further information. Delivery is successful if training and
documentation enable the user to solve the problem the system was intended to solve.

Introduction to Software Engineering | For CICT Classroom Use Only

86
  Training

Two types of people use a system: user and operators. A user exercises the
main system functions to solve the problem described by the requirements
definition document. Thus a user is a problem solver for the customer. The operator
sometimes called computer operator if the operator’s function include powering up,
configuring the device, or performing other tasks that relate to the equipment
rather than to the system operation. Table 5.3.1 contains examples of user and
operator functions.

User Function Operator Functions

Manipulating data files Granting user access

Simulating activities Granting file access
Analyzing data Performing backup
Communicating data Installing new devices
Drawing graph and charts Installing new software
Recovering damage files

Table 5.3.1
User and operator functions
Types of training:

 User training. Training for user is based primarily on major system

functions and the user’s need for access to them. User training
introduces the primary functions so that users understand what the
functions are and how to perform them.
 Operator training. The focus of operator training is familiarity with
the system’s support functions. Training addresses how the system
works, rather than what the system does.
 Special training needs. Users and operators are usually trained in a
concentrated and complete course in system use. Often training
begins with the basics: how keyboard is configured, how menu
selections are made, and so on; this and other functions are
introduces slowly and investigated thoroughly.

Training aids:

 Documentations. Formal documentation accompanies every system

and support training. This document contains all the information
needed to use the system properly and efficiently.
 Icons and Online Help. A system can be designed so that its interface
with the user makes system functions clear and easy to understand.

Introduction to Software Engineering | For CICT Classroom Use Only

87
  Demonstration and classes. Demonstrations and classes add
individualization to training, and the users and operators respond
positively. They are usually organized as a series of presentations, so
that each class in the series teaches one functions or aspect of the
system. This can be more flexible and dynamic than paper or online
documents.
 Expert user. Sometimes, it is not enough to see a demonstration or
participate in a class. You need a role model to convince you that you
can master the system. In this case, it is useful to designate one or
more users and operators as ‘experts’. The experts are trained in
advance of other users and then used as demonstrators or helpers in
a classroom.

 Documentation

Documentation is part of a comprehensive approach to training. The quality

and type of documentation can be critical, not only to training but also to the success
of the system.

o User Manuals. This is a reference guide or tutorial for a system user. The
manual should be complete and understandable, so sometimes it
presents the system to user in layers, beginning with the general purpose
and progressing to detailed functional description.

The manual describes the system in more detail. A system

summary presents the following items:

1. The purpose or objectives of the system.

2. The capabilities and functions of the system.
3. The features, characteristics, and advantages of the system,
including a clear picture of what the system accomplishes.

o Operator Manuals. It presents material to operators in the same fashion

as user manuals. Thus, the operator guide explains hardware and
software configuration, method of granting and denying access to a user,
procedures for adding or removing peripherals from the system, and
techniques for duplicating or backing up files and documents.

o General System Guide. Its audience is the customer, rather than the
developer. This is similar to a system design document; it describes a
solution to a problem in terms the customer can understand. In addition,
the general system guide depicts the system hardware and software
configuration and describes the philosophy behind the system’s
construction.
5.4 Software Maintenance
Introduction to Software Engineering | For CICT Classroom Use Only

88
 The process of changing a system after it has been delivered and is in use is called
software maintenance. The changes may involve simple changes to correct coding errors,
more extensive accommodate new requirements. Maintenance therefore, is the context,
really means evolution. It is the process of changing a system to maintain its ability to
survive.

There are three different types of software maintenance with very blurred
distinctions between them:

1. Corrective maintenance. This is concerned with fixing reported errors in the

software. Coding errors are usually relatively cheap to correct; design errors are
more expensive as they may involve the rewriting of several program
components.
2. Adaptive maintenance. Means changing the software to some new environment
such as a different hardware platform or for use with a different operating
system. The software functionality does not radically change.
3. Perfective maintenance. This involves implementing new functional or non-
functional system requirements. These are generated by software customers as
their organization or business changes.

It is difficult to find up-to-date figures for the relative effort devoted to these
different types of maintenance. A survey by Lientz and Swanson (1980) discovered that
about 65% of maintenance was perfective, 18% adaptive and 17% corrective as shown in
Figure 5.4.1/ similar figures were posted by Nosek and Palvia (1990) 10 years later. It is
therefore reasonable to assume that the current figures are about the same.

Corrective Maintenance
17%

Adaptive Maintenance
18%
Perfective Maintenance
65%

Table 5.4.1
Maintenance Activities effort distribution
Maintenance
Introduction to Software Engineering | For CICT Classroom Use Only

89
 Maintenance activities are similar to those of development: analyzing requirements,
evaluating system and program design, writing or rewriting code, testing changes, and
updating documentations. Thus, the people who perform maintenance – analysts,
programmer, and designer – have similar roles. However, because chnages often require an
intimate knowledge of the structure and content of the system’s code, programmers play
much large role in maintenance than they did in development.

 Who performs maintenance? The team that developes a system is not always used
to maintain the system once it is operational. Often, a separate maintenance team is
employed to ensure that the system runs properly.
 Responsibilities of the Maintenance Team. Maintaining a system involves all
members of the maintenance team. Typically, users, operators, or customer
representative approach the maintenance team with a comment or problem. The
maintenance analyst or programmer determine which part of the code are affected
by the comment or problem, how the design is affected by any resulting changes,
and how much it will cost to implement a change. Thus the maintenance team works
with the system to accomplish several tasks:

o Understand the system

o Locate information in the system document
o Keep existing functions to accommodate new or changing requirements
o Add new functions to the system
o Find source of errors in the system
o Corerct errors identified in the system
o Answer questions about the way the system works
o Restructure design and code
o Rewrite design and code
o Delete design and code modules that are no longer useful
o Manage changes to the system as they are made.

The Problems of Maintenance

Maintening a system is difficult. Because the system is already operational, the

maintenance team balance the need for change with the need for keeping a system
accessible to user.

 Factors contributing to the difficulty of maintenance

As shown in Figure 5.4.2, it illustrates the factors that contribute to difficulty

of maintenance.

Introduction to Software Engineering | For CICT Classroom Use Only

90
 Programmers Effectiveness;
Product12%; 9% 10%;
Quality;
7%
Programmers Time
Availability; 8%; 6%
Perfective Maintenance; 65%;
Corrective Maintenance; 50%
17%; 13%

Adaptive Maintenance; 18%;

14%

Table 5.4.2
Maintenance effort distribution
Maintenance Cost

Maintenance cost vary widely from one application domain to another. For business
application systems, maintenance costs were broadly comparable with system
development cost. It is cost-effective to invest effort when designing and implementing a
system to reduce maintenance cost. Adding functionality after delivery involves an
extensive understanding and analysis activity.

Figure 5.4.3 shows how over all lifetime cost may decrease as more effort is
expended during system development to produce a maintenable system.

System 1

System 2

$0 $100,000 $200,000 $300,000 $400,000 $500,000 $600,000 $700,000

Development Cost Maintenance Cost

Table 5.4.3
Development and maintenance costs
Introduction to Software Engineering | For CICT Classroom Use Only

91
  The Principal Technical and Non-technical factors which affect maintenance

Maintenance costs are related to a number of product, process and

organizational factors. (Table 5.4.1)

o Module independence. It should be possible to modify one component of a

system without affecting other system components.
o Progarmming language. Programs written in high-level programming
langauge are usually easier to understand than programs written in a low-
level programming.
o Programming style. The way in which a program is written contributes o its
understandability and hence the ease which it can be modified.
o Program validating and testing. Generelly, the more time and effort spend
on design validation and program testing, the fewer errors in the program.
Consequently, corrective maintenance costs are minimized.
o The quality of program documentation. If a program is supported by clear,
complete yet concise documentation, the task of understanding the program
can be relatively straightforward. Program maintenance cost tend to be less
for well-documented systems than for systems supplied with poor or
incomplete documentation.
o The configuration management technique used. One of the most
significant costs of maintenance is keeping track of all system documents and
ensuring that these are kept consistent. Effective configuration management
can help control this cost.
o The application domain. If the application is clearly defined and well
understood, the system requirements are likely to be complete.
o Staff stability. Maintenance costs are reduced if system developers are
responsible for maintening theor own programs. There is no need for other
engineers to spend time understanding the system.
o The age of the program. As a program is maintained. The program is
dependent on its external environment it mjst modified as the environment
changes.
o The dependence of the program on its external environment. If a program
is dependent on its external environment it must be modified as the
environment changes.
o Hardware stability. If the program is designed for a particular hardware
configuration that does not change during the program’s lifetime, no
maintenance due to hardware chnages will be required.

Introduction to Software Engineering | For CICT Classroom Use Only

92
 Non-technical factors Technical factors

Application domain Module independence

Staff Stability Programming language
Program age Programming style
External environment Program validation
Hardware stability Documentation
Configuration
Management

Table 5.4.1
Maintenance Cost

Introduction to Software Engineering | For CICT Classroom Use Only

93
 EVALUATION NO. 05
1. What factors should be taken into account when selecting staff to work on a
software development project? Explain your answer.

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

2. Is it ethical that a manager in a software development project will not accept

recommendations/suggestions from a staff? Explain your answer.

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

3. Explain why a high-quality software process should lead to high-quality software

products.

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
Introduction to Software Engineering | For CICT Classroom Use Only

94
 _________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

4. A colleague who is a very good programmer produces software with a low number
of defects but consistently ignores organizational quality standards. How should the
managers in the organization react to this behavior?

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

5. Give an example of a system for which user training and operator training are the
same. Discuss your answer.

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

Introduction to Software Engineering | For CICT Classroom Use Only

95
 6. The user of an automated system need not be familiar with the computer concepts.
However, knowledge of computers is beneficial for most operators. In what case
should the user of an automated system be unaware of the underlying computer
system? Is the lack of awareness a sign of good system design? Give examples to
support your answer.

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

7. Explain why the structuring facilities offered by programming language such ADA
are likely to lead to more maintainable programs

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
Introduction to Software Engineering | For CICT Classroom Use Only

96
 8. Explain why maintenance programming may be more challenging than
development.

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________

Introduction to Software Engineering | For CICT Classroom Use Only

97
 BIBLIOGRAPHY

Bass, B. M. and Dunteman, G. (1963). BEHAVIOR IN GROUP AS A FUNCTION OF

SELF, INTERACTION AND TASK ORIENTATION. J. Abnorm.

Constatine, L. L. and Yourdon, E. (1979). STRUCTURED DESIGN. Englewood Cliffs NJ:

Prentice-Hall

Davis, A. M. (1993). SOFTWARE REQUIREMENTS: OBJECTS, FUNCTIONS AND

STATES. Englewood Cliffs NJ: Prentice-Hall

Fleeger, Shari Lawrence. (1992) SOFTWARE ENGINEERING “THE PRODUCT OF

QUALITY SOFTWARE” 2ND EDITION. St. Martin Publication, Munos,
Quezon City

Harker, S. D. P., et al. (1993). The change and evolution of requirements as a

challenge to the practice of software engineering.

Heninger, K. L. (1980). SPECIFYING SOFTWARE REQUIREMENTS FOR COMPLEX

SYSTEMS. NEW TECHNIQUES AND THEIR APPLICATIONS. IEEE
Trans. on Software Engineering

Kant, Krishna. (1992) INTRODUCTION TO COMPUTER SYSTEM PERFORMANCE

AND EVALUATION. McGraw-Hill Inc.

Maslows, A. A. (1954). MOTIVATION AND PERSONALITY. New York: Harper and

Row

McCue, G. M. (1978). IBM’S SANTA TERESA LABORATORY: ARCHITECTURAL

DESIGN FOR PROGRAM DEVELOPMENT. IBM Systems

Nosek, J. T. and Palvia, P. (1990). SOFTWARE MAINTENANCE MANAGEMENT:

CHANGES IN THE LAST DECADE. SOFTWARE MAINTENANCE: RESEARCH
AND PRACTICE

Nader, Jonar. (1992) PRENTICE HALL’S ILLUSTRATED DICTIONARY OF

COMPUTING. McArthur Press, Parramatta, NSW, Australia.

Preesman, Roger. (1992) SOFTWARE ENGINEERING “A PRACTITIONER’S

APPROACH” 3RD EDITION. McGraw-Hill Inc.

Sommerville, Ian. (1997) SOFTWARE ENGINEERING 5TH EDITION. Addison-Wesly

Inc.

http://www.acm.org/about/se-code

Introduction to Software Engineering | For CICT Classroom Use Only

98
 Course Syllabus

Course Number: CS 28
Course Title: Introduction to Software Engineering
Course Credit: 3 Units (5 hours per week)
Course Prerequisite: CS
Department: Computer Science Department
School: Eastern Samar State University – Salcedo Campus
Semester & School Year: 2nd Semester S.Y. 2011 – 2012
Course Description:
This course introduces more about ways how to build quality software
systems, its specification, development, management and evolution. This is
designed to provide information about capabilities, limitations and useful information
in planning, producing of good quality software that would meet engineering
standards.
Course Objectives:
This course aims to expose students to the different approaches on designing
and developing good quality software. Accordingly, they are expected to attain the
following:
1. Increase insight and awareness on the University and Department’s mission,
vision, goals and objectives.
2. Conceptualized and provide deeper understanding of the basic concepts of
software engineering.
3. Conceptualized, plan and design/build high quality system/software.
4. Develop and attain knowledge and skills on the use of different approaches
and techniques in planning a new software/system.
5. Develop values and work ethics expected in an ICT professional.
Course Policies:
1. To ensure successful completion of the course, students are expected to
arrive for class on time and to remain in class until the end of the class
session. The students are considered dropped from the class after

Introduction to Software Engineering | For CICT Classroom Use Only

99
missing 20% of the total number of hours required for the subject.
2. All students are expected to behave with academic honesty. It is not
academically honest to misrepresent another person’s work as your
own, to take credit for someone else’s words or ideas, to obtain
advanced information on confidential test materials, or to act in a
way that might harm another student’s chances for academic success.
These students will automatically have a grade of 5.0 after three (3)
offenses of academic dishonesty.
3. Assignments, Projects and Exercises should be submitted on the set deadline.
Late assignments, projects and exercises will be deducted accordingly.
4. All students are expected to take Major Exams (Mid-term/Finals) on the
specified day. In general, no make – up test or re-test will be given
except when circumstances warrant but with valid supporting
documents shall be presented.
5. Individual and group activities will be part of the class participation. Students
should participate actively or get involved in group dynamics and other
group assignments.
6. All students are expected to attend classes in the prescribed uniform.
7. Other course policies will be based on the student’s handbook.
Course Outline:

UNIT I – Introduction, Project Planning & Management

a. What is Software Engineering?
b. Software Product attributes
c. The Software Development Process
 General Models
 Roles of the development team.
d. Professional Responsibility
e. Laws of Project Management
f. The project personnel

Introduction to Software Engineering | For CICT Classroom Use Only

100
  Project Rules

UNIT II – Requirements & Specification

a. Requirements Engineering and Analysis
b. System Models
c. Requirements Definition and Specification
d. Software Prototyping

UNIT III – Software Design

a. Software Design
 The design process
 Object oriented design
b. Program Design
 Design guidelines
c. User Interface Design

UNIT IV – Verification, Validation and Testing

a. Verification and validation
b. Testing
 Defective Software
 Purpose of testing
 Stages of Testing

UNIT V – Management and Evolution

a. Managing People
b. Quality Management
c. Process Improvement
d. System Delivery
e. Software Maintenance

Course Requirement:

At the end of the course student should conceptualize and plan a system that

follows an engineering way in designing, developing and testing a software/system.

Introduction to Software Engineering | For CICT Classroom Use Only

101
 Suggested Readings:

Fleeger, Shari Lawrence. (1992) SOFTWARE ENGINEERING “THE PRODUCT

ND
OF QUALITY SOFTWARE” 2 EDITION. St. Martin Publication, Munos,
Quezon City.

Sommerville, Ian. (1997) SOFTWARE ENGINEERING 5TH EDITION. Addison- Wesly

Inc.

Preesman, Roger. (1992) SOFTWARE ENGINEERING “A PRACTITIONER’S

APPROACH” 3RD EDITION. McGraw-Hill Inc.

Kant, Krishna. (1992) INTRODUCTION TO COMPUTER SYSTEM

PERFORMANCE AND EVALUATION. McGraw-Hill Inc.

Nader, Jonar. (1992) PRENTICE HALL’S ILLUSTRATED DICTIONARY OF

COMPUTING. McArthur Press, Parramatta, NSW, Australia.

Introduction to Software Engineering | For CICT Classroom Use Only

102