Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution Structured programming Product SW. Data orientation Expert systems AI distributed systems parallel programming

Topic (1)Software Engineering (601321)2 Introduction Software Engineering is concerned with theories, methods and tools needed to develop high quality software products in a cost effective way. Cost effective: –limited resources. –Time schedule.

Topic (1)Software Engineering (601321)3 Software Engineering Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software

Topic (1)Software Engineering (601321)4 Software products A Software: computer programs and associated documentation and configuration files Software products may be:  Generic products developed to be sold to a range of different customers (on the open market to any customer).  Customised products (Bespoke) developed for a specific customer according to their specification.

Topic (1)Software Engineering (601321)5 The software development process Structured set of activities required to develop or evolve a software product Generic activities in all software processes are: –Requirement specification - what the system should do and its development constraints –Design & Development – design and production of the software system –Validation - checking that the software is what the customer wants –Evolution - changing the software in response to changing demands

Topic (1)Software Engineering (601321)6 Software Process Model A simplified representation of a software process, presented from a specific perspective Generic process models: –The waterfall model Separate and distinct phases of specification and development –Evolutionary development Specification and development are interleaved –Formal system development A mathematical system model is formally transformed to an implementation –Reuse-oriented development The system is assembled from existing components

Topic (1)Software Engineering (601321)7 Waterfall model

Topic (1)Software Engineering (601321)8 Evolutionary development

Topic (1)Software Engineering (601321)9 Evolutionary model Exploratory prototyping –Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements Throw-away prototyping –Objective is to understand the system requirements. Should start with poorly understood requirements

Topic (1)Software Engineering (601321)10 Formal System Development Requirement definition Formal specification Formal transformation executable program Integration and system testing

Topic (1)Software Engineering (601321)11 Reuse-oriented development Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Process stages –Requirement specification –Component analysis; –Requirements modification; –System design with reuse; –Development and integration. –System validation

Topic (1)Software Engineering (601321)12 Spiral model (1) (2) (3) (4)

Topic (1)Software Engineering (601321)13 Sectors of the spiral model Objective setting –Specific objectives and constraints of the phase. Risk assessment and reduction –Risks are analyzed and information is sought to reduce these risks Development and validation –An appropriate model is chosen and used for the development of this phase Planning: The project is reviewed and plans drawn up for the next round of the spiral

Topic (1)Software Engineering (601321)14 Template for a spiral round Objectives Constraints Alternatives Risks Risk resolution Results Plans Commitment

Topic (1)Software Engineering (601321)15 Software process-characteristics Visibility –Is the process progress externally visible? Supportability –Can the process be supported by CASE tools? Reliability –Are process errors discovered before they result in product errors? Robustness –Can the process continue in spite of unexpected problems?

Topic (1)Software Engineering (601321)16 Process visibility Software systems are intangible so managers need documents to assess progress However, this may cause problems –The time taken to review and approve documents is significant –The need to produce documents constraints process iteration

Topic (1)Software Engineering (601321)17 Computer-aided software Engineering Software tools that support the software development process CASE technology has resulted in significant improvements in quality and productivity But, they should be carefully chosen and staff should be properly trained.

Topic (1)Software Engineering (601321)18 CASE classification CASE systems can be classified according to their –Functionality - what functions do they provide –Process support - what software process activities do they support –The breadth of support which they provide Classification allows tools to be assessed and compared Tools unevenly support phases of the software cycle. (e.g. design and implementation are well supported, but not maintenance and specification)

Topic (1)Software Engineering (601321)19 CASE classification Classification according to breadth: –Tools support single tasks (e.g. documentation, compilation) –Workbenches support activities in a process phase (e.g. design, specification) –Environment support all or most of the software development process.

Topic (1)Software Engineering (601321)20 Software quality/ attributes Testability Maintainability Portability Interoperability Reusability EfficiencySecurity Usability Reliability operational Product revision Product transition

Topic (1)Software Engineering (601321)21 Software quality/ attributes Reliability : The extent to which the program can be expected to perform its intended function with required precision under all conditions. Efficiency : The amount of computing resources required by the program. Security : The extent to which access to data and software by unauthorized persons can be controlled.

Topic (1)Software Engineering (601321)22 Software quality/ attributes Usability : The effort required to learn and operate the software. (user interface, documentation). Maintainability : The effort required to meet changes in user needs. Testability : The effort required to test a program to ensure that it performs its intended function.

Topic (1)Software Engineering (601321)23 Software quality/ attributes Portability : The effort required to translate the program from one HW and/or SW environment to another. Reusability : The extent to which a program or part of it can be reused in other applications. Interoperability : The effort required to couple one system to another.

Topic (1)Software Engineering (601321)24 System Engineering Designing, implementing and installing systems which include hardware, software and people System: a collection of interrelated components working together towards some common objective A system may include software, mechanical, electrical and electronic hardware and be operated by people Large systems are used to solve ‘wicked problems’

Topic (1)Software Engineering (601321)25 System Engineering The behaviour of system components depend on other components System properties can be ‘emergent’ (e.g. reliability) Emergent properties are a consequence of the relationships between system components System and its environment

Topic (1)Software Engineering (601321)26 System failures System failures often occur because of unforeseen inter- relationships between components Hardware reliability What is the probability of a hardware component failing and how long does it take to repair that component? Software reliability How likely is it that a software component will produce an incorrect output. Software failure is usually distinct from hardware failure in that software does not wear out. Operator reliability How likely is it that the operator of a system will make an error?