OBJECTIVES
23
CHAPTER
2
Building a System
n
Characterize the size and complexity issues of a system.
n
Describe the technical issues in development and support of a system.
n
Describe the nontechnical issues of developing and supporting a system.
n
Demonstrate the concerns in the development and support activities of a
large application software, using a payroll system example.
n
Describe the coordination efforts needed for process, product, and people;
these software engineering topics are expanded in later chapters.
91998_CH02_Tsui.indd 23 1/5/13 6:57:58 AM
2.1 Characteristics of Building a System
The previous chapter focused on the environment and the conditions under which
a single program may be developed by one person for, perhaps, just a few users. We
have already seen multiple items that must be considered even when one person is
writing a single program. In this chapter we will describe the problems and concerns
associated with building a system that contains multiple components—anything from
just a few components to maybe hundreds or thousands of components. The increase
in number of components and complexity is what requires us to study and understand
the various aspects, principles, and techniques of software engineering that will be
discussed in the later chapters. This discussion introduces the rationale for software
engineering as a discipline, especially for large and complex projects that require a
team of people.
2.1.1 Size and Complexity
As software becomes ubiquitous, the development of systems involving software is
also becoming more complex. Software engineers are asked to solve both simple and
complex problems and to deal with the distinct differences between them. The complex
problems come in multiple levels of breadth and depth. The breadth issue addresses the
sheer numbers involving the following:
n
Major functions
n
Features within each functional area
n
Interfaces to other external systems
n
Simultaneous users
n
Types of data and data structures
The depth issue addresses the linkage and the relationships among items. The linkages
may either be through the sharing of data or through the transfer of control, or both.
These relationships may be hierarchical, sequential, loop, recursive, or some other form.
In developing solutions to these complex problems, software engineers must design
with possibly yet another set of relationships different from that of the problem. Figure
2.1 shows the effect of introducing both (1) the size in terms of breadth and (2) the com-
plexity in terms of depth and number of interactions. Although you can get a natural
“feel” of the difference by just viewing the diagram, it would be worth taking the time
to analyze the differences. The simple case in this figure has three major segments: (1)
start process, (2) perform three normal tasks, and (3) stop process. In Figure 2.1(b), the
number of normal tasks has increased from three to five with the addition of the “wait
for signal” and “perform task A2.” There is also a new decision task, represented by the
diamond-shaped figure in the center. The decision task has greatly increased the num-
ber of paths or choices, and thus it causes the increase of complexity. In addition, the
complexity is further exacerbated by introducing a loop relationship with the decision
task. There are many more interactions involved in a loop or repeat relationship, which
is more complex than the straight sequential relationship among the tasks portrayed in
Figure 2.1(a).
24 Chapter 2 Building a System
91998_CH02_Tsui.indd 24 1/5/13 6:57:58 AM
As shown in Figure 2.1, a relatively minor increase in the number of tasks and deci-
sions has greatly increased the complexity. As is the case for a single programming
module, when both size and complexity are magnified several times in a software system
problem, the solution to those problems also involves a comparable expansion in size
and complexity.
2.1.2 Technical Considerations of Development and Support
In the following three sections we will discuss a variety of technical issues related to
developing and supporting a system.
Problem and Design Decomposition When we move from a simple to a complex
situation of building software systems, there are some technical issues that we must
consider. The basic issue is how to handle all the pieces, parts, and relationships.
One common solution is based on the concept of divide and conquer. This has its
roots in the modularization concept first presented by Parnas (1972). Modularization
will be further discussed in Chapter 7. The natural question—how we divide a large,
complex problem and its solution into smaller parts—is more difficult than it sounds.
We first need to simplify the large, complex problem by addressing the problem in
smaller segments. After we have successfully completed that process, our next step
is to decide whether we should design and decompose the software system solution
along the dividing lines of the problem segments. Thus, if the problem description,
or the requirement, is segmented by function and feature, should we architect and
design the solution along the same function and feature segments? Alternatively,
should we choose another decomposition method for the solution, perhaps along the
Figure 2.1 Size and complexity.
Start
Wait for signal
(b) Increased Size and Complexity
Other
b
a
Signal is?
Perform task A
Perform task A2
Perform task B
Perform task C
Stop
Start
Perform task A
(a) Simple
Stop
Perform task B
Perform task C
2.1 Characteristics of Building a System
25
91998_CH02_Tsui.indd 25 1/5/13 6:57:58 AM
line of “objects”? (Further discussions on objects can be found in Chapter 7.) The key
to attacking large and complex problems is to consider some form of simplification
through the following types of activities:
n
Decomposition
n
Modularization
n
Separation
n
Incremental iterations
This notion is further expanded in Section 2.2.2, which discusses the design of a payroll
system.
Technology and Tool Considerations Aside from the important issue of decomposing
a problem and its solution, there are problems related to technology and tool consider-
ations that will also need to be addressed. If you are not writing a program alone for a
limited set of users, the choice of the specific programming language may become an
issue. A large, complex system requires more than one person to develop the software
solution. While all the developers involved may know several languages, each individual
usually comes with different experience. This diversity in background and experience
often results in personal biases for or against a certain programming language and the
choice of development tool. A common development language and development envi-
ronment needs to be picked. Beyond the programming language and the development
tools, there are further considerations of other technical choices related to the following:
n
Database
n
Network
n
Middleware
n
Other technical components such as code version control
These must be agreed upon by all parties involved in building and supporting a complex
software system.
Process and Methodology We alluded to methodology and process earlier when we
discussed the need for simplification and decomposition. When there is only a single
person developing the solution, there is still a need to understand the problem or
requirements. There is often a need to take the time to put together or design the solu-
tion and then implement it. The testing of the solution may be performed by the same
person and, possibly, with a user. Under such conditions, there is very little communica-
tion among people. No material, such as a design document, is passed from the author
to another person. There still may be a need to document the work performed because
even a single developer forgets some of the rationale behind the decisions made. There
is usually no need to coordinate the work items because there may not be that many
parts. The specific methodology used in performing any of the
tasks does not need to be coordinated when only one or two
people are involved.
In a large, complex development situation, the problem is de-
composed and is worked on by many different experts. A software
development process is needed to guide and coordinate the
Software development process The set of
tasks, the sequence and flow of these tasks,
the inputs to and the outputs from the
tasks, and the preconditions and postcondi-
tions for each of the tasks involved in the
production of a software.
26 Chapter 2 Building a System
91998_CH02_Tsui.indd 26 1/5/13 6:57:58 AM
group of people. Simple items, such as the syntax for the expression of a design, need
to be agreed upon by all the developers so that they can all review, understand, author,
and produce a consistent and cohesive design. Each method used for a specific task
along with the entire development process must be agreed to by the group of people
involved in the project. Software development and support processes were invented to
coordinate and manage complex projects involving many people. The process is greatly
facilitated when a group of people can be converted into a cooperating team of individu-
als. Although continuous improvements and new proposals are constantly being made,
no one has yet proposed the complete elimination of process or methodology. Regardless
of what is believed about software processes, it is commonly accepted that some process
must exist to help coordinate a complex and successful software project. Traditional soft-
ware process models and emerging process models, including the currently popular Agile
methods, will be discussed in Chapters 4 and 5.
Consider the simple scenario of depicting the five major tasks shown in Figure 2.2.
These are the common tasks often performed in software development and support.
Each task appears as an independent item, and each one begs the questions of what
is expected and how we perform it. For example, is there a methodology to gathering
requirements? If there is more than one person performing the requirements-gathering
task, how that task should be broken down needs to be defined. Similarly, we might ask
what constitutes user support and what problems must be fixed.
The tasks in Figure 2.2 are displayed independently. When several individuals are
involved in software development and support, there has to be a clear understanding
of the sequence, overlap, and starting conditions. For example, the designers and cod-
ers may be one group of people that is different from the requirements analysts who
are working with the customers. At what point should the designers and coders start
their tasks? How much can these tasks overlap? How should the completed code be
integrated and tested? The process definition should answer these questions and help
in coordinating the various tasks and in ensuring that they are carried out according to
previously agreed-upon methodologies.
Figure 2.3 represents one approach that employs the concept of incremental devel-
opment and continuous integration. Continuous integration has been practiced since
the 1970s, when large systems were first being built (see Tsui and Priven 1976). Recently,
because of the widespread use of incremental development and Agile methodologies,
continuous integration is gaining general popularity. The methodologies involved in
Figure 2.2 Independent tasks.
Requirements
gathering and
specification
Design
Code/unit test
Integrate and
test
User support
and problem-fix
2.1 Characteristics of Building a System
27
91998_CH02_Tsui.indd 27 1/5/13 6:57:58 AM
incremental development must all be agreed to and practiced by the entire develop-
ment team. The seemingly simple boxes depicting the test–fix–integrate cycle in Figure
2.3 is extremely deceptive. That simple cycle requires a description of a methodology
that answers the following questions:
n
Is there a separate and independent test group?
n
When a problem is found, how and to whom should it be reported?
n
How much information must accompany a problem description?
n
Who decides the severity level of a problem?
n
How is a problem-fix returned to the tester?
n
Should all problem-fixes be retested?
n
How are the problem-fixes integrated back into the code?
n
What should be done with the problems that are not fixed?
These are just some of the questions that must be determined and worked out for a
portion of the process depicted in Figure 2.3. We will expand on the specifics relating to
testing and integration methodologies and process in Chapters 10 and 11. The process
also assumes that incremental development is utilized and that both the problem and
the design can be decomposed into increments. Figure 2.3 does not include the support
and customer problem-fix activities. We must not forget that software products need
usage support, problem-fixes, and enhancements. Process plays a vital part in defining
and coordinating the activities for large, complex systems development and support.
Figure 2.3 One possible process approach.
Requirements
Architecture Design Design Design
Code Code Code Code
Test Fix Test Fix Test Fix
Requirements Requirements
. . .
. . .
. . .
. . .
Integration
28 Chapter 2 Building a System
91998_CH02_Tsui.indd 28 1/5/13 6:57:58 AM
2.1.3 Nontechnical Considerations of Development and Support
In addition to technical implications, large and complex systems also require a cogni-
zance of nontechnical issues. We will discuss two such issues here.
Effort Estimation and Schedule For a small and fairly simple software project that
involves a team of one to three people, the effort estimation and scheduling of the
project is relatively easy. Both the functional and nonfunctional requirements of the
project are fewer in number and complexity. Even then, as you have seen in Chapter 1,
it is still not a trivial task. For complex and large systems, capturing and understanding
the requirements alone can be overwhelming. Estimating the total effort and coming up
with a reliable project schedule under this difficult condition is one of the main reasons
behind so many software project failures; see Jorgensen (2004) for more details. The
inaccurate effort estimates and schedules for large, complex systems are often extremely
optimistic and aggressive; this places unrealistic expectations on both the customers and
the suppliers of these systems.
As an example, consider a relatively simple software project that requires three major
functions with a total of 12 features. The effort estimation of this project requires a good
understanding of all the functional features and the productivity of the individuals in
the small team who will be working on these 12 features. For a large, complex software
system, the number of major functions is often in the tens or hundreds. The total number
of features within these major functions may easily be in the hundreds and thousands.
The number of people needed to develop such a system may easily be in the hundreds.
Under such circumstances, the probability of understanding all the requirements well
and of knowing the productivity of all the individuals accurately is very low. The sort-
ing of the number of combinations of individuals assigned to the design and coding
of such a large number of features alone can be a daunting task. The resulting effort
estimation and the schedule is often a good “guess” and far from being accurate. The
software industry has long recognized this problem and has been confronting this issue.
In Chapter 13 we will address some of the techniques that have been developed and are
now available.
Assignments and Communications We touched on the problem of assigning people
to designing and coding the different functional features when the number of features
increases and the corresponding number of developers increases. Furthermore, there
are other activities that require people resources. The assignment of different people to
different tasks such as testing, integration, or tool support requires more understand-
ing of the skills of the people involved and the specific tasks they have to perform. The
assignment of the most effective and properly skilled people to the right tasks requires a
deeper level of granularity and a finer level of scheduling.
Another related problem with the increase in personnel is the problem of communica-
tions. For a small project involving two or three people, the number of communications
paths is one between two people and three among three people. Figure 2.4 illustrates
how maximum communication paths increase as the number of participants increases.
2.1 Characteristics of Building a System
29
91998_CH02_Tsui.indd 29 1/5/13 6:57:58 AM
The nodes in this figure represent the people, and the lines represent the communica-
tion paths. The number of possible communications paths more than doubled when the
number of team members increased from four to six.
In general, the number of communication paths for
n people is SUM(n–1), where SUM is
the arithmetic sum function of
1, 2, . . . , n. Thus a modest increase from a 4-person team
to a 12-person team would increase the potential number of communication paths from
6 to 66. A tripling of a small team would increase the potential communication paths by
more than ten times!
Associated with this increase in the sheer number of communication paths is the
chance of an error in communications. Consider, for example, that the chance of com-
municating correctly a particular message between any two people is 2/3. The prob-
ability that we will communicate properly from one person to another and then from
that second person to a third person would be (2/3 3 2/3) = 4/9. In general, for n people
where n is 2 or more, the probability of correctly communicating this message would be
(2/3)
n21
. Thus for this message, there is only a 16/81 chance of correctly passing it from
the first person to the fifth person in the team. Suddenly, we have reduced a 2/3 chance
of correctly communicating a message to less than 1/4. Such a low probability of correct
communication among team members may be a serious problem, especially if the mes-
sage is critical. Organizational structures of people need to be put in place to reduce the
complexity and increase the chance of correct communications.
2.2 Building a Hypothetical System
In this section we will use a hypothetical payroll system to illustrate some of the prob-
lems introduced in Section 2.1. The discussion here will cover the major tasks of develop-
ing such a system and of supporting the system once it is released to users. The intent
of this section is to provide only a glimpse of the different problems and concerns that
arise in building our system but not to delve into all the details of constructing and sup-
porting this system.
2.2.1 Requirements of the Payroll System
Everyone has some idea of what a payroll system is. Take a moment to think about what
you would consider as the major functional and the nonfunctional requirements of a
Figure 2.4 Maximizing communication paths.
1 path 6 paths 15 paths
30 Chapter 2 Building a System
91998_CH02_Tsui.indd 30 1/5/13 6:57:59 AM
payroll system. The following functional capabilities represent only some of the tasks a
payroll system should be able to perform. This list is far short of what a real payroll system
would need.
n
Add, modify, and delete the names and associated personal information of all employ-
ees.
n
Add, modify, and delete all the benefits associated with all employees.
n
Add, modify, and delete all the tax and other deductions associated with all employ-
ees.
n
Add, modify, and delete all the gross income associated with all employees.
n
Add, modify, and delete all the algorithms related to computing the net pay for each
employee.
n
Generate a paper check or an electronic direct bank deposit for each employee.
Each of these functional requirements may be expanded to several levels of more
details. For example, just for the first item of names and associated personal information,
one would need to understand what the associated information is. This is a simple ques-
tion, but would require the software engineer to solicit the input for this. Where and who
would the software engineer ask? Should the software engineer ask the users, some desig-
nated official requirements person, or the project leader? Once the question is answered,
should the answer be documented? The next functional requirement in the preceding list
speaks to all the benefits. What are all the benefits? What does having a benefit mean to an
employee’s payroll? Is there a list of all possible benefits? It does not take much to realize
that the requirements solicitation, gathering, documentation, analysis, and validation of a
payroll system will need a considerable effort. In order to properly handle the application
side of the payroll system requirement, we may need to understand something about
benefits, tax laws, and other domain-specific knowledge.
In addition, the payroll system must be able to generate the paychecks and direct
deposits several times a month. What is the allowable payroll cycle? In other words, if
the checks and deposits must be completed by the middle and end of the month, when
must the inputs to the cycle, such as salary increase, be closed? Here we are interested in
understanding the payroll-processing-cycle window that is allowable within the business
environment and what performance capability the system must have to satisfy that pro-
cessing window. The answer to this question will require the software engineer to know
the volume of payroll transactions and the speed of processing each payroll transaction.
To analyze and handle this type of requirement, we may need to know the hardware and
operating system environment capability on top of which the payroll system will be run-
ning. Some of the payroll system requirements will require, in addition to payroll domain
knowledge, the knowledge of technical system and interface information.
There also needs to be an understanding of how the actual payroll run process works
at the user/customer site. For example, if there is a bad record, how should that person’s
paycheck be reprocessed? Does this imply that there is a requirement to rerun the pay-
roll system several times? There may also be some requirements that the users/custom-
ers may not even remember to provide. In Chapter 6 we discuss how we may handle
these late requirements.
Once the requirements information of a payroll system is documented, the complex-
ity of such a system will most likely necessitate a review with the users/customers prior to
2.2 Building a Hypothetical System
31
91998_CH02_Tsui.indd 31 1/5/13 6:57:59 AM
having the requirements specification passed forward to the design and coding phase.
These reviews may be conducted gradually as the requirements are incrementally ana-
lyzed and documented or all at once when all the requirements are analyzed and speci-
fied together. Either situation will require a coordination of effort between the users/
customers and the requirements analysts.
It is thus clear that the total number of activities needed to complete a payroll sys-
tem requirement phase alone may be extremely high as well as time consuming. Not
just a single requirements analyst but a team of requirements analysts—individuals
having diverse skills spanning everything from payroll domain-specific knowledge to
IT and systems development expertise—may be needed. From a quality perspective, it
has also been pointed out by Jones (1992) that approximately 15% of software defects
are due to requirements errors. The activities related to completing a requirements
specification for a system, such as that in our payroll example, are difficult and have
significant impact on all downstream activities and on the final product. Complete
books have been written on just this single topic. (See the Suggested Readings section
at the end of this chapter.)
2.2.2 Designing the Payroll System
Once the requirements of the payroll system are understood and agreed to, the system
must still be designed. Put aside the fact that the payroll system requirements expressed
in Section 2.2.1 are just an example and are incomplete. For example, we might natu-
rally ask whether all the “add, update, and delete” functional requirements should be
grouped together into a single component called “payroll administrative functions.” We
might then ask if all the processing functions such as the calculations of all the deduc-
tions and the net pay amount should be grouped together into a component called
“payroll processing.” Certainly, we must be prepared to handle errors and exceptions.
So, those functions dealing with errors and exceptions processing may be aggregated
into an exceptions-processing component. In addition, the payroll system must interface
with external systems such as direct bank deposits or batch transmissions to remote sites
for local check printing. We may decide to place all the interface functions into a compo-
nent called “payroll interfaces.” This grouping of related functions into components has
several advantages:
n
Provides some design cohesiveness within the component
n
Matches the business flow and the payroll processing environment
n
Provides a potential assignment of work by components
n
Allows easier packaging of the software by components
There may be some drawbacks to this approach. It is conceivable that there are still heavy
interactions or coupling among these components. The coupling, in this case, may arise
from extensive usage of a common data file or a common table in a relational database.
Even at this high level, designers need to look at both the characteristics of design cohe-
siveness and coupling. The concepts related to these topics are discussed extensively in
Chapter 8.
There are also nonfunctional specific, but common-service, needs that must be
designed. For example, the help service or the message service must be designed for
32 Chapter 2 Building a System
91998_CH02_Tsui.indd 32 1/5/13 6:57:59 AM
all the functional components. These services may all be placed in one component
called the services component. The combination of functional components and common
services is shown in Figure 2.5 as horizontal and vertical design entities. The horizontal
entities are the common service functions such as the error handler that crosses all the
individual application features. The vertical entities are the different application domain-
specific functions such as the tax and benefits deduction function in a payroll system.
The interaction, or coupling, of the various functional components with these common
services is a key design concern.
It is during design that the screen interface layout is finalized. In the case of a payroll
system, this is a heavily batch-oriented system rather than an interactive system. User
interface in terms of screen architecture is thus not a prime design concern. Nevertheless,
it needs to be addressed. The database tables and search keys, however, are important
and would be a significant design concern for a large batch-processing application.
Although there are many ways to perform high-level and detailed design, the design
of a payroll system requires a broad set of skills because of the breadth and depth of
the system. From the breadth perspective, the design skills needed require complex
knowledge: database, network, and transmission interfaces; printing interfaces; oper-
ating system interfaces; development tools environment; and the payroll application
domain. From a depth perspective, the designer needs to understand and appreciate
the specifics of a payroll system, such as performance and error processing. Although it
is a batch-processing system, the sheer volume of payroll records for large enterprises
often requires special design concerns that would make the seemingly simple process of
error handling into a complex task. The design must not only catch erroneous informa-
tion or conflicting information but must also consider what should happen to the people
whose records cannot be processed. If these records are not dealt with immediately and
allowed to accumulate until the end of the payroll cycle, there is no time to react. These
records must be handled so that they can be converted to a paycheck within the payroll
Figure 2.5 Vertical and horizontal design entities.
Different vertical functions
Common messages
Common screens
Horizontal
functions
2.2 Building a Hypothetical System
33
91998_CH02_Tsui.indd 33 1/5/13 6:57:59 AM
processing cycle. The designer must consider the payroll environment and the possibility
of having to hand code the paychecks for a small number of unfortunate people. Thus
the designer must design the system to include hand-processing exits from the system
and the reconciliation of these hand-processed records back into the automated payroll
system. The depth of error processing in a large system such as payroll can be a challenge
for even the most experienced designers.
The payroll design mentioned here utilizes functional decomposition and synthesis
techniques within each of the components. In addition to the intercomponent interac-
tions, the various pieces within a component must be clearly divided and the intrac-
omponent interaction between the pieces must also be designed. Clearly, designing a
complex system is quite different from designing a single programming module and will
require greater discipline and additional guiding principles as well as the possibility of
several more team members.
2.2.3 Code and Unit Testing the Payroll System
The high-level design or architecture for the payroll system needs to be further refined
and converted into running code. Within each design component, the individual, inter-
acting, functional unit needs to be designed and converted into code. This activity is
familiar to most people who enter the IT and computing field. The first course often
taught to students entering software engineering or computer science involves a small
problem that must be solved with a detailed functional design and code. At times, when
the solution is small enough, the detail design is not even recorded and only the source
code of the module is available.
For each of the functional units, the programmer must address and develop the fol-
lowing material:
n
Precise layout of the screen interface in some language
n
Precise functional processing logic in some programming language
n
Precise data access and storage logic in some language
n
Precise interface logic in some language
Furthermore, if there are many of these programming units, some common stan-
dards must be set. An example would be a naming convention for each of the modules
that would uniquely identify each as the module of a specific component. Conventions
may also need to be set for different database records such that all elements from a
specific relational table have the same prefix. There may be conventions set to docu-
ment some of the detail design such as providing comments on the conditions under
which this module may be entered and exited. The comments may also describe the
data that are vital to the processing and a short description of the intended function.
A very important part is the design, code, and the documentation of how to handle
the various error conditions. The error messages displayed from the different program
modules need to be consistent; thus each program unit must follow the error message
standard.
After the program module has been completed, the individual who performed the
task should test the module to confirm that it performs the intended tasks. The first step
in this unit-testing task is to set the conditions of the module and to choose the appropri-
34 Chapter 2 Building a System
91998_CH02_Tsui.indd 34 1/5/13 6:57:59 AM
ate input data. The next step is to execute or run the module and observe the behavior
of the module, mainly through checking the output from the module, to ensure that it is
performing what it is intended to do. Finally, if there is any problem discovered through
unit testing, it must be fixed and retested. When all the problems are fixed, the module
is ready for integration into a larger unit such as a functional unit or into a component if
the module itself is a functional unit.
The programming or coding and unit testing of a module is usually performed by
one individual. For a large system, such as a payroll system, there may be hundreds of
modules that need to be coded and unit tested. Thus, programming is a heavily human
resource intensive activity. When the number of programmers increases to a large figure,
then the coordination and integration of all the programming efforts become a manage-
ment challenge. Once again, principles of software engineering management need to be
brought in to alleviate the situation.
2.2.4 Integration and Functionally Testing the Payroll System
As the modules are completed and unit tested, they have to be formally collected from
the individual programmers. The collection activity is known as integration, which is a
part of a larger control mechanism known as configuration management. Configuration
management will be mentioned throughout this text but will be formally discussed in
Chapter 11. A simple reason for the integration step is that if the completed modules
are left with the individual programmers, the programmers tend to make changes to an
already unit-tested module and get confused about which is indeed the latest version.
To ensure that the latest unit-tested modules do work together as a functional unit, these
modules need to be compiled and linked together. A functional unit, in the case of the
payroll system, may be a part of the previously mentioned administrative component
that performs the add, modify, and delete functions of all the federal deduction laws,
which almost always change annually. The integrated set of modules is then tested with
functional test cases generated by a more objective group than the programmers who
coded the modules.
Functional testing usually uncovers some problems that will require fixing by the
programmers. The cycle of problem detection to problem-fix needs to be coordinated
between the testers and the code fixers. The fix code must be integrated into the func-
tional unit and be retested to ensure that all the fixes as a group have not impacted each
other negatively. As a set of modules in a functional unit completes the functional test,
it is electronically labeled as such and is locked from further changes. These functional
units need to be managed by the configuration management mechanism as do the mod-
ule units. In the case of a simple one or two module situation, there is not much need
for an integration and configuration management mechanism. In a very large software
system construction such as a payroll system, there is usually a tool, such as PVCS from
Serena Software, used to help automate the configuration management mechanism.
The people and skills required to tackle the integration and functional testing of a payroll
system are usually different from those needed for coding, designing, or requirements
gathering. However, test scenarios and test scripts often require the knowledge of the
requirements and the design.
2.2 Building a Hypothetical System
35
91998_CH02_Tsui.indd 35 1/5/13 6:57:59 AM
2.2.5 Release of the Payroll System
After the functional units are tested and integrated into components, these components
must be tested together to ensure that the complete system works as a whole. This is
important to ensure that all the interfaces across components actually do work. Also, the
various fixes for the functional units and components may impact some other previously
working functional units and components. Even after the entire payroll system is tested
through all the user scenarios in the context of the user business environment, the sys-
tem cannot be released unless no problem was found. At least all the major problems
and showstoppers must be fixed before the system can be considered releasable to
the users. Once again, the tested payroll system must be managed and protected from
further changes.
Even if the payroll system is totally error free, the users must still be educated in the
usage of the system—a process that for a large system cannot be an afterthought and
must be planned and orchestrated. The development of the educational material alone
for such a system is a nontrivial task. The effort may take several people and several
months. The delivery of user education may require some different skills from technical
design or coding. The emphasis would be presentation and communication skills. The
people who develop the educational material content may be different from those who
deliver the education.
Another area of preparation prior to releasing the payroll system would be the prepa-
ration of user support personnel. It would be rare that the users can master all the details
of a payroll system just through education. Furthermore, it is also rare that a large and
complex system will be totally error free. The support personnel themselves must be
preeducated on the payroll system, user environments, and tools needed for supporting
customers.
Once the system test is complete, the users have been trained, and the support group
is trained and established, the payroll system is then ready for release to the users. Who
should be the person that makes the final call of a product release? Should this be a
group decision? And what criteria should that person use in making the determination
for release? These topics fall under the umbrella of software project management, dis-
cussed further in Chapter 13.
2.2.6 Support and Maintenance
For a small, one- or two-module software product that is utilized by a few people, the
support effort is not a major concern. For a large system such as a payroll, the postrelease
support of the users and customers may be a very complex set of tasks. Who does the
user call for help, after consulting the user manual, when the payroll system stalls and
pops up a message with several possible choices for the user before the payroll system
can continue processing? Who does the user call when the direct deposit interface on
the bank side has changed and the existing payroll system interface needs to be modi-
fied? Who does the user call when the payroll system shows a different behavioral prob-
lem after applying a previous problem-fix? These are just a few of the many questions
that will arise after the payroll system is released. Several assumptions must be made and
36 Chapter 2 Building a System
91998_CH02_Tsui.indd 36 1/5/13 6:57:59 AM
be included in the calculation of the expected payroll system support effort. Many of the
following decision factors will play a role:
n
Number of expected users and customers
n
Number and type of known problems that existed at release time
n
Projected number of problems that will be discovered by users
n
Amount of user training
n
Amount of support personnel training
n
Number of development personnel committed to support the system
n
Expected number of problem-fix releases and future functional releases
Based on these factors, the number of postrelease people required to support and
maintain the payroll system must be estimated and allocated. Clearly distinct skills will
be needed to support such a complex environment, and it will be necessary to consider
at least two sets of support personnel:
n
A group to answer and handle system usage and simple problem work-arounds
n
A group to fix difficult problems and implement future enhancements
The first group does not have to include any program coding personnel. They must,
however, possess good communication skills as well as payroll system and usage knowl-
edge. The second group often needs to include designers and coders. If there is an
expected long product life for the payroll system, then the support personnel must be
prepared for several releases of functional enhancements. The support personnel in this
group may thus resemble a complete development team. The important concept here
is that large, complex systems such as a payroll system will require a support organiza-
tion that may be comparable in size and complexity to the original development team.
Chapter 12 will cover the postrelease support and maintenance subject in more detail.
2.3 Coordination Efforts
The payroll example demonstrates the need for many of the software engineering activi-
ties. A critical concern for large, complex systems is the upward scaling of the needed
process, of the design structure and contents of the product, and of the required person-
nel. In the opposite direction is the concern of downward scaling of the same parameters
for simpler systems. In this section we will introduce these concerns and discuss the
details of process, product design, and personnel management in later chapters.
2.3.1 Process
We have already discussed the notion of a process. As both applications and systems
software became large and complex in the 1980s and 1990s, the number of serious and
costly problems skyrocketed. Often in the past, more and more hurdles—usually in the
form of more reviews, more inspections, more testing, and more meetings—have been
inserted as a part of the process. Large corporations signed up for expensive quality
assurance and measurement efforts. These efforts were designed to prevent, detect,
and correct problems, thereby improving the quality of software and increasing the
productivity of the software developers. Extensive metric programs were put in place to
2.3 Coordination Efforts
37
91998_CH02_Tsui.indd 37 1/5/13 6:57:59 AM
measure quality and productivity; see the article on the Motorola measurement program
by Daskalantonakis (1992). The development and support processes became heavily
weighted toward risk aversion. In recent years there has been a movement to simplify
the process as speed and cost started to take center stage in the software industry (Beck
1999; Cockburn 2001). There is no single process that fits all occasions. Some are more
appropriate for large, complex systems that require extensive coordination, and others
are much simpler and are appropriate for small and quick software projects. We will
cover the topic of software processes in detail in Chapters 4 and 5.
2.3.2 Product
A software product is often thought of as only containing the executable code. However,
in developing and supporting software, many more artifacts have to be produced, rang-
ing from requirements documents to functional test scenarios. Many sophisticated users
and customers require user manuals, user education, and product support as part of the
product. Simply delivering a package of executable code is not enough in many cases.
The payroll system considered in this chapter is an example of a system where the
customers and users will be demanding much more than just the executable code.
Besides the artifacts required in developing the final product, they may ask for the design
document and the source code so that future modifications may be carried out by their
own personnel. Of course, once the product source code is modified by the users and
customers, that portion of the product will have to be maintained and supported by the
users and customers themselves. The software product, large or small, which is expected
to have a long life span, will need to be designed for changes and easy maintenance.
The coordination of the software components and artifacts through a long and lengthy
period of changes, updates, and maintenance is a complex endeavor. A large software
product may initially be designed to be high in functional cohesiveness within each part
and minimal in interactions or coupling among the parts. It is very difficult to maintain
a high degree of internal cohesion and a low amount of coupling as the large software
product evolves through many cycles of modifications. A software product needs to be
protected from design drift and erosion (Taylor, Medvidovic, and Dashofy 2009). The
design of the software product and the notion of cohesion and coupling will be further
covered in Chapters 7 and 8.
As both the design and product increase in complexity, so do the testing efforts. The
coordination of test preparation, testing, fixing, and integration are covered more exten-
sively in Chapters 9, 10, and 11.
2.3.3 People
As the payroll system example has already demonstrated, for a large software system
we need a team of people with an assortment of skills and experience to develop and
support the system. The human element is a crucial component in the development and
support of software. In many ways, the software industry is still labor intensive. Thus the
study of software engineering must include the issues of coordinating people’s activities
and management skills.
Part of the discussion on coordinating software engineers’ activities is embedded in
the process discussion. A large and vital part of coordinating software personnel lies in
the organizational structure and the strength of communications among the various
38 Chapter 2 Building a System
91998_CH02_Tsui.indd 38 1/5/13 6:57:59 AM
constituencies. Chapter 13 will cover some people-management issues as they relate to
different phases of a software project.
2.4 Summary
In this chapter, we have described the growth in the breadth and depth of complex soft-
ware problems and the associated software solutions. Both the technical and nontech-
nical issues—from design decomposition and communications to process, tools, and
methodology—were introduced. A typical payroll system in a large business was used as
the basis for introducing and demonstrating the real problems in large software devel-
opment and in supporting such products. Large software projects require the control of
the process, the product, and the people involved. The field of software engineering is
vital to the development and support of these large and complex systems.
2.5 Review Questions
1. Define the depth versus the breadth issue in software complexity.
2. Describe a way to simplify a complex problem.
3. List two technical concerns in developing large systems.
4. What is the maximum number of communication paths for a team of 20 people?
5. List four factors that should be considered in deciding how many postrelease
people will be needed.
2.6 Exercises
1. (a) Give an example of an increase in software size. (b) Give an example of an
increase in complexity. (c) Discuss which type of increase, in your view, is more
difficult to handle.
2. Discuss the difference between vertical and horizontal functions and the potential
interactions between the two sets.
3. What is meant by integration and why is it important to manage this effort for
large systems?
4. What are the major tasks in developing and supporting a software system?
5. (a) Write a program that reads 11 numbers, divides the sum of the first 10 num-
bers by the 11th number, and displays the result. (b) List all the questions you
had in the process of programming part (a) of this question. (c) Discuss, in your
view, what type of skills are needed to collect and specify the requirements of a
system.
6. Discuss the three areas that need to be coordinated in a large software engineer-
ing project. Is any one of them more important than the others? Explain your
conclusion.
2.6 Exercises
39
91998_CH02_Tsui.indd 39 1/5/13 6:57:59 AM
2.7 Suggested Readings
K. Beck, Extreme Programming Explained: Embrace Change (Reading, MA: Addison-Wesley,
1999).
A. Cockburn, Agile Software Development (Reading, MA: Addison- Wesley, 2001).
M. K. Daskalantonakis, “A Practical View of Software Measurement and Implementation
Experiences within Motorola,” IEEE Transactions on Software Engineering 18, no. 11 (No-
vember 1992): 998–1010.
T. Gilb and D. Graham, Software Inspection (Reading, MA: Addison-Wes ley, 1993).
C. Jones, Critical Problems in Software Measurement, Version 1.0 (Burlington, MA: Software
Productivity Research, Inc., 1992).
M. Jorgensen, “Realism in Assessment of Effort Estimation Uncertainties: It Matters How
You Ask,” IEEE Transactions on Software Engineering 30, no. 4 (April 2004): 209–217.
D. Leffingwell and D. Widrig, Managing Software Requirements: A Use Case Approach, 2nd
ed. (Reading, MA: Addison-Wesley, 2003).
L. Maciaszek, Requirements Analysis and System Design, 2nd ed. (Reading, MA: Addison-
Wesley, 2004).
D. Parnas, “On Criteria to Be Used in Decomposing Systems into Modules,” Communica-
tions of the ACM 15, no. 12 (December 1972): 1053–1058.
Serena Software Inc., www.serena.com.
R. N. Taylor, N. Medvidovic, and E. M. Dashofy, Software Architecture: Foundations, Theory,
and Practice (Hoboken, NJ: John Wiley & Sons, 2009).
F. Tsui and L. Priven, “Implementation of Quality Control in Software Development,” AFIPS
Conference Proceedings (1976), 443–449.
40 Chapter 2 Building a System
91998_CH02_Tsui.indd 40 1/5/13 6:57:59 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.