System and method for software integration and factory deployment

Abstract

A software management database contains data structures supporting computer software provisioning for a range of CTO/BTO variations, language variations, region variations, and operating system variations.

Description

I. FIELD OF THE INVENTION

The present invention relates generally to systems and methods for software integration and factory deployment of the software.

II. BACKGROUND OF THE INVENTION

Producing consumer electronics and in particular computers that might incorporate, in addition to operating systems with various configurations and suites of applications, several subsystems, each in turn with their own software drivers, can be complicated. Not only must a bill of materials (BOM) be defined, managed, and conformed to, but product defects and corrective actions must also be managed in way that ensures corrective action can be known and taken across the globe.

Because of the complexity inherent in the above considerations, it can happen that more than a single management system might develop over time, complicating efforts to integrate knowledge and data. As recognized herein, it is desirable to have a management system that can integrate the knowledge and input of designers, engineers, software integrators, etc. in ways that reduce engineering lead times and provide ease of tracking defects and cures to the defects in a single, globally shared system within an enterprise, while providing an easy way to manage regional differentiation of software offerings, sharing information between business groups within the enterprise, and eliminating duplicative data maintenance.

For example, many computers are sold on a configure to order/build to order (CTO/BTO) basis. Each software part can have a multidimensional relationship with each stock keeping unit (SKU) that represents a product when region, language, various operating system versions, and platforms are factored in. Thus, each software part can potentially have dozens of version releases to accommodate all of these variables. As but one example of the complexity of providing CTO/BTO computers, one version of a “click to DVD” software may be used only on French Windows MCE SR series SKUs that are sold only in Quebec, but another version may be designed to work on any model using Windows XP Home Edition Spanish Version regardless of region.

As another example of complexity, consider that there are currently about ten Sony VAIO platforms worldwide, and each platform may contain multiple VAIO models with variations on CPU, RAM, HDD capacity, wireless (WLAN, WWAN, and Bluetooth), graphics chipset, etc. Several major regions that include an even greater number of languages in many different countries, along with plural operating system variations, may require support. Still further, each model of VAIO for each region/language/country/OS variation contains well over one hundred pieces of software, each of which may be a unique version for only that model, or may be used for multiple models of VAIO, giving an idea of the exponential scope of the relationship between software and computer models the database must be designed to support. In summary, the relationships between software parts and the platforms they are used on have become extremely complex, and with this critical recognition in mind, the invention herein is provided.

In addition, the present invention critically recognizes that the quality of the final product is important. As understood herein, each piece of software may contain defects, or when combined in an image with other software may cause defects to be generated.

SUMMARY OF THE INVENTION

As set forth further below, processes and tools are provided herein for quickly assessing the quality of a project by relating the defects to part releases, which are in turn related to projects. For example, if a major flaw is found in a particular release version of a part, this defect is related to the appropriate part release or releases so that the defect is instantly related to all the projects that use the particular part release. Given the complexity of the software BOMs, without the present invention this task would be difficult and time consuming to do manually.

Thus, preferred implementations of the present invention correlate the relationships between software parts, the platforms they are used on, and the quality of those parts.

A method is disclosed for managing computer production in an enterprise. The method includes receiving a block of software offerings, with each block being associated with at least one product series. A product series component structure is received that defines parts for a respective product series. Parts that are required for a product series are added to the block associated with the series, with parts being assigned to each software class and related software specification pair in a block based on the part or parts required for the pair to thereby define a design structure. The method includes establishing a software bill of materials (BOM) based on the design structure using a template and/or a snapshot.

In non-limiting implementations the method includes defining software offerings. A software offering includes at least one software class and at least one associated software specification. Software offerings are associated with respective product series to establish a configuration, with configurations cumulatively defining a configuration range that contains product offerings of the enterprise for all regions in which the enterprise does business. The method may include grouping classes into blocks. A block is associated with at least one product series.

The non-limiting method may also include defining which classes are dependent on each other, and defining which blocks are base blocks. Defects can be associated with related classes and corrective actions associated with respective defects.

If desired, the method can includes associating a respective installation file with each software offering. Each installation file may include a data file format version number, a version number of an installation data snapshot, an installation order for modules, data required for confirming successful installation, cyclic redundancy check (CRC) data for each binary file, path information for locating files in a file store, partition size information for recovery and customer partitions. Also, installation and recovery tools may use a list of software releases directly instead of microcode, which is used only for customer recovery, with microcode bit mappings being constrained to respective recovery media sets.

In another aspect, a software management database on a computer readable medium can contain data structures supporting computer software provisioning for a range of CTO/BTO variations, language variations, region variations, and operating system variations.

Non-limiting data structures may include bill of materials (BOM) entities containing information related to parent BOMs and child BOMs, if any. Each BOM entity can also include an engineering part ID, a software release ID, a major version ID, a group ID, a component ID, a planning parts ID, and a software series ID. A plan parts entity can also be provided that includes launch dates for software base releases, import dates for software bases indicating when the bases were imported into computers, and identifications for software bases.

Other non-limiting entities in the database may include component entities including launch dates for software base releases, import dates for software bases, identifications for software bases. Software release entities containing a base ID, a name, a file path, a launch date can also be provided, as can be software release status entities that include data representing status and name of a software release. Additional database entities may include: a group entity containing data representing a name and launch of a type, a series entity containing a software series ID, base ID, name, an indication of being active, a launch date, an import date, an engineering parts entity containing an engineering part ID, a base ID, a type ID, a name, a launch date, and indication of dependent parts, an engineering parts major revision entity containing information related to default use, an engineering part software release entity containing information on a related engineering part entity, a related engineering parts major revision entity, a related language code entity, and a language entity containing information related to a language name and a language code.

In another aspect, a computer-implemented system for creating bills of materials (BOMs) includes logic that can be executed by a computer and stored on a computer readable medium. The logic facilitates creation of BOMs using templates and/or snapshots. BOMs can be automatically generated based on part attributes and groups of parts, major versions, and releases. The logic can automatically check BOMs to reduce errors.

In still another aspect, a computer system executing logic stored on a computer readable medium enters, into a first database, first software data. The first software data includes operating systems and configure to order/build to order (CTO/BTO) options. The system transfers at least some of the first software data in the first database to a comprehensive global database, referred to herein colloquially as “ePic.” Second software data such as operating system updates, device drivers, and utilities is automatically adding to a bill of materials (BOM) through the comprehensive global database. Also, software along with metadata that describes the software can be checked into the comprehensive global database by users, and the BOM for a specific series/language/region can be frozen/locked and the process to create factory deliverables including software image, software modules, and data can then begin.

The database tracks defects and relates them to parts, stores test cases which are related to parts which in turn allows test strategies to be auto-generated.

The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-3 are diagrams of non-limiting software management phases;

FIG. 4 is a flow diagram of non-limiting overall software development, integration, and factory deployment processes;

FIG. 5 is a flow diagram of a non-limiting software planning process;

FIG. 6 is a flow diagram of a non-limiting bill of materials (BOM) creation process;

FIG. 7 is a flow diagram of a non-limiting software development process;

FIG. 8 is a flow diagram of a non-limiting software integration process;

FIG. 9 is a flow diagram of a non-limiting factory deployment process;

FIG. 10 is a flow diagram of aspects of a non-limiting factory deployment process;

FIG. 11 is a flow diagram of a non-limiting software installation process;

FIGS. 12-17 are non-limiting screen shots used for defect management and test case management purposes;

FIG. 18 is a diagram showing software inputs to the ePic database interface;

FIG. 18A is a flow chart of logic of downloading an image to a test system;

FIG. 19 is a flow chart showing how BOM snapshots are generated, automatically at least in part, and entered into ePic;

FIGS. 20 and 21 are consolidated diagrams showing the interaction between various entities in a non-limiting implementation;

FIG. 22 is a diagram showing various data entities in the ePic database and some of their attributes;

FIG. 23 is a map showing a non-limiting deployment regime;

FIG. 23A is a flow chart showing software integration logic;

FIG. 24 is a flow diagram showing a non-limiting factory deployment process; and

FIGS. 25-27 are further non-limiting defect-related screen shots.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the present non-limiting implementation, only part of the software data is contained in a data store referred to below as “DB Hero”. Specifically, software data that is visible to customers (e.g., operating systems, configure to order/build to order (CTO/BTO) options, software highlighted on web sites, etc.) is entered into DB Hero. As set forth in the specification below, periodically, some of the data from DB Hero is pushed to a comprehensive global database referred to herein as ePic, including both stock keeping unit (SKU) data and software data.

Software data that is not as visible to customers (such as operating system updates, device drivers, utilities, etc.) are added to the bill of materials (BOM) through the comprehensive global database. Software is checked into the comprehensive global database by developers, vendors or engineers, along with metadata that describes the software for process tools. The BOM for a specific series/language/region is frozen/locked and the process to create the factory deliverables (software image, software modules, and data) can then be started. As set forth in the detailed specification below, various process tools and manual process can be used to create the factory deliverables, all of which use data stored in the comprehensive global database.

Additionally, the factory deliverables are tested and validated to meet quality standards. The factory deliverables, and the metadata that describes them, are then delivered to the factory to be used in mass production.

To better understand terms used herein, the range of potential software offerings for a given sales cycle is defined as a set of classes and specifications. The class structure captures how the various software items will be offered to the customer, and is a specific type of software. Specifications, on the other hand, are individual software items that are associated with classes. Thus, a specification is an option that the customer may choose within a class, and a class may have more than one specification while a specification is assigned to only one class. Software offerings (classes and specifications) are associated with individual series, with the resulting structure being called the “configuration range.” The configuration range for a SKU is a list of all the Classes (and specifications) that are offered for that SKU.

By way of non-limiting example only, a “class” might be “pre-installed office software”, and specifications within that class from which the customer can select might be “MS Office professional”, “MS Office Small Business”, “MS Office Basic”, and “MS Works.”

With the detailed description below it will be appreciated that the database herein supports software variations in CTO/BTO, language, region, and OS. In addition, this database, and the tools that use it, allow for the creation of CTO systems, based on individual customer orders, in the mass production process with every piece of software preinstalled and ready to use, allowing for a virtually infinite number software offerings to customers as opposed to a few pre-defined options.

Also, unnecessary duplicate data entry is eliminated, hardware components are automatically mapped to software releases, and developers can specify language and geographic region supported for each software release at the time of software check-in, with the correct release being assigned to each BOM automatically. Further, BOMs are created using templates and snapshots for efficiency. Moreover, BOMs are automatically generated based on part attributes to reduce effort, and groups of parts, major versions, and releases can be defined and reused. Automatic checking of the BOMs is provided to reduce errors. In addition, installation and recovery tools use a list of software releases directly instead of microcode, which is used only for customer recovery, with microcode bit mappings being constrained to each recovery media set that is defined. This solves the problem of limited microcode bits and makes the changing of a recovery key easier.

Below are details of one non-limiting implementation of present principles. FIG. 1 illustrates that the present methods may be undertaken by a computer system 10 including one or more enterprise computers 12, each potentially having its own monitor 14 which can display the screen shots described below. The enterprise computers 12 can be used by developers and software engineers to execute the invention. Thus, the logic and the databases herein (including the so-called “DBHero” database 16 and global database 18, referred to herein as “ePic”) may be distributed over plural computers if desired, and some of the method steps may be undertaken by human users of the enterprise computers 12 while other method steps can be undertaken automatically by logic resident on computer readable media in computers. The computer readable media can include but is not limited to RAM, ROM, floppy disks, hard disk drives, optical disk drives, solid state memory devices, etc.

Referring briefly to FIG. 19 out of turn, logic for creating BOMs is shown. Beginning at start state 20, a software developer or integrator selects a software series, discussed above, from a list of series. The series can include data on software that an end user ordinarily “sees”, e.g., operating systems and configure to order/build to order (CTO/BTO) software options.

A human language and/or geographic region is selected at state 24 and then based on the selected language and region, at state 26 a processor in one or more of the enterprise computers 12 shown in FIG. 1 can retrieve a list of component parts, including images and modules. These component parts typically include software the end user ordinarily does not “see” such as operating system updates, device drivers, and utilities.

The software integrator then selects the image or module to be built at state 28, and at state 30 a BOM snapshot from a list is selected for the part selected at state 28. In response, a processor in one or more of the enterprise computers 12 shown in FIG. 1 then downloads, at state 32, BOM items from a file store that may be resident in the global database 18 shown in FIG. 1 to create an image to be loaded onto a computer to be vended. The image is checked in to the global database 18 at state 34 and uploaded to the file store, from whence it may be downloaded in the factory and loaded onto a computer to be vended. The process ends at state 36.

A detailed description of a non-limiting implementation of the invention follows below.

0 Project Objectives

0.1 Goals

• • Enable a global software CTO process which can be used for all VAIO business styles (CTO, BTO, Retail).
  • Redesign the software process from design through manufacturing to be a global process.
  • Define a global modular software specification.
  • Define a global recovery specification.
  • Integrate the software and hardware design process.
  • Shorten lead-time to market.
  • Reduce engineering costs.
  • Shift engineering resources from maintenance roles to value-add development roles.
  • Maintain product quality in the new process.
  • Create a flexible process and system.
  • Automate tasks where appropriate to create greater accuracy and speed in activities. 0.2 Critical To Quality
  • World-wide scalability.
  • Global access to system (including third parties).
  • Data portability.
  • Multi-language handling for software items.
  • Seamless interfaces to DB Hero.
  • Turn-key factory deployment. 1 Dependencies and Assumptions 1.1 Dependencies 1.2 Assumptions
  • LangRegion Specifications (Specs) in DB Hero will be reused between series.
  • Software parts in DB Hero will be defined so that the “Part Name” and “Major Version” will be separate fields.
  • No language/region specific information will be entered for parts into DB Hero unless royalty/licensing requirements differ by language/region for the given software part. 2 User Roles and Responsibilities
  • Product Planner
    • Determines the VAIO hardware and software offerings to be made to customers.
  • Program Manager
    • Works with product planners, sales and marketing, and engineering to produce a detailed product plan and offering strategy for each VAIO product series.
  • Software Developer
    • Develops software to be included in VAIO product offerings.
    • Prepares software so that it may be delivered to the factory for installation on products.
  • Software Integrator
    • Uses OPK (OEM Pre-installation Kit) in combination with build systems to prepare images.
    • Prepares data used in the factory to convert manufacturing bills of materials (BOMs) to a list of software items for installation.
    • Prepares data used to facilitate the software recovery by the customer in the event of a failure with their VAIO product.
  • Project Test Lead
    • Person in charge of preparing test cases and test strategies for a series and/or project (project would be Windows beta or VAIO mouse—this concept is not managed by ePic).
    • Assesses defects and devises test strategies to ensure they are fixed.
  • Test Lead
    • Tester in charge of an individual software release/component.
    • Maintain test cases as requirements change.
    • Resolves defects.
  • Tester
    • Tests software deliverables to ensure quality product.
    • Identifies and tracks defects.
    • Reports quality status.
    • Sometimes maintains test cases as requirements change.
  • Factory Engineer
    • Deploys the tools and software deliverables to the factory floor so that they may be automatically installed.
    • Collects data produced in the factory installation process and delivers it to a data warehouse.
  • Customer
    • Makes hardware and software choices when placing an order for a custom product.
    • Initiates the recovery process in the event of a system failure.
    • The customer does not interact with the SIFD system directly.
  • 3^rd Party Developer
    • Checks current software releases.
  • 3^rd Party Factory Engineer/QA Tester
    • Downloads or receives software deliverables and tools. 3 Business Process 3.1 Hardware Design

The Software Integration and Factory Deployment Project solution will operate within the context of the new design process specified as part of the DB Hero project. FIGS. 1 through 3 represent a non-limiting version of DB Hero process.

FIGS. 1-3 do not include software related tasks. One objective of the proposed invention is to integrate the software and hardware design processes.

3.2 Overall Software Process—Now referencing the non-limiting process outlined in FIG. 4.

• • 1. Software Planning and Design
    • a. Description
      • i. Program Managers and Product Planners define software offerings.
    • b. Inputs
      • i. Previous cycle's software offerings.
      • ii. New software offerings.
    • c. Outputs
      • i. Configuration (Config) Range and Component Structure.
    • d. System Interactions
      • i. Offering structure and planning parts are entered in DB Hero.
      • ii. Planning Parts and Component Structure are transferred to ePic.
  • 2. Software Development
    • a. Description
      • i. Register engineering parts and develop software.
    • b. Inputs
      • i. Software offerings.
      • ii. Planning parts from DB Hero.
    • c. Outputs
      • i. Software applications, drivers, documentation, and other software items.
    • d. System Interactions
      • i. Part registration and item check-in in ePic.
  • 3. Software Integration
    • a. Description
      • i. Define image BOMs, build images, define media sets (factory and recovery), and prepare factory deliverables.
    • b. Inputs
      • i. Software items checked-in by developers.
    • c. Outputs
      • i. Images, Modules, and Series Software BOM.
    • d. System Interactions
      • i. Register parts.
      • ii. Check image releases.
      • iii. Create series software BOM.
      • iv. Define recovery media.
  • 4. Release to Manufacturing
    • a. Description
      • i. Planner or Program Manager issues a RTM for a series/region.
    • b. Inputs
      • i. Series software BOM.
    • c. Outputs
      • i. Installation data file. RTM'ed image and module releases.
      • ii. RTM Notification.
    • d. System Interactions
      • i. RTM is issued in ePic.
      • ii. Installation data file is auto-generated in ePic.
  • 5. Download installation data, images, and modules to factory
    • a. Description
      • i. Factory engineer downloads required files from ePic or receives them by disk.
      • ii. Factory engineer deploys the files to manufacturing servers.
    • b. Inputs
      • i. Notification email of updated installation data.
    • c. Outputs
      • i. Factory has up to date BOM information and all required images and modules.
    • d. System Interactions
      • i. Factory engineer downloads or receives latest version of installation data file.
      • ii. If the factory receives files by network, the factory file store system automatically downloads required images and modules and removes obsolete files.
      • iii. If the factory receives files by disk, the factory engineers load the files manually into the local factory file store. 3.3 Planning

The process outlined in the non-limiting diagram of FIG. 5 may be carried out in the DB Hero system. This process describes how the software and hardware design processes are integrated in DB Hero.

The process definitions are tailored to capture details relevant to SIFD only. Details of the hardware design process are not captured here.

This process describes how the software and hardware design processes are integrated in DB Hero.

• • 1. Define Series
    • a. Description
      • i. Hardware planners define the series code names and numbers for a given sales cycle.
    • b. Inputs
      • i. The list of new product series to be offered for a given sales cycle.
    • c. Outputs
      • i. Series prototype numbers.
      • ii. Series code-names.
    • d. System Interactions
      • i. Series information is entered into DB Hero.
  • 2. Identify Software Offerings
    • a. Description
      • i. The planner or program manager defines the software strategy for a given sales cycle. This strategy does not yet specify which software offerings will be made at a series level.
      • ii. Sony and 3^rd party software offerings that may be carried over from a previous cycle are identified.
      • iii. New Sony and 3^rd party software offerings are identified.
      • iv. Updates to existing specifications are made if required.
      • v. New specifications are added to classes if required.
    • b. Inputs
      • i. Previous cycle 3^rd party vendor software items.
      • ii. Previous cycle Sony software items.
    • c. Outputs
      • i. The tentative list of 3^rd party and Sony software offerings for the given sales cycle.
    • d. System Interactions
      • i. None.
  • 3. Define Classes and Specifications
    • a. Description
      • i. A “Class Definition Committee Meeting” is held multiple per year. The purpose of each meeting will be to define the software classes and their contents (specifications) to be used two sales cycles later. Hardware classes are defined separately.
      • ii. The range of potential software offerings is defined for the given sales cycles as a set of classes and specifications. Offerings for individual product series will not be defined at this point.
      • iii. The classes and specifications defined are global and commonly used across all regions. The class structure captures how the various software items will be offered to the customer.
      • iv. Specifications for individual software items, if known, are identified and associated with classes.
    • b. Inputs
      • i. Previously defined classes and specifications.
      • ii. New class definition ideas.
    • c. Outputs
      • i. Class Names.
      • ii. Specification Names (e.g. class contents).
      • iii. Class/Specification relationships.
    • d. System Interactions
      • i. A DB Hero administrator enters the classes into DB Hero. Users cannot input classes due to limitations of DB Hero Software.
      • ii. A Product Planner or Program Manager enters specification information and class/specification relationships into DB Hero.
  • 4. Define Planning Level Parts (e.g. royalties, catalogue, etc.)
    • a. Description
      • i. Software offerings are broken down into individual parts. Offerings which have varying royalty, licensing, or catalogue requirements must be broken up into discrete items.
      • ii. These parts will be associated with classes and specifications during the block definition process at a later time.
      • iii. These parts will later be used in ePic to help create SW BOMs.
    • b. Inputs
      • i. Software offerings.
      • ii. Royalty, licensing, and catalogue requirements.
    • c. Outputs
      • i. List of software Parts.
    • d. System Interactions
      • i. The parts identified are registered in DB Hero.
  • 5. Define Offerings Structure and Constraints
    • a. Description
      • i. Software offerings (classes and specifications) are associated with individual series. The resulting structure is called the Config Range. The Config Range is global in scope and contains all product offerings, both hardware (HW) and software (SW), for all regions.
      • ii. Constraints on the offering range are identified as necessary for engineering or business reasons. These constraints are also global in scope; they do not reflect regional constraints. Regional constraints will be implemented in regional CTO sales systems or implicitly included in fixed configurations defined from the Config Range.
    • b. Inputs
      • i. The software offerings (classes and specifications) identified for the given sales cycle.
    • c. Outputs
      • i. Offering strategy, structure, and constraints, series by series.
    • d. System Interactions
      • i. The classes selected are associated with a series and are entered in DB Hero resulting in the Config Range.
      • ii. Constraints are defined in DB Hero as rules against the Config Range.
  • 6. Define Block Structure
    • a. Description
      • i. Block structure definitions are used to generate the component structure. Users group classes into blocks and define which classes are dependent on each other and which blocks are “base blocks.”
    • b. Inputs
      • i. Config Range for each series.
    • c. Outputs
      • i. Block structure of the classes for a given series.
      • ii. Component Structure without parts.
    • d. System Interactions
      • i. The blocks defined are entered in DB Hero.
      • ii. Classes are associated with the blocks per the defined block structure in DB Hero.
      • iii. “Dependency” and “Base Block” flags are set as required.
  • 7. Confirm Component Structure
    • a. Description
      • i. Program Manager or Product Planners confirm components without parts whether these components are made in just proportion—without exaggeration or omission—for their region.
      • ii. Confirmation of components is done by each region.
    • b. Inputs
      • i. Component Structure without parts.
    • c. Outputs
      • i. Confirmation List.
    • d. System Interactions
      • i. None. Notes:
  • 1. DB Hero series can be made “cycle-less” by adding an additional class specifying product cycle or software revision for integrators to manage software offerings from series to series. 3.4 Engineering Software BOM Creation—Now referencing the non-limiting process outlined in FIG. 6.
  • 1. Transfer Parts and Series info to ePic
    • a. Description
      • i. The parts and series defined DB Hero are transferred to ePic.
    • b. Inputs
      • i. Series and Parts registered in DB Hero.
    • c. Outputs
      • i. Series and Planning Parts registered in ePic.
    • d. System Interactions
      • i. Scheduled system process and/or user initiated process.
  • 2. Planning BOM Creation
    • a. Description
      • i. Parts required for each block are added to the block structure for a series. The parts are assigned to each class/specification pair in a block based on which parts are required for that option. This structure is called the “Design Structure.”
      • ii. When the Design Structure is complete, DB-Hero generates the Component BOM, e.g. Component Structure, for the series.
    • b. Inputs
      • i. Block Structure.
      • ii. Parts.
    • c. Outputs
      • i. Component Structure with parts.
    • d. System Interactions
      • i. Parts are associated with specs via a block/spec pivot table DB Hero.
  • 3. Define engineering image and module parts as required
    • a. Description
      • i. Developer or integrator defines engineering parts in ePic as required. ePic engineering parts can include many things, including images, modules, recovery media sets, documentation, etc.
      • ii. Developer defines technical attributes of each part. (See ePic attributes below for more details.)
      • iii. Developer optionally specifies the target series for this part. One or more target series may be specified.
      • iv. Developer specifies the languages to be supported by this part.
      • v. Developer specifies dependencies between this part and other parts.
      • vi. Developer provides installation instructions, including installation order.
      • vii. Once these parts have been fully registered in ePic, associated software releases for the standalone parts can be checked-in.
      • viii. Composite parts, e.g. images, multipart modules, and recovery media, will require BOMs to be created before automated building can begin.
    • b. Inputs
      • i. Information from hardware engineers, software engineers, and planners.
    • c. Outputs
      • i. List of parts with their associated attributes and target series/language information.
    • d. System Interactions
      • i. Parts, attributes, and target series/language information is entered into ePic via user interface.
  • 4. Associate planning level parts with engineering parts
    • a. Description
      • i. Developer/Integrator associates planning parts from DB Hero with one or more engineering parts defined in ePic.
      • ii. This activity is done for any planning parts that correspond to ePic engineering parts.
      • iii. These associations will be used later to generate the “Series Software BOM”.
    • b. Inputs
      • i. DB Hero part list (planning parts).
      • ii. Engineering parts as defined in ePic.
    • c. Outputs
      • i. Planning to engineering part associations.
    • d. System Interactions
      • i. The associations will be created via ePic user interface.
  • 5. Define image & module contents where required
    • a. Description
      • i. Developer/integrator creates individual image/module BOMs by defining relationships between parts. The Engineering Parts to be included in a given image or module are specified as the children of the top level part.
    • b. Inputs
      • i. Parts completely defined in ePic.
    • c. Outputs
      • i. Image/module BOMs.
    • d. System Interactions
      • i. Developer/Integrator creates BOM structures in ePic using functions specific to each part type, e.g., “Image Planner”, “Media Planner”, “Module Planner.”
  • 6. BOM Confirmation
    • a. Description
      • i. Program Managers or Product Planners confirm component structure.
      • ii. Confirmation of component structure is done by each region.
    • b. Inputs
      • i. Component Structure, including parts.
    • c. Outputs
      • i. Confirmation list or minutes of meeting.
    • d. System Interactions
      • i. None.
  • 7. Transfer Component BOM to ePic
    • a. Description
      • i. The component BOM for a given series is transferred to ePic.
    • b. Inputs
      • i. DB Hero Component BOM.
    • c. Outputs
      • i. Component BOM registered in ePic.
    • d. System Interactions
      • i. Scheduled system process and/or user initiated process.
  • 8. Create Series Software BOM
    • a. Description
      • i. The “Series Software BOM” is a detailed BOM containing all the software releases assigned to a given product series and their relationship to DB Hero Component part numbers. It represents all the software releases (image, module deliverables) that could be installed on a unit and not the software BOM for a specific configuration.
      • ii. This BOM is initially generated automatically based on the target information of engineering parts, engineering part associations with planning parts, and the DB Hero Component BOM. The user can then make changes before the BOM creation process is complete.
      • iii. This data will be combined with recovery and installation data to create an installation data file for the factory.
      • iv. After initial generation, this BOM may be manually modified in the system to manage exceptions/limitations of software releases that are not covered by basic assignment to series and languages or DB Hero constraints.
    • b. Inputs
      • i. Image/module target series information.
      • ii. Planning part/engineering part associations.
      • iii. DB Hero Component BOM.
    • c. Outputs
      • i. Series Software BOM.
    • d. System Interactions
      • i. User will create Series SW BOM using a wizard.
      • ii. Series Software BOM may be edited via ePic UI. 3.5 Software Development—Now referencing the non-limiting process outlined in FIG. 7.
  • 1. Register DB Hero Part
    • See section 7.3, step 4.
  • 2. Transfer Parts to ePic
    • See section 7.4, step 1.
  • 3. Register Part (ePic)
    • See section 7.4, step 3.
  • 4. Associate Planning Parts with Engineering Parts
    • See section 7.4, step 4.
  • 5. Develop Software Module
    • a. Description
      • i. Software Developer codes software module.
    • b. Inputs
      • i. Part definition and technical attributes as specified in ePic.
    • c. Outputs
      • i. Packaged software module with all required installation scripts.
    • d. System Interactions
      • i. None.
  • 6. Check-in Software Module
    • a. Description
      • i. Developer checks-in a software build.
      • ii. Developer updates technical attributes as required. These attributes include installation details, supported languages and other technical information about the release.
      • iii. Developer logs release notes.
    • b. Inputs
      • i. Packaged software module with all required installation scripts.
    • c. Outputs
      • i. Module is stored in the ePic file store.
      • ii. Technical information and release notes stored in ePic.
    • d. System Interactions
      • i. The module check-in procedure will be initiated via ePic user interface or client utility.
      • ii. Files will be uploaded to a local file store, should they be available. If the files represent a module or application, they will be replicated automatically to other file stores. If files represent an image, they will not be replicated to other file stores unless other system users request the replication. 3.6 Software Integration—Now referencing the non-limiting process outlined in FIG. 8.

ePic system interface can engage each regional build tool implementation.

• • 1. Extract Build Info
    • a. Description
      • i. Integrator initiates build process. Build tools gets build data from ePic to be used as input to the build tools.
    • b. Inputs
      • i. ePic image BOM and technical attributes.
    • c. Outputs
      • i. Build data formatted generically.
    • d. System Interactions
      • i. Each regional build system will interface with ePic to obtain image BOMs and software parts.
  • 2. Build Image
    • a. Description
      • i. Image is constructed using build tools.
    • b. Inputs
      • i. Build data extracted from ePic.
    • c. Outputs
      • i. Image files and additional data to be stored in ePic.
    • d. System Interactions
      • i. None.
  • 3. Check-in Image
    • a. Description
      • i. Integrator checks-in image files to ePic.
    • b. Inputs
      • i. Image files and additional data to be stored in ePic.
    • c. Outputs
      • i. Image files are store in the ePic file store and relevant data is updated.
    • d. System Interactions
      • i. Information required for check-in will be entered manually into ePic via UI or supplied by the build system via an interface to ePic.
      • ii. Image files are uploaded to local file store as part of check-in function. 3.7 Test Management and Defect Tracking 3.8 Factory Deployment 3.8.1 Online Factory Deployment Process—Now referencing the non-limiting process outline in FIG. 9.
  • 1. Release to Manufacturing
    • a. Description
      • i. Program Manager releases a series to manufacturing. This is done at for a Series/LangRegion combination.
      • ii. The system performs a number of sanity checks:
        • 1. Ensure that all SW releases are Golden Master or Release Candidates.
        • 2. Ensure that releases exist in the system for the selected LangRegion.
    • b. Inputs
      • i. Series SW BOM.
    • c. Outputs
      • i. New snapshot of RTM'ed Series SW BOM.
    • d. System Interactions
      • i. PM issues RTM in ePic.
  • 2. Generate Installation Data File
    • a. Description
      • i. The system updates the Installation Data File for the RTM'ed releases.
    • b. Inputs
      • i. Series Software BOM.
      • ii. Software release attributes.
    • c. Outputs
      • i. Updated installation data file.
    • d. System Interactions
      • i. None. This is an automated ePic process.
  • 3. Notify Factory Engineers
    • a. Description
      • i. ePic notifies factories that installation data has been updated. Only factories that are affected should be notified.
    • b. Inputs
      • i. Changed Installation data file.
    • c. Outputs
      • i. Email notification message.
    • d. System Interactions
      • i. None. Automated ePic process.
  • 4. Download Installation Data File
    • a. Description
      • i. Factory Engineer downloads the installation data file from ePic.
    • b. Inputs
      • i. Notification email.
    • c. Outputs
      • i. Latest installation data file.
    • d. System Interactions
      • i. Initiate update of installation data file for the Series/LangRegion via file store function.
  • 5. Download Image and Module Files.
    • a. Description
      • i. The factory file store is updated with the latest image and module files.
    • b. Inputs
      • i. Installation data file.
    • c. Outputs
      • i. New required images and modules are downloaded to local file store.
      • ii. Obsolete images and modules are deleted from local file store.
    • d. System Interactions
      • i. Initiate update of image/module releases for the Series/LangRegion via file store function.
  • 6. Place order (NOTE: This step does not involve interaction with ePic. It is depicted here to show the order process relative to factory deployment for a CTO sales process).
    • a. Description
      • i. Customer places an order on a sales system.
    • b. Inputs
      • i. Customer CTO choices or Fixed SKU selection.
    • c. Outputs
      • i. Configuration as a list of DB Hero components.
    • d. System Interactions
      • i. Customer places order in sales system.
      • ii. Sales system or order management system passes order on to factory shop floor control system.
      • iii. Factory shop floor system delivers list of components to installation tools.
  • 7. Install Software
    • a. Description
      • i. The installation data file and list of components in a file for the configuration are provided as inputs to the installation tools.
      • ii. The installation tools automatically install required software. See section 7.9 for further details.
    • b. Inputs
      • i. Configuration of DB Hero component part list.
      • ii. Installation data file from ePic.
    • c. Outputs
      • i. Log data file.
    • d. System Interactions
      • i. Installation tools are executed via automated factory process.
      • ii. Log file must be collected to a central location (should be implemented in factory process).
  • 8. Deliver Log data to GARATA
    • a. Description
      • i. Log data file generated during the installation process is delivered to GARATA for loading into the database.
    • b. Inputs
      • i. Log file from installation process.
    • c. Outputs
      • i. Log file stored in GARATA or other data warehouse system.
    • d. System Interactions
      • i. Log file should be delivered to appropriate Sony server by FTP or other means.
      • ii. Files should be loaded into a database. 3.8.2 Offline Factory Deployment Process is shown in FIG. 10. 3.8.3 Running Change Process

This section describes how running changes would be issued using ePic. This is the VOA EPC process adapted to ePic functionality.

3.8.3.1.1 Purpose

To facilitate, review and implement any Engineering Processing Changes (EPC's) to projects after initial RTM has been issued.

3.8.3.1.2 Definitions

EPC-A: A running change in which existing software on the Series Software BOM RTM snapshot is patched in the manufacturing process. These are deployed as modules of type EPC. There are two types of EPC modules:

• • Temporary—Applied during imaging and “thrown away”. Not in HDD recovery partition.
  • Permanent—Applied during imaging and “kept”. Copied to the HDD Recovery Partition.

EPC-M: A running change in which a foundation image or module is added/changed/deleted to/from the RTM snapshot of a Series SW BOM.

3.8.3.1.3 Deliverables

• • EPC Notification—an automatic email triggered when a program manager re-issues an RTM.
  • EPC Executable—module checked-in to an ePic file store and distributed using online (network) or offline (media) delivery methods.
  • Updated Installation Data File (IDF).
  • Testing Result (Product Quality Group).
  • Testing Result, if applicable (Manufacturing Quality Group).
  • Date EPC was implemented (Manufacturing)—relevant data should be delivered to GARATA. 3.8.3.1.4 Participants
  • Program Management Representative
  • Software Integration Representative
  • Quality Group Representative
  • Sustaining Group Representative
  • Application Champion or other applicable group representative
  • Manufacturing Representative 3.8.3.1.5 Roles & Responsibility
• 1. Program Manager—Initiates EPC request, facilitates the documentation, posting and announcement of EPC release. Issues RTM in ePic to release the IDF and images/modules.
• 2. Software Integration Representative—Creates executable, checks in executable to ePic, announces release.
• 3. Quality Group Representative—Tests and verifies EPC on applicable models.
• 4. Manufacturing Representative—Tests and verifies EPC on applicable models, if applicable. Implements EPC and provides date of when EPC was implemented. 3.8.3.1.6 Process
• 1. Program Manager will email a software integration representative for an EPC request.
  • a. Email should appropriate documentation: issue(s), resolution, applicable models.
• 2. Software Integrator will create EPC module or replacement image module. This may also be performed by the developer.
  • a. New release will be checked-in to ePic.
  • b. Appropriate changes will be made to the Series SW BOM template.
  • c. New snapshot of the Series SW BOM Template will be created and flagged as a release candidate (RC).
  • d. Quality group will be notified.
• 3. Quality member tests software module.
  • a. Test strategies are updated.
  • b. Testing is performed and test results logged.
  • c. If testing fails Integrator is notified and steps from #2 repeated.
  • d. If testing is successful all interested parties are notified.
• 4. Program manager issues an RTM for each applicable Series/LangRegion in ePic.
  • a. System sends running change notification to applicable persons.
• 5. Installation data file and new release(s) are delivered to factory.
  • a. Online or offline factory deployment methods documented above are used to deploy EPC.
• 6. If applicable, factory quality group tests new deliverables.
  • a. If testing fails, interested parties are notified and steps from #2 repeated.
  • b. If testing succeeds, interested parties are notified.
• 7. Factory Engineer deploys new deliverables are deployed in production environment.
  • a. Data concerning which units have the EPC applied is collected (from installation tool log data) and delivered to persons responsible for loading data into GARATA. 3.9 Installation

The installation process and tools will be common for all QA, Factory, and Recovery applications and is in reference by the non-limiting process of FIG. 11.

• • 1. Generate Software Release List
    • a. Description
      • i. The list of DB Hero component part numbers representing a configuration are converted into a list of software releases.
      • ii. This step can be skipped and process can begin from step 2 if a valid software release list has been generated by other means.
    • b. Inputs
      • i. Configuration (DB Hero component part list).
      • ii. Installation data file from ePic.
    • c. Outputs
      • i. List of software releases.
    • d. System Interactions
      • i. Installation tools function.
  • 2. Generate Recovery Key
    • a. Description
      • i. A list of software releases is used to generate a MCode.
    • b. Inputs
      • i. Software release list.
      • ii. Installation data file.
    • c. Outputs
      • i. Encrypted MCode.
    • d. System Interactions
      • i. Installation tools function.
  • 3. Write Recovery Key to DMI
    • a. Description
      • i. The Encrypted MCode is written to DMI.
    • b. Inputs
      • i. Encrypted MCode.
    • c. Outputs
      • i. MCode stored in DMI.
    • d. System Interactions
      • i. This is done using DMI writing tools.
  • 4. Partition Hard Drive
    • a. Description
      • i. The hard drive is partitioned according to data in the installation data file.
    • b. Inputs
      • i. Installation data file.
      • ii. Series and LangRegion.
    • c. Outputs
      • i. Hard drive is partitioned appropriately.
    • d. System Interactions
      • i. Installation tools output a list of partitions with sizes.
      • ii. Partition tools are used to partition the hard drive as part of factory process.
  • 5. Copy required file to recovery partition (HDD Recovery Only).
    • a. Description
      • i. If the series uses HDD Recovery partition, the recovery partition is prepared by the installation tools:
      • 1. The WinPE recovery partition is written to P1.
      • 2. Images modules and required data are copied to the recovery partition.
      • 3. Installation data file (or a portion of it) are copied to recovery partition.
    • b. Inputs
      • i. Software release list.
      • ii. Installation data file.
    • c. Outputs
      • i. Recovery partition is completely setup.
    • d. System Interactions
      • i. Installation tools function.
  • 6. Prepare Customer Partition(s)
    • a. Description
      • i. If the series uses HDD recovery, then the customer partitions are prepared by initiating the user recovery process in “unattended mode.”
      • ii. If HDD recovery is not used, the installation tools prepare customer partitions directly.
    • b. Inputs
      • i. Installation Data File.
      • ii. Software Release list.
    • c. Outputs
      • i. Customer partitions are prepared.
    • d. System Interactions
      • i. Installation tool function.
  • 7. Generate Log Data
    • a. Description
      • i. Data about the releases installed are stored in a file suitable for loading into GARATA or any other data warehouse.
    • b. Inputs
      • i. Data about installation activities.
      • ii. Information about the unit (S/N, service tag, MCode, etc).
    • c. Outputs
      • i. File containing log information.
    • d. System Interactions
      • i. Creation of the log file is an installation tools function.
      • ii. The log file must be collected and delivered to appropriate system as part of factory process. Within this process flow, three use cases for installation tools will be supported:
  • 1. Installation using a list of DB Hero component part numbers.
    • a. Convert list of component part numbers to list of software releases.
    • b. Generate MCode using list of software releases.
    • c. Install software.
  • 2. Installation using a MCode.
    • a. Generate list of software releases using MCode.
    • b. Install software.
  • 3. Installation using a list of releases.
    • a. Generate MCode (optional).
    • b. Install software.
  • Factory Installation will use method #1 only. For retail models the DB Hero component part number list can be prepared offline and distributed at RTM time.
  • Recovery Media Sets (RDVD's or Fulfillment Media) can use method #2.
  • HDD Recovery and recovery using customer created media can use method #3.
  • Test system preparation can use all three methods. 3.10 Recovery 3.10.1 Recovery Media Preparation
  • 1. Define recovery media engineering parts.
    • a. Description
      • i. Engineering parts for fulfillment recovery media are defined in ePic as “Recovery Media Sets.” Engineering parts for user created recovery media are not defined.
      • ii. NOTE: ePic need not be aware of specific recovery media types (SRCD, ARCD, etc.). This can be managed by recovery media creation tools. ePic also need not support media layout functions; eventually only RDVD's with a single set of recovery tools and factory distribution media need be supported.
    • b. Inputs
      • i. Series Software BOM snapshot.
      • ii. Additional Engineering parts required for recovery media.
      • iii. Media set specific information.
    • c. Outputs
      • i. Recovery media BOM in ePic.
    • d. System Interactions
      • i. User defines recovery media using “recovery media planner” in ePic.
  • 2. Generate MCode Specification.
    • a. Description
      • i. System calculates MCode Specification. An MCode Specification (or MCode Spec) is a set of bit/release relationships. More than one release can be assigned to one bit.
    • b. Inputs
      • i. Series Software BOM.
      • ii. Component/Release Mappings.
    • c. Outputs
      • i. MCode Specification.
    • d. System Interactions
      • i. Automated process with possible manual intervention.
  • 3. Create Recovery Media.
    • a. Description
      • i. Recovery Media (AKA, Fulfillment Media or RDVD's) are created using external tools.
      • ii. Tools use BOM's created in ePic.
      • iii. Optionally, media images can be checked into file store as a software release.
    • b. Inputs
      • i. Recovery Media BOM and attributes as defined in ePic.
    • c. Outputs
      • i. Physical Recovery Media.
      • ii. Optionally, media images.
    • d. System Interactions
      • i. Media creation tools interface with ePic to retrieve Recovery Media BOM and part attributes.
      • ii. Media images optionally checked-in to ePic file store. 4 Interactions with other systems. 4.1 Overview

ePic will interface with many systems and tools. This chapter summarizes those interfaces.

• • 1. DB Hero
    • a. DB Hero may be the global product data management system (PDM) for the VAIO business.
    • b. ePic can gather data from DB Hero to be used in BOM creation and factory deployment.
    • c. ePic can interface directly to DB Hero to retrieve needed data. No data need be fed back into ePic.
  • 2. Image/Module Build Tools
    • a. Tools used to build image (or module) releases and check them into the ePic file store.
    • b. ePic will export BOM data to these tools and provide functionality for checking in binary releases.
    • c. Data and functionality will be exposed to tools via an interface DLL.
  • 3. Test System Preparation Tools
    • a. Tools used to install software on systems to be used for testing.
    • b. ePic will expose BOM data for pre-integration testing and installation data files for post-integration testing.
    • c. Data and functionality will be exposed to tools via an interface DLL.
  • 4. Media creation Tools/Systems
    • a. Tools used to create recovery and factory media. Similar to image building tools.
    • b. ePic will export BOM data to these tools and provide functionality for checking in media image releases.
    • c. Data and functionality will be exposed to tools via an interface DLL.
  • 5. VELSUN
    • a. Global sustaining defect tracking system.
    • b. ePic will provide functionality for exporting defects to this system.
  • 6. VALSUN
    • a. Software development defect tracking system.
    • b. ePic will provide functionality for exporting defects to this system.
  • 7. ESG
    • a. VOE sustaining system.
    • b. ePic will export software parts and BOM data and defects to this system.
  • 8. OASIS
    • a. VOA tool to create MCode writing floppy disks.
    • b. Used by many Sony personnel to image systems with Recovery Media.
    • c. ePic will pass simple parameters to this system using an HTTP GET/POST request. 4.2 A Project Peripheral Components

Several components external to the core ePic system will be developed by Neusoft, VOA, and VBD to facilitate these system interactions. Detailed requirements for these components are captured throughout chapter 9.

• • ePic Interface DLL
    • Win32 library.
    • Detailed requirements in chapter 9.14.
  • Installation Tools
    • Installation tools used in for testing, factory installation, and recovery media
    • Tools use the ePic installation data file, DB Hero component list, and/or software release list as inputs.
    • Tools output data suitable for import to GARATA.
  • Test System Preparation CD
    • WinPE based CD may be used to install software releases managed by ePic on test systems to be developed by SIT.
    • Current US implementation, called MINDS (Modular Installation Network Download System), adapted to meet requirements interacts with ePic using the ePic Interface DLL and utilize the Installation Tools.
  • MCode Encoder/Decoder DLL
    • Mcode encoding/decoding libraries adapted to work with ePic Installation Data Files by SIT.
    • This library used by both ePic and Installation Tools for all MCode encoding/decoding requirements.

In addition to the above components, build systems interface with ePic and use ePic data (see chapter 12). SIT's build system (Magellan) will interface with ePic using the ePic Interface DLL. SDNA will use the build system provided by VOA.

5 Requirements

5.1 Key Terms

The following terms are important for understanding requirements in this section. Additional terms are defined in chapter 13.

• LangRegion: Term used to describe the combination of an ISO-639 language code with an ISO-3166-1 country code. (For example, “es_SP”, “es_MX”, “jp_JP”, “en_UK”, “en_US”, etc.). ePic and DB Hero will use LangRegion codes to define which language/region combo is to be supported by a software release.
• Engineering Part: All software, documentation, and media sets are defined as “engineering parts” in ePic. Each engineering part can have many software releases associated with it.
• Major Version: Attribute of an Engineering Part referring to the Major Version of a software item. Major Version is treated like an individual entity in ePic for certain functions.
• Release: A release corresponds to a specific set of files and directories checked into ePic for a specific engineering part. Releases can satisfy one or more LangRegions.
• Planning Part: ePic term for software parts defined in DB Hero.
• Packaged Software: Software which has been packaged using WISE, Install Shield or some other installer technology (whether it was packaged by Sony or an ISV). Packaged Software is NOT the same as a module.
• Foundation Image: Also known as “Base Image”. This is a set of files includes the OS and any software items (drivers, utilities, etc.) the integrator chooses to include. Recovery related components (PAC files, data files, etc.) are also considered a part of the Foundation Images. Module: Software packaged with WISE which is suitable for use by factory installation tools (the installation is silent/unattended; the installation can be verified by install tools; the module is BIOS locked; etc.). ePic will support three types of modules: “Module”, “X-Module”, or “EPC.” “Modules” install in a single configuration. “X-Modules” are can install different configurations depending on target system characteristics. “EPC's” (Engineering Process Changes) are used for patches or running changes. General

Requirements that apply to all aspects of the system are listed here.

5.1.1 Usability/Performance

ID	Description	Comments	Priority
GEN-2.1	All system data should be stored and presented in
	double-byte characters.
GEN-2.2	All user interface prompts, command line tools, and	No internationalization
	online documentation will be in English only.	of UI's!
GEN-2.3	System should perform adequately for users in
	remote regions so that work schedules are not
	impacted by network speeds.
GEN-2.3.1	Page views via the Sony intranet shall take no more
	than 10 seconds per view.
GEN-2.3.2	Uploads/downloads between file stores on the Sony
	intranet should occur at a minimum rate of 450 MB
	per hour (1 Mbps).
GEN-2.4	Online user documentation should be available.

5.1.2 Availability

ID	Description	Comments	Priority
GEN-3.1	The main system (ePic) must be available to all Sony
	users 24 hours a day via intranet.
GEN-3.2	Manufacturing deliverables should be available to 3rd	If network delivery is available, it is
	parties.	preferred, but an offline delivery
		method could also be used.
GEN-3.2.1	Only RTM'ed or Test RTM'ed items should me
	made available to 3rd party factories.
GEN-3.2.3	Pre-release deliverables may be distributed to 3rd
	parties (for example, for validation purposes). Such
	deliveries should be limited to only what is required
	to ensure efficient use of resources.
GEN-3.3	Release check-in functionality should be available to	Per 2005-6-30 BRD feedback from
	3rd parties not on the Sony Network.	VBD.

5.1.3 Support

ID	Description	Comments	Priority
GEN-4.1	Live support for the system must
	be available to all users 24 hours a day.

5.1.4 Security

ID	Description	Comments	Priority
GEN-1.1	Authentication policy as specified by SGS,	The SGS operated
		“Common Authentication”
		system will be used for
		authentication for all users.
GEN-1.1.1	System should be accessible only to named users.
GEN-1.2	Authorization policy.
GEN-1.2.1	System authorization will be role/resource based.
	See table in 9.2.4.1 for role to resource mappings.
GEN-1.2.2	Authorization of the web-based application will be
	performed at a screen level.
GEN-1.2.3	Users can be assigned to one or more roles.
GEN-1.2.4	3rd party users can only access data for series which
	they have been explicitly authorized to view.
		Requirements to be
		rovided by SGS.

5.1.4.1 Role to Resource Mapping

Each instance of an entity can also have an “owner list”. Users with permissions to create/edit and entity can add other users to the owner list. Users on the owner list can edit that instance of the entity regardless of their assigned system role(s).

	Role
								3rd
						Project Test	Factory	Party
Resource/Function	PM/Planner	Developer	Integrator	Tester	Test Lead		Engineer	User*	Admin
BOM-1.1: Manage series information.	X		X						X
BOM-1.2: Manage planning parts.	X	X	X						X
INT-1.12: Create/edit SKU's.		X	X						X
BOM-1.9: Create/edit sample SW BOMs		X	X						X
(release lists).
BOM-1.3/DEV-1.1: Manage engineering		X	X						X
parts.
BOM-1.4: Manage images.			X						X
BOM-1.6: Create series SW BOM.			X						X
BOM-1.7: Set dependencies.		X	X						X
BOM-1.8: Create/edit groups.			X						X
DEV-1.2: Check-in SW releases.		X	X					X	X
MFG-1.1/MFG-1.2: Issue RTM/Test RTM.	X								X
Download installation data and binary data for	X	X	X	X			X	X	X
SW releases.
Download latest DB Hero data into ePic.			X						X
Add users, set privileges.									X
Manage 3rd party access.									X
Set champion of parts.	X								X
Mass edit entities.									X
Create/edit Test Case.					X	X			X
Create/edit Test System.				X	X	X			X
Create/edit Test Strategy.					X	X			X
Edit Test Case Result.				X					X
Create/Edit Defect (except for status and	X	X	X	X	X	X	X	X	X
resolution).
Create/Edit Defect (set status and resolution,		X	X	X	X	X			X
except for “fix-verified” resolution).
Create/Edit Defect (all attributes).				X	X	X			X
Defined MDA/Benchmark categories/keys for									X
test cases.
Edit miscellaneous IDF Data			X						X

• • Third party users can only view data for Series they have been authorized to view (see section 9.13.1, requirement ADM-1.3, “Manage 3rd party data access.”).
  • For VBD/SDNA, software project leaders (SPL's) will be assigned both the “PM/Planner” and “Developer” roles.

5.1.5 Legacy Data

ID	Description	Comments	Priority
GEN-5.1	For all groups who require any legacy data to be	Data will be manually entered to assist in
	loaded, legacy data will be manually entered and	training users and quality testing.
	software releases manually checked-in.	ePic schema is significantly different from
		any existing systems. Data import may be
		impractical.

5.2 Planning

These are requirements for the “high-level planning” functions implemented in DB Hero that impact SIFD. Only business rules or functional requirements which are necessary to ensure proper SIFD functionality are captured here.

5.2.1 Usage Requirements

ID	Description	Comments	Priority
		Regional differentiation of software offerings
		will be managed in ePic.
		This is generically solved by implementing
		DB Hero “spec to component relationship”
		functionality (see section 9.6, INT-1.9).

5.2.2 Business Rules

ID	Description	Comments	Priority
PLAN-2.1	A special DB Hero Class	ePic must use this
	(e.g., Product Cycle or SW	to revise software
	Revision) must be introduced	from cycle-to-cycle.
	into a Series Config Range in
	order for the Series to be
	“cycle- less.”

5.3 Engineering Software BOM Creation

Requirements for the “low-level planning” functions and software BOM creation in ePic are listed here.

The following is a graphical representation of an ePic Engineering Part to help readers understand requirements:

5.3.1 Usage Requirements

ID	Description	Comments	Priority
BOM-1.1	Manage series information.
BOM-1.1.1	A series can be designated as active or inactive to		1
	indicate whether the series is EOL.
BOM-1.1.2	Product cycle (SP05, SU05, FA05) must not be	Since many products can be in production	1
	required to organize data in the system. Product	for many cycles, the active/inactive
	cycle will be an attribute of a series.	designation will be used in place of product
		cycle.
BOM-1.1.3	Set series attributes.		1
BOM-1.2	Manage planning parts.		1
BOM-1.2.1	Associate engineering parts with planning parts.	This information will be used to generate a	1
	Associations can be made to part name or a part	“Series Software BOM”.
	name and major version.
BOM-1.3	Manage engineering parts.		1
BOM-1.3.1	Create/edit engineering part.		1
BOM-1.3.2	Set part type. The following part types will be	See ePic attributes in section 10.4.	1
	supported by ePic:
	1. Foundation Image
	2. P1 (recovery) Image
	3. Monolithic Image
	4. OS Setup
	5. Application
	6. Driver
	7. Online Documents
	8. OS Add-on
	9. Module
	10. Internal Tools
	11. BIOS/Firmware
	12. Recovery Media Set
	13. Factory Media Set
	14. Other
BOM-1.3.3	Set part attributes.	See ePic attributes in section 10.4.	1
BOM-1.3.4	Engineering parts can be composite parts, consisting	This applies to not just images, but modules	1
	of several other parts, or a single standalone part.	and other part types as well.
BOM-1.3.5	Engineering parts can be associated with planning	More fine grained associations are possible	1
	parts (so that series associations can be made via the	by editing the “Series Software BOM
	DB Hero Component BOM), or they can be	Template.” LangRegion associations to
	manually associated with individual product series	releases will be handled at module check-in
	(for example, manual association would be made for	time.
	hardware specific software items).
BOM-1.3.5.1	User may also specify “all series” so that the part	So if new series are added after this is set,	1
	would be used for all active series existing in the	they would still pick up this part in their
	system at any moment in time.	BOMs.
BOM-1.3.6	The LangRegions to be supported by a part can be		1
	specified at part creation time.
BOM-1.3.7	One or more software releases can be associated with		1
	each part. Each software release can be associated
	with one or more LangRegions.
BOM-1.3.8	For each LangRegion, one of the associated releases	The default release can be manually	1
	can be flagged as “default.” The default release will	overridden after Series Software BOM
	be used for “Series Software BOM” creation.	Template generation (see BOM-1.6.2).
BOM-1.3.9	Electronic data files for printed documentation can be	Per 2005-6-30 BRD feedback from VBD.	1
	defined as engineering parts and stored in ePic. No
	additional functionality specific to these items is
	required.
BOM-1.3.10	Installation priority of the part can be specified	Satisfies VBD QA WG requirements 1c.	1
	relative to other part names/major versions as	Installation tools will calculate installation
	“BEFORE” or “AFTER.” The system will not	order for a set of modules at installation
	allow invalid installation order states (e.g., circular	time.
	installation order relationships) to be defined.
BOM-1.3.11	The Bios Lock ID (BLID) must uniquely identify a	Satisfies VBD Factory Install WG	1
	foundation image. This means that relationship	Requirement 1b.
	between BLID and FI will be one-to-one.
BOM-1.3.12	The user can specify whether parts are active or not.		1
	If a user sets a part “inactive” then the system will
	ignore/hide the part in any BOM creation activities.
BOM-1.4	Manage images/modules. Images and modules are	To be implemented as a “Part Registration”	1
	engineering parts which can be final deliverables.	wizard.
BOM-1.4.1	Set image/module type.		1
BOM-1.4.2	Create/edit image/module BOM Template. Each	Composite parts only.	1
	composite engineering part has exactly one BOM
	Template.
BOM-1.4.2.1	Groups, Part Names, Part Major Versions, and/or		1
	Releases can be added to BOM templates.
BOM-1.4.2.2	Auto generate image/module BOM using target		1
	series attribute of parts and groups. User can edit
	auto-generated BOM before it is saved.
	Perform Sanity checks:	The first check is to alert users that items	4
	Ensure items included in template must not be	which are optional for a given series might
	installed individually (use planning part	be included in the foundation image. The
	associations).	system cannot know for sure from the DB
	Ensure dependencies are satisfied.	Hero component structure, but it should
		indicate to the user that an eng. part has
		planning part associations.
BOM-1.4.2.4	Releases flagged as “disabled” cannot be added to a	Per review with SDNA 2005-9-14	1
	BOM template.	(corresponding attribute REL-025 added).
BOM-1.4.3	Snapshot BOM template (Freeze BOM).	NOTE: This requirement applies to Series	1
		SW BOM Templates in addition to
		image/module BOM Templates.
BOM-1.4.3.1	A snapshot contains only software releases		1
	(unspecified releases on the template will be set to
	defaults). Snapshots cannot be edited manually.
BOM-1.4.3.2	All part information at the time of snapshotting is		1
	frozen in a snapshot. Changes made to the main data
	after snapshotting will not be reflected in the
	snapshot.
BOM-1.4.3.3	BOM snapshots are exposed to build tools via the		1
	build tool interface.
BOM-1.4.3.4	A BOM snapshot is retrievable as a file via ePic UI.		1
		Dropped. Satisfied by ePic “group” concept
		described in BOM-1.8..
BOM-1.6	Create Series Software BOM.		1
BOM-1.6.1	System will generate a “Series Software BOM	See requirement BOM-1.8 for definition of	1
	Template”, which consists of the list of specific part	“group”.
	names, major versions, groups and/or releases
	assigned to a series, using DB Hero component
	structure, planning part associations with engineering
	parts, and the properties of engineering parts. The
	system will show default value for unspecified items
	on the template.
BOM-1.6.2	Edit “Series Software BOM Template”. Releases	This function allows special release	1
	can be edited manually.	dependencies/incompatibilities to be handled.
BOM-1.6.3	The Series SW BOM will include mappings from one	Satisfies VBD QA WG requirement 1 g.	1
	or more DB Hero components to one or more ePic
	software releases. See section 9.6, requirement INT-
	1.10.
BOM-1.6.4	Once the Series SW BOM Template is complete, the		1
	user can snapshot the template. A snapshot contains
	only software releases (unspecified releases on the
	template will be set to defaults). Snapshots cannot be
	edited manually.
BOM-1.6.5	All part information at the time of snapshotting is		1
	frozen in a Series SW BOM snapshot. Changes
	made to the main data after snapshotting will not be
	reflected in the snapshot.
	The system will indicate problems to the user when		4
	displaying the Series SW BOM template. Problems
	can be:
	Non-RC/GM releases.
	Target series information in conflict with
	planning part association.
	Dependencies not satisfied.
	No default releases available for a part.
	No releases available for a given
	language.
	Dependencies are not satisfied.
BOM-1.6.7	The system should not allow an “inactive”	Added per review with SDNA 2005-9-14.	1
	part/release to be added to a series SW BOM
	template.
BOM-1.7	Dependencies between engineering part names	Satisfies VBD QA WG requirements 1a and	2
	and/or part name/major versions can be specified.	1b.
BOM-1.7.1	Other parts can be selected and dependencies will be		2
	specified as “DO NOT CARE”, “EXCLUDE”, or
	“REQUIRED.”
BOM-1.7.2	The system will not allow circular dependencies to be		2
	defined.
		Satisfies VBD QA WG requirements 1 g.
		Dropped per review session with VBD 2005-
		9-15.
BOM-1.8	Create edit groups. Groups are user defined lists of	This is an internal ePic concept intended to	1
	engineering part names, major versions, releases, or	allow users to define re-usable collections of
	other groups.	parts. This concept, if used properly, makes
		BOM creation more efficient.
BOM-1.8.1	Groups can be added to composite part BOM	Note that groups are, for the most part,	1
	templates. Changes made to group contents after	functionally equivalent to BOM templates.
	group assignment to a BOM template will be
	reflected on the BOM template.
BOM-1.9	Create edit test software BOM. A test software	Per VBD review 2005-9-15: A facility for	5
	BOM is a manually created list of software releases	creating and sharing test software BOMs
	for a single configuration. The releases must be	must be available in the system.
	listed in proper order of installation (based on	This function will be used by both
	installation priorities specified in the system).	developers and testers. It is the only way to
		create a software BOM in the system before
		a series software BOM has been prepared.
		A test software BOM is, by definition, a
		snapshot. BOM templating functions will
		not be used for test BOMs.
BOM-1.9.1	User can search for and select part names, part		5
	major versions, or releases to be added to a test
	BOM. System will select default release if user does
	not specify a specific release.
BOM-1.9.2	System should provide filtering capabilities to the		5
	user for selecting items for the test BOM.
BOM-1.9.3	System should examine dependencies of the items		5
	selected and automatically add releases to satisfy
	these dependencies.
BOM-1.9.4	User can download file containing the test BOM.		5
BOM-1.9.5	User can save the test BOM in the system, BOM can		5
	be given a name for later retrieval.

5.3.2 User Interface Requirements

ID	Description	Comments	Priority
BOM-2.1	Part Registration Wizard.	Implements the Image	1
		and Module Planners.
BOM-2.1.1	Set general part attributes.		1
BOM-2.1.2	Set type specific part attributes.		1
BOM-2.1.3	Set part dependencies and installation order.		1
BOM-2.1.4	Associate with planning part/set target series.		1
BOM-2.1.5	If part is a composite part, show BOM Template		1
	creation interface (optional).
BOM-2.1.6	BOM snapshotting function (optional).		1
BOM-2.2	Series Software BOM Builder (Wizard).		1
BOM-2.2.1	System generates the series software BOM and		1
	shows it to user with distinctive display of releases
	that fail sanity checks or are marked as special.
BOM-2.2.2	User can edit Series SW BOM.		1
BOM-2.2.3	User can snapshot Series SW BOM.		1
BOM-2.2.4	User can create Component/Release mappings (see		1
	INT-1.10).
BOM-2.3	Entity Editor. Access to all attributes of an entity in		1
	one place.
BOM-2.3.1	Screens must allow all attributes for each major	The same functionality as	1
	system entity to be edited one screen.	the wizard is supplied for
		each entity type.

5.3.3 Business Rules

ID	Description	Comments	Priority
BOM-3.1	Business Rule for Engineering Part Creation
BOM-3.1.1	A new part should only be created for a major
	version release of software. Major version is defined
	as specification change. Iterative releases within a
	major release, to fix defects and such, are called
	Release Versions.
BOM-3.1.2	A part name should include the name of the part
	only, in general terms. For example: Adobe
	Premiere Professional, VAIO Zone, Sonic Stage.
	The major version number is an attribute of the part,
	and can be concatenated for UI and reporting
	purposes. For example, a part can be created with
	the Part Name of “Adobe Premiere Professional”
	and the major version number of “7.1”. The part
	becomes the concatenation of the part name and
	major version number: “Adobe Premiere
	Professional 7.1”.
.BOM-3.1.3	Part names should not contain specific references to
	a series or CTO options. The following examples
	would not be acceptable: “Adobe Premiere 7.1 for
	IRX-3560” or “WinDVD 5.6 for Six Channel
	Speakers.”
BOM-3.1.4	Part names can only contain the characters: a-z, A-Z,	Only pintable ASCII
	0-9, , -, or.	characters (including space)
		should be allowed in part names.
BOM-3.1.5	Major Version Number is a text field, with the same
	character restrictions.
BOM-3.2	Changes to DB Hero controlled entities must be
	made in DB Hero only and then propagated to ePic
	via interface. Entity attributes owned by DB Hero
	must, therefore, not be editable in ePic.

5.3.4 Interface Requirements

ID	Description	Comments	Priority
BOM-4.1	Load series master from DB Hero.		1
BOM-4.2	Load parts master (planning parts) from DB Hero.		1
BOM-4.2.1	Certain classes of hardware parts (HDD's, CPU's,	Hardware parts are required for Test/Defect	1
	etc.) should not be filtered from the master parts list.	management system functions.
	If that is not possible, all hardware parts should be
	loaded and ePic should filter hardware parts from
	UI.
BOM-4.3	Load component structure from DB Hero.		1
BOM-4.4	Load updates to all previously loaded DB Hero data.		1
BOM-4.5	DB Hero interface behavior rules:	BOM-4.5.X applies to all DB Hero interface	2
		requirements.
BOM-4.5.1	DB Hero BOM data can be manually loaded from		1
	into ePic (via ePic UI). Data updates should be
	performed using the most efficient means available.
BOM-4.5.2	Pre DB Hero release BOM data can only be loaded	One button to update all DB Hero data for a	2
	into ePic manually. Initial load of any BOM must be	series is ideal.
	manual.
BOM-4.5.3	After the DB Hero release, structure/part changes	Without ECNs manual load is the only	2
	which generate an ECN are automatically	possibility (except for series and parts,
	implemented in ePic. Revision history is not kept.	whose masters are synced regularly).
BOM-4.5.4	ECNs can be requested by date range. ePic should	Update period should be a configurable ePic	2
	periodically request all ECNs since last update	system option.
	automatically.
BOM-4.5.5	Email and UI notifications will be produced for		2
	software integrators for the following changes to DB
	Hero BOMs:
	Any SW part (planning part) change on
	component BOMs.
	Any changes (HW or SW) to components
	used in component/release mappings.
	Changes to Config Range/Line-up.
BOM-4.5.6	DB Hero data will be loaded into ePic at most once	If users need up-to-date data, they can	1
	per day, and at least once per week.	initiate a manual transfer via ePic UI.

5.4 Software Development

ePic requirements to support developers who use the system are listed here.

The detailed format for software modules is documented separately in a “Modular Specification”.

5.4.1 Usage Requirements

ID	Description	Comments	Priority
DEV-1.1	Engineering part registration (developer specific	See “Software Engineering BOM Creation”	1
	requirements).	for additional information concerning part
		registration.
DEV-1.1.1	The set of LangRegions supported by the module		1
	must be specified.
DEV-1.1.2	The part can be associated with a planning part	See BOM-1.3.5.	1
	and/or target series. Neither is required (though
	warning should be issued if neither is selected).
DEV-1.2	Check-in software release (non-image).		1
DEV-1.2.1	Developer must identify LangRegions supported by		1
	the software release to be checked-in.
DEV-1.2.2	Developer must indicate installation method and		1
	unattended installation command. Alternate
	installation commands may also be entered with
	comments.
DEV-1.2.3	Developer must indicate any special requirements of	These releases will be given special attention	1
	the software release (incompatibilities, special	during “Series Software BOM” creation.
	instructions). System will flag release as having	Can include a flag on release called
	special requirements where appropriate.	“Special” or “Warning.” These releases
		would be called out on part templates and
		snapshots and comment would be displayed.
DEV-1.2.4	Developer must enter release notes. A release note	See attributes in section 10.4 for more	1
	is text entered into ePic. User can append an entry	details.
	to the release note.
DEV-1.2.4.1	Users can download all release note entries in a		1
	single text file via the UI.
DEV-1.2.5	Software item check-in should allow files to be		1
	checked-in to local mirror and uploaded to main store
	asynchronously.
DEV-1.2.6	If the item to be checked in is not an image, it will		1
	automatically be replicated to other file stores. If the
	item is an image, replication will not occur
	automatically. Users can request to the system that
	an image be downloaded to their regional file store.
	via ePic UI.
DEV-1.2.7	The following statuses can be specified for a release:	Satisfies VBD QA WG requirement 1d.	1
	“ES/Test”, “FF”, “Pilot”, “CF”, “RC”, and	Satisfies VBD Factory Install WG
	“GM.”	requirement 2a.
DEV-1.2.8	User can optionally request that the system send the		1
	release email.
DEV-1.2.8.1	Release email address list is a configurable system	This list could also be auto-generated based	1
	item.	on roles.
DEV-1.2.9	User can set a release “inactive.” Inactive releases		1
	cannot be set as “default” and vice versa.
DEV-1.3	Create/Edit Vendor		1
DEV-1.3.1	User can store information about a software vendor		1
	(Name, Address, Contact, Sony Contact).
DEV-1.3.2	Vendor can be optionally associated with an	It is appropriate to include vendor name in	1
	engineering part.	part name and also have a vendor
		association.
DEV-1.4	User can initiate download of any release via ePic		1
	UI.

5.4.2 User Interface Requirements

ID	Description	Comments	Priority
DEV-2.1	Extracting engineering part, release, BOM data, and	Per 2005-6-30 BRD feedback from VBD.	1
	planning part associations from the database must be
	efficient for the developer.
DEV-2.2	Users should be able to easily initiate download of		1
	any release via ePic UI.

5.4.3 Business Rules

ID	Description	Comments	Priority
DEV-3.1	Business rules specified as part of
	requirement BOM-3.1 apply to
	developers, as well.

5.4.4 Interface Requirements

None

5.5 Software Integration

ePic requirements to support integrators who use the system are listed here. ePic will provide a single interface to build tools. Each regional group is expected to modify their build tools to work with the new interface.

Functionality specified here is to be used by integrators as part of image creation and Series Software BOM creation. Functionality to manage DB Hero SKU's and associated BOMs and create dummy SKUs and BOMs is also included here.

5.5.1 Usage Requirements

ID	Description	Comments	Priority
		Dropped. File store related requirements
		will be captures in section 9.10.
INT-1.2	Check-in software release (image).		1
INT-1.2.1	Software item check-in should allow files to be		1
	checked-in to local mirror and uploaded to main store
	asynchronously.
INT-1.3	Schedule software integration activities.	Future Requirement. Not in scope.	NTH
INT-1.4	Track software integration activities.	Future Requirement. Not in scope.	NTH
INT-1.5	Event triggered notification concerning software	Future Requirement. Not in scope.	NTH
	integration activities.
INT-1.6	System should not have any functional dependencies	Build systems will be loosely coupled with	1
	on any external build systems.	ePic.
INT-1.7	Monolithic Images will be created by selecting a	User must select which series SW BOM	5
	SKU that has been loaded from DB Hero or	snapshot to use for this function.
	manually created in the system (see INT-1.12). The
	system will automatically create the Image BOM
	using the series software BOM.
INT-1.7.1	Monolithic image BOMs are not editable by users.	User must edit the appropriate Series	5
		Software BOM to change monolithic BOMs.
INT-1.8	ePic will support creation and deployment of MLHD	MLHD configurations are like SKUs that	5
	configurations.	include software for more than one
		LangRegion.
INT-1.8.1	MLHD BOM Template will be automatically		5
	generated based on user selected SKU BOM(s)
	loaded from DB Hero or manually created in ePic
	(see INT-1.12).
INT-1.8.2	MLHD BOM is not manually editable.	User should edit SKU BOM and associated	5
		Series Software BOM to change MLHD
		BOM contents.
INT-1.8.3	MLHD BOM will be exposed to build system just	An attribute will allow VOE build system to	5
	like any other image BOM.	distinguish MLHD BOMs from other
		images.
INT-1.9	Component selector. Allow user to create DB Hero	User can use this function to specify a	2
	Component lists by selecting DB Hero specs and	configuration or just a set of components.
	classes.	This function is used to specify component-
		to-release mappings during series SW BOM
		Creation (BOM-1.6) and dummy SKU BOM
		Creation (INT-1.12.2). It is intended to
		make it easier for users to select components
		by allowing them to select the same items a
		customer would in a sales system.
INT-1.9.2	If user is creating a configuration, DB Hero	This is necessary to create valid	2
	constraints are checked by the system once all	configurations.
	selections have been made.
INT-1.9.3	DB Hero spec-to-component relations are used to	Thomas will not implement constraints	2
	convert user selected specs/classes to a list of	enforcement which is required for ePic.
	components.
		Dropped. VOA must adapt DB Hero	2
		deliverables to existing systems and Thomas
		will not have all required functionality.
INT-1.10	Specify Component-to-Release Mappings. One or	These mappings will be included in the	1
	more DB Hero Components is mapped to one or	“installation data file,” and factory tools will
	more Releases on a Series SW BOM template.	use these mappings to select the correct
		releases to install on a configuration based
		on the list of DB Hero components that make
		up that configuration (this is a SKU BOM).
INT-1.10.1	If no mappings exist, the system will auto-generate		1
	mappings by using planning part associations to
	resolve which components will be selected.
INT-1.10.2	User can use component selector to select additional		1
	components to be used in a component/release
	mapping or select components directly.
INT-1.10.3	System will perform sanity checks upon submission		1
	of mappings:
	Ensure all SW items on the Series SW BOM
	have mappings with DB Hero components.
INT-1.11	Integrators can request images from non-local file	Images are not synced to other file stores by	1
	stores be copies to the local store.	default.
INT-1.12	Manage SKU's. A SKU represents an individual	SKU BOMs are used by the system to auto-	2
	configuration.	create monolithic image BOMs (INT-1.7)
		and MLHD BOMs (INT-1.8).
		A SKU (stock keeping unit) is a DB Hero
		part representing a configuration. The part
		number of such an item is also called SKU
		or F-number. A SKU BOM is a SKU part
		with a list of DB Hero component parts
		representing one configuration as children.
		Some configurations (for retail products) are
		officially defined in DB Hero. These product
		configurations are referred to as Fixed
		SKUs.
INT-1.12.1	SKU BOMs are loaded from DB Hero as part of DB		2
	Hero interface functionality. SKU BOMs contain a
	SKU item as parent and components as children.
INT-1.12.2	User can also manually create SKU's. User can use		2
	the component selector (INT-1.9) to create a SKU
	BOM. For manually created SKU BOMs, user
	should specify the SKU Description.
INT-1.12.3	User cannot edit SKU BOMs originating from DB		2
	Hero.

5.5.2 User Interface Requirements

ID	Description	Comments	Priority
	Moved to section 9.4.2, requirement BOM-
	2.1.

5.5.3 Business Rules

ID	Description	Comments	Priority
INT-3.1	Both regional and global of foundation
	images will be supported by ePic. When
	reqional images are used, foundation
	images will be designed and built locally
	in each engineering division using ePic
	and local build tools.

5.5.4 Interface Requirements

ID	Description	Comments	Priority
INT-4.1	Provide image BOM data and software items for		1
	VOA's build environment.
		Dropped.
INT-4.3	Provide image BOM data and software items for		1
	SDNA's build environment.
INT-4.4	Data and functionality will be exposed to build tools	DB Connection will be used by SDNA.	1
	via interface DLL.	VOA and VOE will use web services.
INT-4.5	Build data will be exported via system interface.	Build data is a snapshot of a BOM template	1
		for an engineering part. The interface
		should expose other data so that the remote
		user can select snapshots.
INT-4.5.1	Data to be exported:		1
	Active Series Master
	LangRegion Master
	Image/module BOM Snapshots
	All entity attributes
	Binary data (in file store)
INT-4.5.2	Functions to be provided:	Multiple calls required to get BOM.	1
	Authenticate	Filtering of data should be done client side.
	Get Active Series
	Get LangRegion Master
	Get Composite Parts for Series
	Get Snapshot List for Part
	Get Snapshot BOM
	Get Binary Data for SW Release ID (from
	file store)
INT-4.6	Check-in functionality will be provided via system		1
	interface.
INT-4.6.1	Data to be imported:	Part registration is needed since some parts	1
	Release attributes	(like “clean” or “base+” OS images) will be
	Binary data (to file store)	auto-created from build tools.
	Part Registration
INT-4.6.2	Functions to be provided:	Register part functionality must be available	1
	Authenticate	remotely, for example, so that a PIDVD part
	Check-in (to ePic)	(factory media) can be created by build tools
	Upload files (to local file store)	automatically for each monolithic image
	Register Part (to facilitate auto-creation of	created.
	related parts)
	Set default release
INT-4.7	Config Range must be retrieved from DB Hero.	For INT-1.9. Interface specified in “DB	2
		Hero Common Interface Protocol
		Specification 2005-07-07”, page 12 and 27.
INT-4.8	Constraints must be retrieved from DB Hero.	For INT-1.9. Interface specified in “DB	5
		Hero Common Interface Protocol
		Specification 2005-07-07”, page 14 and 30.
INT-4.9	Spec-to-Component relations must be retrieved from	For INT-1.9. Interface specified in “DB	2
	DB Hero.	Hero Common Interface Protocol
		Specification 2005-07-07”, page 17 and 35.
INT-4.10	All SKU BOMs must be retrieved from DB Hero and	For INT-1.7 SKUs are identified by F-	2
	stored in ePic.	number. Interface specified in “DB Hero
		Common Interface Protocol Specification
		2005-07-07”, page 10 and 24.

5.6 Factory Deployment

This section captures ePic requirements specific to factory deployment. Some of these requirements extend previously specified functionality. The requirements and data format for the installation data file is captured in section 9.8.

5.6.1 Usage Requirements

ID	Description	Comments	Priority
MFG-1.1	Snapshot Series Software BOM. This functionality	Snapshots are used for several operations:	1
	should be available from the series software BOM	Installation Data File creation, Test Strategy
	management screens.	management.
MFG-1.1.1	A snapshot can be flagged as a Release Candidate	The latest RC snapshot is used for generating	2
	(RC).	Test Strategies. This function would be used
		for the “BOM Freeze” milestone in VOA.
MFG-1.1.2	User must enter a text version string (or snapshot	For example, “1.0”, “1.1.1-rc”, or “Build	1
	name) for each series software BOM snapshot. This	1”. Business units will decide conventions
	version string should be unique for	this field.
	Series/LangRegion combination.	This is in addition to system generated ID.
		It is used throughout the system and external
		tools as the name of the snapshot.
MFG.1.2	Issue RTM or Test RTM. RTM's and Test RTM's	Test RTM's will be used as a mechanism for	4
	will be issues by Series/LangRegion.	pre-releasing BOMs for PVT events.
MFG-1.2.1	Only one snapshot for a given Series/LangRegion	This implies that different snapshots could be	4
	combination can be flagged as RTM or Test RTM.	used for different LangRegion combinations.
MFG-1.2.2	System must send when an RTM has been issued in		5
	the system. Email must include the following
	information:
	Installation data file name with hyperlink to ePic
	page from which it can be downloaded.
	Name and email of user who issued the RTM.
	Engineering organization of the user.
MFG-1.3	Running change management.		4
MFG-1.3.1	If a user issues an RTM against a Series/LangRegion		4
	combination for which a RTM snapshot already
	exists the system should warn the user that a previous
	snapshot was RTM'ed and this is a running change.
MFG-1.3.2	When system sends release mail to users, the mail	For example:	5
	should indicate that the change is a running change to	Changes since initial RTM:
	RTM'ed software. In addition to items described in	<part name> <detailed ver.> (<rel.
	MFG-1.2.2 the following items should be included in	id>) [ADDED]
	the mail:	<part name> <detailed ver.> (<rel.
	List of releases added/deleted/changed since	id>) [DELETED]
	initial RTM. Items which are patches (EPCs)	<part name> <detailed ver.> (<rel.
	should be tagged as such.	id>) [CHANGED]
	List of releases added/deleted/changed since the	<part name> <detailed ver.> (<rel.
	last running change release. Items which are	id>) [ADDED] [PATCH]
	patches (EPCs) should be tagged as such.	Changes since last RTM:
		<part name> <detailed ver.> (<rel.
		id>)) [ADDED]
MFG-1.4	Manage partitioning information. System will	This data will be included in the installation	5
	provide functionality for specifying partition sizes for	data file.
	all partitions to be used on production systems.
	Special partitions “recovery” and “system” (or C
	drive) can be defined. “System partition must
	always be specified.
MFG-1.4.1	Partitions sizes can be defined for each		5
	Series/LangRegion combination.
MFG-1.4.2	Partition sizes should be specified in MB		5
	(megabytes).
MFG-1.4.3	For the recovery partition, user can select “dynamic”	If a partition size is dynamic, installation	5
	instead of specifying a size. For system partition user	tools will decide whai the size will be.
	can specify “single partition” instead of specifying a	If partition size is “single partition”, then all
	size.	available space remaining on the disk would
		be allocated for the partition.
MFG-1.4.4	For the “system” partition, user must specify a	This is used in the factory so that a	5
	minimum size. This is always required.	diagnostic partition can be created. For
		single partition models the partition size will
		be extended to the final size at the end of the
		factory process.
MFG-1.4.5	If user selects “dynamic” for recovery partition size,		5
	user must also specify “recovery partition installed
	size.” This is the size in MB of all data included in
	the recovery image. It is needed to calculate a
	dynamic partition size.
MFG-1.4.5	For each partition specified, user must specify a disk	For example, “Disk 1, Partition 2,	5
	number, partition number, and label name.	SYSTEM.”
MFG-1.4.6	For each partition specified, user must specify a file	Standard partition types and numbers should	5
	system type. This type will be stored as a	be used.
	hexadecimal number, but system should prompt users
	with partition type name.
MFG-1.5	Factory Media Management. System should provide		4
	some addition functionality to facilitate media
	delivery to factories when defining factory media
	engineering parts.
MFG-1.5.1	System should provide function for auto-creating	▮	4
	media BOM based on a series SW BOM snapshot.
	User can select the snapshot (by RTM, Test RTM,
	Latest, or version field) and system will prepare a
	BOM which includes the appropriate installation data
	file.
MFG-1.5.2	System should provide function for auto-creating a	▮	4
	media set containing only files which have changed
	from another media set. User should select two
	series software BOM snapshots. Default is initial
	RTM'ed snapshot and latest RTM'ed snapshot.
	Appropriate installation data file will be included on
	the BOM.
MFG-1.5.3	User can manually add/remove releases from the	▮	4
	Factory Media BOM.
MFG-1.6	Miscellaneous IDF data maintenance. Functions for	▮	4
	managing data in the IDF not covered elsewhere in
	this document must be provided.

5.6.2 User Interface Requirements

ID	Description	Comments	Priority
MFG-2.1	RTM/Running Change Wizard.	5
MFG-2.2	Download Installation Data file.	3

5.6.3 Business Rules

	ID	Description	Comments	Priority
	MFG-3.1	. . .

5.6.4 Interface Requirements

	ID	Description	Comments	Priority
	MFG-4.1

5.7 Installation and Recovery (ePic)

These requirements describe ePic functionality required to support software installation and recovery.

5.7.1 Usage Requirements

ID	Description	Comments	Priority
INST-1.1	“Installation Data File” (IDF) Management.		1
INST-1.1.1	Installation Data File (IDF) must include the	Satisfies VBD Factory Install WG	1
	following elements for each Series/LangRegion:	requirements 1a-f.
	Minimum tools version number -	Factory Install WG 1c and 1f-1 are satisfied
	checked by tools to ensure the correct	since P1 images, patches, and running
	version is being used (configurable value).	changes are treated like any other module.
	Version number of the installation data
	snapshot.
	The contents of Snyinst.oem. Installation
	order for the modules.
	Mapping of DB Hero components to ePic
	SW releases.
	Data required for the installation tools to
	confirm successful installation of each
	release.
	CRC data for each binary file.
	Total size of each release binary data
	(used for dynamic partition size
	calculation).
	Path information required to locate binary
	files in the file store and download them
	(via SMB share).
	Partition size information for recovery and
	system partitions. All partition
	information defined in the system should
	be included and a field listing total number
	of partitions defined should be calculated
	and included in the file.
	BIOS time zone offset from GMT by the
	series/LangRegion (e.g., GMT +8, GMT
	−7).
	For each release included in the file,
	engineering organization for the developer
	who checked-in the release.
	Recovery type (HDD Recovery or media
	only).
	MLHD specific information, if applicable.
	Relevant MCode specification(s).
	List of all software releases and attributes
	of all software releases on the Series SW
	BOM (BLID will be included as an
	attribute of FI releases).
INST-1.1.3	An installation data file can be automatically	Intended to satisfy Factory Install WG	3
	downloaded to a factory file store, it can be retrieved	requirement 3a.
	manually via ePic UI, or it can be retrieved via DLL
	interface.
INST-1.1.4	Installation data files are generated for each Series	There will be many IDF's. To make	2
	Software BOM Snapshot.	management easier special requirements have
		been specified for online (STOR-1.10 and
		STOR-1.14) and offline (MFG-1.5) factory
		deployment methods.
INST-1.1.5	All users can retrieve the “Test RTM” or “RTM”	Satisfies Factory Install WQ requirement 1f-2.	4
	version of the installation data file for a given series.
	Sony users can additionally retrieve the “latest”
	snapshot of an installation data file.
INST-1.1.6	Each installation data file must have a unique name		1
	with the unique identifier included in the name.
INST-1.2	“RTM”, “Test RTM”, and “latest” snapshots of		4
	installation data can be generated and stored in the
	system.
INST-1.3	Installation data will be “cycle-less.” Installation		2
	data will support all cycles for a given series.
INST-1.4	All users must have a system account to access these		2
	services.
INST-1.5	Third party users should have access only to data		5
	relevant to them. Data will be restricted by series
	(see ADM-1.3).
INST-1.6	MCode management.		4
INST-1.6.2	A MCode specification (bit mapping to software	This means that MCodes can be duplicated	4
	releases) is defined for each Recovery Media Set.	with each instance having different meanings.
INST-1.6.3	The system will generate a MCode specification once		4
	the Recovery Media Set BOM and Series SW BOM
	for the associated series' are complete. This function
	can be re-run if the BOM changes and existing
	MCode Mappings will not be affected.
INST-1.6.4	The system can calculate a MCode given a list of SW	Satisfies VBD Factory Install WG	5
	releases or a list of DB Hero components	requirement 2c.
	representing a single configuration.
INST-1.6.5	The system can calculate the list of software based		5
	on a given MCode.
INST-1.6.5.1	User can produce a list of software from an		5
	encrypted MCode or unencrypted MCode. If the
	MCode is encrypted, user must also enter a UUID
	(text string) to facilitate decryption.
INST-1.6.6	The system can calculate a MCode based on a SKU	System must first convert list of DB Hero	4
	BOM (user defined or from DB Hero) defined in the	components to a list of software releases to
	system.	accomplish this.
		A SKU BOM must be used, because
		calculating a valid MCode requires that DB
		Hero constraints have been enforced for the
		configuration (see Component Selector, INT-
		1.9).
INST-1.6.6.1	User can optionally generate an encrypted MCode by		5
	entering a UUID in the system.
INST-1.6.7	The MCode specification will be included in the		4
	installation data file.
INST-1.7	Recovery Media Planner. Users can define a BOM		4
	template for a Recovery Media Engineering Part
	using a wizard or form.
INST-1.7.1	User selects the Series and LangRegion for which the		1
	recovery media will be created. User
	must select an OS, as well.
INST-1.7.2	System will auto create a Recovery Media BOM		4
	template. This function is identical to Series
	Software BOM auto-generation except that it is also
	constrained by OS selection.
INST-1.7.2.1	User can manually add/remove engineering		1
	parts/release/groups to the BOM template.
INST-1.7.2.2	User can create snapshots of the Recovery Media		1
	BOM template. Requirements are the same as for
	Series Software BOM.
INST-1.7.2.3	A function for comparing Recovery media BOM	Recovery Media BOM's and Series SW	5
	snapshots to series SW BOM snapshots should be	BOM's (their lifecycles are different) are not
	available. Differences should be shown to the user.	directly related. This function is necessary so
		that users can reconcile differences.
INST-1.8	The ePic component selector function must provide a	This is just a button or hyperlink.	4
	function for issuing an HTTP GET or POST to the	This function cannot yet be merged into ePic
	OASIS system in the VOA (This system generates	because it is heavily tied to VSMS and legacy
	MCode writing floppy disks for Sony personnel	support will be required for a while. This can
	around the world). The HTTP request will include	eventually be convened to a standalone tool
	an unencrypted MCode and any other data necessary	which runs alongside ePic once the VSMS
	to produce a MCode floppy in OASIS.	dependencies can be lifted.

5.7.2 User Interface Requirements

ID	Description	Comments	Priority
INST-2.1	Recovery media planner (wizard).		1
INST-2.1.1	Select Series, LangRegion, and OS. One or more of		1
	any of these items may be selected. Set media
	specific attributes.
INST-2.1.2	System auto-generates media BOM. Show software	Series SW BOM is required for auto-	4
	releases and media layout. Allow user to add items	generation. If it is unavailable, user may
	to BOM. Items generated from Series SW BOM	create BOM from scratch.
	cannot be edited.
INST-2.1.3	Generate MCode bit mappings. System stores bit		4
	mappings. Existing bit mappings are frozen if any
	Series/LangRegion assigned to media set it RTM'ed.
	Additional mappings may be created post-RTM.

5.7.3 Business Rules

ID	Description	Comments	Priority
INST-3.1	MCode format will be changed:
	Current MCode space occupied by
	PCODE will be replaced with a
	MCode Spec identifier. All
	remaining bits will be used
	for algorithmic mapping bits to
	software items. There will no
	longer be HW/SW MCode -
	only SW MCode.
INST-3.2	HDD recovery and recovery from
	customer created recovery media
	will not be dependent on MCode.
	MCode is required only for recovery
	using Sony supplied recovery media
	(as defined in ePic).

5.7.4 Interface Requirements

	ID	Description	Comments	Priority
	INST-4.1	. . .

5.7.5 MCode Specification Changes 5.7.5.1 Current MCode Implementation 5.7.5.2 New MCode Implementation

Installation Data File Mockup

<?xml version=“1.0” encoding=“UTF-8”?>
<InstallationDataFile>
// Versioning information and other top level data
<Header>
<Series name=“”/>
<LangRegion name=“”/>
<BomSnapshot id=“” versionString=“”/>
<MinimumToolVersion version=“” />
</Header>
// List of DB Hero component ID to SW release mappings
// (created as part of Series Software BOM management)
<ComponentReleaseMap>
<Mapping>
<ComponentIDList/>
<ReleaseIDList/>
</Mapping>
...
</ComponentReleaseMap>
// List of MCode bit mappings
// MCode spec by recovery media set or Series/LangRegion/OS
<MCodeSpec>
<OperatingSystem id=””>
<Mapping>
<MCode bitmask=“” value=“”/>
<ReleaseIDList/>
</Mapping>
...
</OperatingSystem>
...
</MCodeSpec>
// Partition Data
<ParitionInfo/>
// List of all releases and their attributes for the Series/LangRegion
// (includes BIOS/Firmware releases)
<SeriesSoftwareBom>
<Release id=“” blid=“” ...>
<SetupCommand/>
<Dependencies/>
</Release>
...
</SeriesSoftwareBom>
</InstallationDataFile>

5.8 Installation and Recovery (Tools)

As part of the requirements process global modular and recovery specifications will be defined. These requirements describe changes that must be made to US installation and recovery tools in order to work with ePic. These tools will become the global Installation and Recovery Toolset.

5.8.1 Usage Requirements

ID	Description	Comments	Priority
TOOL-1.1	Image and Module part types can be downloaded and	Requirements TEST-1.1 to TEST-1.4 satisfy	2
	installed automatically using the same tools to be	QA WG requirements for network
	used in the factory.	installation item 2.
		Patches and running changes are “Modules”
		and are thus included.
TOOL-1.2	Installation without a Series SW BOM must be	This functionality should be provided on a	2
	supported.	boot CD.
		Software list building/storing functional
		requirements added to ePic per 2005-9-15
		VBD review.
TOOL-1.3	Installation of a clean OS should be possible.	VBD QA WG Requirement.	2
		This is for early SW development (of
		drivers, for example). ePic will allow such
		images to be checked in and users can use
		QA installation tools to image units.
TOOL-1.4	BIOS/Firmware and tools (e.g., to burn BIOS, write		3
	firmware or write DMI) part types should be
	downloaded automatically.
TOOL-1.5	BIOS/Firmware parts should be automatically		3
	installable.
TOOL-1.6	Release Notes and Bug Lists for all parts can be		2
	automatically downloaded.
TOOL-1.7	Paper manual contents can be automatically		2
	downloaded.
TOOL-1.8	QA download and installation services and tools must	Satisfies QA WG requirements for network	2
	be available worldwide to VAIO engineering groups,	installation item 3 and 5c.
	outsourced QA groups, and ODMs.	Detailed list of users is included in the
		original document.
TOOL-1.9	Tools should check the minimum required version in		2
	the installation data file and should return an error if
	they are a lower version.
TOOL-1.10	Tools will determine install order based on data from		2
	ePic.
TOOL-1.11	Tools must operate in WinXP and WinPE.	Satisfies QA WG requirements for network	2
		installation item 5e and 2i.
TOOL-1.12	Tools must implement function to convert an MCode	This enables the distribution of MCodes to	2
	to a list of software releases (using the installation	factory for Fixed SKU production, and it
	data file) and vice versa.	enables calculation of MCodes on the fly by
		installation tools during the modular
		installation process.
TOOL-1.13	Unique ID of each software release must be verified	Satisfies VBD QA WG requirement 3a.	3
	after installation.
TOOL-1.14	Installation tools must be able to detect whether a	Satisfies VBD QA WG requirement 3b.	3
	module successfully installed.
TOOL-1.15	Installation tools should support automatic creation of	Satisfies QA WG requirements for network	3
	a target environment on a machine.	installation item 5a.
TOOL-1.15.1	Target environment includes an HDD image.	Assumption is that this is a foundation	3
		image.
TOOL-1.15.2	Target environment includes firmware and BIOS		3
	updates.
TOOL-1.15.3	Target environment includes updating of DMI data.		3
TOOL-1.16	Installation tools must have locking mechanism so	Satisfies QA WG requirements for network	3
	that they only work on Sony PCs.	installation item 5b.
TOOL-1.17	QA installation can be initiated using a WinPE boot	Satisfies QA WG requirements for network	2
	CD.	installation item 5d.
TOOL-1.18	Installation tools must work in Windows.		2
TOOL-1.19	Installation tools must support preparing recovery	Satisfies QA WG requirements for network	3
	partition only without performing full install.	installation.
TOOL-1.20	An automated system should exist that can scan	This would help facilitate Test System data	3
	hardware data for test systems and load it into ePic	entry.
	through a network connection.	WMI based configuration checking
		implementation could be used to satisfy this
		requirement.
TOOL-1.21	A DLL should be provided that utilizes MCode		1
	encoding/decoding and MCode
	decryption/encryption.
TOOL-1.22	Three use cases for installation tools will be
	supported:
	1.	Installation using a list of DB Hero
		component part numbers.
	a.	Convert list of component part
		numbers to list of software
		releases.
	b.	Generate MCode using list of
		software releases (optional -
		could be done offline).
	c.	Install software.
	2.	Installation using a MCode.
	a.	Generate list of software
		releases using MCode.
	b.	Install software.
	3.	Installation using a list of releases.
	a.	Generate MCode (optional -
		could be done offline).
	b.	Install software.

5.8.2 User Interface Requirements

	ID	Description	Comments	Priority
	TOOL-2.1

5.8.3 Business Rules

ID	Description	Comments	Priority
TOOL-3.1	For the use cases defined in
	TOOL-1.22:
	Factory Installation will use
	method #1 only.
	For retail models the DB Hero
	component part number list
	can be prepared offline and
	distributed at RTM time.
	Recovery Media Sets
	(RDVDs or Fulfillment
	Media) will use method #2.
	HDD Recovery and recovery
	using customer created media
	will use method #3.
	Test system preparation will use
	all three methods.

5.8.4 Interface Requirements

	ID	Description	Comments	Priority
	TOOL-4.1

5.9 File Store/Mini-ePic

5.9.1 Usage Requirements

ID	Description	Comments	Priority
		Moved to Business Rules section.
		Moved to Business Rules section.
STOR-1.3	New module and application releases will		1
	automatically be synced with other engineering file
	stores. Images will not.
STOR-1.4	Sony user can request that images from another		1
	engineering file store be transferred to their local file
	store via ePic UI.
STOR-1.5	Factory engineers can automatically sync their local	File store solution would thus require a	3
	file store by providing installation data file to	function for parsing the installation data file.
	synchronization tool.
STOR-1.5.1	All binary data required will be automatically		3
	downloaded to factory file store according to
	installation data file.
STOR-1.5.2	Obsolete releases will be automatically deleted from	The “delete obsolete files” function is	3
	factory file store according to installation data file.	intended for factory use. Factories will
	This function can be optionally disabled.	usually only require latest RTM'ed releases.
		Obsolete releases would be any releases that
		were removed/replaced in the installation
		data file. Such a function ensures that
		factories will never need to allocate more
		storage than is absolutely necessary to the
		file store.
STOR-1.5.3	Factory engineers can only download “RTM” or		3
	“Test RTM” releases as indicated in the installation
	data file the receive.
STOR-1.6	For each release, one or more files and directories		1
	can be checked into file store.
STOR-1.6.1	During release check-in, upload process should be a	User should not have to zip up files or FTP	1
	fully automated and atomic operation.	them anywhere.
STOR-1.7	During a download operation, the total size of the		3
	files to be downloaded can be reported to the user
	before the download starts.
STOR-1.8	Users must be able to load binary data into the file	Some factories will receive images and	3
	store from media.	modules on DVD (factory media set).
STOR-1.9	User must be able to operate the file store without a	Perhaps factory file store can work with just	1
	database connection to ePic.	installation data file. Engineering stores may
		use database connection to acknowledge
		check-in(s) and perform other advanced
		functions.
STOR-1.10	File store will provide a function for downloading	This function is for factories.	3
	latest installation data file for a Series/LangRegion.
	The Series/LangRegion list for this function should
	be kept in a configuration file and downloads should
	be manually triggered.
STOR-1.10.1	User should be able to view/download the list of		3
	changes (the same as in requirement MFG-1.3.2)
	when the file store download is triggered.
STOR-1.11	The file store solution should be deliverable as an	Package is sent with user manual and	1
	easily installable package with a simple configuration	required configuration parameters.
	file.
STOR-1.12	The file store solution should be deployable to a wide	File store users will have more flexibility in	1
	range of system architectures.	hardware selection or they can leverage
		existing infrastructure.
STOR-1.13	File and directory management.		1
			1
STOR-1.13.2	Files should be stored in a flat file structure with	It is acceptable to have a few directories on	1
	each file uniquely named.	the file store, as long as it is human.
		navigable.
		Files could be named as the release ID with
		type prefix.
STOR-1.14	A factory file store can be synchronized based on the	Intended to satisfy Factory Install WG	3
	installation data file.	requirement 3b and 3d.
STOR-1.15	Files and directories (binary data) in the file store	Satisfies Factory Install WG requirement 3c.	1
	should be uniquely named.

5.9.2 User Interface Requirements

ID	Description	Comments	Priority
STOR-2.1	Solution should be	Operations can be	1
	command- line based.	scripted. No graphical
	Some functions may be	UI required.
	implemented in a daemon.

5.9.3 Business Rules

ID	Description	Comments	Priority
STOR-3.1	Any business unit requiring a file store will be	Storage requirements will vary for each
	responsible for purchasing and maintaining	installation.
	hardware.
STOR-3.2	Any non-GM software must be available for a	Satisfies QA WG requirements for network
	specified period of time (e.g. 100 days) after the GM	installation item 4.
	version has been released.
STOR-3.3	Golden Master (GM) SW releases must be available	Satisfies QA WG requirements for network
	for an indefinite period of time.	installation item 4.
	If indefinite period is impossible one of the
	following:
	By the end of OS support period.
	By the end of product support period.
	By the end of key parts availability for HW services.

5.9.4 Interface Requirements

ID	Description	Comments	Priority
STOR-4.1	File store must communicate		1
	with other file stores.
STOR-4.2	Files stores must authenticate		1
	before connecting to another file
	store or ePic for any reason.

5.10 Test Management and Defect Tracking

The following key concepts are central to ePic Test Management and Defect Tracking functionality:

• • Test Case: Unit test case associated with a single hardware or software item.
  • Test Case Strategy: A collection of test cases for a series or engineering part/major version. Partially auto-generated based on the releases on a series software BOM. The test case strategy changes over time as items on the series software BOM change.
  • Defect: A flaw of a software or hardware item. Defects can be linked to test cases or standalone.
  • Test System: A PC used for testing. ePic will track the configurations of test systems.

9.11.1 Usage Requirements

ID	Description	Comments	Priority
TEST-1.1	Three primary system roles are used for the		3
	Test/Defect components of ePic: “Project Test		3
	Lead,” “Test Lead,” and “Tester.”
TEST-1.1.1	Only “Project Test Leads” and “Test Leads” can		3
	create/edit Test Cases and create/edit Test
	Strategies.
TEST-1.1.2	Testers can update the results of a Test Case or		3
	create/edit defects. Testers can edit Test Case
	definitions if they have been added to the owner list
	for the Test Case by a Test Lead or Project Test
	Lead.
TEST-1.1.3	Developers and Integrators can update status and	“Fix-verified” resolution is used to confirm	3
	resolution of defects, but cannot set resolution of	regression tests were successful.
	defects to “Fix-verified.”
TEST-1.1.4	Any user with an assigned role in the system can	Authenticated users without roles are given	3
	enter a defect in open status.	read-only access to all parts of the system.
TEST-1.2	Defect management.		3
TEST-1.2.1	Defects can be associated with one or more	Thus for hardware defects, DB Hero part	3
	engineering part/major versions, releases, series,	numbers are used, and for software defects
	or hardware parts. Defects cannot be associated	(including BIOS and firmware) ePic part
	with software planning parts from DB Hero.	numbers are used.
TEST-1.2.2	If a user chooses to associate a defect with a series,		3
	the user should then have the option of selecting
	releases from the series software BOM (if
	available).
TEST-1.2.3	Before entering a defect, the user should be able to	Search functions should be accessible from	3
	search existing defects to ensure that duplicates or	the create defect view.
	similar defects do not already exist.
TEST-1.2.4	Defects can be associated with one or more Test		3
	Systems.
TEST-1.2.4	Defects must be associated with Test Cases if they		3
	are discovered as part of testing (see requirements
	TEST-2.1.4). Defects can also manually be
	associated with a test case.
TEST-1.2.5	Any changes made to an existing defect should be		3
	captured in a history log. The user, date/time, and
	attributes changed should be captured. Changes to
	values for status and resolution of defect should be
	tracked in the history log. For other attributes
	values do not need to be tracked.
TEST-1.2.6	Users checking-in new part releases are required to	This will be required for ALL users who	3
	update the status and resolution of any open defects	check in releases regardless of whether their
	linked against that part/major version.	organization uses the Test Mgmt/Defect
		Tracking functions of ePic. This is critical
		for correctly assessing the quality level in
		any release on the series SW BOM, as will
		as auto-generating the regression portion of a
		Test Strategy.
TEST-1.2.6.1	System will display a table of open defects and	It is preferred that notes entry be a separate	3
	allow user to enter status, resolution, and notes for	screen invoked by a link to facilitate a more
	each defect.	compact UI.
TEST-1.2.6.2	If user sets defect resolution to “Will Not Fix” or		3
	“Deferred” a note is required.
TEST-1.3	Foundation Image (FI) Defect Propagation Tool.	This is a special purpose function required	4
		because each FI is defined as separate
		engineering part in ePic, but defects found in
		the FI will often apply to many FIs (for
		example, defects cause by build tools). It is
		intended to be used by integrators/image
		builders as opposed to QA personnel.
TEST-1.3.1	System displays all open defects against foundation		4
	images and a table of all active foundation image
	engineering parts and releases.
TEST-1.3.2	Attributes displayed for foundation images facilitate		4
	dimensional analysis to identify other FIs affected
	by a defect. User can sort table by column or filter
	table by column values.
TEST-1.3.3	User can select one defect and one or more		4
	releases in the FI table and assign the defect to all
	selected FIs.
TEST-1.4	Create/edit test system. User can define test		5
	systems (PCs used for testing software and
	hardware) in ePic.
TEST-1.4.1	Each BOM should include a list of basic categories	Such categories are maintained in DB Hero	5
	to help user create test BOM: CPU, HDD, ODD,	as an attribute of parts called
	Motherboard, LCD, etc. Parts for specific	“Classification.” This attribute should be
	categories are not required to be entered; these	used for this function.
	categories are used only as filters for the hardware
	parts list.
TEST-1.4.2	The user can create a BOM for the hardware (DB		5
	Hero HW parts) and Firmware (ePic eng. parts) in
	a test system. User can browse parts by series or
	description.
TEST-1.4.3	The user should be able to define addition parts on	Sometimes users must substitute parts that	5
	a test system BOM template that are not included	are not on the DB Hero BOM in the test
	in DB Hero part lists. User defined parts will only	system. User defined HW parts would use
	be available for test system management. User	the same attributes as DB Hero HW parts.
	defined parts will use the same categories as	This function will also be used for special
	normal DB Hero parts.	items which must appear on the RTM report,
		like firmware versions.
TEST-1.4.4	User can use parts from more than one series on a	Appropriate parts may not be available so	5
	test system BOM.	user should be able to use any part in test
		systems.
TEST-1.4.5	When a defect is related to a test system, the test		5
	system BOM template and other data is
	automatically snapshotted. The snapshot must be
	related to the defect.
TEST-1.4.6	DMI settings for each test system must be stored in	This data is included on RTM report. This	4
	ePic. The user can enter the values for a set of	data is output from the SXSYSINF tool
	keys. The keys required are “Manufacturer,”	maintained by System Engineering. Keys
	“Model Name,” “BIOS Lock ID,” “MCode (Un-	must be kept in sync with the development of
	encrypted),” “MCode Tool Version (CDS Models	this tool.
	Only),” “BIOS Information,” “Universal
	Information.” Keys should be configurable (no
	admin screen necessary).
TEST-1.4.7	User can associate a test BOM or SKU BOM with	▮	4
	a test system. This BOM will be used to image the
	system.
TEST-1.5	Test Case Management.		3
TEST-1.5.1	Test Cases can be associated with a series or		3
	engineering part/major version combo. An
	association is not required.
TEST-1.5.1.1	A Test Case result (Pass/Fail/Impeded/Not Tested)		3
	can be stored for each combination of series and
	part release. Results are not stored unless the test
	case is added to a test strategy (default is “Not
	Tested”). A text note and timestamp must be
	stored for each result entered in the system. User
	should be able to retrieve the Test Case result
	history for a test case for a given Test Strategy or
	Release.
TEST-1.5.1.2	Test cases have the following categories:		3
	Basic, Ad-hoc, Use Case, Compatibility. FIV,
	Benchmarks, MDA, Screen Shot Capture,
	Accessory, Business Unit, and Other. Some
	categories have special requirements. See
	description of categories in section 9.11.5.1.
TEST-1.5.1.2.1	Benchmark and MDA Tests results include admin		3
	defined category/key sets. Category, Key, and the
	Value stored are all text fields. Categories should
	have names and long descriptions.
TEST-1.5.1.2.2	Only users with admin privileges can define key	These keys change regularly but	3
	names to be used for Benchmark and MDA testing.	infrequently. An admin screen (not config
		file) is required for this function.
TEST-1.5.1.2.3	Screen Shot Capture tests can have an image file	This is a special test case used for the RTM	3
	(.JPG, .PNG, or .BMP) attached to it.	report.
TEST-1.5.1.2.4	Compatibility Tests can have a list of required		3
	parts attached to them. This is a text field filled
	out manually.
TEST-1.5.1.3	For all test cases “Level” can be set. Levels can	This attribute is used in Test Strategy	3
	be 1, 2, 3, or “Sampling/Sanity Check” (see	generation functions (see below).
	section 10.4.8, TST-13).
TEST-1.5.1.4	Test Case data for a single test case can be	Per VOE review, 2005-11-10.	3
	exported to an Excel spreadsheet.
TEST-1.6	Users can define named Test Case Groups.	Functionality is similar but not identical to	3
		groups used in software BOM creation.
TEST-1.6.1	Test Case Groups can be public or private. Private		3
	groups are visible only to the user that created the
	group.
TEST-1.6.2	Test Case Groups can be assigned to the same		3
	entities as Test Cases. Such assignments are used
	as defaults when a user creates a new test within a
	group.
TEST-1.7	Test Strategy Management.		3
TEST-1.7.1	Each series defined in the system will have a test		3
	strategy associated with it by default. A series test
	strategy is a list of test cases and/or defect
	regressions to be executed against the latest series
	software BOM snapshot for that series.
TEST-1.7.2	User can create and ad-hoc named test strategy to		3
	facilitate pre-integration testing. This test strategy
	can be associated with exactly one engineering
	part/major version.
TEST-1.7.3	Test cases and defect regressions can belong to		3
	more than one test strategy. Test case can be
	added to a strategy only once (no duplicates
	allowed).
TEST-1.7.4	Test strategy auto-update and editing: Test	Only project test leads can perform these	4
	strategies are partially auto-updated when a Project	activities.
	Test Lead accesses the test strategy for a given
	Series/LangRegion combination.
TEST-1.7.4.1	For series test strategies, if a new series software		4
	BOM snapshot has been changed or if the status of
	the snapshot has been changed to Release
	Candidate (RC), the system will auto-update the
	test strategy for any releases or that have changed
	since the last time the test strategy was generated.
	Release for composite parts will be recursively
	processed (system will examine the BOMs for each
	composite part, including FIs).
TEST-1.7.4.2	For ad-hoc test strategies the system will examine		4
	the associated engineering part. Composite parts
	will be recursively processed.
TEST-1.7.4.3	Auto-update of test strategies is performed only for		4
	the selected LangRegion.
TEST-1.7.4.4	1st build (release) test strategy auto-update:		4
	Triggered for the first release checked-in for the
	first major version of an engineering part.
TEST-1.7.4.4.1	Level 1 and 2 test cases associated with the		4
	series/part and Level 1 and 2 test cases with no
	associations are added to the test strategy.
TEST-1.7.4.4.2	User can manually add level 3 test cases and test		4
	case groups. User can remove any auto-added test
	cases.
TEST-1.7.4.5	Minor revision test strategy auto-update: Triggered		4
	for any new releases/defaults which are not the
	first release. Test cases are updated as follows:
TEST-1.7.4.5.1	Defect regressions are added to the test strategy:		4
	Defects with resolution “Fixed” which are
	associated with the current engineering part/major
	version or any of its releases are added to the test
	strategy as “defect regressions.” There are no test
	cases associated with defect regressions (though
	there may be test cases associated with the defect
	itself, they are not used here).
TEST-1.7.4.5.2	System adds test cases for any open defects against	If defects matching the criteria do not have	4
	the current engineering part/major version with	associated test cases then they are ignored by
	Priority of “Must Fix” or “Should fix.” Test cases	the system.
	for open defects with Priority equal to “None” and
	Severity equal to “1” are also added to the test
	strategy.
TEST-1.7.4.6	Major Revision test strategy auto-update: Triggered		4
	for the first release checked in against a major
	version that is not the first major version.
TEST-1.7.4.6.1	Defect regressions are added to the test strategy:		4
	Defects with resolution “Fixed” which are
	associated with the previous engineering part/major
	version or any of its releases are added to the test
	strategy as “defect regressions.” There are no test
	cases associated with defect regressions (though
	there may be test cases associated with the defect
	itself, they are not used here).
TEST-1.7.4.6.2	System adds test cases for any open defects against	If defects matching the criteria do not have	4
	the previous engineering part/major version with	associated test cases then they are ignored by
	Priority of “Must Fix” or “Should fix.” Test cases	the system.
	for open defects with Priority equal to “None” and
	Severity equal to “1” are also added to the test
	strategy.
TEST-1.7.4.7	Final build test strategy auto-update: Triggered		4
	whenever the latest series software BOM snapshot
	has been flagged as a Release Candidate (does not
	apply to ad-hoc test strategies).
TEST-1.7.4.7.1	System adds Compatibility, FIV, and Screen Shot	If a new snapshot has been generated and	4
	Capture Test Cases to the test strategy.	then flagged as an RC before the test
		strategy has been auto-updated, the system
		should also run the appropriate auto-update
		tasks.
TEST-1.7.4.8	User can re-initiate test strategy auto-update		4
	manually at any time.
TEST-1.7.4.9	When an auto-update executes, system should	For example, using color coding.	4
	display changes (test case adds, deletes, and status
	changes) to the user visually.
TEST-1.7.5	User can select a part on the test strategy and view		3
	all open defects.
TEST-1.7.5.1	User can add test cases associated with open		3
	defects to the test strategy.
TEST-1.7.5.2	User can add the defect as a defect regression		3
	(implies changing status to “closed” and resolution
	to “fixed”).
TEST-1.7.6	User can add/delete any test case or test group		3
	from a test strategy (even if the test case was added
	as part of an auto-update action).
TEST-1.7.6.1	If a level 1 or regression test case is deleted, a	Only one warning should be displayed for	3
	warning/confirmation dialog is displayed to the	multiple selections.
	user.
TEST-1.7.6.2	A note indicating that level 1 or regression test		3
	cases were deleted from a test strategy, and who
	deleted it when, should be added to the history log.
TEST-1.7.7	System should invalidate (set to “pending”) any test	This will only be done for Series Test	4
	case result for parts if a new release for a part on	Strategies, not Ad-Hoc ones.
	which they depend (based on dependencies defined
	in ePic) has been checked in. The invalidated test
	cases should be indicated (highlighted) for the user
	on screen. Results of the previous test case result
	should be retained by the system for reference.
TEST-1.7.8	Leads can assign Test Cases on a Test Strategy to		3
	individual testers.
TEST-1.7.9	User can attach one or more test BOMs created	A test BOM can be extracted from the	4
	using the function described in section 9.4.1,	system via interface and used by installation
	requirement BOM-1.9.	tools to prepare a test system.
TEST-1.7.10	User can attach one or more SKUs to the test	The BOM associated with the SKU can be	5
	strategy which have been created using the function	extracted from the system via interface and
	described in section 9.6.1, requirement INT-1.12.	used by installation tools to prepare a test
		system.
TEST-1.7.11	When a tester accesses a test strategy, the system		3
	will display test cases/defect regressions assigned
	to that user, and any test cases/defect regressions
	not assigned to any user. Tester can update the
	result of each test case and the status/resolution or
	each defect displayed.
TEST-1.7.12	Test must select the Test System used before any		5
	test results can be changed.
TEST-1.7.13	System must provide a view of a test strategies by	See RPT-21.	4
	active series which displays the percentage of test
	cases completed.
TEST-1.8	System must provide function to escalate defect to	This requires an interface to the VELSUN	5
	VELSUN (global sustaining system).	system maintained by SDNA.
TEST-1.9	System must provide function to push defect to	This requires an interface to the VALSUN	5
	VALSUN (software defect system used by	system maintained by SDNA.
	SDNA/VBD).
TEST-1.10	Reports currently provided by VSMS for CISC		4
	must be available in ePic.
TEST-1.11	All notes/text area fields should provide advanced		5
	editing functionality.
TEST-1.11.1	Spell checker functionality should be available.		5
TEST-1.11.2	Formatting functionality as follows:		5
	Bullets
	Numbered lists
	Color text
	Font selection
TEST-1.11.3	Formatting applied in edit screens should be		5
	maintained for reports.
TEST-1.12	Benchmark/MDA Field editor. User can define		3
	delete keys used for Benchmark/MDA test case
	categories. Only users with admin privileges can
	use this function.

9.11.2 User Interface Requirements

ID	Description	Comments	Priority
TEST-2.1	User interfaces for viewing test cases/strategies		3
	should provide efficient means for updating data.
TEST-2.1.1	List of test cases and defect regressions should be		3
	displayed in upper right panel. Test cases can be
	marked as pass/fail and defect resolution can be
	changed in this panel without opening other
	windows, only scrolling and clicking.
TEST-2.1.2	Facilitating for updating multiple test cases should be	For example, check boxes for selecting test	3
	provided.	cases and action buttons that apply attribute
		changes to all select test cases.
TEST-2.1.3	Details of each selected test case should be displayed		3
	in lower right panel.
TEST-2. 1.4	Test cases marked as “failed” should trigger a		3
	prompt for entering a defect. Defects created in this
	manner will be automatically linked to the
	appropriate test case.
TEST-2.2	Defects can be entered directly from the main		3
	menu/navigation panel or can be entered when a test
	case has been marked as failed. If a defect is entered
	in connection with a test case the defect.
TEST-2.3	Installation tools and recovery images can be	Same as requirement DEV-2.2 since these	1
	downloaded from ePic manually by UI.	items will be defined as engineering parts in
		ePic.

9.11.3 Business Rules

	ID	Description	Comments	Priority
	TEST-3.1

9.11.4 Interface Requirements

ID	Description	Comments	Priority
TEST-4.1	VELSUN Interface. Used to escalate defects to	Satisfies US sustaining requirements.	5
	global sustaining group.
TEST-4.2	VALSUN Interface. Used to push defects into		5
	software development defect database used in
	VBD/SDNA
TEST-4.4	Tools interface. Tools will provide functions for	Assumption is that testers will perform all	4
	selecting test BOMs and SKU BOMs to be provided	test case/defect updating and test BOM
	to installation tools.	preparation via ePic UI.
TEST-4.4.1	Data to be exported:	These requirements can be merged with	4
	Active Series Master	build tool requirements since the same tools
	LangRegion Master	platform will be used to interface to ePic.
	Test BOMs
	SKU BOMs
	All DB Hero Data for Component Selector
TEST-4.4.2	Functions to be provided:	Some functions defined in requirements INT-	4
	Authenticate.	4.5 and INT-4.6 will be used and are
	Get Active Series.	duplicated here.
	Get open defects for engineering part (used	Test BOMs contain software release ID's
	during release check-in).	and thus don't require an installation data
	Update defect status and resolution (used during	file. SKU BOMs are DB Hero component
	release check-in).	lists and will require an Installation Data
	Get Test Strategy for series/part.	File.
	Get Test BOMs for test strategy.
	Get SKU BOMs for test strategy.
	Get Installation Data File for series.
	Get Binary Data for SW Release ID (from file
	store).
	Functions to allow the component selector
	function to be used remotely with tools to create
	and save SKU BOMs.

9.11.5 Definitions

9.11.5.1 Test Case Types

Name                Description
Basic
Ad-hoc
Use Case            Describes a regular user scenario.
Compatibility       List of steps to test compatibility with external
                    devices (e.g., printer or camera).
FIV (Final Image
Validation)
Benchmarks          Performance parameters captured as key/value
                    pairs.
MDA (Microsoft      Performance parameters dictated by Microsoft
Development         captured as key/value pairs.
Agreement)
Screen Shot Capture Special test case consisting of just an image, which
                    is included on the RTM report.
Business Unit
Accessory
Other

9.11.6 Screen Shot Mock-ups

FIGS. 12-17 show various non-limiting screen shots for defect submission, defect update, test case submit form, defect view, test results, and test case update, respectively.

Reporting and Notification

9.12.1 General Requirements

ID	Description	Comments	Priority
RPTREQ-1	System must provide a custom reporting engine		3
	which will allow custom SQL to be stored and run.
RPTREQ-2	Reports can be viewed on screen or downloaded in	XML is not required for software integration	3
	the following file formats:	and factory deployment reports, because the
	Adobe Acrobat (PDF)	installation data file contains all required
	Microsoft Excel	information in a single XML file.
	Comma Separated Values (CSV)	MS Word format is required for the RTM
	XML (Test/Defect Reports only except for	report. If Word format files cannot be
	RTM)	generated then a format that can be imported
	Microsoft Word (RTM Report Only)	into MS word is acceptable as a substitute.
RPTREQ-3	Some complex reports are configurable by the user.	Details are specified in report descriptions.	3
	Which data sets to be included and criteria for the
	report data can be specified before the report is
	generated.

9.12.2 Reports

The following predefined reports must be provided by ePic. Samples can be found in the appendix (chapter 13.3).

ID	Report Name	Description	Comments	Priority
RPT-1	Series Report	Report of all relevant information for a given Series		2
		(SW BOM and Metadata).
RPT-2	Series BOM	Report of all relevant SW BOM information for a		2
	Report	given Series.
RPT-3	Series Metadata	Report of all relevant metadata for a given Series.		2
	Report
		ID was skipped (it is retained to avoid confusion).
RPT-5	BOM Report	Report of all relevant information for a given Part,	Has Optional Data Choices:	2
		Group or Release which has a BOM.	parts, dependencies, parents,
			children, releases.
RPT-6	Module Release	Report of all relevant information for a given	Has Optional Data Choices:	2
	Report	Module Release including BOM and Metadata.	parts, dependencies, parents,
			children, releases.
RPT-7	Group Report	Report of all Parts and Releases in a given group.	Has Optional Data Choices:	2
			parts, dependencies, parents,
			children, releases.
RPT-8	Image BOM	Report of all Parts and Releases in a given Image	Has Optional Data Choices:	2
	Report	BOM.	parts, dependencies, parents,
			children, releases.
RPT-9	BOM Freeze	Report of all relevant information for a given Series	Previous report is an optional	2
	Report	BOM - which includes a report of new items,	drop down menu of ALL
		updated items, missing items, removed items (from	available Series BOM Snapshot
		previous report).	revisions (this means you could
			compare two different Series).
			The user would be required to
			select a BOM Snapshot to do the
			report for and then a BOM
			Snapshot to compare it to. If no
			comparison BOM Snapshot is
			provided it simply creates the
			report.
RPT-10	Media Set	Report of all Components, Parts and Releases used	Factory Media Report would	2
	Report	in a given factory or recovery media set.	include Metadata for Factory.
RPT-11	Part Report	Report of all relevant information for a given Part.	Has Optional Data Choices: part	2
			releases, dependencies, parents,
			children.
RPT-12	Part Release	List of all Releases by major part with basic attribute	Has Optional Data Choices:	2
	Report	information.	dependencies, parents, children.
RPT-13	Part Release	Report of all relevant information for a given Part	Has Optional Data Choices:	2
	Version Report	Release Version.	dependencies, parents, children.
RPT-14	RTM Report	This is a multi-part report containing test system	Test/Defect report.	3
		information, detailed SW BOM information, defects,
		test cases/results, and other items.
		User must select a Series/LangRegion and one or
		more OSs from the report. User must also select
		which sub-reports to include. The system will then
		extract all required information from the relevant test
		strategy and BOMs and format it.
		The report must be output in MS Word (or
		compatible format) since it must be edited further
		after being generated from ePic.
		See sample in appendix (13.3.14) for more details.
RPT-15	Test Status for	This Report should list ‘Unresolved Defects’ and	Test/Defect report.	2
	Series	‘Test Cases’ that needs to be executed for a
		particular Series.
		User can specify where test cases, defects or both
		are to be included in the report.
		Unresolved Defects: Defects with ‘Defect Status’
		equal to Open and ‘Defect Resolution’ not equal to
		‘Fixed’, ‘Deferred’, ‘Will not Fix’, ‘Duplicate.’
		Defect Attributes to include in the report: Defect ID,
		Part, Summary, Severity, Exposure, Defect
		Resolution (sorted by Priority).
		Test Cases that need to be executed: List of test
		cases with ‘Test Results’ equal to ‘Not Tested’ or
		‘Impeded.’
RPT-16	Test Status for	Same as above for all active series. Sorted by Series.	Test/Defect report.	2
	all Active
	Series
RPT-17	Defect report	Displays all available attributes for a defect. User	Test/Defect report.	2
	for Individual	can optionally request that defect history be included
	Defect	in the report.
RPT-18	Defects by	This is a configurable report for Defect analysis. It	Test/Defect report.	3
	user, team,	is intended to be a way to export defect data for
	series, cycle,	analysis into external tools or for importing to other
	etc.	systems.
		Filtering fields for Defect: Defect ID, Defect Status,
		Defect Resolution, Responsible persons, Priority,
		Severity, Exposure, Champion, Defect Submitter,
		Submit Date, Close Date, Frequency, Assigned to,
		Microsoft Defect ID, Beta ID, Sustaining Status,
		Sustaining Priority, Days Open (less than or equal to
		given number), Series, Part.
		System will include all available defect attributes in
		one table/data structure.
RPT-19	Test Case	This report is similar to RTP-18 except it is for test	Test/Defect report.	2
	Report	cases.
		Filtering fields for Test Case: Test Case ID, Test
		Case Type, Test Results, Part, Series, Test Area,
		Status, Level, Submitter, Last Updated, Excluded
		Series, Submit Date, Linked Defects (to a particular
		test case).
		System will include all available test case attributes
		in one table/data structure.
RPT-20	Test Strategy	Listing of test cases on a test strategy. User can	Test/Defect report. PQD would	2
	Report	optionally request a view.	like this report to function
			similarly to the view on
			http://platform.itd.sel.sony.com/
			(click on “test cases” on menu).
RPT-21	Test Strategy	A view of a test strategies by active series which		2
	Status Report	displays the percentage of test cases completed.
RPT-22	End-of-cycle	This report contains summary information on various		3
	Defect Report	defects for one or more series and/or time periods.
		It is to be used as a post-cycle analysis tool.
		User can select one or more Series/LangRegions.
		User can also select one or more cycles or date
		ranges (for product cycle, initial product cycle
		attribute of the series would be used). User can also
		select which sub-reports to include.
		Data is exportable as PDF or excel files (it is okay if
		more than one excel file is generated).
		The sub-reports are as follows:
		Defect Priority
		Defect Severity
		Defect Exposure
		Defect Resolution by Application Champion
		Defect Resolution by Module (recursive for FI
		BOM)
		Top Ten Deferred/Will Not Fix Defects.
RPT-23	Build Count	Table of Series, OS, FI build count, and Recovery	Test/Defect report. Used for	2
		media build count.	end-of-cycle accounting.
		User must select cycle, date range, or all active
		series.
RPT-24	FI Test Case	Test Case results for a cycle or date range by FI	Test/Defect report.	2
	Report	release.
RPT-25	Module Test	Test Case results for a cycle by Series SW BOM	Test/Defect report.	2
	Case Report	snapshot (test strategy).

9.12.3 Notification

9.12.3.1 General Requirements

ID	Description	Comments	Priority
NOTE-1	Email notifications will not be tied to roles, but		4
	functions for adding sets of email addresses to a
	notification list by system role or group should be
	available. Any email address can be added to a
	notification list (not just system users).
NOTE-2	When a new user is assigned a role in ePic system		4
	should present a list of events to the administrator for
	which notification is available. User will be added to
	the list for any events selected.
NOTE-3	All notification lists can be edited manually in the		4
	system.

9.12.3.2 Events

The following events will trigger email notification to users. On screen notifications are indicated elsewhere in this document.

ID	Description	Reference	Comment
EVENT-1	Email notification is issued when a release check-in is	DEV-1.2.8
	completed (files have been uploaded to file store).
EVENT-1.1	Email notification lists should be stored for each		This requirement will satisfy the
	Engineering Part Type (editable via admin screen).		need to monitor image builds
			(Pilot, RC, GM events).
EVENT-2	RTM email notification requirements. RTM emails	MFG-1.2.2,
	should be sent when “Test RTMs,” “RTMs,” and	MFG-1.3.2
	“running change RTMs” are issued in the system.
EVENT-2.1	Email lists should be maintained by series.
EVENT-2.2	Emails should clearly indicate which event for which
	the email is being sent.
EVENT-2.3	Each email notification should contain a unique
	identifier in the subject line and body of the message
	that can be used to refer to the message. RTM email
	notifications should be logged in a history log that can
	be viewed via ePic UI.
EVENT-2.4	Email content should also be attached as a PDF
	document to the email message (to be used as official
	documentation).
EVENT-3	Series SW BOM snapshot created. Changes since the		Notification of changes to the
	last snapshot (per MFG-1.3.2) should be included in		Series SW BOM (module/image
	the notification.		insertions).
EVENT-3.1	Email lists are maintained by Series.
EVENT-4	Series Software BOM snapshot flagged as release		This is a “BOM Freeze”.
	candidate.
EVENT-4.1	Email lists are maintained by Series.
EVENT-5	Defect submission or defect status/resolution change.
	Defect monitoring is performed by engineering part.
	Users can also choose to receive all.
EVENT-5.1	Application champion and any users on the owner list		If a user wants to monitor a
	for the affected engineering part should be		specific part they must be added
	automatically added to the notification list. Any		to the owner list.
	owners of a test case associated with the part must also
	be notified.
EVENT-5.2	Users can also subscribe to receive defects events by
	Series and/or LangRegion.
EVENT-6	New series loaded in ePic from DB Hero.

9.13 Administration

9.13.1 Usage Requirements

ID	Description	Comments	Priority
ADM-1.1	Add/edit user.		1
ADM-1.1.1	User is required to be associated with an engineering		1
	organization.
ADM-1.1.2	User can be assigned one or more roles.		1
ADM-1.1.3	Users email address must be stored by system.		1
ADM-1.2	Add/edit engineering organization.		1
ADM-1.2.1	Engineering organizations can be Sony or 3rd party.		1
ADM-1.3	Manage 3rd party data access.		3
ADM-1.3.1	One or more series can be assigned to a 3rd party		3
	organization. The 3rd party organization users will
	only be able to see/download data concerning the
	series' which have been assigned to them.
ADM-1.4	Add/edit LangRegion's.		1
ADM-1.4.1	User can add/remove LangRegions to/from the		1
	master.
ADM-1.4.2	DB Hero SPECS are mapped to corresponding	This requirement can be dropped if	1
	LangRegions defined in the system.	LangRegion relationship to DB Hero SPECS
		and COMPONENTS can be identified
		programmatically.
ADM-1.5	System will provide functionality to make batch	This is an admin function only. Users must	2
	changes to attributes entities. User can search for	change items one by one.
	entities, select groups of items to change, and change
	one or more attributes for all items in the group.
ADM-1.6	System should provide a function for defining teams	Some test/defect functions call for	2
	of users.	assignment to a team.
		The group management functionality
		implemented in ePic prototypes may satisfy
		this requirement.
ADM-1.7	Admin functions for defining values for Test Area		2
	(10.4.9, TST-006) and Status (10.4.9, TST-013)
	should be available.

9.13.2 User Interface Requirements

	ID	Description	Comments	Priority
	ADM-2.1

9.13.3 Business Rules

	ID	Description	Comments	Priority
	ADM-3.1

9.13.4 Interface Requirements

	ID	Description	Comments	Priority
	ADM-4.1

9.14 ePic Interface Library

This section describes requirements for the ePic database interface library API for Build Tools and Test System Preparation Tools. Some interface requirements and tools requirements in other sections of this document are satisfied in whole or in part by this API.

VOA tools covered are Magellan and Modular Image Network Download System (MINDS).

All VOA build tools use ePic data, but most of the tools use flat files created by Magellan, as the source of data. Build tools also check in software releases and images and thus need to be able to write data to the ePic database and upload files to the file store.

VOA test system preparation is performed using MINDS tools. These tools are provided on a WinPE CD. This toolset will be made available to ePic users.

SDNA will use VOA provided build tools.

9.14.1 ePic Database Interface Requirements

The ePic database interface should provide the following functions. When a “Recordset” is specified as return value, all applicable attributes for the entity should be included in the Recordset.

ID	Function	Parameters	Return value	Comments	Used By	Priority
DLL-1	Authenticate	User	UserID	Authenticate user. The	Magellan,	2
		Password	SecurityToken	security token should	MINDS
		Action (optional)		be passed on to all
				other functions. All
				other functions can then
				check for a valid security
				token before getting data.
DLL-2	GetImageBOMData	SecurityToken	Recordset	This function should	Magellan	1
		BOM Snapshot ID		return all items on the
		isBasePlus (optional)		specified Image BOM
		isOPK (optional)		that meet the criteria
		isRecoverable (optional)		set by the optional
				arguments. If an
				optional argument is
				not passed to the
				function, that criteria
				should be ignored
DLL-3	GetModulesEPCs	SecurityToken	Recordset	This function should	Magellan	1
		Series ID		return all modules and
		LangRegion		EPCs for the specified
		isPermanent (optional)		Series/LangRegion. If
				Permanent argument is
				True, return all
				permanent items. If it is
				False, return all
				temporary items. If it is
				not specified return all
				items.
DLL-4	GetSeries	SecurityToken	Recordset	This function should	Magellan,	1
				return all active series.	MINDS
DLL-5	GetLangRegions	SecurityToken	Recordset	This function should	Magellan,	1
				return all available	MINDS
				LangRegion values.
DLL-6	GetBOMList	SecurityToken	Recordset	This function should	Magellan,	1
		Series ID		return a list of available	MINDS
		LangRegion		Image BOM
		isImageBOM (optional)		Snapshots/Module BOM
		isModuleBOM (optional)		Snapshots/All BOM
				Snapshots (depending on
				optional arguments) for
				given
				Series/LangRegion.
DLL-7	GetBOM	SecurityToken	Recordset	This function should	Magellan,	1
		BOM Snapshot ID		return the BOM contents	MINDS
				(parts release list) for
				selected BOM Snapshot
				ID.
DLL-8	UploadFiles	SecurityToken	Boolean	This function should	Magellan,	1
		Part Release ID		upload Part Release files	MINDS
		Files to be uploaded.		to the ePic file store.
				One function call
				should upload all the
				required files. We do
				not want to call this
				function for each file.
				This function must be
				called after CheckInPart
				Release. It may be
				called minutes or hours
				after
				CheckInPartReleasefor
				modules (because
				modules require release
				ID to be embedded in the
				module).
DLL-9	CheckInPartRelease	SecurityToken	Part Release ID	This function should add	Magellan	1
		All Part Release data for		a new Part Release to the
		this Part Type.		ePic database.
DLL-10	UpdatePartRelease	SecurityToken	Boolean	This function should	Magellan	1
		Part Release ID.		update Part Release
		All other Part Release		record. This function is
		data for this Part Type.		required as some part
				releases may be created
				using ePic and then
				updated from Magellan
DLL-11	GetSeriesForPart	SecurityToken	Recordset	This function should	Magellan	2
		Part ID		return a list of Series that
				have this Part on their
				BOM Templates.
DLL-12	AddPartReleaseToSeries	SecurityToken	Boolean	This function should	Magellan	2
		Part Release ID		assign the specified Part
		Series IDs		Release to one or more
				Series.
DLL-13	GetDefectsForPart	SecurityToken	Recordset	This function should	Magellan	2
		Part ID		return a list of defects
		Status (optional)		that are currently
				assigned to this Part.
				Optionally result set can
				be filtered by defect
				status.
DLL-14	UpdateDefects	SecurityToken		This function should	Magellan	2
		Part Release ID		update the defect status
		Defect IDs		of specified defects. This
		New Defect Statuses		allows the user to
		New Defect Resolutions		specify what defects have
		New Defect Notes		been fixed in this Release
DLL-15	GetReleaseEmailContents	SecurityToken	Text	Get the email text. This	Magellan	2
		Part Release ID		is used to display the
				email notification to the
				user before it is actually
				sent out.
				Emails sent from
				Magellan will provide
				information on PAC
				Files, FI image, AppInfo
				and DataFile contents.
DLL-16	SendMail	SecurityToken	Boolean	Send email notification.	Magellan	2
		Part Release ID		The contents of the email
		CCText		will be generated
				automatically like part
				releases checked in from
				ePic. Emails sent from
				Magellan will have a
				different target recipient
				list. User should be able
				to add additional
				recipients.
DLL-17	LaunchComponentSelector	SecurityToken	String/Recordset	Launch Component	MINDS	2
		Series ID		Selector to allow user to
		LangRegion is FreeStyle.		select a configuration,
				check for validity and
				returns valid selection of
				parts.
				This is used to create a
				SKU BOM in freestyle
				mode
DLL-18	GetSKUBOMSnapshot	SecurityToken	Recordset	This function should	MINDS	2
	List	Series ID		return a list of available
		LangRegion		SKU BOM snapshots for
				given Series/LangRegion
DLL-19	GetSKUBOM	SecurityToken	Recordset	This function should	MINDS	2
		BOM Snapshot ID		return the SKU BOM
				contents (parts list). It
				should also return the
				installation data file
				(either as XML or
				location from where it
				can be obtained).
DLL-20	AddLog	SecurityToken	BOOL	This function adds a	MINDS	2
		MACAddress		record to the log.
		IPAddress
		SessionID
		User
		Action PartReleaseName
		ReleaseID
		Size
		StartTimestamp
		EndTimestamp
		Time
		Mode
DLL-21	GetLog	SecurityToken	Recordset	This function should get	MINDS	2
		LogID (optional)		the specified log record.
DLL-22	GetSystemTime	SecurityToken	String	Get time on DB server;	MINDS	2
				value used in AddLog.
				(This can be
				implemented within
				AddLog in which case
				this function is not
				required).
DLL-23	IsHDDProject	SecurityToken	BOOL	Check if Series uses	MINDS	2
		Series		HDD recovery
		LangRegion

9.14.2 Technical Requirements

• • Database access for use in MINDS must be able to run in the stripped down version of Windows, Windows Preinstall Environment. (This generally means the code must be written in C++. It's possible to write the programs in Java, Python, Perl, etc., but this would need to be tested and set up within WinPE.)
  • The Database Interface Layer should support applications running in different environments and developed using different programming languages, as shown in the Appendix 1.3.1.
  • All functions in the ePic Database Library should implement stateless security. For example, The Authenticate function should return a SecurityToken object that is then passed to other functions. These functions then check if the security token is valid before interacting with the database. Any other security mechanism can also be used. 9.14.3 Architecture 9.14.3.1 VOA Tools

FIG. 18 shows the non-limiting architecture of VOA Tools.

9.14.4 Usage Scenarios

9.14.4.1 MINDS Usage Scenarios

9.14.4.1.1 Download Image to Test System from MINDS CD.

FIG. 18A logic can be used by testers and by integrators.

9.14.4.1.2 Upload Foundation Image.

FIG. 19 refers, which has been described above and which can be used by integrators.

9.15 Sustaining

This section describes requirements for ePic from the Global Sustaining Group. These requirements will extend existing functionality.

9.15.1 Usage Requirements

ID	Description	Comments	Priority
SUS-1.1	Sustaining modules will be managed in ePic.		5
SUS-1.1.1	A new part type “Sustaining Module” must be		5
	added to ePic.
SUS-1.1.2	Addition sustaining specific attributes must be		5
	supported.
SUS-1.1.2.1	Sustaining ID (or SP-ID), separate from normal		5
	Part/Release ID must be maintained by ePic and
	returned when applicable by check-in functions.
	(ePic will manage this sequence.)
SUS-1.1.3	Sustaining module release notifications will be sent		5
	to a different email notification list than for other
	modules.
SUS-1.1.4	Sustaining modules must have a unique identifier	This is similar functionality as other ePic	5
	embedded in them to support post-installation	modules.
	verification by “VAIO Update” software.
SUS-1.2	Sustaining users should be able to retrieve software		5
	BOM information from ePic UI.
SUS-1.3	Support groups require a network installation	Test System Preparation CD can be used for	5
	system.	this purpose.
SUS-1.4	Maintenance Desk requires Recovery Media		5
	(RDVD's/Fulfillment Media).
SUS-1.5	Module Specification should be unified with	This is so developers only need to create on	5
	Sustaining Patch specification.	format.
SUS-1.6	Software BOM views in ePic should also display		5
	any applicable sustaining patches.
SUS-1.7	Search function should allow entry of a model		5
	name.
SUS-1.8	Search functions should allow Series/LangRegions		5
	to which a particular sustaining patch has been
	applied to be to be found by Sustaining Part ID
	(SP-ID).
SUS-1.9	User can use Part Name/Major Version as a search		5
	key to find Series/LangRegion or list of sustaining
	patches.
SUS-1.10	Legacy data must be maintained in ePic for a time		5
	period suitable to sustaining.

9.15.2 User Interface Requirements

	ID	Description	Comments	Priority
	SUS-2.1

9.15.3 Business Rules

	ID	Description	Comments	Priority
	SUS-3.1

9.15.4 Interface Requirements

	ID	Description	Comments	Priority
	SUS-4.1

10 Data Model 10.1 Concepts

FIG. 20 shows the overall, non-limiting system architecture for Sony PC production. The figure gives an overview for an ePic related systems diagram.

10.2 Data Structure

Moving to FIG. 21, the data structure and flow chart of ePic are shown.

10.3 Database Entities

FIG. 22 illustrates a non-limiting ePic database entities diagram.

10.4 Attributes

10.4.1 Series

	Attribute					Re-	Mod-	Basic	Ext.
ID	Name	Description	Comments	Intended Usage	Examples	quired	ifiable	Search	Search
SER-	Series	Auto-generated system
001	ID	identifier.
SER-	Series	IRX or ATX number.			IRX-3150,	Y	N	Y	Y
002	Name				ATX-2230
SER-	Code	Textual code name for			Diablo EPD	Y	N	Y	Y
003	Name	the series.
SER-	Marketing	There will be many	May be mapped to a	Selection criteria in	VGN-S270,	Y	Y	Y	Y
004	Name	(region to region, cycle	series SW BOM and	system screens	VGN- S27,
		to cycle). For	one or more	reporting.	VGN-S270A,
		Example: PCV-RS500	LangRegions.		VGC-RB30,
			Functionality depends		VGC-RB30C
			on DB Hero handling
			of Marketing Model
			name.
SER-	On	One date for each	Maintained	Reporting.		N	Y	N	Y
005	Sales	LangRegion.	independently in ePic.
	Date		May be useful for
			satisfying sustaining
			requirements.
SER-	Off	One date for each	Maintained	Reporting.		N	Y	N	Y
006	Sales	LangRegion.	independently in ePic.
	Date		May be useful for
			satisfying sustaining
			requirements.
SER-	End	Yes/No. Defaults to no.	Maintained	Reporting.		N	Y	N	Y
007	of		independently in ePic.
	Life		May be useful for
			satisfying sustaining
			requirements.
SER-	Status	Planning, active, archive,	Maintained	Reporting.		Y	Y	Y	Y
008		obsolete, sustaining.	independently in ePic.					(req)	(req)
SER-	Comments	Long description of a	Maintained	Reporting.		N	Y	N	Y
009		series.	independently in ePic.
SER-	Created		Series should not be
010	By		created manually -
			only imported from DB
			Hero. DB Hero
			“created by” is not
			necessary here.
SER-	Created
011	Date
SER-	Active	Yes/No	Maintained	Control display and		Y	Y	Y	Y
012			independently in ePic.	default series lists.
SER-	Planning	List of planning cycles		Reporting.	2005 Q3,	Y	Y	Y	Y
013	Cycle/	applicable for this series.			2005 Q4,
	Season				2006 Q1
SER-	Change	History, system	Maintained
014	Log	generated/maintained	independently in ePic.
SER-	Production	List of production sites	Maintained	May be used for	NFCH,	N	Y	N	Y
015	Site	for this series.	independently in ePic.	RTM and test-RTM	UCCH,
				release status by	DPCH,
				production site to	IT-M,
				facilitate file store	SNT
				functionality and
				reporting.
SER-	LangRegions	List of LangRegions to	Maintained	Used to filter the list	en_US,	N	Y	Y	Y
016	Supported	be supported by this	independently in ePic.	of LangRegions on	en_UK,
		engineering part.		screens and for	jp_JP,
				reporting.	etc.

10.4.2 Components

				Intended				Basic
ID	Attribute Name	Description	Comments	Usage	Examples	Required	Modifiable	Search	Ext. Search
COM-001	Component ID							Y	Y
COM-002	Component Name							Y	Y
COM-003	Active	Yes/No						Y	Y
			Components are					Y	Y
			unique per series so
			this is really a series
			attribute.
COM-005	Type							N	Y
			Components are					N	Y
			system generated in
			DB Hero. There is
			no comments field.
COM-007	Child Parts	List						N	Y
COM-008	List of Specs	Spec-to-Component						N	Y
		relationship may be
		needed for ePic
		functionality.

10.4.3 Planning (DB Hero) Parts

ID	Attribute Name	Description	Comments	Intended Usage	Examples	Required	Modifiable	Basic Search	Ext. Search
PP-001	Part Name							Y	Y
PP-002	Part ID	DB Hero Part						Y	Y
		Number (not
		vendor part number).
PP-003	Active	Yes/No						Y	Y
								(req)
PP-004	SW/HW	Flag						Y	Y
PP-005	Major Version		Assumption is					Y	Y
			that it will be
			separated from
			description in
			DR Hero fro
			SW items.
PP-006	Vendor							Y	Y

10.4.4 Engineering Parts

ID	Attribute Name	Description	Comments	Intended Usage	Examples	Required	Modifiable	Basic Search	Ext. Search
EP-001	Part Name	This is only application name with no version		Can be added to a group.	Adobe Premiere,	Y	Y	Y	Y
		information.			Sonic Stage Studio,
					Radeon 7500 Driver
EP-002	Parent Planning Part		Relation	Used to facilitate	Index to DB Hero	N	Y	Y	Y
				Series SW BOM creation.
EP-003	Active	Yes/No		Used to control	flag (0 or 1)	Y	Y	Y	Y
				display of parts to				(req)	(req)
				users. Only active
				parts should be
				shown in most
				screens. Inactive
				part releases can be
				archived from file store.
EP-004	Major Version	Major version number	New major	Can be added to a	1.1, 2.4, 6.0, 7.0,	Y	Y	Y	Y
		(For Example: 1.1, 1.2,	versions are	group.	4.2.00.06070(Not
		1.3).	created when		for LA)
			specifications
			change —not
			when defects
			are fixed or
			minor changes
			are made.
EP-005	Part Type	Image, OS Setup,	See below.		Lookup List	Y	N	Y	Y
		Installable Application,			including: Image,
		Internal Tools,			OS Setup,
		BIOS/Firmware, Media			Installable
		Set, Other			Application,
					Internal Tools,
					BIOS/Firmware,
					Media Set, Other
EP-006	Part Sub Type	Image (Foundation, P1,	See below.		Lookup List	Y	N	Y	Y
		Monolithic Image)/			including: Image
		Installable Application			(Foundation, P1,
		(Application, Driver,			Monolithic Image)/
		Online Documents, OS			Installable
		Add-on, Module)/			Application
		Media Set (Recovery,			(Application,
		Factory)			Driver, Online
					Documents, OS
					Add-on, Module)/
					Media Set
					(Recovery, Factory)
EP-007	Dependency	Textual description of a		Information for builders.	Text field: IE can	N	Y	N	Y
	Append	dependency that is not			only be installed on
		enforced by the system.			Tuesday.
EP-008	Dependency	List of parts with “Don't		Used to	Relation to another	N	Y	N	Y
		care,” “Need,” or		validate/complete	engineering part
		“Exclude” specified for		release lists for	index.
		each part. System can		testers and during
		enforce/interpret these		BOM creation.
		dependencies.
EP-009	Install Order	List of parts with “Don't		Used by installation	Relation to another	N	Y	N	Y
		care,” “Before,” or		tools to control	engineering part
		“After” specified for		order of release	index.
		each part.		install.
EP-010	Customer Label	Used in Single		Displayed to	Adobe Premiere	Y (for	Y	N	Y
		Application Recovery.		customer during	Standard for	recoverable
		Text for each		application	Windows XP	applications
		LangRegion.		recovery.	English, nVidia	only)
					Graphics Driver,
					DVGate 2.0
EP-011	Customer Desc	Marketing Desc/Hover		Displayed to	Instant Video	Y (for	Y	N	Y
		text used in Single		customer during	Everywhere: Sign	recoverable
		Application Recovery.		application	up for IP Video	applications
		Text for each		recovery.	Conferencing.	only)
		LangRegion.
EP-012	BLID	Used for Foundation	Assigned	Used during	UCV156PEUM	Y (for FI	Y	Y	N
		Image sub type only.	manually	installation of		only)
		BLID = BIOS Lock ID.	currently.	releases. Stored in
			Uniquely	DMI.
			identifies
			foundation
			image in VOA.
			One FI can
			have multiple
			BLIDs in
			VBD/VOE.
EP-013	Is Default	Yes/no (default for each	Actual	Creating Snapshots	flag (0 or 1)	Y	Y	N	Y
		Part Name, Major	implementation	of BOM Templates
		Version, Release,	per the data	(Groups).
		LangRegion	model provided
		combination). Defaults	by Neusoft.
		to false.
EP-014	Champion	Person responsible for			Relation to a user	N	Y	N	Y
		testing info. One or			index.
		more persons can be
		listed.
EP-015	Owner	Contact			Relation to a user	Y	Y	N	Y
		Persons/Developer.			index
		One or more persons
		can be listed.
EP-016	Localized By	Eng. Organization which		For information	text field: VOE,	N	Y	N	Y
		localized the part.		only. Not used by	SDNA, VOA,
		Manually maintained.		system.	STC, VBD
EP-017	Target Series	List that describes BOM			IRX-3440, IRX-	N	Y	N	Y
		template(this part needs			3760, ATX-7100
		to go on these series).
		Specified by developers,
		integrators. Used to
		generate series s/w bom.
EP-018	Series Dependency	Text description for		For information	Text description	N	Y	N	Y
		information, if any.		only. May be used	for information, if
				by builders/testers.	any.
EP-019	Supported	List of LangRegions to		Unsupported	Relatuion to	N	Y	N	Y
	LangRegions	be supported by this		LangRegions	Language Region
		part.		should not be	indexes: ENU-US,
				shown to users in	ENU-UK, SPA-
				other	LA, etc.
				screens/functions.
EP-020	Localized Variation	Yes/No —enables		UI control.	flag (0 or 1)	N	Y	Y	Y
		functionality for defining
		Planned Localized
		Variations.
EP-021	Planned Localized	A named group of		Alternate way to	Look up table to	N	Y	N	Y
	Variation	LangRegions. The		select multiple	LangRegionGroups
		name of variation is		LangRegions for
		manually specified and		screen functions.
		can be anything. For		Releases are
		example: “EN-NTSC” ->		associate with
		en_US, en_UK;		LangRegions and
		“EN-PAL”->en_DE		not Planned
				Release Variations.
EP-022	Change Log	History, system	All changes		History, system
		generated/maintained.	should be		generated/maintained.
			logged with
			who and when.
EP-023	OS	XPP, XPH, MCE,			XPP, XPH, MCE,	Y	Y	N	Y
		WinPE, etc. Only used			WinPE, etc. Only
		when Part Type is			used when Part
		Image.			Type is Image.
EP-024	EPC/Module/X-	For Module sub-types	Used in VSMS	Used by builders	Look up table:	Y (for	Y	N	Y
	Module	only. Select one of	(VOA) to	and installation	EPC/Module/X-	modules
		these (mutually	describe a	tools.	Module.	only)
		exclusive). EPC = Engineering	Module. May
		Process	change pending
		Change.	installation
			tool/recovery
			specification
			definition.
EP-025	Is Temporary	Specifies the part must	Inverse of	Used by installation	flag (0 or 1)	N	Y	N	Y
		be deleted from	VOA “Is	tools.
		recovery partition after	Permanent”
		installation in the	attribute.
		factory. Defaults to
		false.
EP-026	SpecificationFreeze	One date for each		For information	Date field per	N	Y	N	Y
	Sched	Planned Localized		only. In the future,	LangRegionGroup
		Variation.		will be used to	specified above.
				trigger email
				notifications.
EP-027	GUIFreezeSched	One date for each		For information	Date field per	N	Y	N	Y
		Planned Localized		only. In the future,	LangRegionGroup
		Variation.		will be used to	specified above.
				trigger email
				notifications.
EP-028	FeatureFreezeSched	One date for each		For information	Date field per	N	Y	N	Y
		Planned Localized		only. In the future,	LangRegionGroup
		Variation.		will be used to	specified above.
				trigger email
				notifications.
EP-029	RCRelaseSchedule	One date for each		For information	Date field per	N	Y	N	Y
		Planned Localized		only. In the future,	LangRegionGroup
		Variation.		will be used to	specified above.
				trigger email
				notifications.
EP-030	GMReleaseSched	One date for each		For information	Date field per	N	Y	N	Y
		Planned Localized		only. In the future,	LangRegionGroup
		Variation.		will be used to	specified above.
				trigger email
				notifications.
EP-031	GMReleaseActual	One date for each		For information	Date field per	N	Y	N	Y
		Planned Localized		only. In the future,	LangRegionGroup
		Variation.		will be used to	specified above.
				trigger email
				notifications.
EP-032	Default Installer	INF, EXE/BATCH,	Install Property:		lookup table: INF,	N (for major	Y	N	Y
	Type (select from	FILE COPY	Defined in		EXE/BATCH,	version)
	list).		MajorVersion		FILE COPY
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-033	Default Setup File	Path to setup file relative	Install Property:	Used by build tools	\setup.exe or	N (for	Y	N	Y
		to top level folder of	Defined in	to find setup	\DVGATE\config\setup.	major
		release. Text Field.	MajorVersion	executable.	exe	version)
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-034	Default Command	Arguments to be passed	Install Property:	Used by build tools	/quiet/passive	N (for major	Y	N	Y
	Line Arguments	to “Setup File”. Text	Defined in	when running setup	/norestart -s	version)
		Field.	MajorVersion	executable.
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-035	Default OPK	Yes/No: Set for each	Install Property:	Used by build	flag (0 or 1)	Y (for major	Y	N	Y
		Engineering	Defined in	tools.		version)
		Organization	Major Version
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-036	Default Base Plus	Yes/No: Set for each	Install Property:	Used by build	flag (0 or 1)	Y (for major	Y	N	Y
		Engineering	Defined in	tools.		version)
		Organization	MajorVersion
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-037	Default Recoverable	Yes/No: Set for each	Install Property:	Used by tools.	flag (0 or 1)	Y (for major	Y	N	Y
		Engineering	Defined in			version)
		Organization	MajorVersion
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-038	Default Interactive	Yes/No: user interaction	Install Property:	Used by build	flag (0 or 1)	Y (for major	Y	N	Y
		required?	Defined in	tools.		version)
			MajorVersion
			as defaults,
			carried over to
			Release, can be
			modified at
			check-in.
EP-039	Vendor	Vendor of the software.	This is simply		Relation to Vendor	Y	N	Y	Y
			an additional		Index
			attribute. It
			should not be
			concatenated
			with part
			name. There
			should be a
			separate table
			with basic
			Vendor
			information.
			Vendor name
			may also be
			included in part
			name if it
			makes sense.

10.4.4.1 Engineering Part Types

Type	Sub-Type	Description	Special Requirements
Image		Image file(s)
	Foundation
	P1	WinPE image used for HDD Recovery Partition.
	Monolithic Image
OS Setup		OPK unattend setting, i386 folder.	May include some OPK
			specific attributes.
Installable Application		Installed on customer partition.
	Application	Application as delivered from vendor. May be
		repackaged.
	Driver
	Online Documents	PDF Files and other documents installed on systems.
	OS Add-on	QFE's, Patches
	Module	Packaged application: non-interactive installation,	Can be X-module, module,
		secured, ready for factory delivery. Usually includes an	or EPC.
		application and some internal tools.
Internal Tools		Tools, DLL layer, P1 tools/files.
BIOS/Firmware		Firmware updates not recoverable by customer.
Media Set
	Recovery	Customer recovery media.
	Factory	Media set for factory deployment.
Other		Catch all for other types of files. Can be anything, For
		Example “manual settings requests.”

• • Part types will have different system workflows.
  • Some types or sub-types may require additional attributes to be captured in the system.
  • Functionality for sub-types within a part type is mostly the same. 10.4.4.2 LangRegion Table

The following table lists the LangRegions to be used initially.

Language	LangRegion	Description
en	en_US	English for USA.
	en_GB	English for UK and other EU.
	en_int	English for Asia Pacific.
de	de_DE	German for Germany, Austria, Switzerland.
fr	fr_FR	French for France, Belgium, Switzerland.
	fr_CA	French for Canada.
ja	ja_JP	Japanese for Japan.
ko	ko_KR	Korean for Korea.
es	es_ES	Spanish for Spain.
	es_lat	Spanish for Latin America.
it	it_IT	Italian for Italy, Switzerland.
nl	nl_NL	Dutch for the Netherlands, Belgium.
zh	cns_CN	Simplified Chinese for China.
zh	cnt_TW	Traditional Chinese for Taiwan.
pt	pt_PT	Portuguese for Portugal.
el	el_GR	Greek for Greece.
ru	ru_RU	Russian for Russia.

REFERENCES

Language code (ISO-639)

http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt

Region code (ISO-3166)

http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html

10.4.5 Software Releases

For the attributes listed as “required” in search columns, only one of the required fields must be specified by the user.

Some attributes are duplicated between Engineering Part and Release: The attributes set for engineering part should be used as defaults when creating a new release. User can override values set for engineering part at the release level. This function is intended to reduce repetitive data entry due release check-in.

ID	Attribute Name	Description	Comments	Intended Usage	Examples	Required	Modifiable	Basic Search	Ext. Search
REL-001	Release ID	Integer identifier (possibly	SITID(VOA)/ESP #			Y	N	Y	Y
		with part type prefix).	(VOE)/Software ID			(auto)		(req)	(req)
		System generated.	(ITC)
REL-002	Detailed Version	Full release version	Can include the Major		4.0.4.00.25691	Y	Y	Y	Y
		identifier. Text field.	Version value. This is the					(req)	(req)
			same as BOM VAIO's
			“Developer Software
			Release Version” For
			Example: Major Version = 1.4,
			Detailed Version = 1.4.2
			or 1.4.02.06070.
REL-003	Release Name	Concatenation of “Part	For Example: Sonic Stage	Reporting.	Generated: Adobe	Y	N	Y	Y
		Name” + “Detailed	1.4.02.06070		Premiere Standard	(auto)		(req)	(req)
		Version.” Not user			4.0.4.00.25691
		editable.
REL-004	Target	List of LangRegions to be	Relation.		Relation to one or	N	Y	N	Y
	LangRegions	supported by this release.			more LangRegions.				(req)
		(en_US, en_GB, en_int, de_DE,
		fr_FR, fr_CA,, ja_JP, ko_KR,
		es_ES, es_lat, it_IT,
		nl_NL, cns_CN, cnt_TW, pt_PT,
		el_GR, ru_RU)
REL-005	Release Notes	A log of notes. Each	User can add a note to a	For Information		Y	Y	N	N
		notes can belong to one of	release. User specifies	Only. Reporting.
		the categories listed	category of the note at
		below.	data entry time and
			categories can be used to
			filter display.
REL-006	Status	ES/Test, FF,	FF (Feature Freeze)/CF	Sanity checks	Lookup table:	Y	Y	Y	Y
		Pilot, CF, RC, GM	(Code Freeze) = WHQL	during BOM	ES/Test, FF,			(req)	(req)
			candidate.	snapshotting.	Pilot, CF, RC, GM.
				Reporting.
REL-007	Submitted By	User who checked-in the	Released By (VOE),		Relation to user	Y	N	Y	Y
		release.	Contact to Developer		index.			(req)	(req)
			(ITC)
REL-008	Next Release	Text field which specifies		For Information	4.0.4.00.25693A to	N	Y	N	N
		next expected release		Only. Reporting.	be released in late
		version and date.			August 2007.
REL-009	Virus Check	Dropdown		For Information	TBD	N	Y	N	Y
				Only. Reporting.					(req)
REL-010	WHQL status	No submission/under		Sanity checks	Lookup table: no	N	Y	N	Y
		submission/passed/not		during BOM	submission/under				(req)
		applicable.		snapshotting.	submission/passed/
				Reporting.	not applicable.
REL-011	PlmStatus	Dropdown				N	Y	N	Y
									(req)
REL-012	Is Default	Yes/No		Snapshotting of	flag (0 or 1)	N	Y	N	Y
	Release			BOMs.					(req)
REL-013	Is Latest Release	Yes/No		Snapshotting of	flag (0 or 1)	N	Y	N	Y
				BOMs.					(req)
REL-014	Version Path	Registry or file path	May be changed as part of	Used by current	HKEY_LOCAL_MACHINE\	Y	Y	N	N
		(text).	a project globalization of	VOA installation	SOFTWARE\
			installation tools.	tools to verify	Microsoft\Updates\
				installation of a	Windows
				module.	XP\SP3\KB901214\
					Description\
REL-015	Version ID	Version of file or reg key	May be changed as part of	Used by current	Security Update for	Y	Y	N	N
		value(text).	a project globalization of	VOA installation	Windows XP
			installation tools.	tools to verify	(KB901214)
				installation of a
				module.
REL-016	Version check	Text field. Describes		For Information	[How to identify	N	Y	N	N
	before	required installer version		Only. Reporting.	this version]
	installation.	for the given release.			Before Installation
					Check Version.txt
					in installer
REL-017	Version check	Text field. Describes		For Information	[How to identify	N	Y	N	N
	after installation.	another method to		Only. Reporting.	this version]After
		validation installation.			Installation
					Check: Version.txt
					under C:\Program
					Files\Sony\SonicStage
					Mastering
					Studio
					including
					2.0.00.18220
REL-018	Change Log	System generated history:			System generated
		who changed release			history: who
		when.			changed release
					when.
REL-019	Installed Folder	Text field describing path		Some build tools	\\us-sd-itd-san-	Y	N	N	N
	Path	to installed files.		may use this	1\swlibrary\isvrelease\
				field.	0518002.SNC\
REL-021	Installer Type	INF, EXE/BATCH, FILE	Install Property: Defined		lookup table: INF,	Y	N	Y	Y
	(select from list)	COPY	in MajorVersion as		EXE/BATCH,			(req)	(req)
			defaults, carried over to		FILE COPY
			Release, can be modified
			at check-in.
REL-022	Setup File	Path to setup file relative	Install Property: Defined	Used by build	Setup.exe	Y	Y	N	N
		to top level folder of	in MajorVersion as	tools to find setup			(if
		release. Text Field.	defaults, carried over to	executable.			files
			Release, can be modified				not
			at check-in.				uploaded)
REL-023	Command Line	Arguments to be passed to	Install Property: Defined	Used by build	/quiet/passive	N	Y	N	N
	Arguments	“Setup File”. Text Field.	in MajorVersion as	tools when	/norestart -s
			defaults, carried over to	running setup
			Release, can be modified	executable.
			at check-in.
REL-024	OPK	Yes/No: Set for each	Install Property: Defined	Used by build	flag (0 or 1)	N	Y	N	Y
		Engineering Organization	in MajorVersion as	tools.					(req)
			defaults, carried over to
			Release, can be modified
			at check-in.
REL-025	Base Plus	Yes/No: Set for each	Install Property: Defined	Used by build	flag (0 or 1)	N	Y	N	Y
		Engineering Organization.	in MajorVersion as	tools.					(req)
			defaults, carried over to
			Release, can be modified
			at check-in.
REL-026	Recoverable	Yes/No: Set for each	Install Property: Defined	Used by tools.	flag (0 or 1)	N	Y	Y	Y
		Engineering Organization.	in MajorVersion as					(req)	(req)
			defaults, carried over to
			Release, can be modified
			at check-in.
REL-027	Interactive	Yes/No: user interaction	Install Property: Defined	Used by build	flag (0 or 1)	N	Y	N	Y
		required?	in MajorVersion as	tools.					(req)
			defaults, carried over to
			Release, can be modified
			at check-in.
REL-028	Repackaged	Yes/No: Means release	Install Property	For Information	flag (0 or 1)	N	Y	N	Y
		has been modified from		Only. Reporting.					(req)
		ISV original release.
REL-029	Snapshot ID	Identifier of the BOM	Relation.	For Information	Relation to	N	N	N	N
		snapshot which was used		Only. Reporting.	Snapshot Index
		for this release
		(componsite parts only).
			Dropped. System will use			N	Y	N	Y
			active/inactive status						(req)
			instead.

10.4.5.1 Release Notice Categories

Category           Description
By Champion
By Builder
Other Notes
Description
Technical Description
New Features
Notification       E.g. “Same as 2005.2Q”
Installation Steps Step by step description of a manual install.
Uninstall Steps    Step by step description of a manual
                   uninstall process.C26

10.4.6 Groups

	Attribute				Intended	Re-	Mod-	Basic	Ext.
ID	Name	Description	Comments	Usage	Examples	quired	ifiable	Search	Search
GRP-001	Group Name				Windows XP HE	Y	Y	Y
					OS Parts
GRP-002	Group ID	Index ID			Generated Index	Y	N	Y
GRP-003	Comments				Text field: This	Y	Y	Y
					group is for all			(keyword
					Windows XP HE			search)
					images built
					between 2002 and
					2006.
GRP-004	Parts List	Group Members	Can be group, part name,		Relation to a list	N	Y	Y (req)
			major version, release.		of indexes.
GRP-005	Active	Yes/No			flag (0 or 1)	Y	Y	Y (req)
			Dropped. Too
			Complicated.
			Dropped. Too
			Complicated.
			Dropped. Too
			Complicated.
GRP-009	Target	One or more eng	This will be part of a		Lookup Table(s)	N	Y	Y
	Engineering	org, all eng org.	“Define Target Criteria”
	Organization		function used throughout
			the system.
GRP-010	Target Series	List of one or more			IRX-3370,	N	Y	Y
		series for which this			ATX-7100
		group can only be
		used.
GRP-011	Target OS	Select a single OS	This will be part of a	For filtering,	Lookup Table	N	Y	Y
		or “All”. Default to	“Define Target Criteria”	reporting.
		all.	function used throughout	Possibly
			the system.	used for
				sanity checks.
GRP-012	Target	One or more		Used to	Lookup Table	N	Y	Y
	LangRegions	LangRegions.		select the
				correct release
				for BOM
				snapshots.
GRP-013	Usage	Intended usage for		For filtering	Text field:	N	Y	Y
		the group.		and	This group
				organizing	is for all
				groups.	Windows
					XP HE
					images built
					between 2002
					and 2006,
					but only on
					Tuesdays.

10.4.7 Snapshots (BOMS)

	Attribute					Re-	Mod-	Basic	Ext.
ID	Name	Description	Comments	Intended Usage	Examples	quired	ifiable	Search	Search
SNP-001	BOM ID	Index field auto-			Index field auto-	Y	N	N	Y
		generated.			generated.
SNP-002	Description	Name & Revision	(Series/FI/RDVD/		Horizon 3-HE	Y	Y	N	Y
		(IE: Horizon 3-HE	Monolithic/Module/		Build01
		Build01)	Factory Media)
SNP-003	Time and	Auto-Generated			Auto-Generated:
	Date				Aug. 21, 2006
	Stamp				PST
SNP-004	Parent	ID of Series, Image,	Relation		Relation to Index	Y	N	Y	Y
	Part ID	module, etc.			of Parent part or
					Group.
SNP-005	Child Part	All part releases on	Relation		Relation to a lisst	Y	N	Y (return	Y
	Release Ids	the BOM.			of Release			list of
					Indexes.			snaps
								with
								mathcing
								child)
SNP-006	CTO Type	Required/Optional/HW	Relation		Lookup Table	Y	Y	N	Y
		Dependent			Required/Optional/
					HW Dependent

10.4.8 Defect Attributes

						Re-	Modi-	Basic	Ext.
ID	Attribute Name	Description	Comments	Intended Usage	Examples	quired	fiable	Search	Search
DEF-001	Defect ID	Auto generated				Y	N	Y	Y
		sequence.
DEF-002	Defect Status	Open/Closed	Defects can only be			Y	Y	Y	Y
			closed if “Defect
			Resolution is Fix-verified,
			Will Not Fix, Deferred,
			Duplicate, or
			Withdrawn.”
DEF-004	Defect Resolution	Fixed, Fix-verified,	Dropdown. Should be a			Y	Y	Y	Y
		Will Not Fix,	configurable item.
		Deferred,
		Duplicate,
		Withdrawn.
DEF-005	Responsible	Can be one or				N	Y	Y	Y
	persons.	more users or a
		team.
DEF-006	Priority	Must Fix, Should	Dropdown.			N	Y	Y	Y
		Fix, Optional Fix,
		None
DEF-007	Summary (Defect		Text field.			Y	Y	Y	Y
	Title)
DEF-008	Description		Text area.			Y	Y	Y	Y
DEF-009	Frequency	Once, Always,	Dropdown.			N	Y	N	Y
		Sometimes
DEF-010	Frequency Statistics	X out of Y	This can be entered if	For use in		N	Y	N	N
			“Frequency” is	statistical
			“Sometimes.” User can	analysis.
			enter multiple “X of Y”
			sets for each defect.
DEF-011	Notes		Text area			N	Y	N	Y
DEF-012	Related Test Cases	Association with	This cannot be a required			N	Y	N	Y
		one or more test	attribute because defects
		cases.	can be logged without
			associated test cases.
DEF-013	Steps to reproduce.	Can be copied	Text area.			Y	Y	N	Y
		from related test
		cases (attribute
		TST-010) and
		edited.
DEF-014	Expected Results	Can be copied	Text area.			Y	Y	N	Y
		from related test
		cases (attribute
		TST-011) and
		edited.
DEF-015	Workaround		Text area.			N	Y	N	Y
DEF-016	Severity	Values:	Dropdown. Should be a			N	Y	Y	Y
		0-None	configurable item - admin
		1	screen not required.
		2
		3
DEF-017	Exposure	Values:	Dropdown. Should be a			N	Y	Y	Y
		1-LI (Legal	configurable item -
		Implications)	admin screen not
		2-HVCG	required.
		(High Volume
		Call
		Generator)
		3-LNFU
		(Likely to
		Notice with
		Frequent Use)
		4-LIDB
		(Likely to
		Ignore
		Defective
		Behavior)
		5-VUS (Very
		Unlikely will
		See)
DEF-018	Assigned to (parts)	List of one or more				Y	Y	Y	Y
		engineering
		part/major
		versions, releases,
		HW parts, or user
		defined parts
		associated with the
		defect. Should be
		auto-populated if
		submitting from a
		failed test case.
DEF-019	Defect Submitter					Y	N	N	Y
DEF-020	Submit Date					Y	N	N	Y
DEF-021	Close Date					N	Y	N	Y
DEF-022	Attachments					N	Y	N	N
DEF-023	Sustaining status					N	Y	N	Y
DEF-024	Sustaining Priority					N	Y	N	Y
DEF-025	Microsoft Defect ID					N	Y	N	Y
DEF-026	Beta ID					N	Y	N	Y
DEF-027	LangRegion	One or more				Y	Y	Y	Y
		LangRegion's to
		which the defect
		applies. User can
		also select All
		“LangRegions.”
DEF-028	Target Series	The series for				Y	Y	N	Y
		which the defect
		was first
		discovered.
DEF-029	Applicable Series	List of all other	This could be a system			N	Y	N	Y
		series for which a	maintainable attribute
		defect was	based on part information.
		discovered.

10.4.9 Test Case/Strategy Attributes

				Intended		Re-		Basic	Ext.
ID	Attribute Name	Description	Comments	Usage	Examples	quired	Modifiable	Search	Search
TST-001	Test Case ID	Auto-generated				Y	N	Y	Y
		sequence.
TST-002	Test Case	Basic, Ad-hoc, Use	Drop-down.			Y	N	Y	Y
	Type/Category	Case, Compatibility,	For Benchmarks and
		FIV, Benchmarks,	MDA categories: key,
		MDA, Screen Shot	value, and expected
		Capture, Business Unit,	value can be entered.
		Accessory, and Other.	For Screen Shot
			Capture category a
			.jpg or .bmp image
			file can be attached.
TST-003	Test Results	Pass/Fail/Not	Defaults to “Not			Y	Y	Y	Y
		Tested/Impeded stored	Tested.”
		by series, release
		combo.
TST-004	Part/Major Version	One or more part/major				N	Y	N	Y
		versions to which the
		test case is constrained.
TST-005	Series	One or more series to				N	Y	N	Y
		which the Test Case is
		constrained.
TST-006	Test Area	Audio, Video, Still	Dropdown. Should			Y	Y	N	Y
		Picture, Productivity,	be a configurable item
		Etc.	via admin screen.
TST-007	Purpose		Text area.			Y	Y	N	Y
TST-008	Requirements		Text area.			N	Y	N	N
TST-009	Initial Conditions		Text field/Dropdown.			N	Y	N	N
TST-010	Steps		Text area.			Y	Y	N	N
TST-011	Expected Results		Text area.			Y	Y	N	N
TST-012	Notes		Text area.			N	Y	N	Y
TST-013	Status	Active, Obsolete, Etc.	Dropdown. Should be			Y	Y	Y	Y
			a configurable item
			via admin screen.
TST-014	Level	1 - Always Run,	Dropdown			Y	Y	Y	Y
		2 - Sometimes Run,
		3 - Random
		Sampling/Sanity Check
TST-015	Time to Execute	User estimate of time				Y	Y	N	Y
		required to complete the
		test. Integer (in
		minutes).
TST-016	Submitter	Auto - user who creates				Y	N	N	Y
		test case.
TST-017	Related Links	One or more hyperlinks.				N	Y	N	N
		Can be a text field but
		system should interpret
		values as hyperlinks.
TST-018	Last Updated	Auto				Y	Y	N	Y
TST-019	Excluded Series	One or more series				N	Y	N	Y
		which are excluded from
		this test case.
TST-020	Submit Date	Date user created test				Y	N	N	Y
		case.

11 Production Rollout Plan 11.4 Deployment Locations

Now referencing FIG. 23, a non-limiting production rollout plan is shown.

As a global system, More than six places are involved in ePic network:

• • Tokyo
  • Vagana
  • Shanghai
  • Czech
  • Brussels
  • San Diego
  • Other three factories in China

Engineers and factories are in these places:

• • Engineer: San Diego, Brussels, Shanghai, Tokyo
  • Factory: San Diego, Czech, Nagano, Other three factories in China

Network Deployment Diagram

11.5 Phased Rollout

EPic will be rolled out in two phases.

11.5.1 Phase I Release

Phase 1 Requirements will include the following ePic functionality:

• • Parts Registration
  • Image and Module BOM Creation
  • Build System Interface
  • Series Software BOM Creation
  • DB Hero Interface
  • File Store

This release includes full support for image and module building and series software BOM creation. This is essentially the ePic “kernel.”

11.5.2 Phase 2 Release

Phase 2 Requirements will include the following ePic functionality:

• • Test Management
  • Defect Tracking
  • Release to Manufacturing
  • Installation and Recovery Tool Support
  • VALSUN Interface
  • Mini-ePic

This release adds factory deployment, quality assurance, and customer recovery functionality to the ePic system.

11.5.3 Sony Software Development Activities

VOA tools will be adapted to become the global recovery and installation tools. The release date for these new tools will be timed to coincide with the phase 2 release.

Build system modifications must be completed by VOA, VOE, and SDNA in order to build images and modules with ePic.

Plans for implementing and testing changes to build systems must be made with the following milestones in mind:

• • All required ePic system functionality will be implemented in the phase 1 release.
  • A warranty period will be in effect for a TBD period from date of the phase 2 release. After this, changes will be more costly. 12 Changes to Legacy Systems 12.1 Summary 12.1.1 VBD

Current Tools and Systems

• • BOM VAIO—SDNA build system.
  • VELSUN/VALSUN—Defect tracking systems.

Changes to Tools & Systems

• • BOM VAIO will be replaced with VOA's ABU/Magellan.
  • VELSUN/VALSUN—transfer of defects from ePic to VELSUN/VALSUN must be established. 12.1.2 VOE

Current Tools and Systems

• • EIS—VOE Project and Software Management System.
  • Tracker—Image Building and Tracking System.

Changes to Tools & Systems

• • ePic will not support VOE build system since images will no longer be developed at VOE. 12.1.3 VOA
  • SW Plan—excel file defining the software BOM.
  • VSMS—the “VAIO Software Management System.”
  • ABU/Magellan—automated image building tools.
  • Oasis—MCode tool used to support testing.
  • MINDS—automated installation system used by testers.
  • Pacific—tools used to install software in the factory.
  • Recovery Tools—use a localized version of the SDNA GREEN engine.

Changes to Tools & Systems

• • The SW Plan excel file will no longer be used. The data contained therein will be maintained in DB Hero.
  • VSMS, Oasis, and MINDS will be replaced with ePic.
  • ABU/Magellan will be made to interface with the ePic.
  • VOA installation and recovery tools will be modified to become the global toolset.
  • OASIS must be modified to create a floppy based on a single direct HTTP request. 12.2 Build System Changes

Three regional build tool implementations must be modified to work with ePic. Objects created by each regional build system may change to comply with the global modular and recovery specifications, which are to be defined as part of this project.

This section lists current build system artifacts from each region's build system and mappings to ePic fields. The ePic fields listed below are detailed in Section 10.4 of this document. Note that in some cases the format and meaning of the attribute may have changed from the current state. For example, Software Release ID (formerly ESP #, SITID, etc.) will now be an integer with a prefix denoting part type (this will necessitate changes to all three build systems).

Architectural note:

• • Build process should not be interrupted by WAN outages.
  • Caching build data can shield you from WAN outage:
    • Option 1: Build tools interface directly with ePic; caching mechanism can be built into build tools.
    • Option 2: Existing SW system (EIS, BOM VAIO, VSMS) can be used to cache ePic data (possibly lessening impact to build tools). [VOA has chosen to build a caching mechanism into its build system.] 12.2.1 VOA-E Build Tools 12.2.1.1 Build Tools Overview

Build Tools create the following objects:

• • Foundation Image
  • Base Plus Image
  • Monolithic Image
  • P1 Recovery Image
  • Module, X-Module, EPC
  • Factory Deployment Media (RDVD, PIDVD, BDVD)
  • PAC Files
  • P1 Recovery Image
  • PE Module
  • Data file

Database information required includes: Project Info, BOM Info, Component Info (location on server etc).

Files required by Build tools include: OS files, Component Installers (drivers, apps) Output files created by Magellan for use by Automated Build Utility (ABU), Chrysalis recovery tools and others are discussed in the next sections.

12.2.1.2 Files Required by Automated Build Utility (ABU) to Create Foundation and Base-Plus Images.

Script.INI: Contains all items on Image BOM with BasePlus set to FALSE.

BScript.INI: Contains all items on Image BOM with BasePlus set to TRUE and IntegrationMethod is not OPK.

OPKScript.INI: Contains all items on Image BOM with BasePlus set to TRUE and IntegrationMethod is OPK.

VSMS Fields used to              Corresponding ePic fields
create above 3 files.            (refer ePic-Attribs_20050808.xls).
Project name: used for querying and EP-001
to create folder on network to store
these files.
Build name: used for querying and to REL-003
create folder on network to
store these files.
BasePlus: check OPK integration  REL-025
method only for Base Plus.
IntegrationMethod: used by tools & EP-005, EP-006, REL-021
check for OPK items.
Silent: Don't use IntegrationMethod EP-038, REL-027
if not Silent.
BiosLockNo: uniquely identifies  EP-012
image.
ReleaseName                      REL-003
Sitid                            REL-001
NetPath                          REL-020 or Mini ePic part
Switches                         REL-023
InstallInstructions              REL-Installation steps
BuildInfo                        REL-By Builder
VersionPath                      REL-014
VersionID                        REL-015

12.2.1.3 Files Required to Automate Module Creation.

MScript.INI: Contains all items on Module BOM.

VSMS Fields used: Same as above.

12.2.1.4 Files Required by Chrysalis Recovery Tools.

SonyPac.cmd

Is a batch file that creates the structure of one or more PAC files by copying the software releases (that make up the PAC file) from the network to a folder on the local machine. Each folder corresponds to a PAC file. The builder then runs the Pack tool to create a PAC file from the contents of each folder. It is required to create more than one PAC file as one PAC file may not fit on one disc. It contains all items on Image BOM with IsSingleApplicationRecovery is TRUE.

VSMS Fields used:                Corresponding ePic fields.
ProjectName: used for querying, not EP-001
contained in the file.
Build: used for querying, not contained REL-003
in the file.
SITID: to create folder on local machine. REL-001
IsSingleApplicationRecovery: used for REL-026
querying, not contained in the file.
SITInstallProgram: Location on file server. REL-020/Mini ePic
Pac_File: this value is set in VSMS prior to Obsolete in ePic. Move the
creating this file by calculating (according Pac file assignment
to size) which PAC file this software functionality to Magellan
goes on.                         (dynamically assign instead
                                 of storing in database).

Appinfo.ini: Contains all applications and drivers that go on the Foundation Image and are available for recovery through Chrysalis (Single Application Recovery).

                                 Corresponding
VSMS Fields used:                ePic fields.
Project name: used to create folder on network to store EP-001
these files.
Build name: used to create folder on network to store REL-003
these files.
ARCDFolder: used to distinguish Drivers from EP-005, 006
Applications.
ARCDTitle: used as display title for Applications. EP-010
IntegrationMethod: should be OPK-Driver for drivers. EP-006
Used for querying.
ReleaseName: used as display title for Drivers. REL-003
ARCDSpec: text description (hover text). EP-011
SITInstallProgram: installer file. REL-020, 022/
                                 Mini ePic
SITID: used for unpacking.       REL-001
IsSingleApplicationRecovery: determine if compressed. REL-026
Pac_File: used to determine correct PAC file. Obsolete;
                                 generated by
                                 external tool
                                 dynamically.
InstallOrder: used to install in a given sequence. EP-009
Prompts:

12.2.1.5 Files Required for BDVD

AllModules.TXT: Contains all modules and EPCs on a base unit.

VSMS Fields used:               Corresponding ePic fields.
ProjectName: used for querying, EP-001
not contained in the file.
ReleaseName                     REL-003
Installer                       REL-020, 21, 22

12.2.1.6 Files Required for Media Creation

perm modules.cmd: Contains all permanent modules and EPCs for base unit (IsPermanent is TRUE).

temp modules.cmd: Contains all temporary modules and EPCs for base unit (IsPermanent is FALSE).

VSMS Fields used:               Corresponding ePic fields.
ProjectName: used for querying, EP-001
not contained in the file.
isPermanent                     EP-025(reverse logic)
ReleaseName                     REL-003
Installer                       REL-020, 21, 22
Sitid                           REL-001

12.2.1.7 Files Required by MINDS/Pacific

MINDS.CSV

VSMS Fields used: Corresponding ePic fields.
Pcode             Series attributes TBD
BLID              EP-012
Phase             REL-003
Setup             REL-022
VersionID         REL-015
Swmcode           TBD
Version           REL-002
SITID             REL-001
Release Name      REL-003
BaseUnit          Series attributes TBD
Type              EP-005, 006

12.2.1.8 Files Required by Japan

BaseUnitInfo.INI: Contains all base units for a project.

VSMS Fields used: Corresponding ePic fields.
BaseUnit          Series attributes TBD
BaseUnitID
SalesType
ModelNo_JP
OS
Product Mcode
C-Partition Size
P1 Partition Size

12.2.1.9 Other Functionality

Build tools also check in software releases and images and thus need to be able to have a method of writing release data to the database.

13 Appendix

13.4 Terminology

Business
related
CTO	General	Configure To Order	Produce (configure) a product after taking the
			order.
BTO	General	Build To Order
Retail sales,	General		Selling product through normal shop channel.
Direct sales, Online sales	General		Selling product through internet (Web).
B2B	General	Business To Business	Selling product to corporate customer directly
			from Sony.
B2C	General	Business To Consumer
SMB	General	Small Business	Small company like 50 employees.
Enterprise	General	Enterprise	Big company.
SOHO	General	Small Office Home	Very small company like 0 to 3 employees.
		Office	Use home as office.
Product Design
activity
BOM	General	Bill Of Material	List of parts (materials) to produce a product.
SW BOM	General	Software Bill Of
		Material
ES		Engineering Sample
FF		Feature Freeze
Pilot Build		Pilot Build	Test Build
RC	General	Release Candidate
GM	General	Golden Master	Final and approved master software file.
RTM		Release to
		Manufacturing
DVT	Sony	Design Validation T	Hardware prototype for design validation.
PVT	Sony	Production Validation T	Hardware prototype for production
			validation, almost final product.
MP		Mass Production	Real product production, not sample, not
			prototype.
Ex factory			First shipping out of the mass production
			product.
SKU	General	Stock Keeping Unit
Build			Combine many software pieces to make
			single big image file to be copied onto Hard
			Disk Drive of target PC.
Image build, build image			Combine many software pieces to make
			single big image file to be copied onto Hard
			Disk Drive of target PC.
Integration			Combine many software pieces to make
			single big image file to be copied onto Hard
			Disk Drive of target PC.
Software Integration			Combine many software pieces to make
			single big image file to be copied onto Hard
			Disk Drive of target PC.
Preinstall			Install application onto a product so that
			customer doesn't have to install the software
			himself.
Recovery	Microsoft		When a customer wants to go back to factory
			state, “Recovery” to be done.
Hard Disk Recovery	Microsoft
External Recovery Media	Microsoft
Recovery CD, Recovery DVD	Microsoft
BIOS Lock ID, BLID	Sony
M-Code	Sony
BIOS	PC
DMI	PC
Registry	Microsoft
OPK	Microsoft	OEM Pre-installation Kit
OOBE	Microsoft	Out Of Box Experience	Windows Setup screens at very first power-
			on.
Serial number	General
Service Tag	PC
OSR	ITC	OS Recovery or System	Recover the image file.
		Recovery
APR	ITC	Application Recovery	Recover (install) application(s).
SAR (ITE)	ITE	Smart Application	Same meaning as “APR” in SDNA.
		Recovery
VSRU	ITC	VAIO System Recovery	Utility name. Recover the image file, using
		Utility	Green Engine.
VARU	ITC	VAIO Application	Utility name
		Recovery Utility
Wise	General	www.wise.com	Software name to make a package.
Install Shield	General	www.installshield.com	Software name to make an installer.
F.I.	VOA	Foundation Image
MINDS	VOA	Module Installation . . .
VSMS	VOA	VAIO Software Management System
ABU	VOA	Automatic Build Utility
EIS	ITE	Engineering Information
		System
Tracker	ITE
BomVAIO	ITC
BugVAIO	ITC
Valsan	ITC
IRT server	ITC
Librarian	VOA		Image planning.
Build Architect	ITE		Image planning.
Builder	ITC		Image planning.
PM		Project Manager
Multi Language SKU	ITE
DB Hero
terminology
Series	VBD		A product platform. For example,
			“Horizon.”
Class	VBD		A concept representing a set of customer
			choices. For example “Hard Drive” (choices
			might be “100 GB”, “200 GB”, or “250 GB”).
Spec	VBD		Represents a single customer choice.
Config Range	VBD		The set of classes that constitute the full
			(global) range of customer choices for a
			given series. Can be used by a sales system
			to provide CTO offerings to customers.
Component	VBD		Phantom BOM item. Derived from Config
			range during DB Hero block definition
			process.
Component Structure	VBD		List of components for a given structure with
			parts as children. This is considered the
			“manufacturing BOM.”
Factory
terminology
PCN		Production Change	Change form used to disclose any non-BOM
		Notice	related changes to the factory.
ECN		Engineering Change	Change form used to disclose BOM changes
		Notice	to the factory.
EPC	VOE/VOA	Engineering Process	Running change to software. Consists of
		Change	change notification and a corresponding
			software module.
Factory Process			Generic term used to refer to all activities
			performed in the factory in order to produce
			units.
ERP		Enterprise resource	Generic term for inventory, planning, and
		planner	order management systems used in support of
			manufacturing or order fulfillment. Oracle,
			SAP, JD Edwards, etc.
Configuration BOM	VOA		The bill of materials for a specific PC
			configuration.
Platform BOM	VOA		A bill of materials which encapsulates CTO
			customer choices (like the DB Hero Config
			range).
Phantom BOM	VOA		A bill of materials representing the
			manufacturing BOM for a series (like DB
			Hero component structure). Phantom BOM
			items can be included as customer choices on
			the platform BOM.
SMAP		Simple Manufacturing	Unit testing framework used to drive the
		Advanced Process	automated factory process in Sony VAIO
			factories. Imaging in the factory occurs as a
			SMAP process step.
Sony Terminology:
Department
name
VBD or ITC	VAIO Business Division	Tokyo Group	Formerly
			called ITC.
VOA or ITD	VAIO of America	America Group, San	Formerly
		Diego	called ITD or
			ITA.
VOE or ITE	VAIO of Europe	Europe Group,	Formerly
		Brussels	called ITE.
STC	Sony Shanghai Tec Center
SNT	Sony Nagano Factory	200 km from Tokyo
IT-M	Sony San Diego
	Manufacturing division
SVL	Taiwan Exteranl Labo
ODM	China Manufacturing
	Sony Digital Network
SDNA	Applications Inc.,	Tokyo Group	Formerly a
			part of ITC.
Others
SEN	Sony Enterprise Network	Sony Corporate Network (intranet).
		Firewalled.

13.5 Current Process Flows 13.5.1 VOA & IT-M 13.5.1.1 Planning

Below is sequence of how VOA SW planning occurs currently:

• • Explore new ISV business opportunities [VOA-Product Planning & VOA-PM] [Ongoing, but not necessary need to be tracked in DB].
  • Create 1st draft of SW Planning Strategy in ppt by VOA-E PM (N-17).
    • SW Strategy consists of:
      • No platform or project information yet.
      • 80% of Sony software titles leveraged from previous cycle (including utilities & Sony software, but no drivers).
      • Sony Utilities are not updated at this point (No visibility until engineering meeting).
      • Some Sony Software is updated at this point (Info is through grapevine, and not firm until engineering meeting).
      • SW Planning strategy or planning BOMs do not reflect drivers.
      • 20% of ISV software (mostly leverage from previous cycle).
      • Any ISV addition here are 75% firm.
    • Software is also added or remove from SW CTO configuration strategies chart.
      • Grouping of multiple modules to define an offering strategy starts here. Also defines offering rules.
    • Project code names at this point only, no detailed base units names or configuration on PPT.
  • Review 1st draft of SW Planning Strategy in ppt with VOA-PP & ITPD (N-16).
    • Gather questions & consensus prior to Engineering meeting.
      • Make necessary SW plan or offering strategy adjustment up to engineering meeting.
    • Usually not much change here, mostly just to keep ITPD in sync with upcoming strategy.
    • 95% of ISV software are fixed.
  • Present 2nd draft of SW Planning Strategy in ppt @ Engineering meeting in Japan (N-15).
    • 2rd draft includes & updates from PP & ITPD meeting from above.
    • Below is what occurs during engineering meeting:
      • Gather updates & add new Sony Utilities (Utilities strategy are fixed & owned by ITC per platform).
      • Gather updates & add new Sony Software (Sony SW strategies are mostly fixed and owned by ITC per platform. Occassionally, each region are given a choice on certain software pending lead time or if conflicts with local ISV SW strategy.
      • Versions of the above are gathered and updated to SW Strategy ppt (Build revisions are not reflected in SW Strategies or SW planning BOM since they are fixed during integration stage, only reflected in VSMS).
      • ISV Software are presented to ITC (purely to inform them of local strategies).
  • Create 3rd draft of SW Planning Strategy (still in ppt format) (N-14).
    • 3rd draft of the ppt includes updates from engineering meeting.
      • Platform is reflected only if certain software are assigned to specific SKUs.
    • Review 3rd draft with ITPD and VOA-PP to share information from engineering meeting.
  • Review with internal groups (SIT & PQD) by N-13.
    • SW Planning strategy ppt should be fixed.
    • SIT starts to prepare BOM layout in VSMS with SKU & HW config charts.
  • From N-13 to RTM.
    • VOA-PM turns the ppt into SW Planning BOM (in xls format) & adds platform & base units.
      • SW Plan reflects how SW are associated in VSMS to each base units.
      • Either as modules or in foundation image.
      • If in modules, it also reflects if it should be Require “R”, Default “D”, or Optional “O” per base unit.
      • Changes throughout the cycle occurs first in xls & announced to SIT & PQD (VOA-PP & ITPD as well) every Thursday.
      • SW Plan is also used during BOM Freeze (Milestone) to verify that modules assigned in VSMS are all accounted for in both plan & BOM (per base units with each particular projects's BOM Freeze).
      • SW Plan will also be used by ITM royalty reporting group after project RTMs.
      • SW Plan is not used by marketing spec sheet generation, instead a VSMS base unit BOM is used (base unit BOM includes every software, including drivers).
  • Future objectives
    • Elimination of SW planning BOM.
      • Go straight from Strategy ppt to VSMS.
      • Updates should occur in VSMS and populated to projects.
    • Royalty information be assigned according to base units/platform or SW module (Not necessary at planning stage, but need it by RTM). 13.5.1.2 Software Integration

FIG. 23A shows a non-limiting software integration process:

13.5.1.3 Factory Deployment Process

In reference to FIG. 24, the process flow captures a process for deploying CTO software in the factory.

Many of the activities depicted in FIG. 24 are manual, with some small helper applications in use to speed up the work. Some of these activities are executed in parallel with the software integration process.

13.5.2 VOE

13.5.2.1 Software Integration

• • Engineers enter ESP numbers from software plan into EIS via UI.
  • EIS provides a build script via UI.
  • Builder supplies script to build system.
  • Build system builds item.
  • Tracker provides BIOS lock number, image number, and other data to build system. 13.5.3 VBD 13.5.3.1 Software Integration (SDNA)
  • BOM VAIO is standalone database system.
  • Build tools retrieve build data via database link to BOM VAIO. 13.6 Sample Reports 13.6.1 RPT-1: Series Report 13.6.2 RPT-2: Series BOM Report 13.6.3 RPT-3: Series Metadata Report 13.6.4 RPT-4

None. Number skipped.

13.6.5 RPT-5: BOM Report

13.6.6 RPT-6: Module Release Report

MOD-Premiere Pro Build07
BOM Info:
Software Title	Index ID	Version	Defect Owner	Recoverable
Adobe, Multimedia,	0411303.ADB	1.0.00.0404220	Smith 1	No
Premiere Delete DVDBurn
Adobe, Multimedia,	0419801.ADB	1.5.0.0	Smith 2	Yes
Premiere Pro
Sony ITC, Multimedia,	0504604.SNC	5.0.01.14040	Smith 2	Yes
VAIO Edit Components
Adobe, Marketing Material,	0407101.ADB	1.1.00.0403110	Smith 1	Yes
Premiere Pro SerNum and
Readme
Sony ITD, Build Image Tool,	0504903.SND	5.0.1	Smith 3	No
MCODE Reader
Sony ITD, Tools, MN.DLL	0306502.SND	1.2.1	Smith 3	No

Series BOM Associations

		Registered
Series Name	Status	By	Registry Date
Hogwarts4-MC	Shipping	Smith 4	2005/02/20
Hogwarts4_Chrysalis3_Test	In progress	Smith 5	2005/06/07
Horizon2-HE	Shipping	Smith 4	2005/02/20
Horizon2-MC	Shipping	Smith 5	2005/04/19
Horizon2-PR	Shipping	Smith 4	2005/02/20
Horizon3_GD-HE	Shipping	Smith 5	2005/06/09
Horizon3_GD-MC	Shipping	Smith 5	2005/06/09
Horizon3_GD-PR	Shipping	Smith 5	2005/06/09
Jennys_module_test_project	In progress	Smith 4	2005/02/20
LeonS2-HE	Shipping	Smith 4	2005/02/20
LeonS2-PR	Shipping	Smith 4	2005/02/20
LeonS2_Multi-recovery_test	Shipping	Smith 5	2005/02/24
LeonV-HE	Shipping	Smith 5	2005/06/29
LeonV-PR	Shipping	Smith 5	2005/06/29
Messenger-HE	In progress	Smith 5	2005/10/14
Messenger-PR	In progress	Smith 5	2005/10/14
Sherry_WWAN-PR	In progress	Smith 4	2005/10/05
Spirit2-HE	Shipping	Smith 4	2005/02/20
Spirit2-PR	Shipping	Smith 4	2005/02/20
Spirit3-HE	Shipping	Smith 5	2005/06/15
Spirit3-PR	Shipping	Smith 5	2005/06/15

Attachments 13.6.7 RPT-7: Group Report 13.6.8 RPT-8: Image BOM Report 13.6.9 RPT-9: BOM Freeze Report

FI-Inazma-PR (Build03) Image BOM Report

VCC Descriptions
Vendor	Component	Release Name	Hover Text
Adobe	Productivity	Adobe Reader	<ENG> Document viewer: View, navigate, and print PDF
			and E-Book format documents. </ENG>
			<FRA> Visionneuse de document: La vue, dirigent, et
			impriment des documents de format de PDF et E-
			Book </FRA> <ESN> Espectador del documento: La vision,
			navega, e imprime documentos del formato del PDF y del E-
			Book. </ESN>
Alps	Driver-Mouse	Touchpad	Touchpad Driver
Google	Communication	Google Toolbar	<ENG> Maximizes your web searching
			experience. </ENG> <FRA> Facilite vos recherches sur
			internet. </FRA> <ESN> Maximiza su tela que busca
			experiencia. </ESN>
Intel	Driver-System	Intel	Intel 915GM/PM/GMS 910GML Alviso Driver
		915GM_PM_GMS_910GML
		Alviso
Macromedia	Multimedia	Flash Player	<ENG> Play back videos and audio generated in
			Flash. </ENG> <FRA> Lecture de videos et de fichiers audio
			crees avec Flash </FRA> <ESN> Juegue los videos traseros,
			audio generado en flash. </ESN>
Sony ITC	System Tool	Battery Check Utility	<ENG> Manage your notebook power
			settings. </ENG> <FRA> Gerez les parametres
			d'alimentation de votre ordinateur
			portable. </FRA> <ESN> Maneje sus ajustes de energia del
			cuaderno. </ESN>
Sony ITC	Shared Library	ImageStation Library	<ENG> A program utility facilitating ImageStation
			access. </ENG> <FRA> Un utilitaire facilitant l'acces a
			ImageStation. </FRA> <ESN> Una utilidad del programa
			que facilita el acceso de ImageStation. </ESN>
Sony ITC	System Tool	Memory Stick Pro Formatter	<ENG> A program utility for formatting a Memory
			Stick. </ENG> <FRA> Un utilitaire permettant de formater
			un Memory Stick. </FRA> <ESN> Una utilidad del
			programa para ajustar a formato un Memory Stick. </ESN>
Sony ITC	Multimedia	OpenMG Setup	<ENG> A program utility required by
			OpenMG. </ENG> <FRA> Un utilitaire indispensable a
			OpenMG. </FRA> <ESN> Una utilidad del programa
			requerida por OpenMG. </ESN>
Sony ITC	System Tool	Setting Utility Series	<ENG> A program for customizing your utility series
			settings. </ENG> <FRA> Un programme pour personnaliser
			les parametres de vos utlitaires. </FRA> <ESN> Un
			programa para modificar sus ajustes para uso general de la
			serie para requisitos particulares. </ESN>
Sony ITC	Shared Library	Sony Shared Library	<ENG> A program utility required for Sony
			applications. </ENG> <FRA> Un utilitaire pour les
			applications Sony. </FRA> <ESN> Una utilidad del
			programa para los usos de Sony. </ESN>
Sony ITC	Shared Library	Sony Video Shared Library	<ENG> A program utility required for video editing
			applications. </ENG> <FRA> Un utilitaire indispensable
			pour les applications d'edition video. </FRA> <ESN> Una
			utilidad del programa requerida para el video que corrige
			usos. </ESN>
Sony ITC	Shared Library	SonyUtils	<ENG> A program utility required for VAIO

FI-Inazma-PR (Build03) Image BOM Report

VCC Descriptions
Vendor	Component	Release Name	Hover Text
			applications. </ENG> <FRA> Un utilitaire indispensable
			pour les applications VAIO. </FRA> <ESN> Una utilidad del
			programa requerida para los usos de VAIO. </ESN>
Sony ITC	Multimedia	VAIO Entertainment	<ENG> A utility program that installs the VAIO
		Platform	Entertainment Platform. </ENG> <FRA> Un utilitaire
			permettant d'installer la Plateforme VAIO
			Entertainment. </FRA> <ESN> Un programa utilitario que
			instala la VAIO Entertainment Platform. </ESN>
Sony ITC	System Tool	VAIO Event Service	<ENG> A program utility to control specific applications in
			your VAIO computer. </ENG> <FRA> Un utilitaire pour
			controler les applications specifiques de votre ordinateur de
			VAIO. </FRA> <ESN> Usos especificos de un tocontrol
			para uso general del programa en su computadora de
			VAIO. </ESN>
Sony ITC	System Tool	VAIO Power Management	<ENG> Manage your notebook power
			settings. </ENG> <FRA> Gerez les parametres
			d'alimentation de votre ordinateur
			portable. </FRA> <ESN> Maneje sus ajustes de energia del
			cuaderno. </ESN>
Sony ITC	System Tool	VAIO Update	<ENG> Get notifications of the latest driver and news related
			to your VAIO computer. </ENG> <FRA> Recevez les
			notifications vous informant des pilotes les plus recents ainsi
			que les dernieres nouvelles concernant votre ordinateur de
			VAIO. </FRA> <ESN> Consiga las notificaciones del
			conductor y de las noticias mas ultimos relacionados con su
			computadora de VAIO. </ESN>
Sony ITD	Documentation	Latest Information	<ENG> Latest Information. </ENG> <FRA> La Plus
			defunte Information </FRA> <ESN> La Informacion Mas
			ultima </ESN>
Sony ITD	Documentation	Recovery Guide	<ENG> VAIO Recovery Guide. </ENG> <FRA> Guide
			De Reinstallation </FRA> <ESN> Guia De la
			Recuperacion </ESN>
Sony ITD	Tools	VAIO Drivers	<ENG> VAIO Drivers installs the VAIO drivers to their
			original shipping condition. </ENG> <FRA> VAIO Drivers
			installe les conducteurs de VAIO sur leur condition d'expedition
			originale. </FRA> <ESN> VAIO Drivers instala los
			conductores de VAIO a su condicion de envio
			original. </ESN>
Sony ITD	Documentation	VAIO User Manual	<ENG> VAIO User Guide is a program that opens user
			manuals on your VAIO computer. </ENG> <FRA> VAIO
			Manuel D'Utilisateur </FRA> <ESN> Guia de Usuario de
			VAIO </ESN>
Sun	Windows	Java 2 Runtime Environment	<ENG> Installs the Sun MicroSystems Java 2 Runtime
Microsystems			Environment. </ENG> <FRA> Installe l'environnement
			d'execution de Java 2 de Sun MicroSystems. </FRA>
			<ESN> Instala el ambiente del tiempo de pasada de Java 2 de
			los Sun MicroSystems. </ESN>
Veritas	Productivity	PxEngine	<ENG> PxEngine is a shared dynamic link library for optical
			device burning. </ENG> <FRA> PxEngine est une
			bibliotheque de lien dynamique partagee pour la brulure de
			circuit optique. </FRA> <ESN>PxEngine es una biblioteca
			de acoplamiento dinamica compartida para quemarse del
			dispositivo optico. </ESN>

FI-Inazma-PR (Build03) BOM Details
							Re-
	Com-						cov-
Vendor	ponent	Release Name	Champion	SITID	Version	IRT ID	ery
Reference
Sony ITC	Reference	Boot Option Setting	Smith 7	0429908.snc	041017	SP-008333-01	False
		Request
Sony ITC	Reference	HQ Filter setting	Smith 6	0504901.SNC	1.5.02180	SP-009406-00	False
		request			Spirit 2
Sony ITC	Reference	Power Options Setting	Smith 6	0517803.SNC	050627	SP-010128-00	False
		Requests
Sony ITC	Reference	Volume Control	Smith 6	0503821.SNC	050201	SP-009178-00	False
		Settings
Sony ITD	Reference	FI Spec	Smith 8	0509604.SND	3.0.4		False
Sony ITD	Reference	HW Build Document	Smith 9	0521508.SND	Inazma-PR		False
					Build v1.5
Sony ITD	Reference	SCR Specification	Smith 10	0507409.SND	1.1.00.0503150		False
		Document			English
Operating
System
Microsoft	Windows	CDCR patch for	Smith 5	0320501.mst	1.0.0.0		False
		Media Player
Microsoft	Windows	KB307154	Smith 5	0428804.MST	English	SP-008374-00	False
		LowBatteryAlarm
		QFE
Microsoft	Windows	KB835221 HD Audio	Smith 5	0503804.MST	1.0-200408180	SP-008559-00	False
		QFE			English
Microsoft	Windows	KB870669 Critical	Smith 5	0420516.mst	multilingual		False
		Desktop Update for
		MDAC
Microsoft	Windows	KB873333 Security	Smith 5	0504104.mst	English 1.0-	SP-009238-00	False
		Update MS05-012			200502090
Microsoft	Windows	KB873339-Security	Smith 5	0515914.MST	English 1.0-	SP-009052-00	False
		Update MS04-043			200412150
Microsoft	Windows	KB883939-	Smith 5	0517207.MST	English 1.0-	SP-010023.00	False
		Cumulative Security			200506200
		Update for IE
Microsoft	Windows	KB884018-Add and	Smith 5	0422501.MST	English		False
		Remove programs
		copy error
Microsoft	Windows	KB884575	Smith 5	0428801.MST	English	SP-008390.00	False
		BatteryPowerDrain
		QFE
Microsoft	Windows	KB885250 Security	Smith 5	0504101.MST	English 1.0-	SP-009229-00	False
		Update MS05-011			200502090
Microsoft	Windows	KB885835 Security	Smith 5	0503813.MST	KB885835		False
		Update MS04-044			English
Microsoft	Windows	KB885836 Security	Smith 5	0503807.mst	KB8885836	SP-009043-00	False
		Update MS04-041			English
Microsoft	Windows	KB886185 Security	Smith 5	0503801.MST	KB886185	SP-009089-00	False
		Update			English
Microsoft	Windows	KB886612 Memory	Smith 5	0427201.mst	english		False
		Stick Icon Fix
Microsoft	Windows	KB886903 Security	Smith 5	0513204.mst	KB886903		False
		Update MS05-004			Generic
Microsoft	Windows	KB887472 Security	Smith 5	0504516.mst	English 1.0-	SP-009312-00	False
		Update MS05-009			200502090
Microsoft	Windows	KB887742	Smith 5	0503810.MST	KB887742		False
		WLanBlueScreenQFE			English
Microsoft	Windows	KB888113 Security	Smith 5	0504507.mst	English 1.0-	SP-009318-00	False
		Update MS05-015			200502090
Microsoft	Windows	KB888239 MP10_MS	Smith 5	0434401.MST	English		False
		OOBE splash screen			KB888239
		fix
Microsoft	Windows	KB888302 Security	Smith 5	0504510.MST	English 1.0-	SP-009330-00	False
		Update MS05-007			200502090
Microsoft	Windows	KB890046-Security	Smith 5	0517201.MST	English 1.0-	SP-010076-00	False
		Update MS05-032			200506200
Microsoft	Windows	KB890859-Security	Smith 5	0515908.MST	English 1.0-	SP-009693-00	False
		Update MS05.018			200506030
Microsoft	Windows	KB891781 Security	Smith 5	0504504.MST	English 1.0-	SP-009288-00	False
		Update MS05-013			200502090
Microsoft	Windows	KB893056 Hibernate	Smith 5	0507506.mst	English		False
		Button Turn Off fix			KB893056
Microsoft	Windows	KB893066-Security	Smith 5	0517301.MST	English 2.0-	SP-009713-01	False
		Update MS05-019			200506200
Microsoft	Windows	KB893086-Security	Smith 5	0515901.MST	KB893086	SP-009684-00	False
		Update MS05-016			English 1.0-
					200506030
Microsoft	Windows	KB893803-Windows	Smith 5	0515904.MST	3.1-	SP-009766-00	False
		Installer 3.1			KB893803-
					1.0-200506060
Microsoft	Windows	KB894391-SVC Host	Smith 5	0515905.MST	English 1.0-	SP-009724-00	False
		error fix			200505190
Microsoft	Windows	KB896358-Security	Smith 5	0517304.MST	English 1.0-	SP-010013-00	False
		Update-MS05-026			200506200
Microsoft	Windows	KB896422-Security	Smith 5	0517204.MST	English 1.0-	SP-010055.00	False
		Update-MS05-027			200506200
Microsoft	Windows	KB896428-Security	Smith 5	0522305.MST	English 1.0-	SP.010081-00	False
		Update MS05-033			200506200.
Microsoft	Windows	KB901214-Security	Smith 5	0521301.mst	English OEM		False
		Update MS05-036			distribution
Microsoft	Windows	KB903235-Security	Smith 5	0521304.mst	English OEM		False
		Update MS05-037			Distribution
Microsoft	Windows	Media Player 10	Smith 10	0429401.MST	English OPK		False
Microsoft	Windows	Windows.NET	Smith 5	0513101.mst	SPI		False
		Framework Service			KB867460
		Pack
Microsoft	Windows	Windows Media	Smith 5	0516001.MST	ver.X10-86962	SP-009834-00	False
		Connection
Microsoft	Windows	Windows XP OPK	Smith 10	0132507.mst	GM		False
		MUI
Microsoft	Windows	Windows XP	Smith 10	0421902.mst	English SP2		False
		Professional Edition			Gold
Microsoft	Windows	Windows.NET	Smith 10	0314926.mst	Framework		False
					1.1 OPK
					Support
Sony ITC	Windows	SLP Files	Smith 10	0516012.SNC	1.1.1.0-		False
					200506040
Sun	Windows	Java 2 Runtime	Smith 10	0515401.sun	1.5.0.03		True
Micro-		Environment
systems
Driver
Alps	Driver-Mouse	Pointing Driver	Smith 6	0519301.ALP	050629	SP-010147-00	False
		Registry Patch
Alps	Driver-Mouse	Touchpad	Smith 6	0421501.alp	5.3.511.2c	SP-001993-36	True
					WHQL
Connexant	Driver-Modem	Smart MC3Z	Smith 6	0518101.CXT	7.28.00.50-	SP-008161-08	False
					050628logo
Intel	Driver-	Ethernet driver	Smith 6	0430001.itl	8.0.13.0	SP-002515-11	False
	Network				WHQL
Intel	Driver-Display	Intel 915G graphics	Smith 6	0518801.itl	6.14.10.4333h	SP-007709-14	False
					WHQL
Intel	Driver-System	Intel	Smith 6	0520902.itl	6.1.0.1008	SP-008174-00	True
		915GM_PM_GMS_910GML			WHQL
		Alviso
Intel	Driver-Display	Intel Graphics Driver	Smith 6	0515102.itl	v01	SP-009674.00	False
		Registry Patch
Intel	Driver-	Intel Pro	Smith 6	0516401.ITL	9.0.2.25a-logo	SP-007020-07	False
	Wireless	2915ABG_2200BG
	LAN
RealTek	Driver-Sound	Audio Driver	Smith 6	0519601.RTK	5.10.0.5129-	SP-008252-28	False
					050715_WHQL
Sony	Driver-Modem	VDC EGPRS Modem	Smith 11	0506001.ser	3.0.0.1510	SP-009393-00	False
Ericsson		Driver			WHQL
Sony ITC	Driver-System	Notebook Control	Smith 12	0429202.SNC	6.0.1.08290-	SP-004458-00	False
					020604
					WHQL
Sony ITC	Driver-System	SonyPi	Smith 12	0418902.SNC	7.0.3.820	SP-004457-00	False
					WHQL
Sony ITC	Driver-Mouse	USB Mouse	Smith 6	0508001.SNC	1.56-whql	SP-002012-05	False
					(resubmitted)
Sony ITC	Driver-Imaging	VAIO USB Camera	Smith 6	0306208.snc	1.2.00.01172	SP-004578-01	False
					WHQL
Sony ITC	Driver-Hard	VGP-MCA10 registry	Smith 6	0428705.snc	1.0.0.10130	SP-007787-02	False
	Disk	patch
Texas	Driver-Hard	Memory Stick Driver	Smith 6	0520601.tex	2.0.0.5_Logo	SP-009671-04	False
Instru-	Disk
ments
Texas	Driver-Hard	Memory Stick driver	Smith 6	0517802.tex	1.0.0.0-	SP-010131-00	False
Instru-	Disk	Registry patch			20050610
ments
Toshiba	Driver-System	Bluetooth driver	Smith 13	0519901.TOB	3.03.13SO-	SP-009675-03	False
					04_RC3.20050708
Toshiba	Driver-System	Bluetooth Registry	Smith 13	0517801.TOB	1.0.0.0	SP-010130-00	False
		Patch
Utility
Sony ITC	System Tool	AV Mode Button	Smith 6	0519303.SNC	1.0.00.06291	SP-010142-00	False
		Utility
Sony ITC	System Tool	Battery Check Utility	Smith 12	0506701.SNC	1.0.02.01240	SP-007112-03	True
Sony ITC	System Tool	Memory Stick Pro	Smith 12	0503605.snc	2.4.0.13260.0502040	SP-005054-04	True
		Formatter
Sony ITC	System Tool	OCA Marker	Smith 6	0404201.snc	1.03.1.0401130		False
Sony ITC	System Tool	SetReso	Smith 12	0429607.snc	2.3.1.2702	SP-002911-18	False
Sony ITC	System Tool	Setting Utility Series	Smith 12	0516014.SNC	1.2.00.05270	SP-008403-11	True
Sony ITC	System Tool	VAIO Central	Smith 14	0516704.SNC	1.1.02.061005		False
Sony ITC	System Tool	VAIO Event Service	Smith 12	0516805.SNC	2.2.00.06130	SP-008245-21	True
Sony ITC	System Tool	VAIO Power	Smith 12	0521405.SNC	1.7.00.08011	SP-008404-19	True
		Management
Sony ITC	System Tool	VAIO Update	Smith 11	0516103.SNC	2.1.02.01250		True
					(Not for LA)
Sony ITD	System Tool	Sony Digital Signature	Smith 15	0121802.snd	1.0		False
Sony ITD	System Tool	VAIO Support Central	Smith 14	0519320.SND	1.0.0.63005		False
Library
Sony ITC	Shared Library	ImageStation Library	Smith 16	0318106.snc	3.0.01.05290	SP-005050-01	True
Sony ITC	Shared Library	Sony MP4 Shared	Smith 17	0503512.snc	1.1.00.12200	SP-009172-00	False
		Library
Sony ITC	Shared Library	Sony Shared Library	Smith 18	0503811.snc	2.10.00.01250	SP-005988-01	True
					XP
Sony ITC	Shared Library	Sony Video Shared	Smith 17	0503505.snc	2.0.01.12200	SP-009171-00	True
		Library
Sony ITC	Shared Library	SonyUtils	Smith 12	0515908.snc	6.2.00.17310	SP-008151-18	True
Application-
AudioVideo
Macro-	Multimedia	Flash Player	Smith 19	0420101.MAC	7.0.19.0		True
media
Sony ITC	Multimedia	OpenMG Setup	Smith 17	0516005.snc	4.2.00.06070	SP-009199-02	True
					(Not for LA)
Sony ITC	Multimedia	Sonic Stage Mastering	Smith 17	0430713.snc	1.4.00.10260_Aroma-	SP-007851-03	False
		Studio Audio Filter			IRX3190
		Presets
Sony ITC	Multimedia	VAIO Entertainment	Smith 17	0517204.snc	1.2.11.06150	SP-009842-01	True
		Platform
Application-
Productivity
Adobe	Productivity	Adobe Reader	Smith 1	0504801.ADB	7.0.0.0-		True
					English
					Updated
Adobe	Productivity	Adobe Reader Patch	Smith 1	0515201.adb	7.0.1		False
Veritas	Productivity	PxEngine	Smith 20	0518101.VER	2.4.35.500a	SP-007059-10	True
Application-
Communications
Google	Commu-	Google Toolbar	Smith 1	0503801.goo	2.0.114.10_US		True
	nication
Applications-
Marketing
Sony ITC	Marketing	Memory Stick Icon	Smith 12	0209504.snc	1.2.0.0-	SP-002377-02	False
	Material				20010912
Sony ITC	Marketing	VAIO LiteFlow	Smith 18	0515905.snc	1.0.01.05100	SP-008504-01	False
	Material	Wallpaper
Sony ITC	Marketing	VAIO Long Battery	Smith 18	0516607.SNC	1.0.00.05200	SP-009801-00	False
	Material	Life Wallpaper			(RC)
Sony ITC	Marketing	VAIO Original Screen	Smith 18	0516001.snc	1.1.01.06070	SP-008470-05	False
	Material	Saver
Sony ITC	Marketing	VAIO Scene	Smith 18	0503503.snc	1.0.01.12280_Scene_SD_Wide	SP-008486-01	False
	Material	Screensaver
Sony ITD	Marketing	Bookmarks-IE	Smith 1	0503801.SND	1.0.00.0502070		False
	Material				(US)
Sony ITD	Marketing	Image Station Photo	Smith 5	0508804.snd	1.0.0.0503280		False
	Material	Printing RegKeys
Sony ITD	Marketing	VAIO Registration	Smith 15	0519419.SND	Fall05-14.0.2		False
	Material
Documentation
Sony ITD	Documentation	Latest Information	Smith 21	0522304.SND	Fall05 English	n/a	True
					V2
Sony ITD	Documentation	Recovery Guide	Smith 21	0520301.SND	Fall05 English	n/a	True
Sony ITD	Documentation	VAIO User Manual	Smith 21	0520701.SND	1.00.16EN07251	SP-010132.02	True
					(IRX-3250
					ENU)
SIT Build
Tools
Sony ITD	Tools	E-Flyer pop up utility	Smith 4	0507506.SND	1.2.1901.20464		False
Sony ITD	Tools	HDD Kick Tool	Smith 3	0520614.SND	3.1.5.0		False
Sony ITD	Tools	VAIO Drivers	Smith 10	0521610.SND	G336B02		True

Items Associated to Series:

Type	Release Name	Index
MODULE	MOD-Click_To_DVD	(0518903.snd)
MODULE	MOD-DVGate_Plus	(0516403.snd)
MODULE	MOD-IceMaker	(0519313.snd)
MODULE	MOD-Image_Converter	(0517211.snd)
MODULE	MOD-Moodlogic	(0516810.snd)
MODULE	MOD-MS_Works_Bundle	(0506705.snd)
MODULE	MOD-NIS_2005_Trial	(0521324.snd)
MODULE	MOD-Office_2003_Basic	(0505102.snd)
MODULE	MOD-Office_2003_Professional	(0520615.snd)
MODULE	MOD-Office_2003_Small_Business	(0520613.snd)
MODULE	MOD-Office_2003_Small_Business_Trial	(0519613.snd)
MODULE	MOD-Office_2003_Student_Teacher_Trial	(0519616.snd)
MODULE	MOD-PhotoShop_Album_Starter_Edition	(0517909.snd)
MODULE	MOD-Photoshop_Elements	(0505510.snd)
MODULE	MOD-Premiere_Pro	(0503904.snd)
MODULE	MOD-Premiere_Standard	(0520304.snd)
MODULE	MOD-Quicken_New_User_Edition	(0504901.snd)
MODULE	MOD-Roxio_DigitalMedia_SE	(0518107.snd)
MODULE	MOD-S_S_M_S	(0518801.snd)
MODULE	MOD-Spy_Subtract	(0517402.snd)
MODULE	MOD-Toshiba_Bluetooth	(0518111.snd)
MODULE	MOD-VAIO_Media	(0519301.snd)
MODULE	MOD-VAIO_Survey_Standalone	(0518615.snd)
MODULE	MOD-WinDVD	(0518607.snd)
MODULE	MOD-Wireless_Help_Utility	(0504904.snd)
MODULE	MOD-Wireless_Switch_Setting_Utility	(0518108.snd)
MODULE	XMOD-AOL_Software	(0519417.snd)
MODULE	XMOD-SonicStage	(0517302.snd)
Recovery Image	P1 Recovery Image	(0520914.snd)

Changes from Previous:

Missing From Module Build 7
Vendor	Release Name	Defect Owner	Index	Version

New Components to Premiere Pro Module Build 7
Vendor	Release	Defect Owner	Index	Version	IRT ID	Recovery
	Name

New Releases to Premiere Pro Module Build 7
Vendor	Release Name	Index	New Version	Old SITID	Old Version

Removed from Premiere Pro Module Build 7
Vendor	Release Name	Defect Owner	Index	Version
Sony	Driver Settings	Smith 6	0503807.SNC	050131 NB
ITC	Request Page

13.6.10 RPT-10: Media Set Report

Type	Release Name	Index
MODULE	MOD-Click_To_DVD	(0518903.snd)
MODULE	MOD-DVGate_Plus	(0516403.snd)
MODULE	MOD-IceMaker	(0519313.snd)
MODULE	MOD-Image_Converter	(0517211.snd)
MODULE	MOD-Moodlogic	(0516810.snd)
MODULE	MOD-MS_Works_Bundle	(0506705.snd)
MODULE	MOD-NIS_2005_Trial	(0521324.snd)
MODULE	MOD-Office_2003_Small_Business_Trial	(0519613.snd)
MODULE	MOD-Office_2003_Student_Teacher_Trial	(0519616.snd)
MODULE	MOD-PhotoShop_Album_Starter_Edition	(0517909.snd)
MODULE	MOD-Photoshop_Elements	(0505510.snd)
MODULE	MOD-Premiere_Pro	(0503904.snd)
MODULE	MOD-Premiere_Standard	(0520304.snd)
MODULE	MOD-Quicken_New_User_Edition	(0504901.snd)
MODULE	MOD-Roxio_DigitalMedia_SE	(0518107.snd)
MODULE	MOD-S_S_M_S	(0518801.snd)
MODULE	MOD-Spy_Subtract	(0517402.snd)
MODULE	MOD-Toshiba_Bluetooth	(0518111.snd)
MODULE	MOD-VAIO_Media	(0519301.snd)
MODULE	MOD-VAIO_Survey_Standalone	(0518615.snd)
MODULE	MOD-WinDVD	(0518607.snd)
MODULE	MOD-Wireless_Help_Utility	(0504904.snd)
MODULE	MOD-Wireless_Switch_Setting_Utility	(0518108.snd)
MODULE	XMOD-AOL_Software	(0519417.snd)
MODULE	XMOD-SonicStage	(0517302.snd)
Recovery	P1 Recovery Image	(0520914.snd)
Image
Data File	bitindex.ini	(0519625.snd)
Data File	LeonV-HE Data File	(0521334.snd)
Data File	module.ini	R (0520102.snd)
EPC	EPC_A-0198-LeonV_Latest_Information	(0521323.snd)
EPC	EPC_A-0199-Security_Updates_MS05-036_037	(0521602.snd)
EPC	EPC_A-0202-Security_Updates_MS05-038_039	(0523011.snd)
Foundation	FI-LeonV-HE	(0520208.snd)
Image
PAC File	FI-LeonV-HE PAC File	(0520209.snd)

13.6.11 RPT-11: Part Report

Attribute Name                 Description
Part Name                      Adobe Premiere Pro
Parent Planning Part           Adobe Premiere Pro
Active                         Yes
Major Version                  7
Part Type                      Installable Application
Part Sub Type                  Application
Dependency Append              None
Dependency                     Need: VAIO Edit Components 5.0
Install Order                  After: VAIO Edit Components 5.0
Customer Label                 Adobe Premiere Pro
Customer Desc                  ENU-US: Adobe's semi professional
                               video editing application.
BLID                           N/A
isDefault                      Yes
Champion                       Smith 1
Owner                          Smith 1
Localised By                   VOA
Target Series                  Hogwarts4-MC
                               Horizon2-HE
                               Horizon2-MC
                               Horizon2-PR
                               Horizon3_GD-HE
                               Horizon3_GD-MC
                               Horizon3_GD-PR
                               LeonS2-HE
                               LeonS2-PR
                               LeonV-HE
                               LeonV-PR
                               Messenger-HE
                               Messenger-PR
                               Sherry_WWAN-PR
                               Spirit2-HE
                               Spirit2-PR
                               Spirit3-HE
                               Spirit3-PR
Series Dependency              N/A
Supported LangRegions          ENU-US
Change Log
isTemporary                    No
Default Installer Type (select EXE
from list)
Default Setup File             Premiere.EXE
Default Command Line           -s -n
Arguments
Default OPK                    No
Default Base Plus              No
Default Recoverable            yes
Default Interactive            No
Vendor                         Adobe

13.6.12 RPT-12: Part Release Report

Attribute Name              Description
Release ID                  120123
Detailed Version            7.5.0.0
Release Name                Adobe Premiere 7.0
Target LangRegions          en_US
Release Notes               ***Install Instructions***
                            [WeberN - 7/16/04 12:10:00 PM]
                            Run Setup.exe
                            ***Uninstall Instructions***
                            [WeberN - 7/16/04 12:10:00 PM]
                            Uninstall via Add/Remove Programs
                            ***Release Notes***
                            [WeberN - Jul. 16, 2004 12:10:00 PM]
                            Adobe Premiere Pro 7.5, OEM 282
Status                      GM
Submitted By                Smith 22
Next Release                none
Virus Check                 dropdown: statuses TBD
WHQL status                 not applicable
PlmStatus                   dropdown: statuses TBD
Is Default Release          yes
Is Latest Release           yes
Version Path                C:\PROGRAM FILES\ADOBE\
                            PREMIERE PRO 7.5\ADOBE
                            PREMIERE PRO.EXE
Version ID                  7.5.0.000.1010
Version check before        Premiere.EXE version 7.5
installation
Change Log                  No record
Installed Folder Path       C:\PROGRAM FILES\ADOBE\
                            PREMIERE PRO 7.5\
Installer Place             TBD
Installer Type (select from EXE
list)
Setup File                  Premiere.EXE
Command Line                -s -n
Arguments
OPK                         no
Base Plus                   no
Recoverable                 yes
Interactive                 no
Repackaged                  yes
Snapshot ID                 n/a

13.6.13 RPT-13: Part Release Version Report 13.6.14 RPT-14: RTM Report

• • 1. User picks one Series/LangRegion.
  • 2. User picks one or more OSs.
  • 3. User selects which sub-reports to include.
  • 4. System presents format that can be loaded into MS Word for further editing. 13.6.15 RPT-15: Test Status for Series 13.6.16 RPT-16: Test Status for All Active Series 13.6.17 RPT-17: Defect Report for Individual Defect
  • Now referencing FIG. 25, the screen shot of a “Defect View” is shown, which includes the defect report. 13.6.18 RPT-18: Defects By User, Team, Series, Cycle, Etc. 13.6.19 RPT-19: Test Case Report
  • Now referencing FIG. 26, the screen shot of “Test Results: Update from test strategy” is shown. 13.6.20 RPT-20: Test Strategy Report
  • With reference to FIG. 27, the report currently being implemented is shown. This report must be adapted to the Epic Data Model. 13.6.21 RPT-20: Test Strategy Status Report 13.6.22 RPT-22: End-of-cycle Defect Report
  • 1. User picks one or more Series/LangRegion combinations.
  • 2. User picks one or more cycles or date ranges.
  • 3. User selects which sub-reports to include.
  • 4. System loads each report into separate worksheet (preferred) or separate excel document.

Defect Priority

	Fall 05	Sum 05
	Priority	Priority 0	58	82
		Priority 1	213	99
		Priority 2	263	139
		Priority 3	193	102
		Priority 4	22	4
		Priority N/A	146	114
		Total	895	540

Defect Severity

	Fall 05	Sum 05
	Severity	0	20	22
		1	192	120
		2	357	176
		3	203	127
		N/A	123	95
			895	540

Defect Exposure

	Fall 05	Sum 05
Exposure	LI	25	17
	HVCG	160	76
	LNFU	348	194
	LIDB	154	96
	VUS	101	59
	Blank	107	98
		895	540

Defect Resolution by Application Champion

Fall 05
	Champion	Fixed	Def/WNF	Other	Total
	Smith 23	3	0	3	6
	Smith 24	12	1	5	18
	Smith 18	0	1	2	3
	Smith 25	1	1	2	4
	Smith 26	21	4	18	43
	Smith 27	24	12	6	42
	Smith 28	9	1	12	22
	Smith 29	1	4	12	17
	Smith 21	8	11	4	23
	Smith 30	11	7	7	25
	Smith 31	16	9	19	44
	Smith 32	3	2	19	24
	Smith 33	2	1	7	10
	Smith 5	19	2	13	34
	Smith 19	20	2	1	23
	Smith 20	3	2	3	8
	Smith 34	6	8	20	34
	Smith 35	5	0	3	8
	Smith 12	11	4	13	27
	Smith 14	4	18	14	36
	Smith 10	49	32	58	139
	Smith 36	2	1	2	5
	Smith 3	42	23	38	103
	Smith 37	27	11	17	53
	Smith 9	4	4	9	17
	Smith 13	13	20	35	68
	Smith 15	9	35	4	48

Summer 05
	Champion	Fixed	Def/WNF	Other	Total
	jones1	0	2	2	4
	jones2	1	0	0	1
	jones3	6	6	16	28
	jones4	15	3	8	26
	jones5	7	6	4	17
	jones	14	3	11	28
	jones	8	10	45	63
	Jone	0	5	3	8
	jones	13	1	3	17
	jonesa	1	6	0	7
	jones	1	5	5	11
	jones	8	2	1	11
	Smith 19	1	0	1	2
	jones	4	1	1	6
	jones	13	3	17	33
	jones	26	7	16	49
	jones	9	2	2	13
	jones	0	2	1	3
	jones	71	10	25	106
	jones	3	3	6	10
	Winter	4	5	2	11
	jones	1	40	22	63
	jones	7	7	6	20

Defect Resolution by Module (First level applications on FI BOM should be included)

All resolutions-Fall 2005-Top Ten
Application	Sev 0	Sev 1	Sev 2	Sev 3	N/A	Total	P = 0	P = 1	P = 2	P = 3	P = 4	P = N/A	Total
HDD Kick Tool	0	29	34	12	14	89	0	34	21	18	2	14	89
NB Hardware	0	18	26	2	10	56	0	14	19	10	3	10	56
Other
VAIO	0	2	7	29	4	42	0	2	6	30	0	4	42
Registration
VAIO Support	8	0	11	18	2	39	12	0	6	18	0	3	39
Central
Desktop	0	16	10	2	2	30	1	15	10	2	0	2	30
Hardware Other
Sony Changer	3	6	14	7	0	30	3	7	14	6	0	0	30
S/W
Finger Print PS	0	2	19	5	1	27	0	0	15	9	1	2	27
IE Remote	0	11	8	6	0	25	0	11	12	2	0	0	25
Control
Extension
Kansas	0	5	10	10	0	25	25	0	0	0	0	0	25
Emerald/Kansas
SmartWi	1	2	6	7	8	24	1	2	9	4	0	8	24
Connection
Utility

All resolutions-Summer 2005-Top Ten
Application	Sev 0	Sev 1	Sev 2	Sev 3	N/A	Total	P = 0	P = 1	P = 2	P = 3	P = 4	P = N/A	Total
HDD Kick Tool	0	46	45	14	6	111	23	32	39	9	0	8	111
VAIO Control	0	2	18	13	10	43	1	7	11	11	1	12	43
Central
VAIO Central	12	0	9	5	6	32	24	0	0	1	0	7	32
Beta
Connection	1	0	2	21	4	28	0	0	12	9	1	6	28
Manager
SmartWi	0	0	1	16	9	26	0	1	3	12	0	10	26
Connection
Utility
Emerald Beta	1	7	5	3	3	19	14	0	0	2	0	3	19
VAIO	0	0	5	5	4	14	0	1	1	8	0	4	14
Registration
Intel Graphics	0	2	3	3	5	13	0	2	4	2	0	5	13
Windows Media	0	2	4	2	3	11	0	2	2	4	0	3	11
Center
AOL	0	5	1	1	2	9	0	3	2	2	0	2	9

Top Ten Deferred/Will Not Fix Defects

Top Ten Deferred/Will Not Fix Fall 2005
Application	Sev 0	Sev 1	Sev 2	Sev 3	N/A	Total
VAIO Registration	0	0	4	27	0	31
HDD Kick Tool	0	1	10	9	0	20
VAIO Support Central	0	0	5	13	0	18
Windows MCE	0	0	4	8	0	12
Notebook Hardware Other	0	1	8	2	0	11
Sony Changer S/W	0	1	4	4	0	9
Fingerprint Protection Suite	0	0	3	3	0	6
Intel 915G Graphics	0	0	4	2	0	6
MOD-Wireless Connection	0	0	1	5	0	6
Utility
Libertas 802.11bg Wireless	0	1	0	4	0	5

Top Ten Deferred/Will Not Fix Summer 2005
Application	Sev 0	Sev 1	Sev 2	Sev 3	N/A	Total
Connection Manager	0	0	2	18	0	20
SmartWi Connection Utility	0	0	0	15	0	15
HDD Kick Tool	0	3	6	1	0	10
Emerald Beta	1	0	1	2	2	6
VAIO Registration	0	0	2	4	0	6
Intel Graphics	0	0	2	3	0	5
VAIO Control Center	0	0	2	3	0	5
Windows MCE	0	0	3	2	0	5
AOL	0	2	1	1	0	4
VAIO Central Beta	1	0	2	0	0	3

13.6.23 RPT-23: Build Count

			FI	Recovery
	Project	OS	Builds	Media Builds
	Horizon2	MCE	4	1
	Horizon2	HE	2	2
	Mare4/Viento4	HE	4	4
	Spirit2	HE	3	3
	Spirit2	PR	3	3
	JediH2	HE	2	3
	LeonS2	HE	2	2
	LeonS2	PR	2	2
	Horizon2	LA	2	2
		HE
	Viento	LA	2	2
		HE
	Horizon2	PR	2	2
	Spirit2	LA	4	2
		HE
	Spirit2	LA	4	2
		PR
	LeonS2	LA	2	2
		HE
	LeonS2	LA	2	3
		PR
	Spirit2	FC	2	2
		HE
	Aroma3	HE	4	5
	Aroma3	PR	3	5
	Aroma3	LA	2	2
		PR
	Hogwarts4	MCE	4	4
	Hogwarts4	LA	2	1
		HE

While the particular SYSTEM AND METHOD FOR SOFTWARE INTEGRATION AND FACTORY DEPLOYMENT is herein shown and described in detail, it is to be understood that the subject matter which is encompassed by the present invention is limited only by the claims.

Claims

1. A method for managing computer production in an enterprise, comprising: receiving a block of software offerings, each block being associated with at least one product series; receiving a product series component structure defining parts for a respective product series; adding parts required for a product series to the block associated with the series, parts being assigned to each software class and related software specification pair in a block based on the part or parts required for the pair to thereby define a design structure; and establishing a software bill of materials (BOM) based on the design structure using at least one of: a template and/or a snapshot.

2. The method of claim 1, further comprising: defining software offerings, a software offering including at least one software class and at least one associated software specification; associating at least one software offering with at least one product series in a plurality of series to establish a configuration, configurations cumulatively defining a configuration range that contains product offerings of the enterprise for all regions in which the enterprise does business; and grouping classes into blocks, a block being associated with at least one product series.

3. The method of claim 2, comprising defining which classes are dependent on each other.

4. The method of claim 3, comprising defining which blocks are base blocks.

5. The method of claim 1, comprising associating defects with related classes.

6. The method of claim 5, comprising associating corrective actions with respective defects.

7. The method of claim 6, comprising associating a respective installation file with each software offering, each installation file including a data file format version number, a version number of an installation data snapshot, an installation order for modules, data required for confirming successful installation, cyclic redundancy check (CRC) data for each binary file, path information for locating files in a file store, partition size information for recovery and customer partitions.

8. The method of claim 7, wherein installation and recovery tools use a list of software releases directly instead of microcode, which is used only for customer recovery, with microcode bit mappings being constrained to respective recovery media sets.

9. A software management database on a computer readable medium, the database containing: data structures supporting computer software provisioning for a range of CTO/BTO variations, language variations, region variations, and operating system variations.

10. The database of claim 9, comprising: bill of materials (BOM) entities, each BOM entity containing information related to parent BOMs and child BOMs, if any, each BOM entity also including at least one engineering part ID, at least one software release ID, at least one major version ID, at least one group ID, at least one component ID, at least one planning parts ID, and at least one software series ID; and at least one plan parts entity including launch dates for software base releases, import dates for software bases indicating when the bases were imported into computers, identifications for software bases.

11. The database of claim 10, comprising at least one components entity including launch dates for software base releases, import dates for software bases, identifications for software bases.

12. The database of claim 11, comprising at least one software release entity containing a base ID, a name, a file path, a launch date.

13. The database of claim 12, comprising at least one software release status entity including data representing status and name of a software release.

14. The database of claim 13, comprising at least one group entity containing data representing a name and launch of a type.

15. The database of claim 14, comprising at least one series entity containing a software series ID, base ID, name, an indication of being active, a launch date, an import date.

16. The database of claim 15, comprising at least one engineering parts entity containing an engineering part. ID, a base ID, a type ID, a name, a launch date, and indication of dependent parts.

17. The database of claim 16, comprising at least one engineering parts major revision entity containing information related to default use.

18. The database of claim 17, comprising at least one engineering part software release entity containing information on a related engineering part entity, a related engineering parts major revision entity, a related language code entity.

19. The database of claim 18, comprising at least one language entity containing information related to a language name and a language code.

20. A computer-implemented system for creating bills of materials (BOMs), comprising logic executable by a computer and stored on a computer readable medium, the logic: facilitating creation of BOMs using templates and/or snapshots.

21. The system of claim 20, wherein BOMs are automatically generated based on part attributes and groups of parts, major versions, and releases.

22. The system of claim 20, wherein the logic automatically checks BOMs to reduce errors.

23. A computer system executing logic stored on a computer readable medium, the computer system: entering, into a first database, first software data, the first software data including operating systems and configure to order/build to order (CTO/BTO) options; transferring at least some of the first software data in the first database to a comprehensive global database; and automatically adding to a bill of materials (BOM) through the comprehensive global database second software data, the second software data including one or more of operating system updates, device drivers, utilities.

24. The system of claim 23, wherein software along with metadata that describes the software is checked into the comprehensive global database by users.

25. The system of claim 24, wherein the BOM for a specific series/language/region is frozen/locked and the process to create factory deliverables including software image, software modules, and data) is then begun.

26. The system of claim 25, wherein factory deliverables derived from the comprehensive global database are tested and validated to meet quality standards, the factory deliverables, and metadata that describes them, then being delivered to a factory to be used in mass production.

27. The system of claim 26, wherein the comprehensive global database supports software variations in CTO/BTO, language, region, and OS, the comprehensive global database facilitating the creation of CTO systems, based on individual customer orders, in a mass production process with every piece of software preinstalled and ready to use.

28. The system of claim 28, wherein the comprehensive global database facilitates automatically mapping hardware components to software releases.

29. The system of claim 28, wherein the comprehensive global database facilitates specifying language and geographic region for each software release at the time of software check-in, with a correct release being assigned to each BOM automatically.

30. The system of claim 29, wherein the comprehensive global database facilitates creation of BOMs using templates and snapshots for efficiency, the BOMs being automatically generated based on part attributes, groups of parts, major versions, and releases.

31. The system of claim 29, wherein the comprehensive global database facilitates automatic checking of BOMs to reduce errors.

32. The system of claim 29, wherein the comprehensive global database facilitates use of a list of software releases directly instead of microcode, with microcode bit mappings being constrained to each recovery media set that is defined.