Analysis the existing system RKA-SKPD Kota Malang Analysis the proposed system.

73 This in order to better understand and apply the ASB as one of the principal instruments of performance-based budgeting as required by various rules and regulations concerning the Regional Financial Management Guidelines PKD, like the PP. 105 of 2000 on Regional Financial Management and accountability, PP. 58 of 2005, Permendagri No. 13 of 2006 which improved to No. Permendagri. 59 2007 on PKD.

4.1.2 Analysis the existing system RKA-SKPD Kota Malang

Financial SKPD application system can be described as follows: Input rekening Budget Input Input, edit, delete RKA Display Report and print VPN Virtual Private Network provisions of the budget plan sheet Figure 4.1.2.1 Rich Picture Existing system Base on Analysis system of RKA –SKPD Malang above there are some aspects that still can be improved, there are: 1. Their application still work in vpnvirtual private network ,means the application only can be accessed internal only. The researcher want to improve for accessed from public network. 74 2. for the developer want to improve their security of this program Researcher want to used web service and digital signature to increase security of their web. Web service used for bridge the data from vpn intranet system RKA malang and public network, in this case our system. And also add digital signature the system of RKA – Malang can be accessed more secure in public.

4.1.3 Analysis the proposed system.

Based on the problems that arise, the system is still in development stage and still needs improvement on a system that already running, to improve the security of the system itself. Input rekening Budget Input Input, edit, delete RKA Display Report and print VPN Virtual Private Network provisions of the budget plan sheet Web Service Web Secure Application request request response response Figure 4.1.3.1 Rich Picture Proposed System

4.1.3.1 Three main parts in this system.

1. Web service page in this case server for services. 75 Web service page provide service for all function which connected with internal database RKA SKPD Kota Malang, and as explained above, this module can bridge between intranet RKA SKPD Kota Malang and public network. 2. XML The Way to communicate or exchange the data between server web service and client is a XML Extensible Markup Language. There some response code in XML that represents process in system there are: 1. SS, description Success No error and valid signature 2. IS, description Invalid Signature if signature have problem

3. IP, description Invalid Passwordusername work in login form if

password username invalid.

4. LG, description Length Problem if there is problem in inputting length

parameter.

5. IE, description Insufficient Element if you forget to input mandatory

parameter in system. In client Side XML file that generate is request XML and in server side XML file that generate in response XML, The example of those XML can see bellow:

4.1.3.2 XML FORMAT

In example of XML request we can see their 3 main parts, there are: 1. Method ID Show and called which function in web service that we want to used. 2. Content 76 Contain with all data that we want to transfer. 3. Signature Contain Data that already encrypt in system. In example of XML response we can see their 4 main parts, there are: 1. Method ID Show and called which function are in web service that we want to use. 2. Content Contain with all data that we want to transfer. 3. Response Contain code and description that represent the result of executing function. 3. Signature Contain Data that already encrypt in system.

1. XML Login Request Format:

77 ? Xml version=1.0? MethodCall MethodID NameInputName MethodID Content UsernameusernameUsername PasspasswordPass Content Signature DataDataData Signature MethodCall Figure 4.1.3.2.1 XML Request Login Format

2. XML Login Data Description: No

Name Type Status Description Method ID 1. Name String Mandatory Method Name used to which function called in service Content 78 2. Username String Mandatory Username Format :Md5 Length : 30 max 3. Password String Mandatory Password Format : Md5 Length : 30 max Signature 4. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.1 Login request data description table

3. XML Response Login Format:

79 ? Xml version=1.0? ResponseMethod Content Usernameusernameusername Passpasswordpass Content Response CodeCodeCode DescriptionDescription Description Response Signature DataDataData Signature ResponseMethod Figure 4.1.3.2.2 XML Response Login Format

4. XML Login Response Data Description: No

Name Type Status Description Content 1. Username String Mandatory Username from request XML sender 2. Password String Mandatory Password from request XML sender Response 3. Code String Mandatory Response Code Length : 2 Fixed 80 4. Description String Mandatory Response Description Length : 50 max Signature 5. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.2 Login response data description table

5. XML Request Input Format:

81 Figure 4.1.3.2.3 XML Request Input Format

6. XML Input Request Data Description: No

Name Type Status Description Method ID 1. Input String Mandatory Method Name used to which function called in service Content 2. Urusan String Mandatory Purpose the activity Length : 30 max 3. Organisasi String Mandatory Organisation which 82 involved with the activity Length : 30 max 4. Program String Mandatory Activity that will be done Length : 30max 5. Kegiatan String mandatory List of activity Length : 30max 6. Tahun Numeric Mandatory Year of program being held Length : 4fix 7. Lokasi Kegiatan String Mandatory Location of program being held Length : 30max 8. N-1 Numeric Mandatory Budget previous year year -1 Length: 12max 9. N Numeric Mandatory Budget in current year Length: 12Max 10. N+1 Numeric Mandatory Budget in next year Length: 12Max 11. Capaian Program String Mandatory Target of Program Length : 30 Max 83 12. Capaian Program 2 String Mandatory Target of Program detail Length: 30 Max 13. Masukan 2 Numeric Mandatory Incoming budgeting for program being held Length: 12max 14. Masukan String Mandatory Description incoming budgeting Length : 30max 15. Keluaran String Mandatory Description out coming budgeting Length: 30max 16. Keluaran 2 String Mandatory Detail Description out coming budgeting Length: 30max 17. Hasil String Mandatory Result of activity Length: 30max 18. Hasil 2 String Mandatory Detail result of activity Length: 30max Signature 19. Data String Mandatory Data signature create by sender system to identify that the 84 massage is valid Table 4.1.3.2.3 input request data description table

7. XML Response Input Format:

Figure 4.1.3.2.4 XML Response Input Format

8. XML Input Response Data Description: No

Name Type Status Description Content 1. Urusan String Mandatory Purpose the activity Length : 30 max 2. Organisasi String Mandatory Organisation which involved with the 85 activity Length : 30 max 3. Program String Mandatory Activity that will be done Length : 30max 4. Kegiatan String mandatory List of activity Length : 30max 5. Tahun Numeric Mandatory Year of program being held Length : 4fix 6. Lokasi Kegiatan String Mandatory Location of program being held Length : 30max 7. N-1 Numeric Mandatory Budget previous year year -1 Length: 12max 8. N Numeric Mandatory Budget in current year Length: 12Max 9. N+1 Numeric Mandatory Budget in next year Length: 12Max 10. Capaian Program String Mandatory Target of Program Length : 30 Max 11. Capaian String Mandatory Target of Program 86 Program 2 detail Length: 30 Max 12. Masukan 2 Numeric Mandatory Incoming budgeting for program being held Length: 12max 13. Masukan String Mandatory Description incoming budgeting Length : 30max 14. Keluaran String Mandatory Description out coming budgeting Length: 30max 15. Keluaran 2 String Mandatory Detail Description out coming budgeting Length: 30max 16. Hasil String Mandatory Result of activity Length: 30max 17. Hasil 2 String Mandatory Detail result of activity Length: 30max Response 18. Code String Mandatory Response Code Length: 2fix 19. Description String Mandatory Response Description Length: 50 max 87 Signature 20. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.4 input response data description table

9. XML View Request Data Format:

Figure 4.1.3.2.5 XML Request View Format

10. XML View Request Data Description: No

Name Type Status Description Method ID 88 1. Name String Mandatory Method Name used to which function called in service Content 2. Page Numeric Mandatory Page of the data Length : 5 max Signature 4. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.5 view request data description table

11. XML View Response Data Format:

Figure 4.1.3.2.6 XML Response View Format

12. XML View Response Data Description:

89 No Name Type Status Description Content 1. Numpage Numeric Mandatory Number page of data Length : 5 max 2. Page Numeric Mandatory Page of data Length : 5 max 3. Id Alfa Numeric Mandatory Id skpd Length : 30max 4. Skpd String mandatory Detial activity of skpd Length : 30max 5. Program Numeric Mandatory Program of skpd Length : 4fix 6. Kegiatan String Mandatory Activity being held Length : 30max Response 18. Code String Mandatory Response Code Length: 2fix 19. Description String Mandatory Response Description Length: 50 max Signature 20. Data String Mandatory Data signature create by sender system to identify that the 90 massage is valid Table 4.1.3.2.6 view response data description table

13. XML Delete Request Data Format:

Figure 4.1.3.2.7 XML Request Delete Format

14. XML Delete Request Data Description:

No Name Type Status Description Method ID 1. Name String Mandatory Method Name used to which function called in service Content 91 2. Idrka Numeric Mandatory Number of id rka Length : 5 max Signature 4. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.7 delete request data description table

15. XML Delete Response Data Format:

Figure 4.1.3.2.8 XML Response Delete Format

16. XML Delete Response Data Description: No

Name Type Status Description Method ID 1. Name String Mandatory Method Name used to which function called in service Content 92 2. Idrka Numeric Mandatory Number of id rka Length : 5 max Response 3. Code String Mandatory Response Code Length: 5max 4. Description String Mandatory Response Description Length: 50Max Signature 5. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.8 delete response data description table 93

17. XML Request Edit Format:

Figure 4.1.3.2.9 XML Request Input Format

18. XML Input Request Data Description: No

Name Type Status Description Method ID 1. Edit String Mandatory Method Name used to which function called in service Content 2. Urusan String Mandatory Purpose the activity Length : 30 max 94 3. Organisasi String Mandatory Organisation which involved with the activity Length : 30 max 4. Program String Mandatory Activity that will be done Length : 30max 5. Kegiatan String mandatory List of activity Length : 30max 6. Tahun Numeric Mandatory Year of program being held Length : 4fix 7. Lokasi Kegiatan String Mandatory Location of program being held Length : 30max 8. N-1 Numeric Mandatory Budget previous year year -1 Length: 12max 9. N Numeric Mandatory Budget in current year Length: 12Max 10. N+1 Numeric Mandatory Budget in next year Length: 12Max 11. Capaian String Mandatory Target of Program 95 Program Length : 30 Max 12. Capaian Program 2 String Mandatory Target of Program detail Length: 30 Max 13. Masukan 2 Numeric Mandatory Incoming budgeting for program being held Length: 12max 14. Masukan String Mandatory Description incoming budgeting Length : 30max 15. Keluaran String Mandatory Description out coming budgeting Length: 30max 16. Keluaran 2 String Mandatory Detail Description out coming budgeting Length: 30max 17. Hasil String Mandatory Result of activity Length: 30max 18. Hasil 2 String Mandatory Detail result of activity Length: 30max Signature 19. Data String Mandatory Data signature create by sender system to 96 identify that the massage is valid Table 4.1.3.2.9 edit request data description table 19. XML Response Input Format: Figure 4.1.3.2.10 XML Response Edit Format

20. XML Edit Response Data Description: No

Name Type Status Description Content 1. Urusan String Mandatory Purpose the activity Length : 30 max 2. Organisasi String Mandatory Organisation which involved with the 97 activity Length : 30 max 3. Program String Mandatory Activity that will be done Length : 30max 4. Kegiatan String mandatory List of activity Length : 30max 5. Tahun Numeric Mandatory Year of program being held Length : 4fix 6. Lokasi Kegiatan String Mandatory Location of program being held Length : 30max 7. N-1 Numeric Mandatory Budget previous year year -1 Length: 12max 8. N Numeric Mandatory Budget in current year Length: 12Max 9. N+1 Numeric Mandatory Budget in next year Length: 12Max 10. Capaian Program String Mandatory Target of Program Length : 30 Max 11. Capaian String Mandatory Target of Program 98 Program 2 detail Length: 30 Max 12. Masukan 2 Numeric Mandatory Incoming budgeting for program being held Length: 12max 13. Masukan String Mandatory Description incoming budgeting Length : 30max 14. Keluaran String Mandatory Description out coming budgeting Length: 30max 15. Keluaran 2 String Mandatory Detail Description out coming budgeting Length: 30max 16. Hasil String Mandatory Result of activity Length: 30max 17. Hasil 2 String Mandatory Detail result of activity Length: 30max Response 18. Code String Mandatory Response Code Length: 2fix 19. Description String Mandatory Response Description Length: 50 max 99 Signature 20. Data String Mandatory Data signature create by sender system to identify that the massage is valid Table 4.1.3.2.10 edit response data description table 3. Digital Signature Digital Signature usually adds inside XML file format that already want to send. With this system can be more secure. In this case Researcher using RSA algorithm to protect their data. Researcher used two key in encrypting the system there are: 1. .key private key, used to encrypt the massage that wants to transfer. 2. .cer public key, used to decrypt the massage that already sends.

4.1.3.1 Basic Needs System

Here are the basic needs that must be met by the system to be designed: - User Needs In a secure web system users can log in and have the authority in running the system. Therefore that user can do, including the following: 1. Input Data In this case user can input the data to database in server with form input. 2. View Data In this case user can view data which needed in server. 3. Edit Data 100 In this case user can update the data from server database. 4. Management XML In this case user can see the log XML that processed in system.

4.1.3.2 Modeling the clasess

This class modeling shows that there are classes in the web secure system. Here are the candidates who obtained the entity classes based on needs of analysis RKA-SKPD Kota Malang: Table 4.1.3.2.1 Entity Class Candidates on the Web Secure system No Needs Class Entity 1. User can perform data management RKA such as add, view and modify data. user,RKA

2. User can perform converting

data into XML file user, xml

3. User can add digital signature

inside XML file. user , signature 4. User can perform searching data User, search

5. User can perform to see log of

xml User, log 101

4.1.3.3 Class Diagram

Class diagrams describe classes of objects that make up a system and also the relationship between object classes that occur in web secure system. Figure 4.1.3.1 Class Diagram

4.1.3.6 Statechart Diagram for the Proposed System

Statechart diagrams describe the specification of sequences of state caused by the sequence of events that exist in secure web system. 102 1. Statechart Diagram Login Page Web Secure system Start Display the login page Display Error Message Verify in Server Open The Aplication Input username and password Invalid Signature Error Happend Repeat Login End Generate Digital Signature XML file Display The Home Page Send XML file to server Signature TrueNo error Figure 4.1.3.6.1 Statechart Diagram Login Page In Statechart Diagram Figure 4.1.3.6.1 users make the event open the application, and then the state will display the login page. Then the user logs in by entering your username and password correctly in order to go to the page Web secure. If the username or password is entered incorrectly, the state would display an error message and asks the user to repeat the login. If the username and password is 103 entered correctly, then the state will display the users home page in according to the authentication. 4. Statcechart Diagram Management Xml Start Display Super Admin Home Page Display Xml Process Display Logout Menu Login As Super Admin Chose Logout Menu End Display Management Xml Module Chose Management Xml Module Xml Show in text Figure 4.1.3.6.4 Statechart Diagram Management Xml In Statechart Diargam Figure 4.1.3.6.4 user perform event, login,then the state will display the home page for the Super Admin. The Super Admin select event management xml menu and the state will display xml process log in system. 5. Statcechart Diagram View RKA-SKPD 104 Start Display Home Page Display View RKA Form Verify in Server Display data in table Display logout End Login Chose View RKA Generate Digital Signature And XML Valid Signature Chose Logout Menu Display Error Page Repeat View Invalid Signature Figure 4.1.3.6.6 Statechart Diagram View RKA SKPD In Figure 4.1.3.6.6 Statechart Diagram user performs event login, and then the state will display the users home page. To perform a view command, then state will process the data and generate the signature from data that already prepare to send and go to next step convert it into XML file Event select the logout menu made to exit the state system and the system will display the message out. 6. Statcechart Diagram Input RKA-SKPD 105 Start Display Home Page Display View RKA Form Verify in Server Display data in table Display logout End Login Chose View RKA Generate Digital Signature And XML Valid Signature Chose Logout Menu Display Error Page Repeat Input Invalid Signature Display Input RKA Form Chose Input RKA Menu Figure 4.1.3.6.7 Statechart Diagram Input RKA SKPD In Figure 4.1.3.6.7 Statechart Diagram user performs event login, and then the state will display the users home page. To perform a input command, then state display the input page and user input the data , then state will process the data and generate the signature from data that already prepare to send and go to next step convert it into XML file Event select the logout menu made to exit the state system and the system will display the message out. 7. Statcechart Diagram Edit RKA-SKPD 106 Start Display Home Page Display View RKA Form Verify in Server Display data in table Display logout End Login Chose View RKA Generate Digital Signature And XML Valid Signature Chose Logout Menu Display Error Page Repeat Edit Invalid Signature Display Edit RKA Form Chose Edit RKA Menu Figure 4.1.3.6.8 Statechart Diagram Edit RKA SKPD In Figure 4.1.3.6.8 Statechart Diagram user performs event login, and then the state will display the users home page. To perform a edit command, then state display the edit page and user updated the data, then state will process the data and generate the signature from data that already prepare to send and go to next step convert it into XML file Event select the logout menu made to exit the state system and the system will display the message out.