This presentation was used to train the students studying Embedded Systems in the Anna University campus (AU-PERS Centre) by me (Sanjeevi Prasad). I used to be a guest lecturer here in the year 2003. I was given an appreciation letter by this centre because they saw distinct improvements in the performances of their students in project evaluation by the IT professionals of a well-known IT MNC.
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.
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).