1. ITTC Software Projects
Life Cycle - Phases of a project
Research version of cycle
Deliverable Product version of cycle
Best Practices - Guidelines for executing project phases

2. ITTC Project Life Cycle/Research
Proposal
System Testing
Demonstration
Report
Funding
Integration
Best Practices
Unit Testing
Requirements
Third Party SW
Unit Implement
Specifications
Design

3. ITTC Project Life Cycle/ Delivery
Proposal
System Testing
Acceptance
Funding
Integration
Packaging
Best Practices
Unit Testing
User Docs
Delivery
Requirements
Maintenance
Unit Implement
End of Life
Specifications
Design

4. Life Cycle - Proposal How is a project initiated?
Response to a Request For Proposal (RFP)
Request from Govt. for research in a specified field of interest
Solicitation of Private Sector Companies to sponsor a project.
Follow on work from earlier project

5. Life Cycle - Funding Receive money from sponsoring entity.
Government - DARPA, NSF, etc.
Private Sector - Sprint, etc.

6. Life Cycle - Best Practices
Best Practices are guidelines for executing the remainder of the project phases
Best Practices are determined by Principle Investigator (PI) and staff for each project.
Best Practices are derived from ITTC Best Practices template.
Delivery of Best Practices are via WWW pages.

7. ITTC Best Practices
Key driver for Best Practices usage is knowledge capture.
Knowledge capture occurs with documentation.
Knowledge capture is critical with a high personel turnover rate
Project life times can range from 1 to 4 or more years.
Student duration at ITTC averages 1.5 years.
SW reuse is facilitated through documentation
Software is frequently shared between projects.
Best Practices can answer many common new hire SW development questions.

8. ITTC Best Practices (cont)
Best Practices provide a mechanism for structured/organized software development
Defined directory structure
Developers know where to put files
Source code Version Control System
Revision histories are automatic
Specific versions of the project are easily captured/retrieved
Source code templates
Source code structure is consistent through the project
Naming conventions
File/Directory
Document Names
Source code Identifier Names

9. Document Relationships
Requirements - describes environment outside the software (SW).
Specifications - Describe the interface between the environment and the software.
Design - describes the internal design of the software.

10. Document Relationships (cont)
Requirements
Environment
Actors
Information
Specifications
Interface
Software
Design

11. General Document Best Practices
Use Microsoft Word to generate document.
Use Microsoft Powerpoint to generate pictures and presentation slides.
Use present tense sentences.
Omit the words ‘I’, ‘we’, and ‘you’ in sentences.
Use ‘shall’ for items that must be executed.
Use ‘should’ for items that are goals.

12. Life Cycle - Requirements Docs
Requirements describe the environment the SW exists in and WHAT the SW must do.
Requirements are typically the first documents created for a project.
The environment is known.
The software behavior is known.
In a research setting requirements for two or more sets of behaviors may be written
There are two or more project threads.
The specifics of the interfaces are unknown.
The design is unknown.

13. Requirements Docs (cont)
Requirements capture the intent of a project for future team members.
Requirements consist of the following:
Environment actor characteristics
People
Computers and hardware
External Software
Description of data passed between the actors and the SW and under what circumstances
What the SW must do with the data or what the data does to the software
Restrictions and necessary performance of Actors, Data and SW

14. Requirements Docs (cont)
On most projects a hierarchy of requirements are created.
There are two routes to creating the requirements hierarchy
Make sub requirements documents that expand on general higher level requirements. This can be recursive.
Make a requirements document, specifications document and design document. From the design document logical divisions of project can be made. Requirements are written for each project division. This can be recursive.

15. Requirements Docs Best Practices
Each Requirement doc must have the following:
Title page
Project name
Document version
Author’s name
ITTC Copyright Page
Introduction Section
Describe what the document contains.
Requirements Section
Describe Environment Actors
Describe data passed between Environment and SW
List of what SW is required to do to interact with environment.

16. Requirements Docs Best Practices
Each requirement must have a unique ID within the document.
Requirement Ids must not be changed or reused.
Requirement Ids are referenced in other requirement, specification and design documents and possible in source code.
If the requirement expands on a higher level requirement the higher level requirement must be references by Requirement Document name and Requirement ID.
Deprecated Requirements Section
Requirements that are no longer used are moved to this section for historical purposes.
Revision History
List who changed the document, when and why and what the version number was.

17. Life Cycle - Specification
Interface Specification is the description of IO interfaces between the environment and SW.
Specification Documents typically are created following the creation of Requirements Documents.
Requirements documents list the interfaces that are required
Specification documents describe the details of the interfaces.
Typically there is a Specification document written for each Requirement Document at the lowest level in the requirements hierarchy.

18. Specification Docs
Specifications are a mechanism for unambiguous communication of interface information between project team members.
Specifications preserve interface knowledge for future team members.

19. Specifications Doc Best Practices
Specifications Documents must contain the following:
Title page - Same as Requirements
ITTC Copyright Page - Same as Requirements doc
Introduction Section - Same as Requirements doc
Specifications Section
User Interface
Application command line arguments
Graphical windows and menus
Other hardware interface devices (finger print scanners)
File formats
Communication protocols

20. Specification Docs Best Practices
Application Program Interface (API)s
Function Interfaces
Object classes
Data structures
Each specification must have a unique ID within the document.
Specification Ids must not be changed or reused.
Specification Ids are referenced in other specification and design documents and in source code.
Requirement(s) that the specification satisfies must be referenced using the Requirement Document name and Requirement ID.
Deprecated Specifications Section - Same as Requirements doc
Revision History Section - Same as Requirements doc

21. Life Cycle - Design
Design is HOW the SW meets the Requirements and uses the Specifications
Design documents are written after the Requirements and Specifications are written and before implementation.
The design process detects problems with Requirements and Specifications before implementation.
Well designed software greatly reduces time required for implementation.

22. Design Docs (cont)
The Design document captures the information needed by future team members to debug or modify the software.
Design documents with typically be developed in a hierarchy.
A System Level Design document is typically the first design document created.
The system level design document divides the project into well defined sub projects. example: user interface, database
Design Documents are created for each sub project.
The design is iteratively subdivided until a level is reached where implementation is straight forward.

23. Design Docs Best Practices
A Design Documents consists of the following:
Title page - Same as Requirements
ITTC Copyright Page - Same as Requirements doc
Introduction Section - Same as Requirements doc
Design Section
The design provides enough flexibility that during implementation the design does not have to be rewritten when small changes are made in the implementation.
Programming Language is determined
Functional divisions of software and their relationships are described.

24. Design Docs Best Practices (cont)
Design description mechanism to use include:
Control Flow Diagram
Thread relationships
Data Flow Diagram
State Transition Diagrams
Object/Class Relationship Diagram
Internal APIs
Unit test design for functional level designs
Unit level testability must be designed into the software.
Revision History
Each design must pass a design review before implementation begins.

25. Life Cycle - Implementation
Implementation consists of coding the design
Creating directory structures
Setting up a build mechanism
Coding
Language sensitive editors
Internal Documentation
Coding for testing
Using a Version Control System

26. Implementation Best Practices
All source files must contain the following:
ITTC Copyright - ALL RIGHTS RESERVED
Header
Synopsis -one sentence about the file contents
Usage ( form ‘main’ files, Makefile’s and scripts)
Author and Date info
Internal documentation
Source files must be understandable by future project members
Correct, Clear, Complete
Wrong documentation is worse than no documentation
Programmers unfamiliar with the code will have to work on it

27. Implementation Best Practices
Interface Descriptions
Algorithm Description (not pseudo code)
Use language constructs for code clarity
Identifiers should be full nouns/verbs or STANDARD abbreviations
Use spaces around operators (= , ! < )
Indent execution control statements (if, for, switch)
One API function or class per source file
Use multiple local functions in a file.
Short functions - less than 100 lines
Make a new function when tempted to copy and paste code.

28. Implementation Best Practices
Unit testing mechanisms must be incorporated
Debugging output
Test scripts/programs
Source Templates are used to assist in following the Best Practices
All code must pass a code review.
Development must occur on a VCS branch.
Code may only be merged to the ‘trunk’ when it passes unit tests.

29. Life Cycle - Unit Testing
Unit testing consists of executing code from a project unit and comparing the output to a GOLD output.
GOLD output is correct output for the unit.
Unit testing detects unexpected ‘bugs’ when an implementation changes.
A coder may not anticipate the total impact of an implementation change.
Unit testing may detect untested implementation changes before use by others on a project.

30. Unit Testing Best Practice
The unit implementor is responsible for creation of the GOLD output.
Automated Unit Tests are performed at a regular interval (daily, weekly)
Complete compilation
Unit output comparison with GOLD output.
Automated Unit Tests are performed on a Version Control System ‘trunk’
Compilation errors and test failures are reported.

31. Life Cycle - Integration
Integration pulls together the individual project units into a full system.
With good Specifications and Design this process is smooth.
Poor Specifications and Design should be detected early in the project but will definitely be detected here.

32. Life Cycle - System Testing
System testing is similar to Unit testing but encompasses the whole project.

33. Life Cycle - Demonstration
Near the end of most research projects a demonstration is performed for the project sponsor.
Demonstrations also occur during the life of a project.

34. Life Cycle - Report
Research projects require a final project report to be written at the end of the project.
The PI is typically responsible for the final report with input from the students and staff.
Excerpts from student documentation, presentations and research papers created during the project are used in the report.
Research projects also have progress reports at regular intervals.