S3000 A- Design Approach by NiceTime

VIEWS: 0 PAGES: 4

									University of Michigan Administrative Information Services
LC Methodology

         M3000A - Design Phase Approach Document

SDLC Design Phase Approach

I. Introduction
This Design Phase Approach Document is designed for the University of Michigan Administrative
Information Services’ (MAIS) System Development Life Cycle (SDLC) projects.

A. Purpose
The intent of the Design Phase is to produce Design documents that describe the functional and
technical aspects of a requirement(s), providing sufficient detail and information in a standardized
format that allows for coding in the subsequent Development and Unit Testing phase. Repeatable,
consistent processes and comprehensive documentation support this goal. The end result should be
increased quality (correctly implementing the Requirements), and the reduction in delivery time and
effort needed for subsequent projects.

II. Design Phase Approach
A. Approach Description
The general methodology/approach for the SDLC Design Phase at MAIS will involve the following
steps:
       1. Initial planning efforts for this phase will include the establishment of a:
               a. Project Status reporting approach.
               b. Defect Tracking approach.
               c. Metric Collection approach.
       2. (If New Hardware or Configuration) Perform SDLC Environment Setup & Validation Process
          (9000).
       3. Design Analysis Activities.
               The proposed change (Modification) to a PeopleSoft-based code can be classified as
               applying to a) existing PeopleSoft code, and/or b) existing custom code, and/or c)
               additional code needed to develop new PeopleSoft Business Process functionality that
               is not delivered. For the newly identified or carried-over Modifications, an M225
               Requirements Document, which generally describes the proposed change, was
               produced in the preceding Requirements/Analysis phase, and is the basis for the
               Design document.

                      a.   Review the S225 Requirements Document.
                      b.   Review existing and/or proposed Business Processes & Workflows.
                      c.   Review existing Functionality in current system.
                      d.   Review Release Notes, if applicable.
                      e.   Were Compare Reports Needed?
                           i.   Analyze and Review the Compare Reports which were generated in the
                                Requirements/Analysis Phase.



5f70d5d9-3995-437d-a434-c9cf7227f5b6.doc    Last Updated: 8/3/05                   Page 1 of 4
University of Michigan Administrative Information Services
LC Methodology

         M3000A - Design Phase Approach Document

                      f.   Review and Update any existing inventories of RDA’s, Reports, Batch Jobs, or DW
                           Tables, Records, Fields if needed.

         4. Create the Design.
                 a. Create a Functional description of the change, impacts on other groups,
                     assumptions, and issues, by using the S225 Requirements Document as a
                     starting point.
                 b. Create a Technical Description of the change.
                            Online Objects (Views, Pages, Components, Records, etc.)
                            Batch Objects (SQR, Cobol)
                            Interface Objects (SQR, Cobol, App Engine)
                            Report Objects (SQR, Cobol, Crystal, Query)
                            Data Warehouse Objects (Tables, Records, Fields)
                            Security
                            Systems
                 c. Follow-up notification with any groups which may be impacted by this Design
                     Document. The initial notification to impacted groups should have already
                     occurred in the Requirements/Analysis phase.
                 d. Review the initial Design Document with any impacted groups or teams, noting
                     any feedback or changes requested needed.
                 e. Create an Initial Unit Test Plan, using the S404 Unit Test Plan template as a
                     starting point.
         5. Review the Design.
                 a. Hold a Design Team (Peer) review of the Design Document, using the M225
                     Requirements document as a reference.
                 b. Hold a Cross-Team review of the Design Document, using the M225
                     Requirements document as a reference. Impacted groups (those who are
                     impacted, and those who will be impacted) should understand the intent of the
                     design.
                 c. Hold a Customer review, if needed. The Customer should acknowledge the
                     Design as sufficiently meeting the requirements as stated.

III. Status and Reporting

A. Error Tracking Approach
During the Design Phase, problems and errors encountered with Requirements/Analysis Phase
Deliverables and/or Design Phase Deliverables will be noted in the “Modification Log” in their
respective documents. The documents will then need to be reviewed by all impacted groups. Errors
will also be tracked within the Tracking Spreadsheet/Database. Tech Leads will be responsible for
ensuring that the Tracking Spreadsheet/Database is kept up-to-date.

B. Time Tracking & Reporting
The Project Manager will be responsible for ensuring that time is entered into PlanView and that
Monthly Status Reports are created.


5f70d5d9-3995-437d-a434-c9cf7227f5b6.doc     Last Updated: 8/3/05                     Page 2 of 4
University of Michigan Administrative Information Services
LC Methodology

         M3000A - Design Phase Approach Document

C. Metrics To Utilize
Metrics that will be tracked include but are not limited to:
    1. Percentage of Designs, that are in progress, in review, approved, deferred, or not started.
              a. From Planview or the Tracking Spreadsheet/Database.
              b. Also include interim milestones by objects.
    2. Effort Completed as Percentage of Estimated Effort.
    3. From Planview – Time Reported and ETC (Estimated Time to Completion) updates.
    4. Percentage of Effort Remaining – only 100% completion factored in.
    5. Effort Rate.
    6. Burn Rate.
    7. Green/Yellow/Red tasks.


C. Design Phase Status/Issues Meeting
During Design Phase, it is recommended that a weekly status meeting be held. This meeting will
support a communication process to inform the project team of status, issues, risks, and changes.
The Agenda will include a review of open high and medium issues, the overall Design Phase schedule,
status from the Tracking Spreadsheet/Database, and any action items from the previous week.
Meeting minutes should be taken that include a list of attendees, discussion points, and action items.
Designers, Tech. Leads or Product Managers, Reviewers, and cross-team members should be
represented in the meeting. Lessons Learned should be identified and reviewed. Changes in Scope
or Schedule should be managed as part of the Integrated Change Control process.


D. Acknowledgement of Deliverables
Where deliverables require an “acknowledgement”, this means that the acknowledger has reviewed
the artifact(s) and feels that the documentation and or design effort was sufficient. Detailed Designs
will require acknowledgement.


IV. Assumptions and Risks for the Design Phase Approach

A. Assumptions for Design Phase Approach
The following assumptions are critical to the successful accomplishment of this Approach to the
Design Phase:
        Technical Environment is configured and available for use prior to beginning Design Phase activities.
        Architectural Impacts are known and reviewed prior to beginning Design Phase activities.
        New, Obsolete, or Carried-Forward Modifications are identified prior to Design Phase.
        Requirements documents exist for each Modification proposed.
        Methodology templates & processes exist and Designer, Reviewers, & Leads are trained in their use
         prior to initiating Design Phase.
        Realistic levels of availability and commitment are obtained for all resources involved in Design Phase
         activities.


5f70d5d9-3995-437d-a434-c9cf7227f5b6.doc     Last Updated: 8/3/05                           Page 3 of 4
University of Michigan Administrative Information Services
LC Methodology

         M3000A - Design Phase Approach Document

        Reviewers have availability and commitment to review, respond, and approve deliverables in a timely
         manner.
        Business Processes and Modifications are loaded from STAT into the Tracking Spreadsheet/Database,
         and the Database is ready for update.
        Business Processes and Modifications are loaded from STAT into the UMDB and the UMDB is ready for
         update.

B. Risks for Design Phase Approach
        Technical environment not ready.
        Architectural impacts not known and planned for.
        Team members not trained in use of Methodology.
        Inadequate commitment and/or allocation of team members’ effort.
        Insufficient or not agreed-upon Scope definition.
        Inadequate Requirements documents.
        Tracking Spreadsheet/Database not correctly loaded or not ready for update.


V. Deliverables
A. Deliverables from the Project Manager
The following deliverables are required:
        Work Breakdown Structure (WBS) /Schedule - updated business processes and adjusted hours. This is
         required at the beginning of the Design Phase, in order to put the WBS into Planview as a Schedule for
         tracking and reporting.
        Updated Tracking Spreadsheet/Database showing business process, modification, and status of each.
        Updated Metrics.
        Updated Status Reports & Meeting Minutes.


B. Deliverables from the Phase
The following deliverables are required:
        Reviewed and Acknowledged S300 Designs. There can also be an initiated S404 Unit Test Plan and
         Unit Test Plan Data for each Design. These documents will be passed along to Developers in the
         Development/Unit Test Phase.
        Updated existing inventories of Reports, Batch Jobs, Interfaces, RDA’s, etc.


C. Deliverables from the Methodology Team
The following deliverables are required:
        Updated Process Flows, Templates, or Tools if necessary, based upon project team feedback regarding
         successes and challenges.
        Updated Design Phase Approach Document - if needed.



5f70d5d9-3995-437d-a434-c9cf7227f5b6.doc     Last Updated: 8/3/05                        Page 4 of 4

								
To top