Assignment One Feedback

1
Assignment One Feedback

• Thanks to Saad Zafar

2
Overview

• Course Objective
• Assignment Objective
• Important Points
• Common Mistakes
• Conclusion

3
Course Objective

• A systematic introduction to the specification,
  design, implementation, and management of
  large-scale software systems, covering the
  software life-cycle, software engineering
  concepts and techniques, the programming
  environment, and software tools.

4
Assignment Objectives

• The purpose of the assignments is to construct
  and document a Requirements Specification,
  Design, Implementation, Test Results and
  Development Process for a simple software
  problem.
• You should strive to design and implement the
  system in such a way that it is built from
  reusable components that could be used in other
  applications.
• It is crucial that you carefully read the
  Guidance and Marking Scheme sections and supply
  what is required in your report.
• The emphasis of the assignments is upon the use
  of rigorous inspection to find faults in the
  products of the various phases of development
  before the software is ever compiled.

5
Important Points
6
Project Planning

• This section should include
• Expected time to complete each phase of the
  development process
• Verification and correction of the product
  produced in each phase
• Expected number of person hours to be spent on
  each activity
• Actual time taken and when the task was actually
  completed
• Names of team members responsible for each of the
  tasks
• The earned value, projected cost and actual cost
  calculated at per hour per person basis
• Summary included at the front of the report
• The numbers add up for all phases with the
  summary

7
Project Summary
8
Summary of Planning Phase
9
Project Productivity
10
Project Costing
11
Project Schedule
12
Project Task List
13
Requirements

• Documentation of analysis of the original
  problem
• Problems with each individual requirement
  identified
• Assumptions documented
• Data dictionary included
• Backwards traces included
• Requirements (correctly) formally specified using
  BT

14
Requirements Phase Summary
15
Requirements Analysis

• Document the original problem statement
• Perform the behavior tree translation
• Document the assumptions
• Make sure to use the correct BT syntax
• BT has a tree structure (it is not a network
  diagram). Use symbol to join equivalent
  behavior tree nodes
• The reversion node can only be a leaf not in BT
• Cleary distinguish between a condition and an
  event

16
Assumptions Documentation
17
Data Dictionary
18
Architectural Design

• Design Behavior Tree
• Design behavior tree is created by integrating
  individual requirements
• Integration problems are documented
• Component Dependency Network Diagram
• All highest level components are identified
• Component interaction and the interfaces have
  been documented
• Component Projection Diagram
• Interfaces and behaviour of each component from
  DBT has been projected out correctly
• Architectural Design Verification

19
Integrated Behaviour Tree

• All requirements are integrated together
• Integration problems must be documented
• Missing Pre-conditions
• Inconsistencies in the requirements
• Redundancy in the requirements
• Incompleteness of the requirements

20
Component Dependency Diagram
21
Component Interaction
22
Component Projection and Interface Documentation
23
Architectural Design Verification
24
Detailed Design

• Objects and methods used in the implementation
  have been identified
• The objects and methods for implementation have
  been derived from the behaviour of individual
  components
• Detailed design verification

25
Identification of Objects and Methods
26
Detailed Design Verification
27
Implementation

• System and its components are documented
• Components, variables, objects and methods have
  self descriptive names
• The systems component architecture is readily
  apparent in the implementation
• Reusable classes have been used (whenever
  possible)
• Verification
• Direct correspondence between the design and the
  implementation has been established
• Requirements traceability matrix has been included

28
Verification
29
Requirements Traceability Matrix

• A traceability matrix is created by associating
  requirements with the work products that satisfy
  them

30
Testing

• Documented test cases are supplied (for another
  groups program)
• Documented test results of another groups
  testing of the program is included (including the
  report/response from the other group)
• Component test standard has been used

31
Error Analysis

• Error Analysis
• Type of errors found (design error, etc.)
• Errors found in each phase (implementation,
  testing, etc.)
• Measure of how many errors found after the first
  compile and by independent testing
• Appropriate table has been used for documentation
  of error analysis

32
Defect Types

• Documentation
• Syntax
• Compilation
• Interface
• Data
• Function
• System
• etc.

33
Common Mistakes

• Summary not included on the front page
• The phase data and summary data do not match up
• BT syntax not followed
• Did not document architectural design and
  detailed design separately
• Architectural verification not documented
• Detailed design verification not documented
• Architectural design not evident in the
  implementation
• Verification and traceability of implemented code
  to detailed design and architectural design not
  documented
• Testing of ones own program by another group not
  documented
• Error analysis section did not include analysis
  of error types

34
Conclusion

• Follow the process (assignment guidelines)
• Pay careful attention to the marking scheme
• Document summary of data for each phase
• Document each phase separately
• The report should be concise and precise
• Present a professional looking document