Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

specification documents o internal and external programs documentation

Former Member
0 Likes
422

I have to make some changes in the specification documents o internal and external programs documentation. I want to know i there are defined some standard conventions about the technica objects name and the requirements documentation.

We have made some formats, but we have seen change resistance=2 The problem is the amount of information required in these ne formats that we think is important and will help to reduc ambiguity and to avoid backworks but it's going to ad activities to the developers.

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
398

. Ours is bit different to what she sampled but the standardization differ from the team implementing it. You must also come out with the pattern for program "pre" and "post" documentation.

1. Before the actual coding of the program, you have to specify the estimated number of mandays needed for the analysis, coding and documentation. Don't forget to add n% for the buffer. (In our case, we use 30% buffer). Then update the form by putting on the other column the actual mandays consumed. There should not be cases that estimated < actual mandays. If problem is encountered that may cause delay, inform team lead to adjust the estimated mandays.

2. Create a form that will specifically states the unit testing made (eg. Test case, test data, how the test is perform, outcome of testing, rating: pass or fail, etc.)

3. After coding, specific program specification (eg. logic of the program, tables created, function module used, authorization checking, etc). Please be reminded to put result of "program extended syntax check" (tcode: slin) and "run time analysis" (tcode: se30) if applicable.

4. And initial code review must made also. If proper ABAP coding is incorporated and obliged by the program. If the proper naming convention that you implemented is followed by the program...so on and so forth.

hope you'll get some ideas out of it.

cheers,

1 REPLY 1
Read only

Former Member
0 Likes
399

. Ours is bit different to what she sampled but the standardization differ from the team implementing it. You must also come out with the pattern for program "pre" and "post" documentation.

1. Before the actual coding of the program, you have to specify the estimated number of mandays needed for the analysis, coding and documentation. Don't forget to add n% for the buffer. (In our case, we use 30% buffer). Then update the form by putting on the other column the actual mandays consumed. There should not be cases that estimated < actual mandays. If problem is encountered that may cause delay, inform team lead to adjust the estimated mandays.

2. Create a form that will specifically states the unit testing made (eg. Test case, test data, how the test is perform, outcome of testing, rating: pass or fail, etc.)

3. After coding, specific program specification (eg. logic of the program, tables created, function module used, authorization checking, etc). Please be reminded to put result of "program extended syntax check" (tcode: slin) and "run time analysis" (tcode: se30) if applicable.

4. And initial code review must made also. If proper ABAP coding is incorporated and obliged by the program. If the proper naming convention that you implemented is followed by the program...so on and so forth.

hope you'll get some ideas out of it.

cheers,