Home > SW Release Phase 2 – Scope Definition

SW Release Phase 2 – Scope Definition

   
Software Release Process – Phase 2 Scope Definition  

 

Software Release Phase 2 – Scope Definition

What:   This document covers Phase 2 of a Software Release Life Cycle.    It includes a  one-to-two page description of recommended deliverables for this phase.

The requirements for what to possibly include in a release - major projects, minor projects, enhancements to previous products, bug fixes to existing software, integration of previous release patches, etc. -  was collected in Phase 1.     The Scope Definition Phase is now focused on identifying an initial proposed scope for the release, by translating those requirements into  an initial high level plan.    The management staff must create a picture of the desired upcoming release via a reasonably well-understood set of tasks, deliverables and  resource needs.  That plan will be used in phase 3 to make trade-offs and compromises as necessary to allocate time, personnel, equipment, etc.

Why:    The stakeholders for a SW release can be extensive, ranging from the end-user of the software up to the executive staff, and down through many different cross-functional teams and departments.  Many of these stakeholders will have a limited view of the total scope of a large SW release and the business drivers behind different aspects that are competing for resources. They may have a vested interest in potentially a very small portion.  Many stakeholders may be completely unaware of the predecessor requirements for their desired feature or function.  Before a full release plan is committed to, tradeoff decisions will be necessary.  Some projects may not stay in this release but rather be delayed to the next one due to resource issues.   Some enhancements may be likewise left out.   

The scope definition resulting from this phase will provide a concise description of all the requests, bug fixes, planned projects, requirements, etc. that are to be in the release, and show their time and resource usage in a high-level release plan.  This will allow the various decision makers to make informed choices when deciding where to allocate resources and understand  expected schedule for the release. 

How:   Review the deliverables suggested in this document (See Checklist on the next page).  Adjust for your particular organization,  project type, or company. 

Perform the activities described in those deliverables.  See the Software Release Life Cycle Team Member Glossary if you have questions about the roles listed as Driver and Contributor for a deliverable.

At the end of this phase, you will be prepared for Phase 3, Negotiation and Planning, during which tradeoff decisions will be made as necessary to settle on a final release definition and detailed release plan. 

Related documents:

Software Release Life Cycle Overview

Software Release Life Cycle WBS

Software Release Team Member Glossary 

 

About the Author

Peter Michels has served as Director of Engineering and Program Management, Senior Project Manager, Software Development Manager and software developer in large and small companies with most recent focus in commercial wireless and 802.11 network  communications. 

Pete's professional interests are in project recovery, organizational behavior and organizational restructuring. 

It has been commented that Pete has a higher tolerance level than average for negativity, which he explains must be the reason he enjoys, remains in and excels at the project management profession.  Pete has also been quoted as saying "almost everything is a project of some sort."  Apparently, he uses MS Project for many personal activities too.  Pete firmly advocates that schools should teach basic project management along with consumer economics and shop classes.  Pete has an irreverent sense of humor and finds a something amusing in most projects or programs.  Pete's last team shirts read "If you can't juggle, don't join the Circus" next to a juggling clown  logo on a unicycle with the sleeve reading "Ringmaster." 

Pete contributed this series of software release life cycle overview documents and templates from his hard-won experience putting together software release methods in a growing software company.  Even as the company grew a sound process for developing each  hardware/software project, they found they needed an overlay to help with planning of their overall releases-- which often brought together 10-20 individual  (and complex in themselves) software and platform projects, as well as numerous feature enhancements, to enable them to make the necessary releases to the market. 

The deliverables defined in this document, as well at the others in the Software Release Life Cycle series, can be adapted and used for planning of various kinds of software releases. 

NOTE: This document is written in the form of a typical development process reference.    If you are trying to create a methodology document for your software release teams, you can edit this document and the other SRLC phase documents to form your process reference 
 

 

Software Release Phase 2 – Scope Definition 

Checklist for Phase 2 Scope Definition Completion 

Check Document # Document Description


q 2.1 Draft Release Vision
q 2.2 Software Architecture Specifications
q 2.3 Preliminary Release Staging and Benchmarking Plan (RSBP)
q 2.4 Preliminary Work Breakdown Structure (WBS)
q 2.5 Preliminary Risk Management Plan
q 2.6 Preliminary Resource Plan
q 2.7 RSBP, WBS, Risk & Resource Plans Review Meeting
q 2.8 Distribute Preliminary Release Plans
q 2.9 Scope Definition Phase Exit Criteria
 

Each ��Deliverable�� document includes:

Document Name: The name of the document and the phase of the software release process during which it is delivered.

Driver:  Person primarily responsible for making sure the tasks are accomplished and accomplished correctly.  Not necessarily a contributor to the deliverable:

Contributors:  List of persons with knowledge about or responsibilities for the accomplishment of the tasks.

Prerequisites:  Any activities that must be performed before the Driver and Contributors can complete these tasks.  Some of the Phase 2 Scope Definition prerequisites may come from individual project or product development teams.  These deliverables may have a different name than referenced in this document, but are still considered prerequisites to complete the phase.

Purpose and Audience: Describes why this information is needed and who needs it.

Recommended Accomplishments: List of recommended deliverables content, related activities, and decisions that should be accomplished before the deliverable is considered complete. 

 

Draft Release Vision

Deliverable 2.1

Driver: 

      Software Release Project Manager

Contributors:

      SW Project Leaders, Release Team, Product Managers (Marketing), Customer Service

Prerequisites:

      Phase 1 Requirements Gathering Exit criteria met

Purpose and Audience:

      This is an "aligning document". It records the release team��s common agreement on the purpose of the release, benefits to the customer, and major features of the release and system being developed.  Ensures that all interested parties agree on the scope of the release.

      The requirements gathered in phase 1 are what could be included in the release.  The Release Vision is used to think through and document the release scope with a focus on customer needs.

      Used by all release team members and stakeholders as the established and limited set of release objectives- forms the "contract" for the release. Must be formally endorsed by the release team, with any future changes approved by the team as well.

      States what is in the release and what is NOT.

Recommended Accomplishments:

      The following inputs (discussed in the Phase 1 Requirements Gathering document) should be considered for total or partial inclusion in a release vision:

      • New Product Proposals from the marketing department.
      • The product development department��s project priority list with systems upgrades, technology innovations, ongoing maintenance, etc. issues.
      • Long-term maintenance needs, like operating system or customer equipment obsolescence.
      • Software Maintenance Plans (from previous projects)
      • System infrastructure needs or requirements that may not be part of a product
      • 3rd party developed software changes, upgrades, etc. that are used in the software being released.  These include libraries or packages licensed  or customized for use from other companies, etc.
      • Vendor-supplied software.  These include operating systems, databases, web infrastructures, server software, etc.

Continued next page

 

Draft Release Vision

Deliverable 2.1 (continued)

      Bring the early release planners together to discuss the drivers for the release- what are we trying to do for our customers? What does this release need to accomplish for the company?  When do we need to ship?

      Then discuss how the requirements gathered in phase 1 map to the above release drivers.  Prioritize the requirements gathered in phase 1.

      Use the content outline below to create the Vision draft, documenting what the early team feels about the main drivers for the release, and the features etc. that should be included because they are important to meeting the release goals.

      Provide a "business case" - a Cost/Benefit Analysis with the Release Vision, where useful to help with decisions as to how important certain requirements are.    

      Review the draft vision with stakeholders, make updates, distribute it for reference as the release proceeds through phase 2, and update it throughout.   

      Recommended Contents of a Release Vision:

          • Introduction and description of the release (brief) - summarize its purpose. What is it, and why do it now?
          • Target customers, their problems or needs, and the benefits this release provides to the overall goals of the company.
          • Strategic requirements of the company that the release will solve or enhance.
          • Key issues customers will use to judge the quality (measures of success) of the release.
          • Key technologies and key features that are changed or added to the system in this release (summary- this is not a detailed requirements spec).
          • Crucial release factors such as:
          • Migration from previous releases
          • Interaction with components, objects or packages from previous releases
          • Proposed potential for system extensibility, expansion, maintenance or functionality growth (show how SW can extend, if needed)
          • Physical environments effected by the release
          • Safety and liability issues
          • Quality and reliability issues
          • Ergonomics and usability
          • Users�� abilities (or not and why i.e. what got traded off?)
          • Distribution method and deployment of the release
          • Documentation, training, servicing, maintenance and distribution issues
          • Key "measurables" - Scheduled release date, financial targets, budget limitations.
       

      Software Architecture Specifications

      Deliverable 2.2

      Driver: 

          Software Chief Architect, Software Engineer(s)

      Contributors:

          SW Project Leaders, Software QA Engineers, Product Managers (Marketing), others as needed

      Prerequisites:

          2.1 Draft Release Vision

      Purpose and Audience:

          To identify and record the functions, interfaces, methods and performance of the SW release��s major modules and subsystems as envisioned by the Chief Architect. This definition will be used by team members on the individual project teams and those software engineers responsible for detailed designs as they break down requirements to methods and functions, then break down methods and functions into manageable work units.

          The SW Release Project Manager also uses the SW Architectural Specification to ensure that the release schedule includes tasks for the subsystems and modules to be developed in later phases, providing as accurate as possible an early estimate of development and support work to be done during the release.

          Provides early detailed interface definitions for subsystem development and for generalized context reference to the SW release team.  Gives the engineers and team members involved in the integration and testing phases a basis and expectation for making estimates of work effort before the individual subproject designs are completed.

          Captures high-level design decisions and agreements between cross-functional departments to prevent unnecessary revisiting of decisions.

          Provides a large scope, high-level document for new department members, new team members and executive staff to quickly familiarize themselves with the subprojects contained in the SW Release.

          Provides a quick reference to weak points in sub-designs or areas requiring more attention and what design documentation is missing early in the release process.

      Recommended Accomplishments:

          NOTE:  this is a first-pass creation of this document early in release planning.

          Definition of large level hardware and software blocks. Name the interfaces and key technologies.

          Create an Architectural Context Diagram & Description (Include glossary if Architectural Design Language is used.) 

          Continued next page

       

      Software Architecture Specifications

      Deliverable 2.2   (continued) 

      Provide subsystem descriptions, including diagrams, explanation of functions, methods, performance issues and requirements, design constraints, allocation of system components, arbitration of shared system components

      Include synopsis of any system modeling and simulation results.  Include an explanation for any architecture decisions derived from the modeling or simulation results.

      Interfaces — For large system release, this work may be in preliminary form only and be completed later.

      Diagram and documents of interfaces between subsystems — physical descriptions, references to protocols used and any detailed definitions of any messages passed between subsystems.

      External interfaces — document any physical or system requirements or constraints, reference and standard protocols or protocol sub-sets, file i/o, client or server mechanisms external to the SW release,  commercial databases used, etc..

      As the architecture specifications mature with time, individual projects, products and subsystems descriptions should include the functional blocks and interfaces within each subsystem.

      Cross platform or particular platform-specific interface requirements and issues should be documented.

      Make sure any external or supporting documentation is referenced.

 

Preliminary Release Staging and Benchmarking Plan (RSBP)

Deliverable 2.3

Driver:

      Software Release Project Manager

Contributors:

      SW Project Leaders, SW Release Team, Product Managers (marketing), Software QA, Customer Service, Executive Staff, other Release Stakeholders

Prerequisites:

      Phase 1 Preliminary Planning Exit completed

      2.1 Draft Release Vision

      2.2 Software Architecture Specifications reviewed

Purpose/Audience:

      Provide the draft high-level description of the expected phases and management approach for the release.  Providing this information early in the release process allows all the stakeholders to review the process and provide early feedback.

      Some information, even if details are minimal, will provide stakeholders and readers of the Plan with an overview and initial understanding of the software release and begin to set expectations.  To accomplish this goal, explain the release stages, release benchmarks, and decision criteria for completion of phases and key milestones, conditional branches and benchmarks.

Recommended Accomplishments:

      Describe key blocks of work.  Explain expected accomplishments of major activities in general terms.  For example

  • Early System Software Integration (Milestone 1)
  • Proprietary Object Library (package) Integration (Milestone 2)
  • Application XXX to Package Integration (Milestone 3.1)
  • Application YYY to Package Integration (Milestone 3.2)
  • Complete sub-system Integration (Milestone 4)

      Describe the major milestones defined for the software release.  These are the general milestones of a release and include the common milestones similar to a development project using the company��s PDLC.  These will also include major stage milestones.  SW releases may include many larger subprojects and certain ��normal�� milestones may have multiple measurable instances.  Some examples are:

  • "Planning Complete"
  • "Integration Complete"
  • "Alpha Build Complete"
  • ��Integration Stage 1�� & ��Integration Stage 2�� & ��Integration Stage 3��

      Continued next page 

 

      Preliminary Release Staging and Benchmarking Plan (RSBP)

Deliverable 2.3   (continued) 

      Describe the general phases of the release and any additions or exceptions to the proscribed processes for this release.  Since the release may include software projects using different type of project life cycles, like staged development, evolutionary development or iterative development life cycles, also include any special cases this causes in the software release.

      Describe any conditional code branches from the standard code base that are expected during the release.  There may be specific branches of the release to support large hardware projects, demonstration projects, customized releases, internationalized, homologation or site specific requirements.

      Describe the benchmarks that will be used for this release.  Select various benchmarks to judge the state of the software release as it progresses through the release process.  Review the risk management plans of the software subprojects for critical issues and potential problem areas.  Remember that benchmarks are planned decision making points with predefined criteria so that the team can quickly and decisively take action.  Since they use pre-planned decision criteria, they are most useful when a benchmark fails and the team can immediately take the pre-planned decision path.  Some examples are:

  • Quality Assurance benchmarks

    • Schedule slippage benchmarks
    • Events preceding the decision to include or exclude a specific project in the release benchmarks
    • Performance benchmarks
    • Note:  There are many ways to categorize the definition of benchmarks.  The ones mentioned above are just suggestions and the team should decide what is important.

        Describe any special cases within the release for including

    • small projects
    • dedicated time for bug fixing by project teams
    • dedicated time for adding specific enhancements that are not included in the projects included in the release
    • any dedicated or allocated time periods using all or part of the staff for bug fixing (AKA dedicated ��bug fix�� week)

     

    Preliminary Work Breakdown Structure (WBS)

    Deliverable 2.4

    Driver:

        Software Release Project Manager

    Contributors:

        SW Project Leaders, SW Release Team, Software QA, Customer Service

    Prerequisites:

        Phase 1 Exit

        2.1 Draft Release Vision

        2.2 Software Architecture Specifications (can start with partially completed)

        2.3 Preliminary Staging and Benchmarking Plan (start w/ partially completed)

    Purpose/Audience:

        This is the WBS for the high-level software release (the super project).  The individual development projects will have their own WBS-es.

        This document serves as the master WBS for the entire release.  This preliminary version is really an umbrella for large-scale deliverables and any activities not specifically allocated to a development team doing a large or small project.

        As the master WBS, it is used to communicate the same high-level scope and early planning information to all teams, individuals, Executive staff, department managers, marketing and all other stakeholders of the release.  Note:  The information may be transformed into other reports like MS Excel or MS PowerPoint, but the source of the information is the master WBS.

        The master WBS will be used later to plan the remainder of the SW release in detail and communicate projections for the release's critical path, task interdependencies, work breakdown and resource assignments. It will be developed to show the detailed investment in time and resources needed to complete the release.

    Recommended Accomplishments:

        The WBS is a working document.  Use the information available from Phase 1 and the 2.2 SW Architecture Specifications, knowing that this information is preliminary at this point and will change.

        Itemize the SW release phase gates (of the super project) and the separate stages identified in the 2.3 Preliminary Staging and Benchmarking Plan

        Include estimates of the duration of each major task. Solicit input on work effort estimates from individual team members and appropriate project leaders.

        It is strongly suggested that project management planning & scheduling software is used.

        Assign tasks to individuals or teams, if that information is known.  Assign tasks to groups for future manpower loading analysis.

     

    Preliminary Work Breakdown Structure (WBS)

    Deliverable 2.4 (continued) 

      Identify SW release level project management and administration activities, including:

  • Reviews (code, specification, plans, etc.)

    • Meetings that are outside the norm (for example, the 2 four hour schedule review meetings to review this document!)
    • Vacations, holidays, etc.
    • Any early production issues for limited release system builds and distributions

        Include all SW release level milestones and deliverables.

        For planning purposes, you may want to show development projects as bulk time lines at this point.  Your release-level WBS would then communicate quickly the scope of the release in terms of what individual projects will be included.  This allows resources from that project team to be added to the WBS so that even at this early date, you can review the rough initial plan for potential resource allocation issues.  For instance, insert project X of 5-month duration with a start date and the names (or generic functional groups)  of the project members at 100% assignment.

     

    Preliminary Risk Management Plan

    Deliverable 2.5

    Driver:

        Software Release Project Manager

    Contributors:

        SW Project Leaders, SW Release Team, Product Managers (marketing), Software QA, Customer Service, Executive Staff, other Release Stakeholders

    Prerequisites:

        Phase 1 Exit

        2.1 Draft Release Vision

        2.2 Software Architecture Specifications (can start with partially completed)

        2.3 Preliminary Staging and Benchmarking Plan (start w/ partially completed)

        2.4 Preliminary Work Breakdown Structure (WBS)

    Purpose/Audience:

        This Risk Management plan identifies critical issues, unknowns and unbounded issues that might be encountered by the SW release team during the process.

        This preliminary Risk Management Plan will eventually include or reference the individual development projects Risk Management Plans.

        The purpose of doing a preliminary risk plan is to identify the amount of risk in the envisioned release, and as quickly as possible determine whether too much risk is being taken on; ascertain the level of risk management that will be required; and thus aid critical decisions on release scope.

    Recommended Accomplishments:

        Document all risks with:

    • Probability that it will occur
    • Severity of the impact if it does occur (time or money)
    • Name of individual that is responsible for managing the risk
    • Any contingency plans if the risk is actualized.

        Document risks in technology for the SW release, like new test tools, new configuration management tools, etc.

        Document any development project inter-dependency risks.

        At this stage, there will probably be resource allocation risks.

        From the architecture and stage definition information, identify any time or resource risks (most likely during integration periods).  These may already be partially identified in the RSBP as benchmark issues.

        For each risk, also identify it's benefit to the release:  I.e., why do we need to take on this risk at all?  Can we justify the cost?

     

    Preliminary Resource Plan

    Deliverable 2.6

    Driver:

        Software Release Project Manager

    Contributors:

        SW Project Leaders, SW Release Team, Product Managers (marketing), Software QA, Customer Service, Executive Staff, other Release Stakeholders

    Prerequisites:

        2.2 Software Architecture Specifications

        2.3 Preliminary Release Staging and Benchmarking Plan (RSBP)

    Purpose/Audience:

        Although it may seem premature, having a resource plan early in the process will provide visibility to everyone on whether there are adequate resources available to do the SW release with the defined scope and within the time allotted.  We can find out quickly if the initial scope envisioned for the release is unreasonable or outright undoable, and be set to make decisions in phase 3 as to whether to drop projects or features from the release, take on additional resources to enable the bigger release, etc.

        Also provides visibility of the needs for shared physical resource by identifying assumptions about test equipment, software, servers, databases, configuration management software, etc., to aid in scope planning and high-level budgeting.

    Recommended Accomplishments:

        It is strongly suggested that project management planning & scheduling software is used and integrated with the WBS (Gantt, etc.).

        Eventually the resource plan will have each person identified with a unique moniker (their name or initials) and identify a work capability level for each of individual.  The earliest version of the resource plan may use generic functional resource names (e.g. Senior Software Engineer) to help understand aggregate needs per functional group, well before exact resource assignments "by name" would be made.

        Add schedules to the resource plan for each person with their expected absences from holidays, vacations and other expected commitments.

        Make sure that all subprojects in the release are using the same resource plan.  This ensures that every individual is uniquely identified across all projects within the release when the SW release master WBS is "rolled up" with all the development project WBS-es.

        Identify any test equipment, software, servers, databases, configuration management software, etc. not dedicated to an individual's work effort.  Call out any needed physical resource that does not currently exist at the company.

        Identify any physical property needed, like labs or extra cubicles.

     

    RSBP, WBS, Risk & Resource Plans Review Meeting

    Deliverable 2.7

    Driver: 

        Software Release Project Manager

    Contributors:

        SW Managers, Software QA Manager, SW Release Team, Product Managers (Marketing), Customer Service, Executive Staff, other Stakeholders

    Prerequisites:

        2.1 Draft Release Vision

        2.2 Software Architecture Specifications (can start with partially completed)

        2.3 Preliminary Staging and Benchmarking Plan (start w/ partially completed)

        2.4 Preliminary Work Breakdown Structure (WBS)

        2.5 Preliminary Risk Management Plan

        2.6 Preliminary Resource Plan

    Purpose and Audience:

        To review the proposed Release Staging and Benchmarking Plan and understand the associated impacts on the release resource load, schedule and cost. The review meeting minutes record a consensus on the way the release will proceed with detailed activities.

        The documented decisions and results of this review meeting provide guidance and direction for decision making later in the release, lowering the need for debate later (and probably under significantly higher stress levels and time pressure).

        Depending on the scope, complexity and size of the proposed software release, more than one meeting may be required to achieve this deliverable and changes may result from the reviews.

    Recommended Accomplishments:

        Review projects being considered for this release and associated schedule, resource use and budget implications.  (Even though data is very preliminary at this stage of planning, some tradeoff decision areas may emerge)

        Closely review large system enhancements and new technology projects.  Consider how their complexity will impact the release schedule and budget.  Discuss whether partitioning or decomposing the larger enhancements would be a safer approach.  Review alternatives to unknown or complex new technology.  Review if new technology can be invested in smaller steps.

        Consider if the proposed plans and schedules will meet internal and external customer needs and whether the release will provide these customers with timely, needed solutions.

        Continued next page

     

    RSBP, WBS, Risk & Resource Plans Review Meeting

    Deliverable 2.7 (continued) 

      Publish minutes indicating decisions and next steps. Use standards set in the company��s ��Meeting Guidelines and Schedule.��

      During these meetings, answer the questions:

  • Are we trying to do too much?

    • Is the number of major innovations appropriate for our current skill level and resources?  Are separate projects making major innovations that combined, make the total technology risks excessive?
    • What is the severity of resource risks?  Are there any reserves for fire fighting and crisis management, if needed?
    • Will all committed contract obligations be met?

        Ensure all needed, cross-functional people, are involved in reviewing the Plans.

        Define next steps.   Are we ready to exit phase 2- have we agreed upon the scope such that it is time to form the full release team and move to phase 3?

        What scope issues are open, and to be resolved in phase 3 as more project-level information becomes available that will let us refine our risk assessments, estimates, etc.? 
         

         

        Distribute Preliminary Release Definition

        Deliverable 2.8

        Driver:

            Software Release Project Manager

        Contributors:

            Everyone that has anything to do with the release

        Prerequisites:

            2.1 Draft Release Vision

            2.2 Software Architecture Specifications (can start with partially completed)

            2.3 Preliminary Staging and Benchmarking Plan (start w/ partially completed)

            2.4 Preliminary Work Breakdown Structure (WBS)

            2.5 Preliminary Risk Management Plan

            2.6 Preliminary Resource Plan

            2.7 RSBP, WBS, Risk & Resource Plans Review Meeting

        Purpose/Audience:

            Communicate the SW release preliminary scope information to everyone involved.

        Recommended Accomplishments:

            Make copies for everyone.

            Distribute copies for everyone.

            Use the checklist that follows to get critical signatures that the SW release has appropriate initial scope definition and the preliminary plan is approved.

            Communicate what the next steps will be in release definition and planning. What scope issues are open, and to be resolved in phase 3 as more project-level information becomes available?

         

        Scope Definition Phase Exit Report

        Form 2.9

        Scope Definition  Activities Checklist


        q Draft Release Vision - first version created documenting the whys and whats of the release at a high level.
        q Software Architecture Specifications - reviewed and information disseminated and available to all project teams.
        q Preliminary Release Staging and Benchmarking Plan (RSBP) - plan reviewed and process for the SW release is defined.  Includes work effort not allocated to development project teams.
        q Preliminary Work Breakdown Structure (WBS) - SW release master WBS - very high level- is created, reviewed and distributed.
        q Preliminary Risk Management Plan - risks identified by priority and severity and contingency plans documented with responsible individuals names included.
        q Preliminary Resource Plan - people and things needed for the SW release are identified, the rough time periods and percentage they are needed.
        q RSBP, WBS, Risk & Resource Plans Review Meeting - everyone involved in the release has debated, groaned, voiced opinions, etc. about the preliminary plans and given their approval.
        q Distribute Preliminary Release Definition - everyone has received copies of any of the SW release documents that they need.
         

        Team Member Approvals (adjust as appropriate for your organization)


        SW Release Project Manager:  Date:        
        Executive Sponsor:  Date:        
        Development Director:  Date:        
        Marketing Director:  Date:        
        Customer Service Director:  Date:        
        Software QA Manager:  Date:        
        SW Manager (Systems):  Date:        
        SW Manager (Applications):  Date:        
        SW Manager (Embedded):  Date:        
        SW Manager (Networks):  Date:        

Search more related documents:SW Release Phase 2 – Scope Definition

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#nuokui.com
TOP