COSC 4303 Software Engineering Introduction and Initial Planning of Group Project Fall 2009 (Updated on 24 Oct 2009)

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Software change management
Configuration management
Configuration Management
Software Quality Assurance Plan
Configuration Management
MODELING THE TESTING PROCESS Formal Testing (1.0) Requirements Software Design Risk Data Approved, Debugged, Eng. Tested Code Automated Test Tools Tested.
Software Quality Assurance Plan
Jay-Evan J. Tevis Department of Computer Science LeTourneau University Longview, TX
Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
© ABB AB, Corporate Research - 1 5/19/2015 abb Project Breakdown Structure Creation.
Project Change Management
1 RUP Workshop By George Merguerian Senior Partner Business Management Consultants
APPLICATION DEVELOPMENT BY SYED ADNAN ALI.
Software Configuration Management (SCM)
Project Management Session 7
Configuration Management
Chapter 27 Change Management
Software Configuration Management
CSSE 375 Software Construction and Evolution: Configuration Management
Configuration Management Avoiding Costly Confusion mostly stolen from Chapter 27 of Pressman.
1 Introduction to Web Development. Web Basics The Web consists of computers on the Internet connected to each other in a specific way Used in all levels.
This chapter is extracted from Sommerville’s slides. Text book chapter
Effective Methods for Software and Systems Integration
Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
CSI315 Web Applications and Technology Overview of Systems Development (342)
Software Configuration Management
Software System Engineering: A tutorial
COSC 4303 Software Engineering GROUP PROJECT Introduction and Initial Planning Fall 2012.
1 Configuration Management “The Cookbook Approach”
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
COSC 4303 Software Engineering GROUP PROJECT Introduction and Initial Planning Fall 2010.
Configuration Management (CM)
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
1 3. Computing System Fundamentals 3.1 Language Translators.
Refined ECSS Software Process Model Elements SD-TN-AI-0570, Issue 5 APPENDIX D.
Software Quality Assurance
Apply Project Scope Management Techniques Project Scope Processes – Part 2 Certificate IV in Project Management Qualification Code BSB41507 Unit.
© Mahindra Satyam 2009 Configuration Management QMS Training.
KS3 Phase4 Client Server Monitoring System October 1, 2008 by Stephen, Seema, Kam, Shpetim.
SOFTWARE CONFIGURATION MANAGEMENT. Change is inevitable when computer software is built. And change increases the level of confusion among software engineers.
MSE Presentation 1 By Padmaja Havaldar- Graduate Student Under the guidance of Dr. Daniel Andresen – Major Advisor Dr. Scott Deloach-Committee Member Dr.
Develop Project Charter
DPE CSSW Process Model Annex A WP-400 ECSS Case Study.
COSC 4303 Software Engineering Introduction and Initial Planning of Group Projects Fall 2007.
Quick Recap Monitoring and Controlling. Lesson 11: Monitoring and Controlling Project Work Topic 11A: Identify the Monitor and Control Project Work Process.
Software Engineering Lecture # 1.
 Programming - the process of creating computer programs.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
Unit 17: SDLC. Systems Development Life Cycle Five Major Phases Plus Documentation throughout Plus Evaluation…
Timesheet training Version: Introduction Duration: 1.5 hours Purpose: Guide on how to use Timesheet.
CS223: Software Engineering
Apply Project Scope Management Techniques Project Scope Processes – Part 2 Week 4 Certificate IV in Project Management Qualification Code BSB41507.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Software Engineering Lecture 9: Configuration Management.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 2 Diploma of Project Management.
6/6/ SOFTWARE LIFE CYCLE OVERVIEW Professor Ron Kenett Tel Aviv University School of Engineering.
NAVSEA Liaison Scott Huseth Faculty Advisor Dr. Jiang Guo Team Members Areg Abcarians David Ballardo Niteen Borge Daniel Flores Constance Jiang June 3,
Software Reviews Ashima Wadhwa.
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Software Configuration Management
Software Configuration Management
Software Project Configuration Management
Chapter 11: Software Configuration Management
Configuration Management Why do we need it? What does it do?
Lecture 3 Change Management
Software Configuration Management
Gestion de la documentation pendant le cycle de développement
Chapter 11: Software Configuration Management
Configuration management
Presentation transcript:

COSC 4303 Software Engineering Introduction and Initial Planning of Group Project Fall 2009 (Updated on 24 Oct 2009)

Organizational Structure Software Engineering Directorate Dr. Tevis Software Design * Caleb Reinking Peter Moore Daniel Patten Gary Raduns Customer Liaison * Stephen Brown Joshua Millet Quality Assurance * Kim White Silas Brill Brett Clark Austin Eyler Daniel Ferguson Michael Roettger Requirements Management * Spenser James Aaron Cutbirth Josh Haines Jon Hersack Aaron Hume Erik Lindow Project Management Elijah Lofgren Configuration Management (Contractor) C++ Software Construction * Robert Whiting Ben Cooley James Denton Brett Smith Java Software Construction * Benaiah Henry Evan Allrich Dave Estes Bill Tuscher

(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 4)‏ (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)‏

Organizational Responsibilities (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

Organizational Responsibilities (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

Organizational Responsibilities (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

Organizational Responsibilities (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

Organizational Responsibilities (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

Organizational Responsibilities (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

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

Clickermatic Software Clicker Software Requirements Summary –Create a TCP-based GUI-based client/server computer program in which the server displays a series of questions and multi-choice answers on its screen, the client anonymously gathers student responses to each question via an on-screen software clicker on its screen, and the server tabulates the answers and displays the results on its screen. All questions and answers are read from a formatted text file. The questions shall be presented either one at a time (single mode) or in a group (quiz mode) Project Start Date: Monday, Sep. 28, 2009 Project Delivery Date: on or before Friday, Nov. 6, 2009 Electronic tools and formats (other than source code construction) –Office 2003/2007 with Office 2003 doc, ppt, and xls file formats Programming Languages and Compilers –GNU C++ (Object-oriented, OpenGL GUI, no extensions) –Sun Java (Object-oriented, SWING GUI, no extensions‏) Implementation Constraints –Targeted for desktop, laptop, or netbook computers running 32-bit Windows, Linux, or Mac OS –No source code dependency on any specific platform or operating system –No dependency on any integrated development environment (IDE) for coding, testing, or software execution –No dependency on language matches between client and server (i.e., only a common application layer protocol for each implementation) –Source code submission to Project Management by zip file with a readme.txt file enclosed