The Evolution of Software Process Models: From the Waterfall Model to the Unified Modelling Language (UML

International Journal of Information Technology & Systems, Vol. 3; No. 2: ISSN: 2277-9825 (July-Dec. 2014)

The Evolution of Software Process Models: From the Waterfall Model to the Unified Modelling Language (UML) Saad Subair College of Computer and Information Sciences, Princess Nourah bint Abdulrahman University, Riyadh KSA Email: [email protected]

Abstract: Software process models are integral constituents of system lifecycle models that were initially proposed to follow a structured approach to building an improved or a new system. They are the core processes of the software engineering area. This work is an attempt to study the different software process models. The advantages and disadvantages of every model have been analyzed and the performance of every model has been evaluated. The main critics to the present software systems models are that they cannot be built with mathematical certainty hence they are not empirical models. Many models like Waterfall model (sequential approach), Incremental Model (incremental approach), Spiral Model (evolutionary approach), Formal Methods Model (specialized approach), Extreme Programming Model (agile approach) and Rational Unified Process (RUP) are studied in a comparative and differentiative manner. The evolution of these development methods has been uncovered in this study.

Keywords: Software Development Process, SDLC, software process model, UML, software lifecycle, Software Engineering

Accepted On: 31.10.2014

1. Introduction Software consists of codes instructs to the hardware as well as the documents and programs supporting the whole software engineering process and procedures. Nowadays, a considerable number of enterprises produce software programs in large scale and with high qualities. The ultimate goal of software engineering is to generate software products of high functionality and quality [1, 2, 3, 4, 5, 6, 7, 8]. The conventional activities of problem solving in software development consists of: Analyze the problem, Plana solution for the problem, Code the solution, Test the coded program, and Maintain the program [1]. These activities have to be broken into smaller sub-activities or phases for complex and large systems [1, 2, 5, 6].Maintenance in software development is very crucial. It is very likely that some bugs of the system, which were not found during the software testing phase, may be found by the users. Also, over time, as newer technologies and platforms are developed, programs need to accommodate these changes. It is important to provide new and additive features to the program or system on specific intervals and make it compatible and up to date with various latest platforms and technologies. This is also known as versioning [9].There are various www.gtia.co.in

different approaches and methodologies to developing software. In this study, they are discussed as follows: 1.1 Linear or Sequential Approach In the linear or sequential approaches program developments or projects are sequenced into a set of steps or phases that are completed serially and typically span from the determination of user needs to the validation that the developed solution satisfies the user needs. Progress is carried out in a linear fashion enabling the passing of control and information to the next phase when pre-defined phases completed. This approach is highly structured and allows extreme control over the software processes but is characterize by its resistant to change and the need for corrections and iterations. Examples of this approach are: waterfall model (Fig. 1) and the V-process model (Fig. 2) [1, 2, 3]. The Waterfall Model: The waterfall model is the classical or conventional model of software process model and software engineering in general (Fig. 1). This model is one of the oldest models and is widely used in government projects and in many major enterprises. This model emphasizes planning at early stages.The documentation and planning properties of this model make it works well with projects with high functionality control standards. The original 7


waterfall lifecycle consists of several distinct stages, as shown Figure 1. The model begins with system requirements and continues with the design, implementation or coding, testing, deployment and maintenance. The waterfall model serves as a baseline for many other lifecycle models [1, 2].

projects rarely follow the sequential approach [1, 2]. The V-process model is a variation of the waterfall model and takes a typical V shape instead of straight line. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing as shown in Fig. 2.

Fig. 1. the Traditional Waterfall (green lines) and Waterfall with iteration (blue lines)

The advantages and disadvantages of the waterfall model are shown in Table 1. However, the major advantage of this mode is that it is easy to understand since it follows good development habits, while the major disadvantage is that real

Fig. 2. The V-process model. A modified waterfall model with testing at each phase

Table 1. Advantages and Disadvantages of different approaches of software development

Model Waterfall Model

Incremental Model

Spiral Model

www.gtia.co.in

advantages 1. Easy to understand and implement 2. Reinforces good habits: define-before-design and design-before-code. 3. Identifies deliverables and milestones 4. Works well on mature deliverables 1. Divides project into smaller parts 2. Creates working model early 3. Feedback from one phase provides information for the next phase 4. Very useful when more staffing is unavailable 1. Designed to include the features form Waterfall Prototyping Model 2. Good for large mission-critical projects 3. Introduces risk assessment new component

best and and as a

disadvantages 1. Real projects rarely follow sequential approach 2. Uncertainty at the beginning of the development 3. No working version of the system until very late 1. Users need to be actively involved in the project. 2. Communication and coordination skills are central process 3. Informal requests for improvement for each phase may lead to confusion 4. It may lead to scope creep 1. Can be a costly model to use 2. Risk analysis requires specific expertise 3. Project’s success is highly dependent on risk analysis phase 4. Doesn’t work well for smaller projects 8


4. Similar to prototyping model XP and Agile

1. Light methods suit small to medium size projects. 2. Iterative. 3. Produces good team organization. 4. Emphasizes final product. 5. Test based approach to requirements and quality assurance.

1.2 Incremental Approaches The Incremental Model: Incremental approaches emphasize phased development by offering a series of linked processes known as increments, releases, or versions as shown in Fig. 3. Work on different parts and phases, is allowed to overlap throughout the use of multiple sub-cycles running in parallel. Each cycle adds additional functionality and capability. Delivery of increments is done as calendar time progresses. There is a considerable project management skill in this approach. Incremental approaches are mainly useful when there are not enough personnel to complete the project and when the requirement specification is not complete [2, 10, 11].

Fig. 3. The Incremental Model with four increments

The main advantage of this model is that it divides the project into smaller parts. It is useful when enough personnel are not available. The main disadvantage is that this model needs communication and coordination skills. Also this www.gtia.co.in

1. Difficult to scale up to large projects 2. Needs experiences and skills 3. Programming pairs is costly. 4. Test case construction is a difficult and specialized skill.[1]

type of development may lead to scope creep. Table 1 shows the advantages and disadvantages of this model in details.

1.3 Evolutionary Approaches Evolutionary approaches recognize the great degree of uncertainty embedded in certain projects and allow developers and managers to execute partial versions of the project while learning and acquiring additional information and gradually evolving the conceptual design [2]. The initial implementation benefits from exposure to user comments and feedback leading to a series of iterations. Final goals are thus allowed to evolve based on the discovery of user needs and changes in expectations along the development passes. Projects in this category are likely to be characterized by a high degree of technological risk and lack of understanding of full implications by both stakeholders and developers. Evolutionary approaches are particularly effective in change-intensive environments or where resistance to change is possibly to be strong [2]. The Spiral Model: The spiral development model is a risk driven process model. It has two main features: one is cyclic approach for incrementally growing the system extent of definition and implementation while decreasing its degree of risk [11]. The other is a set of anchor-point milestones for ensuring the stakeholder commitment to feasible and satisfactory system deliverables [2]. The spiral model is similar to the incremental model, with more emphases on risk analysis. It has four phases: Planning, Determine Objectives, Risk Analysis, Development and Evaluation as shown in Figure 4.A software project repeatedly passes through these phases in iterations (called Spirals in this model). In the baseline spiral, starting in the planning phase, requirements are gathered 9


and risk is assessed. Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. The program software is produced in the engineering phase, with its testing process. The evaluation phase allows the user to evaluate the output of the project to date before the project continues to the next spiral [1, 2]. The main advantage of spiral model is that it introduces risk analysis in the development of large software. The disadvantage is that the cost can be very high as well as risk analysis need special expertise. Table 1 shows the detailed advantages and disadvantages of this development process model.

Fig. 5. The Agile Development method There are many types of agile development; Scrum is the most popular one due to its simplicity and flexibility. It emphasizes empirical process control of the project. Scrum uses real data and does not use forecasting or guessing to plan and schedule next phases or releases [15]. Agile development is particularly useful in environments that change steadily and impose demands of early or partial solutions (Table 1). Agile approaches support the notion of concurrent development and delivery within an overall planned environment.

1.5 Extreme Programming Fig. 4. The Spiral Model with its four phases

1.4 Agile Approaches The agile development approaches are typically concerned with maintaining active user involvement, developing small incremental releases and iterations, and testing is integrated throughout the project lifecycle by conducting it early and often (Fig. 5). Agile development is achieved through regular cadences or strokes of work, known as sprints or iterations that must present a product increment at its end [11, 12, 13, 14].

www.gtia.co.in

Extreme Programming (XP) is mainly initiated for object-oriented projects development using teams of programmers in one location [2, 11]. The methodology is largely based on five underlying principles: communication, simplicity, feedback, courage, and respect [15, 16, 17]. It is an approach based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pair wise programming as shown in Fig. 6 [15, 16, 17]. The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

10


a software engineer to specify, develop and verify a computer-based system by applying a rigorous mathematical notation. A variation on this approach, called clean-room software engineering, is currently applied by some software development organizations [2, 20, 1]. When formal methods are used during development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. Ambiguity, incompleteness and inconsistency can be discovered and corrected more certainly by applying mathematical analysis [2, 20]. Figure 6: The Extreme Programming (XP) development method with its planning and feedback loops illustrated The main advantages of these approaches Agile and XP are that they suit small and medium size projects and testing is integrated in development. The disadvantages are: difficult to implement in large project, in addition to that programming pairs is costly to implement [13, 14, 16, 17]. Table 1 explains these features in details. Theoretically, each of the approaches described above seems to have clear benefits as well as some drawbacks. However the diversity of different approaches leads to a problem when selecting the most suitable approach for a project. It needs high managerial skills to choose the most appropriate approach. It is the responsibility of the leading programmer or the project manager to choose the most appropriate model for a project. Table 2 explains the appropriateness of these models concerning some characteristics or parameters of software developments. There are some other methods and approaches of software developments like the Formal Methods model and the Component-based software engineering (CBSE) model.

2.1 Component-Based Development Component-based software engineering (CBSE) emerged in the late 1990s as an approach to software systems development based on reusing software components. Component here means a unit or a part of a model. It is the process that emphasizes the design and construction of computer-based systems using reusable software components or simply building software system form pre-existing components [1, 2]. CBSE life cycle is shorter as compare to waterfall model and it is a less expensive development approach. The maintenance of CBSE is easily accomplished by replacing or introducing a new component to the system [7]. The various process models discussed above can be summarized as follows in this Table 2:

2. Formal Methods The formal methods model encompasses a set of activities that leads to formal mathematical specification of the project or the computer software to be developed. Formal methods enable Table 2: Comparison between different software development models Model/Features Waterfall Incremental Spiral Agile Requirement Specifications www.gtia.co.in

Early stage

Early stage

Early stage

Frequent change

RUP Early stage

11


Resource Control Complexity

Yes

Yes

Yes

Simple

Intermediate

Risk

High

Low

Intermediate Complex Simple clear lower lower lower

User Involvement

Intermediate

High

High

Late stage

Flexibility

Early stage No

Less Flexible

Yes

In between

Cost

Low

Low

High

Reusability

Limited

Yes

Yes

Highly Flexible Very High Yes- Use Case

Understanding Requirements Possibility of Success

Yes

Yes

No

No

Yes existing classes Yes

less

less

In - between

high

high

Overlapping Phases

No

Yes

Yes

Yes

Yes

Implementation time

Long

In between

less

less

less

Special managerial Skills

No

No

Yes

Yes

Yes

Early Delivery of product in time Request for Changes at any time during development of product Quality of product is a major concern Development pattern

No

No

Yes

Yes

Yes

No

Yes-slow

Yes

Yes

Yes

No

Yes-low

Yes

Yes

Yes

Sequential

Iterative

Iterative

Development time

Longer

Sequential with Iterative iteration Medium Short

Shorter

Short

Yes-low

Yes

Yes

Yes

Medium

Small

Small

Any

Quality of product is a No major concern Large Size of Project

2.2 Rational Unified Process (RUP) Rational Unified Process (RUP) is an object-oriented development that provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget [18, 19].The Rational Unified Process enhances team productivity, by providing every team member with easy access to a knowledge base with guidelines, templates and tool mentors for all critical development activities. The Rational Unified Process activities create and www.gtia.co.in

No

Yes and

High –

maintain models rather than focusing on the production of large amount of paper documents [4, 20]. As shown in Fig. 7, RUP divides the development process into four distinct phases that each involves business modeling, analysis and design, implementation, testing, and deployment. The four phases are: Inception, Elaboration, Construction, and Transition [4, 20].The Rational Unified Process has become a guide for how to effectively use the Unified Modeling Language (UML). The UML is an industry-standard language that allows to clearly communicate requirements, architectures and designs. The UML was originally created by the 12

International Journal of Information Technology & Systems, Vol. 3; No. 2: ISSN: ISSN 2277-9825 9825 (July-Dec. (July 2014)

Rational Software, and is now maintained by the standards organization rganization Object Management Group (OMG) [21, 22].

Fig. 7. The Four phases and their distributions and iterations of Rational Unified Process (RUP)

2.3 Modelling and Unified Modelling Language (UML) A model is a simplification of reality. A model provides the blueprints of a system. Every model may be expressed at different levels of precision. The best models are connected to reality. Modeling is a fundamental step of all the activities of developmentt and deployment of good software. Models are built for so many reasons, to communicate the anticipated structure and behavior of our system to others, to visualize system architecture, to better understand our system, and to manage risk. Modeling is a pro proven and well-accepted accepted engineering technique. Success of software depends mainly on good modelling [23, 24]. In software development process, the two most common ways of building models are: algorithmic perspective and object-oriented object perspective. The traditional tional view of software development is an algorithmic perspective approach. In this approach, the main building block of all software is the procedure or function. In real life, as requirements change and the system grows bigger, systems built with an algorithmic rithmic approach will be difficult to maintain. The current view of software development is an object-oriented oriented perspective. In this approach, the main building blocks of all software system systems are the objects and classes. The purpose of the Unified Modeling Language is visualizing, specifying, constructing, and docum documenting object-oriented systems. UML is described as a language in a sense that a language provides a vocabulary and the rules for combining words in www.gtia.co.in

that vocabulary for the purpose of communication. n. A modeling language is a language that its vocabulary and rules focus on the conceptual and physical representation of a system [23, 24, 25]. A software process is the group of activities that guide to deciding what to produce, what workers to use, and d how to use those objects to measure and control ontrol the development process. There are four kinds of relationships in the UML: 1. Dependency, 2. Association, 3. Generalization, Generalization and 4. Realization. diagrams UML includes nine essential diagrams: 1. Class diagram 2. Object diagram 3. Use case diagram 4. Sequence diagram 5. Collaboration diagram 6. Statechart diagram 7. Activity diagram 8. Component diagram 9. Deployment diagram The UML is essentially process-independent, independent, in a sense that it is not tied to any particular software soft development life cycle. However, to get the most from UML, the process should: use case driven, architecture centric and Iterative or incremental development. Fig. 8 shows the different diagram of UML.

Fig. 8. Diagram Types in the Unified nified Modelling Language (UML)

3. Conclusions Various models and approaches of system development has been reviewed and discussed in this study. Each model has its own advantages and disadvantages. The trends of modern models of development are towards getting the advantages and minimizing the disadvantages of each model. Project management skills are needed in several models of development. 13


Formal methods of development are used for some critical system by applying some mathematical models. Component based development is adopted by many enterprises for its ease of implementation and short lifecycle. Software development methodologies evolved from the very rigid waterfall approach to the Agile and Extreme programming approach. The UML is lastly evolved as a manifest for developing complex and professional software. It is the responsibility of the project manager to decide which software mode suits his project.

Acknowledgements The author would like to appreciate the assistance rendered by the University of Princess Nourah bint Abdulrahman, Riyadh, KSA regarding this research work.

References: [1] Sommerville,

I., Software Engineering, Addison-Wesley, Harlow, England, 2010. [2] Pressman, R. S. , Software Engineering: A Practitioner’s Approach, New York: Mc Graw Hill International Ltd, 2010. [3] Ivar Jacobson, Magnus Christerson, PatrikJonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley,1992, 582p. [4] Larman, C. &Basili, V. R., Iterative and Incremental Development: A Brief History. IEEE Software, Vol. 20, pp. 47-56, 2003. [5] Highsmith, J. A., Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing. New York, NY. 358 p, 2000. [6] Humphrey, W. S., A Discipline for Software Engineering. Addison Wesley Longman, Inc. 242 p, 1995. [7] Mili, Mili, Yacoub, Addy Edward, Reuse-Based Software Engineering, AWiley-Interscience Publication, John Wiley & Sons, INC.,2002. 540 p. [8] William Harrison, Harold Ossher, PeriTarr, General Composition of Software Artifacts, Proceedings of Software Composition Workshop, March 2006, Springer-Verlag, LNCS 4089,pages 194-210 [9] McCarthy J., Dynamics of Software Development. Microsoft Press, 1995. [10] Abrahamsson, P., Salo, O., Ronkainen, J. &Warsta, J., Agile Software Development Methods: Review and Analysis. VTT www.gtia.co.in

Publications 478. VTT Electronics. Espoo. 107 p, 2002. [11] Lycett, M., Macredie, R. D., Patel, C. & Paul, R. J., Migrating Agile Methods to Standardized Development Practice. Computer, Vol. 36, 6 (6), June, pp. 79-85, 2003. [12] Larman, C., Agile and Iterative Development: A Manager’s Guide. Pearson Education, Inc. Boston. 342 p, 2004. [13] Beck, Kent; et al., Manifesto for Agile Software Development. Agile Alliance, 2001. Retrieved 30 September 2014. [14] Williams, L. & Cockburn, A., Agile Software Development: It’s about Feedback and Change. IEEE Computer Society, Vol. 36, 6 (6), June, pp. 39-43, 2003. [15] Schwaber, K., Scrum Development Process. In: The proceedings of the OOPSLA’95 Workshop on Business Object Design and Implementation. Springer-Verlag. Pp. 117-134, 1995. [16] Beck, K., Embracing Change with Extreme Programming. IEEE Computer, Vol. 32, 10 (10), pp. 70-77, 1999. [17] Beck, K., Extreme Programming Explained: Embrace Change. Addison Wesley Longman, Inc. 190 p, 2000. [18] Philippe Kruchten, Rational Unified Process: An Introduction, Addison-Wesley, 1999. [19] Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999. [20] Sanjana Taya and Shaveta Gupta, Comparative Analysis of Software Development Life Cycle Models, IJCST Vol. 2, Issue 4, Oct . - Dec. 2011 [21] Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language 1.3, White paper,Rational Software Corp., 1998. [22] OMG, Business Process Model and Notation (BPMN), 2011, version 2.0. [23] White SA, Miers D. BPMN – Modeling and references guide. Future Strategies Inc., Lighthouse Pt; 2008. [24] Mendeling J, Reijers HA, Van der Aalst W. Seven Process Modeling Guidelines (7PMG); 2009. [25] Jendrik J., Uwe A. Concern-Based (de)composition of Model-Driven Software Development Processes, Model Driven Engineering Languages and Systems 2010 p.47-62

14

The Evolution of Software Process Models: From the Waterfall Model to the Unified Modelling Language (UML

Recommend Documents