The document outlines the software development life cycle (SDLC) encompassing phases from system analysis to maintenance, emphasizing the importance of documentation, customer insights, and careful planning for each stage. It discusses key practices such as domain analysis, coding standards, various testing methodologies, and software metrics to ensure successful implementation and maintenance of software projects. Additionally, it highlights the role of CASE tools in automating software engineering tasks throughout the process.

1. What is Software?
A set of programs
designed for specific predefined purpose(s).

2. Input
Process
Output

3. You won’t work on the same project all
your life.
You won’t work in the same company all
your life.
Maintenance work is difficult without
documentation.
To experience the importance of
documentation, work on another person’s
project part without documentation.

4. Software Development Life
Cycle (SDLC)
System
Analysis
System
Study
Implementation
System
Design
Construction
Testing

5. System Study Phase
Domain Analysis
Functional experience
Get your Customer’s point of view
Customer is NOT just the Management, but
also the end-users
Your team members are also your
customers (internal)…get their points of
view as well

6. System Study Phase
Domain Knowledge
 Which field or subject is the software for?
 What are the classifications & hierarchies used?
 What are the core principles of the field?
 Get expert’s advice.
 Interview people working at your Customer’s
place.
 Read technical literature of that domain.
 See software already done in that domain.

7. System Study Phase
Domain Analysis Inputs
Technical literature
Existing software
Customer surveys
Expert advice
Current / future requirements

8. System Study Phase
Domain Analysis Outputs
Class taxonomies
Reuse standards
Functional models
Domain languages

9. Software Process
Process Maturity Levels
SEI’s CMM
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Managed
Level 5: Optimized

10. System Study Document
 Domain Analysis Model
 Overview of current system (CAD)
 Inputs
 Outputs
 Processes
 External entities
 Data stores
 Physical DFD of current system
 Logical DFD of current system
 Data Dictionary of current system

11. System Analysis Phase
 Problems faced in current system (Bottleneck
Analysis)
 Possible solutions
 Benefits Analysis of each possible solution
 Selection of new system
 CAD, Physical & Logical DFD of new system
with Automation Boundary
 System Proposal document
 Customer’s approval

12. System Design Phase
 Benefits of new system are Project Goals.
 Balance between Top-down and bottom-up approaches.
 Drilling down top-level DFDs to detailed DFDs.
 Data Dictionary of new system (if different from old).
 Automation Boundary for the new system.
 Database Design, User Interface Design.
 External events, system states & system behaviour.
 Project Specifications document for both manual and
computerized parts of the new system.
 Freeze Specs.

13. Construction Phase
 Select programming language.
 Map Project Specifications document terms into
programming language terms.
 Construct data structures / classes / objects from class
taxonomies in Domains Analysis outputs.
 Construct Database from Data Dictionary.
 Construct User Interface.
 Input and output formats.
 Write Algorithms for processes.
 Directory structure and files list.

14. Construction Phase
Coding
 Commenting is extremely important.
 Every variable’s purpose must either have a
comment or must be mentioned in one of the
project documents.
 Every function’s / procedure’s purpose must either
have a comment or must be mentioned in one of
the project documents.
 Have checklist for every project part.

15. Testing Phase











Modular approach during development makes testing easier
Testing strategies
Test cases mapped from Customer requirements
Checklists – specified-actual comparison
Errors – during development
Defects – after delivery to customer
Defect Rates
Validation testing – building the right product
Verification testing – building the product right
80% errors caused by 20% code in most software
Higher chances of errors in test cases with boundary values input

16. Software Testing Techniques










Black box testing – functionality-based
White box testing – all execution paths exercised
Integration testing – as each module is integrated into the system
Regression testing – repeat previous tests as integration
progresses.
Unit testing – individual program
Top-down approach – whole to parts, stubs and drivers required
Bottom-up approach – parts to whole
System testing
Alpha testing – by customer at developer’s place
Beta testing – by end-users at customer’s place

17. System Testing
 Software must work properly with the other
parts of organization’s system
 Recovery testing – force failure and see if
recovery is proper
 Security testing – sensitive info protection
 Stress testing – abnormal situations, high loads
 Performance testing – high priority for Realtime embedded systems

18. Testing for Real-time systems
 Task testing – test each task independently
 Behavioural testing – simulate behaviour, examine
 Intertask testing – task synchronization
 System testing – software/hardware interface
 Interrupts present in most real-time systems
 Test priorities assignment and handling
 Correct handling
 Performance of interrupt handling
 Test if high volume of interrupts creates problems in
function or performance

19. Debugging
 Errors – during development.
 Defects – after delivery.
 Observation and noting effects.
 Trace cause(s) from observed effects.
 List of probable causes.
 Test each probable cause and eliminate irrelevant ones and
arrive at actual cause(s).
 Partitioning or decomposing large problem into smaller,
simple problems.
 Inference and deduction.
 Fixing one bug may cause another new one.

20. Software Metrics
 Project, LOC, Effort, Cost, Errors, Defects, People
 Errors per KLOC
 Defects per KLOC
 Cost per LOC
 Pages of document per KLOC
 Errors per person-month
 LOC per person-month
 Cost per page of document

21. Software Metrics…
 Costing based on LOC has drawbacks. So,
Function Points-based costing replaced it.
 Function Points
 No. of user inputs
 No. of user outputs
 No. of user inquiries
 No. of files
 No. of external interfaces
 Count and Complexity Factor for each parameter
 Count * Complexity Factor gives the final measure

22. Implementation Phase
 If System Study was done precisely, most implementation
issues would have been handled at the beginning of the
project itself.
 Checklist containing end-users, locations, hardware &
software configuration.
 Software Configuration Management is the task that solves
most technical issues during implementation.
 Having a good rapport with people at customer site is
critical for implementation and finetuning.
 Implementation may lead to Corrective Maintenance.
 Communication and co-ordination with customer and endusers.

23. Maintenance
 Starts after delivery only.
 Good design considers maintenance issues.
 SDLC applicable in this phase.
 Checklists containing end-users, locations, hardware &
software configuration.
 Software Configuration Management is critical and is an
umbrella activity.
 Adaptive Maintenance must begin with Impact Analysis.
 Communication and co-ordination with customer and endusers is important.
 MTTC = Mean Time-To-Change

24. Reverse Engineering
Design document for a software not
available.
Analyze program to create
specifications.
Extract design from source code.
Recover design from whatever is
available in the project.

25. C.A.S.E.
 Computer-Aided Software Engg.
 CASE tools automate software engg. tasks in
every step of the process.
 CASE tools usually generate code as well. But
don’t expect it to generate the whole software!!!
 CASE tools build a framework for projects.
 e.g.: Rational Rose by Rational Software
Corporation which uses a process framework
named RUP (Rational Unified Process) which is
based on UML (Unified Modeling Language).