Faculty

Divya MG
divyam@cdac.in
C-DAC, Bangalore

1
References:
1. Software Engineering-10e; Ian Sommerville
2. Software Engineering: Chandramouli
3. http://nptel.ac.in/courses/
4. All ppts will be shared
 
 

2
 Building blocks
1. Request for work (RFW) is say from
client
2. “Feasibility study”
3. “Approval” from Client and his management
4. “Software requirement specification-SRS”
5. “Project Planning” process
6. “Various review” process
7. “Training” process
8. “Configuration management” process
9. “Design” process
10. “Coding” & “Testing” process
11. “Progress tracking/monitoring”
procedures
12. “Installation” (deployment)
13. “Maintenance”
14. “Postmortem analysis”
15. “Quality assurance”

3
Software Engineering Explained

BlackBerry Developer SideShow

Theme: Andreas04 by Andreas Viklund. Blog at WordPress.com.
What is software
1. Instructions (computer programs) that when executed provide desired
features, function, and performance
2. Data structures that enable the programs to adequately manipulate
information
3. Descriptive information in both hard copy and virtual forms that
describes the operation and use of the programs
4. So on

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
construction, most software continues to be custom built

5
 Software Systems
 Ubiquitous: Used in wide variety of applications
 Business, engineering and scientific applications
 Simple to complex,
 Internal to public,
 Single function to enterprise-wide,
 One location to distributed,
 Batch or real time,
 Informational to mission critical,
 etc …

6
 Software Applications
Today, seven broad categories of computer software present
continuing challenges for software engineers:

• System software
- Compiler, Operating System…
• Application software
- Railway reservation…
• Engineering/scientific Software
- Astronomy, automated manufacturing…
• Embedded software
- Braking system, Mobile phone…
• Product-line software
- Word processor, personal finance application…
• WebApps (Web applications)
- Social networks…
• AI software
- Pattern recognition, neural networks…
7
Large projects
 Involve different types of people
 Large building : architect, civil engineer, electrical engineer,
workers (painter, carpenters etc).
 FlipKart online shopping system: project manager, software
architect, database expert etc
 Continuous supervision for quality assurance
 On site supervisors (check cement/steel quality, Ensuring
proper mix of sand &cement)
 Similarly for FlipKart system……..
 Many deliverables: architectural plan, model structural diagrams,
electrical cabling layouts, Software Requirement Specification, Test
Reports, User manuals, …
 Standards, regulations, conventions need to be followed
 Steps, milestones defined and reviews are carried out: Progress is visible

8
Challenge in large projects
 Developing large/complex software application is very challenging
 Effort intensive
 High cost
 Long development time
 Changing needs for users
 High risk of failure, user acceptance, performance,
maintainability…
 Quite different from one time programs where author and user are
same!

9
Software Engineering
(Few realities)
 It follows that a concerted effort should be made to understand
the problem before a software solution is developed
 It follows that design becomes a pivotal activity
 It follows that software should exhibit high quality
 It follows that software should be maintainable

The IEEE [IEE93a] has developed a more comprehensive definition

where it states as :
Software Engineering: 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
Successful software system
 When do we consider a software application successful?
 Development completed
 It is useful
 It is usable and
 It is used
 Cost effectiveness, maintainability implied

Software projects have not always been successful.

11
A project can be considered successful, only if all the four conditions
are satisfied :
a. Quality software is delivered to the client
b. Development is completed within the time frame
c. Development is completed within the budget
d. Relations amongst the team members are cordial during
project execution.

12
 Quality

Software Quality Triangle

 Operational characteristics (requirements during the operation or
usage of the software)
 Transition characteristics (usage in another hardware/operating system
environment)
 Revision characteristics (requirements for making changes to the
software easy)

13
 Time
 An important criterion for the success of a project is time.
 The software has to be delivered to the customer within the time
committed.
 Time overrun attracts penalties from the client.
 Time overrun invariably causes budget overrun.

At project proposal, as a
project manager, you
may say that it will take
6 months for
development. Customer will put a “late
delivery” clause which says
The customer may that 5% of the project cost will
negotiate on the time be deducted from the payment
frame and finally you if the delay is say one month
may agree for 4 months.
 Budget
 Before taking up the project, the management will estimate the total
cost of the project and the expected profit.
 The software development has to be completed within the budget
allocated by the senior management.
 Cost overrun results in reduced profit margin to the organization.
 If the money spent exceeds the project cost, the organization will make
a loss.
 Remember, people run business to make money.

15
 Relationship
 It is important to keep cordial relations amongst
 Team members and project manager
 Team members and top management
 Team members and client/users
 Development team and other teams (such as QA, test team etc.)
 In many projects, people fight amongst themselves causing strained
relations because of unsystematic project development.
 A project is successful/progress well only if all the members have good
relations during the course of development.

16
Reasons for failure
 Schedule slippage
 Cost over runs
 Does not solve user problem
 Poor quality of software
 Poor maintainability
 Adhoc software development results in;
 No planning of development work
 Deliverables to the 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

17
 What is Software Process ?
• A process is a structured set of activities required to develop a system
which includes specification, design, validation and evaluation.
• The roadmap to building high quality software products is software
process.
• Software processes are adapted to meet the needs of software engineers
and managers as they undertake the development of a software product.
• A software process provides a framework for managing activities that can
very easily get out of control.
• Different projects require different software processes.
• The software engineer's work products (programs, documentation, data)
are produced as consequences of the activities defined by the software
process.
• The best indicators of how well a software process has worked are the
quality, timeliness, and long-term viability of the resulting software
product.

18
 Software process (cont…)
Objectives of Software Process
 To introduce various software lifecycle models.
 To describe a number of different lifecycle models and when
they may be used.
 To describe outline process models for requirements
engineering, software development, testing and evolution.
Generic Software Engineering Phases
Definition phase - focuses on what (information engineering,
software project planning, requirements analysis).
Development phase - focuses on how (software design, code
generation, software testing).
Support phase - focuses on change (corrective maintenance,
adaptive maintenance, perfective maintenance, preventative
maintenance).

19
Software engineering practices
 The essence of software engineering practices
 General principles of software engineering practices

20
The essence
 Understand the problem (communication and analysis).
 Plan a solution (modeling and software design).
 Carry out the plan (code generation).
 Examine the result for accuracy (testing and quality assurance).

21
General principles
David Hooker has proposed seven principles that focus on software
engineering practice as a whole:
1. The Reason It All Exists
2. KISS (Keep It Simple, Stupid!)
3. Maintain the Vision
4. What You Produce, Others Will Consume
5. Be Open to the Future
6. Plan Ahead for Reuse
7. Think!

22
 Inherent Problems with Software Development
 Requirements are complex
 The client does not know the functional requirements in advance
 Requirements may be changing
 Technology enablers introduce new possibilities to deal with nonfunctional
requirements
 Frequent changes are difficult to manage
 Identifying milestones and cost estimation is difficult
 There is more than one software system
 New system must be backward compatible with existing system (“legacy
system”)
 Phased development: Need to distinguish between the system under
development and already released systems
 Let’s view these problems as the nonfunctional requirements for a system that
supports software development!
 This leads us to software life cycle modeling

23
Task: Build a Simplest Accounting S/W
You’ve been offered to build a very basic accounting software for
Bangoo Banks Inc.
 You’ll need to collaborate with 3-4 other developers.
 You’ll receive handsome amount of cash for full functional
software!
 Deadline: very, very strict. Say, couple of months?

24
What are you going to do?
 Divide the total project in visible sections, say:
 User Accounts
 Human Resource
 Accounting
 Etc…
 And start asking questions to the clients how they want the program
behave, design database…

25
All four developers started coding as fast as you can
to maintain deadline.

26
After some days… you felt like integrating your
works?
 But you figured out you need a change in some part, you could change
it, but others’ code can break?
 You hardly understand what your friend means by variable baln or
function register()
 Your disc crashed and your codes are gone?
 You’ve created too many folders like code_old code_working,
code_new2, code_final… now what?
 How do you merge everybody’s code to a full-functional system?

27
Messed Up?
• Without putting your code in a function, you just wrote it down,
thinking, “Hey, I’ll not use this code anywhere else! So Why do I need to
put it in a function or class?”
• But, you never know…
• Client may change his mind
• New functionalities may appear in future
• And you’re very likely to duplicate same codes
• Man is mortal. To fix buggy codes you’ll need to investigate
your whole project number of times you copy-pasted same
code.
 Hard to find bugs. 

28
Software Evolves…
 If your software is usable, it will have changes in it and have future
releases.
 Clients will add new features, or users will want changes.

29
After some days, you’re about to bring some
changes in your code.

30
And…

You don’t
understand
your own code

31
If you don’t practice standards, it’ll be very, very
difficult to maintain the project later

So What are
best practices?

32
Software Development Life Cycle

33
Definition of Software Development Life Cycle
(SDLC) (or) Project Life Cycle (PLC)
The various phases which are under taken sequentially
when developing a software are commonly modeled as
Software Development Life Cycle (SDLC) (or) project life
cycle (PLC).
The software development life cycle begins with the
identification of requirements for a software and ends with
the formal validation of the developed software against the
requirements.

34
Software Life Cycle
 Software construction goes through a progression of states

35
Requirements Analysis What is the problem?
Problem
Problem
Domain
Domain
System Design What is the solution?

What are the mechanisms

Program Design that best implement the
solution?
How is the solution Implementation
Implementation
Program Implementation constructed? Domain
Domain
Testing Is the problem solved?

Delivery Can the customer use the solution?

Maintenance Are enhancements needed?

36
 IEEE
IEEEStd
Std1074
1074

Project Pre- Develop- Cross-

Cross-
Project Pre- Develop- Post-
Post-
Management Development ment Development
Development
Management Development ment Development
Development (Integral
(IntegralProcesses)
Processes)
> Project Initiation > Concept > Requirements > Installation >V&V
>Project Monitoring Exploration Analysis > Operation & > Configuration
&Control > System > Design Support Management
> Software Quality Allocation > Implemen- > Maintenance > Documen-
Management tation tation
> Training

37
38
 Feasibility Analysis/Assessment
 Planning & Estimation
Solution Definition
 System Requirement Specification (SRS)
 System Analysis & Design
 Coding
 Testing/Validation Build & Acquire

 Release/Delivery/deployment
 Maintenance/Technical Support

39
Study of user requirements to know any hurdles before designing the
system. Generally following areas are analyzed in this phase.
 Technical Feasibility
 Project Schedules/time frames
 Financial Activities
Key Players
 Analysts
 Developers
 Testers
Deliverables
 Feasibility Analysis Report 

40
Proper estimation is done in this phase to complete the given task.
Estimation is done in the initial phase of project based on the
requirements. Client has to approve the estimation. There are different
techniques like Function Point analysis, COCOMO (involves costing
also) for estimation. Estimation generally done by team
leads/experienced team members.
Key Players
 Team leads
 Senior Developers/Testers
Deliverables
 Estimation  

41
User/client requirements are collected in this phase from the client.
Requirements should be specific not generic. Following requirements are
collected in this phase.
Functional/Business requirements (how the user going to use the system)
Environmental requirements (like Hardware, Software, Networks etc.,)
User interface & Usability requirements (like look & feel, hot keys, key board
supports)
Main focus of the system is
Who is going to use the system? 
How will they use the system? 
Business logic of the system?
What data should be input into the system? 
What data should be output by the system?
Deliverables
System Requirement Specification (SRS) document 
Use Cases

42
Software requirements are transformed into architecture and detailed design. The
software system design is produced from the results of the requirements phase. 
Architects have the ball in their court during this phase and this is the phase in
which their focus lies. Architecture, including hardware and software,
communication, software design (UML is produced here) are all part of the
deliverables of a design phase
Key Players
 Architects and Developers
Deliverables
High level design (HLD)/ Architectural design
Low level design (LLD)/ Detailed design
Test Plan (TP)
Test Scenarios
Test cases documents
Test Matrix

43
Transforms design into code (business logic). Code is produced from the
deliverables of the design phase. Coding and unit testing are parallel
activities.
For a developer, this is the main focus of the life cycle because this is where
the code is produced.  Implementation may overlap with both the design and
testing phases.  Many tools exists (Computer Aided Software Engineering
(CASE) tools) to actually automate the production of code using information
gathered and produced during the design phase.
Key Players
 Developers
Deliverables
 Unit test Report
 Beta version of the application (.exe file, web link)
44
Validating the system against the user requirements. During testing, the
application is tested against the requirements to make sure that the system is
actually meeting the needs of the user needs addressed in the requirements
phase. 
System Test, System Integration Test, acceptance tests are done during this
phase.  Unit tests act on a specific component of the system, while system
tests act on the system as a whole.
Key Players
•Test engineer, Test Leads
Deliverables
•Final version of the completed application
•Test Summary Report (TSR) (Summary of System test, system Integration
testing)
•Test Incident Report (TIR) (any event (environment down etc.,) that occurs
during testing which requires further investigation.
•Test Status Report (TStR) (Progress/status of testing )

45
Release the application to the end user/Production environment
for real time use.

Key Players
 Developers
 Test engineers
 Team Leads

46
Supporting the application (24x7) during the run time (production) for
undetected errors during testing.
Technical support for the application may vary depending upon the
application criticality.
 Critical applications - 24 x 7 support
 Semi critical applications - 24 x 5 support
 Low critical applications - 12 x 5 support
Key Players
 Developers
 Testers
 Team Leads

47
Thank You

48
Requirements Engineering Principles
INTRODUCTION
 Software development, the software project life cycle starts with
capturing the requirements of the project. Developing product/service
is nothing but catering and taking the requirements to the next level.
Gathering, documentation and managing the requirements is the key to
success any project.

 According to industry average, more than 90% of the software projects

fail due to faulty or incomplete requirements capturing.
Few failed projects
1. Project Name: Cover Oregon
Type: Health care exchange- Web based application
Country: United States
Project cost: ~$200 million
Year 2012-2014

2. Project Name: Knight Capital

Project type: Retail Brokers
Country: United States
Project cost: ~$440 million
Year 2012
Few failed projects
3. Cost of Mumbai metro project increased from Rs 2356 crores to
Rs 4321 crores.
4. Blackberry 9500 launched in a market to compete with Apple’s
iPhone. Highly volatile market which demanded for performance.
Unfortunately, the storm didn’t performance expected. It had
various flaws in its technology .Flaws like No Wi-Fi, Memory,
Capacitive Touch Feature. Due to all such issues, customer is
reluctant to buy Blackberry Storm, resulting in low prices and no
resale value
What is requirement engineering
 According to IEEE standard 610.12-1990, requirement is defined as “a
condition or capability needed by a user to solve a problem or achieve
an objective”

 “Requirement engineering is the discipline that explores the externally

imposed conditions on a proposed computer system and tries to
identify the capabilities that will meet those imposed conditions and
recording the same in the form of documentation called the
requirement document of the computer system”
Types of Requirements
The requirements are categorized as:
1. Functional/User requirements
2. Non functional requirements
3. Interface specifications
Functional Req
 The set of req that defines what the system will do or accomplish is
called functional req. These reqs determine how the software will
behave to meet users’ needs.

 It will capture business logic, data logic, data manipulation, processing

logic, decision making so on. Functional req are often captured in ‘use
cases’.

 An example of functional req is a web based taxi service “Ela Cabs

Rental System” software. It captures main page details/parameters,
different types of roles, types of vehicles, where vehicle will be used
(local/national), payment options etc
Non Functional requirements (NFR)
 Functional req are supported by non functional reqs. The quality
attributes, the design and architecture constraints that the system must
have are called NFRs.
 Few examples are;
 The system should be available 24x7
 The car rental system s/w should display list of current
available cars in 30 seconds
 System should adhere to X.509 standard

 Some of the quality attributes of the system which forms NFR are
performance, availability, usability, security. From developers
perspective includes re-suability, testability, maintainability, and
probability.
Interface specifications
 It defines how the system will interact with other external system.
 Interface specifications helps in building different systems in such a
fashion that they can seamlessly interact with each other to produce the
desired outcome.
Steps involved in req engineering
 The req engineering process may vary based on the application
domain, a few generic steps are common across all types of software
projects. The Requirement Engineering steps are;
• Feasibility study
• Requirement elicitation
• Requirement analysis
• Specifying and validating requirements
• Requirements management
USE CASE
 Project Title: Web based e-Learning tool for the Disabled – LOTUS
 Problem statement or Request for work: Development of web portal on
windows & mobile app for disabled children. The solution for
Accessibility for the Disabled in the domain of e-Learning is
for the children's of the age group up to 10 years. The purpose of the
implementation is to enhance the learning process of children with
autism. This application helps these children to learn with the help of
multimedia (i.e. image, audio or video) or 3D content, through a
learning environment, that can be accessed over mobile devices.