1.0 Introduction

System analysis methodology has a long developing history and each methodology tool has its own characteristics.This paper is specified on the research for methodology developing history and aim to This paper is specified on the research for methodology developing history and aim to identify the difference between different methodology tools and have some comments for future system design methodology development.

2.0 Background of methodology

The methodology can be refers to a set of solution for the specified problems.(Baugh 1990) However specified on system analysis, the methodology can be referred to a standard set of steps named a systems development methodology, developed by the organizations and aimed to develop and support their information system. (Fowler, 2003)  It also can be descried as a modern approach to systems analysis and design. The formation of system development methodology should be contributed to development of analysis and design of computer-based information system. The formation of system development methodology can be concluded as periods which should be demonstrated below

In 1950s, in this period, computers were considered as critical resources. Because of they have characteristicsthat large, expensive, and unreliable, the focus are on the automating the existing process, on the conserving enough memory for data storage and on the processes the software performed. (Hoffer,George&Valacich, 2012) 

In 1960s, the advanced technology had the innovation of mini-computers, which are smaller, faster and less-expensive became possible, it can be seen as the start of the software industry. (Fowler, 2003) 

In 1970s, because of the cost consideration, to customize information systems for every application became rare possible to implement. The early management systems which using the hierarchical and networks model appears and it shifts the focus on the system development from processes first to data first. (Hoffer,George&Valacich, 2012) 

In 1980s, the microcomputers had been widely accepted, the focus on system development are a “transition from builder to integrator.” (Fowler, 2003), in this period, the concept of integration appeared, it can be discovered by  the operation system appearance, organizations’ activities of developing more graphics applications, developing less software in-house and bringing “relatively more from software vendors.” (Hoffer,George&Valacich, 2012) 

In 1990s, the concept of “integration” became the mainstream, the visual programming environments are widely used by developer such as Visual Basic, PowerBuilder etc.  The companies intended to purchase the entire information system from system companies such as SAP,AG or Oracle. The systems became large and complex which include a series of independent system modules.  In later 1990s, the system development focus on the internet. (Hoffer,George&Valacich, 2012)

In recent, as the more focus on “developing systems for the internet and for the firms’ intranets and extranets.” (Fowler, 2003), the in-house application developments are no longer the options for the companies, the outsourcing for system tools became the priority consideration.
The system development methodologies are informed at that background, for the reason that most organizations discovered that using a standard set of steps are beneficial.

3.0 Systems development life cycle
Because the development of information system can be considered as a progress, similar as general products which have the introduction, growth maturity and decline periods. (Figure 1) The systems development life cycle have several phrases to present the system’s analysis and effort progress.

Figure 1 general products life cycle
(Source link: http://www.consumerpsychologist.com/cb_Diffusion_of_Innovation.html)

Figure 2 The system development life cycle
(Source link: http://www.umsl.edu/~sauterv/analysis/newlifecycle/sdlc.gif)

As Figure2 demonstrated, the system development life cycle can be concluded as five “planning,analysis,design,implement and maitenence(support)”. Planing can be considered as the firse phase in SDLC, as intitial study of system development. In this phase, the priority is to identify the needs for future deisgned system. The reuqired information for system design can be obtained by reviewing the orgnazation needs as whole. The information can be sourced from current procedures’ problems, furture needs for additional tasks or the effient uitilization on the exsiting IS system. The shcheule for system development process and the resources distribution plan are set, the outcomes of each processes should also be studied. Another important fator during this phase is to determine the scope of the system, it is benefical for having a detailed further develpoment plan to evaluate return of investment. “analysis” is the second phase and can be detailed into two subphases,the first subphase is to determine the customer’s needs,the second subphase is to structure the information and determine the necessary harware and software for the designed system. The third phase is design part, in this part, the information in first two phases should be transformed to logical and then phsycial design. The logical design refers to the processes of design without “specific hardware and software” (Hoffer,George&Valacich, 2012),  it should be concentrated on business aspects of the system. The  phsycial design is to implement the logical design’s thinking in plan level.  In the phase, some detailed and specified information about building the final system should be considered such as programming languages,database and hardware platform.The ourth phase is implementation , in this phase, the physical design’s  specification should be converted into programmes, the process includes coding, testing and installation. Coding referes to programmes writing, tesing refers to testing the programmes in order to “find and correct errors” (Hoffer,George&Valacich, 2012) installation means install the application,have the application become parts of the system.  The maintanance phase is not only to have the system running properly but also to consider the possbility of updating the functions of system. The summaries of system develpoment life cycle should be represented in figure 3. However ,  there are some current practises integatered the five phases as four phases which referes to analysis,design,code and test. These four phases can also be seen as the core of the system.

Figure 3  Five phase of System Develpoment Life cycle
(Souce link http://www.softwaretestingdiary.com/2010/08/system-development-life-cycle-sdlc.html)

4.0 Traditional waterfall SDLC

The traditional waterfall SDLC (Figure 4)can be described as the “programmed” and “none spaces “ procedure, it have the phases of system development life cycle into orders, the activities which belongs to one phase should be completed before switch to the next step.  It has some limits for the following:

• While reach the new phase, it seems hard to go back to the pervious phases. It means it must have some advancing view on system design for catching up the speed of technology development and organization development.  However it won’t be beneficial when the circumstance changes because it lacks flexibility.  Although the organization forces to change the system, the cost should be considerable high because it means develop another new system.
• It defines the roles of users narrowly. (Kay 2002) User roles are determined in the early phases which mean there is no room for changing while business conditions change.  
• The priority for waterfall approach is to meet considerable numbers of deadlines and tasks accomplishment.  It means the feedback for process may be ignored which is beneficial to have a good analysis and design.  If the system is not fit the customer’s needs, the maintenance cost should be considerably high.

Figure 4 Tradtional waterfall SDLC
(Source link http://www.umsl.edu/~sauterv/analysis/termpapers/f11/jia.html#ref3)

5.0 Approaches to improve Tradtional waterfall SDLC
In order to improve the traditional waterfall SDLC, two methodologies should be introduced which refer to “AGILE METHDOLOGIES” and “Object-oriented analysis and design”

5.1 Agile methodologies
The Agile methodologies can be described as a group of systems analysis and design approaches.  According to Fowler(2003), , the agile methodologies have more differences while be compared to the traditional waterfall methodology

 Table 1  The Difference between  Traditional waterfall methodology and Agile methodology

It being developed “because the software development methodologies adapted from engineering generally do not fit with the real-world software development” . (Hoffer,George&Valacich, 2012) ,In the engineering view, the requirements of the project seem to be well understood in the first place. When the work of project’s design part done, the remaining parts of the whole project become very predictable.  The whole project is more focus on the construction. However the further changing about the project becomes challenge because the waterfall methodologies have limited spaces for significant changing according to its procedure structure.  For software design, the waterfall methodologies may not be suitable because the requirements are rarely well understood in the first place, and changes occur during the lifetime of whole project.  “Construction may account for as little as 15 percent of the total project effort, with design constituting as much as 50 percent” (Hoffer,George&Valacich, 2012) 

Agile methodologies focus on people rather than the roles they perform. (Hoffer,George&Valacich, 2012)  It means not roles decide people to play, but people select their roles to play. “agile forgoes the documentation but is initially difficult to adapt by adding many new facets to the development model that confuse people”( http://www.umsl.edu/~sauterv/analysis/termpapers/f11/jia.html#ref3). The Agile methodologies have “a self-adaptive software development” (Fowler, 2003) , the process aim to improve and refine the software which can adopt the changing environment. People “are characterized by short iterative cycles of development driven by product features, periods of reflection and introspection, collaborative decision making, incorporation of rapid feedback and change, and continuous integration of code changes into the system under development.”  The detailed information between Agile methodologies and traditional waterfall methodologies should be represent in figure
(http://www.umsl.edu/~sauterv/analysis/challenges_of_migrating_to_agile_methodologies.pdf)

However the Agile methodologies have specified requirements for project, the project may have the characteristics of “unpredictable or dynamic requirements, responsible and motivated people and customers who understand the process and will get involved” (Hoffer,George&Valacich, 2012)  it means Agile methodologies have the more requirements on people’s social skills than on technical skills. Many issues can influence the outcome while using the Agile methodologies such as management skill, organization culture, social structure of organization, interactions among the team and team members etc.  The Agile methodologies have the challenges for “changes” which include changes in the attitude of each group member –from “command-and control management to leadership-and-collaboration.” Etc , changes in the operation- from much documentation to particularly documentation etc, changes in organization view “from certain and predictable to uncertain and unpredictable” etc , changes in technology tools “from pervious to recent”etc and companies should have investment.

Figure 5 Five Critical Factors that Distinguish Agile and Traditional Approaches to System Develpoment
Hoffer, J,A. , George, J,F., and Valacich, J,S. (2012)  Modern Systems Analysis and Design, 6th edition, New Jersey: Prentice Hall ppt 21

5.2  Object oriented analysis and design (OOAD)

The Object oriented analysis and design (OOAD) combines data and processes into objectives. Each objective represents a real thing in the progress of information system development, it could be “customers, suppliers, contracts, and rental agreements.”
(http://www.umsl.edu/~sauterv/analysis/termpapers/f11/jia.html#ref3)

It can be considered as another form of “Block design theroy” (David 2000)which considers system as the composition of several entities in which each entity has its specific characteristic or function. The progress of system design can be seen as the progress of integrating entities. It has the system elements more reusable in order to increase the productivity of the system analysis and design.  The OOAD also has the characteristic of “inheritance”, it being represented by the use of object classes. It allows the “groups of objects sharing structural and behavioral characteristics.” (Fowler, 2003), for instance, for the group of classes named “assault rifle”, you can use some of its characteristics to define “AR-15 series” such as “Weight, Cartridge, Rate of Fire, Effective range, Country authority” , however “AR-15 series” is more specific, it can be seen as the subset of “assault rifle”. “The object-oriented approach to systems development shares the iterative development approach of the Agile Methodologies, one of the most popular realizations of the iterative approach for object-oriented development ” named Rational Unified Process(RUP) which has four phases “inception, elaboration, construction and transition”. The description for each phase can be described as follows:

• In the inception phase, the scope of the system should be defined, after that, the feasibility of the project, use requirement should be identified and develop a software implementation plan.
• In the elaboration phase, the requirements should be detailed and a base-line architecture should be established.
• In the construction phase, the software is coded, tested and documented and this phase may be the most resources intensive.
• In the transition phase, the system is deployed and the users are rained and support.

These phases can be further separated as parts, for the future system development, these parts can be seen as raw material or mature entities for the system construction. however, there is challenges for OODA, it has no well accepted standards, “some variability in the analysis models' content and structure is unavoidable.”
(http://www.umsl.edu/~sauterv/analysis/termpapers/f11/jia.html#ref9)

6.0 Thinking about methodologies improvement

As Agile methodologies and Object oriented analysis and design methodology demonstrated before, the Agile methodologies can be seen as solution targeted on the tradition waterfall life cycle’s limitation – less of flexibility and not focus on people but focus on roles. Object oriented analysis and design methodology attempt to modular the system development process and to have the modular more easily to recycle. However there are still challenges for both of the methodologies. For the Agile methodologies, the issues about management and organization, people, process-related and technology should all be concerned because each issue has strong relationship to the success of the project.  For OOAD, the variability of further system can be considered as a considerable challenge.
There should be some solutions to improve the methodologies which demonstrated before, some hypothesizes should be demonstrated below
DIY system development and open-source system development
As the methodologies demonstrated before, the efficient system development should have the characteristic as follows:

• More achieved business’ goals in another words, more satisfy customer needs
• More short design, analysis, coding and testing period
• More easy to implement and more easy to use
• More efficient on resources utilization
• Cost reduction for each design phases.

The pervious methodologies emphasized the interaction among the analysts, designers and customers. However, the general procedure is “analysts ask, customers speak, analyst listen, then implement” , the problems can described as figure 6

Figure 6 system development life cycle problems

(Source link: http://www.umsl.edu/~sauterv/analysis/is6840start.html)

The combination of designers and customers may be the option to solve the problem, as the theories demonstrated before, the traditional life cycle have the disadvantages however it has the characteristics of predicable, mature and standardization, it means they can be the producers who provide the matured and detailed small entities for the whole system development.  However the entities should have the following characteristic:

• Each entity should has its detailed function and attribute
• The entity should have highly compatibility to the system or the entities they will adapt to.
• More easy to be understand  and to be integrated as a system
• Highly cost efficiency – can be achieved as multi--used entities

The Future Combat systems’ program may provide some hints, in this system, the major functions in battlefield are designed as the main platform. For instance, as littoral combat ship, the ship is designed to satisfy the combat needs in the littoral zone. (http://en.wikipedia.org/wiki/Littoral_combat_ship), the customer – the navy can choose the different mission modules(entities) to satisfy the different combat needs such as anti-submarine module, surface warfare module or mine countermeasures modules, in another way to say, the customer design its own system.  The other example is FCS (future combat system) network which consists five layers “that combine to provide seamless delivery of data to forward-deployed Army units.” (http://en.wikipedia.org/wiki/Future_Combat_System) , the whole system can be seen as a large combination of systems. (Figure 7 )

Each layer has its own missions, sensor and platform layer is particle layer to achieve the objectives in battlefield. This layer’s  function can be concluded as “see first, attack first, and destroy first”, order to achieve that, sensor in charge of reconnaissance, platform in charge of technical strike. The application layer is to provide the integrated ability to achieve network-focus missions by using a common interface, it consists ten packages of software in order to satisfy the different network missions’ needs. The service layer specified on support to the whole systems including to provide “interoperability with existing systems, intra and inter platform networking (including e-mail and web services), data services and information assurance, and search capabilities”( http://en.wikipedia.org/wiki/Future_Combat_System). The transport layer provides radio and computers supports to process information and the standards layer provides the necessary governance for network implementation.

Figure 7 FCS-NETWORKING
(Source link: http://en.wikipedia.org/wiki/File:FCS-Network.png)

For business use, the cloud computing technologies provide both the methodology and the platform for system development, and because it has the characteristic of functions integration. The functions including providing platform, open source application and database service. In other words it provide the system development circumstances.( http://en.wikipedia.org/wiki/Cloud_computing), and problem of system boundary is no longer a big issue. Open source and function integration can considerable reduce the cost of system development. Just as the user of iphone do not have to know the exactly developing progress of app. The organization may not have to know the exactly system development life cycle and detailed technical issues. The analysts and technicians’ future mission should be to develop more visual and more adoptive entities.

7.0 Conclusion

As concluded, system analysis methodology is coming from the integration of system design, the traditional waterfall approach should be straightforward for system analysis and design,  for small and unpredictable project, the agile methodologies might be the first option, if the project is more emphasized on entities referenced, the object-oriented approach may be the best option. The future methodologies for system development tend to be more integration, more block and module design and more customer involved.

8.0 List of reference

Baugh, K (1990) The Methodology of Herbert Blumer: critical interpretation and repair, 1st edition, USA: Cambridge University Press.
Boeham,B. and R. Turner. (2004) Balancing Agility and Discipline. Boston:Addison-Wsley
Hoffer, J,A. , George, J,F., and Valacich, J,S. (2012)  Modern Systems Analysis and Design, 6th edition, New Jersey: Prentice Hall
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
Mohammad, R. 2006. Dilemma between the structured and object-oriented approaches to systems analysis and design. The Journal of computer information systems: 32-42.
Erickson, J. 2005. Agile Modeling, Agile Software Development, and Extreme Programming: The State of Research. Journal of database management: 88-100.
Hsueh, N., Kuo, J., & Lin, C. 2009. Object oriented design: a goal-driven and pattern-based approach. Softw syst model: 8:67-84
Wang, S. 1996. Two MIS analysis methods: an experimental comparison. Journal of education for business: 136.
Bak,D 2007. Building blocks of design. Journal of design news : 8-7-00-35
Security 1996 What is systems integration. Journal of security 18
Fowler, M., and J.Highsmith. 2001. “The Agile Manifesto”  [ONLINE] Available at
www.ddj.con/architect/184414755. [Accessed 09 November 12]

University of Southern California. 2001. general products life cycle. [ONLINE] Available at: http://www.consumerpsychologist.com/cb_Diffusion_of_Innovation.html. [Accessed 09 November 12]

 Vicki.S,2012 The system development life cycle [ONLINE] Available at: http://www.umsl.edu/~sauterv/analysis/newlifecycle/sdlc.gif [Accessed 09 November 12]

softwaretestingdiary.com, Five phase of System Develpoment Life cycle [ONLINE] Available at:
http://www.softwaretestingdiary.com/2010/08/system-development-life-cycle-sdlc.html [Accessed 09 November 12]

Vicki.S,2012 Tradtional waterfall SDLC [ONLINE] Available at: http://www.umsl.edu/~sauterv/analysis/termpapers/f11/jia.html#ref3 [Accessed 09 November 12]

 Jia-Ching Lin, 2012, Various Approaches for Systems Analysis and Design[ONLINE] Available at: http://www.umsl.edu/~sauterv/analysis/termpapers/f11/jia.html#ref9 [Accessed 09 November 12]

Vicki.S,2012 system development life cycle problems [ONLINE] Available at: http://www.umsl.edu/~sauterv/analysis/is6840start.html [Accessed 09 November 12]

Wikipedia, littoral combat ship introduction [ONLINE] Available at: http://en.wikipedia.org/wiki/Littoral_combat_ship [Accessed 09 November 12]

Wikipedia, future combat systm [ONLINE] Available at: http://en.wikipedia.org/wiki/Future_Combat_System [Accessed 09 November 12]

Wikipedia, cloud computing introduction [ONLINE] Available at:
http://en.wikipedia.org/wiki/Cloud_computing [Accessed 09 November 12]