(A Very Brief) Introduction to Engineering Authors: Address: Version: 1.1 Simon Pickin, Marisol García Vals Departamento de Ingeniería Telemática Universidad Carlos III de Madrid Spain 1 Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 2 1
What is Engineering? (1/4) The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines F.L. Bauer. Engineering. Information Processing 71., 1972 3 What is Engineering? (2/4) engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates R. Fairley. Engineering Concepts. McGraw-Hill (New York), 1985. 4 2
What is Engineering? (3/4) engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1) IEEE Std 610-1990 5 What is Engineering? (4/4) Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems. SEI Report on Undergraduate Engineering Education, 1990. 6 3
What is not Engineering? (1/2) Computer science concerned with theory and fundamentals software engineering concerned with practicalities of developing and delivering useful software. still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering). Engineering, Sommerville 7 What is not Engineering? (2/2) System engineering concerned with all aspects of computer-based systems development including hardware, software and process engineering software engineering is the part of this process concerned with developing the software infrastructure, control, applications and databases in the system. system engineers involved in system specification, architectural design, integration and deployment. Engineering, Sommerville 8 4
Why Engineering (1/4)? Term software engineering popularised in the late 1960s Response to the so-called software crisis hardware performance was increasing much faster than software performance. large software system development was unsatisfactory; major projects: were usually delivered late (sometimes very late) usually went over-budget (sometimes massively overbudget) gave rise to unreliable products that were difficult to maintain 9 Why Engineering (2/4)? Techniques used for single-developer software do not scale up. large projects require a team quality of communication between members a serious problem documentation Desire to benefit from previous experience Need to plan for maintenance and evolution important design decisions must be documented 10 5
Why Engineering (3/4)? with the client/user is of paramount importance understand the client requirements e.g. Xtreme programming: client represented on development team 11 Why Engineering (4/4)? Need to estimate how much effort, time and money needed based mainly on modelling of current project & comparison to previous projects do we want the job? how much to charge? c.f. Constructive Cost Model COCOMO Constructive Systems Engineering Cost Model COSYSMO c.f. The mythical man month, Brooks, 1975: adding manpower to a late software project makes it later 12 6
What is a software development process? Process: A series of actions or operations conducing to an end (Websters) development process The set of activities, methods and practices used in the production and evolution of software. 13 What is a software development process? A software development process can include a lifecycle model dividing the development into phases and prescribing the activities to be carried out in each phase providing criteria to determine when each development phase has terminated defining the deliverables / artifacts / products of each phase consideration of tools and equipment consideration of personnel and their organisation constraints on activities, artifacts, tools, personnel, etc. For many authors: Development Process = Life-Cycle 14 7
What is a software life-cycle? The period of time that starts when a software is conceived and ends when the product is no longer available for use. The software life-cycle typically includes a requirements phase, design phase, implementation phase, test phase, installation and check-out phase, operation and maintenance phase, and sometimes, retirement phase. A Lifecycle Model is a particular abstraction that represents a Life Cycle. A Life Cycle model is often called a Development Life Cycle (SDLC). IEEE Standard Glossary of Soft. Eng. Terminology 15 (& Hardware) Modelling Sceptic s view of Models: bubbles and arrows, as opposed to programs, never crash Bertrand Meyer 1997 The use of models is as old as engineering before building the real thing, engineers build models and learn from them Some desirable characteristics of a model abstract understandable accurate predictive inexpensive to build 16 8
Modelling: The Purpose of Models To help us understand a complex problem by analysis and simulation To enable the investigation and comparison of alternative solutions To facilitate the communication of ideas about a problem or a solution To enable the detection of errors and omissions during the design To drive the implementation software peculiarity: the model becomes the implementation 17 Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 18 9
The Development Process System analysis Development Operation and Maintenance User requirements system 19 Waterfall Life Cycle Model (1/2) Requirements analysis Design Implementation and unit testing Integration and system testing Operation and maintenance 20 10
Waterfall Life Cycle Model (2/2) Requirements analysis Specification of software system Design Design of architecture and components Implementation and unit testing Implemented components Integration and system testing Integrated system Operation and maintenance 21 V Life Cycle Model Requirements capture Requirements analysis Architectural design Component design Real world validation System verification Subsystems verification Components verification Operation and Maintenance Acceptance testing System integration Subsystem integration Component coding Unit testing 22 11
Incremental Life Cycle Model Planning of whole system and the different iterations is done at the beginning Development & delivery broken down into increments each increment delivers part of the required functionality User requirements prioritised highest priority included in early increments Requirements for an increment whose development has started are frozen requirements for later increments can continue to evolve. Prototyping: each iteration can be treated as a prototype 23 Evolutionary Life Cycle Model No initial planning of whole system and different iterations final system evolves from initial outline specification Start with well-understood requirements and add new features as proposed by the customer on last iteration Objective of each iteration is to understand the system requirements Prototyping: each iteration can be treated as a prototype 24 12
Spiral Life Cycle Model (generalised) Determine: objectives alternatives constraints Evaluate alternatives Identify and resolve risks Cost Progress Plan next phase Develop next level product and process Verify / validate product and process 25 Spiral Life Cycle Model (original version) Source: A Spiral Model of Development and Enhancement Barry Boehm, IEEE Computer, May 1988 26 13
Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 27 Requirements Engineering Systematic use of well-established principles, techniques, languages and tools to obtain the costeffective analysis and documentation of continuallyevolving user needs and the specification of the external behaviour of a system that satisfies these needs. Donald Reifer (see Pressman) The task of capturing, structuring and accurately representing the user s requirements so that they can be correctly embodied in systems which meet those requirements. FOLDOC (http://foldoc.org/) 28 14
Context of the Analysis Phase Requirements capture / development what Requirements analysis (and specification) design how Usual definition: requirements engineering = requirements capture, analysis and specification Some authors: requirements engineering = requirements analysis requirements capture and specification 29 Structured Analysis data description entity-relation diagrams data dictionary data-flow diagrams functional description state-transition diagrams control description 30 15
OO Analysis Based on objects and their operations/attributes instead of on data flows Currently most commonly-used notation: UML structural models (class model, component model, ) behavioural models (use-cases, state model, collaborations, interactions, ) Structural models via domain analysis Behavioural models use-case modelling is favoured technique other behavioural models can be problematic refinement of analysis model to design model? 31 Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 32 16
Brief Historical Notes (1/2) Late 1960s: control oriented design (Structured Programming) modularity single-entry, single-exit program constructs (sequence, selection, iteration) no use of go to construct (but what about exception handling?) : Goto Statement Considered Harmful, Dijkstra, Comm. ACM, 1969 33 Brief Historical Notes (2/2) 1970s: data-structure oriented design (extension of Structured Programming) program code structure reflects data structure e.g. Jackson Structured Programming 1980s: object-oriented design unifies data-structure oriented and control oriented design (or does it?) currently most commonly-used notation: UML 34 17
What is software architecture? The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of -Intensive Systems 35 Architectures System top-down design Subsystem bottom-up design Component Deployment Unit (not only!) Module Compilation unit Data Functions 36 18
Architecture Essentials Components and subsystems what are the individual elements Connections how components communicate Topology how components and connections are organised Constraints restrictions on components, connections, topology, evolution, 37 Architectural Styles Restrict the way in which components can be connected Promote fundamental principles separation of concerns, generality, incrementality, low coupling, high cohesion, Based on success stories also chosen in function of application type Examples: pipe-and-filter, layers, software bus, client-server, peer-to-peer, hierarchical, centralised control, 3-tier client-server, etc. 38 19
Typical Design Process Specification of software requirements Architectural design Detailed design Subsystems Interfaces Design model: architecture Components Interfaces Design model: components Interactions Modules Control Data Procedures Algorithms 39 Some Basic Design Concepts Abstraction emphasis on important details, omitting characteristics that are not relevant in the context Refinement the process of gradually adding more detail, going from more abstract models to more concrete models Modularity decomposition into components that are to be integrated to satisfy the problem requirements Information hiding ensuring components only make available such information as is needed by other components (interfaces do not show design/implementation details) 40 20
Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 41 Some Design Quality Factors (1/2) External criteria (user point of view) Correctness Reliability Usability / user-friendliness Good performance Robustness Internal criteria (developer point of view) Efficiency Maintainability Reusability Portability Interoperability 42 21
Some Design Quality Factors (2/2) From the maintenance and reuse perspective Functional independence of components High intra-component cohesion Low inter-component coupling Readability / understandability Naming scheme Complete and up-to-date documentation Simplicity / Elegance Adaptability Evolvability and generality Automation of access to documentation Automation of version control 43 SQA: Quality Assurance (1/2) Involves activities performed throughout the software life cycle Definition of verification (after IEEE): ensure a software system, or a model of it, meets a specification (often produced in a previous development phase) concerned with internal consistency are we building the system right? Definition of validation (after IEEE): ensure a software system, or a model of it, meets the requirements (customer s intent) concerned with external consistency are we building the right system? Testing usually considered validation but can also be verification Metrics 44 22
SQA: Quality Assurance (2/2) Source: Object-oriented Engineering. Steven Schach. McGraw-Hill. 45 What Are Formal Methods? Formal semantics: semantics based on set theory, algebra, logic, automata, graph theory, etc. Formal specification: an abstract description with a formal semantics; specification styles: model-oriented property-oriented Formal method: a method used in software/hardware development involving use and manipulation of formal specifications: proving properties on formal specifications deriving implementations, or other software artifacts (e.g. test cases), from formal specifications proving properties on implementations by using an abstract interpretation of the code 46 23
Use of Formal Methods Especially important for safety-critical systems, e.g.: aircraft, trains, metro power grid, power stations telecom networks... Also for secure systems May also be worthwhile for low-cost but massively produced systems Often introduced after serious problem occurs, e.g.: model-checking at Intel after Pentium floating point division error discovered 47 Formal Methods for SQA (1/2) Increase understanding of the system modelled Automate common software development activities code generation test generation / test synthesis Analysis/simulation of models from early phases of software development: early consistency checking early detection of errors, omissions, ambiguities, undesirable properties, 48 24
Formal Methods for SQA (2/2) Analyse implementations detection of errors, omissions, ambiguities, undesirable properties, Model transformation & consistency checking between models: at different levels of abstraction from different development phases 49 Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 50 25
What is software testing? The execution of the software implementation in a controlled fashion using carefully chosen input data and the observation of the result. testing is one aspect of Quality Assurance (SQA) 51 Definition of a test case A specification of an interaction between the Implementation Under Test (IUT) and the test software, or human user (playing the role of the IUT environment), in which the latter stimulates the IUT via its interfaces, observes its behaviour and its responses and, if it includes a test oracle, assigns a verdict to the result of this interaction. A test case is designed to exercise a particular execution or verify compliance with a specific requirement. 52 26
Testing: True or False (1/3) The effort that must be dedicated to testing is under-estimated by most software developers. undoubtedly; developers tend to think in terms of lines of code per day Testing must always be carried out by people from a different team to the development team. not all testing always (e.g. unit testing), but some testing always No testing can be carried out until the implementation of the whole application is available. e.g. unit testing Testing is more of a craft than a science. experience of the test personnel is often crucial No test cases can be written before the code to be tested is available. not always (e.g. unit testing with JUnit) 53 Testing: True or False (2/3) The ultimate goal of testing is to demonstrate that the software being developed is error-free. impossible to do with testing After fixing errors found in the testing phase the software being developed should be re-tested. the errors may not have been fixed and the attempt to fix them (successful or not) may have introduced new errors The testing phase of a typical software development life cycle terminates when the software being developed contains no more errors. one can never be sure of this If a module from a well-tested software product is re-used in another product from the same product line, it does not need re-testing. e.g. Ariane 5 54 27
Testing: True or False (3/3) Testing activities can be easily automated. this is precisely why it is still more of a craft than a science All errors found in testing of a software product under development should be fixed before the product is released. Always a compromise between severity of the error and cost of fixing it Automatic test generation has the potential to produce huge productivity gains automation is difficult but very desirable When software is modified, the test cases that were used on the previous version should be executed on the modified version. this is regression testing; new test cases may also be necessary, of course 55 Basic Testing Notions (1/2) The goal of testing is to find errors NOT to prove their absence a successful test finds an error no amount of testing can guarantee an error-free program Should test that the application does what it is supposed to do does not do what it is not supposed to (as far as possible). Testing approaches (sometimes term grey box is also used) black box testing white box testing (structural testing) Testing phases unit testing integration testing system testing 56 28
Basic Testing Notions (2/2) Test coverage white box: segments, branches, conditions, loops, black box: requirements Test data selection (mainly for black box) equivalence partition (uniformity hypothesis) boundary value analysis Other types of testing acceptance testing performance testing robustness testing stress testing interoperability testing regression testing mutation testing 57 Contents 1. Overview / definition of terms 2. Lifecycle models 3. Requirements capture, analysis and specification 4. design 5. quality 6. testing 7. Some recent developments 58 29
Some Recent Developments (1/3) Design patterns general, repeatable solution to a commonly-occurring problem in software design inspiration in architecture, esp. work of Christopher Alexander insufficient theoretical foundation? frameworks: a reusable design for a software system or subsystem (architectural pattern?) product lines software development process for a set of related products generally use software frameworks 59 Some Recent Developments (2/3) Lightweight development (in response to software & documentation bloat ): extreme programming, Scrum, etc. agile modelling Model driven development primary artifacts are models rather than programs ( code generation) OMG s MDA initiative (PIMs and PSMs) design refactoring Service-oriented architecture (SOA) architectural style whose goal is to achieve loose coupling among interacting software agents playing producer or consumer roles 60 30
Some Recent Developments (3/3) Component Based Engineering system assembled (at least partially) from existing cmpnts. Open Source Engineering collaboration between often large numbers of spatiallyseparated developers novel management and organisational structure heterogeneity in use of tools, approaches etc. study of relation to traditional S.E. on-going Web Engineering (development of Web applications) currently very popular types of applications are there particular development characteristics or is it just hype? 61 31