Process: Difference between revisions

From Thunderforce
Jump to navigation Jump to search
No edit summary
m (Protected "Process" [edit=sysop:move=sysop])
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Obsolete}}
Thunderforce's development process is loosely based on [http://reports-archive.adm.cs.cmu.edu/anon/isri2005/CMU-ISRI-05-103.pdf Anthony Lattanze's Architecture-Centric Development Methodology (ACDM)], which is popular process framework in the Master of Software Engineering (MSE) program at Carnegie Mellon University and elsewhere. For the development phase, a design-oriented process that refines the architectural modules into detailed design and then code will be used.
Thunderforce's development process is loosely based on [http://reports-archive.adm.cs.cmu.edu/anon/isri2005/CMU-ISRI-05-103.pdf Anthony Lattanze's Architecture-Centric Development Methodology (ACDM)], which is popular process framework in the Master of Software Engineering (MSE) program at Carnegie Mellon University and elsewhere. For the development phase, a design-oriented process that refines the architectural modules into detailed design and then code will be used.
#[[Requirements elicitation]]
#[[Requirements elicitation]]
Line 10: Line 12:
#[[Module identification and assignment]]
#[[Module identification and assignment]]
#[[Integration test creation]]
#[[Integration test creation]]
#Detailed module designs
#[[Detailed module designs]]
#Module unit tests
#[[Module unit tests]]
#Module code
#[[Module code]]
#Integration tests passing
#Integration tests passing
#Releases
#Releases

Latest revision as of 21:40, 22 November 2008

Note: This page is obsolete. Please go to the home page.

Thunderforce's development process is loosely based on Anthony Lattanze's Architecture-Centric Development Methodology (ACDM), which is popular process framework in the Master of Software Engineering (MSE) program at Carnegie Mellon University and elsewhere. For the development phase, a design-oriented process that refines the architectural modules into detailed design and then code will be used.

  1. Requirements elicitation
  2. Quality attributes
  3. Requirements prioritization and project scope
  4. High-level project planning
  5. Use cases
  6. Notional architecture
  7. Experiments
  8. Architectural review and refinement
  9. Module identification and assignment
  10. Integration test creation
  11. Detailed module designs
  12. Module unit tests
  13. Module code
  14. Integration tests passing
  15. Releases