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

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

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

A Common Process Framework Task sets activities are unique for each project and umbrella activities are performed for all projects and are fairly equal in different projects.

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

Process as Problem Solving Process model or a software engineering paradigm problem solving loop (note that the stages in this loop may overlap, and that we can go through the loop more than once; note that this process may be repeated within phases 2, 3, and 4 more than once): status quo is the present state problem definition recognizes the problem and defines it in terms that can be understood technical development applies certain technological approach to solving the problem solution integration delivers the solution in the suitable form (documents, graphs, code, data, new business function, new program ) Recognize that this process exists at different levels in the production of software: (1)high level: defining the applications (2)medium level: defining the components (3) low level: implementation of the requirements (writing code, documenting… )

Process Types … 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)

Characteristics of a Good Process 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, …

A Good Process … 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 Facilitates early detection of and removal of defects Defects add to project cost Late detection/correction is costly It should facilitate monitoring and improvement Based on feedback Permit use of new tools, technologies Permit measurements

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

Generic view/ Phases Software Engineering 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).

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

Reasons for failure 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

Capability Maturity Model (CMM) Level 5: Optimizing Level 4: Managed Level 3: Defined Level 2: Repeatable 1. Initial: SW process is ad hoc, few processes are defined; success depends on individual efforts 2. Repeatable: basic project management (track cost, time and performance (functionality)); repetition of the behavior which contributed to success in previous projects 3. Defined: SW process for the engineering and management are documented and standardized; all processes use an approved approach 4. Managed: detailed measures of software process and product are collected; The process and the product are quantitatively understood 5. Optimized: continuous process improvement using process feedback and the product innovative ideas... Level 1: Initial

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

Key process areas

Key Process Areas (KPA) CMM Level 2 CMM Level3 CMM Level 4 CMM level 5 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 Predictability, effectiveness, and control of an organization are believed to improve as the organization move up the CMM scale. Empirical data support this belief. Companies that have done process improvement for more than three years is 1. Typical return on investment 7:1, 2. average gain in 37% per year, 3. increase of 18% in the number of defects found during the testing, 4. 19% reduction in time to market, 5. 45% reduction in field error reports per year. Note that the KPAs are cumulative, which means that the KPAs contained in the level 2 are also contained in levels 3, 4, and 5

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

Generic Framework activities 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

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.

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

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

The software design process

Design methods 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

Programming and debugging 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

3. Software validation 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

The testing process

Testing phases

4. Software evolution 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

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

What is CASE? 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

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

Functional tool classification

Activity-based classification

CASE integration Tools Workbenches Environments Support individual process tasks such as design consistency checking, text editing, etc. Workbenches 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

Tools, workbenches, environments

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

CASE Building Blocks 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)

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

Taxonomy of CASE Tools (Continued) Support Tools 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

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

Integrated CASE (I-CASE) 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

Benefits of I-CASE 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

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

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