Software evolution

Last updated

Software evolution is the continual development of a piece of software after its initial release to address changing stakeholder and/or market requirements. Software evolution is important because organizations invest large amounts of money in their software and are completely dependent on this software. Software evolution helps software adapt to changing businesses requirements, fix defects, and integrate with other changing systems in a software system environment.

Contents

General introduction

Fred Brooks, in his key book The Mythical Man-Month , [1] states that over 90% of the costs of a typical system arise in the maintenance phase, and that any successful piece of software will inevitably be maintained.

In fact, Agile methods stem from maintenance-like activities in and around web based technologies, where the bulk of the capability comes from frameworks and standards.[ citation needed ]

Software maintenance addresses bug fixes and minor enhancements, while software evolution focuses on adaptation and migration.

Software technologies will continue to develop. These changes will require new laws and theories to be created and justified. Some models as well would require additional aspects in developing future programs. Innovations and improvements do increase unexpected form of software development. The maintenance issues also would probably change as to adapt to the evolution of the future software. Software processes are themselves evolving, after going through learning and refinements, it is always improve their efficiency and effectiveness. [2]

Basic concepts

The need for software evolution comes from the fact that no one is able to predict how user requirements will evolve a priori . [3] In other words, the existing systems are never complete and continue to evolve. [4] As they evolve, the complexity of the systems will grow unless there is a better solution available to solve these issues. The main objectives of software evolution are ensuring functional relevance, reliability and flexibility of the system. Software evolution can be fully manual (based on changes by software engineers), partially automated (e.g. using refactoring tools) or fully automated.

Software evolution has been greatly impacted by the Internet:

Types of software maintenance

E.B. Swanson initially identified the three categories of maintenance: corrective, adaptive, and perfective. Four categories of software were then catalogued by Lientz and Swanson (1980). [5] These have since been updated and normalized internationally in the ISO/IEC 14764:2006: [6]

All of the preceding take place when there is a known requirement for change.

Although these categories were supplemented by many authors like Warren et al. (1999) [7] and Chapin (2001), [8] the ISO/IEC 14764:2006 international standard has kept the basic four categories.

More recently the description of software maintenance and evolution has been done using ontologies (Kitchenham et al. (1999), [9] Deridder (2002), [10] Vizcaíno (2003), [11] Dias (2003), [12] and Ruiz (2004) [13] ), which enrich the description of the many evolution activities.

Stage model

Current trends and practices are projected forward using a new model of software evolution called the staged model. [14] Staged model was introduced to replace conventional analysis which is less suitable for modern software development is rapid changing due to its difficulties of hard to contribute in software evolution. There are five distinct stages contribute in simple staged model (Initial development, Evolution, Servicing, Phase-out, and Close-down).

Lehman's Laws of Software Evolution

Prof. Meir M. Lehman, who worked at Imperial College London from 1972 to 2002, and his colleagues have identified a set of behaviours in the evolution of proprietary software. These behaviours (or observations) are known as Lehman's Laws. He refers to E-type systems as ones that are written to perform some real-world activity. The behavior of such systems is strongly linked to the environment in which it runs, and such a system needs to adapt to varying requirements and circumstances in that environment. The eight laws are:

  1. (1974) "Continuing Change" — an E-type system must be continually adapted or it becomes progressively less satisfactory [15]
  2. (1974) "Increasing Complexity" — as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it [15]
  3. (1980) "Self Regulation" — E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal [15]
  4. (1978) "Conservation of Organisational Stability (invariant work rate)" - the average effective global activity rate in an evolving E-type system is invariant over the product's lifetime [15]
  5. (1978) "Conservation of Familiarity" — as an E-type system evolves, all associated with it, developers, sales personnel and users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves. [15]
  6. (1991) "Continuing Growth" — the functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime
  7. (1996) "Declining Quality" — the quality of an E-type system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes
  8. (1996) "Feedback System" (first stated 1974, formalised as law 1996) — E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base [16]

It is worth mentioning that the applicability of all of these laws for all types of software systems has been studied by several researchers. For example, see a presentation by Nanjangud C Narendra [17] where he describes a case study of an enterprise Agile project in the light of Lehman’s laws of software evolution. Some empirical observations coming from the study of open source software development appear to challenge some of the laws [ vague ][ citation needed ].

The laws predict that the need for functional change in a software system is inevitable, and not a consequence of incomplete or incorrect analysis of requirements or bad programming. They state that there are limits to what a software development team can achieve in terms of safely implementing changes and new functionality.

Maturity Models specific to software evolution have been developed to improve processes, and help to ensure continuous rejuvenation of the software as it evolves iteratively[ citation needed ].

The "global process" that is made by the many stakeholders (e.g. developers, users, their managers) has many feedback loops. The evolution speed is a function of the feedback loop structure and other characteristics of the global system. Process simulation techniques, such as system dynamics can be useful in understanding and managing such global process.

Software evolution is not likely to be Darwinian, Lamarckian or Baldwinian, but an important phenomenon on its own. Given the increasing dependence on software at all levels of society and economy, the successful evolution of software is becoming increasingly critical. This is an important topic of research that hasn't received much attention.

The evolution of software, because of its rapid path in comparison to other man-made entities, was seen by Lehman as the "fruit fly" of the study of the evolution of artificial systems.

See also

Available tools

Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

Software documentation is written text or illustration that accompanies computer software or is embedded in the source code. The documentation either explains how the software operates or how to use it, and may mean different things to people in different roles.

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Iterative and incremental development</span> Development methodology

Iterative and incremental development is any combination of both iterative design or iterative method and incremental build model for development.

Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.

Software development is the process used to conceive, specify, design, program, document, test, and bug fix in order to create and maintain applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through the final manifestation, typically in a planned and structured process often overlapping with software engineering. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Web development is the work involved in developing a website for the Internet or an intranet. Web development can range from developing a simple single static page of plain text to complex web applications, electronic businesses, and social network services. A more comprehensive list of tasks to which Web development commonly refers, may include Web engineering, Web design, Web content development, client liaison, client-side/server-side scripting, Web server and network security configuration, and e-commerce development.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

<span class="mw-page-title-main">User interface design</span> Planned operator–machine interaction

User interface (UI) design or user interface engineering is the design of user interfaces for machines and software, such as computers, home appliances, mobile devices, and other electronic devices, with the focus on maximizing usability and the user experience. In computer or software design, user interface (UI) design primarily focuses on information architecture. It is the process of building interfaces that clearly communicate to the user what's important. UI design refers to graphical user interfaces and other forms of interface design. The goal of user interface design is to make the user's interaction as simple and efficient as possible, in terms of accomplishing user goals.

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

The change request management process in systems engineering is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a system. Its main goals are to support the processing and traceability of changes to an interconnected set of factors.

<span class="mw-page-title-main">V-model (software development)</span> Software development methodology

In software development, the V-model represents a development process that may be considered an extension of the waterfall model, and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.

CADES was a software engineering system produced to support the design and development of the VME/B Operating System for the ICL New Range - subsequently 2900 - computers.

In software engineering, the laws of software evolution refer to a series of laws that Lehman and Belady formulated starting in 1974 with respect to software evolution. The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand. Over the past decades the laws have been revised and extended several times.

The term “adaptation” in computer science refers to a process where an interactive system adapts its behaviour to individual users based on information acquired about its user(s) and its environment. Adaptation is one of the three pillars of empiricism in Scrum.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

References

  1. Fred Brooks, The Mythical Man-Month . Addison-Wesley, 1975 & 1995. ISBN 0-201-00650-2 & ISBN   0-201-83595-9.
  2. aeddy; ref: Understanding Open Source Software Evolution Walt Scacchi Institute for Software Research
  3. Bennett, K. H.; Rajlich, V. T.; Mazrul, R. Mohamad (1995). "Legacy System: Coping with success". IEEE Software . pp. 19–23.
  4. Trung Hung Vo (2007), Software Maintenance
  5. Lientz, B.P. and Swanson, E.B., Software Maintenance Management, A Study Of The Maintenance Of Computer Application Software In 487 Data Processing Organizations. Addison-Wesley, Reading MA, 1980. ISBN   0-201-04205-3
  6. ISO/IEC 14764:2006, 2006.
  7. Paul Warren; Cornelia Boldyreff; Malcolm Munro (1999). "The evolution of websites". Proceedings of the Seventh International Workshop on Program Comprehension. IEEE. pp. 178–185.
  8. Ned Chapin; Joanne E Hale; Khaled Md Khan; Juan F Ramil; Wui-Gee Tan (2001). "Types of software evolution and software maintenance". Journal of Software Maintenance and Evolution: Research and Practice. 13 (1): 3–30. doi:10.1002/smr.220.
  9. Barbara Kitchenham; Guilherme Travassos; Anneliese von Mayrhauser; Frank Niessink; Norman Schneidewind; Janice Singer; Shingo Takada; Risto Vehvilainen; Hongji Yang (1999). "Towards an ontology of software maintenance". Journal of Software Maintenance: Research and Practice. 11 (6): 365–389. doi: 10.1002/(SICI)1096-908X(199911/12)11:6<365::AID-SMR200>3.0.CO;2-W . hdl:10945/55140.
  10. Dirk Deridder (2002). "A concept-oriented approach to support software maintenance and reuse activities". Proceedings of the 5th Joint Conference on Knowledge Based Software Engineering.
  11. Aurora Vizcaíno; Jesús Favela; Mario Piattini (2003). "A multi-agent system for knowledge management in software maintenance". Knowledge-Based Intelligent Information and Engineering Systems. Springer. pp. 415–421.
  12. Márcio Dias; Nicolas Anquetil; Káthia de Oliveira (2003). "Organizing the knowledge used in software maintenance". Journal of Universal Computer Science. 9 (7): 641–658.
  13. Francisco Ruiz; Aurora Vizcaíno; Mario Piattini; Félix García (2004). "An ontology for the management of software maintenance projects". International Journal of Software Engineering and Knowledge Engineering. 14 (3): 323–349. doi:10.1142/S0218194004001646. S2CID   15592498.
  14. 1 2 3 4 5 6 Bennett, Keith; Rajlich, Václav (2000-07-01). "A Staged Model for the Software Life Cycle" (PDF). Computer . IEEE Computer Society. 33 (7): 66–71. doi:10.1109/2.869374. S2CID   7547412 . Retrieved 2020-05-23.{{cite journal}}: CS1 maint: date and year (link)
  15. 1 2 3 4 5 Lehman, M. M. (1980). "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". Journal of Systems and Software. 1: 213–221. doi:10.1016/0164-1212(79)90022-0.
  16. Lehman's laws of software evolution
  17. Narendra, Nanjangud (29 April 2011). "Software Evolution in Agile Development". InfoQ. Retrieved 19 March 2016.

Further reading