um abap development standards

UM ABAP Development Standards

2008

The University of Mississippi 4/01/2009

UM ABAP Development Standards 2

The University of Mississippi | Confidential

Table of Contents

NAMING STANDARDS ................................................................................................................... 4 PROGRAM STANDARDS ................................................................................................................ 5 DIALOG PROGRAM STANDARDS ............................................................................................... 6

1. Module Pool ............................................................................................................................ 6 2. Screens .................................................................................................................................... 6 3. GUI Status ............................................................................................................................... 6 4. Miscellaneous ......................................................................................................................... 6

TRANSACTION STANDARDS ....................................................................................................... 7 1. Reports .................................................................................................................................... 7 2. Dialog Programs ..................................................................................................................... 8

CODING STANDARDS .................................................................................................................. 10 1. Formatting ............................................................................................................................. 10 2. One command per line .......................................................................................................... 11 3. Indented source code ............................................................................................................. 11 4. Variable naming .................................................................................................................... 11 5. Reusable code ....................................................................................................................... 12 6. Parameter passing in subroutine ........................................................................................... 12 7. Text handling ........................................................................................................................ 12 8. Usage of UserIDs in programs .............................................................................................. 12 9. Messages ............................................................................................................................... 12 10. Development Class ............................................................................................................. 12 11. Source Code Documentation .............................................................................................. 13 12. Function Modules ............................................................................................................... 14

PERFORMANCE STANDARDS .................................................................................................... 16 1. General Performance Standards ............................................................................................ 16 2. Performance Checking .......................................................................................................... 20

DICTIONARY: TABLE STANDARDS .......................................................................................... 21 1. User-developed table naming convention ............................................................................. 21 2. User-developed table definition convention ......................................................................... 21 3. Maintenance settings ............................................................................................................. 21

RULES STANDARDS ..................................................................................................................... 22 TRANSPORTING STANDARDS ................................................................................................... 25

1. Communication ..................................................................................................................... 25 2. Transports ............................................................................................................................. 25 3. Re-imports ............................................................................................................................. 25 4. Critical Imports ..................................................................................................................... 25

TESTING STANDARDS ................................................................................................................. 27 1. Internal testing ...................................................................................................................... 27 2. Return Codes ......................................................................................................................... 27



3. Performance analysis ............................................................................................................ 27 4. Requestor Review ................................................................................................................. 27

AUTHORIZATIONS STANDARDS .............................................................................................. 28 PROJECT LIFE CYCLE .................................................................................................................. 29 REFERENCES ................................................................................................................................. 31



SAP Development Standards Guide

NAMING STANDARDS

1. Program names may be between 5 and 40 characters in length. Program names will be composed of the following subfields:

a. Z — all programs must begin with the letter “Z”.

b. XX — where XX is the SAP module. Current SAP modules include: 1. AM Asset Management 2. BC Basis Component 3. BG UM Budget Preparation System 4. BI Business Intelligence 5. CO Controlling 6. CM Student Lifecycle Management 7. EP Enterprise Portal 8. FA Financial Aid 9. FI Financials 10. FM Funds Management 11. HR Human Resources 12. MB Mobius 13. MM Materials Management 14. PM Plant Maintenance 15. SE Staff Evaluations 16. TR Travel Management 17. UM global to all modules 18. other modules as designated or added to the system

c. “_” — separate the prefix from the remaining program name by an underscore

“_”.

d. If the program is for use by UMMC only, characters 5-10 must include “UMMC_”.

e. The remaining 31-36 characters may be as descriptive as you wish.

f. When writing a temporary or training program, please use the prefix “ZTST_XX_” for the beginning of your program name. This will indicate that this program should not be used on a regular basis in the production environment.



g.

PROGRAM STANDARDS

1. A template program ZTEMPLATE in client 110 has been provided for your convenience. Please be careful not to update this program directly. Copy it to your new program name, and then modify your program. Be sure to change the “Title” field on the attribute page of your program to reflect a description of what your program does.

2. All programs should include a comment box at the beginning of the program listing the following information (see ZTEMPLATE):

a. Program name b. Author c. Date written d. Description of the program. Be sure to list any special considerations and/or

situations. List any tables being used, with a brief description of the table. e. All modifications to the program should also be documented in this area. (See

Coding Standards: Source Code Document for more information.

3. Use descriptive data and paragraph names. Do NOT use a hyphen “-“ in variable names or in paragraph (“form”) names. Use the underscore “_” instead. SAP uses the hyphen “-“ to separate a table name from the field name in the table. Using an underscore will increase readability of your program.

4. Group parameters and select-options together. Group table names together. All data items should be at the beginning of the program before any event logic.

a. Names of parameters and select-options are limited to 8 characters. b. Table names are limited to 16 characters.

5. Event paragraphs should be listed in a logical order inside of a START-OF-SELECTION

…END-OF-SELECTION section.

6. Use indentation to make the reading of your program easier. This is automatically set when you use Pretty Printer (see Code Standard: Formatting).

7. Screen frame titles should be constructed using standard Title Case.

8. All emails generated from SAP programs should use proper grammar and punctuation and appropriate line-wrapping.



DIALOG PROGRAM STANDARDS

1. Module Pool a. Transactions are maintained using SAP transaction SE38 (ABAP Editor).

b. Naming convention – SAPMZXX_

c. Naming convention for includes

i. MZXX_...TOP – Global data ii. MZXX_...O01 – PBO modules

iii. MZXX_...I01 – PAI modules iv. MZXX_...F01 – Form routines

2. Screens a. Transactions are maintained using SAP transaction SE51 (Screen Painter).

3. GUI Status a. Standard menu bar, application toolbar and standard toolbar are maintained using

SAP transaction SE41 (Menu Painter).

4. Miscellaneous a. Initialize all screen fields and global variables in the PBO (Process before Output)

module.

b. PAI (Process after Input) should contain the logic to be executed after the user has selected a function key, menu item, etc.

c. POV (Process on Value-Request) should contain logic to display list of possible

values on F4 request.

d. POH (Process on Help-Request) should contain logic to display help information on F1 request.



TRANSACTION STANDARDS

Transactions are maintained using SAP transaction SE93 (Maintain Transactions). User must select the appropriate “Start object“ on the first “Transaction Creation Screen”. Depending on the underlying associated object (e.g.: Reports or Dialog Programs) user selects the appropriate Start object type.

Figure 1

The following two sections describe the Transaction standards for Start object: Reports and Dialog Programs respectively:

1. Reports a. Transaction Code name can be up to 20 characters. The standard naming

convention (ZXX_) should be used (see Naming Standards).

b. The standard package is always ZDEV for UM clients only.

c. GUI Support – select all (HTML, Java, and Windows).



Figure 2

2. Dialog Programs

a. Transaction Code name can be up to 20 characters. The standard naming convention (ZXX_) should be used (see Naming Standards).

b. The standard package is always ZDEV for UM clients only.

c. GUI Support – select all (HTML, Java, and Windows).



Figure 3



CODING STANDARDS

1. Formatting a. Standardize formatting should be used to format all programs, function modules, etc.

To setup, select ‘Setting’ under the ‘Utilities’ option on the SAP toolbar. Select ‘ABAP Editor’ option. Within this option, select ‘Pretty Printer’. Check the following options:

i. Indent ii. Convert Uppercase/lowercase

iii. Keyword Uppercase

Figure 4



2. One command per line a. Each ABAP/4 command consists of a sentence ending with a period. As a standard,

start each new command on a new line. This will allow for easier deleting, commenting, and debugging.

3. Indented source code a. For command statements that have a corresponding “END” (such as IF…ENDIF,

SELECT…ENDSELECT, LOOP…ENDLOOP), the “END” part of the statement should be placed in the same column as the beginning part of the statement. It is helpful to also comment the “END” statement by using the “ parameter on the same line. For example,

LOOP at ITAB. …….. statements here ENDLOOP “ ITAB table

4. Variable naming a. ABAP/4 variable names can be up to 30 characters for DATA fields and subroutines

and up to 8 characters for SELECT-OPTIONS and PARAMETERS, therefore, as a standard, make the names descriptive. Do NOT use a hyphen “-“ in variable names or in paragraph (“form”) names. Use the underscore “_” instead. SAP uses the hyphen “-“ to separate a table name from the name of a field in that table. Using an underscore will increase readability of your program.

b. Some variable types should be prefixed with a specified letter or letters: Variable Type Prefix Selection screen parameter p_ or a_ Form routing parameter p_ Select-options s_ Ranges r_ Internal tables (global) t_ or gt_ Internal tables (local) lt_ Local structures ls_ Global structures gs_ Constants c_ or lc Global constants gc_ Local variables lv_ Global variables gv_

c. Whenever possible, the LIKE parameter should be used to define the type of a

variable.

d. Whenever possible, global constants should be used instead of creating local constants or hard-coded values. For function modules and dialog programs, global



constants should be stored in the “MZXX_...TOP” section of the function module group.

5. Reusable code a. If a block of code is executed more than once, it should be placed in a subroutine at

the bottom of the code or in a function module. This makes the code more readable, requires less indentation, and is easier to debug.

6. Parameter passing in subroutine a. Whenever possible use a TYPE or LIKE statement when specifying the formal

parameters of a subroutine. This is a good programming style, plus it allows the ABAP compiler to generate more efficient code (which can increase performance up to a factor of 2x).

7. Text handling a. Variable names should not be used on the parameter selection screen for any

program placed in production. Use the “Text Element” function found in the ABAP editor to describe the selection criteria and relate it to the variable name.

b. INCLUDE files can't define their own Text Elements - any Text Elements to which they refer must be defined in the main program which invokes the INCLUDE file. TIP: You can use the INITIALIZATION event of the “include” program to set the values of these text elements.

8. Usage of UserIDs in programs a. In no case should a production program or function contain a UserID as either literal

or constant data. In the development system it may be necessary to code temporary breakpoints for specific UserIDs, however, these debugging techniques must be removed before the program is transported.

9. Messages a. Declare the message class in the report statement. While it is possible to specify the

message class each time a message is output, it is easier to specify once it in the report statement. You can still use a message from another class than the one defined in the report by adding the class in parentheses after the message. Messages can be defined using SAP transaction SE91 (Message Maintenance: Initial Screen).

b. Messages should use proper grammar and punctuation.

10. Development Class a. The development class of any program, table, function, etc., should be ZDEV for

UM clients only. If a special development class is required, authorization must be request from BASIS (see Authorization Standards for more information).



11. Source Code Documentation a. It is wise to provide future programmers with documentation inside your source

code. Explain the purpose, design, structure and any testing hints at the top of the program.

b. All programs should also have a modification log displayed at the top of the program. This log should the initials of the developer making the change, the date of the change, and a description of the change. The log should be dated with the most recent change first. For example:

Figure 5

c. Comment work fields, and fields in work records especially those used for

interfacing. Comments should explain what the code is doing.

d. Comments should be included before each “form” subroutine to briefly describe what the subroutine is to accomplish. Comments should also be placed before SAP events. These comments help to pinpoint the beginning of events and subroutines, and help direct the flow of logic.



Figure 6

Figure 7

e. It is also helpful to include comments for each block of code designed to accomplish

a task. For example:

Figure 8

12. Function Modules a. The standard naming convention (ZXX_) should be used for naming Function

Modules and Function Groups (see Naming Standards).



b. The import and export parameters of function modules should be documented at the top of the source code section of the function module with brief descriptions of the fields and their typical contents. Also, any special requirements or usage should be noted.

c. The first letter of the parameter’s name should indicate the direction in which the

parameter was passed: Input or importing = I Output or exporting = E Bi-directional or changing = C

d. The second letter of the parameter’s name should indicate the nature of the formal parameter:

Single value or variable = V Single structure or record (however complicated) = S Internal table (however complicated the line structure) = T

e. Function modules that contain database reads should also contain at least one EXCEPTION parameter.

f. All RFCs (Remote Function Call) must contain at least one EXCEPTION parameter.



PERFORMANCE STANDARDS 1. General Performance Standards

a. "Dead" code - (Avoid leaving "dead" code in the program. Comment out (or delete) variables that are not referenced and code that is not executed. Use program --> check --> extended program to check to see a list of variables which are not referenced statically.

Figure 9

b. Logical databases - Most SAP modules have logical databases that are available for

your use. However, it has been found that unless you are using a lot of the data from the logical databases, the runtime of the program using a logical database is greatly increased from one directly accessing a database table using a “SELECT” statement.

c. Subroutine usage - For good modularization, the decision of whether or not to execute a subroutine should be made before the subroutine is called. For example:

This is better:

IF f1 NE 0. PERFORM sub1. ENDIF. FORM sub1. ... ENDFORM.

Than this:

PERFORM sub1. FORM sub1.



IF f1 NE 0. ... ENDIF. ENDFORM.

d. IF statements - When coding IF tests, nest the testing conditions so that the outer conditions are those which are most likely to fail. For logical expressions with AND, place the mostly likely false first and for the OR, place the mostly likely true first.

e. CASE vs. nested Ifs - When testing fields "equal to" something, one can use either the nested IF or the CASE statement. The CASE is generally better because it is easier to read.

f. MOVE-ing structures - When records a and b have the exact same structure, it is

more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.

g. SELECT – Direct SELECT statements should only be used if the data can not be accessed using a function module or an evaluation path. When possible the SELECT statements should be stored in a function module.

h. SELECT and SELECT SINGLE - When using the SELECT statement, study the

key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row or there is only one row to be returned, using SELECT SINGLE can increase performance by up to 3x.

i. Check each SELECT statement for the use of index. This can be most easily

determined using the Code Inspector, transaction SCI, which will report on any SELECT statement against large tables not using an index.

j. Check that there is no assumed sort order after the SELECT statement. Do not

assume that the data will be returned in primary key order.

k. SELECT * versus SELECTing individual fields - In general, use a SELECT statement specifying a list of fields instead of a SELECT * to reduce network traffic and improve performance. For tables with only a few fields the improvements may be minor, but many SAP tables contain more than 50 fields when the program needs only a few. In the latter case, the performance gains can be substantial.

l. SELECT – Direct SELECT statements should only be used if the data can not be

accessed using a function module or an evaluation path. When possible the SELECT statements should be stored in a function module.

m. Small internal tables vs. complete internal tables - In general it is better to minimize

the number of fields declared in an internal table. While it may be convenient to



declare an internal table using the LIKE command, in most cases, programs will not use all fields in the SAP standard table.

n. Refreshing internal tables – When you are done working with an internal table REFRESH the table to release it from memory.

o. Row-level processing of a table - Selecting data into an internal table using an array fetch versus a SELECT-ENDELECT loop will give at least a 2x performance improvement. After the data has been put into the internal data, then row-level

processing can be done. For example, use: select ... from table <..> into <itab> (corresponding fields of itab) where ...

loop at <itab>

<do the row-level processing here> endloop.

instead of using: select ... from table <..> where ... <row-level processing> append <itab>.

endselect.

p. READing single records of internal tables – When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. This means that if the data is not sorted according to the key, the system must sequentially read the table. Therefore, you should SORT the table and use READ TABLE WITH KEY BINARY SEARCH for better performance.

q. SORTing internal tables - When SORTing internal tables, specify the fields to be SORTed.

r. Deleting duplicates – After sorting internal tables, remember to use the command

“DELETE ADJACENT DUPLICATES FROM” to remove duplicate records.

s. Number of entries in an internal table - To find out how many entries are in an internal table use DESCRIBE.

t. Length of a field - To find out the length of a field use the string length function.

LV_FLDLEN = STRLEN (FLD).



u. Nested SELECTs versus table views - Since OPEN SQL does not allow table joins, often a nested SELECT loop will be used to accomplish the same concept. However, the performance of nested SELECT loops is very poor in comparison to a join. Hence, to improve performance by a factor of 25x and reduce network load, you should create a view in the data dictionary, then use this view to select data.

v. If nested SELECTs must be used - As mentioned previously, performance can be dramatically improved by using views instead of nested SELECTs, however, if this is not possible, then the following example of using an internal table in a nested SELECT can also improve performance by a factor of 5x:

Use this: form select_good.

data: t_vbak like vbak occurs 0 with header line. data: t_vbap like vbap occurs 0 with header line. select * from vbak into table t_vbak up to 200 rows.

select * from vbap for all entries in t_vbak where vbeln = t_vbak-vbeln. ...

endselect. endform.

Instead of this: form select_bad.

select * from vbak up to 200 rows. select * from vbap where vbeln = vbak-vbeln. ...

endselect. endselect. endform.

w. Avoid unnecessary statements - There are a few cases where one command is better than two. For example: Use:

append <tab_wa> to <tab>. Instead of:

<tab> = <tab_wa>. append <tab> (modify <tab>).

And also, use: if not <tab>[] is initial.

Instead of: describe table <tab> lines <line_counter>. if <line_counter> > 0.

x. Copying or appending internal tables ⎯ Use this: <tab2>[] = <tab1>[]. (if <tab2> is empty)

Instead of this: loop at <tab1>.

append <tab1> to <tab2>.



endloop.

y. Clear vs Refresh – Use the CLEAR statement to initialize local variables and local structures. Use the REFRESH statement to initialize local tables. If the table has a header row, use “REFRESH lt_table[]” to clear both the table and the header row. Don’t forget to re-initialize local variable and table before each re-use.

z. Report display – Make sure the case matches throughout the report. Do not mix all upper-case displays with all lower-case displays. Ex:

Do not display: SHIELA LONG, academic administrator, school of education Instead use: Sheila Long, Academic Administrator, School of Education

aa. System fields – ABAP automatically stores information necessary to control the program’s internal flow of logic in some system fields and tables. These fields and tables are accessible by the programmer. It is better to use a system field than to create logic to generate the same data (i.e. current time, current date, table index, etc.). A list of system fields and system tables can be found in The Official ABAP Reference

2. Performance Checking a. Performance diagnosis ⎯ SAP transaction SE30 (ABAP/4 Runtime Analysis) must

be ran on all new programs before they are put into production. This utility allows statistical analysis of transactions and programs.

b. Error checking – Use the SAP transaction SCI (Code Inspector) to spot meaningful error; however, the developer will still need to use judgment to filter out meaningless errors.



DICTIONARY: TABLE STANDARDS

1. User-developed table naming convention a. Table names are limited to 16 characters. Follow the naming convention for

programs as far as the first 3 to 4 characters are concerned (ex. ZFPM, ZAM, ZFI).

2. User-developed table definition convention a. The first field defined for any customer table should be: MANDT. This is the 'client'

field, and makes the table specific to the client that it is used/modified in.

b. Field names do not have to begin with ‘Z’; however, the field name should be descriptive.

3. Maintenance settings a. "Tab. Maint. Allowed" 'X' or (blank)

i. An 'X' indicates that this table is to be maintained directly using the "Standard Table Maintenance" functions (SM31 / SM30). This means that the table can be maintained independently of any other table or application. This should only be used for tables that have a relatively low number of updates, done on an infrequent basis. Tables that are maintained this way are typically used to set control information, or similar table values that change infrequently, but will change. Examples are tax rates, overhead rates, program control tables, message tables, program or error status tables, etc.

ii. Tables maintained this way should NOT have any dependency on other tables or other entries in the same table for the validity of a new entry or new value, unless that dependency can be validated through the use of a check table for the field.

iii. X should be selected ONLY if the table is to be maintained by the "Standard Table Maintenance" functions. (SM30 or SM31) Any table for which entries are maintained / changed / inserted / deleted by an application should in most cases not have this field checked.

Updates: Direct database updates of SAP standard tables Under no circumstances should any program directly update SAP-delivered tables using the INSERT, UPDATE, or DELETE commands. SAP-delivered tables begin with all letters other than Y and Z, and they should only be updated using an SAP transaction. To automate updates to SAP tables via a program, you can use an SAP supplied function module.



RULES STANDARDS 1. Each University should have their own instance of programs ZGBBR000 and ZGBBS000, and

VSR.

2. Exit names (in ZGBBR000 or ZGBBS000) a. Limited to 5 characters. b. They should all begin with “U”.

Figure 10

3. Validations and Substitutions

a. Limited to 7 characters. b. Uses exit: same name as Exit

i. Info-only (footnote): IMSG001-IMSG999

Figure 11

c. Program-type related: Begin with 1st character of program-type

i. Uxxxxxx (UMAXHRS for Undergraduate Maximum Hours) ii. Lxxxxxx (LMAXHRS for Law Maximum Hours)

iii. Gxxxxxx (GMINHRS for Graduate Minimum Hours)

Figure 12

d. School related: Begin with 1st three characters associated with school

i. LAxxxxx ( Liberal Arts) ii. BUSxxxx (School of Business)



iii. ENGxxxx (School of Engineering)

Figure 13

e. Department related: Begin with Department/Course prefix

i. MLANGxx (Modern Languages) ii. ENGL (English)

Figure 14

f. Classification related: Begin with classification prefix

i. FRxxxxx (Freshman) ii. SOxxxxx (Sophomore)

iii. JRxxxxx (Junior) iv. SRxxxxx (Senior)

Figure 15

g. Campus related: Begin with campus prefix

i. OXFxxxx (Oxford)

Figure 16

h. Status related: Begin with status prefix

i. HONxxxx (Honors)

Figure 17

i. Specialization related: Begin with X, then<specialization>

i. XMATHxx for Math Majors

Figure 18



4. Rule Modules a. Limited to 4 numbers with desc. b. All descriptions same as Validation or Substitution as referenced.

Figure 19

5. Rule Containter

a. Limited to 12 characters. b. In general, similar text as used in validation, but enhanced for Web display purposes.

i. PRxxxxxxxx for Pre-requisite ii. COxxxxxxxx for Co-requisite

iii. SPECxxxxxx for Specialization iv. IMSGxxxxx for Informational Message

Figure 20



TRANSPORTING STANDARDS

1. Communication a. If you are going to working on a program, function module, table, structure, etc. for

a length of time, it is crucial that you communicate with the other developers before transporting these items to production.

b. It is the developer’s responsibility to determine if a more recent copy of any item in his/her transport group has already been moved to production.

2. Transports a. Transports are requested using transaction ZTRANSPORT_FORM.

b. When transporting more than one transport group, be sure to transport the groups in

the order they were created.

c. When completing a project, transport ALL transport groups for that project into production.

3. Re-imports a. Re-import requests are submitted using the Transports transaction

ZTRANSPORT_FORM.

b. Requests for transports to be re-imported into QAS and PROD must be submitted in PROD. Be sure to select the correct Target System.

c. If transports were not originally submitted in the correct order, they can be re-

submitted using the Reimport Request option.

d. When completing a project, transport ALL transport groups for that project into production.

4. Critical Imports a. Critical Import requests are submitted using the Transports transaction

ZTRANSPORT_FORM.

b. Requests for transports are generally done at set times during normal workdays. Any requests for transports that need to be completed outside of these normally scheduled times must be coded as Critical.

c. Only transports that are truly crucial to the operating of the system should be marked as Critical.



d. Developers must enter an explanation for the critical transport in the “Requester’s

Comments for BASIS / Reason for Critical Transport”.

Figure 21



TESTING STANDARDS

1. Internal testing a. All projects (including enhancements) should be tested internally within IT before

being reviewed by the requestor. Appropriate support teams in IT are available to assist with this task.

b. All developers are responsible for developing their own test plans. Test plans should include an appropriate sampling of data before and after project has ran. They should also include measure to ensure the appropriate outcome.

c. A program review will be conducted by the appropriate manager.

2. Return Codes a. Test all return codes (sy-subrc) for success and failure after any I/O and calls to

function modules (database selects, internal table reads, call transaction, etc.)

3. Performance analysis a. Program performance analysis should be conducted using SE30 (ABAP Runtime

Analysis) .

4. Requestor Review a. All projects should be tested/reviewed and signed-off on by the requestor before

they are moved to production.



AUTHORIZATIONS STANDARDS The SAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP System after he or she has logged on to the system and authenticated himself or herself. Follow standards to restrict access for any table, program, transaction or service.

a. The development class of any restricted program, table, function, etc., should not be ZDEV. Consult with BASIS and create a new package specific to application having name starting with Z, and use this package as development class.

Figure 22

b. For Dictionary objects: select Utilities-> Assign Authorization Group and enter

table/view name associated with newly created package name as Authorization Group.

Figure 23

c. Submit a request with BASIS to link authorization object related to this new

package and restrict the access.



PROJECT LIFE CYCLE

Figure 24

1. Project request arrives via IT Work Request.

2. CIO approves/disapproves project

3. Approved projects a. Written Requirements

i. IT and requestors develops and agree on written requirements. ii. Requestor must sign-off on requirements before development on the project

can begin. b. Design Document and Project Schedule

i. The Developer/Project Team will be responsible for creating a design document and project schedule.



ii. The Director or Associate Director of Enterprise Applications must sign-off on the design document.

iii. More complex projects will require a sign-off by the CIO/Deputy CIO also. c. Project Development

i. Developer/Project Team will be responsible for developing code, configuring the system, creating interfaces, etc. as needed for the project.

ii. Weekly/Bi-weekly checkpoints should be setup to monitor the progress of the project.

iii. All development should take place in the development/test system. d. Internally Testing

i. Project should be tested within IT first. ii. Appropriate support teams within IT will be available to assist with testing,

such as, SAP Support Team, FTDC, Helpdesk, and Academic Computing Coordinator. The developer is responsible for ensuring an appropriate test plan has been developed.

iii. Problems during internal testing should be fixed before the project moves to the next step.

e. Requestor Testing i. Once project has been tested internally, the project should be tested/reviewed

by the requestor. ii. The developer should assist the requestor in developing an adequate test

plan. f. Finalization

i. Support teams will be responsible for finalizing documentation and for developing a roll-out plan.

ii. Support teams will be responsible for conducting necessary user training to support the project.

iii. The developer will be responsible for coordinating efforts with BASIS to ensure appropriate user authorizations have been granted.

g. Deployment i. Projects are not to be deployed to the production system(s) until the

requestor has signed-off. ii. The developer will be responsible for making sure all transports related to

the project are properly deployed. h. Notification

i. The developer will be responsible for notifying the requestor when the new functionality will be available.

ii. The developer will be responsible for determining if others on campus need to be aware of the new function (i.e. appearance of a new tab on Student File).

4. Disapproved projects a. CIO/Director of Enterprise Application notifies requestor.



REFERENCES 1. The SAP Style Guide is available in the help documentation using the following path:

a. Help -> R/3 Library -> BC-Basis Components -> ABAP Workbench (BC-DWB) -> BC-> SAP Style Guide.

2. The task code ABAPDOCU or ABAPHELP can be accessed through the command window.

3. Inside the ABAP editor, you can click on the “Information” or “I” icon.

um abap development standards

Documents