Skripsi Mini Series Part 3: Development Methodology (Metodologi Pengembangan)

1. What is Chapter 3: Development Methodology (BAB III: Metodologi Pengembangan)?

Chapter 3: Development Methodology turns the questions from Chapter 1: Introduction (BAB I: Pendahuluan) into a concrete, executable plan. Chapter 1 asked what you want to know; Chapter 3 answers how you will find out and, just as importantly, how you will measure it. A typical Polinema JTI Development Methodology chapter covers these subsections:

Get this chapter wrong, and everything downstream suffers: an undefined metric in Chapter 3 cannot be reported credibly in Chapter 6.

1. Apa Itu BAB III: Metodologi Pengembangan?

BAB III (Metodologi Pengembangan) adalah bab yang mengubah pertanyaan BAB I Anda menjadi rencana yang konkret dan dapat dieksekusi. Jika BAB I menanyakan apa yang ingin Anda ketahui, BAB III menjawab bagaimana Anda akan mengetahuinya, dan, yang krusial, bagaimana Anda akan mengukurnya. Bab Metodologi JTI Polinema yang tipikal mencakup:

Jika penulisan bab ini keliru, semua yang mengikutinya akan terdampak: metrik yang tidak terdefinisi di BAB III tidak dapat dilaporkan secara kredibel di BAB VI.

2. Why Getting the Methodology Right Matters

What is it?

The Development Methodology chapter is the operational contract for your project: a defined process, a defined timeline, and defined instruments. It mirrors the same discipline a software team applies before a sprint begins.

Why does it matter?

• A defined methodology is the single biggest lever for finishing on time. Naming your methodology, with explicit phases and a timeline, turns “build a Todo app” into a checklist you can actually track week by week.
• A defined methodology makes your comparison defensible. Without a precisely defined metric, such as “cyclomatic complexity, measured with PHPMD, averaged per method”, a reviewer cannot tell whether your Chapter 6 numbers mean anything.
• What you define here becomes your actual research instrument, not just a description of one. Whatever you specify in this chapter (the tools, the formulas) you must run for real in Chapter 5 and report in Chapter 6. A vague definition here becomes an impossible measurement later.

When do you use it?

Draft this chapter right after Chapter 2’s theory is stable, since your metrics (Section 3.x) must be theoretically justified: cyclomatic complexity is valid because of the theory in Chapter 2, Section 2.2.5. Revisit the timeline weekly throughout the semester; treat it as an actual project-tracking tool, not a one-time document.

Where does it fit?

The outputs of this chapter are used everywhere downstream. Section 3.4 (development method) shapes how Chapter 4 and Chapter 5 are organized. Section 3.x (metrics) defines exactly what Chapter 6 must report. Section 3.7 (testing approach) defines the Blackbox/UAT scenarios detailed in Chapter 4, Section 4.4, and executed in Chapter 5, Section 5.5.

How do you create one?

1. Draw the Research Flow as a single diagram covering every phase.
2. State the location and time (often just “Laboratorium SE, Polinema, semester genap 2026”).
3. Name your data-collection methods: literature study, tool documentation, direct measurement.
4. Choose and justify a development methodology.
5. Define every metric with an exact formula and tool; no metric without a measurement procedure.
6. Describe your testing approach at a methodological level (details belong in Chapter 4).

2. Mengapa Menulis Metodologi dengan Benar Itu Penting?

Apa itu?

Metodologi adalah kontrak operasional untuk proyek Anda: proses yang terdefinisi, linimasa yang terdefinisi, dan instrumen yang terdefinisi, yaitu disiplin yang sama yang diterapkan tim software sebelum sprint dimulai.

Mengapa penting?

• Ini adalah faktor terpenting untuk selesai tepat waktu. Metodologi yang diberi nama, lengkap dengan fase dan linimasa, mengubah “bangun aplikasi Todo” menjadi daftar periksa yang benar-benar bisa Anda lacak minggu demi minggu.
• Membuat perbandingan Anda dapat dipertahankan. Tanpa metrik yang terdefinisi secara presisi (“cyclomatic complexity, diukur dengan PHPMD, dirata-ratakan per method”), peninjau tidak dapat menilai apakah angka BAB VI Anda berarti sesuatu.
• Digunakan kembali sebagai instrumen Anda, bukan hanya dideskripsikan. Apa pun yang Anda definisikan di sini (tool, formula) harus benar-benar Anda jalankan di BAB V dan laporkan di BAB VI. Definisi yang kabur di sini menjadi pengukuran yang mustahil nanti.

Kapan digunakan?

Susun segera setelah teori BAB II stabil, karena metrik Anda (3.x) harus dijustifikasi secara teoretis (cyclomatic complexity valid karena teori di BAB II Bagian 2.2.5). Tinjau ulang linimasa mingguan sepanjang semester sebagai alat pelacakan yang sesungguhnya bagi proyek Anda, bukan dokumen sekali jadi.

Di mana tempatnya?

Keluaran Metodologi digunakan di berbagai bagian selanjutnya: 3.4 (metode pengembangan) membentuk bagaimana BAB IV/V diorganisasikan; 3.x (metrik) mendefinisikan persis apa yang harus dilaporkan BAB VI; 3.7 (pendekatan pengujian) mendefinisikan skenario Blackbox/UAT yang dirinci di BAB IV Bagian 4.4 dan dijalankan di BAB V Bagian 5.5.

Bagaimana membuatnya?

1. Gambar Alur Penelitian sebagai satu diagram yang mencakup setiap fase.
2. Nyatakan lokasi/waktu (seringnya cukup “Laboratorium SE, Polinema, semester genap 2026”).
3. Sebutkan metode pengumpulan data Anda (studi literatur, dokumentasi tool, pengukuran langsung).
4. Pilih dan justifikasi metode pengembangan.
5. Definisikan setiap metrik dengan formula/tool yang persis: tidak ada metrik tanpa prosedur pengukuran.
6. Deskripsikan pendekatan pengujian Anda pada level metodologis (detail masuk ke BAB IV).

3. Continuing Our Example: Research Flow and Timeline

3.1 Research Flow (Alur Penelitian)

3.2 Location and Time of Research

State this plainly, for example: “Penelitian dilakukan secara mandiri menggunakan environment pengembangan lokal, selama semester genap 2026, dari minggu ke-1 hingga minggu ke-16.”

Suggested Timeline (16-week semester)

Time-boxing tip: If week 9 arrives and Perancangan is not finished, treat that as your earliest and cheapest signal to revisit Scope and Limitations (Part 1). Cut scope now, not in week 14.

3. Melanjutkan Contoh Berkelanjutan Ini: Alur Penelitian dan Linimasa

3.1 Alur Penelitian

3.2 Lokasi dan Waktu Penelitian

Nyatakan ini secara langsung: mis. “Penelitian dilakukan secara mandiri menggunakan lingkungan pengembangan lokal, selama semester genap 2026, dari minggu ke-1 hingga minggu ke-16.”

Linimasa yang Disarankan (semester 16 minggu)

Tips time-boxing: jika minggu ke-9 tiba dan Perancangan belum selesai, itu adalah sinyal termurah dan paling awal untuk meninjau ulang Batasan Masalah (Bagian 1): potong ruang lingkup sekarang, bukan di minggu ke-14.

4. Writing Chapter 3 Section by Section

3.3 Data Collection Method (Metode Pengumpulan Data)

Name your actual sources: the literature study (sources from Chapter 2), official framework documentation (Laravel docs), and, specific to a measurement-based project, direct instrumentation: running static-analysis tools against your own code.

3.4 System Development Method (Metode Pengembangan Sistem)

We use Prototyping, a natural fit for a solo, time-boxed mini thesis (mini-skripsi) built around a single analyze-design-build-evaluate loop. Prototyping’s phases, adapted for a solo student, are:

1. Requirements Gathering & Analysis: output from Chapter 1 and Chapter 2 feeds directly into this phase, alongside Chapter 4’s Analisis Kebutuhan.
2. Quick Design: in Chapter 4, produce UML diagrams, a DB schema, and UI wireframes, just enough design to start building. Refine this iteratively with your advisor acting as the “user” stakeholder.
3. Build Prototype: in Chapter 5, build the Action Pattern implementation and test continuously rather than in one block at the end.
4. Evaluation: in Chapter 6, run Blackbox/UAT testing plus metric measurement against literature thresholds. If evaluation reveals issues, Prototyping lets you refine the design and rebuild, an honest fit for a scoped mini thesis, unlike a rigid waterfall approach.
5. Finalize & Document: final integration, conclusions in Chapter 6, and the write-up in Chapter 7.

Because Prototyping iterates, expect to build more than one version of your prototype as evaluation surfaces gaps. Document each iteration with a compact Iteration Log in Chapter 5 (Section 5.4) rather than a full diagram-and-code narrative per version; Part 5 shows exactly what that log looks like.

Justify your own choice: Waterfall, Scrum/Agile, and RAD are equally valid if you can argue why they fit your project’s constraints (team size, timeline, requirement volatility) better than Prototyping does.

3.5 Defining Metrics (Research Instrument)

This is the section most projects under-specify. Each metric needs a name, a formula/tool, and a unit: nothing vague like “we will measure code quality.”

3.7 Testing (Pengujian)

At a methodological level, state that the implementation will be validated with Black Box Testing (functional correctness) and User Acceptance Testing (whether the end result meets user expectations). The detailed scenario tables belong in Chapter 4, Section 4.4; this section only states the approach and acceptance criteria, for example: “seluruh skenario Blackbox harus lulus; indeks penerimaan UAT ≥ 80%“.

4. Menulis BAB III Subbab demi Subbab

3.3 Metode Pengumpulan Data (Data Collection Method)

Sebutkan sumber Anda yang sebenarnya: studi literatur (sumber BAB II), dokumentasi resmi framework (dokumentasi Laravel), dan (spesifik untuk proyek berbasis pengukuran) instrumentasi langsung: menjalankan tool static-analysis terhadap kode Anda sendiri.

3.4 Metode Pengembangan Sistem (System Development Method)

Penelitian ini menggunakan Prototyping, cocok secara alami untuk mini-skripsi solo yang time-boxed, dibangun di sekitar satu putaran analisis-desain-pembangunan-evaluasi. Fase Prototyping, disesuaikan untuk mahasiswa solo:

1. Requirements Gathering & Analysis: output BAB I/II langsung masuk ke sini, bersama Analisis Kebutuhan BAB IV.
2. Quick Design: BAB IV: diagram UML, skema DB, wireframe UI, cukup untuk mulai membangun, disempurnakan secara iteratif dengan pembimbing Anda berperan sebagai pemangku kepentingan “pengguna”.
3. Build Prototype: BAB V: bangun implementasi Action Pattern, uji secara berkelanjutan, bukan dalam satu blok di akhir.
4. Evaluation: BAB VI: pengujian Blackbox/UAT ditambah pengukuran metrik terhadap ambang batas literatur. Jika evaluasi mengungkap masalah, Prototyping memungkinkan penyempurnaan desain dan pembangunan ulang, sangat cocok untuk mini-skripsi berskala kecil, tidak seperti waterfall yang kaku.
5. Finalise & Document: integrasi akhir, kesimpulan BAB VI, dan BAB VII.

Karena Prototyping bersifat iteratif, Anda perlu bersiap membangun lebih dari satu versi prototipe seiring evaluasi mengungkap kesenjangan. Dokumentasikan ini dengan Log Iterasi ringkas di BAB V (Bagian 5.4), bukan narasi diagram-dan-kode lengkap per versi; Bagian 5 menunjukkan persis seperti apa bentuknya.

Justifikasi pilihan Anda sendiri. Waterfall, Scrum/Agile, dan RAD sama validnya jika Anda berargumen mengapa metode itu lebih cocok dengan kendala proyek Anda (ukuran tim, linimasa, volatilitas kebutuhan).

3.5 Mendefinisikan Metrik (Instrumen Penelitian)

Ini adalah bagian yang paling sering kurang spesifik di kebanyakan proyek. Setiap metrik membutuhkan nama, formula/tool, dan satuan: bukan hal kabur seperti “kami akan mengukur kualitas kode”.

3.7 Pengujian

Nyatakan, pada level metodologis: implementasi akan divalidasi dengan Black Box Testing (kebenaran fungsional) dan User Acceptance Testing (apakah hasil akhir memenuhi ekspektasi pengguna). Tabel skenario detail masuk ke BAB IV Bagian 4.4: bagian ini hanya menyatakan pendekatan dan kriteria penerimaan (mis., “seluruh skenario Blackbox harus lulus; indeks penerimaan UAT ≥ 80%“).

5. Self-Check: Is Your Development Methodology Ready?

1. Does the Research Flow diagram include every phase you will actually go through, with no hidden steps?
2. Does every metric have a name, a formula or tool, and a unit? If you can’t say “measured how,” it isn’t defined yet.
3. Is your chosen SDLC model justified, not just named, for your project’s constraints?
4. Does your timeline account for review and revision cycles with your advisor, not just “build” time?
5. Would a classmate be able to reproduce your measurement procedure exactly from this chapter alone?

5. Periksa Sendiri: Apakah Metodologi Anda Siap?

1. Apakah diagram Alur Penelitian mencakup setiap fase yang benar-benar akan Anda lalui, tanpa langkah tersembunyi?
2. Apakah setiap metrik punya nama, formula atau tool, dan satuan? Jika Anda tidak bisa menyebut “diukur bagaimana”, berarti belum terdefinisi.
3. Apakah model SDLC yang Anda pilih dijustifikasi (bukan hanya disebutkan) untuk kendala proyek Anda?
4. Apakah linimasa Anda memperhitungkan siklus tinjauan/revisi dengan pembimbing, bukan hanya waktu “membangun”?
5. Bisakah teman sekelas mereproduksi prosedur pengukuran Anda persis hanya dari bab ini?

6. Common Mistakes in Chapter 3

6. Kesalahan Umum dalam BAB III

7. What Comes Next?

With a defined process, timeline, and, crucially, precisely defined metrics, we can now design the system itself. Part 4 covers Chapter 4: System Analysis and Design (BAB IV: Analisis dan Perancangan Sistem): requirements analysis and the full UML design (Use Case, Activity, Class, and Sequence diagrams) for our Action Pattern implementation, with Fat Controller kept as an explicitly labeled conceptual contrast. It cross-links to the UML Mini Series.

7. Apa yang Akan Datang Selanjutnya?

Dengan proses, linimasa, dan, yang krusial, metrik yang terdefinisi secara presisi, sistem itu sendiri siap dirancang. Bagian 4 membahas BAB IV (Analisis dan Perancangan Sistem): analisis kebutuhan, dan desain UML lengkap (diagram Use Case, Activity, Class, Sequence) untuk implementasi Action Pattern dalam penelitian ini, dengan Fat Controller dijaga sebagai kontras konseptual yang diberi label jelas, dengan tautan ke Seri Mini UML.