University of Missouri, St. Louis
Jia-Ching Lin
11-8-2011
When developing information systems, most organizations use a standard of steps called the systems development lifecycle (SDLC) at the common methodology for systems development. SDLC includes phases such as planning, analysis, design, implementation, and maintenance. At the heart of systems development, analysis and design are the second and third phases of SDLC. The analysis phase usually requires a careful study of the current system, which continues two sub phases: requirements determination and analysis study. Requirements determination process usually involves a careful study of the current manual and computerized systems that may be replaced or improved within the project. Analysis study process usually involves analysts to study the structural requirements according to the components interrelationships and eliminate redundancies. In the design phase, analysts design all aspects of the system, provide physical specifics on the system from input and output screens to reports, databases, and computer processes.1 In the effort to improve the systems analysis and design processes, different approaches have been developed. The traditional waterfall approach focuses on compartmentalizing project into several phases. The agile approach focuses on self-adaptive processes with an emphasis on individual talents. The object-oriented approach focuses on combining data and processes into objects and shares the iterative development approach of the agile method. These approaches all have different advantages and disadvantages in a way that they could be used to fit and optimize different kinds of projects.
This structured approach looks at the system from a top-down view.2 It is a formalized step by step approach to the systems development lifecycle (SDLC) which consists of phases or activities. The activities of one phase must be completed before moving to the next phase. At the completion of each activity or phase, a milestone has been reached and a document is produced to be approved by the stakeholders before moving to the next activity or phase; painstaking amounts of documentation and signoffs through each part of the development cycle is required. 1,3 "The center of the structured approach is the process model, which depicts the business processes of the system, and the primary model that presents the processes is the data flow diagram."4
The agile methodologies emphasize focus on people; on individuals rather than on the roles that people perform. Unlike the waterfall development methodology, agile forgoes the documentation but is initially difficult to adapt by adding many new facets to the development model that confuse people.3 "Agile methodologies attempt to capture and use the dynamics of change inherent in software development in the development process itself rather than resisting the ever-present and quickly changing environment."5Traditional methods demand complete and accurate requirement specification before development; agile methods presume that change is unavoidable and should be embraced throughout the product development cycle.6 The individuals who fill those roles are more important than roles that people fill. Fowler believes that each talented individual bring something unique to the development team and disagrees with the application of engineering principles that viewed people as interchangeable units.
In another article published by
Ambler, he summarized a few key lessons learned when doing internet based
development via agile methods, these lessons are:7
-People matter
-You don't need nearly as many documents as you think
-Communication is critical
-Modeling tools aren't nearly as useful as you think
-You need a wide variety of modeling techniques in your intellectual toolkit
-Big upfront design isn't required
-Reuse the wheel, don't invent it
Self-adaptive software development processes is promoted by the agile methodologies. The process used to develop the software is expected to be refined and improved over time. Improvements are done through a review process associated with the compilation of iterations. Agile methodologies are not for every project. Fowler recommends an agile or adaptive process if your project involves: unpredictable or dynamic requirements, responsible and motivated developers, and customers will understand the process and will get involved.1
The object oriented approach looks at a system from a bottom-up view. It combines data and processes (methods) into objects. Within an information system, objects could be customers, suppliers, contracts, and rental agreements. A set of diagrams or models is used to represent various views and functionality of the system and is commonly known as Unified Modeling Language (UML). The OO approach later becomes known as the unified process when these models are used along with a particular method of systems development. Unified process is an iterative and incremental approach to systems development.4 The goal of OOAD is to improve system quality and productivity of systems analysis and design by making it more usable. Objects are grouped into classes to share structural and behavioral characteristics. OOAD also incorporates the use of inheritance; it allows the creation of new classes that share the characteristics of existing classes. Similar to the agile methodologies, the object-oriented approach to systems development is similar in the way of iterative development approach.1 In the analysis phase, object-oriented models are used to fill the gap between a problem and the solution. The aim, in essence, is to transform the use cases into analysis model to realize the associated goals.
In Hsueh's study, such analysis model is built through six steps incrementally, and his research team examined these steps by use case description to identify possible participating objects based on some heuristics. To proceed into the design phase, object oriented design involves a transformation process that transforms real-world concepts into a software model that provides solution model. The transformation process is to be achieved by taking the following design issues into consideration:8
-Basic issue: concerns basic, common and recurring problems when designing a system. E.g: decomposes system, to allocate objects, to dispatch control process, and to compose components
-Quality issue: concerns how to enhance nonfunctional requirements
-Tradeoff issue: concerns how to resolve conflicting requirements
It is also important to note that
the OO model has no well accepted standards. Therefore, these models very
significantly from one development to another, some variability in the analysis
models' content and structure is unavoidable.9
Figure 1-1
Fig
1-2
Comparing between traditional methods and the object oriented method, the phases of those approaches do not match, because the unified approach is a two-dimensional model as compared to the traditional one-dimensional waterfall model. For the unified process model, all phases of the SDLC are visited on to the developers satisfy the requirements in each increment. In each increment, "activities of one phase predominate over the others ¡V causing the systems development effort to move from the inception to elaboration, from elaboration to construction, and from construction to transition." 4Comparing between agile methods and traditional methods, as demonstrated in table 1-1, agile methods seems to be more suitable for small IS projects, and traditional method seems to be more suitable for larger scale projects.
Wang's study showed that there was
a longer learning curve associated with object-oriented analysis but, once
learned, the object-oriented analysts performed better than the data flow
diagram subjects in analyzing a system.10However, comparing between
the three approaches: traditional, agile, and object oriented approach, there
is no clear answer as which is the best approach since they all have different
advantages and disadvantages. Depending on the need, and willingness of
businesses to make investment on their particular project, it is difficult to
tell which approach would bring the best outcome. In all, SDLC's can be viewed
as tools, similar to programming languages, databases, middleware frameworks or
any other piece of technology. Whether it works or not depends on your company,
your people, your processes and procedures, your history, and everything else.3
The approaches of SDLC discussed above all have different ways of implementing and process details. The traditional approach is perhaps the most straightforward method for systems analysis and design, however, for even smaller projects; agile methods may be more desirable. However, if the project's goal is more heavily emphasized on project scalability and component reusability, object-oriented approach could be the best choice.
References
Figures
1-1: Hoffer, J., George, J., & Valacich, J. 2006.Modern systems analysis and design 6th. Prentice Hall: U.S.A.
1-2: Mohammad, R. (2006). Dilemma between the structured and object-oriented approaches to systems analysis and design. The Journal of computer information systems: 32-42.
Tables
1-1: Hoffer, J., George, J., & Valacich, J. 2006.Modern systems analysis and design 6th. Prentice Hall: U.S.A.
Texts:
1. Hoffer, J., George, J., & Valacich, J. 2006.Modern systems analysis and design 6th. Prentice Hall: U.S.A.
2. Harris, A., Lang, M., Oates, B,. & Seau, K. 2011. Systems analysis & design: an essential part of IS education. Journal of information systems education: 241-248.
3. Gabe, M. 2011. Revision proven development processes. Mortgage banking 71(12): 88-89.
4. Mohammad, R. 2006. Dilemma between the structured and object-oriented approaches to systems analysis and design. The Journal of computer information systems: 32-42.
5. Erickson, J. 2005. Agile
Modeling, Agile Software Development, and Extreme Programming: The State of
Research. Journal of database management: 88-100.
7. Ambler, S. 2002. Lessons
in agility from internet-based development. IEEE software: 67-73.
8. Hsueh,
N., Kuo, J., & Lin, C. 2009. Object oriented
design: a goal-driven and pattern-based approach. Softw
syst model: 8:67-84.
9. Briand, L., Labiche,
Y. 2002. A UML-based approach to system testing. Softw syst model: 1:10-42.
10. Wang, S. 1996. Two MIS analysis methods: an experimental comparison. Journal of education for business: 136.