ITTC Project Life Cycle


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ITTC Project Life Cycle

  1. 1. ITTC Software Projects <ul><li>Life Cycle - Phases of a project </li></ul><ul><ul><li>Research version of cycle </li></ul></ul><ul><ul><li>Deliverable Product version of cycle </li></ul></ul><ul><li>Best Practices - Guidelines for executing project phases </li></ul>
  2. 2. ITTC Project Life Cycle/Research Funding Best Practices Specifications Design Unit Implement Proposal Requirements Unit Testing Integration System Testing Demonstration Report Third Party SW
  3. 3. ITTC Project Life Cycle/ Delivery Funding Best Practices Specifications Design Unit Implement Proposal Requirements Unit Testing Integration System Testing User Docs Packaging Delivery Maintenance End of Life Acceptance
  4. 4. Life Cycle - Proposal <ul><li>How is a project initiated? </li></ul><ul><ul><li>Response to a Request For Proposal (RFP) </li></ul></ul><ul><ul><ul><li>Request from Govt. for research in a specified field of interest </li></ul></ul></ul><ul><ul><ul><li>Solicitation of Private Sector Companies to sponsor a project. </li></ul></ul></ul><ul><ul><li>Follow on work from earlier project </li></ul></ul>
  5. 5. Life Cycle - Funding <ul><li>Receive money from sponsoring entity. </li></ul><ul><ul><li>Government - DARPA, NSF, etc. </li></ul></ul><ul><ul><li>Private Sector - Sprint, etc. </li></ul></ul>
  6. 6. Life Cycle - Best Practices <ul><li>Best Practices are guidelines for executing the remainder of the project phases </li></ul><ul><li>Best Practices are determined by Principle Investigator (PI) and staff for each project. </li></ul><ul><li>Best Practices are derived from ITTC Best Practices template. </li></ul><ul><li>Delivery of Best Practices are via WWW pages. </li></ul>
  7. 7. ITTC Best Practices <ul><li>Key driver for Best Practices usage is knowledge capture. </li></ul><ul><ul><li>Knowledge capture occurs with documentation. </li></ul></ul><ul><ul><li>Knowledge capture is critical with a high personel turnover rate </li></ul></ul><ul><ul><ul><li>Project life times can range from 1 to 4 or more years. </li></ul></ul></ul><ul><ul><ul><li>Student duration at ITTC averages 1.5 years. </li></ul></ul></ul><ul><ul><li>SW reuse is facilitated through documentation </li></ul></ul><ul><ul><ul><li>Software is frequently shared between projects. </li></ul></ul></ul><ul><ul><li>Best Practices can answer many common new hire SW development questions. </li></ul></ul>
  8. 8. ITTC Best Practices (cont) <ul><li>Best Practices provide a mechanism for structured/organized software development </li></ul><ul><ul><li>Defined directory structure </li></ul></ul><ul><ul><ul><li>Developers know where to put files </li></ul></ul></ul><ul><ul><li>Source code Version Control System </li></ul></ul><ul><ul><ul><li>Revision histories are automatic </li></ul></ul></ul><ul><ul><ul><li>Specific versions of the project are easily captured/retrieved </li></ul></ul></ul><ul><ul><li>Source code templates </li></ul></ul><ul><ul><ul><li>Source code structure is consistent through the project </li></ul></ul></ul><ul><ul><li>Naming conventions </li></ul></ul><ul><ul><ul><li>File/Directory </li></ul></ul></ul><ul><ul><ul><li>Document Names </li></ul></ul></ul><ul><ul><ul><li>Source code Identifier Names </li></ul></ul></ul>
  9. 9. Document Relationships <ul><li>Requirements - describes environment outside the software (SW). </li></ul><ul><li>Specifications - Describe the interface between the environment and the software. </li></ul><ul><li>Design - describes the internal design of the software. </li></ul>
  10. 10. Document Relationships (cont) Environment Software Requirements Specifications Design Interface Actors Information
  11. 11. General Document Best Practices <ul><li>Use Microsoft Word to generate document. </li></ul><ul><li>Use Microsoft Powerpoint to generate pictures and presentation slides. </li></ul><ul><li>Use present tense sentences. </li></ul><ul><li>Omit the words ‘I’, ‘we’, and ‘you’ in sentences. </li></ul><ul><li>Use ‘shall’ for items that must be executed. </li></ul><ul><li>Use ‘should’ for items that are goals. </li></ul>
  12. 12. Life Cycle - Requirements Docs <ul><li>Requirements describe the environment the SW exists in and WHAT the SW must do. </li></ul><ul><li>Requirements are typically the first documents created for a project. </li></ul><ul><ul><li>The environment is known. </li></ul></ul><ul><ul><li>The software behavior is known. </li></ul></ul><ul><ul><ul><li>In a research setting requirements for two or more sets of behaviors may be written </li></ul></ul></ul><ul><ul><ul><li>There are two or more project threads. </li></ul></ul></ul><ul><ul><li>The specifics of the interfaces are unknown. </li></ul></ul><ul><ul><li>The design is unknown. </li></ul></ul>
  13. 13. Requirements Docs (cont) <ul><li>Requirements capture the intent of a project for future team members. </li></ul><ul><li>Requirements consist of the following: </li></ul><ul><ul><li>Environment actor characteristics </li></ul></ul><ul><ul><ul><li>People </li></ul></ul></ul><ul><ul><ul><li>Computers and hardware </li></ul></ul></ul><ul><ul><ul><li>External Software </li></ul></ul></ul><ul><ul><li>Description of data passed between the actors and the SW and under what circumstances </li></ul></ul><ul><ul><li>What the SW must do with the data or what the data does to the software </li></ul></ul><ul><ul><li>Restrictions and necessary performance of Actors, Data and SW </li></ul></ul>
  14. 14. Requirements Docs (cont) <ul><li>On most projects a hierarchy of requirements are created. </li></ul><ul><li>There are two routes to creating the requirements hierarchy </li></ul><ul><ul><li>Make sub requirements documents that expand on general higher level requirements. This can be recursive. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  15. 15. Requirements Docs Best Practices <ul><li>Each Requirement doc must have the following: </li></ul><ul><ul><li>Title page </li></ul></ul><ul><ul><ul><li>Project name </li></ul></ul></ul><ul><ul><ul><li>Document version </li></ul></ul></ul><ul><ul><ul><li>Author’s name </li></ul></ul></ul><ul><ul><li>ITTC Copyright Page </li></ul></ul><ul><ul><li>Introduction Section </li></ul></ul><ul><ul><ul><li>Describe what the document contains. </li></ul></ul></ul><ul><ul><li>Requirements Section </li></ul></ul><ul><ul><ul><li>Describe Environment Actors </li></ul></ul></ul><ul><ul><ul><li>Describe data passed between Environment and SW </li></ul></ul></ul><ul><ul><ul><li>List of what SW is required to do to interact with environment. </li></ul></ul></ul>
  16. 16. Requirements Docs Best Practices <ul><ul><ul><li>Each requirement must have a unique ID within the document. </li></ul></ul></ul><ul><ul><ul><li>Requirement Ids must not be changed or reused. </li></ul></ul></ul><ul><ul><ul><ul><li>Requirement Ids are referenced in other requirement, specification and design documents and possible in source code. </li></ul></ul></ul></ul><ul><ul><ul><li>If the requirement expands on a higher level requirement the higher level requirement must be references by Requirement Document name and Requirement ID. </li></ul></ul></ul><ul><ul><li>Deprecated Requirements Section </li></ul></ul><ul><ul><ul><li>Requirements that are no longer used are moved to this section for historical purposes. </li></ul></ul></ul><ul><ul><li>Revision History </li></ul></ul><ul><ul><ul><li>List who changed the document, when and why and what the version number was. </li></ul></ul></ul>
  17. 17. Life Cycle - Specification <ul><li>Interface Specification is the description of IO interfaces between the environment and SW. </li></ul><ul><li>Specification Documents typically are created following the creation of Requirements Documents. </li></ul><ul><ul><li>Requirements documents list the interfaces that are required </li></ul></ul><ul><ul><li>Specification documents describe the details of the interfaces. </li></ul></ul><ul><ul><li>Typically there is a Specification document written for each Requirement Document at the lowest level in the requirements hierarchy. </li></ul></ul>
  18. 18. Specification Docs <ul><li>Specifications are a mechanism for unambiguous communication of interface information between project team members. </li></ul><ul><li>Specifications preserve interface knowledge for future team members. </li></ul>
  19. 19. Specifications Doc Best Practices <ul><li>Specifications Documents must contain the following: </li></ul><ul><ul><li>Title page - Same as Requirements </li></ul></ul><ul><ul><li>ITTC Copyright Page - Same as Requirements doc </li></ul></ul><ul><ul><li>Introduction Section - Same as Requirements doc </li></ul></ul><ul><ul><li>Specifications Section </li></ul></ul><ul><ul><ul><li>User Interface </li></ul></ul></ul><ul><ul><ul><ul><li>Application command line arguments </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Graphical windows and menus </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Other hardware interface devices (finger print scanners) </li></ul></ul></ul></ul><ul><ul><ul><li>File formats </li></ul></ul></ul><ul><ul><ul><li>Communication protocols </li></ul></ul></ul>
  20. 20. Specification Docs Best Practices <ul><ul><ul><li>Application Program Interface (API)s </li></ul></ul></ul><ul><ul><ul><ul><li>Function Interfaces </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Object classes </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Data structures </li></ul></ul></ul></ul><ul><ul><ul><li>Each specification must have a unique ID within the document. </li></ul></ul></ul><ul><ul><ul><li>Specification Ids must not be changed or reused. </li></ul></ul></ul><ul><ul><ul><li>Specification Ids are referenced in other specification and design documents and in source code. </li></ul></ul></ul><ul><ul><ul><li>Requirement(s) that the specification satisfies must be referenced using the Requirement Document name and Requirement ID. </li></ul></ul></ul><ul><ul><li>Deprecated Specifications Section - Same as Requirements doc </li></ul></ul><ul><ul><li>Revision History Section - Same as Requirements doc </li></ul></ul>
  21. 21. Life Cycle - Design <ul><li>Design is HOW the SW meets the Requirements and uses the Specifications </li></ul><ul><li>Design documents are written after the Requirements and Specifications are written and before implementation. </li></ul><ul><li>The design process detects problems with Requirements and Specifications before implementation. </li></ul><ul><li>Well designed software greatly reduces time required for implementation. </li></ul>
  22. 22. Design Docs (cont) <ul><li>The Design document captures the information needed by future team members to debug or modify the software. </li></ul><ul><li>Design documents with typically be developed in a hierarchy. </li></ul><ul><ul><li>A System Level Design document is typically the first design document created. </li></ul></ul><ul><ul><ul><li>The system level design document divides the project into well defined sub projects. example: user interface, database </li></ul></ul></ul><ul><ul><li>Design Documents are created for each sub project. </li></ul></ul><ul><ul><ul><li>The design is iteratively subdivided until a level is reached where implementation is straight forward. </li></ul></ul></ul>
  23. 23. Design Docs Best Practices <ul><li>A Design Documents consists of the following: </li></ul><ul><ul><li>Title page - Same as Requirements </li></ul></ul><ul><ul><li>ITTC Copyright Page - Same as Requirements doc </li></ul></ul><ul><ul><li>Introduction Section - Same as Requirements doc </li></ul></ul><ul><ul><li>Design Section </li></ul></ul><ul><ul><ul><li>The design provides enough flexibility that during implementation the design does not have to be rewritten when small changes are made in the implementation. </li></ul></ul></ul><ul><ul><ul><li>Programming Language is determined </li></ul></ul></ul><ul><ul><ul><li>Functional divisions of software and their relationships are described. </li></ul></ul></ul>
  24. 24. Design Docs Best Practices (cont) <ul><ul><ul><li>Design description mechanism to use include: </li></ul></ul></ul><ul><ul><ul><ul><li>Control Flow Diagram </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Thread relationships </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Data Flow Diagram </li></ul></ul></ul></ul><ul><ul><ul><ul><li>State Transition Diagrams </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Object/Class Relationship Diagram </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Internal APIs </li></ul></ul></ul></ul><ul><ul><ul><li>Unit test design for functional level designs </li></ul></ul></ul><ul><ul><ul><ul><li>Unit level testability must be designed into the software. </li></ul></ul></ul></ul><ul><ul><li>Revision History </li></ul></ul><ul><li>Each design must pass a design review before implementation begins. </li></ul>
  25. 25. Life Cycle - Implementation <ul><li>Implementation consists of coding the design </li></ul><ul><ul><li>Creating directory structures </li></ul></ul><ul><ul><li>Setting up a build mechanism </li></ul></ul><ul><ul><li>Coding </li></ul></ul><ul><ul><ul><li>Language sensitive editors </li></ul></ul></ul><ul><ul><ul><li>Internal Documentation </li></ul></ul></ul><ul><ul><ul><li>Coding for testing </li></ul></ul></ul><ul><ul><li>Using a Version Control System </li></ul></ul>
  26. 26. Implementation Best Practices <ul><li>All source files must contain the following: </li></ul><ul><ul><li>ITTC Copyright - ALL RIGHTS RESERVED </li></ul></ul><ul><ul><li>Header </li></ul></ul><ul><ul><ul><li>Synopsis -one sentence about the file contents </li></ul></ul></ul><ul><ul><ul><li>Usage ( form ‘main’ files, Makefile’s and scripts) </li></ul></ul></ul><ul><ul><ul><li>Author and Date info </li></ul></ul></ul><ul><ul><li>Internal documentation </li></ul></ul><ul><ul><ul><li>Source files must be understandable by future project members </li></ul></ul></ul><ul><ul><ul><li>Correct, Clear, Complete </li></ul></ul></ul><ul><ul><ul><ul><li>Wrong documentation is worse than no documentation </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Programmers unfamiliar with the code will have to work on it </li></ul></ul></ul></ul>
  27. 27. Implementation Best Practices <ul><ul><ul><li>Interface Descriptions </li></ul></ul></ul><ul><ul><ul><li>Algorithm Description (not pseudo code) </li></ul></ul></ul><ul><ul><ul><li>Use language constructs for code clarity </li></ul></ul></ul><ul><ul><ul><ul><li>Identifiers should be full nouns/verbs or STANDARD abbreviations </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Use spaces around operators (= , ! < ) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Indent execution control statements (if, for, switch) </li></ul></ul></ul></ul><ul><ul><li>One API function or class per source file </li></ul></ul><ul><ul><ul><li>Use multiple local functions in a file. </li></ul></ul></ul><ul><ul><li>Short functions - less than 100 lines </li></ul></ul><ul><ul><li>Make a new function when tempted to copy and paste code. </li></ul></ul>
  28. 28. Implementation Best Practices <ul><li>Unit testing mechanisms must be incorporated </li></ul><ul><ul><li>Debugging output </li></ul></ul><ul><ul><li>Test scripts/programs </li></ul></ul><ul><li>Source Templates are used to assist in following the Best Practices </li></ul><ul><li>All code must pass a code review. </li></ul><ul><li>Development must occur on a VCS branch. </li></ul><ul><li>Code may only be merged to the ‘trunk’ when it passes unit tests. </li></ul>
  29. 29. Life Cycle - Unit Testing <ul><li>Unit testing consists of executing code from a project unit and comparing the output to a GOLD output. </li></ul><ul><ul><li>GOLD output is correct output for the unit. </li></ul></ul><ul><li>Unit testing detects unexpected ‘bugs’ when an implementation changes. </li></ul><ul><ul><li>A coder may not anticipate the total impact of an implementation change. </li></ul></ul><ul><li>Unit testing may detect untested implementation changes before use by others on a project. </li></ul>
  30. 30. Unit Testing Best Practice <ul><li>The unit implementor is responsible for creation of the GOLD output. </li></ul><ul><li>Automated Unit Tests are performed at a regular interval (daily, weekly) </li></ul><ul><ul><li>Complete compilation </li></ul></ul><ul><ul><li>Unit output comparison with GOLD output. </li></ul></ul><ul><li>Automated Unit Tests are performed on a Version Control System ‘trunk’ </li></ul><ul><li>Compilation errors and test failures are reported. </li></ul>
  31. 31. Life Cycle - Integration <ul><li>Integration pulls together the individual project units into a full system. </li></ul><ul><li>With good Specifications and Design this process is smooth. </li></ul><ul><ul><li>Poor Specifications and Design should be detected early in the project but will definitely be detected here. </li></ul></ul>
  32. 32. Life Cycle - System Testing <ul><li>System testing is similar to Unit testing but encompasses the whole project. </li></ul>
  33. 33. Life Cycle - Demonstration <ul><li>Near the end of most research projects a demonstration is performed for the project sponsor. </li></ul><ul><li>Demonstrations also occur during the life of a project. </li></ul>
  34. 34. Life Cycle - Report <ul><li>Research projects require a final project report to be written at the end of the project. </li></ul><ul><ul><li>The PI is typically responsible for the final report with input from the students and staff. </li></ul></ul><ul><ul><li>Excerpts from student documentation, presentations and research papers created during the project are used in the report. </li></ul></ul><ul><li>Research projects also have progress reports at regular intervals. </li></ul>