Introduction:
The impressive improvements that are continuously being made
in cost-effectiveness of computer hardware are causing an
enormous expansion in the number of application for which
computing is becoming a feasible and economical solution.
This in turn is placing greater and greater demands for the
development and operation of computer software systems. The
growth of software industry has not however been painless.
Statistics shows that the development of software has been
marked by cost over-run, late deliveries, poor reliability
and users dissatisfaction. In an effort to bring discipline
to the development of software systems, attempts have been
made since 1970s to apply the rigours of science and engineering
to the software production process (Tarek K. Abdel-Hamid and
Madnick 1989).The methodologies have matured from the introduction
of Structured Analysis method in late seventies to the Object
Oriented Analysis of eighties.
Structured System Analysis and Design:
Structured Systems Analysis/Structured Design, abbreviated
SSA/SD, (also called Structured Analysis and Design, abbreviated
SA/SD) has been the most popular and widely used analysis
and design method since the 1970s. Although it is being superseded
by object-oriented approaches, many of the notations, processes,
and heuristics of this method have been adopted by later methods.
Structured Systems Analysis and Design Methodology is the
most sophisticated of the function-oriented analysis and design
methods. Structured Systems Analysis (SSA) was originally
developed by Yourdon and DeMarco and refined several times.
SSA formed the mainstream of Systems Analysis from the late
1970’s into the 1990’s. SSA is still the preferred
systems analysis for a lot of people.
Principles of Structured Methodology:
Since its introduction in the late seventies, Structured
Analysis has undergone a considerable amount of changes, however
the underlying principles have more or less remained the same.
It belongs to a broad family of design methods based on hierarchical
decomposition of function, often referred to as functional
analysis.
Structured analysis and design is an approach that emphasizes
analysis of data flows and processes rather than control flows
or functional hierarchies.
This approach uses data flow diagrams, data dictionaries,
minispecs, and structure charts to produce and document analyses
and designs.The method was pioneered by Larry Constantine
in 1974 and documented in a variety of books. The best modern
treatment of structured analysis is Edward Yourdon, “Modern
Structured Analysis”,
Yourdon Press, 1992 (Yourdon 1992). Modern treatments of
structured design are rare (probably because the design process
and heuristics are not very useful), so the best introduction
is Edward Yourdon and Larry Constantine, “Structured
Design”, Prentice-Hall, 1979.(Yourdon and Constantine
1979)
The methodology since its inception has influenced other design
methods and is also supported my most CASE tools.
The Notations used in the Structured Methodology are,[1]
Data flow diagrams (DFDs) show functional decomposition,
with an emphasis on the transfer of data in and out of the
system and between program units.
A context diagram is a special kind of data flow diagram
used to depict the inputs and outputs of a system as a whole.
Pseudocode/Minispecs is English written with programming
constructs as a means of easily but precisely describing processing.
A data dictionary is a master list of all the data flows,
stores, terminators, processes, minispecs, attributes, and
data elements in a system.
According to Demarco (DeMarco 1978), the Analysis should
include four steps modeling the current physical, current
logical, new logical and new physical. Each step should consist
of a complete description of the system by DFDs, the data
dictionary and minispecs. Although there has been a lot of
debate on the usefulness of a current physical model and has
resulted in many recommendations like building an “Essential
Model” (Palmer and McMenamin 1984) or skipping the building
of a current physical model (Yourdon 1992)
Structured Analysis/Structured Design contained a practice
known as “The Transform Analysis” [2],
which was used to convert the diagrams representing a Structured
Analysis into the diagrams that represented a Structured Design.
This practice, and indeed much of the documentation of the
period, established the notion that the design was directly
derivable from the analysis by applying some simple transformation
rules. This meant that the analysis was really a preliminary
description of the design, requiring only a mapping operation
to complete. In SASD it was necessary to finish the analysis
before the Transform Analysis could be applied to translate
the analysis into a design. Thus, SASD strongly reinforced
the waterfall model of systems development.
Critical Assumptions Underlying Structured Analysis (Bansler
and Bodker 1993)
· Structured Methodology is representative of a “Functionalist”[3]
or a “System-Structural” approach to the study
of organizations. So the organization is seen as a “machine”
designed to perform a given function optimally.
· The problem that is to be solved is clearly defined,
and will not change during the process. It is possible to
verify if the solution obtained meets the initial design criteria.
· The designer is assumed to be completely rationale
i.e., he has complete knowledge as to what the final solution
should look like.
· It is possible to separate function from implementation,
i.e. decisions about the new physical model must be postponed
until after the new logical model has been determined.
These assumptions have led to a number of deficiencies with
regard to the practical application of the method:
· Structured Analysis underrates the skill of the workers
and workers or people are made into objects, perceived as
system components comparable with tools, machines and raw
materials.
· In real life design situations, problems are ill
defined more often than not, Objectives and goals are vague
and keep changing constantly which undermines the assumptions
of the Structured Method.
· Usually the design process is a collective process
where interactions between several actors take place and not
just by a rational designer. The Structured method overlooks
the fact that some form of active user participation is indispensable
when objectives and evaluation criteria are not explicit and
fixed at the outset.
· It is less likely that the user will be able to imagine
how the system will function only by looking at formal descriptions
such as the data flow diagrams.
· The data flow diagrams and the various types of formal
notations are not designed with the user in mind, and hence
causes difficulties in communicating with the users
Structured Methodology thus needed a lot of refinement to
be actually used in theory, there was a need for a more user-centered
approach to Systems Analysis and Design.
In the late 1980’s a new set of ideas arrived in the
field of systems analysis and design – Object Oriented
Analysis and Design.
Object Oriented Methodology:
Though object-orientation (OO) was invented in the sixties,
it languished for two
decades, before rising to popularity in the nineties. At first,
there was just object-oriented programming (OOP). Soon, however,
the OO prefix was applied to both analysis (OOA) and design
(OOD).
The goal for OOA was to eliminate the Transform Analysis that
was used in structured methods, or its equivalent. Instead
of having to translate the finished analysis into a design,
an OOA could be elaborated into an OOD through the addition
of extra detail. This meant that the analysis and design could
be performed in the same notation, and at the same time.
Object-oriented analysis examines system requirements from
the perspective of classes and objects found in the specified
domain. It looks at the behaviour of the system independent
of its domain. Object-oriented analysis looks at the real-world
environment, in which a system will operate, with this environment
consisting of people and things interacting to create some
result. The people and things are first analysed in the most
abstract form and these abstractions become the class. The
abstraction is analysed and reanalysed in multiple iterations
until all objects are uniquely identified. Object characteristics
and their behaviours are then analysed to establish the various
states an object can have and to define the methods the object
will use to create action. This analysis effort will identify
the objects that will need to be created and supported as
well as the methods and the messages used by the objects to
cause actions. How does this differ from traditional analysis
methods? In the traditional method, the focus is on business
processes and the data needed to support the process. Traditional
methods describe the system in terms of inputs, outputs and
data flows -- starting with a structured analysis and developing
procedural programs. Object-oriented analysis shifts the focus
to an effort to combine processes and data into objects to
de-emphasise the focus on procedures. The object knows how
to accomplish a task or behaviour; therefore, it is not important
to the analysis effort to focus on the processes associated
with the behaviour, shifting the focus from how to what a
system is supposed to do. Object-oriented analysis models
the concepts of behavioural and interaction within a system
rather than the processes and procedures.
Object-oriented development is not a new technology but it
has not had widespread use and is still maturing. Object-oriented
analysis starts you on a path that can lead to benefits not
only in the analysis process but also in subsequent development
phases.
Benefits of Object Oriented Methods:
Proponents of the object-oriented approach list the benefits
as
· An easier way to promote the understanding of a system,
· Reusability of models and programming, modifiability
· Reduced costs associated with change
· Reduced development risk
· High quality of the models
· High productivity
· The development speed, degree of organization, robustness,
and code reuse have all been enhanced so much that going back
to any other way of doing things is completely unthinkable.
· Encapsulation of data and behaviour into a single
entity (i.e., the object)
These benefits lead to a superior method of analysing business
processes and requirements. Finally, because the contemporary
view of development is from the object-oriented perspective,
object-oriented analysis allows us to take advantage of the
contemporary programming languages, operating systems and
associated tools.
Objects are said to replicate what humans see in real life
and, therefore, appeals to human cognition.
The object-oriented paradigm views the world as composed of
objects with well-defined properties, with objects replicating
things in an environment. It is easier to promote a user's
understanding when the user is presented with objects describing
things found in the normal course of conducting business.
Reusability is a desired goal of all development and is based
on the reluctance of reinventing something when it has already
been invented. Object-oriented development supports this,
especially in the concept of abstraction. Abstraction supports
continual iterations of analysis until unique objects are
found in a class hierarchy. These unique objects inherit characteristics
from the higher-level classes and this allows you to reuse
information from the previously defined classes, eliminating
the need to reinvent it. The use of objects makes it easier
to change and modify systems.
While the proponents of object-oriented analysis detail the
benefits discussed above, critics have maintained that it
is not the solution to all problems.
Criticisms of object-orientation include
· lack of standardization,
· the costly nature of adopting this paradigm,
· problems associated with the concept of reusability,
· applicability of adopting it for legacy systems
· confusion of too many OOA/D methods[4]
Changing from a traditional development model to an object-oriented
approach is costly and should not be dismissed lightly.
This change requires the infamous paradigm shift, meaning
you have to completely change your way of thinking and change
your business processes as well as invest in training in order
to ensure the staff is ready to accommodate the changes. This
requires an investment in not only money but also time. Critics
of object-oriented development contend reusability is very
difficult to employ in both new development and the continual
development of systems.
In spite of these criticisms, Object Oriented Approaches
are better suited than Structured approaches, an important
reason being the fact that it reduces complexity, which has
been the root cause of many IS failures in the past. Coad
and Yourdon suggest 7 aspects of complexity any form of analysis
needs to address, and which the OO approach embodies,
· Abstraction
· Encapsulation
· Inheritance
· Association
· Communication
· Pervading Methods of Organisation
· Scale
· Categories of Behaviour
Most importantly OO approach is an incremental and iterative
approach thus it takes into consideration the aspects of risk
involved in the development process unlike the structured
approaches.
Should businesses adopt object-oriented analysis? There is
no clear-cut answer to this because it is dependent upon business
needs, and the willingness of the business to make the investment
necessary to adopt this methodology. In order to adopt this
methodology, the business should invest in training for all
individuals involved in the analysis process and slowly integrate
the process by using it in low-risk projects first to allow
the analysts to learn from their mistakes. Successful adoption
of this methodology lies in commitment, training, and experience.
Conclusion:
It is clear that the Object Oriented paradigm and technologies
are with us to stay and will help us create the application
systems of the next century. Object Oriented Development (OOD)
has been touted as the next great advance in software engineering.
It promises to reduce development time, reduce the time and
resources required to maintain existing applications, increase
code reuse, and provide a competitive advantage to organizations
that use it. There are many pitfalls and traps involved in
using OOD technologies[5]
, just like there are in using traditional methodologies for
systems development. However, if OOD is used properly, the
rewards and benefits can be greater than using traditional
approaches and this would definitely lead to a reduction of
Information Systems Failures.
-
Palmer and McMenamin
supplement Structured Analysis with tools to describe
data relationships at a higher level in entity-relationship
diagrams (Palmer and McMenamin 1984) . To describe time-dependent
behavior, Yourdon has added State Transition Diagrams
to Structured Analysis (Yourdon 1992).[ Return]
-
Refer paper
written by Robert C. Martin at http://www.objectmentor.com/resources/articles/On_Analysis[ Return]
-
From the Burrell
and Morgan Paradigm of classification of Organisational
Theories.[ Return]
- There are a number of OOAD Methodologies,
some of the major methodologies include Booch OOMD, Coad
and Yourdan OOMD, Fusion, Jacobson Objectory, LBMS SE00Rumbaugh
OMT[Return]
-
Refer “Pitfalls
of Object Oriented Development” by Shah, Sivitanides
and Martin[ Return]
- BIBLIOGRAPHY:
- Avison, D and Fitzgerald, G., (1995). Information
Systems Development: Methodologies, Tools and Techniques.
2/E. McGraw Hill, Maidenhead
- Bansler , J. and K. Bodker (1993). "A Reappraisal
of Structured Analysis: Design in an Organizational Context."
ACM transactions on Information Systems 11: 165-193.
- DeMarco, T. (1978). Structured Analysis and System
Specification. New York, Yourdon Press.
- Palmer, J. and S. McMenamin (1984). Essential
Systems Analysis. New York, Yourdon Press/ Prentice-Hall.
- Tarek K. Abdel-Hamid and S. E. Madnick (1989).
"Lessons Learned from Modelling the Dynamics of Software
Development." Communications of the ACM 32(12).
- Yourdon, E. (1992). Modern Structured Analysis.
New York, Yourdon Press/Prentice Hall.
- Yourdon, E. and L. Constantine (1979). Structured
Design, Prentice-Hall.
|
