TM354 Software Engineering PDF

TM354: Software Engineering Block I: From domain to requirements Unit 1: Approaches to software development 1  Unit aims  This unit investigates the characteristics of a good software system, and considers what a development process w...

TM354: Software Engineering Block I: From domain to requirements Unit 1: Approaches to software development 1  Unit aims  This unit investigates the characteristics of a good software system, and considers what a development process would need to build such software.  It also considers the importance of focusing on the users’ needs and, wherever possible, making use of replaceable and reusable components in developing good software systems.  The unit introduces you to different approaches to software development, from plan-driven to agile, and discusses the factors that affect the choice of a process.  You will be also introduced to the importance of modelling within software development. Note that: All SAQs and Exercises in this unit are required. 2 Section 2: Software and software engineering  Software is a collection of computer programs and related data that provide instructions to tell computer what to do.  Software engineering: is concerned with the theories, methods and tools which are needed to develop the software which is reliable and works efficiently. It also concerns with evolving these models to meet changing needs and requirements.  System: an assembly of components that are connected together in an organized way. ◦ A system has properties that cannot be deduced or predicted by examining any one of its components in isolation (or even all its components, if they are not organised and connected). 3 Section 2: Software and software engineering  System boundary: is a conceptual line that divides the system that we wish to study from ‘everything else’, (scope of a system).  System’s environment is made up of those things which are not part of the system, but which can either affect the system or be affected by it.  A domain is a particular area of interest. 4 Section 2: Software and software engineering The Important characteristics of software that affect its development: 1. Malleability: Software is easy to change. This malleability creates a constant pressure for software to be changed rather than replaced. 2. Complexity: Software is often complex. Complexity can usually be recognized, but it is less easy to define. - One item of software can be considered more complex than another if the description of the first requires more explanation than that of the second. - If complexity is increased, errors will be increased. 3. Size: It is likely that there will be more errors in a large piece of software than there will be in a small one.. 5 Section 2: Software and software engineering A good software system is one that meets its users’ needs. It has the following characteristics: 1. Useful: software system should meet users’ needs. 2. Usable: the software should have an interface which is easy to use and user's friendly. 3. Reliable: errors must be minimized, otherwise users will not be able to perform those tasks that needs its support. 4. Flexible: software is easy to change as times goes. 5. Available: available in the target environment. 6. Affordable: it should meet users delivery date and costs which were agreed on when signing the contract between the two parties. 6 Section 2: Software and software engineering  A software system should be both available, so that users can decide whether or not its till meets their needs, and flexible, so that the developer can change it to meet its users’ needs.  In order to be maintainable, a software system should be written and documented in such a way that changes can readily be made.  What the developer does during development affects the ease with which it can be maintained.  If a change is easy to make, the cost of that change can be minimized so that the software system continues to be affordable.  The maintainability of software is greatly influenced by how it is designed and written. 7 Section 2: Software and software engineering  Many existing software systems have been purpose- built or specially adapted from a standard system. Such systems are called legacy systems which: - are usually large; - are critical to the business; - have probably been changed a number of times since their inception; - are often difficult to understand because of either a lack of documentation about their internal structure or a lack of experience within the group responsible for them; - are difficult to maintain because of the above factors.  Legacy system is lacking in flexibility, the longer software it will be the more difficult to maintain and cost. 8 Section 2: Software and software engineering Divide and Conquer  The only way till now to reduce the complexity of systems is modularization.  Modularization means decompose system or problem to a smaller sub-system with separate boundaries (modules). Examples of modules are: - whole programs or applications; - software libraries; - classes, in an object-oriented language such as Java. 9 Section 2: Software and software engineering There are two forms of decomposition: A. Projection: dependent modules, common elements between modules. B. Partitions: independent modules, which are easy to use  Usually even if the modules sound separate there are relationships between them which must be taken into consideration through the software development and during maintenance. 10 Section 2: Software and software engineering  A component depends on another if a change to one requires a change to another.  Another important issue is not only the nature of dependency but the number of dependencies.  In Software engineering, the term Coupling is used to refer to the degree of interdependence among different modules.  Ex: Module A depends on B and B depends on C (chain of interdependent modules),  another form of interdependencies is circular dependent if C depends on A.  A good software is loosely coupled system, which is easier to understand, modify, replace and reuse. 11  Section 2: Software and software engineering Chain Dependency Module A depends on Module B and B depends on C -> chain of interdependent modules Circular Dependency In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly. Such modules are also known as mutually.recursive.Suppose we have a class called A which has class B’s Object In UML terms A HAS B At the same time we class B is also composed of Object of class A In UML terms B HAS A Obviously this represents circular dependency because while creating the object of A, the compiler must know the size of B... on the other hand while creating object of B, the compiler must know the size of A 12 Section 2: Software and software engineering  In an object-oriented software system, two classes need to be coupled in order to allow any communication between their instances.  The class A is coupled to the class B if any of the following applies: - A inherits from B; - A has an attribute of class B; - A has a method that uses an instance of class B as an input or output argument; - A knows of a public attribute of class B.  A module which provides a service may require other services from another module, the required services are called context dependencies.  Abstraction is a particular way of viewing a complex problem to arrive at some useful decomposition of that problem 13 Section 2: Software and software engineering  In the same module, how closely the activities within a single module are related to each other is known as Cohesion.  A highly cohesion module performs one task or achieve a single objective. It is better if a module applies one single task.  Low coupling and high cohesive are competing.  A developer should try to achieve the best balance between the levels of coupling and cohesion. 14 Section 2: Software and software engineering Architecture and components  A system (or software) architecture is the structure of the items that make up a complete software system.  It includes: - the responsibilities for these items; - their interconnections; - and the appropriate technology (where it affects the effectiveness and efficiency of the software system).  The system architecture tells the developer about the overall shape of the actual or proposed software system.  It explains how the development team can use the various technologies to construct or assemble a software system. 15  Section 2: Software and software engineering  Layers, components and services. Figure: Three-layered architecture in distributed computing systems 16  Section 2: Software and software engineering  The top layer concentrates on the presentation aspects concerned with the user interface, which are more prone to change than the rest of a software system. (It is natural to expect a number of requests from users to make a software system more usable.)  The application domain is concerned with support for the way a user performs a given task, such as the processing of a customer’s order. ◦ A business may redesign the tasks that its employees perform, but perhaps not as often as amendments will be made to the user interface. Unless a business makes a radical shift in its core business concepts and transformations, the business services are less prone to change than the user interface.  The infrastructure contains the system support that usually includes the operating system and the databases, which allows the system to be more easily ported to new platforms. 17  Section 2: Software and software engineering  The term component as a unit of reuse or replacement in a software system. So, a component could be a module or class with certain properties that make it reusable or replaceable in a given system architecture. ◦ Enterprise Java Beans (EJB),.Net and CORBA are examples of standards for components  A service is a unit of reuse corresponding to a piece of functionality, described in a standard language, with published interfaces through which the service execution can be requested. ◦ A service-oriented architecture (SOA) structures software as a set of services. The notion of services being accessed remotely through a web browser – software as a service (SaaS) – is popular now with systems such as those provided by Google (for example, Gmail and Google Docs) 18  Section 2: Software and software engineering  Similarities and differences between components and Services  Similarities ◦ They both promote reuse and flexibility. ◦ They both use public interfaces to allow requesters to make use of their functionality without relying on their implementation.  Differences ◦ A component is usually implemented in a specific object-oriented technology; therefore only clients compliant with that technology can easily communicate and integrate with it. ◦ A service uses communication standards that allow the interoperation of diverse technologies. ◦ Components tend to be associated with business entities, while services tend to be associated to business processes – they may realize part or the whole of the functions within such a process and may involve several business entities. 19  Section 2: Software and software engineering Summary of section  This section has briefly examined the nature of software, and identified the desirable characteristics of a software system. You have seen: ◦ that a good software system is one that meets its users’ needs ◦ examples that illustrated the connections between the usefulness, usability, reliability, flexibility, availability and affordability of a software system ◦ that a software system can soon be out of date, as users’ needs change with time, and that needs can often be missed during requirements capture ◦ that modularisation is the main method of dealing with the size and complexity of a software system ◦ the problems that arise with legacy systems ◦ the significance of maintenance ◦ the importance of software architecture. 20  Section 3: An introduction to software development  Software development has a great deal in common with the discipline of engineering.  Software engineering: The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. ◦ To obtain a high quality software product requires a well-managed development process.  Software development is a human activity that involves the activities: analysis, design, implementation and testing that leads to produce a software system. 21  Section 3: An introduction to software development  There are some common characteristics between software development and engineering which support the argument that software development is an engineering discipline as follows: ◦ it is concerned with meeting a set of requirements that are defined as clearly as possible ◦ it uses a defined process with clear activities, each of which has at least one identifiable end product ◦ developers can apply their skills and experience to the tasks demanded of them ◦ validation and verification are regarded to be as essential as building the software itself ◦ it makes sensible use of tools and standards ◦ it follows a code of practice. 22  Section 3: An introduction to software development  A development process is a set of rules that defines how a software development project should be carried out, and a set of software engineering activities associated with the development of software.  Each activity undertakes some clearly defined process, starting with a number of inputs from any preceding activities.  On completion of an activity there may be one or more outputs, which are known as deliverables  The order in which these activities are carried out is called a life cycle or process model, and outlines an overall process for the development of a software system.  Distinguishing between a customer and a user: ◦ a customer is someone, who pays for a software system, ◦ users are people who use it on a day-to-day basis — (although a customer may also be one of the intended users). 23  Section 3: An introduction to software development Typical technical activities for the development of software  Domain modelling. Understanding the environment in which a system may be introduced – the business processes and rules. This is typically an activity that precedes a decision to develop a software system. Activities for the development of a good software system 1. Requirements (also known as requirements engineering). A set of steps including requirements elicitation, where you identify the problem, and requirements analysis, where you categorise, prioritise and model requirements. This defines what the system is to do. 2. Design. Determining how you will solve the problem. 3. Implementation. Acting upon the decisions made at the design stage. 4. Testing. Testing what you have done so that you can determine whether or not you have solved the problem. 24  Section 3: An introduction to software development Activities for the development of a good software system (contd.) 5. Maintenance activity: allows system to evolve within time in order to: - Correct errors, - Adapt SW to a changing environment - Introduce enhancements required by customer (meet users' needs) - Improve SW in anticipation of future changes. Integration is a necessary task within the maintenance activity. 6. Quality management: ensure that the characteristic of good SW is achieved: reliable, flexible, usable, available. 7. Project management: is concerned with controlling the cost of developing such systems. 25 Section 3: An introduction to software development Figure: Life cycle of software development activities 26 Section 3: An introduction to software development  The models of SW development are: Waterfall, Iterative, and incremental model. 1. Waterfall model: It is the classic model where the five activities (analysis, design, implementation, testing, and maintenance) are arranged into a single sequence (purely sequential life cycle).  Waterfall model has not proven satisfactory in practice because: A. A working version of the software system will not be available until late in the testing activity. B. Errors will be detected in testing activity and this is so significant because the developer needs to check all the previous activities to check the source of the error which may cause delay in delivery at the end.  Real projects rarely follow a purely sequential life cycle. 27  Section 3: An introduction to software development 2. Iterative and incremental development.  It is often difficult to identify all requirements and state them explicitly at the outset of a development project. It is a good idea to start with a subset of the requirements and incrementally grow the system with feedback from each iteration. This approach is known as iterative and incremental development.  Each iteration is a complete small project, with a short, fixed timeframe (timeboxed), consisting of requirements, design, implementation, testing and integration, and resulting in a partially working system. Each of these repeated short iterations adds complexity until the final system is produced. 28  Section 3: An introduction to software development Figure 6 Iterative and incremental development process (Larman 2005, p. 20)  In an iterative and incremental development, users obtain useful and usable software quickly.  This method also enables the developers to take on board feedback from users as the software develops – an increment may simply be an enhancement of the previous version.  Increments can be developed sequentially or in parallel, depending on circumstances. 29  Section 3: An introduction to software development  Agile development  Agile development has become, in the last twenty years, a popular approach to software development. It is an umbrella term used to describe a variety of (agile) methods that promote a set of practices that encourage simpler, more light- weight, faster and nimbler software development that can adapt to the inevitable changes in customer requirements.  The continual realignment of development goals with the needs and expectations of the customer aims at software that better serves its purpose.  Agile development is an approach to software development that puts people and working software at the forefront of the development process. ◦ We will be using the term agile (with a small ‘a’) to refer to best practices, as opposed to Agile (with a big ‘A’) to refer to specific agile methods. We will use the term plan-driven development to distinguish traditional, more prescriptive approaches to software development from agile development approaches. 30  Section 3: An introduction to software development  Dealing with risk  A software solution to a problem needs to be considered in the broad context of the domain to allow you to manage the risks associated with a development project.  There are additional risks when developing large projects because the chances of failure increase as the size of a software project increases, as more errors are likely to be introduced. Effective communication between the members of a large team also becomes more difficult.  Assessing risks and taking steps to reduce them are important activities in software development – this is known as risk management. 31  Section 3: An introduction to software development Dealing with risks  Risk assessment is an important feature of software development. Figure: A spiral process to deal with risk 32  Section 3: An introduction to software development Traceability  The ability to trace the history of each requirement in a software development process is known as traceability.  Traceability is important for the reconstruction of significant events. In software development it should be possible to follow all the activities undertaken in response to a proposed change. In particular, you should be able to trace backwards from an implemented component or components, through their design, to a given requirement. 33  Section 3: An introduction to software development  A project notebook is a disciplined approach to organizing your thoughts and actions.  Your project notebook is a record of notes, thoughts, drawings, ideas and decisions (and the reasons for taking those decisions) as you work on a project.  In its simplest form, a project notebook will be paper-based, but it could be recorded in files on a personal computer.  You must keep accurate dates and times for the information recorded in your notebook for the following three reasons (all of which relate to traceability): - Your project notebook may be required as evidence in some enquiry or even in a court of law. - It helps you to review what you have done and how long you took to do some task. - It facilitates learning. 34  Section 3: An introduction to software development Summary of section This section considered how you might approach the development of a good software system as follows.  Large software projects are prone to problems because of their size and complexity.  Software is inherently easy to change, and this makes it easy to introduce new errors (‘break’ it).  Software development is similar to engineering when it involves a defined process with clear activities, each of which has one or more products that can be tested against the users’ requirements.  A basic process for the development of software is a set of rules that define how a software development project should be carried out. It incorporates a number of activities, and a life cycle (or process model) that indicates how these activities are ordered. It helps to coordinate and control the use of those methods and any tools that support them.  Process models can be sequential, iterative, incremental or some combination of these.  A disciplined approach to software development implies that you must make some effort to record your activities from both a personal view and a project view. It means that documentation is an important task for all those who work on a project. In particular, it must be sufficient for the level of traceability required.  An agile approach to software development puts an emphasis on people rather than on process or documentation, on short iterations and quickly working software, and on the acceptance that systems change. It also encourages practices that promote cooperative work in software development. 35 Section 4: Modelling in software development  Modeling: is a way of thinking about things and ideas in the 'real world'.  A model, in terms of software development, is an abstract representation of a specification, a design or a system, from a particular point of view.  It is a simplification of reality, created in order to understand an aspect of the system in question.  A ‘good model’ is an abstraction that allows those involved to concentrate on the essentials of a complex problem by excluding non-essential details while capturing those of interest.  In Software development, models are: - A way of understanding the problems involved. - An aid to communicate especially between developers. - A component of the methods used in development activities such as analysis and design. 36 Section 4: Modelling in software development  Agile modelling  Agile modelling is Scott Ambler’s approach to lighter modelling (Ambler, 2002).  It proposes a set of values, principles and practices to help software developers become agile modellers.  A typical activity of an agile modeller is to stand up with others in front of a whiteboard, sketch a few models, discuss these sketches, and then discard them if they serve no further need.  There are also tools to help in the creation of models from existing software.  They can be used to document a piece of code that has not been modelled throughout development. 37 Section 4: Modelling in software development  It is better to use standard notation in modeling throughout SW development process i.e. modeling language.  A modeling language is based on diagrams and their construction, meaning and use.  There are two rules within a diagram based modeling language: 1. Syntax: determine what diagrams exist and what symbols are used for. 2. Semantic: what these symbols mean.  The modeling language you select must: 1. Allows to express many facets of the subject. 2. Helps you to resolve misunderstanding rather than introducing new ones. 3. Is easy to learn and use. 4. Is supported by tools. 5. Is used widely and accepted in industry. 38 Section 4: Modelling in software development  The Unified Modeling Language (UML): is a standard modeling language, which is diagrammatic, but also allowing developers to add text, and is easy to use, efficiently expressive, unambiguous, widely used and supported by tools.  Using a standard modeling language is important: 1. It helps when new people join a project.  It reduces the time needed to enable them to become productive team members. 2. It is likely that project components will have been constructed using that language.  This makes the software easier and cheaper to maintain. 39 Section 4: Modelling in software development Models illustrate points of view  During SW development, you will be interested in different aspects or views of the problem and its solution at different times. This implies constructing different models.  When it comes to the development of an object-oriented software system, there are two distinct kinds of model: ◦ structural (or static) models, which describe the objects in the real world or in a (software) system and their relationships to other objects ◦ behaviour (or dynamic) models, which describe the behaviour in the real world or of a (software) system over time. 40 Section 4: Modelling in software development Models illustrate points of view  This simple partition of a software system to static and dynamic is not enough. ◦ For example, in a distributed system a developer must also consider the location of the modules (or classes). ◦ So the overall process of software development takes a number of different views into account.  A software architecture is a way of identifying the differing views.  In practice, the developers are likely to produce a system architecture for the software system during certain project activities such as analysis or design.  Each view can be thought of as a model that expresses a particular aspect of the overall system – each one is an abstraction. 41 Section 4: Modelling in software development Introducing the Unified Process  The Unified Process (UP) (Jacobson et al, 1999) has emerged as a popular iterative and incremental development process for building enterprise systems based on an object-oriented approach, and using UML.  Best practices promoted by UP are: ◦ development is organised in short timeboxed iterations and that it should be adaptive to accommodate inevitable change ◦ dealing with high-risk issues in early iterations ◦ prioritising the user’s perspective by involving users in requirements, evaluation and feedback ◦ building a view of the system’s architecture in early iterations. 42 Section 4: Modelling in software development  A UP project is organised into four major phases: 1. Inception: The business case is developed, together with an idea of the scope of the system and a rough estimate of the effort required. 2. Elaboration: The core of the system is developed in an iterative fashion. In this phase all major risks are addressed and resolved, most of the requirements are identified and dealt with, and a more realistic estimate of the effort required is made. 3. Construction: The final product is constructed, including the remaining lower-risk and easier elements of the system, again in an iterative fashion. 4. Transition: This includes beta testing and deploying the system. 43 Section 4: Modelling in software development The figure illustrates what a UP project might look like. The columns represent iterations. For each discipline, the relative effort is represented throughout the UP.phases and their iterations For instance, most of the domain modelling (referred to as business modelling in the UP) occurs in the early iterations of the inception and elaboration phases, while most of the implementation occurs within the Figure: UP phases and disciplines.construction phase 44 Section 4: Modelling in software development  Views in the UP ◦ The UP was developed by the same people who originally specified UML and UML is its modelling language. A system’s architecture includes models that address five different views: Figure: Five views of a software system’s architecture 45 Section 4: Modelling in software development 1. The use case view contains the basic scenarios that describe the users and the tasks that they need to perform with the aid of a software system.  These scenarios are partitioned into use cases, which we will describe in Unit 3. 2. The logical view is concerned with the functional requirements of the software system. What should the software do for its intended users? Typically this involves the construction models that represent the main elements of a system and how they interact.  We will discuss these models from Block 2 Unit 5 onwards. 3. The implementation view is concerned with the organisation of the code modules that comprise a software system. Typically it addresses the management of source code, data files and executables. 4. The deployment view is concerned with the relationship between the various executables (and other run-time components) and their intended computer systems.  We will touch briefly on implementation and deployment in Block 3 Unit 12. 5. The process view is concerned with aspects of concurrency. What are the processes and threads? How do they interact? It deals with such things as response time, deadlock and fault tolerance.  Concurrency is outside the scope of this module. Note: It is possible to apply the UP in an agile manner and it is often the context in which it is used – the will and experience of developers will dictate whether an agile development takes place 46 Section 4: Modelling in software development Activities and artefacts in the development process  Artefacts refer both to model and other document, the artifact produced from an activity is used to feed into the next activity  The techniques used in the module are not specific to the UP – they can be used in many iterative and incremental processes based on an object-oriented approach to software  Our core activities follow the UP disciplines: ◦ domain modelling – modelling what already exists in the domain ◦ requirements – identifying, categorising, prioritising and modelling what the system must do ◦ analysis – modelling how the structure and behaviour of the system will meet its specification from a user’s perspective, moving from the domain to a software solution ◦ design – deciding on the distribution of responsibilities to fulfil that specification ◦ implementation – producing code that will meet the user requirements ◦ testing – ensuring that the software does meet its requirements ◦ deployment – configuring the code to give a runnable system. 47 Section 4: Modelling in software development Activities and artefacts in the development process  Artefacts refer both to model and other document, the artifact produced from an activity is used to feed into the next activity  Throughout the SW development, the following 7 models are produced: 1. Domain modeling: is concerned with gaining an understanding of the environment in which any system that is designed must operate. During domain modelling, we produce the following artefacts: - Dynamic model: a description of the business processes and behavior of the domain. - Business rules: constraints on the way the above model operates. - Glossary: definitions of relevant terms. - Structural domain model: an initial structural model representing the significant concepts in the domain and how they are related. 48 Section 4: Modelling in software development Activities and artefacts in the development process Requirements  This step is to gather and document the requirements for your system and to model what the system is intended to do.  Requirements are the expression of the things the system must do or the qualities the system must have in order to meet the stakeholders’ needs.  Starting from some description of the problem, you will learn how to systematically record requirements information. ◦ Unit 2 discusses requirements, how they are recorded and the properties we expect them to have. ◦ In particular, you will be shown how to use the Volere template, which provides a disciplined way of recording requirements. ◦ We model requirements at various levels of detail, using use case models, use cases elaborated as text and detailed software requirements stating what the system should do. 49 Section 4: Modelling in software development Activities and artefacts in the development process Analysis  Analysis starts modelling the structure and behaviour of a software solution from a user’s perspective.  During analysis, with both use cases and software requirements, you start looking at a system to be implemented, and build both structural and behaviour models.  The structural model evolves from that of the domain – it no longer represents concepts from the domain, but rather entities in a software solution. This is usually called the analysis model.  Use cases and software requirements lead to the specification of what is expected from the system from the user perspective.  The system operations show how this behaviour can be carried out by the entities chosen.  It is at this stage also that architectural decisions are taken in terms of the  overall structure of the system. 50 Section 4: Modelling in software development Activities and artefacts in the development process Design  Design is concerned with making decisions concerning how a system will meet its specification  During design, your goal will be to decide how the expected functionality is to be allocated to each part of the system.  UML uses interaction (sequence and communication) diagrams that show a set of classes and the messages between them.  During design you produce the following artefacts: ◦ structural model, an updated version of the one produced during analysis but with its operations specified ◦ behavioural models, showing how objects in the system will interact and behave internally, and also how functionality will be distributed across the system. 51 Section 4: Modelling in software development Activities and artefacts in the development process Implementation  The implementation model is a description of the assembled components that comprise the working version of the software.  It describes how classes are packaged together, and shows some of the relationships between such packages of classes.  These relationships are modelled using a component diagram. 52 Section 4: Modelling in software development Activities and artefacts in the development process Testing  The implementation needs to be tested against its requirements to ensure that it meets them.  Tests will be drawn up based on the requirements, and held in test document. (Tests can be drawn up as soon as you know the requirements.)  In the test-driven design approach, the tests for a system are drawn up before design and automated testing procedures are set up.  An initially empty implementation can be run against the tests and the subsequent failure can be used to drive design. As time goes on, this process is repeated as the implementation is built up, until no tests fail. 53 Section 4: Modelling in software development Activities and artefacts in the development process Deployment  Many significant computer systems will consist of a variety of software components located on a number of machines communicating via a variety of hardware and software mechanisms.  A deployment model records how various components are to be mapped onto different machines and how they will communicate.  This can be represented using a deployment diagram. 54 Section 4: Modelling in software development Figure: Some development artefacts 55 Section 4: Modelling in software development Summary of section This section considered the role of modelling in the development of a good software system:  A model is an abstract representation of a concept, a specification, a design or a system from a particular point of view of either the user or the developer. In general, it is a simplification that is used to understand an aspect of the system in question.  A standard modelling language helps those involved in software development projects to communicate effectively. If the standard is widely used, it will reduce the time taken for developers to become familiar with a new project.  The Unified Modeling Language (UML) is a useful standard because it is easy to use, sufficiently expressive, unambiguous and widely used. There are also a variety of tools that support UML.  During software development, there may be many models made from a variety of viewpoints. They must not contradict each other, that is, they must be consistent. 56  Unit Summary On completion of this unit you should be able to:  describe the essential characteristics of a good software system  identify, using examples, the connections between the characteristics of a good software system  explain why a software system can be out of date even as it is being developed  explain the importance of modularisation  suggest reasons why large software projects are prone to problems and give examples to support your case  give examples to support the notion that software development can be considered as an engineering discipline  describe the elements of a basic software development process  illustrate the variety of different life cycles by using examples  explain the role of documentation in a software development project  understand the motivation for, and best practices of, an agile approach to software development  explain why a standard modelling language is beneficial to a development process  explain the benefits of the Unified Modeling Language (UML) as a standard notation for modelling  identify the different kinds of model used in the development of software  describe the relationship between models, viewpoints and software development  understand the relationship between activities and artefacts used in this module. 57