See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/232623363

A Practitioner's Approach to Software System Design

Article · December 2010

DOI: 10.1109/ISED.2010.13

CITATIONS READS
0 9,321

1 author:

Debajyoti Mukhopadhyay
Bennett University
275 PUBLICATIONS 2,057 CITATIONS

SEE PROFILE

All content following this page was uploaded by Debajyoti Mukhopadhyay on 31 July 2014.

The user has requested enhancement of the downloaded file.

 2010 International Symposium on Electronic System Design

Plenary Talk - 5
A Practitioner’s Approach to Software System Design

Debajyoti Mukhopadhyay
Web Intelligence & Distributed Computing Research Lab
Calcutta Business School, D.H. Road, Bishnupur 743503, India
[email protected]


Abstract: How to design an efficient and cost effective software software engineers is to produce high-quality software with a
system is a million dollar question to every software engineer. The finite amount of resources and to a predicted schedule.
challenges lie in the fact that there is no such fixed rules and
regulations, following which will produce an efficient software The attributes of a software product are the characteristics
system. Practitioners have proposed many solutions to address this
displayed by the product once it is installed and put into use.
issue. In this discussion, we will try to touch base on some of the
vital points which a practitioner is encouraged to adapt in order to
These are not the services provided by the product. Rather,
lead a team of software engineers to produce cost effective efficient they are concerned with the product’s dynamic behavior and
system. the use made of the product. Examples of these attributes are
therefore maintainability, dependability, efficiency, usability,
Keywords: Software Development Life Cycle, SRS and so on.
document, Cohesion, Coupling, , Re-usability.
Maintainability: It should be possible to evolve software to
1. Introduction meet the changing needs of customers.

The job of a software engineer is to find best way of Dependability: Software dependability includes a range of
producing software product. We will try to find out what are characteristics including reliability, security and safety.
the best practices in order to achieve that goal. It is important Dependable software should not cause physical or economic
to understand what is meant by software product. Software damage in the event of system failure.
products fall into two broad classes: A) Generic Products:
These are stand-alone systems which are produced by a Efficiency: Software should not make wasteful use of system
development organization and sold on the open market to any resources such as memory and processor cycles.
customer who is able to buy them. B) Bespoke (customized)
Products: These are systems which are commissioned by a Usability: Software should have an appropriate user interface
particular customer. The software is developed specially for and adequate documentation.[1][2][3][4]
that customer by some contractor.
3. The Software Process
The procedures of software development and the software
engineering methods which may be used are the same for The software process is the set of activities and associated
software products and bespoke systems. The most significant results which produce a software product. These activities are
difference is that generic product specifications are produced mostly carried out by software engineers. Computer Aided
internally by the marketing department of the product Software Engineering tools (CASE tools for short) may be
company. They reflect what they think will sell. They are used to help with some process activities.[5]
usually flexible and non-prescriptive. By contrast,
specifications for bespoke systems are often the basis for the There are four fundamental process activities which are
contract between customer and contractor. They are usually common to all software processes. The activities are:
defined in detail and changes have to be negotiated and
carefully estimated in terms of cost. 1. Software Specification: The functionality of the software
and constraints on its operation must be defined.
2. Software Product Attributes 2. Software Development: The software to meet the
specification must be produced.
Like all engineering, software engineering is not just about 3. Software Validation: The software must be validated to
producing products but involves producing products in a cost- ensure that it does what the customer wants.
effective way. Given unlimited resources, the majority of 4. Software Evolution: The software must evolve to meet
software problems can probably be solved. The challenge for changing customer needs.

978-0-7695-4294-2/10 $26.00 © 2010 IEEE 20

DOI 10.1109/ISED.2010.13
There is no such thing as a “right” or a “wrong” software encountered. This information is used during the next phase.
process. Different software processes decompose these Phase reports are also used to keep management informed of
activities in different ways. The timing of the activities varies project progress, so that management can use the reports to
as does results of each activity. Different organizations use change project direction and to allocate resources to the
different processes. However, some processes are more project.
suitable than others for some types of application. If the
wrong process is used, this will probably reduce the quality or Linear cycle phases are chosen to encourage top-down
the usefulness of the software product to be developed. problem solving. Designers must first precisely define the
problem to be solved and then use an ordered set of steps to
Detailed software process models are still the subject of reach a solution. The linear cycle gives the project direction
research but it is now clear that there are a number of different and guidance about what should be done as the project
general models or paradigms of Software Development Life proceeds. The system life cycle also assists management by
Cycle: producing reports on project status and keeping track of
resource needs.
1. Linear Cycle or The Waterfall Model: This takes the
above activities and represents them as separate process The top-down approach implies that both the problem to be
phases such as requirements specification, software solved and the solution are elaborated in more detail as the
design, implementation, testing and so on. After each project proceeds. Thus the linear cycle begins with a broad
stage is defined it is “signed-off” and development goes definition of requirements and continues by developing the
on to the following stage. solution in greater detail. The first step in such detailed
2. Evolutionary Development: This approach interleaves development is to determine the feasibility of providing a
the activities of specification, development and workable solution. If a solution is deemed feasible, then a
validation. An initial system is rapidly developed from detailed analysis of the system is made in order to produce
very abstract specifications. This is then refined with both a description of the system and an expansion of user
customer input to produce a system which satisfies the requirements of the new system. Analysis is followed by
customer’s needs. The system may then be delivered. system design and implementation. These linear cycles
Alternatively, it may be re-implemented using a more phases are described below in detail.
structured approach to produce a more robust and
maintainable system. It is also important to take precautions to ensure that all user
3. Formal Transformation: This approach is based on requirements are satisfied at the completion of the project, that
producing a formal mathematical system specification and is, that the necessary quality assurance mechanisms are in the
transforming this specification, using mathematical process. It includes validation of outputs at the different steps
methods, to a program. These transformations are against user requirements. Validation takes place at the
“correctness-preserving.” This means that one can be conclusion of the feasibility study, systems analysis and
sure that the developed program meets its specification. design phases and then finally following implementation.
4. System Assembly from Reusable Components: This Verification takes place continuously through the process,
technique assumes that parts of the system already exist. with the outputs at one phase verified against the inputs from
The system development process focuses on integrating the previous phase. Finally, any designed software modules
these parts rather than developing them from scratch. must be thoroughly tested during development.

The first two of these approaches, namely the waterfall 3.2 Phases in Waterfall Model
approach and evolutionary development, are now widely used
for practical systems development. Some systems have been 3.2.1 Phase 1 – Problem Definition
built using correctness-preserving transformations but this is
still an experimental process. Many people consider problem definition to be the most
important phase. It defines the user requirements, or what the
3.1 The Waterfall Model user expects the system to do, and thus sets the direction for
the whole project. This phase also sets the project bounds,
The waterfall model or the linear cycle has been widely used which define what parts of the system can be changed by the
in the design of systems that can be easily understood and project what parts are to remain the same. The resources to be
which have well-defined workflows. It is a process that made available to the project are also specified in this phase.
specifies a sequence of steps to be followed by designers. The These three important factors: the project goal, project
linear cycle groups system development activities into a bounds and resource limits – are sometimes called the
sequence of consecutive phases. A phase in the sequence can project’s terms of reference. Because of their importance,
only commence once the previous phase has been completed. they are set by the organization’s management.
A report is produced at the end of each phase, describing what
has been achieved and outlining the plan for the next phase. The output of this phase defines the user requirements. It
The report also includes any system descriptions, new or consists of the project goal, its bounds and the terms of
expanded user requirements, design decisions and problems reference for the project. Furthermore, it may include any

21
restrictions on the project, such as the parts of the existing the new system. Analysts use many of the commonly used
system which cannot be changed, as well as those which can. systems analysis techniques, such as data flow diagrams and
data analysis. They also follow specified procedures in their
Resource limitations are also often specified at this time to search for information about the system. This calls for
indicate the funds and personnel available for the project. interviews with system users, questionnaires and other data-
This will include a rough idea of the resource requirements of gathering methods. Analysts must spend considerable time
each of the subsequent project phases. It will contain tentative examining components, such as the various forms used in the
start and completion dates for each phase and the number of system, as well as the operation of existing computer systems.
persons expected to be involved in each phase.
This phase results in a detailed model of the system. The
3.2.2 Phase 2 – Feasibility Study model describes the system functions, system data and system
information flows. The phase report contains any revisions to
The feasibility study proposes one or more conceptual project goals and cost-benefit estimates. It also contains a
solutions to the problem set for the project. The conceptual more detailed exposition of system problems than that given
solutions give an idea of what the new system will look like. in Phase 1. This exposition usually includes a detailed
They define what will be done on the computer and what will specification of user requirements. Such requirements are
remain manual. They also indicate what input will be needed used to set the objectives for the new system. Part of the
by the systems and what outputs will be produced. These management review of this phase is to reach an agreement on
solutions must be proven feasible and a preferred solution such objectives. Once agreement is reached, design can
must be accepted. commence. The output is validated against requirements and
the existing system. Validation in this case often incorporates
Three things must be done to establish feasibility. First, it is the ideas of structured walkthroughs.
necessary to check that the project is technically feasible.
Does the organization have the technology and skills 3.2.4 Phase 4 – System Design
necessary to carry out the project and, if not, how should the
required technology and skills be obtained? Second, This phase produces a design for the new system. There are
operational feasibility must be established. To do this it is many things to be done here. Designers must select the
necessary to consult the system users to see if the proposed equipment needed to implement the system. They must
solution satisfies user objectives and can be fitted into current specify new programs or changes to existing programs, as
system operation. Third, project economic feasibility needs to well as a new database or changes to existing database.
be checked. The study must determine whether the project’s Designers must also produce detailed procedures that describe
goal can be achieved within the resource limits allocated to it. how users will use the system.
It must also determine whether it is worthwhile to proceed
with the project at all, or whether the benefits obtained from System design usually proceeds in two steps: broad design
the new system are not worth the costs (in which case, the (Phase 4A) and detailed design (Phase 4B).
project will be terminated).
3.2.4.1 Phase 4A – Broad Design
Many beginners in systems analysis find the idea of a
conceptual solution hard to understand. All that is needed at During this phase, the conceptual solutions proposed by the
this stage is a very broad idea of the solution, enough to give feasibility study are looked at in more detail. Major new
potential users an estimate of whether it can work and how functions are proposed and changes to existing functions
much it is likely to cost. It is usually a good idea to consider a defined. Important inputs and outputs are also defined at this
number of possible solutions at this stage. point and performance requirements are specified. In
addition, broad design outlines which part of the system is to
One output of a feasibility study is a preferred conceptual be automated and which will remain manual. Thus, in our
solution together with the expected system costs and benefits. case, we may still consider such decisions as whether to place
It also includes a more detailed specification of what is needed the actual ordering on the computer or to have manual
of the new system. The plan in Phase 1 is now expanded to ordering and only use the computer for dissemination of data.
show the resource requirements for each phase. The phase Alternative automation boundaries may therefore be
output is validated against the user requirements. considered and their costs evaluated in this phase.

3.2.3 Phase 3 – Systems Analysis At the conclusion of broad design we may know what we
need in order to build the system. This may include the size
This phase is a detailed appraisal of the existing system and of the computer and the software needed to put the system
included finding out how the system works what it does. It together. It will also state which software can be purchased
also includes finding out in more detail what the system off-the-shelf and which requires new programs to be
problems are and what users require of any new or changed developed. The design may also suggest whether the
system. Following this phase, analysts should be familiar with computer should be rented or purchased and whether
the detailed operation of the system and what is required of

22
 programs are to be developed using internal programmers or in nature and can be re-used as much as possible instead of in
external contractors. re-inventing the wheel thus saving time and cost.

The broad design identifies the main architecture of the References

proposed system. This architecture is verified against the [1] Pressman, Roger S., “Software Engineering: A
proposed system model and validated against user Practitioner’s Approach”, Tata McGraw-Hill, Fifth
requirements. Edition, 2001.
[2] Jalote, Pankaj, “An Integrated Approach to Software
3.2.4.2 Phase 4B (Detailed Design) Engineering”, Narosa, Third Edition, 2005.
[3] Sommerville, Ian, “Software Engineering”, Pearson
It is only when a broad solution is chosen that detailed design Education, Sixth Edition, 2002.
starts. During the detailed design phase, the database and [4] Mall, Rajib, “Fundamentals of Software Engineering”,
program modules are designed and detailed user procedures Prentice-Hall India, Second Edition, 2003.
are documented. The interaction between the system users [5] Lawrence, Shari, “Software Engineering: Theory and
and computers is also defined. These interfaces define exactly Practice”, Pfleeger; Pearson Education, Second Edition,
what the user will be expected to do to use the system. 2001.
[6] Mukhopadhyay, Debajyoti and Dalezman, Blanka,
The output of detailed design includes a proposed equipment “Designing Open Systems with CASE”, Information
configuration together with specifications for the database and Systems Management Journal; Auerbach Publications,
computer programs. Detailed user procedures are also Boston, Massachusetts, USA; Vol.12 No. 1; Winter 1995;
provided. These include any input forms and computer pp.26-34.
interaction between users and the computer. The user manual
is also ready at the end of this phase. This output, particularly
the proposed interactions between the computer and users, is
validated against user requirements.

3.2.5 Phase 5 – System Construction

Like the design phase, this phase is also often broken up into
two smaller phases: development and implementation. The
individual system components are built during the
development period. Programs are written and tested and user
interfaces developed and tried by users. The database is
initialized with data. During implementation, the components
built during development are put into operational use. Usually
this means that the new and old systems are run in parallel for
some time. To complete the changeover, users must be
trained in system operation and any existing procedures
converted to the new system. One important part of
construction is testing. It is necessary to test all modules to
ensure they work without any errors once they are put into
operation. Testing itself can be a process on its own. We first
test individual modules, then we test their interfaces and see
how they work together. At the end of this phase, users are
provided with a working system.

4. Conclusions

We have discussed the basic steps involved in designing a

cost effective and efficient software system. It is important to
carry out each of the phases in the life cycle model. Meeting
the users several times and collecting sample data and reports
always help writing a good Software Requirements
Specification document. While designing the software
system, creating modules with high cohesion and low
coupling is always desirable. Reusability is another important
aspect for creating cost effective system. Special attention
should be given to develop the software such that it is modular

23

View publication stats