Software engineering for Computer Science Students

1. Introduction to Software
Engineering
.

2. Introduction , Defining Software
 A set of Instructions (computer programs) that when executed provide desired features,
functions and performances , is called a Software.
Some of the constituted items of software are described below:
 Program: The program or code itself is definitely included in the software.
 Data : The data on which the program operates is also considered as part of the
software.
 Documentation : All the documents related to the software are also considered as part
of the software.
So the software is not just the code written in Cobol , Java or C++ , It also includes the
data and all the documentation related to the program.

3. Engineering and Software Engineering
 “The process of productive use of scientific knowledge is called engineering”
 Software Engineering is the process of utilizing our knowledge of computer science in effective production of
software systems.
 Software Engineering as defined by IEEE(International Institute of Electric and Electronic Engineering). IEEE is an
institution regarding the computer related issues.
“The application of a systematic , disciplined ,quantifiable approach to the development, operation and maintenance of
software, that is , the application of engineering to software”
 Definition of Software Engineering by Somerville “All aspects of software production –
It is not just concerned with the technical processes of software development but also with activities such as software
project management and with the development of tools, methods, and theories to support software production”
 So , Software engineering is the combination of all the tools , techniques , and processes that used in software
production.

4. Software Engineering by Fritz Bauer
 “The establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real machines”
 What are “sound engineering principles” that can be applied to computer software
development?
 How do we “economically” build software so that it is “reliable”?
 What is required to create computer programs that work “efficiently” on not one but
many different “real machines”?

5. Relevant Things To Software
 Programming Languages
 Programming Language Design
 Software Design Techniques
 Tools
 Testing
 Maintenance
 Development
 Documentation
 Project Management

6. Well-Engineered Software’s
Characteristics
 It is reliable and produces accurate and expected results.
 It has good user-interface (GUI): Information systems must interface effective and
efficient interface to the user.
 It has acceptable performances
 It is of good quality
 It is cost-effective : economically feasible
Every company can build software with unlimited resources, but well-engineered
software is one that conforms to all properties listed above.
The major challenge for a software engineer is that he/she has to build software within
limited TIME and BUDGET in a cost-effective way with good quality.Challenge

7. Stakeholders in Software Systems
 Different people have different views of an information system. Managers, users
and technical specialists each view the system in different ways and in different
levels of details. We call these people stakeholders in the system.
 A person who gets benefitted by the system is a stakeholder.
OR
A person or group of persons hwo have shares in business.
 A stakeholders is any person who has an interest in an existing or new system.
They can be technical or nontechnical workers. These can classified into SIX
groups:

8. Stakeholders in Software Systems
 Owners: Who pay for the system to be built and maintained, set priorities, determine
policies for its use, they are sponsors of the system, and responsible for funding the
project to develop, operate and maintain.
 Users: Who actually use the system to perform or support the work to be completed
 Designers: Who designs (–how will the system be implemented using technology. )the
system to meet the user’s requirements (-what the system “is” and “must” do
independent of technology.)
 Builders: Who construct , test and deliver the system into operation. Computer
programmes are written , tested and debugged in coding process.
 Analysts: Who studies and analyse the systems in use.
 IT Vendors and Consultants: Who sell you hardware and software or services.

9. Software System Development
 A system development is a set of activities processes,
methods, best practices and tools used to develop a high quality software and to
maintain it.
 Given a taskset , we apply FOUR layers in Software Engineering to solve it
 Process (like which theoretical process to follow e.g. Waterfall )
 Methods (like how to model data e.g. OOD, UML ,Database Schema)
 Tools (like what tools to use for Coding it e.g. C/Java)
 A Quality Focus (like performance , efficiency , Cost effectiveness , Time)

10. Stages of Software's Systems
A system life cycle divides the life of an information system into 2 stages.
 System Development
 System Operation & Support (Maintenance)
First you build it , then you use it , keep it running and support it. Eventually at some
point , you cycle back from Operation & Support to Re-Development.
The 2 key EVENTS between the 2 STAGES are:
1. When a system cycles from Development to Operation & Support, a conversion
must take place.
2. At some point, Obsolescence occurs & a system cycles from Operation & Support
to Re-Development.

11. Conversions
 Pilot Conversion- manual work is stopped at a sudden and software is used.
 Partial Conversion- simultaneously the developed software is used along with the
manual paper work.

12. 3 important reasons to start a project
(Business Needs)
These are reasons due to which the existing system requires changes:
 Problems – it needs corrective actions and are complaints made by users
whether internal or external users. Problems are to be solved. e.g. Reports may be
late or customers complaining about quality or to build the defected area of the
existing system.
 Opportunities- these are chances of successes for businesses , new ways and
enhancements for earnings. Knowledge workers like managers explores it.
Opportunities are exploited. e.g. management sees that the expected goals are not
achieved… explore an option.
 Directives- these are simply orders from the management like owners or board of
governors of organizations. Directives are obeyed. e.g. re-organizing the system or
building new one.

13. Software Development Life Cycle (SDLC):
8-steps in 3-phases
 Survey the situation
 Study the existing system Analysis Phase
 Define User Requirements
 Evaluate Alternative Solutions
 Acquire new Hardware / Software (if needed) Design Phase
 Design the system
 Implement the system
 Deliver the system Implementation Phase

14. SDLC: Survey The Situation
 Feasibility and initial survey of the project with objectives and nature
 Cost/benefit analysis in rough
 Scope of the project (boundaries of the system) and Problem
 Knowledge Workers identification (Domain Experts)
 Time and Budget
 Existing Hardware and Software with skills of workers and staff
 Suppliers , Customers , Unions , Policies , Charts , Forms , Documents
Output: Feasibility Statement with verification from owners
Check to cancel the project.

15. SDLC: Study The Existing System
 Detailed survey of the existing system (appoint a study team)
 Identification of Various Sources of data with Collection of data using:
Interviews , Questionnaires , Record Reviews ,Meetings , Observation
 How serious are the problems ? And how important are the opportunities?
 Costs and expenditures for the existing system, cost/benefits of the proposed
system
 Identification of the competitors, vendors and services providers
 Job descriptions and responsibilities of workers
Output: Problem Statement with verification from owners.
Check to cancel the project.

16. SDLC: Define User Requirements
 What the owners and users wants of the system?
 Requirement Engineering (slide 25)
Output: Requirement Statement with verification from owners

17. SDLC: Evaluate Alternative Solutions
Look for possible solutions on the basis of :
 Economic Feasibility – do we have the budget? New equipment may be needed
and staff deployed… (cost-benefit analysis)
 Operational Feasibility- any resistance from users if implemented? Will it be
user-friendly if implemented? Better than existing system?
 Technical Feasibility- do our team have the capability to do the project?
Will it solve the problem easily? Existing equipment or new to use? Repair the
defected area of the existing system or new one to develop?
(less cost , user friendly, expertise)-get opinion of the owners
Think of OUTSOURCERS in special. Check to cancel the project.
Select the one

18. SDLC: Acquire New Hardware/Software (if
needed)
 Demand of proposals to Venders and Service providers
Output: Proposals for equipment in return

19. SDLC: Design The System
 Algorithms and business logic on paper (Processing Design )
 Flowcharts of activities to view system flow of control
 Front-end GUI (effective and efficient that must be user friendly)
 Controls for navigation (Interface Design )
 Forms Layout for data entering (Input Design)
 Reports layout to view information (Output Design)
 Database schema for storing data (Storage Design and File structure)
Advice: (get it okayed by the owners and users) –get opinion of owners
Check to cancel the project.

20. SDLC: Implement The System
 Write computer programs,
test(identification of un-discovered error) and
debug (fixing errors) and documenting it
 Actual code in high level languages is hard coded
 Installation and configuration of hardware and software if purchased

21. SDLC: Deliver The System
 Software
 Hardware
 Installation and Configuration
 Documentation
 Training (support)

22. Documentation Phase of SDLC
 Feasibility Statement
 Problem Statement
 Requirements Statement and SRS
 Getting Opinions and Views of Owners and Users (Internal and External)
on Design of the system
 Flowcharts and Algorithms to visualize activities in Design with Reports and Forms
plus Database Schema ( DFD and ERD)
 Source Code , devising Testing strategies
 Trainings and Tutorials (Support)

23. Usage of SDLC
 Manual system when applied SDLC , you get Improved Proposed system
Existing
System
SDL
C
Proposed System

24. Usage of SDLC
Given an existing system with business needs of Problems, Directive or Opportunities,
when you apply SDLC to it, you get an Improved system where the Directives are
fulfilled, Problems removed and Opportunities exploited.

25. REQUIREMENTS ENGINEERING
 “The broad spectrum of tasks and techniques that leads to an understanding of
requirements is called requirements engineering “
 Does the customer know what is required?
 Do the end users have understanding of the features and functions that will
provide benefit to organization?
 Will the needs not change?

26. Definitions of Software Requirements
 Caper Jones … “ a statement of needs by a user that triggers the development of
a program or system”
 Alan Davis … “ a user need or necessary feature, function, or attribute of a system
that can be sensed from a position external to that system”
 Sommerville…” a specification of what should be implemented. They are
descriptions of how the system should behave , or of a system property or
attribute. They may be a constraint on the development process of the system”
 IEEE…” a condition or capability needed by user to solve a problem or achieve an
objective”

27. Characteristics of Requirement Statement
 Complete (covering all aspects like scope , performance , constraints…)
 Correct (posses no mistakes, according to the needs)
 Feasible (can be done under the known capabilities of resources)
 Prioritized (whether a basic need or an ad-on)
 Un-ambiguous (narrative be interpreted as the same by all)
 Verifiable (testable and sources defined)
 Traceable (Features are well distinguished in each phase)
 Changeable (Traceable features are changeable)

28. Importance of Requirements
 Fred Brooks in his classical book on software engineering and project
management “ The Mythical Man Month” emphasizes the importance of
requirements engineering and writes:
“The hardest single part of building a software system is deciding precisely what to
build. No other part of the conceptual work is as difficult as establishing the
detailed technical requirements , including all the interfaces to people , to
machines, and to other software systems. No part of the work so cripples the
system if done wrong. No part is more difficult to rectify later.”
So , Requirements engineering tasks are conducted to establish a solid foundation for
design and implementation. It occurs in communication and analysis phases
mainly.

29. Key Point
 Requirements Engineering establishes a solid base for design and implementation.
Without it , the resulting software has a high probability of not meeting customers’
needs.
 “The seeds of major software disasters are usually sown in the first three months
of commencing the software project” – Caper Jones
 “Requirement Engineering provides the appropriate mechanism for understanding
what the customer wants, analyzing needs , assessing feasibility , negotiating a
reasonable solution ,specifying the solution unambiguously , validating the
specification ,and managing the requirements as they are transformed into an
operational system.”

30. Some Risks In Requirements
 Insufficient user involvement leads to unacceptable products.
 Creeping user requirements contribute to overruns and degrade quality.
 Ambiguous requirements lead to ill-spent time and rework.
 Gold-plating by developers and users adds unnecessary features.
 Minimal specification lead to missing key requirement and hence result in an
unacceptable product.
 Incompletely defined requirements make accurate project planning and tracking
impossible.
 Internal Politics may influence requirements.

31. Requirements Origins and Comparative
Costs
0
5
10
15
20
25
30
35
40
45
Feasibility Analysis Design Coding Testing
Growth
Costs

32. Stakeholders Point Of View
 Different stakeholders have different requirements-sometimes even conflicting e.g.
 Users would describe their own requirements and quality attributes, and that
cannot be ignored because they actually use the system.
 Management would provide business requirements and project parameters.
 Hardware Engineers would specify hardware interfaces.
 Marketers would specify their own requirements.
 Software engineer will be interested in some other.

33. Seven Tasks or Functions in Requirements
Engineering
These 7 tasks are conducted by members of the Software Team
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Management

34. Inception
 Establish a basic understanding of the problem, and scope
 Feasibility of project (3-types of feasibility )
 Address major features and functions that must be present for the system to meet
its objectives.
 The people who want a solution are identified (stakeholders)
 The nature of the solution that is desired (stakeholders perception)
 Define overriding project constraints and restrictions
 Effectiveness of preliminary communication and collaboration between the other
stakeholders and the software team

35. Inception (output)
 Problem understanding
 Scope of project
 Stakeholders perception of solution
 Feasibility of the project
 Features and functions of the system
 Constraints on features and functions applied
 Quality constraints (speed and accuracy )
 Size , Time ,Cost ,Deadlines related restrictions or any business rules
OUTPUT : Product Request in 1 or 2 pages

36. Elicitation (A requirement gathering activity) --3
 What are the objectives of the system and product?
 Previous info is expanded and refined. (INPUT)
 How the system or product fits into the needs of the business?
Christel and Kang identified 3 types of problems while eliciting :
 Problem of scope : The boundary of the system is ill-defined or the
customer / user specify unnecessary technical detail that may confuse , rather
than clarify overall system objectives.
 Problem of volatility: The requirements change over time.
 Problem of understanding: continued on next slide…

37. Elicitation
 Problem of understanding: The customers /users are not completely sure of
what is needed
 Have poor understanding of the capabilities and limitations of their computing
environment
 Don’t have a full understanding of the problem domain
 Have trouble communicating needs to the system engineer
 Omit information that is believed to be “obvious”
 Specify requirement that conflict with the needs of other customers/users
 Specify requirements that are ambiguous or untestable

38. Elicitation (Goal)--1
The goal is to identify the problem , propose elements of solution , negotiate different
approaches , and specify a preliminary set of solution requirements .
 Collaborative Requirements Gathering : (Procedure)
 Meetings are conducted
 Rules for preparations and participation are established
 An agenda is suggested
 Charts , bulletin boards etc are used for reviews (Definition Mechanism)

39. Elicitation (Taskset)--2
For a small , relatively simple project ,the taskset for elicitation is:
 Make a list of stakeholders for the project
 Invite all to an informal meeting
 Ask each one to make a list of features and functions required
 Discuss and build a final list
 Prioritize requirements
 Note areas of uncertainty
 Note constraints and restrictions that will be placed on the system
 Discuss methods for validation

40. Elicitation (Output)--4
 Feasibility statement
 Requirements statement
 Scope and boundary of the system
 Stakeholders perception of solution
 Technical details
 Features and functions with constraints and restrictions imposed
 Costs approximations

41. Elaboration
 Expanding and refinements using UML and diagrams are made
(You must know when to stop)
Covered in slide 51

42. Negotiation
 Customers ,users and other stakeholders are asked to rank requirements and then
discuss conflicts in priority.
 Assess their cost and risk
 Addresses any internal conflicts
 Combined ,modified to achieve some measure of satisfaction
(all argue that their version of requirements is essential for their special needs)
Advice: There should be no winner and no loser in an effective negotiation. Both sides
win, because a “deal” that both can live with is solidified.
The intent of this negotiation is to develop a realistic project plan on the basis of
priority and relative cost of each requirement.

43. The Art of Negotiation
 Not a competition rather compromise
 Listen carefully
 Focus on the other side interests
 Be creative

44. Specification Definition
 A specification can be a written document, a set of graphical models , a
mathematical model , a collection of usage scenarios , a prototype, or any
combination of these.
 Written document that combines natural language descriptions and graphical
models may be a best approach that is well understood in technical environments.
 A software requirements specification (SRS ) is a document that is created when a
detailed description of all aspects of the software to be built must be specified
before the project is to commence.

45. Software Requirements Specification
(SRS)
 Table of contents
 Revision History
 Introduction
• Purpose
• Project Scope
• References
 Product and System Features
 Operating Environment
 Design and Implementation Constraints
 Assumptions and Dependencies
 User Interfaces
 Performance Requirements
 Security Requirements
 Issues List

46. Central Role of SRS
 Refer to srs-template
SRS
Project Planning
& Analysis
Project
Management
System Testing
Project
Documentation
Design
Implementation
Analysis

47. Validation (For Quality)
 To ensure that software requirements have been stated unambiguously
 That inconsistencies , omissions and errors have been detected and corrected or
removed
 The specification is looked for errors in content or interpretation
 Areas where clarification may be required
 Missing information
 Conflicting requirements
 Un-realistic and un-achievable requirements
 Use of Checklist in Validation… (Next Slide)

48. Validation Checklist
It is often useful to examine each requirement against a set of checklist questions.
 Are requirements stated clearly?
 Can they be misinterpreted?
 Is the source (e.g. a person , a regulation , a document) of the requirement
identified or referenced?
 Does the requirements violate any system domain constraints?
 Is the requirements testable? If so, can we specify tests called validation criteria ,to
exercise the requirements?
 Is the requirements structured in a way that leads to easy understanding , easy
reference , and easy translation into more technical word products?

49. Requirements Management
 Project team must identify , control , and track requirements and changes to
requirements at any time as the project proceeds.

50. DATA MODELING
 System description shows overall business functionality that is achieved by
applying software ,hardware ,data , human
 Design shows application architecture , user interface & component level structure
SYSTEM
DESCRIPTIO
N
ANALYSI
S MODEL Design

51. Elements of analysis model
 Scenario based elements depicts how the user interacts with the system and the
specific sequence of activities that occur as the software is used
 Class based elements shows relationships between the objects
 Behavioral elements show how external events change the state of the system
 Flow oriented elements represent the system as an information transform ,
depicting how data flow through various system functions

52. Elements Of Analysis Model
.
Scenario –based elements
like use cases
Class based like Class
Diagram
Behavioral elements like
state and sequence
diagrams
Flow elements like DFD’s
Software
Requirements

53. Use Cases LIBERARY SYSTEM
-
Reserve
book
Borrow
book
Return
book
Extend
loan
Update Record
Browse

54. DFD REGISTRATION SYSTEM

55. FLOWCHART REGISTRATION SYSTEM

56. USE CASES REGISTRATION SYSTEM

57. DFD REGISTRATION SYSTEM

58. USE CASES REGISTRATION SYSTEM

59. SEQUENCE DIAGRAM

60. DFD EXAMINATION SYSTEM

61. ACTIVITY DIAGRAM

62. CLASS DIAGRAM

63. CODE

64. CODE

65. The Software PROCESS (Phased approach )
 A process is a collection of activities , actions and tasks that are performed when some
work product (software) is to be created .
 A process framework is a collection of activities in sequence …
 Communication
 Planning
 Analysis
 Design
 Implementation
 Deployment
 Maintenance
 Decommissioning

66. Communication
 Before any technical work can commence , it is critically important to communicate
and collaborate with the customer and other stakeholders . The intent is to
understand stakeholders objectives for the project and to gather requirements that
help define software features and functions .

67. Planning
 The software project plan defines the work by describing :
 the technical tasks to be conducted ,
 the risks that will affect the quality ,
 the resources that will be required (needed),
 the work product to be produced ,
 and a work schedule .

68. Analysis
 SDLC Analysis Phase 3 steps (slide 13)

69. Design
 Algorithms and business logic on paper (Processing Design )
 Flowcharts of activities to view system flow of control
 Front-end GUI (Interface Design )
 Forms Layout for data entering (Input Design)
 Reports layout to view information (Output Design)
 Data Model
 Database schema for storing data (Storage Design and File structure)
 ERD

70. Implementation
 This activity combines code generation ( either manual or automated ) and testing
that is required to uncover errors in the code.

71. Deployment
 The software is delivered to the customer and feedback is received on acceptance
testing.

72. Maintenance
 Making changes and adopting it to future needs . Maintaining software as per
requirements …

73. Decommissioning
 Business vanished , or technology phased out , out of service …

74. Umbrella Activities (overlapped)
 Software engineering process framework activities are complemented by a number of
umbrella activities which are applied throughout a software project and help a software
team to manage and control progress , quality , change , and risk .
 Software project tracking and control (Project Management )
 Risk management (Quality affecting )
 Software quality assurance (Q/A)
 Technical reviews (Validation)
 Change control management
 Reusability management
 Documentation
 Testing

75. The Waterfall Software Process Model
 In times when the requirements are well understood , well defined and reasonably
stable and static.
 When work flows from COMMUNICATION through DEPLOYMENT in a linear
fashion.
 When enhancements to an existing system are made.
 The Waterfall model , sometimes called the classic life cycle , suggests a
systematic , sequential approach to software development that begins with
communication , and progresses through planning , analysis , design,
implementation , deployment …
 This approach was first formulated and documented by Dr. Winston W. Royce in
1983
 Blocking States are present .

76. WATERFALL PROCESS MODEL
CONCEPT & FEASIBILITY
USER REQUIREMENTS
DEVELOPER SPECIFICATIONS
PLANNING
DESIGN
IMPLEMENTATION
INTEGRATION TESTING
ACCEPTANCE TESTING
OPERATION & MAINTENANCE
DECOMMISSIONING
TEST
TEST
TEST
TEST
TEST
DEVELOPMENT
OPR &
MAINTENANCE
2
WEEK
S
2
WEEKS
2
WEEKS
8 WEEKS
4 WEEKS

77. A case in point
 I didn’t discuss with the customer the specs of the HW and OS before developing a
particular e-commerce software
 I wrote it for the hardware and operating system that was easily available to me.
 Unfortunately that hardware / operating system differed from the what was easily
available to the client.
 Result: huge amount of rework, higher cost, delayed delivery, low quality, raised
complexity.

78. Cost of Change
0
1
2
3
4
5
6
7
8
9
Waterfall
Waterfall

79. The Extreme Programming Process
.
Planning Design
Testing
Implement
ation
User stories
Acceptance Test
Criteria
Prototypes
Pair Programming
Refactoring
Unit Testing
Acceptance Testing
Release
Or Software
Increments