Enterprise Systems Development: Impact of Various Software Development Methodologies

By
NAVEEN KARKONDA Id#110-00-4907

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: 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 functionality with suitable development methodology. However, identifying one stop option 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. 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.
History of software methodology:
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].
• Extreme Programming since 1999 (Agile Software Development) [9].
• Rational Unified Process (RUP) since 2003 [10].

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.

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 :
• 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, 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.

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.
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
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.

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, well-defined interfaces are required. Also difficult problems tend to be pushed to the future to demonstrate early success to management.
The disadvantage of Incremental approach is that in this difficult problems tend to be pushed to the future to demonstrate early success to management.
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 safety-critical systems are used or where risk avoidance is a high priority. The major problem with sprial model is that it is highly customized to each project and thus is quite complex, limiting reusability.
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 1991. 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. 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 self-organizing 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.

Of course, 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 software development process 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 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.
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.

Future Enhancements: 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.
References:
[1] R. Pressman, “Software Engineering: A Practitioner’s Approach”, 6th Edition, McGraw publishing, 2007.
[2] Standish Group Report, http://www1.standishgroup.com/newsroom/chaos_2009.php, last accessed Feb 03, 2010.
[3]Edsger Dijkstra, “Notes on Structured programming”, http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF , last accessed Feb 13, 2010.
[4] C.M. Ashworth, “Using SSADM to specify Requirements”, IEEE Proceedings, 1989.
[5] Bjarne Stroustrup, The C++ programming language, special edition, 3rd Edition, Addison-Wesley, 1997.