../

Graduate Presentation

  • Team selection 3/17
  • Topic 3/31
  • Present on 4/16, 21, 23, 28
  • Papers posted on Canvas
  • 15 minutes
  • Prepare class activity and submit it 1 day before

Notes

The slides seem to be a study on a large number of professional projects It is not possible to cover all 43 rules in class and some of those like hiring people/ not working them too much seem irrelevant. So the plan would be to pick out rules that are relevant/useful for the final project Show off the mistakes that we all made when doing mini projects

The full list

  1. Informal development process
  2. Not enough paper
  3. No written requirements
  4. Requirements omit extra-functional aspects
  5. Requirements with poor measurability
  6. No defined software architecture
  7. Poor code modularity
  8. Too many global variables
  9. No message dictionary for embedded network
  10. Design skipped or created after code is written
  11. Flowcharts are used in place of statecharts
  12. Inconsistent coding style
  13. Ignoring compiler warnings
  14. No peer reviews
  15. No real time schedule analysis
  16. Use of home-made RTOS
  17. Inadequate concurrency management
  18. No methodical approach to user interface design
  19. No test plan
  20. No stress testing
  21. No defect tracking
  22. No run-time fault instrumentation nor error logs
  23. Defect resolution for 3rd party software
  24. Disaster recovery not tested
  25. Insufficient consideration of reliability/availability
  26. Insufficient consideration of safety
  27. Insufficient consideration of security
  28. No IP protection plan
  29. No or incorrect use of watchdog timers
  30. Inadequate system reset approach
  31. High requirements churn
  32. No version control
  33. No backward compatibility plan
  34. No software update plan
  35. Lessons learned not being recorded
  36. Acting as if software is free
  37. Use of cheap tools instead of good ones
  38. High turnover and developer overload
  39. No training for managing outsource relationships
  40. Resources too full
  41. Too much assembly language
  42. Project schedule not taken seriously
  43. No Software Quality Assurance (SQA) function

Feedback

  • Make sure you cover anything relevant from the paper/resource you are referring to in the presentation. I see several interesting slides and examples from the original slide deck that you didn’t cover.  Remember that you will have 15 minutes, and the discussion should be more technical

  • Can you revise the class activity questions so that they are not very open-ended?  For example, if you provide more examples and details in your slides, you can ask them to assess specific types of practices (in requirements, design, testing, or other aspects) and provide examples. The second question is very open-ended. I would revise it with a question based on a practical example. Maybe you can ask the students about a specific Mini Project they did and how specific practices discussed here were addressed or not addressed in it.

Categories

Technical

  • 7 Poor Code Modularity
  • 8 Too many global variables
  • 9 No message dictionary for embedded network
  • 11 Flowcharts are used in place of state charts
  • 12 Inconsistent coding style
  • 13 Ignoring compiler warnings
  • 15 No real time schedule analysis
  • 16 Use of home-made RTOS
  • 17 Inadequate concurrency management
  • 18 No methodical approach to user interface design
  • 19 No test plan
  • 20 No stress testing
  • 21 No defect tracking
  • 22 No run-time fault instrumentation nor error logs
  • 23 Defect resolution for 3rd party software
  • 24 Disaster recovery not tested
  • 25 Insufficient consideration of reliability/availability
  • 26 Insufficient consideration of safety
  • 27 Insufficient consideration of security
  • 29 No or incorrect use of watchdog timers
  • 30 Inadequate system reset approach
  • 32 No version control
  • 41 Too much assembly language
  • 43 No Software Quality Assurance (SQA) function

“Process”

  • 1 Informal development process
  • 2 Not enough paper
  • 3 No written requirements
  • 4 Requirements omit extra-functional aspects
  • 5 Requirements with poor memorability
  • 6 No defined software architecture
  • 10 Design skipped or created after code is written
  • 14 No peer reviews
  • 35 Lessons learned not being recorded

Management

  • 28 No IP protection plan
  • 33 No backward compatibility plan
  • 34 No software update plan
  • 36 Acting as if software is free
  • 37 Use of cheap tools instead of good ones
  • 38 High turnover and developer overload
  • 39 No training for managing outsource relationships
  • 40 Resources too full
  • 42 Project schedule not taken seriously