Introduction
System analysis (SA) is the study of sets of interacting entities that are composed of computer systems analysis. Operations research is closely related to this field. System analysis is an open formal query conceded out to help somebody (the decision maker) to identify the suitable course of action (Krippendorff). System Design (SD) is the procedure of defining the interfaces, components, architecture and data for an organization to please specified necessity (Boehm, Barry 2006). Systems Analysis and Design (SAD) is defined as the process of developing information systems that efficiently use software, hardware, processes, data, and people to support the company’s business objective.
The evolution of system analysis and design takes the below history:
1970s pre SSADM- first generation
These “semi formal” plan methodologies and methodologies of 1970s paid attention on mimicking the reasonable flows of the industry. Systems designers recognized incompleteness with the approach. Kimble describes it as having “anti-realistic ontology rationalist epistemology”. Edward Yourdon published the first criticism of the traditionalist approaches in his book (Structured designs, 1979). The first generation approaches were monolithic. Functional specifications were large and often cumbersome hence dealt with the entire system and therefore required the developers to understand them in their entirety. This inadequacy hindered up-and-coming design approaches that required a more modular move toward where the client may have wanted a consideration of one of the building blocks of the scheme without automatically need to understand the other.
The first generation approaches contained redundancies. Consider that when the user requirements changed, adjustments were required on several areas of the functional specifications document. The approaches contained inconsistencies. These were basically brought about by redundancy and the need to revise several areas of the functional document thus creating inconsistency. First generation designs were difficult to maintain. They would no longer represent the major functions adequately.
1980s SASDM vs. .SSAD in evolution
In the early 1980s studies indicated that the first generation approach had shortcomings thus new ideas begun to take center stage. These new ideas advocated the need for more modular design methods that allowed programmers insight into the parts of the procedure rather than the process as a whole. These new approach was generally referred to as System Analysis and System Design (SASD). Edward Nash Yourdon, 1989 fully claimed to be replacing the “Top down” first generation systems analysis with a more event-driven process illustrated in a graphic of the data flow diagram. Yourdon’s approach detailed out the steps as follows; a physical model of existing system was created using data flow diagrams and supporting documentation. The corporal details were detached from the supporting documentation and diagrams to produce a reasonable model of existing system.
Illustration of a data flow diagram:
Source: Yourdon models
Criticism of SASD
SASD was time consuming; the weakness of new SASD methodologies begun to emerge.
The process of creating various innovations was considered by developers to the current physical system and they would go ahead and restructure the physical components before developing a logical model and then modify it as time consuming. The methods for making data flow
diagrams also differed hence they lacked a guideline to substantiate. Costly reworking efforts for bringing on the same page different teams were brought about by the viewers in regard to the system.
Development of SSADM techniques
Structured System and Analysis Design Method (SSAM) consist of modeling of logical datawhere there is identification of process data requirements. The system data are then separated into entities (system players and actors) and the relationships (the associations between entities). It also looks at the data flows and the direction in which the data moves. There is entity behavior modeling which is the course of modeling, identifying, and documenting the proceedings that concern each entity and the series in which the actions occur. (Yourdon and DeMarco)
In regard to evolution of the System Analysis and design, the entity relationship diagram addresses the relationship between the different actors within a system. Two scholars, Finklestein and Martin have clearly defined entities. Finklestine define entities in the designer’s wisdom of representing “facts to be stocked up for reference at a later date” while Martin describes to entities as “something regarding which we store data.
Simple Yourdon/ DeMarco events list is illustrated below:
Id name status
Id status source: winter, 1998.making data model is readable.
Finkelstein’s Entity Relationship Diagram:
Is III Is to
Is for Is vendor III
Is on Is for
V.Rajaraman in a module paper that contributed to SADs evolution discuses development stages of the System Analysis and Design (SAD). The module paper is embarked by there motivational strategies that are in support of the SAD life cycle. They include; helping organization design information systems in an easier way, to help students know how to logically divide a complex job into smaller manageable steps and to ensure each stride must have a rational commencement and end and must be self contained (V.Rajaraman1). The lifecycle of SAD has nine stages which include the following; requirements determination, requirements specification, feasibility analysis, final specifications, hardware study, system design, system implementation, system evaluation and system modification (V.Rajaraman 4).
The module paper categorically looks at the nine stages and what each entails. The first stage entails requirements determination is arrived at by a consensus among the managers, setting priorities among the determined applications and picking high priority applications. The second stage involving requirements specification, described as System Requirements Specification (SRS) that understands the system which is existing. Where systems are needed application are listed, finally getting to user’s applications requirements after discussion with the user. The third stage is the feasibility analysis. It involves formulating goals and finding alternative methods of meeting the goals, assessing cost of each alternative and finally finding the best alternative method subject to resource constraints. The fourth development stage is the final specifications. Specifications would state what the system would achieve; specifications drawn up are improved for implementation. The fifth stage in the development cycle is the hardware study. It involves determining the hardware and software required to execute the application and determining the response time, volume of data to be processed the pick the hardware (V. Rajaraman 9).
The sixth stage under the lifecycle of SADs is the system design. It looks at the logical design of the system, objects identified, database design, program specification drawn up, implementation plan drawn up and test plan. The seventh stage under the SADs development is system implementation. The stage involves; writing programs, creating data base, documenting the system, training the users, trail run of the system and the last one is testing and accepting. The eighth stage involves system evaluation which entails finding from the users whether the system meets specified requirements, list areas of dissatisfaction and finds reasons and finally suggests whether there has to be any improvements to the system. The final stage is the system modification. It entails fixing the errors, tuning the system and continuous monitoring of the system (V. Rajaraman 13).
System Analysis and Design (SADs) is an interdisciplinary part of science which can be related to the following:
Object- Oriented Analysis and Design (OOAD), is engineering approach software that models a scheme as a group of objects which interact. Each object is therefore said to represent some entity of interest which is on the modeling process and it is characterized by the data elements, class and its behavior. OOA applies the techniques of object modeling for examination of practical system necessities. Objected oriented analysis applies some techniques such as object modeling in order to examine the practical necessities of that particular system Object oriented design then intricate the analysis model to produce the specifications implementations needed.OOA is then said to focus on the deeds of the system while OOD focuses mostly on the system executes. (Bertrand Meyer 1997).
Another discipline is the Service Oriented Analysis and Design which redirects to service oriented modeling. It is a discipline of modeling business and software system with a motive of designing and specifying service- oriented business system inside a diversity of architectural styles such as application architecture, enterprise architecture, cloud computing and service- oriented architecture. Any service slanting methodology of modeling characteristically includes a modeling language that can be used by both the business and the organization, which’s a unique perspective typically influence the service development lifecycle strategy and the projects implemented using that strategy. Service- oriented modeling aspires at making models that offer a wide sight of the analysis, design and architecture of all software entities in an organization, which can be well understood by people who own levels of various business and technical consideration. Service-oriented modeling encourages viewing software entities as assets.
There are many different models that have been projected for service modeling including Service -oriented Modeling, Architecture (SOMA) and Service-oriented Modeling Framework (SOMF). SOMA is composed of a design and an analysis method that widens customary object-oriented and component- based analysis and design methods with a view of including concerns relevant to and supporting service-oriented analysis (Bieberstein et al). Michael Bell proposed the service-oriented framework (SOMF) as an anthropomorphic and holistic modeling language for development of software that mainly employs various mechanisms and a language that is universal to provide strategic and tactical results to problems of enterprise. The term holistic language regards to a language of modeling that can be used to design any application which is under business or technological environment. While on the other hand “anthropomorphic” associates the SOMF language with intuitiveness of implementation and straightforwardness of usage (Bell 2).
Structured System Analysis and Design Method (SSADM) is discipline that we have earlier discussed under the evolution of the system analysis and design. It is a water fall method for the analysis and design of information system. As an implementation tool SSDAM is believed to build on work various schools analysis and development methods, such as Peter Checkland’s soft systems methodology, Larry Constantine’s structured analysis, Edward Yourdon structured method Michael A. Jackson structured programming and Tom DeMarco structured programming. The name “Structured System Analysis and Design Method” acquired patent rights by being registered trade marks of the Office Government Commerce (OGC) which is an office of the United Kingdom’s (UK) treasury (OGC 2010).
The principle development stages of SSADM were later categorized into twelve stages which the paper is going to briefly look at. They included; The Central Computer and Telecommunication Agency (CCTA) which was founded in the year 1980s to evaluate analysis and design methods. The second development stage emerged in 1981 where the consultants working for Laermonth and Bruchett Management Systems, led by John Hall chose to develop SSADM. In the year 1982 John Hall Keith Robinson left to find model systems Ltd, and late during the year Learmont and Bruchett Management Systems (LBMS) settled to develop LSDM as their proprietary version.
In the course of the advancements SSADM was made mandatory for all new information systems development. During the year 1984 version 2 of the Structured System Analysis and Design Method was released. Later version 3 of the System Analysis and Design Methods (SSADM) was released and adopted by NCC (UK government education awarding body). SSADM was promoted as an ‘open’ standard in the year 1988 when SSADM certificate of proficiency was launched. In the year 1989 the developments moved towards euro method which was the launch of CASE certification scheme. During the year 1990 version 4 of the SSADM was launched. The Standard and Tools Conformance Scheme which was a modification to the 4th version was launched in 1993. In the year 1995 SSADM V4+ was announced and a subsequent launch of V4.2 was made. During the year 2000 Central Computer and Telecommunications Agency (CCTA) renamed SSADM as Business System Development. This method was later repackaged into 15 modules and other six modules were added. (History of SSADM adopted from http://en wikipedia.org/wiki/).
Another discipline is the Structured Analysis and Design Technique (SADT). It is as illustrative notation designed particularly to help people illustrate and recognize a system. It presents building blocks to characterize entity and actions and variety of arrows showing the relationship of the boxes (D. Marca 1987). These boxes and arrows have an associated informal semantics (John Mylopoulos 2004). The SADT method not only helps one user to define the development needs for IT development but also helps in explaining and presenting an activity manufacturing process and procedure.
According to Levitt 2000, Structured Analysis and Design Techniques it is an element of a sequence of structured methods that present a compilation of analysis, design and programming techniques that were developed in the response to the problems facing the software world from 1960s to 1980s. Under this time frame most of the commercial programming was done in COBLO and FORTRAN, the C and Basic. There was minimal guidance on good design and programming techniques and there was lack of standardized documentation requirements and design. Systems were getting harder and more cumbersome thus information system development proved harder to undertake. As a way to help mange complex large and complex system software multiple structured methods emerged to aid.
Works cited
DeMarco, Tom. Structured Analysis and System Specification. New York: YOURDON Press,1978.
Edward Yourdon, and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of
Computer Program and System Design, 1979. Print
Kimble, Chris. System Design Methodologies (SDM) Semi Formal Methodologies/ The First
Generation Methodologies. chris-kimble.com:
http://www.chris-kimble.com/Courses/sdm/Session_5.html, 2011.
Martin, James, and Clive Finkelstein. Information Engineering, Technical Report. Lancs, UK:
Savant Institute, Carnforth, 1981.
Winter. Making Data Models Readable: Information Systems Management. 15, Boca Raton, FL:
CRC Press, 1998. Print
Sauter, Vicki. A History Of Structured Systems Analysis & Design Methodologies. n.d. 2011. 24 February 2013
Wasson, Charles S. System Analysis, Design, and Development: Concepts, Principles, and Practices. New Jersey: Wiley Publishers, 2006.
