1. 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

2. 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

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

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

5. 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

6. 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… )

7. 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)

8. 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, …

9. 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

10. 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

11. 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).

12. 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

13. 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

14. 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

15. 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

16. Key process areas

17. 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

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

19. 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

20. 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.

21. 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)

22. 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

23. The software design process

24. 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

25. 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

26. 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

27. The testing process

28. Testing phases

29. 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

30. 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.

31. 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

32. 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

33. Functional tool classification

34. Activity-based classification

35. 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

36. Tools, workbenches, environments

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

38. 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)

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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