Quality checking of DFD

• Correctness checking determines that the syntax and connections used in diagrams, charts, and so forth are  accurately used. 
• Completeness checking is  performed with the  users  to  validate  the  meanings  of  all  terms and to verify the semantics used in all documentation.  
• Consistency  checking  ensures  consistency  and  correctness  of  all  entries  that  span multiple diagrams, text, charts, and so on.  Consistency  checks  evaluate  the  interitem  syntax  and semantics. These checks are first performed by the project team during walk-throughs or other quality assurance evaluations. Then, they may be reviewed by  independent  quality  assurance  analysts  as  an added check. 

Sumber: Conger, 2008

Decompose Level 0 to Level 1

For each Level 0 process,

1. Draw the input and output flows  and the icons to which they connect from the higher level diagram. This forms the skeleton of the diagram. These are called the net  inflows and outflows. 
2. Define the subprocesses by asking, "What are the steps required to do this process?" Then for each step, "Can I separate this from the other steps and do  it in isolation?" For each subprocess you isolate,  draw a process rec-tangle on the lower level diagram. 
3. Identify whether data stores are required or not. Add them and, if they are new,  name them. 
4. Identify data flows  to complete the diagram.  Make sure you provide all and only the information required to perform the process. 
5. Review the diagram for unnecessary connec-tions and,  if found,  remove them. 
6. Update the  data dictionary with all new information.

Sumber: Conger, 2008

Identify the Level 0 processes

• Identify the Level 0 processes that are  within the circle of the context diagram, without defining any data stores.
• The difficulty of this activity varies with your understanding of the problem domain and the  scope of the project.
• After the processes are  identified, next define file locations  on  the  Level  0  data flow  diagram.  
• You could  leave  files  for  a  lower  level  of analysis  as many texts and companies do by convention. In that case, you are ready to  draw the diagram.  
• To  identify data stores, first consider each process.  
• Can the process be completed without reading or writing to a data store? 
• If your answer is yes, then you do  not need a file  at this level. 
• If the answer is no,  you need one data store for every required read action and every required write action.  
• Many times, the reads and writes are to the same data store. Then, you have one data flow per input/output action. 
• As these required reads and writes are identified, you add to the DFD to  include the data store name and data flow(s).  
• When you do  this part of the drawing, make sure that each flow  and store has a name. 

Level 0 Syntax Rules:

1. All processes are connected to something else. 
2. All process have both inputs and outputs. 
3. No processes have only outputs or only inputs. 
4. Processes may connect to  anything:  other processes, data stores, or entities. 
5. All processes have a unique name and number. 
6. Each process number is used once in the diagram set. 
7. Only subprocesses of a process shall follow the numbering scheme of the parent process. 
8. Entities and data stores may connect only to processes. Another way to state this is that each data flow must have at least one end connected to  a process. 
9. Data flows  are the only legal type of connection between entities, processes, and data stores. 
10. Make sure there are no  dangling arrows. 
11. The net data flows  to  and from context diagram external entities must balance, that is, be present, in each level of DFDs. 
12. Trivial errors and exceptions are  not handled until L1 or lower in the DFD set. 
13. Trivial data stores show up in the diagram set the first time they are referenced by a process. 

Sumber: Conger, 2008

Data Flow Diagram

• A data flow diagram (DFD) is a  graphic representation of the application's component parts. 
• The entities and data flows  from  the  context diagram are  all  present ini DFD.  
• Data flows may connect processes to other processes,  data  stores,  or  external  entities.  
• Data stores and external entities do not interact directly with each other. 
• All entities and data flows from the higher level processes must be in every more detailed diagram.  The names of entities and data flows must be consistent across the levels of the  diagrams

DFD Rules:

1. Define the processes. 
2. Define the files  and other data flows  required to support the processes. 
3. Draw a Level 0 DFD. At level 0,  ignore trivial error paths and data stores. If you define a validation process, you must eventually identify an error path.  Define the error path at the primitive level. Similarly for data stores, define files  when they are shared between processes. Introduce files  that are only used within a given process at the level at which the file  is shared between two or more subprocesses.
4. Balance the DFD with the context diagram. Compare the net inputs and outputs to external entities on the DFD to the net inputs and outputs on the context diagram. There should be a one-to-one correspondence between the diagrams. 
5. Iterate through this procedure until the primi-tive level of DFD is reached for  all processes. Always balance the current level DFD's net inputs and outputs with those of the previous level.

Sumber: Conger, 2008

Data Flows

• Data flows  are  information about some business event being tracked by the  application.  
• A data flow  is  data or information that is  in transit. 
• A  data flow  might be a piece of paper, a report,  a diskette,  or a computer message.  
• Data flows  in  a diagram are directed arrows that depict data movement from one place to  another. 
• They do not identify physical items. 
• For example, an invoice is information  about  an  order  that  would  also  have actual goods.  A data flow  to a customer shows the invoice but not the physical goods. 
• for each data flow,  create a definition in the data dictionary. 

The dictionary of Data Flow

• Name, 
• Alias,
• Timing,
• Contents, 
• Constraints

Sumber: Conger, 2008

External Entity

• External entities are people, places, or things which interact with the application. 
• Usually, we identify titles/roles (e.g.,  Customer), departments (e.g., Accounts Receivable), organizations (e.g., Medicare Administration), or applications (e.g.,  Accounts Receivable Application) as entities. 
• The phrase 'interact with the application'  has a very specific meaning.  
• The entity is  outside the control and/or processing being modeled for the  current application.  That is,  external entity processing, procedures, and data are not subject to analysis or change. 
• Relationships between external entities are  not shown on the diagram(s) (i.e., external entities cannot connect to  each other).
• if you are modeling an  order processing application that does not do inventory control, the warehouse would be on the context diagram.  
• If inventory  control  and  warehouse  processing  are within the scope of the application, the warehouse would not be on the context diagram

Dictionary of External Entity

• Entity Name
• Aliases
• Definition
• Relationship to Application
• Contact, if entity is an organization

Sumber: Conger, 2008

Contex Diagram

Introduction:

• A context diagram depicts the scope of the project, using circles, squares, and arrows.  
• A large circle  designates  the  application. 
• Squares  identify external entities  with  which  the application must interact.  
• Directed lines are the data flows  which indicate movement of data between entities and the application.

Rules:

• Define the boundaries (i.e.,  scope) of the application. Specifically, define what the application will do and what it will not do.  Draw the circle identifying the application and write the application name in the center. 
• Using the application boundary as  a starting point, identify all external entities with which the application must interact. For each entity, draw one square on the diagram and label the square. 
• For each entity, create a definition in the data dictionary. 
• For each external entity, identify the specific data flows  that define the interface. 
• For each data flow,  create a definition and list of tentative contents in the data dictionary. 
• For a complex application, you might need two levels of context  diagrams.  
• One level  summarizes all entities with directed arrows  that are unlabeled. 
• The other level shows input flows  on one diagram, and output flows  on the other diagram with labeled data flows  on both diagrams.

Sumber: Conger, 2008

Manajemen Pengetahuan (Knowledge Management) pada Unit Layanan Pengadaan (ULP)

Terminologi Pengetahuan (Knowledge) pertama kali diperkenalkan oleh Henry pada tahun 1974 yang mengungkapkan adanya perbedaan makna dan adanya transisi dari data, informasi hingga menjadi knowledge (Wallace, 2007). Adapun istilah manajemen pengetahuan (knowledge management) yang dikenal luas di dunia bisnis adalah suatu pengelolaan sumber daya untuk dapat menangkap, menyimpan, menyebarluaskan dan menggunakan pengetahuan-pengetahuan yang dimiliki organisasi untuk menjadikan organisasi lebih baik dari waktu ke waktu (Smith, 1971 dalam Wallace 2007; Dalkir, 2005; Nonaka dan Takeuchi, 1995).

Manajemen pengetahuan saat ini tidak hanya dikenal dalam perusahaan swasta (private sector) tetapi juga sudah dikenal pada organisasi pemerintahan (public sector). Setiadi, dkk (2011)  mengungkapkan bahwa penerapan manajemen pengetahuan di organisasi pemerintahan hampir sama dengan organisasi swasta. Perbedaannya, organisasi swasta tujuanya adalah profit, sedangkan organisasi pemerintahan tujuan akhirnya adalah peningkatan layanan publik.Sejumlah literatur menunjukkan bahwa organisasi pemerintahan telah menginisiasi penerapan manajemen pengetahuan (Syed-Ikhsan dan Rowland, 2004; Menteri Negara Pendayagunaan Aparatur Negara dan Reformasi Birokrasi, 2011; Badan Pengkajian dan Penerapan Teknologi, 2012). Penerapan manajemen pengetahuan pada organisasi pemerintahan ditujukan untuk mempermudah proses penciptaan, pengumpulan, penyimpanan, dan berbagi-tukar pengetahuan (knowledge sharing), menutup kesenjangan pengetahuan antara satu karyawan dengan karyawan lainnya dan meningkatkan kemampuan organisasi dalam mengelola aset intelektual, pengetahuan dan pengalaman yang ada (Bappenas, 2011; Ningky, 2010).

Penerapan manajemen pengetahuan, khususnya pada organisasi pemerintahan di Indonesia sampai awal tahun 2012 belum masif karena baru dikeluarkannya pedoman pelaksanaan program menajemen pengetahuan oleh Menteri Negara Pendayagunaan Aparatur Negara dan reformasi Birokrasi pada tahun 2011. Selain itu, penerapan manajemen pengetahuan belum menyentuh ke unit-unit organisasi pemerintahan, yakni Kantor/Lembaga/Pemerintah Daerah/Instansi (K/L/D/I). Penerapan manajemen pengetahuan masih diperuntukkan untuk Unit Pengelola Reformasi Birokrasi Nasional (UPRBN) dalam mengelola forum manajemen pengetahuan yang dapat dimanfaatkan sebagai knowledge sharing yang berguna baik dalam perumusan kebijakan reformasi birokrasi nasional dan juga sebagai benchmarking bagi Kementerian/Lembaga dan Pemerintah Daerah (Menteri Negara Pendayagunaan Aparatur Negara dan Reformasi Birokrasi, 2011).

Penerapan manajemen pengetahuan yang dilakukan UPRBN tentu belum bisa memberikan hasil yang optimal dalam mengelola pengetahuan organisasi pemerintah. Idealnya, penerapan manajemen pengetahuan langsung diterapkan pada seluruh atau sebagian K/L/D/I yang banyak mengelola pengetahuan dalam bentuk inovasi atau peraturan-peraturan. K/L/D/I yang banyak mengelola inovasi atau peraturan-peraturan. Manajemen pengetahuan di sini diperlukan agar organisasi mampu melaksanakan fungsinya secara efektif akibat tidak adanya gap pengatahuan pada setiap elemen organisasi.

Salah satu organisasi pemerintah yang relevan menerapkan manajemen pengetahuan adalah lembaga pengadaan (procurement) (Bappenas, 2011). Lembaga pengadaan ini adalah Unit Layanan Pengadaan (ULP), yakni unit organisasi pemerintah yang berfungsi melaksanakan Pengadaan Barang/Jasa di K/L/D/I yang bersifat permanen, dapat berdiri sendiri atau melekat pada unit yang sudah ada (Republik Indonesia, 2010). ULP relevan menerapkan manajemen pengetahuan karena dalam melaksanakan tugasnya, staf ULP harus memiliki pengetahuan yang utuh terhadap semua aturan-aturan Pengadaan Barang/Jasa dan best practice dalam melaksanakan Pengadaan Barang/Jasa. Kurangnya pengetahuan staf ULP terhadap kedua aspek tersebut, terkadang menyebabkan staf ataupun pimpinan lembaga pemerintah terjebak dalam kasus hukum.

Selain karena ULP mengelola pengetahuan yang sangat dinamis dari waktu-kewaktu, struktur organisasi ULP dikelola oleh gabungan orang-orang dari berbagai instansi sehingga budaya (culture) berbagi (sharing) pengetahuan mutlak diperlukan untuk menjadikan pemahaman setiap staf menjadi utuh. Disamping itu, struktur organisasi yang relatif ramping dan baru terbentuk di semua wilayah menjadikan ULP relatif mudah untuk menerima penerapan sistem manajemen pengetahuan, dan ini tentunya berbeda dengan organisasi yang telah lama terbentuk yang terkadang memiliki retensi terhadap perubahan atau penggunaan sistem baru. Dengan demikian, apabila pemerintah hendak menerapkan manajemen pengetahuan pada K/L/D/I maka ULP adalah salah satu organisasi yang sangat relevan untuk segera menerapkannya.

Penerapan manajemen pengetahuan pada ULP memerlukan persiapan yang baik. Berdasarkan Pedoman Pelaksanaan Program Manajemen Pengetahuan, ada tiga tahapan utama dalam implementasi manajemen pengetahuan, yakni tahap perencanaan, tahap implementasi, dan tahap evaluasi serta penyempurnaan manajemen pengetahuan (Menteri Negara Pendayagunaan Aparatur Negara dan Reformasi Birokrasi, 2011). Tahap perencanaan tersebtu tersusun dari sejumlah tahapan: (1) Identifikasi konteks manajemen pengetahuan dalam organisasi; (2) Identifikasi praktek manajemen pengetahuan dalam organisasi; (3) Identifikasi dan melakukan analisis terhadap para pemangku kepentingan; (4) Perumusan strategi manajemen pengetahuan; (5) Pengembangan strategi manajemen perubahan; dan (6) Pengembangkan strategi implementasi manajemen pengetahuan.

Panjangnya tahapan penerapan manajemen pengetahuan mengindikasikan bahwa manajemen pengetahuan tidak dapat serta merta langsung diterapkan di ULP. Selain itu, oleh karena staf ULP tidak semuanya memahami konsep manajemen pengetahuan, maka diperlukan pihak lain di luar ULP yang dapat membantu penerapan manajemen pengetahuan. Oleh karena itu, penelitian ini bermaksud mengkaji tahap perencanaan manajemen pengetahuan untuk ULP. Melalui kajian ini diharapkan membantu secara khusus ULP dan secara umum Pemerintah Indonesia untuk melihat lebih teknis apa-apa yang perlu dipersiapkan dalam penerapan manajemen pengetahuan pada level K/L/D/I.

---

Technorati Tags: Unit Layanan Pengadaan (ULP),Manajemen Pengatahuan (Knowledge Management)

Aplikasi P2M Fakultas Teknik

Sistem informasi Pengelolaan Data Penelitian dan Pengabdian kepada Masyarakat Fakultas Teknik (PPMFT) Universitas Sebelas Maret adalah sebuah aplikasi berbasis web yang digunakan untuk mengelola data P2M yang dilakukan oleh dosen-dosen Fakultas Teknik UNS. Fitur aplikasi dibedakan berdasar jenis user yaitu Umum, Dosen dan Administrator.

http://ft.uns.ac.id/ppmft

Output aplikasi ini antara lain:

www-data problem on Ubuntu

Secara default, Apache pada server ubuntu berjalan dengan user dan grup www-data. Masalah sering timbul apabila website yang dibuat tidak menggunakan user www-data, melainkan menggunakan user lain (user baru dengan lokasi direktori sesuai direktori ftp). Masalah umum yang terjadi adalah terkait privilege file atau folder yang diupload menggunakan website. Secara default, file atau folder yang dibuat melalui website, maka pemiliknya adalah user www-data. Akibatnya, apabila user ftp akan menghapus, atau mengedit atau bahkan menambahkan file lain ke dalam folder yang dibuat sebelumnya oleh www-data, user ftp ini tidak punya hak akses. Umumnya orang masuk sebagai root kemudian melakukan chmod 777 terhadap file atau folder. Namun demikian, cara ini tidak efektif apabila website yang dibuat berfungsi untuk mengupload banyak file/folder yang namanya berubah sesuai waktu dan terkadang penambahan bisa melalui web ataupun ftp.

Cara ini sebenarnya tidak disarankan, namun cukup ampuh apabila di dalam satu server hanya ada sebuah website saja.

Masukklah sebagai root:

hpserver# nano /etc/apache2/envvars

Ubah user dan group www-data menjadi user ftp yang akan digunakan (misal user ftp adalah hpserver):

export APACHE_RUN_USER=hpserver
export APACHE_RUN_GROUP=hpserver
export APACHE_PID_FILE=/var/run/apache2.pid

Kemudian restart apache

hpserver# /etc/init.d/apache2 restart

Silahkan lihat di phpinfo(), sekarang user handler apache bukan lagi www-data melainkan hpserver :)

Technorati Tags: www-data,server,Ubuntu,Apache,Pemrograman PHP