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

2. Organizational Chart Software Engineering Director Dr. Tevis Software Design * Micah Shennum Carl Hannusch Quality Assurance * Daniel Rothfus Peter Champlin Requirements Management * Stephen Wood Mark Smullen Project Management * Joshua Carl Configuration Management (Contractor) Software Construction * Joseph Kostreva Paul Ambler Ryan Stallard * = Team Leader

3. (SED) Update software development plan (SDP)‏ (RM) Create OORA model (SRS)‏ Software Requirements Review (SRR)‏ (SD) Create architectural design model (SDD)‏ Preliminary Design Review (PDR)‏ (SD) Create component- level design (SDD)‏ (SC) Construct source code and do unit testing Critical Design Review (CDR)‏ (SC) Do product build and integration testing Test Readiness Review (TRR)‏ (QA) Do validation and system testing (SC) Create software version description (SVD)‏ (QA) Determine qualification methods for requirements (STP)‏ (SD) Create interface design description (IDD)‏ (SED) Create preliminary software development plan (SDP)‏ Task Network for the Organizational Software Development Process (Version 5)‏ (QA) Create validation and system test cases (STD)‏ (RM) Do preliminary identification of software requirements (SRS)‏ (CM) Deliver software and documentation Functional and Physical Configuration Audits (FCA/PCA)‏ 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 (SED) Discuss software needs and project scope with customer Test Outcome Review (TOR)‏ (RM) Create interface requirements specification (IRS)‏ (RM) Identify and record software requirements (SRS)‏ Increment #x

4. Organizational Roles, Process, and Procedures (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, and Procedures (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, and Procedures (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, and Procedures (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, and Procedures (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, and Procedures (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 Passed Test? Actual Output Expected Output Input Data Qual. Type Requirement Description Req. IDTest Case Req. Status

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