DITF LDI Lietišķo datorsistēmu programmatūras profesora grupa e-business Solutions Basic Trends of Modern Software Development
2
3
Software Engineering FAQ What is software engineering? An engineering discipline concerned with all aspects of software production. What is a software process? A set of activities whose goal is the development or evolution of software. What is a software process model? A simplified representation of a software process, presented from a specific perspective What is software architecture? A software architecture is a description of how a software system is organized. 4
Trends of Software Engineering I. Increasing complexity of software II. Raising the level of abstraction III. Continuous improvement of development process IV. Ability to deal with changes in requirements V. Reusing experience to address recurring problems successfully 5
Software reuse 6
Software reuse The process of creating software systems from existing software rather than building them from scratch An important mechanism to improve software quality and development productivity 7
Software reuse In most engineering disciplines, systems are designed by composing existing components that have been used in other systems. Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need a design process that is based on systematic software reuse. 8
Software reuse Different published rates about reuse up to 60% of design and code is reusable in business applications up to 75% of functions are common to more than one application up to 85% - theoretical reuse potential 9
Software reuse Reusability the property of a software asset, that indicates its probability of reuse often understood as one of software quality and development productivity factors Reusable asset (artefact) reusable software or software knowledge different software life cycle products Systematic software reuse based on the defined processes and rules without relying on individual initiative or luck 10 10
Software reuse Most new business software systems are now developed by reusing knowledge and code from previously implemented systems. There are many different ways to reuse software. These range from the reuse of classes and methods in libraries to the reuse of complete application systems. 11
Software reuse Application system reuse Component reuse The whole of an application system may be reused either by incorporating it without change into other systems or by developing application families. Components of an application from sub-systems to single objects may be reused. Object and function reuse Software components that implement a single well-defined object or function may be reused. 12
Benefits of software reuse Benefit Explanation Increased dependability Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed. Reduced process risk The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused. Effective use of specialists Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge. 13
Benefits of software reuse Benefit Explanation Standards compliance Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface. Accelerated development Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time may be reduced. 14
Software reuse Benefits of reuse Gains in quality error fixes accumulated from reuse Gains in reliability reuse increases the chance of errors to be detected Gains in productivity less design and code, less testing efforts Reduction of maintenance costs fewer defects and maintenance costs with proven quality components Reduction of product time to market Support for rapid prototyping 15 15
Problems with reuse Problem Explanation Increased maintenance costs If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes. Lack of tool support Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools. Not-invented-here syndrome Some software engineers prefer to rewrite components because they believe they can improve on them. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people s software. 16
Problems with reuse Problem Explanation Increased maintenance costs If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes. Lack of tool support Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools. Not-invented-here syndrome Some software engineers prefer to rewrite components because they believe they can improve on them. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people s software. 17
Software reuse Obstacles of reuse Managerial and organizational obstacles support of top-level management is needed lack of management incentives Economic obstacles requires up-front investments Conceptual and technical obstacles - difficulty of finding reusable software - non-reusability of legacy components - modification effects on the component 18 18
Software reuse Software reuse is multidisciplinary organizational aspects managerial and technological infrastructure centralized or distributed organizational approaches economic aspects proactive or reactive capital investments metrics, reuse cost estimation techniques, returnon-investment models technical aspects 19 19
Approaches that support software reuse Approach Description Architectural patterns Standard software architectures that support common types of application systems are used as the basis of applications. Design patterns Generic abstractions that occur across applications are represented as design patterns showing abstract and concrete objects and interactions. Component-based development Systems are developed by integrating components (collections of objects) that conform to component-model standards. Application frameworks Collections of abstract and concrete classes are adapted and extended to create application systems. 20
Approaches that support software reuse Approach Description Program libraries Class and function libraries that implement commonly used abstractions are available for reuse. Model-driven engineering Software is represented as domain models and implementation independent models and code is generated from these models. Program generators A generator system embeds knowledge of a type of application and is used to generate systems in that domain from a user-supplied system model. Aspect-oriented software development Shared components are woven into an application at different places when the program is compiled. 21
Approaches that support software reuse Approach Description Service-oriented systems Systems are developed by linking shared services, which may be externally provided. Software product lines An application type is generalized around a common architecture so that it can be adapted for different customers. ERP systems Large-scale systems that encapsulate generic business functionality and rules are configured for an organization. Configurable vertical applications Generic systems are designed so that they can be configured to the needs of specific system customers. 22
Agile Software Development 23
Rapid software development Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast changing requirement and it is practically impossible to produce a set of stable software requirements Software has to evolve quickly to reflect changing business needs. Rapid software development Specification, design and implementation are inter-leaved System is developed as a series of versions with stakeholders involved in version evaluation User interfaces are often developed using an IDE and graphical toolset. 24
Agile methods Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: Focus on the code rather than the design Are based on an iterative approach to software development Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework. 25
Agile manifesto 26
The principles of agile methods Principle Description Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and so design the system to accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system. 27
Extreme programming Perhaps the best-known and most widely used agile method. Extreme Programming (XP) takes an extreme approach to iterative development. New versions may be built several times per day Increments are delivered to customers every 2 weeks All tests must be run for every build and the build is only accepted if tests run successfully. 28
Extreme programming practices Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. Small releases 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. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. 29
Extreme programming practices Pair programming Developers work in pairs, checking each other s work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. 30
Refactoring Programming team look for possible software improvements and make these improvements even where there is no immediate need for them. This improves the understandability of the software and so reduces the need for documentation. Changes are easier to make because the code is wellstructured and clear. However, some changes requires architecture refactoring and this is much more expensive. 31
Examples of refactoring Re-organization of a class hierarchy to remove duplicate code. Tidying up and renaming attributes and methods to make them easier to understand. The replacement of inline code with calls to methods that have been included in a program library. 32
Test-first development Writing tests before code clarifies the requirements to be implemented. Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly. Usually relies on a testing framework such as Junit. All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors. 33 33
Pair programming In XP, programmers work in pairs, sitting together to develop code. This helps develop common ownership of code and spreads knowledge across the team. It serves as an informal review process as each line of code is looked at by more than 1 person. It encourages refactoring as the whole team can benefit from this. Measurements suggest that development productivity with pair programming is similar to that of two people working independently. 34
Agile project management The principal responsibility of software project managers is to manage the project so that the software is delivered on time and within the planned budget for the project. 35
Agile project management The standard approach to project management is plan-driven. Managers draw up a plan for the project showing what should be delivered, when it should be delivered and who will work on the development of the project deliverables. Agile project management requires a different approach, which is adapted to incremental development and the particular strengths of agile methods. 36
Scrum The Scrum approach is a general agile method but its focus is on managing iterative development rather than specific agile practices. There are three phases in Scrum. The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. This is followed by a series of sprint cycles, where each cycle develops an increment of the system. The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project. 37
Scrum 38
The Sprint cycle Sprints are fixed length, normally 2 4 weeks. They correspond to the development of a release of the system in XP. The starting point for planning is the product backlog, which is the list of work to be done on the project. The selection phase involves all of the project team who work with the customer to select the features and functionality to be developed during the sprint. 39
Scrum benefits The product is broken down into a set of manageable and understandable chunks. Unstable requirements do not hold up progress. The whole team have visibility of everything and consequently team communication is improved. Customers see on-time delivery of increments and gain feedback on how the product works. Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed. 40
Architectural Design 41
Architectural design An early stage of the system design process. Often carried out in parallel with some specification activities. It involves identifying major system components and their communications. 42 42
Architecture reuse Systems in the same domain often have similar architectures that reflect domain concepts. Application product lines are built around a core architecture with variants that satisfy particular customer requirements. The architecture of a system may be designed around one of more architectural patterns or styles. 43
4 + 1 view model of software architecture A logical view, which shows the key abstractions in the system as objects or object classes. A process view, which shows how, at run-time, the system is composed of interacting processes. 44
4 + 1 view model of software architecture A development view, which shows how the software is decomposed for development. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. Related using use cases or scenarios (+1) 45
Architectural patterns Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. Patterns should include information about when they are and when the are not useful. 46
The organization of the Model-View-Controller Izmaina stāvokli Biznesa loģika Sistēmas dati Pieprasa stāvokli 47
Layered architecture Used to model the interfacing of sub-systems. Organises the system into a set of layers each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. 48
Information / Enterprise systems architecture Information systems have a generic architecture that can be organised as a layered architecture. These are transaction-based systems as interaction with these systems generally involves database transactions. Layers include: The user interface User communications Information retrieval System database 49