COSC 4303 Software Engineering

1. GROUP PROJECT Introduction and Initial Planning Fall 2010 COSC 4303Software Engineering

2. Organizational Chart CustomerLiaison * David Howard Software Engineering Directorate Dr. Tevis Project Management * Uli De La Fuente Requirements Management * Drew CrawfordAndy AloiaArlan Hooley SoftwareDesign * Jason HoytNicholas CapoBion Oren Quality Assurance * Nathan McGarveyAdam MagstadtCody Riggenbach SoftwareConstruction* Joseph WallaceJoshua HillmannJoe PalermoChris Stillwell Configuration Management(Contractor)

3. (SED) Discuss software needs and project scope with customer (SED) Create preliminary software development plan (SDP)‏ (RM) Identify and record software requirements (SRS)‏ (RM) Do preliminary identification of software requirements (SRS)‏ Software Requirements Review (SRR)‏ (SED) Update software development plan (SDP)‏ (RM) Create OORA model (SRS)‏ (RM) Create interface requirements specification (IRS)‏ (SD) Create architectural design model (SDD)‏ Preliminary Design Review (PDR)‏ (QA) Create validation and system test cases (STD)‏ (QA) Determine qualification methods for requirements (STP)‏ (SD) Create interface design description (IDD)‏ Test Readiness Review (TRR)‏ (SC) Do product build and integration testing (SC) Construct source code and do unit testing Critical Design Review (CDR)‏ (SD) Create component- level design (SDD)‏ (SC) Create software version description (SVD)‏ (QA) Do validation and system testing Functional and Physical Configuration Audits (FCA/PCA)‏ (CM) Deliver software and documentation Test Outcome Review (TOR)‏ Note: If formal approval does not occur following a review or audit, this will require an implied return to the previous non-review step in the process Task Network for the Organizational Software Development Process (Version 4)‏

4. Organizational Roles, Process, andProcedures (1 of 6)‏ • Software Engineering Director • Provide oversight for all of the company’s software engineering projects • Serve with the director of the customer organization as the review and project approval authority • Act as the baselining authority (along with the director of the customer organization) for all project documents and software • Plan and oversee the formal reviews (SRR, PDR, CDR, TRR, TOR, FCA/PCA) and product delivery • Project Management (PM)‏ • Based on the task network, the organizational responsibilities, and the project objectives, construct an initial timeline chart for the project • Maintain the timeline chart over the life of the project by getting subtask information from the team leaders and updating the status of all tasks as information becomes available • Submit updated timeline charts to the Software Engineering Director before each directorate meeting and as requested • Use the timeline chart to brief the current status of the project at each directorate meeting • Report any project abnormalities, problems or delays to the Software Engineering Director • Collect artifacts after each formal review from Requirements Management, Software Design, Software Construction, and Quality Assurance that need to be baselined • Submit these artifacts to Configuration Management for baselining

5. Organizational Roles, Process, andProcedures (2 of 6)‏ • Configuration Management (CM)‏ • Provide configuration management services for all artifacts that are submitted for baselining • Receive artifacts for baselining from Project Management only • Make baselined artifacts available through a project website • Deliver the baselined finished software and documentation to the Customer Organization • Customer Liaison (CL) • Work for the head of the Customer Organization • Act as an information conduit between the director of the Customer Organization and all offices in the Software Engineering Directorate • Serve as the customer representative at all directorate meetings • Tentatively approve any decisions made concerning product requirements • Periodically brief the head of the Customer Organization on project status • Point out any unapproved additions, changes, or deletions to product requirements that occur in any phase of the software development • Assist the head of the Customer Organization at all reviews and audits • Accept delivery of the baselined finished software and documentation for the Customer Organizaton

6. Organizational Roles, Process, andProcedures (3 of 6)‏ • Requirements Management (RM)‏ • Submit subtask information to Project Management for any work assigned to RM • Gather the initial product software requirements • Create the initial master software requirements and testing table • Record the initial requirements in the master software requirements and testing table • Maintain the integrity of the master requirements and testing table through SRR by tracking any additions, changes, and deletions to the requirements • Based on the software requirements, create an interface requirements specification • Based on the software requirements and interface requirements, create the initial OORA Model (use-case diagram, class diagram, and a top-level state diagram)‏ • Present the master requirements and testing table, the interface requirements specification, and the initial OORA model at the Software Requirements Review (SRR)‏ • After the SRR, submit the master requirements and testing table, the interface requirements specification, and the OORA model to Project Management for baselining • Assist Quality Assurance in the validation and system testing of the software • Point out any unapproved additions, changes, or deletions to product requirements that occur in the design, construction, or testing phases of software development

7. Organizational Roles, Process, andProcedures (4 of 6)‏ • Software Design (SD)‏ • Submit subtask information to Project Management for any work assigned to SD • Based on the requirements listed in the baselined master requirements and testing table, transform the baselined OORA model into an OO architectural design model (i.e., a class diagram) • Present this model at the Preliminary Design Review (PDR)‏ • After the PDR, submit the architectural design model to Project Management for baselining • Based on the master requirements and testing table, expand the baselined architectural design model into a component-level design model • Expand the baselined interface requirements specification into an interface design description • Present these models and descriptions at the Critical Design Review (CDR)‏ • After the CDR, submit the interface design description and the component-level design model to Project Management for baselining

8. Organizational Roles, Process, andProcedures (5 of 6)‏ • Software Construction (SC)‏ • Submit subtask information to Project Management for any work assigned to SC • Based on the master requirements and testing table, translate the baselined design models and the interface design description into source code and perform unit testing • Perform a product build and do software integration testing • Present the source code and your unit and integration testing results at the Test Readiness Review (TRR)‏ • After the TRR, submit the source code to Project Management for baselining • Provide assistance to QA during validation and system testing of the software • Based on the test results, make any practical changes to the software to create a corrected version for retesting by QA • Present the corrected source code at the Test Outcome Review (TOR)‏ • After the TOR, submit the corrected source code to Project Management for baselining • Create a software version description (SVD) • Create a final class diagram that reflects the actual software implementation • Present your SVD and class diagram at the Functional/Physical Configuration Audit (FCA/PCA)‏ • After the FCA/PCA, submit your SVD and class diagram to Project Management for baselining

9. Organizational Roles, Process, andProcedures (6 of 6)‏ • Quality Assurance (QA)‏ • Submit subtask information to Project Management for any work assigned to QA • After SRR, obtain the baselined master requirements and testing (R&T) table from Configuration Management • Take over the responsibility to maintain the master R&T table and the interface requirements specification • Submit the R&T table to Project Management for baselining at various times as requested by the Software Director • Determine the qualification method for each requirement listed in the master R&T table • Based on the qualification method, create a validation or system test case (along with input data and expected output data, if applicable) for each requirement listed in the master R&T table; record these in the table • Present the validation and system test cases, as recorded in the master R&T table, at the Test Readiness Review (TRR)‏ • After TRR, submit the updated master R&T table (with test cases) to Project Management for baselining • Before validation and system testing begins, obtain the baselined source code from Configuration Management • With the assistance of Requirements Management, Software Design, and Software Construction, perform validation and system testing of the software requirements and record all results in the master R&T table • When errors are found during testing, have Software Construction make any practical changes to the software (if possible) in order to create a corrected version, then retest this version • Present the validation and system test results, as recorded in the master R&T table, at the Test Outcome Review (TOR)‏ • After the TOR, submit the updated master R&T table (with test results) to Project Management for baselining

10. Format for the Software Requirements and Testing Table Req. ID Status Requirement Description Qual. Type TestCase Input Data Expected Output Actual Output Passed Test?

11. Monopoly Metrics Tracking Software (MMTS) • Software Requirements Summary • Create a text-based program in Java that plays the board game of monopoly using only computer-generated players. No graphical display of any type shall be generated. All input to the program shall come from the command line and from specified input files only. All output shall be sent to standard out (for report data) and standard error (for program trace). The program shall follow the rules of Monopoly as supplied and modified by the customer. During game play, the program shall gather metrics about the game as requested by the customer, and provide those metrics in a summary report when the game ends. • Project Start Date: October 1, 2010 • Project Delivery Date: on or before Friday, Nov. 5, 2010 • Electronic tools and formats (other than source code construction) • Office 2007 with Office 2003 doc, ppt, and xls file formats • Programming Language and Compiler • .Java (no extensions‏) • Implementation Constraints • Software will be targeted for a desktop, laptop, or netbook computer running 32-bit Windows, Linux, or Mac OS • No source code dependency shall exist for any specific platform or operating system except as stated above • No dependency shall exist on any integrated development environment (IDE) for coding, testing, or software execution (only Java source code files shall be delivered) • The Java source code files will be submitted to Project Management by zip file with a readme.txt file enclosed