Project Proposal by np6KJuHl

VIEWS: 35 PAGES: 8

									Implementation Proposal
     Version 1.0


  December 15, 2005




                      Theoractice Team




                          Kang-Woon Hong
                          Hyung-Choul Kim
                          Sang-Jin Han
                        Theoractice Implementation Proposal

Document Revisions

Revision   Date       Contributor        Comments
0.1        10/17/05   Hyung-Choul Kim    Created initial draft of Implementation
0.5        12/8/05    Hyung-Choul Kim
1.0        12/15/05   Hyung-Choul Kim    Modify and update




Theoractice Implementation Proposal                                       Page 2 of 8
                                       Theoractice Implementation Proposal

                                                       Table of Contents


1     INTRODUCTION..................................................................................................... 4
2     SECTIONS ................................................................................................................ 5
    2.1       CONTEXT ............................................................................................................. 5
      2.1.1      Project overview ........................................................................................................ 5
      2.1.2      Team name ................................................................................................................. 5
      2.1.3      Team members ........................................................................................................... 5
      2.1.4      Project Dimension ..................................................................................................... 6
    2.2       APPROACHES ....................................................................................................... 7
      2.2.1      Methods, Techniques, and Strategies Used ............................................................... 7
      2.2.2      Artifacts ..................................................................................................................... 7
      2.2.3      References .................................................................................................................. 8
    2.3       ANALYSIS ............................................................................................................ 8
      2.3.1      Approach verification and validation ........................................................................ 8
      2.3.2      Artifacts ..................................................................................................................... 8
      2.3.3      References .................................................................................................................. 8
    2.4       REFLECTION ......................................................................................................... 8
      2.4.1      How well did the approaches work ........................................................................... 8




Theoractice Implementation Proposal                                                                                            Page 3 of 8
                          Theoractice Implementation Proposal


1 Introduction
The Implementation proposal will be a living document that will contain several sections:
context, approaches, analysis, and reflection. Initially, the proposal will provide context,
define approaches, and a strategy for analysis. After the approach and analysis section,
the team will add the final section that discusses their reflection upon the approaches and
analysis techniques and methods that they selected.


Concern: Technology – Dimension: Implementation
Definition  This refers to the construction of the product.
Approaches Select methods, techniques, and strategies for building the prod-
            uct. (Examples include: Pair programming, Black Box, Traditional
            Coding Implementation.)
Analysis    Verify that the implementation operates according to the specifica-
            tion. (Examples include: Fagan reviews, automated testing, test
            scripts, test coverage (Markov Modeling))
Reflection  How well did these methods work? Faced with a similar situation,
            what would you do next time?




Theoractice Implementation Proposal                                             Page 4 of 8
                          Theoractice Implementation Proposal


2 Sections


2.1     Context

2.1.1    Project overview
TTA is a non-profit corporation that their activities include the filed of
telecommunications, information technology, Radio Communication & broadcasting,
establishing approximately 2,000 TTA Standards until now. Specifically, they have the
references such as Software Testing, Software Quality Assurance, Software Evaluation,
and Software Component-Related Technology.

     TTA provides comprehensive and unbiased testing services to ensure that products
tested meet the requirements of specific standards in order to guarantee quality and
performances. Such testing greatly enhances the brand image and ultimately leads to
more successful marketing of the product. There are numerous benefits that can be
gained.

     TTA now wants to define transaction processing and database benchmarks and to
disseminate objective, verifiable TPC performance data to the industry.

      The TPC Benchmark™H (TPC-H) is a decision support benchmark. It consists of a
suite of business oriented ad-hoc queries and concurrent data modifications. The queries
and the data populating the database have been chosen to have broad industry-wide
relevance. This benchmark illustrated decision support systems that examine large
volumes of data, execute queries with a high degree of complexity, and give answers to
critical business questions.

     TTA want to produce the TPC-H supporting tool for supporting DBAuditor to
measure and analyze high complexity queries. Based on the TPC-H Benchmark, the
TPC-H supporting tool provides the support for generating testing data sets, executing
Ad-hoc queries, and reporting the results. By utilizing this supporting tool, they can en-
sure that products tested meet the requirements of specific criteria and help those industry
entrepreneurs to help enhance their product image in real industry market.

2.1.2    Team name
Theoractice


2.1.3    Team members
Kang-Woon Hong
Hyung-Choul Kim
Sang-Jin Han




Theoractice Implementation Proposal                                             Page 5 of 8
                         Theoractice Implementation Proposal

2.1.4   Project Dimension
The Implementation Proposal describes the process of implementing the final product
from the architecture and design artifacts produced via the process outlined in the Design
Proposal. It also includes a high-level description of how we intend to test the imple-
mentation.




Theoractice Implementation Proposal                                           Page 6 of 8
                             Theoractice Implementation Proposal


2.2       Approaches

2.2.1 Methods, Techniques, and Strategies Used
The goal of the implementation phase is to ensure that the requirements specified in the
SRS are realized. Therefore, the components of the implementation shall be directly
traceable to one or many components of the design.

The Theoractice team will be taking an Object-Oriented approach to the implementation
of the framework. The Design Proposal describes a process that will utilize components
and objects to realize the requirements of the customer. For this reason, and to help en-
sure traceability, it makes good sense to extend that approach one level further into im-
plementation. The architectural design will be concrete to the level of defining the public
interfaces to be used by the individual components for communication purposes.

All newly created source code will be required to follow a coding standard. This will help
to ensure readability of the code across different team members and will greatly help to
expedite the peer review process (see below).

All source code for the project will be maintained within a source code control system
(possibly CVS or similar). There are multiple reasons for this. First, using a source code
control system allows the team to keep all files relevant to the implementation of the sys-
tem within one logical location. Second, the control system will track all modifications to
the code base (i.e. what was the change? Who made the change? When did they make the
change?). Third, the control system will help the team to manage concurrent changes to
the same file by multiple team members.

Prior to checking any code into the source code control system, there will be a strict set of
steps that must be followed by the developer wishing to commit the new or modified
code. First, the developer must ensure that any public interfaces defined by the objects
within the code do not contradict the public component interfaces as described by the de-
sign artifacts. Second, all unit testing (defined in the next section) of the objects defined
by the code must be complete. Third, the source code must undergo and pass a peer re-
view by another team member. This peer review is a technical critique of the code as well
as a check of the implementation to ensure that the functionality provided therein is
traceable back to the design. These steps will ensure that all code stored within the source
code control system is consistent with the design and understood by at least one other
team member. This will greatly help to reduce conflicts at the time of component integra-
tion by increasing communication and agreement amongst the team members prior to the
release of any new code.



2.2.2 Artifacts
          Coding Standard Document
          Source Code and associated support files




Theoractice Implementation Proposal                                              Page 7 of 8
                             Theoractice Implementation Proposal

2.2.3 References
[1] PandoraImplProposal_v1.1.doc, Pandora Team, CMU MSE Course 2005
“http://dogbert.mse.cs.cmu.edu/mse2005/projects/Pandora/public_html/Home/home.html

2.3       Analysis

2.3.1 Approach verification and validation
There will be three main types of testing: unit testing, integration testing, and system test-
ing. The unit tests will be used to ensure that the implemented objects both operate with-
out bugs and completely realize the requirements assigned to their respective components
by the design. The integration tests will be used locally by the developer of the compo-
nent to ensure that a newly developed component integrates properly with the rest of the
application on the development machine. The system tests will ensure that once all im-
plemented objects are integrated together as part of a baseline, they interact without bugs
and completely realize all the requirements of the customer as described by the SRS.

During unit testing, individual components will be tested prior to their insertion into the
baseline to ensure that they are free of bugs. All error statements created within the scope
of the object being tested should be identified and removed.

During integration testing, the developer ensures that the newly completed component
works properly with respect to the rest of the components locally on the development
machine. The integration testing can catch many interaction bugs before the component is
checked back in to the baseline. This is different from system testing in that integration
testing is executed by the developer, and system testing is a full check of the entire sys-
tem, possibly done by someone entirely outside of the development team.

The unit testing combined with the integration and system testing as described herein will
make it possible to ensure that the final product is both free of bugs and complete with
respect to functionality. In other words, it will ensure that the team has both built the sys-
tem right as well as built the right system.


2.3.2 Artifacts
          Test Plans (As many as necessary to realize the use cases)
          Testing metrics (i.e. number of errors found, etc.)

2.3.3 References
[1] PandoraImplProposal_v1.1.doc, Pandora Team, CMU MSE Course 2005
“http://dogbert.mse.cs.cmu.edu/mse2005/projects/Pandora/public_html/Home/home.html”

2.4       Reflection

2.4.1 How well did the approaches work




Theoractice Implementation Proposal                                               Page 8 of 8

								
To top