REQUIREMENTS MANAGEMENT PLAN PADA
EXTREME PROGRAMMING
ABSTRAK
Metodologi pengembangan perangkat lunak yang berkembang saat ini telah
beralih ke metodologi yang lebih sederhana. Metodologi yang dikenal sebagai
agile methods ini mengutamakan fleksibilitas terhadap perubahan-perubahan yang
terjadi selama pengembangan. Bahkan perubahan ataupun penambahan pada saat fase
terakhir pun teratasi apabila menggunakan metodologi ini. Salah satu yang
paling popuper yaitu eXtreme Programming. Metodologi ini memiliki keunikan yang
sebenarnya juga bisa menjadi kelemahannya, yaitu tanpa dokumentasi formal. .
Makalah ini akan mencoba memasukkan dokumentasi sederhana pada extreme
programming sebagai requirements management. Selanjutnya menjelaskan tentang
peran peran unit dalam requirement management plan serta proses proses yang
terjadi
Kata kunci : eXtreme Programming, requirements managemen plan.
BAB 1
PENDAHULUAN
1.1 Latar belakang
Management requirement planing tidak lain merupakan
konsep manajemen produksi yang berbicara mengenai cara tepat perencanaan
kebutuhan barang dalam berproduksi. Management requirement planing dalam
keberadaannya memanfaatkan kemampuan komputer untuk menyimpan dan mengolah data
yang berguna dalam operasionalisasi aktifitas perusahaan.
Management requirement planing mampu mengkoordinasikan berbagai fungsi dalam
perusahaan manufaktur seperti teknik, produksi, dan pengadaan. Dari karenanya,
Management requirement planing menarik tidak hanya menunjang decision making
tetapi juga total perannya mendukung aktifitas perusahaan.
Pada dasarnya Management requirement planing
terdiri dari jadwal induk produksi, dan catatan persediaan. Berdasarkan
informasi dari jadwal induk produksi diketahui permintaan suatu produk akhir.
Lantas, dengan mengetahui komponen yang membentuk Produk akhir, status
persediaan, waktu tenggang untuk memesan bahan maupun merakit komponen disusun
suatu perencanaan kebutuhan dari komponen yang diperlukan. Output Management
requirement planing tidak lain berbentuk jadwal pesanan pembelian komponen
kepada supplier atau bagian produksi dalam pengerjaan perakitan komponen
tertentu. Product explosion demikian terjadi karena demand produk akhir di
pecah ke dalam demand dari berbagai komponen produk tersbut.
1.2
Ruang Lingkup
Ruang lingkup penelitian meliputi
pengenalan terhadap metode baru yaitu Extreme Programming serta pengenalan terhadap
requirement management plan dan peran orang orang yang terlibat dalam proses
requirement management plan tersebut.
1.3 tujuan dan
manfaat
1.3.1 tujuan
tujuan dari requirement management
p Menetapkan dan menjaga kesepakatan dengan
customer dan stakeholder lain tentang apa yang harus dilakukan oleh system
p Untuk memberikan pemahaman yang lebih baik
kepada pengembang system tentang kebutuhan system
p Menetapkan
batasan system
p Untuk
menyediakan dasar perencanaan teknis
p Untuk menyediakan dasar perkiraan biaya
dan waktu pengembangan system
p Untuk
mendefinisikan user interface system
1.3.2 Manfaat
·
Manfaat dari requirement management plan antara
lain
·
Dengan requirement management plan dapat lebih
merencanakan sasaran management yang akan dilakukan
·
Dengan requirement management plan dapat lebih
mudah menganalisa permasalahan yang terjadi
·
Dapat
lebih memahami kebutuhan dari user
·
Dapat
membangun system yang tepat
BAB 2
LANDASAN TEORI
Kontoya (2000) menjelaskan bahwa model dari aktifitas proses rekayasa
requirement secara garis besar antara lain:
1. Requirement Elicitation
Requirement dari sistem ditemukan, digali dengan
cara melakukan konsultasi dengan stakeholder dari dokumentasi sistem
pengetahuan di bidangnya (domain knowledge) dari studi pasar. Nama lain
dari proses ini adalah pencarian/pengembilan requirement ( requirement
acquisition) ataupun penemuan/pencarian requirement (requirement discovery)
2.
Analisa requirement dan negosiasi
Requirement
dianalisa dengan detail dan dari berbagai stakeholder ditemukan negosiasi untuk
memutuskan requirement mana yang dapat diterima. Proses ini diperlukan karena
tidak dapat dihindari adanya konflik antara requirement dari berbagai sumber
yang berbeda. Informasi yang tidak lengkap ataupun pengungkapan requirementnya
tidak sesuai dengan angaran atau biaya yang tersedia (untuk pengembangan
sistem).kadang kala diperlukan fleksibilitas pada requirement dan negosiasi
untuk menentukan dan memutuskan kumpulan requirement yang disepakati (pada
sistem)
3. Requirement dokumentasi
Requirement yang telah disepakati didokumentasikan
dengan tingkat kedetailan yang wajar dan layak. Secara umum diperlukan dokumen
requirement yang dapat dimengerti oleh semua stakeholder ini berarti juga bahwa
requirement harus didokumentasikan dengan bahasa yang baik, mudah dimengerti
dan dengan bantuan diagram diagram
4. requirement validation
perlu dilakukan pengecekan yang cukup baik untuk
konsistensi dan kelengkapan requirement. Proses ini diajukan untuk menemukan,
mengidentifikasi masalah pada dokumentasi requirement sebelum digunakan sebagai
dasar bagi pengembangan sistem.
Isye (2002), mendefinisikan pengertian requirement managament sebagai
pendekatan systematic untuk mendapatkan, mengorganisasi, mendokumentasikan dan
mengatur perubahan requirement aplikasi software selain itu Requirement
management juga memastikan Software developer akan memecahkan permasalahan yang
tepat dan membangun system yang tepat pula
BAB 3
PEMBAHASAN
3.1 Pengertian Requirement
management
Requirement management merupakan pendekatan
systematic untuk mendapatkan, mengorganisasi, mendokumentasikan dan mengatur
perubahan requirement aplikasi software.
Requirement
management untuk memastikan Software developer akan memecahkan permasalahan
yang tepat dan membangun system yang tepat pula.
Proses requirements
engineering bukanlah merupakan hal yang mudah. Seorang
system analyst, project manager, atau siapapun yang
memegang peran project champion harus
mengumpulkan berbagai requirement dari
para stakeholder, menganalisarequirement tersebut,
mengkomunikasikasikannya dengan para programmer, serta menyelesaikan konflik
yang terjadi antar berbagai requirement
yang ada.
Seringkali
project champion ini harus
bekerja di luar kantor untuk bertemu dengan para stakeholder. Hal ini terutama terjadi pada kasus proyek software development di
mana
organisasi pengembang berbeda dengan organisasi yang pada akhirnya akan
menggunakan perangkat lunak tersebut.
3.2 EXTREME PROGRAMMING
Extreme Programming (XP) adalah metode pengembangan perangkat lunak
yang ringan dan termasuk salah satu agile methods yang dipelopori oleh
Kent Beck, Ron Jeffries, dan Ward Cunningham. XP merupakan agile methods yang paling banyak digunakan dan menjadi
sebuah pendekatan yang sangat terkenal. Sasaran XP adalah tim yang
dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan
sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements
yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang
sangat cepat.
XP sebagai sebuah metode yang dinamis diperlihatkan
dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar
yang diperlukan dalam XP. Kent Beck menyatakan bahwa tujuan jangka
pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values
yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values
tersebut adalah :
1.
Komunikasi (Communication)
2.
Kesederhanaan (Simplicity)
3.
Umpan Balik (Feedback)
4.
Keberanian (Courage)
Sebagai sebuah metodologi untuk mengembangkan
peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP ini
terdapat lima fase yaitu :
1. Exploration Phase
2. Planning Phase
3. Iteration to Release Phase
4. Productionizing Phase
5. Maintenance Phase
6. Death Phase
3.3
Persyaratan Manajemen Organisasi dan
Tanggung Jawab
Yang paling bertanggung jawab atas Kebutuhan
Manajemen dalam Electronic Records Archives terletak pada Program Direktur
(PD). Program direktur mewakili tanggung jawab untuk persyaratan persyaratan
management ke lapangan. Peran utama dalam management requirement adalah
:
- Requirements Officer,
- Configuration Management (CM) Specialist,
- Development Contractor,
- Engineering Review Board (ERB),
- Configuration Control Board (CCB),
- Users/Subject Matter Experts (SMEs),
- Quality Management (QM) Team,
- Team leader
- Risk Officer (RO).
- Configuration manager
- Requirements specifier
3.3.1 Requirements Officer
Persyaratan Officer yang bertanggung jawab untuk
memastikan bahwa kegiatan Persyaratan Manajemen dilakukan seperti yang
dijelaskan dalam rencana ini. Persyaratan Officer yang bertanggung jawab atas
pemeliharaan dan pelaksanaan rencana ini. Persyaratan Officer juga bertanggung
jawab untuk semua persyaratan yang terkait dengan masalah, rekomendasi, dan
jaminan bahwa persyaratan tersebut terpenuhi. Persyaratan Officer bertanggung
jawab untuk memastikan bahwa semua menerima persyaratan waktu respon.
Persyaratan Officer yang dipilih untuk Electronic Records Archives memiliki
pengalaman dan keahlian yang diperlukan untuk menjalankan tugas sebagai
Persyaratan Manajemen yang dijelaskan dalam rencana ini.
3.3.2 Configuration Management
(CM) Specialist
Spesialis
Configuration Management yang bertanggung jawab
untuk menjaga semua yang dikontrol sesuai dengan prosedur di Electronic Records
Archives Konfigurasi Rencana Pengelolaan (CMP).
3.3.3
Development Contractor
Development
Contractor merupakan Seseorang yang bertanggung jawab untuk
mengembangkan fungsionalitas yang dibutuhkan sesuai dengan standard prosedur proyek. Termasuk didalmnya aktifitas
utnuk melakukan pengumpulan kebutuhan, analisa dan perancangan, implementasi
dan pengujian.. Berdasarkan persyaratan yang disampaikan kepada pengembangan
oleh kontraktor Electronic Records Archives Program Management Office,
perkembangan lebih lanjut akan memperbaiki persyaratan untuk menentukan
fungsional, data, dan sistem persyaratan. Pengembangan kontraktor akan memberikan akhir persyaratan dalam bentuk
Sistem Persyaratan Spesifikasi untuk sistem, dan akan memimpin sebuah Tinjau
Persyaratan Sistem untuk persyaratan fungsional. Sebagai bagian dari System
Requirements Review, pengembangan kontraktor akan bertanggung jawab untuk
memastikan traceability ke tingkat persyaratan yang lebih tinggi.
3.3.4
Engineering Review Board (ERB)
Engineering Review Board yang
akan melaksanakan perannya dalam kaitannya dengan persyaratan perubahan dalam
cara yang ditetapkan dalam Configuration Management Plan. Misi dari Engineering Review Board adalah untuk
melakukan evaluasi teknis pada semua Masalah Laporan, Kebutuhan Ganti Proposal,
menyarankan penambahan, modifikasi atau revisi ke Electronic Records Archives
program dasar dan mendukung produk sebelum bekerja.
3.3.5
Configuration Control Board (CCB)
Configuration
Control Board yang melakukan perannya dalam kaitannya dengan persyaratan
perubahan dalam cara yang ditetapkan dalam Configuration Management Plan. Electronic Records Archives Configuration Control Board yang
bertanggung jawab atas semua perubahan ke Fungsional, dialokasikan, Produk, dan
Produksi dasar.
3.3.6
Users/Subject Matter Experts (SMEs)
User dan Users/Subject
Matter Experts memberikan masukan pada definisi persyaratan melalui
proses partisipasi dalam Integrated Product Teams (IPTs), pengguna konferensi,
dan persyaratan lainnya yang berkaitan dengan mengumpulkan kegiatan. User dan Users/Subject Matter Experts umumnya
menentukan kebutuhan bisnis karena keahlian mereka dalam proses bisnis,
sedangkan Electronic Records Archives Program
Management Office menterjemahkan dan
mendefinisikan kinerja dan persyaratan teknis.
3.3.7
Quality Management (QM) Team
Persyaratan audit dalam team Quality Management dalam mutu yang ditetapkan dalam quality
management team. Quality Management akan membantu dalam
menentukan kriteria evaluasi untuk persyaratan dan pengujian spesifikasi,
persyaratan evaluasi terhadap kriteria evaluasi, memastikan proses perbaikan
dilaksanakan dan didokumentasikan, berpartisipasi dalam Configuration Control
Board, dan memastikan personil partisipasi dan setuju terhadap persyaratan
alokasi.
3.3.8
Team leader
Pemimpin
tim adalah penghubung antara pihak manajemen dan pengembang. Pemimpin tim
bertanggungjawab untuk memastikan bahwa setiap aktifitas dilakukan dan
dimonitor sampai penyelesaiannya. Pemimpin tim juga bertanggungjawab untuk
memastikan bahwa staf pengembang mengikuti standar proyek dan sesuai dengan
jadwal proyek
3.3.9
Risk Officer (RO)
Seluruh risiko
persyaratan dan pengelolaan proses pembangunan, harus diidentifikasi, dikelola
dan ditetapkan di Electronic Records Archives Risk Management Plan (RKM). Persyaratan yang terkait dengan resiko
harus dilaporkan kepada Electronic Records Archives Risk
Officer
3.3.10
Training
setiap individu
Mengisi peran dalam menerima pelatihan yang berkaitan dengan peran yang ditetapkan dalam Electronic
Records Archives Kebutuhan Pelatihan Assesment (Tra) dan Rencana Pelatihan
Program Management Office.
3.3.11
Configuration manager
Manajer
konfigurasi bertanggungjawab untuk menyusun struktur produk dalam manajemen
perubahan, mendefinisikan dan mengalokasikan ruang kerja bagi pengembang, dan
melakukan integrasi. Manajer konfigurasi harus melaporkan hasil kegitannya
kepada manajer proyek
3.3.12
Requirements specifier
Seseeorang
gyang bertugas utnuk menyusun spesifikasi dari bagian fungsionalitas system
dengan menggambarkan aspek kebutuhan tersebut ke dalam satu atau lebih use
case. Requirement specifier juga bertanggungjawab untuk mempaketkan
usecase, menjaga integritas dari paket tersebut.
3.4 The Requirements Management Program
3.4.1 Requirements
Identification
Bagian ini menggambarkan tentang artifact
(dokumen, tipe kebutuhan dan atribut
kebutuhan) dan mendefinisikan bagaimana artifact tersebut diberi nama,
ditandai, dan diberi nomor.
3.5 Requirements
Change Management
3.5.1 Change
Request Processing and Approval
Setiap permintaan
perubahan yang diajukan oleh stakeholder, maka perubahan ynag diinginkan
tersebut harus dituangkan ke dalam dokumen tertulis, berisikan detail
perubahan, alasan dan dampak dari perubahan
Yang
diinginkan, Dokumen permohonan perubahan tersebut selanjutnya harus disetujui
oleh sponsor. Setelah mendapat persetujuan dari sponsor maka dokumen tersebut
harus diperiksa oleh manajer proyek (kepala Configuration Control Board) untuk
dilihat cakupan perubahannya Configuration Control Board akan mengaudit setiap
permintaan perubahan, kemudian akan menandai permohonan perubahan tersebut
dengan status diterima (accepted), membutuhkan tindak lanjut (need
more info) dan ditolak (rejected). Jika cakupan perubahan yang
diminta masih terhitung on budget, on schedule dan masih berada dalam
scope proyek maka akan segera ditindaklanjuti oleh pengembang untuk memenuhi
perubahan tersebut. Namun jika ternyata cakupan perubahan tersebut besar, tidak
on budget dan tidak on schedule maka aka diadakan pertemuan
antara stakeholder dengan pihak pengembang untuk pembicaraan lebih lanjut
berkenaan dengan rencana perubahan tersebut, sementara untuk perubahan yang
diluar scope proyek akan diabaikan. Detail dokumentasi terdapat pada Change
Management Plan.
3.5.2
Change Control Board (CCB)
Permohonan perubahan
harus dimasukkan ke dalam Rational ClearQuest untuk dievaluasi oleh Change
Central Board ( CCB). Configuration Control Board beranggotakan tim pelaksana
proyek, dikepalai oleh Pak Sugiharto dan akan diselenggarakan pertemuan berkala
untuk mengevaluasi seluruh perubahan yang diminta kepada kebutuhan dengan
menggunakan integrasi Rational ClearQuest RequisitePro.
3.5.3 Project Baselines
Proyek ini melalui 4
tahapan utama yaitu : Inception, Elaboration, Construction, and Transition.
Untuk setiap akhir iterasi tahapan dideliver dokumentas.
3.6 Concept Exploration Phase Requirements
Management
Tahap eksplorasi konsep Persyaratan Manajemen melibatkan pendatangan
dan pengembangan dari persyaratan untuk tingkat detail yang diperlukan untuk
digunakan oleh kontraktor pembangunan sebagai dasar untuk
tawaran pada Request for Proposal.
tawaran pada Request for Proposal.
3.7 Concept Exploration Phase
Requirements Development Process
Gambar 3.7 Concept Exploration Phase Requirements
Development High-Level Steps
3.7.1
Vision Development
Visi
pembangunan adalah proses pengembangan konsensus yang melihat dari cakupan
Electronic Records Archives program ini. Ini mencakup keseluruhan visi dan misi
untuk tujuan sistem. Ini adalah tingkat tertinggi-persyaratan yang terkait
dengan dokumen, yang menyatakan maksud dan tujuan dari sistem di highlevel
syarat-syarat yang memenuhi kebutuhan dan tujuan dari agen.
Visi
Electronic Records Archives untuk dikembangkan dengan menggunakan pendekatan
two-track. Pada track pertama, konsep Pernyataan visi dikembangkan berdasarkan
pada pemahaman tentang sistem oleh Electronic Records Archives Program Management Office. Pernyataan visi ini telah
digunakan untuk kedua awal konsep pembangunan dan sebagai masukan pada track
kedua dari visi pembangunan. Secara paralel, track kedua dari visi pembangunan
yang dilakukan oleh kepemimpinan tim untuk memperbaiki konsep dan visi untuk
menciptakan "buy-in" Electronic Records Archives untuk program ini. Akhir pernyataan visi yang telah disetujui
oleh Archivist dari Amerika Serikat.
3.7.2
Concept of Operations Development (ConOps)
Dokumen
Electronic Records Archives Concept of Operations (ConOps) merupakan salah satu
produk dari konsep tahap eksplorasi. Suatu konsep pembangunan Integrated Product Team menciptakan ConOps
dokumen. The ConOps menggambarkan karakteristik sistem dari sudut pandang
pengguna.
3.7.3
Concept Exploration Phase Requirements
Development Activities
Concept exploration phase requirements
development adalah kegiatan yang berulang. Serangkaian langkah
ini dilakukan untuk memperoleh awal persyaratan. Setelah melalui siklus yang
sama denganlangkah-langkah yang digunakan untuk terus memperbaiki persyaratan
ke titik yang diperlukan untuk dimasukkan dengan
Request for Proposal.
Request for Proposal.
Langkah-langkah berikut merupakan siklus
persyaratan pembangunan :
- Prepare for cycle,
- Elicit requirements,
- Analyze requirements,
- Formalize requirements, and
- Validate and Verify requirements.
3.7.3.1
Prepare for Cycle
Dalam persiapan untuk setiap siklus persyaratan
dari evolusi , berikut langkah-langkah yang harus diambil.
- Menetapkan tujuan dari siklus
penerimaan kriteria untuk setiap siklus harus
dikenal dengan pasti. Untuk
contoh, kriteria untuk siklus mungkin untuk memetakan masing-masing syarat tertentu perlu usaha atau tujuan. Artinya, setiap kebutuhan harus traceable ke pernyataan di Mission Needs Statement atau ke salah satu tujuan dari Rencana Strategis.
contoh, kriteria untuk siklus mungkin untuk memetakan masing-masing syarat tertentu perlu usaha atau tujuan. Artinya, setiap kebutuhan harus traceable ke pernyataan di Mission Needs Statement atau ke salah satu tujuan dari Rencana Strategis.
- Menentukan teknik untuk mengumpulkan siklus
Teknik untuk mengumpulkan atau memperbaiki
persyaratan yang ditetapkan untuk setiap siklus. Teknik ini termasuk
brainstorming Tingkat Integrated Product Team untuk menggunakan persyaratan
tingkat 0 dan tingkat 1, penciptaan dan penggunaan kasus dekomposisi, Object
Oriented Analysis, pengguna konferensi, wawancara, dan kuesioner untuk upaya
persyaratan perbaikan.
- Mengidentifikasi stakeholders/participants
Kunci
stakeholder diidentifikasi untuk tiap tiap cycle dari requirement gathering.
Hal ini termasuk mengidentifikasi kegiatan kedatangan peserta.
3.7.3.2
Elicit Requirements
Persyaratan dikumpulkan atau disempurnakan
dengan menggunakan teknik yang ditetapkan selama "persiapan".
3.7.3.3
Analyze Requirements
Persyaratan kandidat yang akan dianalisis
untuk membentuk persyaratan informal. Persyaratan yang dibuat harus konsisten
dan detail.
3.7.3.4
Formalize Requirements
Persyaratan
yang ditempatkan di RequisitePro requirement management tool. Traceability
matrices didefinisikan atau diperbarui.
3.7.3.5
Verify and Validate Requirements
Requirements Document yang
diverifikasi dan divalidasi oleh para stakeholder melalui pemeriksaan dan
wawancara untuk memastikan bahwa ia memenuhi tujuan yang telah ditetapkan dalam
siklus.
3.7.3.6
Concept Exploration Phase Requirements Review
Ketika
National Archives and Records Administration dan Electronic Records Archives
Program Management Office percaya persyaratan telah mencapai tingkat yang
sesuai untuk penyertaan dengan Electronic Records Archives Meminta Proposal ,
berikut ini tambahan kegiatan yang dilakukan dalam persiapan untuk Requirements
Review
3.7.3.7
Concept Exploration Phase Requirements Baseline
menjelaskan dasar fungsional dan kinerja
persyaratan desain dan kendala
entitas Electronic Records Archives secara keseluruhan. Program ini terdiri dari persyaratan yang ditetapkan di bawah persetujuan konfigurasi kontrol, menjelaskan suatu sistem yang menentukan spesifikasi fungsional dan kinerja sistem persyaratan, tinggi persyaratan sistem interface, sistem kendala teknis, dan kualifikasi yang diperlukan untuk memastikan pencapaian setiap kebutuhan. Fungsional dasar yang dihasilkan dari konsep eksplorasi didefinisikan sebagai tahap akhir dari Concept Exploration Phase Requirements Baseline.
entitas Electronic Records Archives secara keseluruhan. Program ini terdiri dari persyaratan yang ditetapkan di bawah persetujuan konfigurasi kontrol, menjelaskan suatu sistem yang menentukan spesifikasi fungsional dan kinerja sistem persyaratan, tinggi persyaratan sistem interface, sistem kendala teknis, dan kualifikasi yang diperlukan untuk memastikan pencapaian setiap kebutuhan. Fungsional dasar yang dihasilkan dari konsep eksplorasi didefinisikan sebagai tahap akhir dari Concept Exploration Phase Requirements Baseline.
3.8
Concept Exploration Phase Requirements
Development Cycles
requirements activities merupakan persyaratan untuk
kegiatan yang diberikan dalam Electronic Records Archives Program Rencana
pengelolaan (PMP). Bagian berikut
ini memberikan pendekatan untuk persyaratan pembangunan yang digunakan selama
pelaksanaan rencana ini. Memodifikasi pendekatan ini dapat dibuat jika
diperlukan selama kegiatan “Prepare for Cycle” pembangunan untuk setiap siklus
Konsep eksplorasi Kebutuhan Pengembangan proses terdiri dari tiga Iterasi
persyaratan pembangunan, antara lain:
persyaratan pembangunan, antara lain:
• Tingkat 0 Kebutuhan Pembangunan iteration,
• Tingkat 1 Kebutuhan Pembangunan iteration, dan
• Kebutuhan perbaikan iteration.
• Tingkat 1 Kebutuhan Pembangunan iteration, dan
• Kebutuhan perbaikan iteration.
3.8.1
Level 0 Requirements Development Iteration
Tingkat
the 0 persyaratan pendatangan berdasarkan masukan dari para anggota persyaratan Integrated Product Team, serta review dokumen dan
wawancara dengan senior staf National
Archives and Records Administration. Persyaratan Officer dilakukan analisis dan langkah-langkah formalisasi,
verifikasi dan validasi dilakukan oleh persyaratan Integrated Product Team.
3.8.2
Level 1 Requirements Development Iteration
Di Level 1 persyaratan pendatangan telah
dicapai oleh kombinasi brainstorming dan meninjau bahan baku dari tahap Tingkat
0. ini dilakukan oleh persyaratan Integrated Product Team, dan melibatkan
pengguna dari sistem dan UKM.
3.8.3
Requirements Refinement Iteration
Requirements refinement (final iteration) telah
disempurnakan oleh persyaratan berbasis Tingkat 1. pada pembuatan use case
dilakukan pencarian yang lebih lanjut dan persyaratan yang baru. Program
Management Office staf Electronic Records Archives yang dibuat dengan
menggunakan kasus yang telah diajukan ke grup terdiri dari anggota dari
Committee on Archival Requirements ditambah
dengan additional Subject Matter Expert ,untuk analisa,komentar dan validasi.
Committee on Archival Requirements dengan Subject Matter Expert komentar mengenai use case itu kemudian digunakan untuk memperbaiki
persyaratan, atau menciptakan syarat-syarat baru.
3.9
Concept Exploration Phase Requirements
Traceability and Allocation
persyaratan
traceability terdiri dari:
- Traceability antara National Archives and Records Administration Tujuan Strategis dan tingginya tingkat kebutuhan, Traceability antara menggunakan kasus dan tingginya tingkat kebutuhan, dan
- Traceability persyaratan tingkat high level
"parent" dan persyaratan. lower level "children"
requirements activities selama tahap konsep eksplorasi terdiri dari
requirement alicitation, dank arena itu ketentuan ini diharapkan dapat berubah.
Sejak Integrated Product Team dan use case merupakan sumber untuk mayoritas
Konsep tahap eksplorasi persyaratan.
3.10 Concept
Development Phase Requirements Management
National Archives and Records Administration akan memberikan
penghargaan kontrak kepada dua Kontraktor Pembangunan yang akan menganalisa
secara independen dan persyaratan yang diberikan kepada mereka oleh Electronic
Records Archives Program Management Office. Pengembangan masing-masing Kontraktor akan
menghasilkan sebuah sistem desain, berisi decomposed persyaratan mereka.
National Archives and Records Administration akan meninjau desain kontraktor,
dan memilih salah satu kontraktor untuk mengembangkan sistem Electronic Records
Archives.
Pengembangan konsep Persyaratan Manajemen Proses,
menggambarkan langkah-langkah proses Konsep Persyaratan Manajemen Pembangunan.
Gambar 3.10 Concept
Development Requirements Management Process
3.10.1
Provide Baselined Requirements to Development
Contractors
Electronic
Records Archives Program Management Office
menyediakan baselined persyaratan Pengembangan Kontraktor untuk digunakan
sebagai dasar kontraktor untuk persyaratan dekomposisi dan usaha desain.
3.10.2
Contractor Requirement Analysis
Persyaratan
yang diberikan kepada Kontraktor Pembangunan oleh Electronic Records Archives Program Management Office lebih disempurnakan oleh
para kontraktor ke tingkat yang diperlukan untuk merancang sistem Electronic Records Archives dan pelaksanaannya. Setiap Pembangunan Kontraktor bertanggung
jawab untuk menyampaikan hasil analisis persyaratan sistem mereka dalam bentuk
Spesifikasi Persyaratan Sistem (SyRS) dalam format traceability dan kriteria
yang ditetapkan dalam dokumen ini.
requirement akan dialokasikan untuk pembangunan
akan menambahkan dalam SyRSs berdasarkan petunjuk yang diberikan pada
Requirements Document.
3.10.3
System Requirements Review (SRR)
Tujuan System Requirements Review adalah untuk memastikan
kecukupan Pengembangan Kontraktor usaha untuk memfokuskan pada sistem
kelengkapan persyaratan dalam hal identifikasi, definisi, dan penentuan awal
kearah kemajuan dan Pengembangan Kontraktor sistem teknik pengelolaan usaha.
Beberapa kriteria yang dapat digunakan untuk persyaratan evaluasi meliputi:
• Traceability untuk kebutuhan akuisisi,
• Konsistensi dengan kebutuhan akuisisi,
• Konsistensi dengan kebutuhan akuisisi,
• Testability,
• Kelayakan dari sistem arsitektur, dan
• Kelayakan operasi dan pemeliharaan.
• Kelayakan dari sistem arsitektur, dan
• Kelayakan operasi dan pemeliharaan.
3.10.4
Electronic
Records Archives Program Management Office Reviews Requirements and Provides Feedback
Setelah
System Requirements Review, ketika Kontraktor Pembangunan kembali bekerja
terhadap desain mereka, maka Electronic Records Archives Program Management Office sekaligus meninjau dan menganalisa
persyaratan yang diberikan di System Requirements Review.
3.10.5
Development Contractors Produce System Design
Documents
Pengembangan
Kontraktor membuat desain dari sistem baselined persyaratan yang diberikan
Program Management Office oleh Electronic Records Archives, analisis
persyaratan mereka sendiri dan umpan balik yang diberikan oleh Electronic
Records Archives Program Management Office
pengembangan dari kontraktor System Requirements Review, dan hasil dari usaha
ini merupakan system design dokumen(SDDs).
3.10.6
System Design Reviews (SDRs)
Pengembangan
Kontraktor akan mempresentasikan system design dokumen ke Electronic Records
Archives Program Management Office di Desain
Sistem Review (SDRs). Tujuan Desain Sistem Review adalah untuk memastikan bahwa
Electronic Records Archives Program Management
Office dan Pengembangan Kontraktor sependapat bahwa desain sistem yang
diusulkan memenuhi fungsi dasar dan persyaratan kinerja.
3.10.7
Development Contractor Selected
Berdasarkan
pemeriksaan dan analisis dari System Design
Document yang diajukan oleh Kontraktor Pembangunan, National Archives and
Records Administration akan memilih salah satu Kontraktor Pembangunan untuk
mengembangkan Electronic Records Archives sistem.
3.11 Initial
Production Phase Requirements Management
Setelah persetujuan dari sdd oleh Electronic Records Archives Program Management Office, Development Contractor
mengembangkan sistem dalam lima kenaikan.
3.11.1
Increment Requirements Management
Kenaikan System
Requirements Review dekat dengan awal setiap kenaikan. Kenaikan System Requirements Review dilakukan bila sistem fungsional persyaratan
telah dialokasikan untuk kenaikan tersebut.
Tujuan kenaikan System Requirements Review adalah
untuk memastikan kecukupan Pengembangan dari Kontraktor usaha di fokus pada
kelengkapan persyaratan sistem mereka dalam hal identifikasi, definisi, dan
penentuan awal ke arah kemajuan dan Pengembangan Kontraktor sistem manajemen
usaha untuk ditetapkan kenaikannya.
3.11.2
Release Requirements Management
Untuk setiap pengeluaran, berikut
persyaratan yang terkait dengan kegiatan terjadi:
- mengalokasikan baselined persyaratan pengeluaran dan menganalisa persyaratan pengeluaran,
- Produksi System Requirements Specification untuk pengeluaran
- Melaksanakan System Requirements Review
- Mengubah control pengeluaran
Gambar 3.11.2 Release Requirements Management Process
3.11.2.1
Allocate Baselined Requirements to Release
Pada awal
pengeluaran, Electronic
Records Archives Program Management Office dan
Pengembangan Kontraktor kerja bersama-sama menentukan persyaratan untuk
mengalokasikan ke pengeluaran berdasarkan fungsi yang dilaksanakan.
3.11.2.2
Decomposition/Development of Release
Requirements
Berdasarkan Pembangunan Kontraktor dari
persyaratan analisis, kontraktor akan melakukan dekomposisi persyaratan yang
diperlukan jika ditemukan keperluannya. Dalam hal kehilangan requirement maka
pengembangan kontraktor mengembangkan persyaratan yang diperlukan.
3.11.2.3
Produce System Requirements Specification (SyRS)
for the Release
Development Contractor bertanggung
jawab untuk persyaratan yang tercakup oleh pengeluaran System Requirements Specification ke perangkat keras, perangkat
lunak, operasional dan komponen system mereka sebagai bagian dari pengeluaran System Requirements Specification
3.11.2.4
System Requirements Review (SRR) for Release
Development Contractor menyajikan
sebuah pengeluaran Produce System
Requirements Specification ke Electronic Records Archives Program Management Office untuk
persetujuan pengeluaran System Requirements Review.
Electronic
Records Archives Program Management Office
mengevaluasi Pengembangan Kontraktor dari pengeluaran System Requirements
Specification dan menentukan penerimaannya. Berdasarkan pada penerimaan System
Requirements Specification, hal hal yang akan terjadi antara lain :
·
Jika pengeluaran System Requirements
Specification dapat diterima, maka Electronic Records Archives Program Management Office akan menyetujui System Requirements Specification dan
persyaratan akan re-baselined jika diperlukan.
·
Jika pengeluaran System Requirements
Specification tidak diterima, maka Electronic Records Archives Program Management Office akan menolak ijin untuk
memulai pengembangan peningkatan. Pengembangan Kontraktor harus memperbaiki
kekurangan yang diidentifikasi oleh Electronic Records Archives Program Management Office, dan menghasilkan revisi
System Requirements Specification.
3.11.2.5
Release Change Control
requirements
Change Management process untuk tiap perubahan requirement diidentifikasi
selama pengeluaran yang bergantung pada apakah syarat-syarat yang diusulkan
akan berdampak pada perubahan jadwal atau biaya
dari keluaran. Pengembangan Kontraktor akan bertanggung jawab untuk melaksanakan proses Configuration Management. Bagian Pembangunan Kontraktor dari proses configuration management harus menyertakan Kontraktor Pembangunan Configuration Control Board. Electronic Records Archives Program Management Office Contracting Officer Representative (COR) akan memiliki bagian di pembangunan kontraktor Configuration Control Board.
dari keluaran. Pengembangan Kontraktor akan bertanggung jawab untuk melaksanakan proses Configuration Management. Bagian Pembangunan Kontraktor dari proses configuration management harus menyertakan Kontraktor Pembangunan Configuration Control Board. Electronic Records Archives Program Management Office Contracting Officer Representative (COR) akan memiliki bagian di pembangunan kontraktor Configuration Control Board.
Bagian ini menentukan apakah perubahan ini
cenderung berdampak proyek jadwal atau biaya. Perubahan yang tidak diharapkan
seperti dampak lingkup, jadwal, atau biaya dapat disetujui oleh Kontraktor
Pembangunan dari Configuration Control Board. Perubahan yang diharapkan
dapat berdampak lingkup, jadwal, biaya atau harus dirujuk ke Electronic Records
Archives Program Management Office Configuration Control Board untuk diperiksa dan
disetujui sebagai oleh Configuration Management Plan.
National
Archives and Records Administration akan menginformasikan Pengembangan
Kontraktor dari keputusan Electronic Records Archives Configuration
Control Board dan Pengembangan Kontraktor akan memperbarui persyaratan yang
ditetapkan untuk mencerminkan Electronic Records Archives Configuration Control Board dari keputusan.
Pengembangan Kontraktor akan bertanggung
jawab untuk menjaga melengkapi persyaratan traceability selama proses
pengeluaran.
Pengembangan Kontraktor akan diperlukan untuk
menjaga traceability, dalam hal ini, "sumber" adalah baselined
persyaratan yang diberikan kepada Kontraktor pembangunan oleh Electronic
Records Archives Program Management Office, atau
setelah persyaratan baselined.
3.11.3
Initial Production Phase Status Reporting
Persyaratan Officer yang akan menyediakan
kebutuhan yang berhubungan dengan data, diperlukan untuk generasi yang berisi
laporan sebagai berikut :
Ø Cakupan kebutuhan
Ø Kebutuhan pertanyaan
Ø Kebutuhan menilai perubahan
Ø
Kebutuhan review penyelesaian akhir
Ø
Kebutuhan review penyelesaian tepat waktu
Ø
System cakupan dan
Ø
Cakupan software desain
Ø
3.12 Requirements
Management Process Reviews
Persyaratan Manajemen Proses Review meliputi ulasan berikut:
- Management Review,
- Requirements Management Quality Management Review, and
- Independent Verification and Validation Review.
3.12.1
Management Review
Requirements Management activities akan
diperiksa secara teratur. Jadwal dan kegiatan yang terkendali ini ada pada Program Management Plan
3.12.2
Requirements Management Quality Management Review
Quality
Management Plan yang menggambarkan audit dari persyaratan
dan Persyaratan kegiatan Manajemen.
3.13 Requirements
Acceptance Criteria
Setiap kebutuhan Electronic
Records Archives akan diperiksa untuk
memastikan bahwa Electronic Records Archives memenuhi kriteria sebagai berikut:
.
.
ü
Apakah
valid ? Apakah persyaratan yang berbeda dan mewakili identitas yang diperlukan?
ü
Apakah
dapat diuji? Setiap kebutuhan harus dapat diverifikasi oleh pengujian atau
melalui analisis.
melalui analisis.
ü Apakah
traceable? Setiap kebutuhan harus traceable untuk kebutuhan lain.
ü
Apakah
jelas? Syarat harus dimengerti tanpa penjelasan lebih lanjut atau
pengetahuan.
pengetahuan.
ü
Apakah
ia independen? Persyaratan jangan "tumpang tindih," mereka harus
atomik.
ü
Apakah
itu layak? Apakah mungkin untuk dilaksanakan?
3.14 Resources
for Requirements Management
Sumber daya yang
dialokasikan untuk kebutuhan pengelolaan usaha sebagaimana tercantum dalam
Program Management Plan sebagai berikut:
v
Integrated
Product Team yang digunakan untuk mengembangkan dan memfalidasi persyaratan;
v Electronic
Records Archives Program Management Office yang
memberikan dukungan untuk persiapan atau pengumpulan dokumen kepada Integrated Product Team dan menbuat use case.
v Requirements
Management tool digunakan oleh Requirements Officer.
3.15 Tools
for Requirements Management
Persyaratan Manajemen
efektif harus didukung oleh alat yang telah ditetapkan. Pedoman
Pengembangan system National Archives and Records Administration menjelaskan
proses untuk mengevaluasi produk.
Requirement
management tool harus:
ü Memanfaatkan database
ü Memberikan kapasitas penomoran
ü Memberikan kapasitas nama yang berbeda
ü Memberikan pandangan yang berbeda dari
requirement
ü
Memberikan prioritas skema
ü
Menyediakan traceability matrices
3.16 Plan
Maintenance
Rencana akan diperbarui sesuai dengan kebutuhan saat
ini untuk mempertahankan dan mencukupi kebutuhan dari setiap kegiatan.
BAB 4
PENUTUP
4.1
Kesimpulan
Maka dapat dikatakan
requirement management plan merupakan suatu deskripsi yang menjabarkan
bagaimana proses requirement terjadi serta mengenalkan kepada kita akan peran
dan fungsi dari tiap unit yang terlibat dalam requirement management
plan.selain itu juga membahas tentang
garis besar penambahan fase requirements management pada eXtreme
Programming sangat membantu untuk lebih menstrukturkan metode ini. Requirements Management yang disisipkan
terutama difokuskan dalam hal dokumentasi. Pendokumentasian pada eXtreme Programming ini tidak akan
mengganggu proses secara keseluruhan karena dilaksanakan secara paralel dengan planning phase.
4.2
saran
orang orang yang berperan
dalam requirement management harus lebih optimal dalam tanggung jawabnya masing
masing agar setiap perencanaan dapat tertata dengan baik dan dapat berjalan
sesuai dengan waktunya atau sesuai dengan yang telah ditentuka
DAFTAR
PUSTAKA
Adib (2003), penerapan design pattern untuk implementasi alat Bantu, http://rambutan.sourceforge.net/files/rambutan-paper.pdf
Adrianto (2009), requirement management pada extreme programming,
http://adrianto.ruangkopi.com/eii2009/fullpaper/REQUIREMENTS_MANAGEMENT_PADA_EXTREME_PROGRAMMING.doc
Isye (2009), Requirement
management,
kisi-kisi UTS profesi kependidikan dan jawabannya
Berikut ini adalah isi kode etik guru di Indonesia, yaitu :
Guru berbakti membimbing peserta didik untuk membentuk manusia indonesia seutuhnya berjiwa Pancasila.
Guru memiliki dan melaksanakan kewjujuran professional.
Guru berusaha memperoleh informasi tentang peserta didik sebagai bahan melakukan bimbingan dan pembinaan.
Guru menciptakan suasana sekolah sebaik-baiknya yang menunjang berhasilnya proses belajar mengajar.
Guru memelihara hubungan baik dengan orang tua murid dan masyarakat sekitarnya untuk membina peran serta dan tanggung jawab bersama terhadap pendidikan.
Guru secara pribadi dan secara bersama-sama mengembangkan dan meningkatkan mutu dan martabat profesinya.
Guru memelihara hubungan profesi semangat kekeluargaan dan kesetiakawanana nasional.
Guru secara bersama-sama memelihara dan meningkatkan mutu organisasi PGRI sebagai sarana perjuangan dan pengabdian.
Guru melaksanaakn segala kebijakan pemerintah dalam bidang pendidikan.
FUNGSI KODE ETIK GURU
Pada dasarnya kode etik memiliki fungsi ganda yaitu sebagai perlindungan dan pengembangan bagi profesi. Fungsi seperti itu sama seperti apa yang dikemukakan Gibson dan Michel yang lebih mementingkan pada kode etik sebagai pedoman pelaksanaan tugas profesional dan pedoman bagi masyarakat sebagai seorang profesional.
Biggs dan Blocher mengemukakan tiga fungsi kode etik yaitu :
Melindungi suatu profesi dari campur tangan pemerintah.
Mencegah terjadinya pertentangan internal dalam suatu profesi.
Melindungi para praktisi dari kesalahan praktik suatu profesi.
Kode etik guru berfungsi sebagai seperangkat prinsip dan norma moral yang melandasi pelaksanaan tugas dan layanan profesional guru dalam hubungannya dengan peserta didik, orang tua/ wali siswa, sekolah dan rekan seprofesi, organisasi profesi, dan pemerintah sesuai dengan nilai-nilai agama, pendidikan, sosial, etika dan kemanusiaan.
Sutan Zahri dan Syahmiar Syahrun mengemukakan empat fungsi kode etik guru bagi guru itu sendiri, antara lain :
Agar guru terhindar dari penyimpangan tugas yang menjadi tanggung jawabnya.
Untuk mengatur hubungan guru dengan murid, teman sekerja, masyarakat dan pemerintah.
Sebagai pegangan dan pedoman tingkah laku guru agar lebih bertanggung jawab pada profesinya.
Penberi arah dan petunjuk yang benar kepada mereka yang menggunakan profesinya dalam melaksanakan tugas.
TUJUAN KODE ETIK GURU
Pada dasarnya tujuan merumuskan kode etik dalam suatu profesi adalah untuk kepentingan anggota dan kepentingan organisasi profesi itu sendiri. Secara umum tujuan mengadakan kode etik adalah sebagai berikut:
Untuk menjunjung tinggi martabat profesi
Dalam hal ini kode etik dapat menjaga pandangan dan kesan dari pihak luar atau masyarakat, agar mereka jangan sampai memandang rendah atau remeh terhadap suatu profesi. Oleh karena itu, setiap kode etik suatu profesi akan melarang berbagai bentuk tindak-tanduk atau kelakuan anggota profesi yang dapat mencemarkan nama baik profesi terhadap dunia luar. Dari segi ini, kode etik juga sering kali disebut kode kehormatan.
Untuk menjaga dan memelihara kesejahteraan para anggotanya
Yang dimaksud kesejahteraan di sini meliputi baik kesejahteraan lahir (material) maupun kesejahteraan batin (spiritual atau mental). Dalam hal kesejahteraan lahir para anggota profesi, kode etik umumnya memuat larangan-larangan kepada para anggotanya untuk melakukan perbuatan-perbuatan yang merupakan kesejahteraan para anggotanya. Dalam hal kesejahteraan batin para anggota profesi, kode etik umumnya memberi petunjuk-petunjuk para anggotanya untuk melaksanakan profesinya.
Untuk meningkatkan pengabdian para anggota profesi
Tujuan lain kode etik dapat juga berkaitan dengan peningkatan kegiatan pengabdian profesi, sehingga bagi anggota profesi dapat dengan mudah mengetahui tugas dan tanggung jawab pengabdian dalam melaksanakan tugasnya. Oleh karena itu, kode etik merumuskan ketentuan-ketentuan yang perlu dilakukan para anggota profesi dalam menjalankan tugasnya.
Untuk meningkatkan mutu profesi
Kode etik memuat norma-norma dan anjuran agar para anggota profesi selalu berusaha untuk meningkatkan mutu pengabdian para anggotanya.
Untuk meningkatkan mutu organisasi profesi
Untuk meningkatkan mutu organisasi profesi, maka diwajibkan kepada setiap anggota untuk secara aktif berpartispasi dalam membina organisasi profesi dan kegiatan-kegiatan yang dirancang organisasi.
GURU adalah setiap orang yang mengajarkan suatu hal yang
baru dapat juga dianggap seorang guru.
Profesi adalah pekerjaan
yang membutuhkan pelatihan dan penguasaan terhadap suatu pengetahuan
khusus.suatu pengetahuan, keahlian ,pengalaman , sikap dan prilaku atau
kepribadian yang mendapat pengakuan oleh masyarakat.
1. Kode
etik profesi
2. Pengetahuan
yang terorganisir
3.
4. Tingkat
pendidikan
5. Punya
sertifikat keahlian
6. Mengalami
proses tertentu ( magang, kkn / praktek lapangan)
7. Kesempatan
menyebarluaskan dan penukaran ide di antara anggota profesi
8. Adanya
disiplin dan batasan tertentu
Kode etik guru ialah pedoman yang mengatur hubungan guru
dengan teman kerja, murid dan wali murid, pimpinan dan masyarakat serta dengan
misi tugasnya.
Kode Etik GuruBerikut ini adalah isi kode etik guru di Indonesia, yaitu :
Guru berbakti membimbing peserta didik untuk membentuk manusia indonesia seutuhnya berjiwa Pancasila.
Guru memiliki dan melaksanakan kewjujuran professional.
Guru berusaha memperoleh informasi tentang peserta didik sebagai bahan melakukan bimbingan dan pembinaan.
Guru menciptakan suasana sekolah sebaik-baiknya yang menunjang berhasilnya proses belajar mengajar.
Guru memelihara hubungan baik dengan orang tua murid dan masyarakat sekitarnya untuk membina peran serta dan tanggung jawab bersama terhadap pendidikan.
Guru secara pribadi dan secara bersama-sama mengembangkan dan meningkatkan mutu dan martabat profesinya.
Guru memelihara hubungan profesi semangat kekeluargaan dan kesetiakawanana nasional.
Guru secara bersama-sama memelihara dan meningkatkan mutu organisasi PGRI sebagai sarana perjuangan dan pengabdian.
Guru melaksanaakn segala kebijakan pemerintah dalam bidang pendidikan.
FUNGSI KODE ETIK GURU
Pada dasarnya kode etik memiliki fungsi ganda yaitu sebagai perlindungan dan pengembangan bagi profesi. Fungsi seperti itu sama seperti apa yang dikemukakan Gibson dan Michel yang lebih mementingkan pada kode etik sebagai pedoman pelaksanaan tugas profesional dan pedoman bagi masyarakat sebagai seorang profesional.
Biggs dan Blocher mengemukakan tiga fungsi kode etik yaitu :
Melindungi suatu profesi dari campur tangan pemerintah.
Mencegah terjadinya pertentangan internal dalam suatu profesi.
Melindungi para praktisi dari kesalahan praktik suatu profesi.
Kode etik guru berfungsi sebagai seperangkat prinsip dan norma moral yang melandasi pelaksanaan tugas dan layanan profesional guru dalam hubungannya dengan peserta didik, orang tua/ wali siswa, sekolah dan rekan seprofesi, organisasi profesi, dan pemerintah sesuai dengan nilai-nilai agama, pendidikan, sosial, etika dan kemanusiaan.
Sutan Zahri dan Syahmiar Syahrun mengemukakan empat fungsi kode etik guru bagi guru itu sendiri, antara lain :
Agar guru terhindar dari penyimpangan tugas yang menjadi tanggung jawabnya.
Untuk mengatur hubungan guru dengan murid, teman sekerja, masyarakat dan pemerintah.
Sebagai pegangan dan pedoman tingkah laku guru agar lebih bertanggung jawab pada profesinya.
Penberi arah dan petunjuk yang benar kepada mereka yang menggunakan profesinya dalam melaksanakan tugas.
TUJUAN KODE ETIK GURU
Pada dasarnya tujuan merumuskan kode etik dalam suatu profesi adalah untuk kepentingan anggota dan kepentingan organisasi profesi itu sendiri. Secara umum tujuan mengadakan kode etik adalah sebagai berikut:
Untuk menjunjung tinggi martabat profesi
Dalam hal ini kode etik dapat menjaga pandangan dan kesan dari pihak luar atau masyarakat, agar mereka jangan sampai memandang rendah atau remeh terhadap suatu profesi. Oleh karena itu, setiap kode etik suatu profesi akan melarang berbagai bentuk tindak-tanduk atau kelakuan anggota profesi yang dapat mencemarkan nama baik profesi terhadap dunia luar. Dari segi ini, kode etik juga sering kali disebut kode kehormatan.
Untuk menjaga dan memelihara kesejahteraan para anggotanya
Yang dimaksud kesejahteraan di sini meliputi baik kesejahteraan lahir (material) maupun kesejahteraan batin (spiritual atau mental). Dalam hal kesejahteraan lahir para anggota profesi, kode etik umumnya memuat larangan-larangan kepada para anggotanya untuk melakukan perbuatan-perbuatan yang merupakan kesejahteraan para anggotanya. Dalam hal kesejahteraan batin para anggota profesi, kode etik umumnya memberi petunjuk-petunjuk para anggotanya untuk melaksanakan profesinya.
Untuk meningkatkan pengabdian para anggota profesi
Tujuan lain kode etik dapat juga berkaitan dengan peningkatan kegiatan pengabdian profesi, sehingga bagi anggota profesi dapat dengan mudah mengetahui tugas dan tanggung jawab pengabdian dalam melaksanakan tugasnya. Oleh karena itu, kode etik merumuskan ketentuan-ketentuan yang perlu dilakukan para anggota profesi dalam menjalankan tugasnya.
Untuk meningkatkan mutu profesi
Kode etik memuat norma-norma dan anjuran agar para anggota profesi selalu berusaha untuk meningkatkan mutu pengabdian para anggotanya.
Untuk meningkatkan mutu organisasi profesi
Untuk meningkatkan mutu organisasi profesi, maka diwajibkan kepada setiap anggota untuk secara aktif berpartispasi dalam membina organisasi profesi dan kegiatan-kegiatan yang dirancang organisasi.
Fungsi guru
Mendidik, mengajar, menbimbing, mengarahkan
7 prinsip etika guru
Berbangsa dan bernegara
Beragama
Berorganisasi
Profesi guru
Berelasi dengan rekan atau mitra kerja
Bermasyarakat
Menjaga lingkungan
Tidak ada komentar:
Posting Komentar