Friday, May 27, 2022
Saturday, May 09, 2015
Pertemuan 2
Model-Model Proses Perangkat Lunak
1. Model Linier/Berurutan diantaranya yaitu Water Fall Model;
WaterFall Model Referensi Pressman
WaterFall Model Referensi Sommerville
Penjelasan:
1. Requirements analysis & Definition.
Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.
2. System & Software Design.
Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.
3. Implementation & Unit Testing.
Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit per unit.
4. Integration & System Testing.
Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).
5. Operation & Maintenance.
Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.
Masalah pada Waterfall Model
1. Perubahan sulit dilakukan karena sifatnya yang kaku.
2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan dibeberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.
1. Model Linier/Berurutan diantaranya yaitu Water Fall Model;
WaterFall Model Referensi Pressman
WaterFall Model Referensi SommervillePenjelasan:
1. Requirements analysis & Definition.
Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.
2. System & Software Design.
Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.
3. Implementation & Unit Testing.
Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit per unit.
4. Integration & System Testing.
Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).
5. Operation & Maintenance.
Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.
Masalah pada Waterfall Model
1. Perubahan sulit dilakukan karena sifatnya yang kaku.
2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan dibeberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.
Pertemuan 3
Evolutionary Software Process Models
Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses. Dua model dalam evolutionary software process model adalah:
1. Incremental Model (Original: Mills)
Cirinya;
1. Mengkombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan.
2. Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
3. produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
4. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
5. Mampu mengakomodasi perubahan secara fleksibel.
6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.
Masalah pada Incremental model:
1. Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
2. Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna kedalam rencana spesifikasi masing-masing hasil increment
2. Spiral Model (Original: Boehm)
Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :
1. Objective settings (menentukan tujuan):
Menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
2. Risk assessment and reduction (Penanganan dan pengurangan resiko):
Setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
3. Development and Validation (Pembangunan dan pengujian):
Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.
4. Planning:
Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.
Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:
1. Customer communication:
Membangun komunikasi yang baik dengan pengguna/customer.
2. Planning:
Mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek
3. Risk analysis:
Identifikasi resiko managemen dan teknis
4. Engineering:
Pembangunan contoh-contoh aplikasi, misalnya prototype
5. Construction and release :
Pembangunan, test, install dan support.
6. Customer evaluation:
Mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.
Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses. Dua model dalam evolutionary software process model adalah:
1. Incremental Model (Original: Mills)
Cirinya;
1. Mengkombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan.
2. Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
3. produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
4. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
5. Mampu mengakomodasi perubahan secara fleksibel.
6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.
Masalah pada Incremental model:
1. Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
2. Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna kedalam rencana spesifikasi masing-masing hasil increment
2. Spiral Model (Original: Boehm)
Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :
1. Objective settings (menentukan tujuan):
Menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
2. Risk assessment and reduction (Penanganan dan pengurangan resiko):
Setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
3. Development and Validation (Pembangunan dan pengujian):
Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.
4. Planning:
Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.
Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:
1. Customer communication:
Membangun komunikasi yang baik dengan pengguna/customer.
2. Planning:
Mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek
3. Risk analysis:
Identifikasi resiko managemen dan teknis
4. Engineering:
Pembangunan contoh-contoh aplikasi, misalnya prototype
5. Construction and release :
Pembangunan, test, install dan support.
6. Customer evaluation:
Mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.
Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
PEMBAGIAN KELOMPOK MATAKULIAH RPL
| Kelompok |
NIM
|
NO
|
Kelompok
|
NIM
|
NO
|
| RPL-A1 |
200353018
|
1
|
RPL-B4
|
200453033
|
1
|
200453005
|
2
|
200453034
|
2
| ||
200453007
|
3
|
200453035
|
3
| ||
200453009
|
4
|
200453036
|
4
| ||
200453013
|
5
|
200453039
|
5
| ||
| RPL-A2 |
200453020
|
1
|
RPL-B5
|
200453040
|
1
|
200453024
|
2
|
200453043
|
2
| ||
200453025
|
3
|
200453044
|
3
| ||
200453028
|
4
|
200453047
|
4
| ||
200453041
|
5
|
200453048
|
5
| ||
| RPL-A3 |
200453046
|
1
|
RPL-B6
|
200453051
|
1
|
200453050
|
2
|
200453052
|
2
| ||
200453069
|
3
|
200453053
|
3
| ||
200453072
|
4
|
200453059
|
4
| ||
200653184
|
5
|
200453062
|
5
| ||
| RPL-B1 |
200353019
|
1
|
RPL-B7
|
200453065
|
1
|
200353023
|
2
|
200453066
|
2
| ||
200453002
|
3
|
200453067
|
3
| ||
200453004
|
4
|
200453071
|
4
| ||
200453006
|
5
|
200453073
|
5
| ||
| RPL-B2 |
200453008
|
1
|
RPL-B8
|
200453074
|
1
|
200453010
|
2
|
200453075
|
2
| ||
200453012
|
3
|
200453076
|
3
| ||
200453015
|
4
|
200453077
|
4
| ||
200453017
|
5
| ||||
| RPL-B3 |
200453021
|
1
| |||
200453027
|
2
| ||||
200453029
|
3
| ||||
200453031
|
4
| ||||
200453032
|
5
| ||||
Pertemuan 1
Pentingnya Rekayasa Perangkat Lunak (RPL) dan Perangkat Lunak (PL)
Berbagai instansi pemerintah maupun swasta, baik dalam maupun luar negeri menggunakan perangkat lunak (software) sebagai kebutuhan esensial. PL digunakan dari berbagai tingkatan manajemen. Terdapat tingkatan manajemen tertentu yang bertugas untuk mengembangkan atau bahkan membuat perangkat lunak (software engineering). Bahkan saat ini banyak instansi/perusahaan tersebut yang dengan sengaja menciptakan departemen/bagian yang mengurusi perangkat lunak atau rekayasa perangkat lunak.
Berikut ini adalah pentingnya RPL dan PL;
o Semua negara maju ekonominya bergantung pada perangkat lunak.
o Makin banyak sistem yang dikendalikan oleh PL
o RPL berkaitan dengan teori, metode dan alat untuk pembangunan PL secara rofesional.
o Pengeluaran dana untuk PL di negara maju sangat besar.
o Harga PL sering lebih mendominasi harga sistem komputer. Harga PL pada PC sering lebih mahal dari pada harga perangkat kerasnya.
o Biaya pemeliharaan PL lebih mahal dibanding biaya pembuatannya.
o RPL berkaitan dengan biaya efektif pembuatan PL.
Dari poin-poin di atas, peninjauan pengadaan PL dan pengembangan PL ternyata menimbulkan komponen biaya yang tidak sedikit. Hal ini cukup beralasan, karena dengan PL yang dimilikinya pihak manajemen dapat membuat keputusan berdasarkan data yang disediakan oleh PL dengan akurat, cepat, efisien dan dapat menyesuaikan kondisi saat ini (relevan).
Definisi RPL dan PL
Apakah PL
Dalam organ tubuh manusia terdapat perangkat lunak dan perangkat keras. Biasanya perangkat lunak pada tubuh manusia dilindungi dengan jaringan perangkat kerasnya. Contoh otak sebagai perangkat lunak dan dilindungi oleh tulang tengkorak. Hal ini berbeda sama sekali dengan asumsi bahwa perangkat lunak komputer itu berupa alat yang lunak seperti pada organ tubuh manusia. Mungkin agar mendekati kesamaan asumsi perangkat lunak komputer, perangkat lunak manusia mungkin bukan berupa alat/organ atau jaringan tubuh yang sifatnya lunak melainkan sinyal sensorik dan motorik yang menggerakkan atau memberikan perintah pada organ melalui jaringan syaraf yang saliang berkoordinasi dan berhubungan dengan baik. Berikut rangkuman hal-hal yang berkaitan dengan apa yang disebut dengan perangkat lunak komputer;
o Program komputer & dokumentasi yang berkaitan seperti dokumen kebutuhan,rancangan, dan user manual.
o Produk PL bisa dibangun untuk pengguna khusus atau umum.
Generic dibangun untuk dijual ke pengguna yang berbeda-beda misalnya PL untuk PC seperti Excel atau Word.
Bespoke (custom) untuk pengguna khusus/pemesan sesuai kebutuhannya.
o PL baru bisa dibuat dengan membangun program baru, konfigurasi sistem PL atau gunakan lagi (reuse) program yang sudah ada.
Apakah RPL
Perangkat lunak merupakan program komputer yang mengkoordinasikan (mengenalkan, memiliki fungsi pengaturan dan pengontrolan) unjuk kerja perangkat keras dan dokumentasi yang berkaitan seperti dokumen kebutuhan, rancangan dan petunjuk pemakaiannya. Sedangkan Rekayasa Perangkat Lunak adalah disiplin ilmu rekayasa atau teknik yang berkaitan dengan semua aspek dalam membuat perangkat lunak yang mengharuskan mengikuti pendekatan yang sistematis dan teratur dan menggunakan alat dan teknik yang cocok sesuai dengan masalah yang akan dipecahkan, batasan pembangunan dan sesumber yang tersedia.
Beda RPL Dengan Istilah-Istilah lain
Beda RPL dan Ilmu Komputer
o Ilmu komputer berkaitan dengan teori dan konsep-konsep dasar; RPL berkaitan dengan praktek pembangunan PL.
o Teori ilmu komputer masih kurang sebagai penyangga RPL.
Beda RPL dan Rekayasa Sistem
o Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.
o Para ahli sistem (system engineers) terlibat dalam spesifikasi sistem, desain arsitektural, integrasi dan peluncurannya.
Proses PL (Software Process)
o Serangkaian aktifitas yang tujuannya adalah pembangunan atau evolusi PL
o Aktifitas umum dalam semua proses PL:
Spesifikasi apa yang dilakukan sistem dan batasan pembangunan.
Pembangunan produksi dari sistem PL.
Validasi pemeriksaan apakah PL sesuai dengan permintaan pemesan.
Evolusi mengubah PL untuk menyesuaikan perubahan permintaan.
Model Proses PL (software process model)
Gambaran sederhana dari proses PL, berdasarkan pandangan tertentu, seperti misalnya:
o Workflow aktivitas yang berurutan;
o Data-flow arus informasi;
o Role/action siapa melakukan apa.
o Model process, contohnya:
Waterfall;
Iterative development;
Component-based software engineering; dll.
Berbagai instansi pemerintah maupun swasta, baik dalam maupun luar negeri menggunakan perangkat lunak (software) sebagai kebutuhan esensial. PL digunakan dari berbagai tingkatan manajemen. Terdapat tingkatan manajemen tertentu yang bertugas untuk mengembangkan atau bahkan membuat perangkat lunak (software engineering). Bahkan saat ini banyak instansi/perusahaan tersebut yang dengan sengaja menciptakan departemen/bagian yang mengurusi perangkat lunak atau rekayasa perangkat lunak.
Berikut ini adalah pentingnya RPL dan PL;
o Semua negara maju ekonominya bergantung pada perangkat lunak.
o Makin banyak sistem yang dikendalikan oleh PL
o RPL berkaitan dengan teori, metode dan alat untuk pembangunan PL secara rofesional.
o Pengeluaran dana untuk PL di negara maju sangat besar.
o Harga PL sering lebih mendominasi harga sistem komputer. Harga PL pada PC sering lebih mahal dari pada harga perangkat kerasnya.
o Biaya pemeliharaan PL lebih mahal dibanding biaya pembuatannya.
o RPL berkaitan dengan biaya efektif pembuatan PL.
Dari poin-poin di atas, peninjauan pengadaan PL dan pengembangan PL ternyata menimbulkan komponen biaya yang tidak sedikit. Hal ini cukup beralasan, karena dengan PL yang dimilikinya pihak manajemen dapat membuat keputusan berdasarkan data yang disediakan oleh PL dengan akurat, cepat, efisien dan dapat menyesuaikan kondisi saat ini (relevan).
Definisi RPL dan PL
Apakah PL
Dalam organ tubuh manusia terdapat perangkat lunak dan perangkat keras. Biasanya perangkat lunak pada tubuh manusia dilindungi dengan jaringan perangkat kerasnya. Contoh otak sebagai perangkat lunak dan dilindungi oleh tulang tengkorak. Hal ini berbeda sama sekali dengan asumsi bahwa perangkat lunak komputer itu berupa alat yang lunak seperti pada organ tubuh manusia. Mungkin agar mendekati kesamaan asumsi perangkat lunak komputer, perangkat lunak manusia mungkin bukan berupa alat/organ atau jaringan tubuh yang sifatnya lunak melainkan sinyal sensorik dan motorik yang menggerakkan atau memberikan perintah pada organ melalui jaringan syaraf yang saliang berkoordinasi dan berhubungan dengan baik. Berikut rangkuman hal-hal yang berkaitan dengan apa yang disebut dengan perangkat lunak komputer;
o Program komputer & dokumentasi yang berkaitan seperti dokumen kebutuhan,rancangan, dan user manual.
o Produk PL bisa dibangun untuk pengguna khusus atau umum.
Generic dibangun untuk dijual ke pengguna yang berbeda-beda misalnya PL untuk PC seperti Excel atau Word.
Bespoke (custom) untuk pengguna khusus/pemesan sesuai kebutuhannya.
o PL baru bisa dibuat dengan membangun program baru, konfigurasi sistem PL atau gunakan lagi (reuse) program yang sudah ada.
Apakah RPL
Perangkat lunak merupakan program komputer yang mengkoordinasikan (mengenalkan, memiliki fungsi pengaturan dan pengontrolan) unjuk kerja perangkat keras dan dokumentasi yang berkaitan seperti dokumen kebutuhan, rancangan dan petunjuk pemakaiannya. Sedangkan Rekayasa Perangkat Lunak adalah disiplin ilmu rekayasa atau teknik yang berkaitan dengan semua aspek dalam membuat perangkat lunak yang mengharuskan mengikuti pendekatan yang sistematis dan teratur dan menggunakan alat dan teknik yang cocok sesuai dengan masalah yang akan dipecahkan, batasan pembangunan dan sesumber yang tersedia.
Beda RPL Dengan Istilah-Istilah lain
Beda RPL dan Ilmu Komputer
o Ilmu komputer berkaitan dengan teori dan konsep-konsep dasar; RPL berkaitan dengan praktek pembangunan PL.
o Teori ilmu komputer masih kurang sebagai penyangga RPL.
Beda RPL dan Rekayasa Sistem
o Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.
o Para ahli sistem (system engineers) terlibat dalam spesifikasi sistem, desain arsitektural, integrasi dan peluncurannya.
Proses PL (Software Process)
o Serangkaian aktifitas yang tujuannya adalah pembangunan atau evolusi PL
o Aktifitas umum dalam semua proses PL:
Spesifikasi apa yang dilakukan sistem dan batasan pembangunan.
Pembangunan produksi dari sistem PL.
Validasi pemeriksaan apakah PL sesuai dengan permintaan pemesan.
Evolusi mengubah PL untuk menyesuaikan perubahan permintaan.
Model Proses PL (software process model)
Gambaran sederhana dari proses PL, berdasarkan pandangan tertentu, seperti misalnya:
o Workflow aktivitas yang berurutan;
o Data-flow arus informasi;
o Role/action siapa melakukan apa.
o Model process, contohnya:
Waterfall;
Iterative development;
Component-based software engineering; dll.
Friday, September 21, 2007
Pembagian Mingguan
Pelaksanaan | Topik Kuliah | Bahan |
Pertemuan 1 | Penyampaian Silabus Informasi Tentang RPL | Pengantar PR Individu |
Pertemuan 2 | Model Proses:
| |
Pertemuan 3 | Model Proses:
| |
Pertemuan 4 | Managing Software Project
Project Scheduling | Managing |
Pertemuan 5 | SQA | |
Pertemuan 6 | Requirement | |
Pertemuan 7 | Pembahasan Tugas Pra UTS | Model Proses Requirement |
Pertemuan 8 | Design Concept | |
Pertemuan 9 | User Interface Design | |
Pertemuan 10 | Software Testing Techniques and Strategis | |
Pertemuan 11 | C/S Software Engineering | |
Pertemuan 12 | Web Engineering | |
Pertemuan 13 | Projects Hall of Fame | Presentasi Program |
Pertemuan 14 | Pembahasan Tugas Pra UAS |
Subscribe to:
Posts (Atom)