Enterprise Systems Development: Impact of Various Software

Transcription

1 Enterprise Systems Development: Impact of Various Software Development Methodologies 1 Deepak Dahiya, 2 Pooja Jain 1 Department of CSE & IT Jaypee University of Information Technology, Solan, Indiadeepak.d@acm.org 2 Pooja Jain Department of CSE & IT Jaypee University of Information Technology, Solan, India poojaalld@yahoo.com doi: /ijact.vol2.issue4.8 Abstract Software Development Methodologies have always been the main focus in the software development life cycle of any project. Each evolutionary shift introduced new ways of thinking and viewing problems as well as introducing strengths and weaknesses in software development. However, identifying one stop solution in terms of a software development methodology for enterprise wide application development whose various sub-components or sub-stages can be best used to describe a software development scenario is still an evolving domain. This, coupled with the reality that computer science and its allied areas like information systems and information technology domains are moving forward rapidly with regards to available technologies, making it extremely difficult task for practitioners to maintain pace with the available information technologies and their application in various domains. It is to address these scenarios and probabilities that this research paper examines various software development methodologies or process models and their impact on the overall software development life cycle. 1. Introduction. Keywords: Software, Development, Methodology, Agile, Iterative, Paradigm Software Development Methodologies have always been the main focus during the software development life cycle of any project. Over the past 40 years, there have been significant paradigm shifts in software development, such as structured programming, object oriented programming and now Extreme programming and Aspect Oriented Programming. Each evolutionary shift introduced new ways to thinking and viewing problems as well as introducing strengths and weaknesses in software development. In the initial days of software development the idea of software development would not have been as documented or structured as it is done in today s software environment. In current times, the presence of software development projects without applying any kind of software development methodology presents a high probability of project failure [1]. Although we are applying software development life cycle with increased frequency to most development projects today as compared to the initial years, we are still plagued with these high failure rates. Software development can be described by the software community as a complex undertaking in ideal conditions; an undertaking that finds itself continuously at risk from internal and / or external factors which can have a significant impact on the successful completion of the project. With the maturing of the software industry, positive changes are becoming more and more visible in the various parameters like project success / failure rates, project cost overruns. This fact is no better substantiated by the Standish Group Chaos report. According to the 2009 Standish Group report, it shows more project failing and less successful projects. In other words, as per the Standish Group Report s "CHAOS Summary 2009, "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions.[2]. In other words, current software development methodologies do provide a variety of options from which software developers may chose when tasked with matching system 77

2 International Journal of Advancements in Computing Technology Volume 2, Number 4, October 2010 functionality with suitable development methodology. However, identifying one stop option in terms of a software development methodology for enterprise wide application development whose various subcomponents or sub-stages can be best used to describe a software development scenario is still an evolving domain. With the domain still in the stage of infancy, to date, best practices have not been ascertained. This, coupled with the reality that computer science and its allied areas like information systems and information technology domains are moving forward rapidly with regards to available technologies, making it extremely difficult task for practitioners to maintain pace or tempo with the available information technologies and their application in various domains. It is to address these scenarios and probabilities that this research paper examines various software development methodologies or process models and their impact on the various software development life cycle stages. The research methodology consisted of the following stages: Conducting literature and web survey, Extensive study of concepts, tools, technologies, empirical study and market relevance Analyze current state of practice and general architecture Implementation of Learning Resources System (LRS) project prototype, and finally, Prototype integration into a broader Problem domain under study / implementation. The aim of the outcome of the research work is primarily to document the relevance of current practices in software development methodologies and explore the viability of a unified software development methodology for the LRS project which will then be generalized for any domain independent enterprise application. In other words, the influence(s) that the LRS software development life cycle may impose on a given software development methodology and its implications in turn on the implementation of enterprise applications are also explored and the path to future work is highlighted. The significance of this research work can be gauged from the fact that today there are so many processes / methodologies that are being used in the IT industry that the businesses may find it difficult to integrate them with their current or future business strategy. A single unified one stop solution towards enterprise software development will serve as the right input at this juncture. 2. Background. Software-development life-cycle methodologies provide the what (processes and deliverables), how (techniques), and who (roles) for every typical role in a software-development project, such as solution architects, business consultants, and developers. Over the years, the software industry has matured to a great extent in terms of the methodologies used. Today, the industry has quite a number of established and proven software-development methodologies that cater to different kinds of project life cycles. Evolution of some of the common software development methodologies currently in use is as follows: 1970s - Structured programming since 1969 [3] 1980s - Structured Systems Analysis and Design Methodology (SSADM) from 1980 onwards [4] 1990s Object-oriented programming (OOP) has been developed since the early 1960s, and developed as the dominant programming methodology during the mid-1990s [5]. Rapid application development (RAD) since 1991 [6]. Scrum (development), since the late 1990s [7]. Team software process developed by Watts Humphrey at the SEI [8, 22]. 2000s Extreme Programming since 1999 (Agile Software Development) [9]. Rational Unified Process (RUP) since 2003 [10]. 78

3 Agile Unified Process (AUP) since 2005 by Scott Ambler [11-12]. To use these methodologies effectively, it is important to follow the processes defined in the methodologies in a consistent manner across all projects. Following the software-development processes in a consistent and accurate manner is a challenging task because: Software-development processes are complex, involving many levels of interdependent activities. Most of the processes and methodologies are available as reference documents only. It is difficult for practitioners to learn the exact processes from the document references and follow them in their projects. Practitioners follow the processes manually and submit the required data into various life-cycle tools that do not have much integration with the engineering tools. The life-cycle tools could be isolated tools for project management, requirement management, bug tracking, or review management, whereas the engineering tools could be separate tools for activities such as designing, coding, testing, or Integrated Development Environments (IDE). These different sets of tools make it difficult to have a consistent methodology implementation across multiple projects, and generate inconsistent data and reports in the organization. Inconsistency makes the process analysis unreliable, thus making it difficult to identify the process improvements. Also, as the processes are followed manually, data collection and reporting become manual tasks, which results in lower productivity and delivery efficiency. Software development methodologies are complex processes that are simultaneously resilient and fragile; software development life cycle and its management has the potential of impacting software methodologies negatively hence potentially compromising the positive delivery of a sound software product. Methodologies themselves provide diverse approaches to resolve the requirements of a particular process. When looking at their respective theoretical models, although diverse, a common thread is woven among them. Whether it is a historically long standing methodology or a new innovative methodology, all have an identical goal in the end, to provide a solid, i.e., fault free, software product that meets the client s stated or determined requirements. 3. Related Work. One of the oldest software development tools is flowcharting, which developed since the 1920s. The software development methodology has emerged since the 1960s. The oldest formalized methodology for building information systems is the Systems development life cycle. The traditional Systems development life cycle originated in the 1960s to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities resolved around heavy data processing and number crunching routines. [3] Software development approaches. Every software development methodology has more or less its own approach to software development. There is a set of more general approaches, which are developed into several specific methodologies. These approaches are [1]: Waterfall: linear framework type Prototyping: iterative framework type Incremental: combination of linear and iterative framework type Spiral: combination linear and iterative framework type Rapid Application Development (RAD): Iterative Framework Type Waterfall model : The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, 79

4 International Journal of Advancements in Computing Technology Volume 2, Number 4, October 2010 design, implementation, testing (validation), integration, and maintenance. The first formal description of the waterfall model is often cited to be an article published by Winston W. Royce [13] in 1970 although Royce did not use the term "waterfall" in this article. Figure 1. Waterfall Model The disadvantage of waterfall model is that it is rigid in responding to changes in the requirement that occur later in the various phases of the software development life cycle [14]. Prototyping : Software prototyping, is the framework of activities during software development of creating prototypes, i.e., incomplete versions of the software program being developed[15]. Not a standalone, complete development methodology handling selected portions of a larger, more traditional development methodology Incremental, Spiral, or Rapid Application Development (RAD). It improves both user participation in system development and communication among project stake holders. However, approval process and control is not strict. Further, software prototyping can lead to poorly designed systems. Figure 2. Prototype Model The problem with prototyping approach is that it can lead to false expectations, where the customer mistakenly believes that the system is finished when in fact it is no but is not truly functional [14]. Incremental : Various methods are acceptable for combining linear and iterative systems development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. Moderate control is maintained over the life of the project through the use of written documentation and the formal review and approval / signoff by the user and technology management at designated major milestones. Stakeholders can be given concrete evidence of project status throughout the life cycle. The weakness of this model is that since some modules will be completed much earlier than others, welldefined interfaces are required. Also difficult problems tend to be pushed to the future to demonstrate early success to management. [16] The disadvantage of Incremental approach is that in this difficult problems tend to be pushed to the future to demonstrate early success to management [14]. 80

5 Spiral : The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Focus is on risk management [17]. Weaknesses include there are no established controls for moving from one cycle to another cycle. Without controls, each cycle may generate more work for the nest cycle. Further, there are no firm deadlines. Cycles continue with no clear termination condition, so there is an inherent risk of not meeting budget or schedule. Spiral model is most appropriate for situations where real-time or safetycritical systems are used or where risk avoidance is a high priority. Figure 3. Spiral Model The major problem with sprial model is that it is highly customized to each project and thus is quite complex, limiting reusability [14]. Rapid Application Development (RAD) : Rapid Application Development (RAD) is a software development methodology, which involves iterative development and the construction of prototypes. Rapid application development is a term originally used to describe a software development process introduced by James Martin in Basic key objective is for fast development and delivery of a high quality system at a relatively low investment cost. RAD attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. Here, the key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance. Disadvantage of RAD is that more speed and lower cost may lead to lower overall system quality. Further, project may end up with more requirements than needed [14]. RAD also suffers from the same problem that incremental model suffers i.e. the tendency for difficult problems to be pushed to the future to demonstrate early success to management Current Software Development Approaches. Rational Unified Process (RUP) is an iterative software development methodology approach, based on UML. RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development: Inception, Elaboration, Construction, and Guidelines. There are a number of tools and products available designed to facilitate RUP implementation [18]. Agile Software Development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between selforganizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated [19]. Aspect Oriented Software Development: Iterative Framework Type [20]. Ofcourse, many of the new generation software methodologies the Agile Process also has found applications in the OMG promoted Model Driven Architecture (MDA) framework [21-22]. a) Knowledge management systems enabling sofware development process 81

6 International Journal of Advancements in Computing Technology Volume 2, Number 4, October 2010 The software industry is resource-oriented and it becomes quite important to ensure that knowledge in the minds of resources is safeguarded. It is found that, while 26 per cent of knowledge in the average organization is stored on paper and 20 per cent digitally, an astonishing 42 per cent is stored in employees' heads. There have been many instances where the learning and knowledge is lost when resources move to newer roles, or leave the organization. Knowledge is invisible and is tied up in customer relationships. It is linked to the ratio of experienced to junior employees. KM assists in getting the right knowledge to the right person as fast as possible and assists in retaining customers. The most difficult part in implementing KM is not the technology. It is to understand where knowledge resides within the organization [31]. b) The Need for Capturing and Sharing Process and Product Knowledge Knowledge Management addresses the issues of capturing and sharing knowledge, while the problems of project diversity and product singularity make it clear that such a system must be flexible enough to encompass variations on the same theme. Most artifacts guiding a software project and developed during a software project can be represented as documents. Therefore, these are the main explicit assets of the software organization. These assets directly support the core business and must be managed so that they do not get lost. The problem of transferring knowledge from experts to novices is facilitated if the knowledge is readily captured, stored, and organized, possibly as documents [32]. c) The Need for Acquiring Knowledge about New Technologies Knowledge Management fosters a knowledge sharing culture within the company that helps facilitate sharing of knowledge related to new technologies. Knowledge Management also makes the point that time should be spent on actively searching for knowledge both within the organization and outside. Knowledge sharing occurs within communities of practice and interests, which can help speed up the learning curve. d) The Need for Knowing Who Knows What Knowledge Management can never tap the brains of the employees, but it can help build structures and frameworks for capturing key information that can help retain some knowledge when employees leave. This key information would at least help in understanding what the employee who left knew and what profile his successor needs to have to fill the position. Knowledge Management can help establish routines for identifying knowledge, as well as the people who own the knowledge --- the experts. Competence Management, which also aims at identifying gaps in the knowledge structures, is, besides document management, the second cornerstone in our knowledge management model. e) The Need for Distance Collaboration Any larger software development is a group activity. The division of work into phases often means that different groups are involved at the same or different time. Due to globalization, these groups are often spread out geographically and it is common that group members live and work in different time zones. Outsourcing of subsystems to subcontractors also results in geographically co-located teams that need to work together. These groups need to communicate, collaborate, and coordinate independently of time and place. Knowledge Management can help solve this problem as it acknowledges the need to capture, organize and store knowledge, as well as the necessity of knowledge transfer. Communication in software engineering is often related to the transfer of knowledge. Collaboration is related to mutual sharing of knowledge. Coordination that is independent of time and space is facilitated if the work artifacts and their status are stored and made part of an organizational memory. f) Challenges for Knowledge Management in Software Engineering Implementing knowledge management in any organization is a challenge because of the time and effort that is required before it starts to return on the investment. Software organizations seem to have even less time than others because of the fast pace of the business. Another challenge is the elusiveness of software. Unlike products of other domains, software is not visible. Invisibility leads to less reuse of the system. A 82

7 developer, while implementing or modifying a system, cannot find out if the work has already been done. Many times, developers reinvent a system instead of reusing it, and this result in lower productivity. Another result is that software developers are not accustomed to reuse, which is a problem because the idea behind knowledge management is reuse of assets. The most problematic challenge to knowledge management is that most of the knowledge in software engineering is tacit and will never become explicit. It will remain tacit because there is no time to make it explicit. There are very few approaches and tools for turning tacit knowledge into explicit knowledge, and most of the tacit knowledge is tacit in the most extreme way. Therefore, it is difficult to express and make explicit. A way to address this problem can be to develop a knowledge sharing culture, as well as technology support for knowledge management, never forgetting that the main asset of the organization is its employees. In order to produce quality software, software organizations are trying to better use one of its most important resource: the organizational software engineering knowledge. In the context of software development, KM can be used to capture the knowledge and experience generated during the software process. Reusing knowledge can prevent the repetition of past failures and guide the solution of recurrent problems. Also, we cannot forget that collaboration is one of the most important knowledge sources for software organizations [30]. To support the knowledge management process in a SEE, a KM infrastructure should be provided. The corporate or organizational memory (OM) must be at the core of this infrastructure, supporting knowledge sharing and reuse. Arranged around the OM, knowledge management services shall actively provide useful information to users working on knowledge-intensive tasks [29]. These knowledge management services correspond to the activities of the knowledge management process: creation, capture, retrieval, access, dissemination, use, and preservation of the organization s knowledge, as shown in Figure 4. Figure 4. Knowledge management infrastructure The primary requirement for an OM is to prevent the loss and enhance the accessibility to organizational knowledge by providing a centralized, well-structured knowledge repository. Since workers are often too busy to look for information or do not even know that relevant information exists, proactive services must be provided, actively reminding workers of helpful knowledge. Thus, knowledge distribution may be passive or active, as either the user can search for the required information, or the KM system itself can offer knowledge that seems relevant to the user s task. To gain user acceptance, a KM system must be integrated into the organization s process, allowing collecting and storing relevant knowledge as they are generated in the work. Consequently, it should be also integrated to the existing work environment [29]. The KM system is to be an assistant to the user, supplying him with relevant organizational knowledge, but leaving him the responsibility of a contextual interpretation and evaluation of this information. In this context, to keep an OM up to date, it is important to get feedback from its users, who must be enabled to point out deficiencies and suggest improvements without significantly disrupting their usual workflow. Therefore, user feedback is essential for OM maintenance and evolution. 4. Case Study: Learning Resources Center (LRC) Project We now look at a prototype application problem that demonstrates implementation of the above methodologies for a learning resource center that provides services to its customers in the form of 83

8 International Journal of Advancements in Computing Technology Volume 2, Number 4, October 2010 periodicals, books, newsletters and magazines. This learning resource center library has various resources (books) of which all copies are located in the same room and shelf. An Information officer handles the maintenance of the association between these resources and their locations. The Information officer also maintains an up-to-date view of the lending status of copies of books, periodicals and journals Functional Decomposition Based on the problem definition above the following types of services will be required: Finding resources on a topic: A search operation that takes partial or incomplete description of the resources and lists accurate matches in the form of books or journals. Getting list of Journals: A search service that lists all the journal issues for a particular publishing month (quarterly / bi-monthly etc). The user will be able to filter the selections based on the criteria specified regarding the journal details. Upcoming Issues: This will list the future issues for publication and the issue month. Authentication: Before providing any kind of services the application needs to verify the credentials (username and password) to it. Logging: A logging function requirement to keep track of the calls made to the the web services. These kind of features are useful to track the preferences of cardholders and resources in demand type of statistics from within the application. The fig. 4 below shows the functional decomposition diagram for the LRC prototype. Figure 5. Functional Decomposition diagram for LRC Requirements & Design: Software Methodology Selection for LRC Project Further, for each of the methodologies that was followed at the requirements and design stage, the following conclusions listed in table 1 below were drawn: Table 1. Comparison of general software development methodologies Parameter Waterfall Prototyping Incremental Spiral RAD Development Sequential + Sequential + Sequential Iterative Iterative type Iterative Iterative Flexible Control Rigid Flexible Flexible Flexible Most Appropriate for Least Appropriate for Strengths Mainframe Web Software development Small to Medium Mainframe Encourages innovation and Web Interactive Customers involved at all Real-time Low Risk priority Promotes risk control and can Small Real-time Can be modified 84

9 Weaknesses measurable and Conserve resources Inflexible and excessive documentation quick to implement False customer expectations and may lead to poor design stages and quick to implement Difficult implementation issues delayed include other methodologies No firm deadlines and may end up waterfall model like rapidly and close to implementation at every stage No firm deadlines and Difficult implementation issues delayed Due to the various disadvantages of each of the above methodologies (classified in the table as general software development methodologies), it was decided to use one of the widely popular software development approaches namely, i.e., Agile Software Development which subscribes to Test Code Test approach Implementation: LRC Project. Based on the above functional decomposition, an prototype implementation was carried out using Java Server Pages (JSP), Servlets, Java Beans, Java Enterprise Edition (Java EE) [24], JUnit [25], HSQLDB Database [26], and Tomcat Web Server [27] under Eclipse platform [28]. For carrying out code tests, JUnit framework was used. In addition to these tools, various other tools available as Eclipse Plug-ins [29] like DbVisualizer, UML tool and others were installed as and when required in various phases of the project implementation. Shown below in fig. 5 and fig. 6 are snapshots of the prototype implementation under Eclipse platform. Figure 6. LRC database query Implementation on Eclipse platform Figure 7. JSP Client Implementation for LRC project 85

10 5. Observations and Results. International Journal of Advancements in Computing Technology Volume 2, Number 4, October 2010 To summarize, there is no single software development methodology that can meet all the needs of all the stakeholders. This has resulted in the evolution of number variant methodologies as the tools and technologies matured. They also evolved from the experiences the software developers, architects, designers and business analyst shared at different forums. Some of the popular methodologies that evolved and are currently the choice of the software industry and are used for software development are Rational Unified Process, Agile Process and Aspect Oriented Methodology. Based on the study of various software development methodologies carried out at various stages of the LRC prototype implementation namely, analysis, design and implementation as identified in section 4 above, the following inferences were drawn as shown in the table 2 below: Table 2. Relevance of various software development methodologies Methodology Relevance Waterfall Suitable for Legacy applications in use today Prototyping Suitable for quick deploy application for in-house environment Incremental Suitable for small web applications Spiral More suited for Real-time applications RAD More suited for Real-time applications Agile Very much relevant to today s Web / Distributed setup in today s business environment 6. Conclusion. As we move towards a global economy, so are our software development efforts. Therefore, understanding the impacts on software development methodology on enterprise software development is an important milestone and an important step towards mastering and adopting the right techniques and their productive relevance towards their integration in any future business strategy in the IT industry relying on the various business domain segments. Significance of this work can be gauged from the fact that today there are so many processes / methodologies that are being used in the industry that the businesses may find it difficult to decide, implement and integrate these software methodologies for any future business strategic plan. A single one stop window will serve as the right input at this juncture. 7. Future Work. Future work in this direction will now encompass doing a comparative analysis of the current software architecture and component frameworks based on current software methodologies like agile methodology and Aspect Oriented methodology. This will involve implementation based on the Java programming language, Java Enterprise Environment (Java EE) and related web engineering tools and technologies.relevant for a distributed environment. 8. References. [1] R. Pressman, Software Engineering: A Practitioner s Approach, 6 th Edition, McGraw publishing, [2] Standish Group Report, last accessed Feb 03, [3] Edsger Dijkstra, Notes on Structured programming, last accessed Feb 13, [4] C.M. Ashworth, Using SSADM to specify Requirements, IEEE Proceedings, [5] Bjarne Stroustrup, The C++ programming language, special edition, 3 rd Edition, Addison-Wesley, [6] Gerry Coleman and Renaat Verbruggen, A Quality Software Process for Rapid Application Development, Software Quality Journal, Springer Netherlands, Vol. 7, No. 2, July 1998, pp

11 [7] Jeff Sutherland, Future of Scrum: Parallel Pipelining of Spirits in Complex Projects, IEEE Proceedings of the Agile Development Conference, 2005, MA, US, pp [8] last accessed Feb 03, [9] Scott Ambler. Last Accesses on April 03, [10] A Rational Software Corporation white paper. IBM. Rational Unified Process: Best practices for software development teams. Accessed on Feb 01, [11] Georges Gauthier Merx & Ronald J. Norman (2006). Unified Software Engineering with Java. p.201. [12] Accessed Feb 13, 2010 [13] Winston W. Royce. Managing the Development of large software systems, IEEE Proceedings, (IEEE WESCON), (August 1970), pp [14] SELECTING A DEVELOPMENT APPROACH. Retrieved 27 April [15] L. Bernstein. Get the design right [software prototyping], IEEE Software, Sep pp [16] Barry Boehm and Jo Ann Lane. Using the Incremental Commitment Model to Achieve Successful System Development, Last accessed on April 23, [17] Barry W. Boehm. A Spiral Model of Software Development and Enhancement, IEEE Computer (May 1988), pp [18] Last accessed Feb 07, [19] Last accessed Feb 11, [20] Zhang, C. and Jacobsen, H. A. Towards just in-time middleware architectures. In proceedings of the 2 nd International Conference on Aspect Oriented software development p ISBN [21] Jon Siegel, Why use the model driven architecture to design and build distributed applications, IEEE Proceedings of the 27 th International Conference on Software Engineering, St. Louis, MO, USA, pp [22] Last accessed Feb 12, [23] Watts S. Humphrey, Introduction to the team software process, Addison-Wesley Longman Ltd., Essex, UK, ISBN: X, [24] Last accessed on Feb 10, [25] Last accessed on Feb 11, [26] Last accessed on Feb 11, [27] Last accessed on Feb 13, [28] Last accessed on Feb 14, [29] A.C.C. Natali, R.A. Falbo, Knowledge Management in Software Engineering Environments, In: proceedings of the XVI Brazilian Symposium on Software Engineering - SBES'2002, , Gramado, Brazil, October [30] S. Staab, R. Studer, H.P. Schurr, Y. Sure, Knowledge Processes and Ontologies, IEEE Intelligent Systems, January/February, Vol. 16, No. 1, [31] Knowledge Management for Software Companies by Mohan Srinivasan, Advisory Project Manager IBM Global Services India Pvt. Ltd. Bangalore, India [32] Knowledge Management in Software Engineering A State-of-the-Art-Report Prepared for: Mr. Paul M. Engelhart Air Force Research Laboratory Information Directorate/IFED 87