Software Quality Assurance Plan



Similar documents
Software Quality Assurance Plan

MSE Presentation 1 MultiAgent Control of Traffic Signals (MACTS)

Project Plan 1.0 Airline Reservation System

Master of Software Engineering Portfolio

Formal Technical Inspection. Using CLIPS to Detect Network Intrusions - (CLIPNIDS)

Project Plan. Online Book Store. Version 1.0. Vamsi Krishna Mummaneni. CIS 895 MSE Project KSU. Major Professor. Dr.Torben Amtoft

What is a life cycle model?

SOFTWARE PROCESS MODELS

Sistemi ICT per il Business Networking

Test Plan Airline Reservation System

Example IEEE software project management plan (SPMP)

Software Engineering. An Introduction. Fakhar Lodhi

MNLARS Project Audit Checklist

Software Quality. Software Quality Assurance and Software Reuse. Three Important Points. Quality Factors

SOFTWARE DEVELOPMENT PLAN

CS 6361, SPRING 2010 Advanced Requirements Engineering Web Based Meeting Scheduler- Project Plan

Overview of STS Consulting s IV&V Methodology

Software Quality Assurance Software Inspections and Reviews

Metrics in Software Test Planning and Test Design Processes

Management. Project. Software. Ashfaque Ahmed. A Process-Driven Approach. CRC Press. Taylor Si Francis Group Boca Raton London New York

Test Plan1.0 For the project A Credit Assessment System (CAS) Version 1.0

<name of project> Software Project Management Plan

Vision Document CUSTOMER RELATION MANAGEMENT SYSTEM Version 1.0

Project Management. Lecture 3. Software Engineering CUGS. Spring 2012 (slides made by David Broman) Kristian Sandahl

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Keywords: SQA,Black Box Testing( BBT), White Box testing(wbt).

Purchasing Contracts Management System

Nova Software Quality Assurance Process

Software Quality Assurance: II Software Life Cycle

How To Understand The Software Process

Supporting Workflow Overview. CSC532 Fall06

A Case study based Software Engineering Education using Open Source Tools

Software Project Management using an Iterative Lifecycle Model

Effort and Cost Allocation in Medium to Large Software Development Projects

Program Lifecycle Methodology Version 1.7

Software Project Models

Product Build. ProPath. Office of Information and Technology

Principles of integrated software development environments. Learning Objectives. Context: Software Process (e.g. USDP or RUP)

Software Development Process

Configuration Management Plan

Surveying and evaluating tools for managing processes for software intensive systems

<Company Name> <Project Name> Software Development Plan. Version <1.0>

Vision Document Airline Reservation System

Quality Management. Lecture 12 Software quality management

AIRLINE RESERVATION SYSTEM KAAVYA KUPPA. Bachelor of Engineering, Jawaharlal Nehru Technological University, India, 2005 A REPORT

An Iterative and Agile Process Model for Teaching Software Engineering

Software Quality Assurance Plan

Java Software Quality Tools and techniques

Software Development Processes. Software Life-Cycle Models

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology

E-vote 2011 Version: 1.0 Testing and Approval Date: 26/10/2009. E-vote SSA-U Appendix 5 Testing and Approval Project: E-vote 2011

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

Oracle Technical Cloud Consulting Services Descriptions. July 23, 2015

Digital Marketplace Services Service Definition

Managing Small Software Projects - An Integrated Guide Based on PMBOK, RUP, and CMMI

Software Life Cycle Processes

How To Write A Contract For Software Quality Assurance

Peer Review Process Description

Software Configuration Management Plan

Software Development Life Cycle (SDLC)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

Software Testing. Knowledge Base. Rajat Kumar Bal. Introduction

Software Process Training

Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

Software Process and Project Plan

Software Engineering Reference Framework

Independent Verification and Validation of SAPHIRE 8 Software Project Plan

Minnesota Health Insurance Exchange (MNHIX)

Time Monitoring Tool Software Development Plan. Version <1.1>

Course Description for Operating Systems Hands-On (S&R Technology Lab)

STS Federal Government Consulting Practice IV&V Offering

Recognition of Prior Learning (RPL) BSB41515 Certificate IV in Project Management Practice

Software Project Plan

Effective and Best practices of load and performance testing Oracle Applications using BSD Oracle plug-in for Rational Performance Tester

IBM Rational Asset Manager

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal

Peer Review Process Description

An Integrated Quality Assurance Framework for Specifying Business Information Systems

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

How To Migrate To Redhat Enterprise Linux 4

Software Engineering Question Bank

Introduction to OpenUP (Open Unified Process)

Contents. 3 Agile Modelling Introduction Modelling Misconceptions 31

Software Quality Testing Course Material

Project QA and Collaboration Plan for <project name>

Collection Inventory Software Project Plan

CSE 435 Software Engineering. Sept 16, 2015

Development Methodologies

Experiences in Developing a Web-based Assessment System

Development models. 1 Introduction. 2 Analyzing development models. R. Kuiper and E.J. Luit

Testing Tools Content (Manual with Selenium) Levels of Testing

Successfully managing geographically distributed development

ITS Projects Systems Engineering Process Compliance Checklist

Karunya University Dept. of Information Technology

2015 IBM Continuous Engineering Open Labs Target to better LEARNING

Transcription:

Applying Broadcasting/Multicasting/Secured Communication to agentmom in Multi-Agent Systems Software Quality Assurance Plan Version 1.1 This document conforms to IEEE Std 730.1-1995 Software Quality Assurance Plan. This document is submitted in partial fulfillment of the requirements for the degree MSE. Chairoj Mekprasertvit CIS 895 MSE Project Kansas State University Spring 2003 1

Table of Contents 1 Purpose... 3 2 Reference... 3 3. Management... 3 4. Documentation... 4 5. Standards, Practices, Conventions and metrics... 5 6. Reviews and audits... 5 7. Problem reporting... 5 8. Tools, Techniques and Methodologies... 5 9. Media control... 6 10. Training... 6 2

1 Purpose The purpose of this document is to specify how the software quality assurance plan will be handled in the software development life-cycle of the project Applying Broadcasting/Multicasting/Secured Communication to agentmom in Multi-Agent Systems. The intended use of this to software project is to enhance the pre-exist agentmom (agentmom 1.2) to be capable of providing multicasting conversation and basic message encryption for security purpose. This document is based on the IEEE standard for Software Quality Assurance Plan, IEEE Std 730.1-1995. This document is intended to be used in partial fulfillment of the requirements for the Master of Software Engineering Project s Portfolio. Furthermore, this document will be reviewed and evaluated by the major professor and the supervisory committee. 2 Reference Project Overview version 1.0, Kansas State University, March 2003, (http://www.cis.ksu.edu/~cme6556/project_overview_1.0.pdf) Project Plan version 1.0, Kansas State University, March 2003, (http://www.cis.ksu.edu/~cme6556/project_plan_1.0.pdf) Software Requirements Specification, Kansas State University, March 2003, (http://www.cis.ksu.edu/~cme6556/software_requirements_specification_1.0.pdf) IEEE Guide for Software Quality Assurance Planning IEEE Standard for Software Quality Assurance Planning, IEEE Std 730.1-1995 Software Project Management: A Unified Framework AgentMom User s Manual, Air Force Institute of Technology, July 2000 Multiagent Systems Engineering. The International Journal of Software Engineering and Knowledge Engineering 3. Management 3.1 Organization Supervisory Committee consisted of: Dr. Scott A. DeLoach Dr. David Gustafson Dr. William Hankley Major Professor: Dr. Scott A. DeLoach Developer: Chairoj Mekprasertvit Formal Technical Inspector consisted of Madhukar Kumar Acharaporn Pattaravanichanon 3.2 Responsibilities 3.2.1 Supervisory Committee Primary responsibilities include reviewing each milestone deliverable at the requirements, architecture, and implementation phases. After reviewing, each committee member should provide feedback and suggestions to the software developer. 3

3.2.2 Major Professor In addition to the responsibilities as one of the committee member, the major professor will supervise and evaluate all artifacts submitted by developer. Reviews and walkthroughs of related materials will be conducted on weekly basis. 3.2.3 Software Developer Since the project is being developed individually, developer is responsible for ensuring quality of the project. The software developer is also responsible for producing the required artifacts for MSE projects. 3.2.4 Formal Technical Inspectors The major responsibility of inspectors is to provide a formal report on their inspection result from architecture design artifact produced by developer. Furthermore, the following tasks will be conducted in order to ensure quality assurance: 1. Driving Requirements: The developer should ensure that the software requirement specification in the vision document clearly states the functionality of software and unambiguously declares the requirements that must be satisfied. In addition, descriptions of the scope should clearly outline what the software will allow and not allow. 2. Design: The developer and major professor will conduct reviews and analyses of the construction of the software. Strengths and weaknesses of various design techniques will be discussed and scrutinized. 3. Implementation: Informal code reviews will be conducted by the developer on a regular basis to ensure consistency with the design and the detection of any error. Also, JavaDoc will be produced for purpose of maintainability and future work. 4. Testing: Developer will conduct tests as presented in the Software Test Plan to ensure the requirement satisfaction and reliability of the software. 4. Documentation The following documentation will be generated and updated throughout the duration of software life cycles: Phase I: 1.) Vision Document - provides detailed description of the entire project, goals of the software, constraints and requirements for the software to satisfy. 2.) Project Plan - illustrates the major milestones and provides a rough timeline for the project and estimation on the size and effort of the project. 3.) Software Quality Assurance Plan provides plan for software quality assurance Phase II: 1.) Formal Requirement Specification UML/OCL methodology will be used to produce this document. 2.) Test Plan - provides description of test cases during testing 3.) Architecture Design Object Model and Use Cases will be produced. 4.) Formal Technical Inspection - two MSE students will participate in formal technical inspection, and developer will also provide an inspection checklist. Phase III: 1.) User Manual - instructions on how to use software 4

2.) Final source code - actual implemented documented source code 3.) Assessment Evaluation - assessment of reliability and performance of software 4.) Project Evaluation - review of the entire project 5. Standards, Practices, Conventions and metrics 5.1 Standards Documents MSE portfolio requirements, CIS Dept., Kansas State University Coding Java 1.4.0 (commenting will follow JavaDoc standards) Testing IEEE Standard for Software Test Documentation 5.2 Metrics SLOC source lines of code will be primarily used for measuring the size of the software COCOMO I cost estimation will be calculated based on COCOMO I model. 6. Reviews and audits Two formal MSE students will perform a formal technical inspection on the architecture design document and provide a formal report. Also, each committee member will review the produced documentation and make comments and suggestions during each presentation. Each milestone must be approved by each committee member to proceed to the next milestone. Each milestone is indicated by the presentation of each phase. There are three presentation described as follow: Presentation I at the end of phase I includes project overview, software requirements, project plan, SQA plan and prototype demonstration. Presentation II at the end of phase II includes formal requirement specification, architecture design, test plan and architecture prototype demonstration. Presentation III at the end of phase III includes component design, assessment evaluation, project evaluation, result from formal technical inspection and completed software demonstration. 7. Problem reporting If any problems are encountered throughout the duration of the project, the software developer can report and discuss the problems with the major professor. If any conflicts or problems are discovered by one of the committee members during a presentation, the developer will then correct the errors. 8. Tools, Techniques and Methodologies For determining whether the software requirements were satisfied, a software test plan will be written during phase II. This plan will provide an overview of the methodologies, timetables, and resources for testing the software. Testing will commence in three primary ways: 8.1 Unit Testing Individual classes will be tested to ensure reliability and functionality within a unitlevel. Furthermore, testing module will be created before the tested code to ensure that 5

the code is testable. Junit 3.8 will be the tool to perform testing. Unit testing will be performed before alpha and beta release. 8.2 Integration Testing Several classes will be tested together to ensure sufficient execution and compliance with the requirements after integration. Integration testing will be performed before beta release. 8.3 System Testing The whole system shall be used for system testing to ensure all requirements is satisfied, and reliability will be included in the testing to measure successful rate of message delivery. System testing will be performed before beta release. The following tools are used in creating, testing and debugging software Java 1.4.0 will be the language used for coding the software. USE 2.0 will be used for modeling the formal specifications, using UML/OCL methodology Rational Rose will primarily be used for producing object models. Eclipse IDE 2.1 will be used for coding the software package. Jakarta Ant 1.5 will be used for building project s source code. JUnit 3.8 will be used to perform unit test and generate test cases. log4j 1.2 will be used to output log statement and help debugging This software package will be tested under Microsoft Windows XP/2000, Linux Red Hat 8.0 and Unix Solaris 2.7. 9. Media control All the required documentation generated throughout the course of the project is available at the software developer s personal website (http://www.cis.ksu.edu/~cme6556). Upon project completion, a CD containing all the project document, prototype, and final product is created. 10. Document and Software Version Control Each document version or software version is incremented by 0.1 after it is approved by major professor. Also, version is move to the next digit after it is approved by all committee members. For example, version 1.2 will be changed to version 2.0 after all committee approval or version 1.2 to 1.3 after major professor approval. Alpha version is released after the software is passed all unit tests. Beta version is released after the software is passed all unit tests, integration tests and system tests. Final version is released after the software is approved by major professor. 11. Training CIS 740 Software Engineering CIS 748 Software Management CIS 771 Software Specifications CIS 890 Agent-Oriented Software Engineering 6