1. Introduction to Software Engineering
Chapter 1
Introduction to Software Engineering

2. Topics Software Characteristics Components Applications
Layered Technologies
Processes
Methods And Tools
Generic View Of Software Engineering
Process Models- Waterfall model, Incremental, Evolutionary process models- Prototype, Spiral And Concurrent Development Model

3. Software:
== Program +good user interface + operating procedures+ documentation

4. Software Characteristics
Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware
Software is developed or engineered, it is not manufactured in the classical sense.
Software doesn't "wear out.“
Although the industry is moving toward component-based assembly, most software continues to be custom built. (reusability of components)

5. Failure curve for Hardware Software

6. Software crisis Poor quality s/w produced
Development team exceeds the budget
Late delivery of s/w
User requirement not completely supported
Difficult to maintain.

7. Software Applications
System software.
Real-time software.
Business software
Engineering and scientific software
Embedded software.
Personal computer software.
Web-based software.
Artificial intelligence software.

8. Software Process
software process as a framework for the tasks that are required to build high-quality software
Is process synonymous with software engineering?
The answer is “yes” and “no.”

9. Software Engineering Definition
[Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines
2.[IEEE] The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

10. Advantages of using S.E. Improved requirement specification
Improved cost and scheduled estimates
Improved quality
Better use of automated tools
Less defects in final products
Better maintenance of delivered s/w
Well defined processes

11. Process, Methods, Tools / A Layered Technology

12. Quality Focus
The bedrock that supports software engineering is a quality focus.

13. Process The foundation for software engineering is the process layer.
Process defines a framework for a set of key process areas (KPAs) that must be established for effective delivery of software engineering technology.

14. Methods
Software engineering methods provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include requirements analysis,
design, program construction, testing, and support.

15. Tools
Software engineering tools provide automated or semi-automated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

16. A Generic View of Software Engineering
The work associated with software engineering can be categorized into three generic phases, regardless of application area, project size, or complexity.
The definition phase focuses on what.
The development phase focuses on how.
3.The support phase focuses on change associated with error correction, adaptations required as the software's environment evolves, and changes due to enhancements brought about by changing customer requirements.

17. Type of change of SUPPORT PHASE
Correction: corrective maintenance changes the s/w to correct defects
Adaption: Adaptive maintenance in modification of external environment
Enhancement: Perfective Maintenance beyond to its original functions
Prevention: Preventive Maintenance, s/w reengineering- makes changes for more easiness of above 3 changes

18. Cont..
The phases and related steps described in our generic view of software engineering are complemented by a number of umbrella activities.
Typical activities in this category include:
• Software project tracking and control
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management

19. THE SOFTWARE PROCESS

20. Cont…
A common process framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size or complexity.
A number of task sets—each a collection of software engineering work tasks, project milestones, work products, and quality assurance points—enable the framework activities to be
adapted to the characteristics of the software project and the requirements of the project team

21. Cont… umbrella activities—such as software quality assurance, software
configuration management, and measurement2—overlay the process model.
Umbrella activities are independent of any one framework activity and occur throughout
the process.

22. Process Flow
Linear.
Iterative.
Evolutionary.
Parallel.

23. What is a Process … ?
When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks
You do not usually
bake a cake before all the ingredients are mixed together
We can think of a series of activities as a process
The software process is the way we produce software.
Any process has the following characteristics
It prescribes all of the major activities
It uses resources and produces intermediate and final products
It may include sub-processes and has entry and exit criteria
The activities are organized in a sequence
Constrains or control may apply to activities
(budget control, availability of resources )

24. Software Processes
When the process involves the building of some product we refer to the process as a life cycle
Software development process – software life cycle
A software process model is an abstract representation of a process

25. Software Process Models
A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required.
Process model also known as software life cycle models

26. The Waterfall Model
Generic Framework

27. The Waterfall Model Waterfall Strengths
Requirements – defines needed information, function, behavior, performance and interfaces.
Design – data structures, software architecture, interface representations, algorithmic details.
Implementation – source code, database, user documentation, testing.
Waterfall Strengths
Easy to understand, easy to use
Each phase has well defined inputs & outputs
Each stage has well defined deliverable & Milestones.
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule.

28. Disadvantages of Waterfall model
Once the phase x is over then next phase y started. Model is always sequential in nature.
Users have little interaction with the project team. Their feedback is not taken during development.
After the development starts changes cannot be possible easily.
Model do not support delivery of system in pieces.
Working version is available very late so review of software product from customers is also late.
Model is very rigid because output of each phases is depend on their successive stages.

29. Incremental Process Model
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality
User requirements are prioritised and the highest priority requirements are included in early increments
Once the development of an increment is started, the requirements are frozen.
it combines elements of the waterfall model applied in iterative fashion. (iterative process model).
Example: word processing software

30. Incremental Models: Incremental
C-Communication
P-Planning
M-Modeling
C-Construction
D-Deployment

31. Advantages of Incremental Model
Limited number of persons can be put on project because work is to be delivered in parts.
Customer value can be delivered with each increment so system functionality is available earlier
Early increments act as a prototype to help elicit requirements for later increments
Lower risk of overall project failure
Total cost of project is distributed.
End user’s feedback requirements for successive releases become more clear.
Testing become more easily.
Risk of failure is decrease.

32. Disadvantages of Incremental Model
Model required well defined project planning schedule to distribute the work properly.
Testing of modules result into overhead and increased cost.
Product is delivered in parts, total development cost is higher.
Well define interfaces are required to connect modules.

33. RAD Model (Rapid Application Development)
If requirements are well understood and project scope is well defined then this model is very useful.
It is high speed model to develop the project.
It is incremental model.
Important feature of RAD model is customer/user involve in all stages of development.
The process start with building rapid prototype (in 60 days) and delivered to customer for use and feedback.
Final shape of project is started after positive feedback.

34. RAD Model

35. Advantages of RAD model
Customer involved in all stages so software achieving customer satisfaction.
Feedback from the customer is available at the initial stages.
Development time of the product may be reduced due to use of powerful tools.
In order to increase productivity, case tools and framework are used.
Quick initial view of the product are possible.
Involvement of the users may increase the acceptability of the product.

36. Disadvantages of RAD model
Highly specialized and skilled developers are required.
Model is ineffective if system can not be properly modularized.
If user cannot be involved throughout the life cycle, this model is not suitable.
Absence of reusable components can lead to failure of the project.
It may be hard to use a legacy systems.
Note: when to use the RAD model
First, on systems that may be modularized and that are scalable
Second, on systems with reasonably well known requirements

37. Evolutionary Models
This model is also known as the successive versions model.
System is first broken down into several modules or functional units that can be incrementally implemented and delivered.
The developers first develop the core modules of the system.
Next refine the modules as another incremental level by adding new functionalities. C B B A A A
A,B,C are modules of a software product that are incrementally developed and delivered

38. 1. Rough requirements specification 2
1. Rough requirements specification 2. Indentify the core and other parts to be developed incrementally 3. Develop the core part using an IWM 4. Collect customer feedback and modify requirements 5. Develop the next identified features using an IWM 4 ----all features complete maintenance

39. Although it can be used as a standalone process model, it is more commonly used as a technique that can be implemented within the context of other process models
The prototyping paradigm assists the SW engineer and the customer to better understand what is to be built when requirements are fuzzy(customer identify general objective but not defines the details of input ,processing , and processing so the developer becomes unsure about efficiency , algorithms and so on to solve this problem prototype is used )
Ideally, the prototype serves as a mechanism for identifying SW requirement

40. Advantages. Risk analysis is better.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During life cycle software is produced early which facilitates customer evaluation and feedback.

41. Disadvantages Not suitable for smaller projects.
Management complexity is more.
End of project may not be know which is a risk.
Can be costly to use.
Highly skilled resources are required for risk analysis.
Project’s progress is highly dependent upon the risk analysis phase.

42. Prototype model
Customer knows all general objectives of software but does not define input, output and functionality very clearly then this…..
In other case developer does not sure of different algorithms then…
Before developing actual software, a working prototype of the system should be built.
It is partial developed product. It has limited functional capabilities, low reliability and inefficient performance.
The prototype may be useable program but is not suitable as the final software product.

43. Evolutionary Model: Prototyping

44. Scenario of model Requirement Gathering 
Quick design  build prototype  customer evaluation of prototype (suggestions)
Acceptance by customer  design  implement  test  maintain  feedback

45. Prototype ? Limited functions Shortcut implementation
Use : input data formats like gui based, reports etc..
When technical solutions are unclear(product dev, design decision, algorithm etc)

46. Advantages of Prototype model
A partial product is built in the initial stages therefore customer get a chance to see the product early in the life cycle so give the necessary feedback.
Flexibility in design and development is also supported by the model.
Customer may be more satisfied because he is involved from starting phase.
Disadvantages of prototype model
After seeing an early prototype the users may demand the actual system to be delivered soon.
End user may not be understand the prototype model.
Poor documentation.
If user not satisfied then he may be loose the interest in the project.

47. The Spiral Model (1)
Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
It provides the potential for rapid development of increasingly more complete versions of the software
It is a risk-driven process model generator
It has two main distinguishing features
Cyclic approach
Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk
A set of anchor point milestones
A combination of work products and conditions that are attained along the path of the spiral

48. The Spiral Model (2) Fig 3.5: A typical spiral model Planning
Communication
Planning
Modeling
Construction
Deployment
delivery
feedback
Start
analysis
design
code
test
estimation
scheduling
risk analysis
Fig 3.5: A typical spiral model

49. The Spiral Model (3)
Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer s/w
The circuits around the spiral might represent
Concept development project
New Product development project
Product enhancement project
The spiral model demands a direct consideration of technical risks at all stages of the project

50. Simplified Spiral Model
If risks cannot be resolved, project is immediately terminated

51. Spiral Model (Strength and Weaknesses)
Strengths
Introduces risk management
Prototyping controls costs
Evolutionary development
Weaknesses
Lack of risk management experience
Model is not suitable for small project

52. The Concurrent Development Model (1)
Sometimes called concurrent engineering
Can be represented schematically as a series of framework activities, s/w engineering actions and tasks, and their associated states
Defines a series of events that will trigger transitions from state to state for each of the s/w engineering activities, actions, or tasks
Applicable to all types of s/w development
Defines a network of activities
Events generated at one point in the process network trigger transitions among the states

53. The Concurrent Development Model (2)
None
Modeling activity
Under
development
Represents the state
of a software engineering
activity or task
Awaiting
changes
Under review
Under
revision
Baselined
Done

54. Advantages of CDM:

55. Disadvantages of CDM:

56. CMM Level
SEI (Software Engineering Institute) has developed a comprehensive model
To grade organizations’ current state of process maturity
Grading scheme determines compliance with a Capability Maturity Model (CMM) that defines key activities required at different levels of process maturity.
Is used for improving the s/w project

57. Cont.
Level 1: Initial
s/w process characterized as adhoc and occasionally even chaotic
Few processes are defined and success depends on individual effort

58. Level 2 : Repeatable
Basic project management processes are established to track cost, schedule and functionality.
Level 3: Defined
- s/w process for both management and engineering activities is documented, standardized and integrated into an organizational wide s/w process

59. Level 4 : Managed
Detailed measures of the software process and product quality are collected.
Both the s/w 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 from testing innovative ideas and technologies

60. Umbrella activities s/w project tracking & control Risk mgmt. SQA
Formal Technical review
S/w configuration mgmt.
Work product preparation & production
Reusability mgmt.
Measurement

61. Requirement Engineering
Chapter 2
Requirement Engineering

62. Topics Problem recognition Requirement Engineering Tasks Processes SRS
Use cases and Functional specification
Requirement validation
Requirement Analysis
Modeling and types

63. Requirement ?
A requirement can range from high level abstract statement of a service or of a system constrain to a detailed mathematical specification.

64. Requirement engineering ?
Is the process of
 Establishing the services that the customer requirement from system
 The contraints under which it operates and is developed

65. Types of Req. User – collection of statement written for customer.
System – structured document gives detailed description. Contract between client and contractor.
Software specification – software description for design implementation.

66. Problem Recognition
Sys engineering
Req analysis
Sw design

67. How is Req analysis helpful?
Analyst
Designer
Developer

68. What are req. ana. Efforts?
Problem Recognition
Evaluation
Modeling
Specification
Review

69. Role of system analyst
What is system analyst ???

70. Cont..
“Is a person who starts requirement gathering and requirement analysis activity by collecting all the information from the customer.”

71. cont.. What is the problem ? What is the need to solve the problem ?
What could be the solutions to the problem ?
What sort complexities or problem that might arise while solving the problem ?
What kind of input or output would be for the system ?

72. Types of Req engineering.
1) functional and non- functional requirement.
2) user requirement.

73. Software Requirements Specification
Requirement analysis and specification consist of basic two activities:
Requirements gathering and analysis
Solve the following problems:
Anomaly (ambiguity)
Inconsistency
Incompleteness
Requirement Specification
SRS

74. Software Requirements Specification
Who needs the SRS and for what purpose?
Users, customers and marketing personnel
SRS will meet their needs
Software developers
Develop the exact functionality which is specify in SRS document
Test engineers
SRS provide meaningful functionality for making test templates.
User documentation writers
Understand the SRS documents well enough to be able to write user’s manual.
Project managers
Estimate the cost easily and planning
Maintenance engineers
Understand the functionality, design and coding.

75. Software Requirements Specification
SRS document should clearly document the following aspects of a system:
Functional requirement
Non functional requirement
Goals of implementation
High level functional requirements
Sub requirements
This include aspects concerning maintainability, portability and usability.
Also include reliability issues, accuracy of results, human- computer interfaces issues.
Give some general suggestions regarding development.

76. Characteristics of a good SRS documents
Concise
The SRS document is to the point at the same time unambiguous, consistent and complete. Irrelevant description reduce reliability and increase error in srs.
Structured
The SRS document should be well structured.
Black-box view
The SRS should specify the externally visible behavior of the system.
Conceptual integrity
The SRS document should exhibit conceptual integrity so that the reader can easily understand the contents.
Response to undesired events
The SRS document should characterize acceptable responses to undesired events.
Verifiable
Whether or not requirements have been met in an implementation.

77. Organization of the SRS document
Depends on system analysist
Depends on Project type
Depends on company polices and rules
So SRS document is always differ organization to organization.

78. Software Requirements Specification Format
Introduction
Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Overview
Overall Description
Product Perspective
Product Functions
User characteristics
Constraints
Assumptions and dependencies

79. Software Requirements Specification Format
Specific Requirements
Functionality
Usability
Reliability
Performance
Supportability
Design Constraints
On-line User Documentation and Help System Requirements
Purchased Components
Interfaces
Licensing Requirements
Legal, Copyright, and Other Notices
Applicable Standards