Skip to end of metadata
Go to start of metadata

1      Custom Development Process

The custom development process is composed of a number of stages which are sequential. To complete a stage and progress to the subsequent stage, the stage deliverable is evaluated based on defined exit criteria. To facilitate this, all custom developments will follow the diagram shown below.

Note: To be done.





Custom Development Process

Functional Design

Functional design is to clearly communicate user and business requirements at a detailed level, which is technology independent.  Functional designer will review and understand the business impact and the affected users thru gap analysis, identify opportunities to reuse standard functionality prior to documenting the business requirements, testing conditions, and error handling processes.
Responsibilities
Process team: Gather user requirements and translate them into a functional specification according to the templates provided. Get the sign-off for the completed functional specification from the process leads and process architects.

Development team: Assist the process team on any technical queries that might arise. Will also assist the process teams in creating the functional specification. Review & sign-off the completed functional specification(i.e. after the peer review is completed) before moving to the technical design phase.

Technical Design

Technical design is to document the detailed technical approach for satisfying the business requirements documented in the functional specification. The Technical designer will carefully review the functional specification as the primary input; identify opportunity for reuse prior to document the detailed technical approach with consideration in performance optimization, as well as provided test cases.
Responsibilities
Process team: Provide assistance to the development team on functional specification clarification. Seek user consensus regarding any changes due to technical limitations.

Development team: Create the technical specification document. Inform the process team of any design issues due to technical limitations.

Code

Once the Technical Specification has been completed, the technical specification initiates the coding stage.  The result of this phase should align with the user’s requirements.
Responsibilities
Process team: Provide assistance to the development team on functional specification clarification. Seek user consensus regarding any changes due to technical limitations.

Development team: Developing, proofreading and debugging the object. Inform process team of any design issues due to technical limitations.

Component Testing

The purpose of the Component Test is to ensure that the work unit is performing correctly as per the technical specifications with testing in the development environment. The programmer assigned to the coding of the program will execute the component test.  Component test documentation proves very useful during later revisits to the same program and serves as the basis for regression test.
Responsibilities
Process team: Provide assistance to testing in the form of configuration or master data maintenance.

Development team: Perform component test and fix any issues arising.


Between each stage in the custom development lifecycle, exit and entry criteria are defined to ensure that each stage is complete before it is signed off and passed to the next phase.

Functional Specification Design

A Functional specification design is to clearly communicate user and business requirements at a detailed level, which is technology independent.  The Functional designer will review and understand the business impact and the affected users through gap analysis^[3]^, identify opportunities to reuse standard functionality prior to document the business requirements, testing conditions, and error handling processes.

        Identify Opportunities for Reuse

Prior to begin design, the functional designer should determine if it is possible to reuse, either fully or partially, assets that already exist.   Some of these questions may require the assistance of a technical designer.

  • Does SAP provide a similar solution via standard transactions?
  • Has this work unit (WRICEF) been developed before at another system (GSAP, AluSAP)?

        Entry Criteria

The following entry criteria must be met prior to functional specification.

  • Assess if current assets can be reused.
  • Gap analysis has been performed and the resolution documented.
  • Related BPD's (Business Process Design) completed,
  • Resource is identified as the owner of the design.  

Configuration changes can dramatically impact both the content and the completion date of the functional specification.  It is the responsibility of the functional team member to track configuration commitments and to ensure the project team is aware of milestone deviations.

The process team leads, process architects will be responsible for the sign-off of the completed functional specification.  Once sign-off is completed, further changes will result in a redesign or budget change, which will require the approval of a scope change request. More details of this can be found in section ‎9.

Once the entry criteria have been satisfied, the process team members will begin the actual functional specification design process.

        Document Business Requirements

A key objective of a functional specification is to clearly communicate user and business requirements at a detailed level, which is technology independent.  The more detailed the functional specifications, the easier the technical designer’s job becomes, and the less time will be spent on reviewing issues and questions.

The functional specification should also include the business impact and the affected users. This information will be used in the development of the Change Management effort.

This information can be obtained using a combination of the following methods.

  • Review of associated Process Detailed Designs
  • Discussion of any questions with process team leads, SME’s, and business representatives and key users
  • Discussion with existing system developers or system or process architects.

        Map Business Requirements to SAP

Once the business requirements have been defined, these requirements must be mapped to SAP.  The Process Team Member will be responsible for determining where data elements can be found in SAP (i.e. what transaction, what screen) and mapping those data elements to business requirements.  They will then determine where possible key data elements are stored in SAP (i.e. what table, what field).  Depending on the type of development a different set of information is required. The functional specifications templates will guide the designer through the information that needs to be provided.  This information will be used by the Technical Designer to create the Technical Specification.

        Document Testing Requirements

The process team member is responsible for specifying high-level test conditions and test scenarios^[5]^.  These conditions/scenarios are the same ones that the programmer will use to execute a component test for the finished work unit.  Process team member is responsible to provide the master and/or transactional data to satisfy these requirements. The test data may not need to be provided upon the completion of the Functional Specification, it should be provided before the execution of the component test.

        Document Error-Handling Requirements

The functional designer is responsible for identifying potential functional errors that may occur during the course of program execution.  An example of a functional error would be “material type not found” or “posting period has been closed”.   The process team member should perform the following activities to document the error-handling requirements.

  • Potential Errors.  Specify the potential errors that may occur.
  • Error Types.  For each potential error, specify whether it should be a warning, an error or a fatal error (abend). 
  • Notification Strategy.  Specify the method to be used to communicate fatal and non-fatal errors (i.e., SAP Inbox, Open Mail, Standard Operations Messaging Queues, Work Flow, error report).
  • Notification Matrix.  Specify the individual to be notified if a particular error occurs.
  • Error Reports: Identify error report requirements.  Each error report needs to be defined using the “Report Functional Specs” design template.

        Document Issues

All issues that arise during the functional design process are to be documented in the ITG Mercury database.  Upon completion of the functional specification, each issue should be accompanied by a resolution.

        Exit Criteria and Sign Off

The functional specification is reviewed by the process team leads, the process architect, the SME and the development team leads using the Functional Specification Review Checklist in Appendix A.   There should be no open issues upon Functional Specification signed-off. The process team leads and the process architects sign-off on the design, formally acknowledging that the exit criteria have been satisfied.

Technical Specification Design

The technical specification is to document the detailed technical approach for satisfying the business requirements documented in the functional specification design.  Technical designer will carefully review the functional specification as the primary input, and then identify the opportunity for reuse prior to document the detailed technical approach with consideration in performance optimization, as well as provided test cases.

        Entry Criteria

The functional specification is the primary input to the technical design phase, and it is therefore critical that the technical designer review it thoroughly.  The gap definition provides background as to why the functional specification was created and should be reviewed as well.

When reviewing the functional specification, the technical designer should also note references to important configuration documentation, and review and understand the existing SAP configuration as it relates to the functional specification requirements. The technical designer should look at the test data requirements identified in the functional specification and then test the configuration by attempting to create some test data.  If any configuration anomalies are found it should be brought to the attention of the functional team member immediately.

When performing the review, the technical designer should note any issues or questions.  If necessary, the technical designer should set up a meeting with the development coordinator to walk through the design and answer any questions. Technical design should not commence unless the Functional specification has closed any open issues and has entry/exit criteria satisfied by the functional specification checklists.

        Identify Opportunities for Reuse

Prior to beginning design, the technical designer should determine if it is possible to reuse, either fully or partially, assets that already exist.   This step is performed during the creation of the functional specification as well, but should be revisited by the technical designer.

The following are some points that should be considered by the technical designer. 

  • Is there another functional or technical specification for 1SAP which is predominantly the same functionality? (Consider all WRICEF inventories.)
  • Has the work unit (WRICEF) been developed previously in another system?

        Document Detailed Technical Approach

A key objective of a technical specification is to document the detailed technical approach for satisfying the business requirements documented in the functional specification.  When developing the technical specification, the following points should be kept in mind.

  • Follow SAP’s User interface style; any additions (modifications, user exits, etc.) should reflect SAP’s approach in order to limit the confusion from the user’s perspective
  • Maintain open and continuous communications with the SAP configuration team so that any configuration changes can be reflected in the design in a timely manner
  • Understand how approved scope changes may impact the Technical specification
  • Understand how decisions made regarding integration have an impact on other work units

        Design Programs

The technical specification should provide concrete, intuitive, and conceptual explanations of the functional requirements. Each technical specification may result in the development of one or more programs.  Each program is defined as a program definition.  For each program, the following must be documented:

  • Common program - Specify whether the program is a common program or a new program.  For common programs, specify the program name. 
  • Application - Specify the SAP application.
  • Development Class^[6]^ - Specify the development class to be used for the program.
  • Authorization Group^[7]^ - Specify the authorizations necessary to execute the program.
  • SAP Transaction - Specify the related SAP transaction(s).
  • Program Description - Provide a detailed description of the program. 
  • Input/Output Files - Specify all input and/or output files utilized by the program.
  • Program Flow - Provide a program flow diagram to supplement the program description, if necessary.

 

Performance considerations should also be considered during the technical design. It should take the following into account:

  • Make rough estimates of response times and resource consumption
  • Locate the information from the most efficient source (e.g. if you are looking for financial open items, query the BSID instead of the BSEG table)
  • Determine the most efficient methods to pull data (e.g. indexes^[8], view[9]^, etc)

        Draft Component Test Plan

The technical designer must specify acceptance test criteria for each technical specification.  These acceptance test criteria will be used to test the entire work unit (i.e. all of the work unit programs working together).  The expected and actual results, as well as the master data and transactional data used must be documented.  No integration is anticipated in this phase as it is a component test. If additional test conditions are required, it will be added in the code phase by the developer.

        Document Issues

All issues that arise during the technical design process are documented in the issues database.  Upon completion of the technical specification, each issue should be accompanied by a resolution from the responsible party.

        Exit Criteria and Peer Review

The exit criterion for this stage is a review conducted by a peer of the technical designer. The technical specification is reviewed to ensure the following:

  • Adherence to standards for each document
  • Accuracy and completeness of content
  • Integration consideration among applications/systems
  • Performance consideration as applicable

A high-level component test plan according to the functional requirements has been started.

The peer will use both the general Technical specification checklist and the applicable WRICEF specific Technical specification checklist during the review (See Technical specification Review Checklist in Appendix A).  The intent is that any re-work that is needed may be done based on this review.

An approved technical specification will contain:

  • Functional overview of what the program is to accomplish
  • Technical process steps
  • Database tables/fields accessed
  • Selection/sorting criteria
  • Sample layout of program output
  • Program Flowchart
  • Performance considerations
  • Integration points/Interface Architecture
  • Technical Specification Check List
  • Approval signature from development lead

Code

Once the Technical Specification has been completed, the technical specification initiates the coding stage. The technical designer can take up the role of developer, thereby providing a seamless transition between the stages.  The communication between the Technical Designer/Developer and the onsite development coordinator will remain imperative throughout the coding and testing of the custom program with frequent communications between the two.

        Code Program(s)

The following should be kept in mind during coding:

  • Basic error handling, messages and audit trail.
  • Missing or empty input or output files, directories and variants.
  • Calculation field overflows and errors (e.g. dividing by zero).
  • Input field formatting (search helps^[10]^, value lists, numeric vs. alpha errors).
  • Output field formatting (layout accuracy, decodes, pagination, headers, footers, tabs, currency, decimals).
  • Selection criteria all work (WHERE clause completeness).
  • Calculation correctness (summation and grouping).
  • Time/date/user stamps complete.
  • Printing and downloading if specified.
  • Ensure code is commented sufficiently

        Proofread and Debug Program(s)

Proofread and debug the code until a high degree of confidence is achieved that the program works according to the technical specifications.

        Update Component Test Plan

Update the Component Test Plan draft based on changes or new conditions that surface during coding of the program. Test data for the component test should be provided by the functional team member. Finalize the Component Test Plan and outline the steps to be followed when running each cycle (i.e. test data used, user selection screen parameter values.)  Ensure that expected and actual results are documented.

        Document Issues and Changes

During the coding phase some unforeseen issues may arise that requires changes to the original technical or functional specifications.  When these occur, the programmer must review the issues and subsequent changes with the technical designer, onsite development coordinator and the development lead in order to determine the best solution. The onsite development coordinator will discuss the issues and subsequent changes with the functional designer where necessary.

This meeting will establish:

  • What changes should be made,
  • When the changes are to be implemented
  • What is the schedule impact
  • What budget changes are needed

Component Test

Component testing and high quality component test documentation play a key role in the development process.  The purpose of the Component Test is to ensure that the work unit (WRICEF) is performing correctly as per the design specifications.

        Conduct Component Test

The programmer assigned to the coding of the program executes the component test.  Component test documentation proves very useful during later revisits to the same program and serves as the basis for the regression test of the component. If any configuration anomalies are found it should be brought to the attention of the functional team member immediately.

A complete component test should at least include conditions to test for each of the following possible key areas:

  • Selection criteria validation
  • Negative vs. Positive values
  • Select statements (e.g. select singles) checking return code sy-subrc
  • Where clauses (all components)
  • Read statements - checking return code sy-subrc
  • Extract statements - for datasets
  • Clear statements - proper times to clear
  • Assignment statements
  • Table loops: endless loops and efficiency
  • Verifying all PERFORMs’ and function modules’ functionalities
  • User interfaces (push buttons, line selection)
  • Output layouts including paper printouts
  • Online documentation

        Document Issues and Changes

During the component test phase some unforeseen issues may arise that requires changes to the original technical or functional specifications.  When these occur, the programmer must review the issues and subsequent changes with the technical designer, onsite development coordinator and the development lead in order to determine the best solution. The onsite development coordinator will discuss the issues and subsequent changes with the functional designer where necessary.

This meeting will establish:

  • What changes should be made,
  • When the changes are to be implemented
  • What is the schedule impact
  • What budget changes are needed

        Conduct Code & Component Test Review

Code review will be conducted by the peer/technical designer/lead of the developer.

The review will be done based on the Code Review Checklist in Appendix A. All reviewers have to verify that the program satisfies the technical requirements and performance considerations.

To complete the component test review, the programmer should review the following:

  • Explain how each design specification will be tested
  • Review Test cycles
  • Review Cycle scripts
  • Demonstrate sufficient test data has been created to test all conditions
  • Demonstrate that data is representative of real life business data (working with the functional designer)
  • Review performance

The review helps to remove errors in the work unit (WRICEF) early and efficiently.  The further into the custom development life cycle the errors are discovered, the more costly they are to correct. 

Any items related to the component test plan, which require rework, must be annotated on the issues.

Once the program(s) have passed these reviews, the reviewer will sign off on the code review check list and component test plan review check list to indicate that the object is ready for unit test.

        Sign off

Rework and follow up reviews will occur until both parties agree that all open issues are resolved. Sign-off signifies that the work unit (WRICEF) is technically complete.  The Component Test Plan Review Checklist in Appendix A details the exit criteria requirements for each WRICEF component.

  • No labels
  1. Guest

    Hello Aveek,

    Thanks for this great article. 

    Do you have any idea, where can we find all those Review Checklists?

    It seems that Appendix A and links to those 4 documents are currently missing...

    Thanks,
    Isaac