COSC 4303 Software Engineering

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

2. Organizational Chart Software Engineering Director Dr. Tevis Project Management * Joshua Carl Requirements Management * Stephen WoodMark Smullen SoftwareDesign * Micah ShennumCarl Hannusch Quality Assurance * Daniel RothfusPeter Champlin SoftwareConstruction* Joseph KostrevaPaul AmblerRyan Stallard Configuration Management(Contractor) * = Team Leader

3. (SED) Discuss software needs and project scope with customer (SED) Create preliminary software development plan (SDP)‏ (RM) Do preliminary identification of software requirements (SRS)‏ (RM) Identify and record 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 5)‏ Increment #x

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) (Optional) • 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 Requirements and Testing Table Req. ID Req. Status Requirement Description Qual. Type TestCase Input Data Expected Output Actual Output Passed Test?

11. DOATS • Software Name: Distributed On-time Attendance Tracking System (DOATS) • Create a TCP-based text-based pair of client and server programs. The server reads a text file containing a list of line-oriented, comma delimited student names and passwords from a file, whose file name is submitted by the user. The server then listens for a client who requests the list of student names and passwords, and then reports back each time a student checks in. The client asks for the list of students (and passwords) from the server and then displays the student names in alphabetical order, numbered 1 through n. It then prompts the user for a student number (read as a character string) and a password (read as a character string). After a successful password entry, the client notifies the server that the student has checked in. After three consecutive wrong passwords, the client prompts for a student number. When a special negative number and password are read by a client, it informs the server that attendance checking has ended and then terminates. The server then closes all client connections and displays a list of students who have not checked in. The file of student names and passwords is created with a text editor. • Project Start Date: Monday, Oct. 8, 2012 • Project Delivery Date: on or before Friday, Nov. 9, 2012 • Electronic tools and formats (other than source code construction) • Office 2007/2010 using doc, docx, ppt, pptx, and xls file formats • Programming Languages and Compilers • Sun Java 1.6 compliant (no extensions‏) • Initial Implementation Constraints • Software shall run on a computer running 32-bit/64-bit Windows, Linux, or Mac OS 10.x • Software shall run on a stand-alone wired LAN consisting of a router and a switch. The LAN shall have one computer running the server and one or more other computers, each running the client • 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 shall be submitted by zip file with a readme.txt file enclosed