UNIVERSITI TUNKU ABDUL RAHMAN

FACULTY OF ENGINEERING AND SCIENCE

Master of Information Systems

MECM15503 Software Project Framework May 2013 Assignment 1

Assessors Name: Prof. Junichi Kishigami Date of Submission: 25/07/2013

Name Teh Yew Pin

Student ID 13UEM06777

Contact No. 017-5787892

E-mail yewpin@hotmail.com

Table of Contents

Title 1.0 2.0 Background and History of SSADM and RAD Principles (Philosophy), Techniques and Tools, Life Cycle Stages

Page Number 1 2-6

and Output, and Practices of SSADM and RAD 2.1 Structured Systems Analysis and Design Methods (SSADM) 2.2 Rapid Application Development (RAD) 3.0 Compare and Contrast the two methodologies 2-4 4-6 66-7 7-8 8 9

3.1 Similarities between SSADM and RAD 3.2 Differences between SSADM and RAD 4.0 5.0 Conclusion References

1.0

Background and History of SSADM and RAD

Structured Systems Analysis and Design Methods (SSADM) Structured Systems Analysis and Design Methods (SSADM) is a comprehensive method containing techniques and products for system analysis and design (The Stationary Office, 2000). SSADM was introduced in 1981 as a standard method of analysis and design developed by CCTA (Central Computing and Telecommunication Agency) for UK Government projects. OGCIO (formerly known as ITSD) adopted SSADM since May 1988. The full implementation of SSADM commenced in 1991 after a few series of successful implementations. All administrative computer systems developed in OCGIO used SSDAM since November 1991. The key feature of SSADM is flexibility where the elements of the method may be used thoroughly if needed. Individual products may be used, supplemented, varied, replaced or even omitted according to the needs of the specific project, programme or the organization as a whole.

Rapid Application Development (RAD) Rapid Application Development (RAD) is a development lifecycle designed to produce much faster development and higher quality results compared to those achieved with the traditional lifecycle (CASEMaker Totem, 2000). It is also defined as an approach to build computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, userdriven prototypes and strict project delivery deadlines into an effective and reliable methodology for quality and productivity. In 1986, Barry Boehm wrote A Spiral Model of Software Development and Enhancement, which initially defined the concept of prototyping and iterative development with a focus on risk reduction. During the late 1980s, Scott Shultz and James Martin refined the concepts of prototyping and iterative development into a methodology called Rapid Iterative Production Prototyping (RIPP) that focused on developing systems in a shorter time with small teams consisting of highly qualified, motivated and experienced staffs. James Martin further expanded and formalized RIPP which lead to the publishing of the book Rapid Application Development in 1991.

2.0

Principles (Philosophy), Techniques and Tools, Life Cycle Stages and Output, and Practices of SSADM and RAD

2.1

Structured Systems Analysis and Design Methods (SSADM)

SSADM utilizes a combination of three techniques which are as follows. a) Logical Data Modeling is the process of identifying, modeling, and documenting the data requirements of the system being designed. The data is then separated into entities and relationships (Government of the HKSAR, 2012). b) Data Flow Modeling is the process of identifying, modeling and documenting how data moves around an information system. It examines processes, data stores, external entities and data flows (Government of the HKSAR, 2012). c) Entity Behavior Modeling is the process of identifying, modeling and documenting the events that affect each entity and the sequence in which these events occur (Government of the HKSAR, 2012).

The following are the seven stages in the software development lifecycle of SSADM.

Stage 0 Feasibility study A Feasibility Study is a short evaluation of a proposed information system to determine whether the system can effectively meet the specified business requirements of the organization. The current and required environments are studied and documented only in sufficient detail to enable the Project Steering Committee to select from a range of business and technical options in order to determine if it is beneficial to implement the chosen option. The major deliverables in this stage include Current System Description, Current Physical Data Flow Model, Current Environment Logical Data Model, Requirements Catalogue, and Selected Feasibility Option. Stage 1 Investigation of the Current Environment Stage 1 involves planning of the project and inspection of documents from the Feasibility Study. The details of the current environment which include the business area, objectives and the users involved are analyzed and recorded in the Business Activity Model, Current System Description, Data Flow Model and Logical Data Model. Besides that, the requirements of the proposed 2

systems and constraints of the project are also recorded. The major deliverables in this stage include Business Activity Model, Current System Description, Current Physical Data Flow Model, Current Environmental Logical Data Model, Requirement Catalogue and Constraint List. Stage 2 Business System Options During Stage 2, the derivation of possible system options with different set of functions and interfaces with other systems are carried out. For each option, impacts on the organization, costs and benefits, and other considerations such as technical constraints are analyzed to assist users in making decisions in their selection of the Business System Option. The major deliverable in this stage is Selected Business System Option. Stage 3 Requirements Specification In Stage 3, the Requirements Specification is developed based on the Selected Business System Option. The Data Flow Model and Logical Data Model are modified to integrate functions and data requirements of the proposed system. After discussing with users to confirm the system requirements, functions from the Data Flow Model and other required retrieval functions are merged and described in detail in the Function Definition documents. Furthermore, parts of the proposed system could be subjected to prototyping in order to clarify and confirm some detail requirements. The major deliverables in this stage include Required System Description, Required System Data Flow Model, Required System Logical Data Model and Function Definition. Stage 4 Technical System Options When defining the Technical System Options for the required system, documents containing the Evaluated Capacity Planning Information and in-house standards for installation and technical environment should be studied. For example, Information Systems Strategy Study Plan. The impact on the organization, cost and benefit, and other related considerations should be analyzed for each technical system option defined in order to assist the user in selecting the best option. The Selected Technical System Option is then expanded to detail the technical system environment, the design objective of the proposed system and the implementation plan for the

targeted environment. The major deliverables in this stage include Application Style Guide, Sizing Model and Selected Technical System Option. Stage 5 Logical Design Based on the Requirements Specification, the Dialogue Design is prepared for functions related to user interaction. Besides that, the Retrieval and Update Functions are transformed into Retrieval and Update Process Modules respectively. When defining process modules, design objectives such as modularity, shared use, maximal cohesion and minimal coupling should be taken into consideration. The major deliverables in this stage include Process Modules and Screen/ Report Layouts. Stage 6 Physical Design Preparation for the physical design is made by learning the rules of the implementation environment. Besides that, these rules should also be stated in the product specific guides provided by suppliers. This stage also involves in the completion of the specification of functions such as preparing the program specifications. Furthermore, this stage also optimizes the design of data and process while testing them against the sizing and timing objectives stated in the design objectives. The major deliverables in this stage include Optimized Physical Data Design, Program Specifications and Process Data Interfaces.

2.2

Rapid Application Development (RAD)

Rapid Application Development (RAD) has many core elements that make it a unique software development methodology such as prototyping, iterative development, time boxing, team members and RAD tools (BlueInk, 2005).

Prototyping Prototyping is used to help users visualize and request changes to the system therefore allowing applications to evolve iteratively as it is being built. The purpose of prototyping is to build a feature light version of the finished system as quickly as possible. The prototype will serve as a concept and tool for refining requirements with the client.

Iterative Development Iterative development is used to develop functional versions of the proposed system in short development cycles. Each version is reviewed with the client in order to capture requirements and feedbacks for the next version. This process is iterated until all functionality has been developed.

Time Boxing Time boxing is the process of delaying certain features to future prototype versions in order to complete the current version in as little time as possible. The process must be managed strictly in order not to lengthen development iterations which will limit client feedback.

Team Members The utilization of small teams consisting of experienced, versatile, and motivated members that are able to perform multiple roles is recommended. Besides that, the client plays a vital role in the development process. Hence, dedicated client resources must be available during the initial Joint Application Development (JAD) sessions as well as Focus Group Sessions conducted at the end of development cycles.

RAD Tools According to James Martin, developer of RAD, it is essential to take advantage of the latest technology available to speed up development. The tools utilized in RAD back in the 1980s include Computer-Aided Systems Engineering (CASE) tools, data modeling tools and code generation tools. The software development lifecycle of RAD consisting of four phases are briefly described below.

Requirements Planning phase This phase is also known as the Concept Definition phase. This phase defines the business needs, project scope, constraints and system requirements. This phase concludes when the team consisting of users, managers and IT staff members agree on the key issues and obtain management authorization to proceed.

User Design phase This phase is also known as the Functional Design phase. In this phase, the team uses a combination of CASE tools and Joint Application Development (JAD) workshops to translate user requirements into models and prototypes that represent critical system functionality.

Construction phase This phase is also known as the Development phase. This phase include activities such as programming and application development, coding, unit integrations and system testing. At this point, users continue to participate and suggest changes or improvements to the system.

Implementation phase This phase is also known as the Deployment phase. This phase involves the data conversion, final user testing, the implementation to the new system, and user training.

3.0 3.1

Compare and Contrast the two methodologies Similarities between SSADM and RAD

The similarities between SSADM and RAD are as follows. a) SSADM and RAD both include user involvement in the software development cycle. However, for SSADM, the user is only involved during mid-project discussion and planning of requirements and during post-project presentation of final product. b) SSADM and RAD both uses Computer-Aided System Engineering (CASE) tools in the development of the system. However, for SSADM, the employment of the CASE tool is not mandatory.

c) SSADM and RAD both employs diagram modeling tools to represent system designs, data models, process models and etc. These diagrams are used to clarify doubts on the requirements, plot out relationships between modules as well as their dependencies, and have an overall understanding and view of the system structure.

3.2

Differences between SSADM and RAD SSADM More formal Clear and defined formal documentation Developers avoid changes RAD Less formal Reduce the amount of documentation to minimal Developers welcome changes

Differences Formality Requirements planning

Initial project estimates

A detailed feasibility study is conducted to estimate the resources and time required

The high-level user team and developer team participate in the Joint Requirements Planning workshop to estimate the resources and time required

Active user involvement

No, seldomly involves user in the development

Yes, an user coordinator is selected to oversee the project from the user perspective Workshops, Joint Application Development (JAD) Time boxing Prototyping CASE tools essential for rapid development Modeling techniques such as DFD, ERM, Action Diagram

Techniques and tools used

Interviews, questionnaires, observation and analysis of documentations

CASE tools not essential for development Modeling techniques such as DFD, ERM, ELH

Roles and responsibilities

Less clearly defined roles. For instances, systems analyst, user, development programmer and etc.

More clearly defined roles. For instances, sponsor, user coordinator, requirements planning team, user design team and etc. Frequent reviews by the user Uses prototyping for review sessions Formal review at the end of project

Quality management

Formal reviews during the requirements gathering and during the end of project

4.0

Conclusion

SSADM is one of the many structured based software development methodologies based on the traditional Waterfall methodology. SSADM was designed to address the drawbacks of the Waterfall methodology by incorporating flexibility throughout the life-cycle. On the other hand, RAD is one of the earliest agile methodologies designed to solve the drawbacks of the traditional software development methodologies. RAD aims to produce much faster and higher quality systems in a short duration compared to the traditional methodologies. In conclusion, SSADM and RAD has their share of similarities and differences. In terms of similarities, SSADM and RAD both incorporates user involvement, employment of CASE tools and diagram modeling tools. However, in terms of differences, RAD is less formal compared to SSADM. RAD tends to focus on system development while SSADM tend to focus on detailed documentation. Besides that, RAD emphasizes heavily on active user involvement while it is lightly emphasized in SSADM. The system developed using RAD will be of higher quality than SSADM because RAD involves frequent user reviews and prototyping for quality assurance and usability. After comparing the methodologies above, RAD appears to be the better software development methodology but that is not necessarily true. This is because there is no one perfect methodology for any given software development project. RAD would not exist if the traditional software development methodologies have no drawbacks. The best software development methodology would be an existing methodology or combination of existing methodologies customized to suit the organizations culture, business process, and development team. 8

5.0

Bibliography

BlueInk. (2005). Rapid Application Development. Retrieved June 17, 2013, from http://www.blueink.biz/RapidApplicationDevelopment.aspx

CASEMaker Totem. (2000). What is Rapid Application Development?. Retrieved June 16, 2013, from http://www.casemaker.com/download/products/totem/rad_wp.pdf

The Government of the HKSAR. (2012). An introduction to structured systems analysis & design methodology (SSADM). Retrieved June 16, 2013, from

http://www.ogcio.gov.hk/en/infrastructure/methodology/ssadm/doc/s3a_pub.pdf

The Stationary Office. (2000). SSADM foundation. Retrieved June 15, 2013, from http://books.google.com.my/books?hl=en&lr=&id=5ZrwvsBuWDMC&oi=fnd&pg=PR3&dq=ba ckground+and+history+of+ssadm&ots=yqj_FfimA&sig=Ww5xur5jeezkp_egKEYt53Kzzh4#v=onepage&q&f=false

Webopedia.

(n.d.).

What

is

SSADM?.

Retrieved

June

16,

2013,

from

http://www.webopedia.com/TERM/S/SSADM.html