Project Management

1
Project Management Software Engineering
Techniques to Achieve High Software Quality
2
Introduction

• What is Quality?
• Project Management Practices
• Software Engineering Practices
• Purpose
• Workflows
• Templates
• Process Improvement Practices
• Review Case Studies to Reveal Techniques

3
Software Engineering

• Best Practices
• Business Modeling
• Requirements Analysis
• Design
• Coding Unit Testing
• Software Testing
• Software Release

• Modeling
• Simplification of reality
• Enough Detail to develop and review effectively

4
Engineering Best Practices

• Analyse the Problem
• Qualify the Solution
• Break up the Solution
• Control the Relationships

5
Quality Assurance Best Practices

• What are they?

Quality Control
Configuration Management
Validation Verification
Testing Evaluation
6
Business Modeling

• Purpose
• Understand Business Domain of an organization
• Identify Business Actors and Business Objects
• Communicate a common understanding to
  stakeholders
• Derive system requirements
• Justify Business Case
• Decreased Costs
• Increased Revenue
• Workflow
• Find Business Actors and Use Cases
• Develop Business Use Cases
• Review Update Business Use Cases

7
Business Modeling

• Template
• Context and Scope
• Business Use Cases
• Business Use Case Model
• Actors
• Name, Role, Description, Use Case List
• Business Use Cases
• Goal, Main Scenario, Alternate Scenario
• Business Object Model
• Business Workers, Business Entities
• How BUCs are performed in terms of these
• Class represents organisational responsibility
• Supplementary Business Specification

8
Business Modeling Lessons

• Identifying Use Cases that arent Business Use
  Cases
• Business Actors are external to business
• BUCs are business processes
• Identifying Business Objects that arent Business
  Objects
• Doing it when not necessary
• Not for all new features
• Do for new projects
• Do when lots of people involved
• Do when lots of information to handle
• Business Justification not being done yet

9
Requirements Analysis

• Purpose
• To come to an agreement with the customer and the
  users on what the system should do
• Basis for estimation and planning the technical
  contents of iterations
• Define a User Interface for the System
• Classic Definition
• A Requirement is a condition or capability to
  which a system must conform
• Definition for Use
• WHAT the system does, NOT HOW

10
Requirements Analysis

• Workflow
• Requirements Input
• Prototyping
• Business modeling
• Joint application development
• Request for Comment
• Develop Requirements
• Template
• Requirements Review Update
• Review
• Quality control mechanism
• Requirements under configuration management
• Review checklists
• Appropriate scope, ambiguous, clear, missing
  requirements

11
Requirements Analysis

• Template
• Scope
• Assumptions, Dependencies, Constraints
• Use case diagram
• Use Cases
• Actors
• Scenarios
• Activity Diagrams
• Screen Layouts

12
Requirements Analysis

• Template
• Requirements
• Functional
• Usability
• Reliability
• Performance
• Supportability
• Environmental
• Documentation
• Security
• Other
• Consequences

13
Requirements Analysis

• Object Modeling
• Attributes
• Responsibilities
• Relationships
• Boundary, Control or Entity

14
Requirements Analysis Lessons

• Understand Needs - the Why
• Allows prioritisation
• Allows trade-offs good design decisions
• Requirements that arent requirements
• Propose or lean towards a solution
• Describe the HOW

15
Requirements Analysis Lessons

• Use cases
• Over reliance on a main scenarionot enough
  alternative scenarios
• Weak expression in scenario steps
• Dont allow steps to become too long or
  descriptive
• Prefer active voicea verb is said to be in the
  active voice if its subject is the agent of the
  action
• Use activity diagrams when use descriptions
  become complex and repetitive
• Gives give clear definition of scope and level
  then use cases
• User Interface Prototypes
• Good visual feedback for user by capturing
  interactions with system
• Dont let it become the end of requirements
  analysis though

16
Design

• Purpose
• Translate requirements into a specification that
  describes how to implement the system
• HOW we do requirement X
• Workflow
• Design Input and Preliminary Design Review
• Prototypes
• Good risk mitigation
• Examines non-functional requirements
• Request for Comment
• PDR
• Good for junior engineers

17
Design

• Workflow
• Design Development
• 41 view of Architecture
• Use cases (1)
• Logical View
• Process View
• Deployment View
• Implementation View
• Detailed Design
• Template
• Design Review
• Quality control mechanism
• Design under configuration management
• Verification of Requirements
• Design Evaluation
• Reuse
• Maintainability
• Reliability
• Performance

18
Design

• Template
• Scope
• Design
• Use Case view
• Logical Object Model
• Process view
• Deployment view
• Implementation view
• Design Assessment
• Design Alternatives
• Maintainability
• Reliability
• Performance
• Architecture and Detailed Design drill down on
  these at different levels

19
Design Lessons

• Object Models
• Finding Objects and Classes that arent
• Betrand Meyer The Grand Mistake
• This class performs and Single function
  classes
• Remember, classes are usually a noun or adjective
• Non-functional requirements
• Design for these, DONT test them in

20
Coding Unit Testing

• Purpose
• To implement classes and objects in terms of
  components
• To test the developed components as units
• To integrate into an executable system the
  results produced by individual implementers or
  teams
• Workflow
• Code (at last!!!!)
• Code review unit test
• Which one first
• Quality Control mechanism
• Coding standards
• Path Flow Coverage
• Once reviewed under configuration management
• Verify Design
• Validate requirements

21
Coding Unit Testing

• Template tools
• C Header templates
• Automated Testing Infrastructure
• Tstlib
• Run nightly
• Results published

22
Coding Unit Testing

• Template tools
• Path Flow Coverage (PFC)
• White Box Testing
• Unit Testing should result in high PFC

23
Coding Unit Testing

• Template Tools
• Path Flow Coverage

24
Coding Unit Testing

• Templates Tools
• Revision Control System (RCS)
• Maintenance of a tree of revisions
• Trunk revisions are on central line
• Branch revisions are to the sides
• Trunk revisions, branches and branch revisions
  can be labeled symbolically
• Resolution of access conflict and merging of
  revisions and resolution of conflicts
• Release and configuration control

25
Coding Unit Testing

• Templates Tools
• Revision Control System (RCS)
• Nightly Builds
• Daily RCS logs
• /src/forms/master/src/eqlib/common/fxform.cxx,
  v revision 3.2date 1996/04/12 042539
  author shaun state Exp lines 4 -4DTS
  9001. Previous change wasn't quite correct.
  Reviewers pca, agw.
  /src/forms/master/src/eqlib
  /common/text1.cxx,v revision 3.33date
  1996/04/12 060720 author joeca state Exp
  lines 4 -3DTS9001 added member
  initialization for copy constructor to stop
  purifyUMR's. Rev michael
  /src/forms/master/src/
  eqlib/common/browser.cxx,v revision
  1.11.3date 1996/04/12 060917 author
  michael state Exp lines 38
  -29DTS14306Fixed msie i/f to work with dde
  calls. rev joeca.
  

26
Coding Unit Testing Lessons

• Keep modules small
• Reduces complexity
• Makes code easier to understand
• Develop Unit tests as you code
• Avoid evil hack and slash temptation when you
  uncover significant design and requirements
  defects

27
Software Testing

• Purpose
• To execute a program with the intent of finding
  an error
• To Break the Program
• Verify that all requirements have been correctly
  implemented
• Workflow
• Develop Test Plan review
• Template
• Review for Team resource plans, test case
  selection, risk reduction strategies, release
  criteria applied, conformance to standards, inter
  team interactions are planned and coordinated
• Develop Test Procedure review
• Template
• Review for clarify, completeness, usability,
  reusability, traceability to requirements,
  satisfies plan, conformance to standards

28
Software Testing

• Workflow
• Develop Test Scripts review
• Template
• Review for satisfaction of test case, test script
  coding standards
• Testing tools
• Perform Tests
• Forms
• Testing tools
• Summarise and Review Test Results
• Forms
• Review for release readiness

29
Software Testing

• Templates Tools
• Test Planning
• Scope
• Approach
• Environment
• Test Procedure
• Scope
• Test case design
• Equivalence Partitioning
• Limits Testing
• Test cases

30
Software Testing

• Templates Tools
• Test scripts
• Regression suites
• Common Testing Infrastructure Library (CTIL)
• SilkTest
• Perform Tests
• Manual Testing
• Efficiency - Purify Quantify
• Reliability - Volume Testing Limits Testing
• Memory Usage Testing
• GUI Testing - Usability
• Test Summaries

31
Software Testing Lessons

• Thoroughly inspect the result of each test
• Test cases must be written for the invalid and
  unexpected (as well as the valid and expected)
• Make test cases and data repeatable
• Do NOT plan a testing effort on the tacit
  assumption that no errors will be found
• Dont automate everything
• Automate where there is a benefit
• Apply coding workflows to Test Scripts
• Recognise that Testware is as much a deliverable
  as software

32
Software Testing Lessons

• Regression test suites
• Ensure they are maintained
• Build capability to recover from errors
• Structure tests so that success is not dependent
  between test cases
• Start each test from a known base state

33
Software Release

• Purpose
• To determine if the product is ready for use by
  our customers by ensuring that all requirements
  and release criteria have been met
• Workflow
• Product Development Testing is complete and
  Release Criteria met
• Dependent on release type
• Alpha, Beta, Manufacturing release
• Update, General Availability

34
Software Release

• Workflow
• Defect Density severity measures
• Critical
• Serious
• Medium
• Low
• Coverage measures
• For new and modified code

35
Software Release

• Workflow
• Customer Care release criteria met
• Customer usability and upgrade impact
• Release notes and documentation usability
• Manufacturing release
• Master source and build CDs cut
• Master product CD cut
• Escrow cut
• CD autorun

36
Software Release Checklist

• Release Checklist
• All stakeholder groups sign-off that release
  criteria have been met
• Guides developers through the release process
• Records notes about the release
• Identifies
• Product name
• Package Name and Build Number
• Release Platform/s
• Product Distribution Details
• Product Changes Defect Fixes

37
Process Improvement

• Best Practices
• Standards Process Frameworks
• Continuous Improvement
• Process for Process Improvement

38
Process Improvement Best Practices

• Put effort into Prevention
• Detect and Correct Early
• Eliminate the Cause
• Audit the Work
• Process and Project Level

39
Standards Process Frameworks

• Models
• ISO 9001
• SEI CMM
• RUP
• Mentor
• Extreme Programming
• Xerox - Steal from others but Adapt

40
Continuous Improvement

• Wedge and Ball model for continuous improvement

41
Process for Process Improvement

• Specify Goals of Process
• Simple
• Meet customer and market requirements
• Reduce development time
• Produce high quality products by putting effort
  into prevention
• Identify remove wastes
• Waiting
• Inappropriate processing
• Unnecessary actions
• Transporting
• Defects
• Overproduction
• Unnecessary inventory

42
Process for Process Improvement

• Identify prioritise current process issues
  select headings
• Brainstorm on issues
• Fishbone diagram (Cause-Effect Diagram)
• Analyse issues propose solutions to address
  issues
• Brainstorming
• Why-Why
• How-How
• Define process and review including selection of
  methods and development standards
• Activity Diagrams
• Develop and review templates and work
  instructions to support process
• Trial new processes, methods, templates and tools
  as appropriate
• Training of people

43
Conclusion

• Use Software Engineering and Process Improvement
  techniques to produce high quality software and
  improve your own personal practices as well as
  that of your organisation

44
Closing Remarks
45
Info

• OSA - http//www.osa.com.au/common/ppt/missile.ppt
  
• ACS Presentation on 4Ps of Short Cycle Product
  Development
• Rational http//www.rational.com/
• Unified Software Development Process
• Constantine Lockwood http//www.foruse.com/
• Software for Use