Software Engineering A layered Technology Software engineering

Software Engineering – A layered Technology Software engineering encompasses a process, technical methods, and the use of tools. l l l Process: p-23 Method : p-23 Tools: p-24 Slide 1

A Layered Technology Communication Software Engineering Requirements Design Code tools Testing Deployment Methods “how to’s” support process model a “quality” focus Slide 2

Software Process l l Activities in software projects Characterised by a common process framework • Framework activities - task sets • Umbrella activities l “Process maturity” enables development of quality software products Slide 3

A Common Process Framework Slide 4

Software Engineering Umbrella Activities : l l l l Software project tracking and control Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management Slide 5

Process as Problem Solving Slide 6

Process Types … l l Process for software development: produces software as end-result Process for managing the project • defines project planning and control • effort estimations made and schedule prepared • resources are provided • feedback taken for quality assurance • monitoring done. Process for change and configuration mgmt. • Resolving requests for changes • Defining versions, their compositions • Release control Process for managing the above processes themselves • Improving the processes based on new techniques, tools, • Standardizations and certifications (ISO, CMM) Slide 7

Characteristics of a Good Process l l Should be precisely defined – no ambiguity about what is to be done, when, how, etc. It must be predictable – can be repeated in other projects with confidence about its outcome • Predictable with respect to effort, cost: Project A: Web-based library applications done by 3 persons in 4 months another project B (guest house bookings), similar in complexity should also take about 12 person months. • Predictable for quality: with respect to number and type of defects, performance, … Slide 8

A Good Process … l l Predictable process is said to be ‘under statistical control’ , where actual values are close to expected values It supports testing and maintainability • Maintenance by third party • Follow standards, provide necessary documentation • This characteristic differentiates between prototype and product l Facilitates early detection of and removal of defects • Defects add to project cost • Late detection/correction is costly l It should facilitate monitoring and improvement • Based on feedback • Permit use of new tools, technologies • Permit measurements Slide 9

Generic Phases l Definition Phase • Focus on ‘what’ the software is l Development Phase • Focus on ‘how’ the software works l Maintenance Phase • Focus on ‘change’ to the software Slide 10

Generic view/ Phases Software Engineering l l l Definition phase - focuses on what (information engineering, software project planning, requirements analysis). Development phase - focuses on how (software design, code generation, software testing). Maintenance phase - focuses on change (corrective maintenance, adaptive maintenance, perfective maintenance, preventive maintenance). Slide 11

Successful software system l l Software development projects have not always been successful When do we consider a software application successful? • • l Development completed It is useful It is usable, and It is used Cost-effectiveness, maintainability implied Slide 12

Reasons for failure l l l Schedule slippage Cost over-runs Does not solve user’s problem Poor quality of software Poor maintainability Ad hoc software development results in such problems • • • No planning of development work (e. g. no milestones defined) Deliverables to user not identified Poor understanding of user requirements No control or review Technical incompetence of developers Poor understanding of cost and effort by both developer and user Slide 13

Capability Maturity Model (CMM) Level 5: Optimizing Level 4: Managed Level 3: Defined Level 2: Repeatable Level 1: Initial Slide 14

CMM There must be a commitment to QA. SEI developed a process model to measure Quality l Level 1: Initial- ad hoc software processes l Level 2: Repeatable- able to repeat earlier successes l Level 3: Defined- management and engineering processes documented, standardized, and integrated into organization-wide software process l Level 4; Managed- software process and products are quantitatively understood and controlled using detailed measures l Level 5: Optimizing- continuous process improvement is enabled by quantitative feedback from the process and testing innovative ideas Slide 15

Key process areas Slide 16

Key Process Areas (KPA) l l l CMM Level 2 l l l l CMM Level 3 l l CMM Level 4 l l CMM level 5 l l SW configuration management SW quality assurance SW subcontract management SW project tracking SW project planning Requirements management Peer reviews Inter-group coordination SW production engineering Integrated software management Training Organization process definition Organization process focus Software quality management Quantitative process management Process change management Technology change management Defect prevention Slide 17

Generic Framework activities/ Five Framework Activities: l l l Communication Planning Modeling • • l Construction • • l Analysis of requirements Design Code generation Testing Deployment Slide 18

Generic Framework activities l l l Communication • Get to know your Customer and their processes • Identify stakeholders • Requirement elicitation Planning • Plan the work • Identify resources • Identify tasks • Set the schedule Modeling • Analysis of requirements • Design • Blue print for customer and • developers communications Construction • Code generation • Testing Deployment • Customer evaluation and feedback Slide 19

v. Generic Activity of software process Generic activities in all software processes are: • Specification - what the system should do and its development constraints • Design and implementation/Development - production of the software system • Validation - checking that the software is what the customer wants • Evolution - changing the software in response to changing demands. Slide 20

1. Software specification l l The process of establishing what services are required and the constraints on the system’s operation and development Requirements engineering process (4 steps) Slide 21

2. Software design and implementation The process of converting the system specification into an executable system l Software design • l Implementation • l Design a software structure that realises the specification Translate this structure into an executable program The activities of design and implementation are closely related and may be inter-leaved Slide 22

The software design process Slide 23

Design methods l l l Systematic approaches to developing a software design The design is usually documented as a set of graphical models Possible models • • Data-flow model Entity-relation-attribute model Structural model Object models Slide 24

Programming and debugging l l Translating a design into a program and removing errors from that program Programming is a personal activity - there is no generic programming process Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process The debugging process Slide 25

3. Software validation l l l Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customer Involves checking and review processes and system testing System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system Slide 26

The testing process Slide 27

Testing phases Slide 28

4. Software evolution l l l Software is inherently flexible and can change. As requirements change through changing business circumstances, the software supporting the business must also evolve and change Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new Slide 29

Automated process support (CASE) l l l Software systems that are intended to provide automated support for software process activities. CASE systems are often used for method support. Upper-CASE • l Tools to support the early process activities of requirements and design; Lower-CASE • Tools to support later activities such as programming, debugging and testing. Slide 30

What is CASE? l l CAD/CAM - Computer-aided design & manufacturing Automated support for software engineering process Provides engineer with ability to automate manual activities and improve engineering insight and quality Can be single tool or complete environment Slide 31

CASE classification l l Classification helps us understand the different types of CASE tools and their support for process activities Functional perspective • l Process perspective • l Tools are classified according to their specific function Tools are classified according to process activities that are supported Integration perspective • Tools are classified according to their organisation into integrated units Slide 32

Functional tool classification Slide 33

Activity-based classification Slide 34

CASE integration l Tools • l Workbenches • l Support individual process tasks such as design consistency checking, text editing, etc. Support a process phase such as specification or design, Normally include a number of integrated tools Environments • Support all or a substantial part of an entire software process. Normally include several integrated workbenches Slide 35

Tools, workbenches, environments Slide 36

Building Blocks for CASE Tools Integration Framework Portability Services Operating System Hardware Platform Environment Architecture Slide 37

v. CASE Building Blocks l l l CASE tools Integration framework(specialized programs allowing CASE tools to communicate with one another) Portability services (allow CASE tools and their integration framework to migrate across different operating systems and hardware platforms without significant adaptive maintenance) Operating system (database and object management services) Hardware platform Environmental architecture (hardware and system support) Slide 38

Taxonomy of CASE Tools l Business Systems Planning • Information Engineering Tools • Process Modeling and Management Tools l Project Management • • • Project Planning Tools Risk Analysis Tools Project Management Tools Requirements Tracing Tools Metrics and Management Tools Slide 39

Taxonomy of CASE Tools (Continued) l Support Tools • • • l Documentation Tools System Software Tools Quality Assurance Tools Database Management Tools Software Configuration Management Tools Analysis and Design Tools • PRO/SIM Tools • Interface Design and Development Tools • Prototyping Tools Slide 40

Taxonomy of CASE Tools (Continued) l Programming Tools • • • l Integration and Testing Tools Static Analysis Tools Dynamic Analysis Tools Test Management Tools Client/Server Testing Tools Maintenance Tools • Reengineering Tools Slide 41

Integrated CASE (I-CASE) l l Integration of a variety of tools and information that enables closure of communication among tools, between people and across the software process Combination of CASE tools in an environment where interface mechanisms are standardised Slide 42

Benefits of I-CASE l l Smooth transfer of information from a tool to another and one SE step to the next Reduction in effort to perform umbrella activities such as SCM, SQA and document production increase in project control Improved coordination among staff members in a large software project Slide 43

Integration Framework Diagram User interface layer - interface tool kit - presentation protocol Tools management services CASE Tools layer tool Object management layer - integration services - configuration management services Shared repository layer - CASE database - access control functions Slide 44

Integration Framework l User interface layer • incorporates standardised interface toolkit with common presentation protocol • human-computer interface, display objects, guidelines for same look & feel l Tools layer • tools management - control behaviour of tools • coordination of tasks, e. g. multitasking l Object management layer • configuration management functions • integration services - standard modules that couple tools with repository l Shared repository layer • CASE database • access control functions - enable object management layer interact with database Slide 45