Docstoc

Infrastructure Components Part 2

Document Sample
Infrastructure Components Part 2 Powered By Docstoc
					CHAPTER 5

    Infrastructure Components
              PART II
   Procedures and work instruction.
   Quality support devices like templates and
    checklists.
   Staff SQA training and certification
    activities.
   Preventive and corrective actions.
   Software configuration management.
   Documentation and quality records
    control.



                BCS3263 – Software Quality Assurance SemII0809   2
                               BARIAH YUSOB
Corrective and Preventive Actions
(CAPA) - Definition
    Corrective actions:
        A regularly applied feedback process that
         includes collection of information on quality
         non-conformities, identification and analysis
         of sources or irregularities as well as
         development and assimilation of improved
         practices and procedures, together with
         control of their implementation and
         measurement of their outcome.

                    BCS3263 – Software Quality Assurance SemII0809   3
                                   BARIAH YUSOB
Corrective and Preventive Actions
(CAPA) - Definition
    Preventive actions:
        A regularly applied feedback process that
         includes collection of information on
         potential quality problems, identification
         and analysis of departures from quality
         standards, development and assimilation of
         improved practices and procedures,
         together with control of their implementation
         and measurement of their outcome.

                    BCS3263 – Software Quality Assurance SemII0809   4
                                   BARIAH YUSOB
Corrective and Preventive Actions
(CAPA) - Definition
    Sources of CAPA information:
        Quality records, service reports, internal
         quality audits, project risk reviews, software
         risk management reports, etc.




                    BCS3263 – Software Quality Assurance SemII0809   5
                                   BARIAH YUSOB
Corrective and Preventive Actions
(CAPA) - Process
    Successful operation of a CAPA process
     includes the following process:
      Information collection (CAPA sources)
      Analysis of information

      Development of solutions and improved
       methods
      Implementation of improved methods

      Follow-up.



                 BCS3263 – Software Quality Assurance SemII0809   6
                                BARIAH YUSOB
      Development process                                      Product and infrastructure
      information                                              information. Examples:
      Examples:                                                Customer complaints
      Design review reports                                    Software quality metrics and
      Inspection reports                                       quality costs
      Test reports                                             Internal quality audits
      Special reports of development                           Special reports of current
      failures and successes                                   operations failures and
                                                               successes
                                                                                  Feedback on content
Feedback on content            Analysis of collected information                  and regularity of
and regularity of supply                                                          supply of product
of process information                                                            information
                                 Development of solutions and
                                      improved methods

                            Corrective                       Preventive
                             actions                         actions

                           Implementation of improved methods
Feedback on                                                                         Feedback on
outcomes of                Fo llo w - u p o f im p lem en t at i o n an d           implementation
improved                       o u t co m es o f co r r ect iv e an d               of improved
methods                               p r ev en t iv e act io n s                   methods


                            BCS3263 – Software Quality Assurance SemII0809                              7
                                           BARIAH YUSOB
Sources of CAPA information
 Internal information sources                                  SQA infrastructure class of sources
                                                                 Internal quality audit reports
 Software development process                                    External quality audit reports
    Software risk management reports                            Performance follow-up of trained and
    Design review reports                                        certified staff
    Inspection reports                                          Proposals suggested by staff members.
    Walkthrough reports
    Experts’ opinion reports                                  Software quality management procedures
                                                                   class of sources
    Test reviews
                                                                  Project progress reports
    Special reports on development failures
     and successes                                                Software quality metrics reports
    Proposal suggested by staff members.                         Software quality cost reports
                                                                  Proposals of staff members.
 Software maintenance
    Customer applications statistics                          External information sources
    Software change requests initiated by                           Customer complaints
     customer applications                                           Customer service statistics
    Software change requests initiated by                           Customer-suggested proposals.
     maintenance staff
    Special reports on maintenance failures
     and successes
    Proposals suggested by staff members.


                                BCS3263 – Software Quality Assurance SemII0809                            8
                                               BARIAH YUSOB
Analysis of collected information

    Analysis involves:
        Screening the information and identifying potential
         improvements.
        Analysis of potential improvements, to determine:
             Expected types and levels of damage
             Causes of faults
             Estimate total damage expected and determine the priority
              of each fault case.
        Generating feedback on the content and regularity
         of information received from the designated
         information sources.

                         BCS3263 – Software Quality Assurance SemII0809   9
                                        BARIAH YUSOB
Development of solutions

    Solutions to identified causes of
     recurrent software systems faults are
     required to:
      Eliminate recurrence of the types of faults
       detected
      Contribute to improved efficiency by
       enabling higher productivity and shorter
       schedules.


                  BCS3263 – Software Quality Assurance SemII0809   10
                                 BARIAH YUSOB
Development of solutions
    Several directions for solutions are commonly
     taken:
        Updating relevant procedures. Ex: changes of the
         maximum and minimum number of participants in a
         DR session, etc.
        Changes in practices, including updating of relevant
         work instructions.
        Shifting to a development tool that is more effective
         and less prone to the detected faults.
        Improvement of reporting methods, including
         changes in report content, frequency of reporting
         and reporting tasks.
        Initiatives for training, retraining or updating staff.

                      BCS3263 – Software Quality Assurance SemII0809   11
                                     BARIAH YUSOB
Implementation of the solutions

    Relies on proper instructions and often
     training but most of all on the
     cooperation of the relevant units and
     individuals.




                 BCS3263 – Software Quality Assurance SemII0809   12
                                BARIAH YUSOB
Follow-up of activities
    Follow-up of the flow of development and
     maintenance CAPA records from various
     sources of information.
        enables feedback that reveals cases of no
         reporting, low quality reporting – important details
         are incorrect/missing.
    Follow-up of implementation.
        Indicate whether the designated actions have been
         performed in practice.
    Follow-up of outcomes.
        Assessment of how much CAPA actions have
         achieved the expected results.

                      BCS3263 – Software Quality Assurance SemII0809   13
                                     BARIAH YUSOB
Organizing for CAPA
    Collecting CAPA records from the various
     sources.
    Screening the collected information.
    Nominating ad hoc CAPA teams to tend to
     given subjects or head the teams.
    Promoting implementation of CAPA
    Following up information collection, data
     analysis, progress made by ad hoc teams,
     implementation as well as outcomes of
     improved CAPA methods.

                  BCS3263 – Software Quality Assurance SemII0809   14
                                 BARIAH YUSOB
Ad hoc CAPA teams

 They regularly focus on:
      Analysis of the information related to the team’s
       topic.
      Initiation of additional observations and inquiries.
      Identification of the causes for the faults.
      Development of solutions and the relevant CAPA.
      Preparation of proposed implementation revisions.
      Analysis of the CAPA implementation outcomes
       and CAPA revision if necessary.



                    BCS3263 – Software Quality Assurance SemII0809   15
                                   BARIAH YUSOB
Configuration Management

    Questions:
      What is the correct version of the software
       module that I have to continue its coding?
      Who can provide me with an accurate copy
       of last year’s version 4.1 of the TMY
       software system?
      What version of the software system is
       installed at ABC Industries?
      Etc..


                  BCS3263 – Software Quality Assurance SemII0809   16
                                 BARIAH YUSOB
Software configuration – Items and
management
    Software configuration item (SCI) or
     configuration item (CI):
        An approved unit of software code, a
         document or piece of hardware that is
         designed for configuration management and
         treated as a distinct entity in the software
         configuration management process.




                    BCS3263 – Software Quality Assurance SemII0809   17
                                   BARIAH YUSOB
Software configuration – Items and
management
    SCI version:
        The approved state of an SCI at any given point of
         time during the development or maintenance
         process.
    Software configuration version:
        An approved selected set of documented SCI
         versions that constitute a software system or
         document at a given point of time, where the
         activities to be performed are controlled by software
         configuration management procedures. The
         software configuration versions are released
         according to the cited procedures.

                      BCS3263 – Software Quality Assurance SemII0809   18
                                     BARIAH YUSOB
Common types of SCI
    Design documents
        SDP, SRD, PDD, CDD, STP, STPR, STR, etc.
    Software code
        Source code, object code, prototype software.
    Data file
        Test cases and test scripts, parameters, codes, etc.
    Software development tools (the versions
     applied in the development and maintenance
     stages)
        Compilers and debuggers, application generators,
         CASE tools.


                      BCS3263 – Software Quality Assurance SemII0809   19
                                     BARIAH YUSOB
                                                Release and release date
                            PMT Version 6.0                                  PMT Version 7.0
                            January 6, 2002                                  January 22, 2003
SCI Version            SCI Version in the Release                       SCI Version in the Release
SRD                                   Ver. 1                                      Ver. 1
CDD                                   Ver. 3                                      Ver. 4
STP                                   Ver. 3                                      Ver. 4
SIP                                   Ver. 2                                      Ver. 2
VDD                                   Ver. 6                                      Ver. 7
Code Module 1                         Ver. 3                                      Ver. 5
Code Module 1                         Ver. 8                                      Ver. 8
Code Module 1                         Ver. 2                                      Ver. 2
Test cases file                       Ver. 3                                      Ver. 4
CL compiler                           Ver. 5                                      Ver. 7
Software user manual                  Ver. 6                                      Ver. 7




                       BCS3263 – Software Quality Assurance SemII0809                                20
                                      BARIAH YUSOB
Software configuration management
(SCM) - Definition
    SCM:
        An SQA component responsible for
         applying (computerized and non-
         computerized) technical tools and
         administrative procedures that enable
         completion of the tasks required to maintain
         SCIs and software configuration versions.




                    BCS3263 – Software Quality Assurance SemII0809   21
                                   BARIAH YUSOB
Tasks of the SCM

  Control software change
  Release of SCI and software
   configuration versions
  Provision of SCM information services
  Verification of compliance to SCM
   procedures.



              BCS3263 – Software Quality Assurance SemII0809   22
                             BARIAH YUSOB
The software configuration authority

  SCM procedures specify who is responsible
   for SCM issues.
  This responsible usually assigned to a senior
   professional or a committee that been set-up
   to handle the SCM issues – software change
   control authority (SCCA) or software change
   control board (SCCB).
  During the development phase, the project
   manager may be charged with the authority to
   carry out SCM responsibilities.

                BCS3263 – Software Quality Assurance SemII0809   23
                               BARIAH YUSOB
Software control change

    Software change management controls
     the process of introducing changes
     mainly by doing the following:
      Examining change requests and approving
       implementation of appropriate requests.
      Assuring the quality of each new version of
       software configuration before it becomes
       operational.


                  BCS3263 – Software Quality Assurance SemII0809   24
                                 BARIAH YUSOB
Factors affecting approval of
proposed changes
    Expected contribution of the proposed change
    Urgency of the change
    Effect of the proposed change on project
     timetables, level of service, etc.
    Efforts required in making the change
     operational
    Required software quality assurance efforts
    Estimated required professional resources and
     cost of performing the change.

                  BCS3263 – Software Quality Assurance SemII0809   25
                                 BARIAH YUSOB
Software change request (SCR)
document - a template
 1.   Change principles
        •    The initiator
        •    The date the SCR was presented
        •    The character of the change
        •    The goals
        •    The expected contribution to the project/system
        •    The urgency of performance
 2.   Change details
        •    Description of the proposed change
        •    A list of the SCIs to be changed
        •    Expected effects on other SCIs
        •    Expected effect on interfaces with other software systems and hardware firmware
        •    Expected delays in development completion schedules and expected disturbances to
             services to customers
 3.   Change timetable and resources estimates
        •    Timetable for implementation
        •    Estimated required professional resources
        •    Other resources required
        •    Estimated total cost of the requested change.




                             BCS3263 – Software Quality Assurance SemII0809               26
                                            BARIAH YUSOB
Quality assurance of software
changes
    Quality assurance efforts are required at
     two levels:
      Quality assurance of each of the changed
       SCIs
      Quality assurance of the entire new
       software system version (that includes
       changed SCIs).



                 BCS3263 – Software Quality Assurance SemII0809   27
                                BARIAH YUSOB
Quality assurance of the changes
SCIs
  Require preparation of a reviews and testing
   plan at a magnitude appropriate to the
   character of the change.
  It is important that reviews and testing be
   carried out by professional testers and not by
   the SCI’s developer.
  The process of reviews and testing,
   corrections and re-testing (regression testing)
   the change SCIs is expected to conclude with
   their approval.

                 BCS3263 – Software Quality Assurance SemII0809   28
                                BARIAH YUSOB
Quality assurance of the entire new
software system version
  A new version of the software is considered to
   have been completed once the changed SCIs
   replace the former SCIs.
  Many new versions, especially of complex
   software systems, actually fail.
  The failures generally occur as a result of
   damage done to interfaces between the
   changed SCIs and other SCIs left unchanged
   and not retested because they were not
   expected to be affected by the changes
   performed.


                BCS3263 – Software Quality Assurance SemII0809   29
                               BARIAH YUSOB
Release of software configuration
versions
    The need to release a new software
     configuration control:
      Defective SCIs
      Special features demanded by new
       customers
      The team’s initiatives to introduce SCI
       improvements.



                  BCS3263 – Software Quality Assurance SemII0809   30
                                 BARIAH YUSOB
Types of software configuration
releases
    Baseline versions
        Planned early, during a system’s development or operating stage.
        As part of the process, they are reviewed, tested and approved,
         as their SCIs.
        They serve as milestones in the SDLC, and represent the
         foundations for further system development.
    Intermediate versions
        When problem arise that require immediate attention – an
         intermediate version of the software is often prepared.
        Usually, serve only a portion of a firm’s customers, limited period,
         until replaced by a new baseline versions.
        Can serve as a “pilot” to the next baseline version.
    Revisions
        Introduce minor changes and corrections to a given SC version.
        In some cases, revisions are released before a new baseline
         version is released.
                          BCS3263 – Software Quality Assurance SemII0809   31
                                         BARIAH YUSOB
Numeration conventions for identification of
SCI and software versions

     Decimal numeration
       Indicates the successive version and
        revision numbers.
       Example: DD7 Ver.1.0, DD7 Ver.1.1, etc.




                  BCS3263 – Software Quality Assurance SemII0809   32
                                 BARIAH YUSOB
Software configuration management
plans (SCMPs)
    Objective:
        to plan ahead the schedule of baseline version
         releases and the required resources to carry out all
         the activities required for the software configuration
         releases.
        To enable one to follow up the progress of activities
         involved in software version release.
    SCMPs are required during the development
     stage as well as the operation (maintenance)
     stage.

                      BCS3263 – Software Quality Assurance SemII0809   33
                                     BARIAH YUSOB
SCMP – the content
    An overview of the software development project or
     existing software system.
    A list of scheduled baseline version releases.
    A list of SCIs (documents, code, etc.) to be included in
     each version.
    A table identifying the relationship of software
     development project plans and maintenance plans to
     scheduled releases of new SCIs or SCI versions.
    A list of assumptions about the resources required to
     perform the SCMP.
    Estimates of the human resources and budget needed
     to perform the SCMP.

                     BCS3263 – Software Quality Assurance SemII0809   34
                                    BARIAH YUSOB
SCMP for the development stage

    SCMP sets the release dates of baseline versions,
     which usually coincide with the conclusion of one or
     more of the following three events: the design stage,
     the coding stage and the system test stage –
     represent a segment of the entire system’s
     development plans, prepared at a project’s initiation.
    Development process must be comply with the SCMP.
    All instructions and procedures necessary for
     performing the SCM tasks are documented in the
     SCMP.
    Responsibility – the project manager.


                    BCS3263 – Software Quality Assurance SemII0809   35
                                   BARIAH YUSOB
SCMP for the operation
(maintenance) stage
  Further releases of software baseline versions
   are required.
  SCMP usually schedules new baseline releases
   periodically – annual/semiannual, which include
   corrected/new versions of SCIs.
  Only SCIs for which changes have been
   completed and approved by the targeted release
   date can be included in new SC versions.



                BCS3263 – Software Quality Assurance SemII0809   36
                               BARIAH YUSOB
Software configuration evolution
models
    The linear evolution model
        Only one unique SC version serves all customer at
         any given time.
        For system that is developed to serve a single
         organization.
        Applied to popular software packages
        Uniform in structure.
    The tree evolution model
        Several parallel versions are developed to serve the
         needs of different customers.
        Applied in firmware configuration versions, where
         each branch serves a different product or product
         line.

                       BCS3263 – Software Quality Assurance SemII0809   37
                                      BARIAH YUSOB
    Ver 4.1 IN

   Ver 4.0 BL      Ver d1.1 IN                 Ver e1.1 BL       Ver c2.0 BL

   Ver 3.0 BL
                                 Ver b1.1 IN
    Ver 2.2 IN     Ver d1.0 BL                  Ver e1.0 BL      Ver c1.1 BL
                                                       Color
    Ver 2.1 IN     Black                              printer
                  printer
                                 Ver b1.0 BL                     Ver c1.0 BL
     Ver 2.0 BL
                       Printer                                            Printer
                                                                           - fax
     Ver 1.0 BL                                Ver a1.0 BL
                                                                General
Linear evolution model               Tree evolution model
Software configuration release
documentation – VDD template

  Identification and installations
            Release version and revision number, including date
            List of installations where the release was installed


  Configuration of the released version
            List of SCIs (including SCI’s version) in the released
             software version
            List of hardware configuration items required for operating
             the specified version
            List of interfacing software and hardware systems
            Installation instructions for the new release




                       BCS3263 – Software Quality Assurance SemII0809      39
                                      BARIAH YUSOB
Software configuration release
documentation – VDD template (cont..)
  Changes in the new version
           Previous software configuration version
           List of SCIs that have been changed, new SCIs, and deleted
            SCIs
           Short description of introduced changes.
           Operational and other implications of changes in the release.


  Further development issues
           List of software system problems that have not been solved in
            the new version.
           List of delayed SCRs and proposals for development of the
            software system.




                       BCS3263 – Software Quality Assurance SemII0809       40
                                      BARIAH YUSOB
Provision of SCM information
services
  The SCM is required to provide information to
   professionals, mainly developers,
   maintenance teams and customer
   representatives, who have requested that
   changes be introduced in a software system.
  The information provided may be classified
   into information related to software change
   control and information dealing with SCI and
   software configuration versions:
        Information related to software change control
        Information about SCIs and software configuration
         versions.

                     BCS3263 – Software Quality Assurance SemII0809   41
                                    BARIAH YUSOB
Information related to software
control change
  Change request status information –
   based on records for every submission
   of an SCR and the decisions made.
  Change order progress information –
   based on records for every approved
   SCO, its schedule, implementation
   progress and test results, including the
   information about delays in performance.

              BCS3263 – Software Quality Assurance SemII0809   42
                             BARIAH YUSOB
Information about SCIs and software
configuration versions
    Accurate copies of SCI versions (code SCIs,
     document SCIs, etc.) and entire software configuration
     versions.
    Full reports of changes between successive releases
     (versions and/or revisions) of code SCIs and between
     successive releases of other types of SCIs.
    Copies of SCI version documentation and software
     configuration version documentation (VDDs).
    Detailed version and revision history for SCIs and
     software configurations.
    Progress information about planned versions and
     releases
    Information correlated about versions installed at a
     given site and about the site itself.
    List where a given software configuration version is
     installed.

                    BCS3263 – Software Quality Assurance SemII0809   43
                                   BARIAH YUSOB
Software configuration management
audits – report on:
    Percentage of unapproved changes introduced in the system during
     development or operation.
    Percentage of SCOs not carried out according to instructions and not
     fully complying with procedures.
    Percentage of design reviews and software tests of changed SCIs that
     have not been performed according to the relevant procedures.
    Percentage of SCOs that have been completed on schedule.
    Percentages of cases where SCIs affected by changes have not been
     checked, with some necessary changes not implemented.
    Percentages of properly documented new SCIs and software
     configuration versions.
    Percentage of properly documented installations of new software
     configuration versions.
    Percentage of cases of failure to transmit all versions-related information
     to the customer.
    Number of cases recorded annually where the SCI work coordination
     mechanism failed (i.e., did not prevent different teams from
     simultaneously introducing changes in the same SCI).

                           BCS3263 – Software Quality Assurance SemII0809          44
                                          BARIAH YUSOB
Computerized tools for managing
software configuration
   Application of tools in SC differs in their level of
    comprehensiveness, flexibility of application and ease of
    use.
   Benefit of using computerized tools:
       Able to comply with the required level of accuracy and
        completeness of information, and with the required level of
        availability.
       Operate the mechanisms coordinating the work on an SCI’s
        changes and prevent different teams from simultaneously
        introducing changes in the same SCI.
       Secures the code version and documentation files versions by
        protecting them from any changes, deletions and other damages.
       Activates back-up procedures required for safe SCM file storage.


                         BCS3263 – Software Quality Assurance SemII0809   45
                                        BARIAH YUSOB
Documentation Control

    Controlled document:
      A document that is currently vital or may
       become vital for the development and
       maintenance of software systems as well as
       for the management of current and future
       relationships with the customer.
      Its preparation, storage, retrieval and
       disposal are controlled documentation
       procedures.

                 BCS3263 – Software Quality Assurance SemII0809   46
                                BARIAH YUSOB
Documentation Control

    Quality record:
      A special type of controlled document.
      Customer-targeted document that may be
       required to demonstrate full compliance with
       customer requirements and effective
       operation of the software quality assurance
       system throughout the development and
       maintenance processes.


                  BCS3263 – Software Quality Assurance SemII0809   47
                                 BARIAH YUSOB
Documentation control - objectives

    To assure the quality of the document.
    To assure its technical completeness and compliance
     with document structure procedures and instructions
     (use of template, proper signing, etc).
    To assure the future availability of documents that may
     be required for software system maintenance, further
     development, or responses to the customer’s
     (tentative) future complaints.
    To support investigation of software failure causes and
     to assign responsibility as part of corrective and other
     actions.


                     BCS3263 – Software Quality Assurance SemII0809   48
                                    BARIAH YUSOB
Typical controlled documents
(including quality records)
     Pre-project documents
         Contract review report, negotiation meeting minutes, development
          contract, subcontracting contract, software development plan, etc.
     Project life cycle documents
         SRD, preliminary design document, critical design document,
          database description, DR report, STP, etc.
     SQA infrastructure documents
         SQA procedures, template library, SQA form library, etc.
     Software quality management documents
         Progress report, software metrics reports, etc.
     SQA audit documents
         Management review report, internal quality audit report, etc.
     Customer documents
         Software project tender documents, customer’s software change
          requests, etc.



                           BCS3263 – Software Quality Assurance SemII0809      49
                                          BARIAH YUSOB
Typical component of
documentation control procedures
  Definition of the list of the document types
   and updates to be controlled (some classified
   as quality records).
  Document preparation requirements.
  Document approval requirements.
  Document storage and retrieval requirements,
   including controlled storage of document
   versions, revisions and disposal, document
   security.

                BCS3263 – Software Quality Assurance SemII0809   50
                               BARIAH YUSOB
Authority for controlled document
and quality record list
  Deciding which document type is to be categorized as
   a controlled document and which controlled document
   types are to be classified as quality records.
  Deciding whether the level of control is adequate for
   each document type categorized as a controlled
   document.
  Following up of compliance with the controlled
   document types lists. This can be incorporated in the
   internal quality plan.
  Analyzing follow-up findings and initiating the required
   updates, changes, removals and additions to the
   controlled documents types list.

                    BCS3263 – Software Quality Assurance SemII0809   51
                                   BARIAH YUSOB
Controlled document preparation

  Creation of new document or revision of an
   existing document focus on completeness,
   improved readability and availability.
  This relies in the document:
        Structure – may be free or defined by a template.
        Identification method – unique identity based on
         version/revision code/number.
        Standard orientation and reference information –
         support future access.


                      BCS3263 – Software Quality Assurance SemII0809   52
                                     BARIAH YUSOB
Content for orientation and
reference information
    The author
    Date of completion
    Person(s) who approved the document, including
     position
    Date of approval
    Signature of the author and approver
    Descriptions of the changes introduced in the new
     release
    List of former versions and revisions
    Circulation list
    Confidentiality restrictions.

                    BCS3263 – Software Quality Assurance SemII0809   53
                                   BARIAH YUSOB
Issues of controlled document
approval
    Position of the person(s) who can approve a
     document or document type
        Can be granted by a person, several persons, or
         committees.
        Have sufficient experience and technical expertise.
    The approval process
        Aim at detecting and preventing professional
         inadequacies together with deviations from the
         document template.



                      BCS3263 – Software Quality Assurance SemII0809   54
                                     BARIAH YUSOB
Issues of controlled document
storage and retrieval
    Document storage
        Number of copies, unit responsible, storage
         medium.
    Circulation and retrieval of documents
        Instruction for circulating a new document,
         recipients, efficient and accurate retrieval of copies.
    Document security, including document
     disposal requirement
        Provide restricted access, prevent unauthorized
         changes to stored documents, provide back-up,
         determine storage period.

                       BCS3263 – Software Quality Assurance SemII0809   55
                                      BARIAH YUSOB

				
DOCUMENT INFO
Shared By:
Stats:
views:14
posted:2/23/2012
language:English
pages:55
Description: Infrastructure Components Part 2