Introduction to Software Engineering 1 Envergure porte Engineering

Introduction to Software Engineering 1

Envergure, portée Engineering Software engineering is a discipline whose aim: ® is the production of fault-free software, ® that is delivered on time, ® within budget, ® and satisfies the user’s needs. 2

Engineering Envergure, portée Historical Aspects: ® 1967, a NATO group invent the term “Software Engineering” ® 1968 NATO Software Engineering Conference concurred that “Software production should be an engineering-like activity”. ®Using philosophies and paradigms of established engineering disciplines to solve: “Software Crisis: that the quality of software was generally unacceptably low and that deadlines and cost limits were 3

Engineering? m The definition given in IEEE is : Software engineering is the application of a systematic, disciplined, quantified approach to the development, operation, and maintenance of software. m The essential characteristics of the field are always, explicitly or implicitly, present: ® Software engineering concerns the construction of large programs ® The central theme is mastering complexity ® Software evolves ® The efficiency with which software is developed is of crucial importance ® The software has to support its users effectively 4

Engineering Maintenance is so important, a major aspect of software engineering consists of techniques, tools, and practices that lead to a reduction in maintenance cost. Approximate relative costs of the phases of the software life cycle. Maintenance 76% 5

Scope of Software Engineering m Specification and Design Aspects ® Software professionals are humans, and humans can error. make ® The fact that so many faults are introduced early in the software life cycle, highlights another important aspects of software engineering, namely, techniques that yield better specifications and designs. ü For example, reducing specification and design faults by 10% will reduce the overall number of faults by 6 -7%. m Team Programming Aspects ® Most software being developed and maintained by a team of software engineers ® Scope of software engineering must also include techniques for ensuring that teams are properly organized and 6

of a “software development project” Information planning Boundary conditions documentatio n people input progra m software output progra m procedures We do not just develop software, we develop systems. A system transforms inputs into outputs Software is an important ingredient of the systems we develop. The technical and user documentation, the hardware, the procedures that govern the use of the system, and even the people using the software, may be considered as part of that same system. 7

Software ®Programs ®Documentation during the development of programs (e. g. specification) ®Primary aids for running the programs (e. g. user manuals) ®Secondary aids for running the programs (e. g. key boards overlays) Software is not just programs! 8

Software Life Cycle ® Software is like humans. ® It has a life cycle. ® Software in a system is conceptualized first. ® It becomes obsolescent at the end. ® The period in between is called the software life cycle. 9

Software Life Cycle Sotware Planning − Requirements − Specification (Analysis) − Design − Implementation • • • Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance − Integration − Maintenance (highest cost among all these phases) üCorrective, Perfective, and Adaptive Maintenance ÃRetirement 10

The Software Process (Simplified) A simple view of software development Feasibility and Planning Requirements specification Design Implementatio n Design: During the design phase, a model of the whole system is developed which solves the problem for the user. à The problem is decomposed into manageable pieces called modules or components. The functions of these modules and the interfaces between them are specified in a very precise war Operation and Maintenanc e 11

Software Life Cycle Models (Processes( ® Build-and-Fix Model ® Waterfall Model ® Rapid prototyping model ® Incremental Model ® Spiral Model ® Concurrent Development Model ® … 12

Requirements Analysis and Definition m The system's services, constraints and goals are established by consultation with system users. m They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into: ® Feasibility study (often carried out separately) 13

Requirements Phase: Feasibility Study Before beginning a project, a short, lowcost study to identify ® Client ® Scope ® Potential benefits ® Resources needed: staff, time, equipment, etc. ® Potential obstacles Where are the risks? How can they be minimized? 14

Requirements Phase: Feasibility Study A feasibility study leads to a decision: ü ü ü go ahead do not go ahead think again In production projects, the feasibility study often leads to a budget request. In research, a feasibility study is often in the form of a proposal. 15

How to Minimize Risk? ®Several target levels of functionality: required, desirable, optional ®Visible software process: intermediate deliverables ®Good communication within team and with Teaching Assistant Good processes lead to good software Good processes reduce risk 16

Feasibility Report A written document ® For a general audience: client, financial management, technical management, etc. ® Short enough that everybody reads it ® Long enough that no important topics are skipped 17

The Requirements Process Feasibility Study Requirements Analysis Requirements Definition System Models Feasibility Report Requirements Specification Definition of Requirements Document Specification of Requirements 18

Requirements Definition High-level abstract description of requirements: ®Specifies external system behavior ®Comprehensible by customer, management and users Should reflect accurately what the customer wants: ®Services that the system will provide 19

Requirements Definition Non-functional Requirements Environment: ®Estimates of sizes, numbers of users, etc. ®Reliability and performance measures and targets Preferred: ®Hardware and software systems (e. g. Unix…) ®Database systems (e. g. , Oracle…) ®Programming languages (e. g. , C and C++) 20

Requirements Definition Evolution of Requirements ®If the requirements definition is wrong, the system will be a failure. ®With complex systems, understanding of requirements always continues to improve. Therefore. . . ®The requirements definition must evolve. ®Its documentation must be kept current (but clearly identify versions). 21

Requirements Analysis Methods for data modeling and design ®Data flow diagrams ®Entity-relation diagrams ®Data dictionaries ®Object models Many of these methods blur the distinction between analysis and design. 22

Non-Functional Requirements m Product requirements ® performance, reliability, portability, etc. . . m Organizational requirements ® delivery, training, standards, etc. . . m External requirements ® legal, interoperability, etc. . . 23

Requirements Specification What is the purpose of the Requirements Specification? 24

Requirements Specification: Purpose m It describes the requirements to the stakeholders ® Expressed in the terms that the stakeholders understand ® Comprehensible from many viewpoints ® Reviewed by stakeholders so that they understand implications ® Must be clear about assumptions (things left out) m It describes the requirements to the implementers ® As precise and specific as possible ® Expressed in terms that they understand ® Comprehensible to new team members m It records the requirements for the future ® An essential part of system evolution m If may be a contractual document 25

Requirements Specification: Approaches ®Natural language ®Structured natural language ®Design description language ®Requirements specification language ®Graphical notation ®Formal specification 26

Requirements Engineering REQUIREMENTS ELICITATION AND ANALYSIS Problem analysis Have we captured all the user need? Problem description Prototyping and testing Are we using the right techniques or views? Is this function feasible? REQUIREMENTS DEFINITION AND SPECIFICATION Documentation and validation Have we captured what the user expects? 27

Requirements ®Goal − To understand the problem ®Necessary to Understand Requirements − Organization − Existing Systems − Processes − Improvements ®Once you have all this information, now what? 28

Requirements Elicitation Techniques ® ® Interview / Meeting Survey / Questionnaire Observation Ethnography / Temporary Assignment ® Business Plans ® Review Internal / External Documents ® Review Software 29

Requirements Analysis ® Goal To bridge the gap between the problem domain and the technical domain ® Tasks − Problem Recognition − Evaluation and synthesis − Modeling − Specification − Review 30

Requirements Analysis Principles ® Information domain of a problem must be represented and understood ® Models that depict system information, function, and behavior should be developed ® Models must be partitioned in a manner that uncovers detail in a layered fashion ® Analysis process should move from essential information toward implementation detail 31

Requirements Review? ® Are the requirements complete? ® Are the requirements concise? ® Are the requirements correct? ® Are the requirements consistent? ® Are the requirements modular? Can they accommodate change? ® Are the requirements realistic? ® Is the requirement needed by the customer? ® Are the requirements traceable? 32

Waterfall Model System and Software Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs Unified Modeling Language (UML) 33

Waterfall Model Integration and System Testing The individual program units are: ® integrated and tested as a complete system ® tested against the requirements as specified ® delivered to the client 34

Waterfall Model Operation and Maintenance ®Operation: The system is put into practical use. ®Maintenance: Errors and problems are identified and fixed. ®Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment. 35

Software Life Cycle Models (Processes) −Build-and-Fix Model −Waterfall Model −Rapid prototyping model −Incremental Model −Spiral Model −Concurrent Development Model −… 36

Software Life Cycle Models Built-and-Fix Model ®Unfortunately, many software products are developed with built-and-fix model. ®Without specification or any attempt in design, just build a product, and reworked as many times to satisfy the customer. needed ®Unsatisfactory for any size of software development, we better specify the various phases of software process. 37

Why use a life cycle model? ®Life cycle model breaks down the development Software Life Cycle Models process into phases or stages. ®This is because software development is complex. ®Breaking down the development process makes it easier to manage. ®Each phase can be performed in various ways. 38

Waterfall Model Software Life Cycle Models Requirement Changed Requirements verify Verify Specification Design Verify Implementation Testing Integration Development Maintenance Testing Operation Mode Retirement 39

Discussion of the Waterfall Model Advantages: ®Process visibility ®Dependence on individuals ®Quality control ®Cost control Disadvantages: ®Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised. 40

Rapid Prototyping Model Software Life Cycle Models ®A rapid prototype − is a working model − that is functionally equivalent to a subset of the product (internal structure is not concerned yet). ®The soleseul use of rapid prototyping: − is to determine what the client’s real needs are, − construct the rapid prototype as rapidly as possible to speed up the software 41

Rapid Prototyping Model Software Life Cycle Models Rapid Prototype Changed Requirements verify Verify Specification Verify Planning Verify Design Verify Implementation Testing Integration Development Testing Operation Mode Maintenance Retirement 42

Incremental Model Software Life Cycle Models ® The s/w product is designed, implemented, integrated, and tested as a series of incremental builds, − where a build consists of code pieces from various modules interacting to provide a specific functional capability. ® It is sometimes necessary to re-specify, re-design, re-code, or at worst, throw away what has already been completed and start again. 43

Incremental Model Software Life Cycle Models Requirement Verify Specification Verify Planning Verify Architectural Design Verify For each build: • • Development Perform detailed design, implementation, and integration. Test. Deliver to client. Operation Mode Maintenance Retirement 44

Spiral Model Software Life Cycle Models m The idea of minimizing risk via the use of prototypes and other means is the concept underlying the spiral model. m A simplified spiral model is as a waterfall model with each phase preceded by risk analysis. ® Before commencing each phase, an attempt is made to control (resolve) the risks. If it is impossible to resolve all the significant risks at a stage, then the project is immediately terminated. 45

Full Spiral Model [Boehm, IEEE 1998] Software Life Cycle Models Determine objectives, alternatives, constraints Cumulative cost Progress through steps Evaluate alternatives, identify, resolve risks Risk Analysis Commitment Prototype 1 Prototype 2 Review Partition Risk Analysis Requirement plan life-cycle plan Development Plan Software Requirements Plan next phase Integration and Test Plan Detailed Design Software Product Design Code Unit Test Design validation and verification Implementation Operational Prototype Simulations, models, benchmarks Concept of Operation Requirement Validation Prototype 3 Acceptance Test Integration Test Develop, verify next-level product 46

Software Development m Software is developed using a life cycle model. m Just a life cycle model is insufficient for development. m We need: ® A broad philosophy ® A set of tools which support the philosophy. ® A language which supports the philosophy. 47

Software Development Paradigm m A paradigm provides a general approach to work during each phase of the life cycle model. m A paradigm is a broad philosophy. m A paradigm is not a specific model. m Some Software Development Paradigms ®Functional Composition ®Logic Programming ®Structured Development ®Object Orientation 48

Structured Development m Also called SASD, SADT & Functional Decomposition. m Breaks the system into processes & decomposes them. m Languages C, Fortran, Pascal, Cobol, Basic and a lot more support this paradigm. m By far the most popular paradigm. 49

Object Orientation ®Most recent paradigm. ®Treats a problem as a collection of objects. ®Becoming very popular now. ®More and more languages support this paradigm now. ®Tools for OO − Rambaugh (OMT) − Coad-Yourdon − Booch − UML 50