Components of Successful Software Projects

A successful software project is much more than just getting the code to compile and run. Building a successful piece of software requires multiple stages of planning and execution. The success or failure of the project will depend as much upon the processes used for development the project as the final project itself. This presentation is a high level survey of key processes and considerations that should be addressed for any project, from the beginning to end. When to use them, when they can be skipped and what the consequences can be if a process is skipped inappropriately.

Transcript

1. Lloyd Moore, President Lloyd@CyberData-Robotics.com www.CyberData-Robotics.com Components of Successful Software Projects
2. Overview  Planning and Design Phase  Construction Phase  Verification & Validation Phase  Hardening Phase  Summary
3. Planning and Design Phase  Problem statement, purpose statement  Requirements document  Process design  System design  Interface design  Security / threat model
4. Planning: Purpose Statement  A simple one or two sentence statement of WHY the project is being under taken.  Focuses and guides the project  Almost no cost to create this in a minimal fashion. Can also incorporate market research.  Without this project can wander and you may build something not needed.  Should never be skipped.
5. Planning: Requirements  A formal or semi-formal list of what the system must do.  Will translate directly to top level feature tasks.  Prevents scope creep and focuses development.  Also defines when the project is done.  VERY simple projects may be able to skip this.
6. Planning: Process Design  Defines the development process for the team.  Repository processes, review processes, testing processes, etc. This presentation can be used as a starter check list!  Forces the question of what is appropriate for this project.  May not always need to do this if you have a well established process already.
7. Planning: System Design  A more detailed design of how the system will be constructed. May be done in UML or other modeling language.  Catches architecture flaws early, allows the project to more easily be done in parallel.  Can be simple to VERY extensive.  Should never be skipped. Even a simple diagram on the back of a napkin is helpful!  Also helpful for driving library selection.
8. Planning: Interface design  Fully defines ALL interfaces in the system.  Ensures different components work together easily during integration phase.  Cost is generally pretty minimal.  If not present development will lag as the protocols get worked out “real time” and integration will take much longer.  One developer on a program that doesn’t interact with anything may not need this.
9. Planning: Security / Threat Model  Not necessary for every project  If needed should be designed in from the start, not retrofitted later on!  Plenty of material available here so won’t dive too deep.  Also think about industry specific requirements:  Personally Identifiable Information (PII)  Children’s Internet Protection Act (CIPA)  International Traffic in Arms Regulations (ITAR)  Many others – these are just a few I’ve seen!!
10. Construction Phase  Code comments  Static analysis / style checks  Code reviews  Unit tests  Continuous Integration  Merge checks/gates
11. Construction: Code Comments  “Self documenting code” is necessary but not sufficient!  Code will only capture what the code does and not the developer’s intent!  Minimum:  Each module / class has a description  Each function / method has a description  All “magic numbers” documented  Any “complex” algorithm documented
12. Construction: Static Analysis  Already covered some of this in my Culture of Code Reviews talk:  https://nwcpp.org/July-2020.html  Goal is to let developer stay focused on high level concepts, and automation catches detailed mistakes.  Fairly simple to setup these days for basic checks.  Commercial tools can be expensive.  Recommend always having at least basic checks these days. Free, easy to use tools exist.
13. Construction: Code Reviews  Included here for completeness.  See my talk: Culture of Code Reviews  https://nwcpp.org/July-2020.html
14. Construction: Unit Tests  Should know what this is!!  Included here for completeness, not going into much detail.  Note that these are important for gating checks and CI which are next on the list!  May not want these for experimental / prototype code as they tend to slow down the process.
15. Construction: Continuous Integration  Automates the development, testing and deployment processes.  Mostly a time saver, however for complex systems also ensures correct process.  Can be expensive to setup and maintain. Often has a dedicated person.  Implement when you are spending more time managing the process then it takes to setup and/or mistakes are starting to appear.
16. Construction: Merge Checks  Automated checks that must pass before ANY commit can be merged into a “master” or “development” branch.  Typical Checks:  Clean code review, all issues resolved  Passing unit tests  Passing style check  Passing static analysis  Minimal cost to implement if all the “basics” are in place  Will ensure the protected branch is always “good”; builds, passes base tests.  Small teams (1-3 devs) can often skip this formality. Simply put the checks into your local build process. (“make check”)
17. Verification & Validation Phase  Does the system meet the requirements?  Integration testing (hardware, ext systems)  Customer testing  “As built” documentation
18. Verification: Requirements Testing  Typically one test for each requirement.  Demonstrates the system meets the original goals and intents.  Can be time consuming to build, but essential. Typically combination of unit and integration tests.  If you do not have this you CANNOT demonstrate a successful project!
19. Verification: Integration Testing  Often intermixed with Requirements Tests.  Demonstrates system can inter operate with related systems reliably.  Ideally includes testing error conditions and edge cases.  Can be time consuming to build.  Can you skip it? : Knight Capital Group  https://en.wikipedia.org/wiki/Knight_Capital_Group
20. Verification: Customer Testing  Does the system meet the customer’s needs? Also called Beta Testing or Acceptance Testing in some cases.  Ideally verifies requirements as well.  Will always be present, even if not “official”.  Best to have an official process to capture and manage feedback.
21. Verification: As Built Documentation  Update ALL documentation to reflect how the system was actually built.  Can be part of the formal hand off process to the customer.  Have also mixed this into training new team members – first task, study the system and update documentation.
22. Hardening Phase  Does the system behave reasonably in bad or abusive environments?  Stress testing  Fuzz testing  Penetration testing
23. Hardening: Stress Testing  Applies “pressure” to each aspect of the system to ensure it meets the requirements.  Dimensions: Memory, compute load, database size, network load, EMI, radiation, temperature, etc.  Typically special tests operating in special conditions.  Failures in the field will be difficult or impossible to diagnose.
24. Hardening: Fuzz Testing  Generally applies malformed input to the system and ensures proper behavior.  May be wrapped with security testing.  Specialized tests and set ups.  Cannot ensure a secure system without.  Can likely skip this in cases where security is not an issue, or all system inputs are controlled and well defined.
25. Hardening: Penetration Testing  Typically a “third party” will attempt to break, or break into the system.  Also typically assumes malicious intent.  Further establishes the security of the system.  Can skip this for many systems as it can be costly.  Need to evaluate the cost if the system is hacked.
26. Summary  Building a successful system requires multiple stages of planning and execution.  Need to select the activities that are appropriate to the project at hand.  Need to balance costs of “having” vs. “not having” for each activity.  Need to establish a realistic budget BEFORE starting.
27. Questions?
28. Heading  What it is  Benefits of having  Costs of having  Costs of not having  When can you skip it?