Perangkat Lunak – Software

Sebuah program komputer yang berisi sekumpulan instruksi yang dibuat dengan menggunakan bahasa khusus yang memberi perintah pada komputer untuk melakukan berbagai pengoperasian atau pemrosesan terhadap data yang terdapat dalam program tersebut atau data yang dimasukkan oleh pengguna komputer. Dapat disimpulkan bahwa software merupakan ‘jiwa’ sedangkan hardware berfungsi sebagai ‘tubuh’ dalam sebuah komputer kalian.

Software merupakan peralatan logis atau perangkat lunak dari sebuah sistem komputer , yang terdiri dari semua komponen logika yang diperlukan untuk memungkinkan untuk melakukan tugas-tugas tertentu, yang bertentangan dengan komponen fisik, yang disebut hardware.

Komponen logis termasuk, di antara banyak lainnya, aplikasi komputer , seperti pengolah kata , yang memungkinkan pengguna untuk melakukan semua tugas yang menyangkut mengedit teks, perangkat lunak sistem , seperti sistem operasi , yang pada dasarnya memungkinkan seluruh fungsi program yang benar, juga memfasilitasi interaksi antara komponen hardware dan aplikasi lainnya, dan menyediakan antarmuka dengan pengguna.

Klasifikasi Software

Software Klasifikasi

Berikutini adalah 3 klasifikasi utama software:

Sistem Software : Ini bertujuan untuk benar decouple pengguna dan programmer dari detail dari sistem komputer tertentu yang digunakan, terutama mengisolasi pengolahan mengacu pada karakteristik internal: memori, disk, port dan perangkat komunikasi, printer, layar , keyboard, dll Sistem perangkat lunak akan mencoba untuk pengguna yang tepat dan pengembang tingkat tinggi interface , driver , alat-alat dan utilitas yang memungkinkan dukungan pemeliharaan sistem global.

Termasuk antara lain:

Sistem Operasi
Perangkat Drivers
Diagnostik Alat
Koreksi dan Optimasi Alat
Server
Keperluan

Pemrograman perangkat lunak : Alat yang memungkinkan programmer untuk mengembangkan perangkat lunak menggunakan alternatif yang berbeda dan bahasa pemrograman , dengan cara yang praktis. Pada dasarnya meliputi:

Teks editor
Compiler
Interpreters
Linker
Debugger

Integrated Development Environment ( IDE ): Mereka kelompok alat di atas, biasanya di lingkungan visual, sehingga pemrogram tidak perlu memasukkan beberapa perintah untuk mengumpulkan, menerjemahkan, debugging , dll. Biasanya memiliki canggih antarmuka pengguna grafis ( GUI ).

Aplikasi perangkat lunak : Salah satu yang memungkinkan pengguna untuk melakukan tugas tertentu atau tugas dalam setiap bidang kegiatan yang bisa otomatis atau dibantu, dengan penekanan khusus pada bisnis. Termasuk di antara banyak lainnya:

Aplikasi untuk sistem kontrol dan otomasi industri
Aplikasi Kantor
Perangkat Lunak Pendidikan
Bisnis Software
Database
Telekomunikasi (yaitu internet dan semua struktur logis)
Video
Medis Software
Software untuk perhitungan numerik dan simbolik.
Software -aided design (CAD)
CNC Software ( CAM )

Sistem Penciptaan Software

Ditetapkan sebagai proses set memerintahkan langkah-langkah untuk mencapai solusi dari masalah atau mendapatkan produk, dalam kasus ini, untuk produk perangkat lunak yang memecahkan masalah tertentu.

Proses pengembangan perangkat lunak bisa sangat kompleks, tergantung pada ukuran mereka, dan kekritisan dari karakteristik yang sama. Misalnya penciptaan sistem operasi adalah tugas yang memerlukan manajemen proyek, sumber daya banyak dan tim kerja disiplin. Pada ekstrem yang lain, jika itu adalah program sederhana (misalnya, resolusi persamaan urutan kedua), dapat dilakukan oleh pengontrol tunggal (termasuk amatir) dengan mudah. Jadi biasanya jatuh ke dalam tiga kategori sesuai dengan ukuran mereka ( baris kode ) atau biaya: dari ‘kecil’ , ‘medium’ dan ‘ukuran besar’ . Ada beberapa metodologi untuk memperkirakan itu , salah satu yang paling populer adalah sistem COCOMO menyediakan metode dan perangkat lunak (program) yang menghitung dan memberikan perkiraan semua biaya produksi dalam “proyek software” (hubungan manusia / jam, biaya moneter , jumlah baris sumber yang digunakan sesuai dengan bahasa, dll).

Mengingat ukuran besar, maka perlu untuk melakukan tugas-tugas yang kompleks, baik teknis maupun manajerial, manajemen yang kuat dan berbagai analisis (antara lain), kompleksitas ini telah menyebabkan untuk mengembangkan studi teknik tertentu dan mencoba untuk: adalah dikenal sebagai Rekayasa Perangkat Lunak .

Sementara di mid-size, tim kecil (bahkan berpengalaman analis pemrogram saja) dapat melakukan pekerjaan. Meskipun selalu dalam kasus menengah dan besar (dan kadang-kadang juga di beberapa berukuran kecil, sesuai dengan kompleksitas mereka), maka harus mengikuti langkah-langkah tertentu yang diperlukan untuk membangun perangkat lunak. Langkah-langkah tersebut, meskipun mereka harus ada, fleksibel dalam penerapannya, sesuai dengan metodologi atau proses pembangunan yang dipilih dan digunakan oleh tim pengembangan atau tunggal analis programmer (jika ada).

Proses pengembangan perangkat lunak ‘telah menetapkan aturan, dan harus diterapkan dalam menciptakan media perangkat lunak dan besar, karena kalau itu lebih mungkin bahwa proyek gagal untuk menyimpulkan atau mengakhiri tanpa memenuhi set tujuan, berbagai kegagalan dan tidak dapat diterima (gagal, singkatnya). Diantara seperti “proses” ada tangkas atau ringan (misalnya XP ), berat dan lambat (misalnya RUP ), dan varian menengah. Biasanya diterapkan sesuai dengan jenis dan tonase dari perangkat lunak yang dikembangkan, pada kebijaksanaan pemimpin (jika ada) dari tim pengembangan. Beberapa dari proses ini Extreme Programming (Bahasa Pemrograman eXtreme atau XP), Rational Unified Process (English Rational Unified Process RUP atau), Pengembangan Fitur Driven ( FDD ), dll

Apapun “proses” digunakan dan diterapkan untuk pengembangan perangkat lunak (RUP, FDD, XP, dll), dan hampir independen dari dirinya, selalu menerapkan “model siklus hidup”.

Perkiraan total proyek software besar yang dilakukan, 28% gagal, jatuh 46% menjadi modifikasi parah yang delay dan 26% yang benar-benar sukses.

Ketika sebuah proyek gagal, itu adalah jarang karena kegagalan teknis, penyebab utama dari kesalahan dan kegagalan adalah kurangnya penerapan metodologi pengembangan suara atau proses. Antara lain, kecenderungan yang kuat, dalam beberapa dekade, adalah untuk meningkatkan metodologi pengembangan atau proses, atau menciptakan kesadaran baru di kalangan profesional informasi mengenai penggunaan yang tepat. Biasanya para spesialis dalam penelitian dan pengembangan daerah-daerah (metodologi) dan sekutu (seperti model dan bahkan manajemen proyek yang sama) adalah insinyur perangkat lunak, adalah orientasi. Spesialis dalam area lain dari pengembangan perangkat lunak (analis, programmer, BA dalam ilmu komputer, insinyur komputer, sistem insinyur, dll.) Biasanya menerapkan keahlian mereka tetapi menggunakan model, paradigma dan proses yang sudah dikembangkan.

Adalah umum bagi tim pengembangan perangkat lunak untuk manusia berukuran menengah yang terlibat menerapkan ‘metodologi’, biasanya hibrida dari proses di atas dan kadang-kadang dengan kriteria mereka sendiri.
Proses pembangunan dapat melibatkan banyak tugas dan bervariasi 6 , dari staf kantor, ke atas teknis dan manajemen dan manajemen. Tapi, hampir parah, selalu bertemu tertentu langkah minimum , yang dapat diringkas sebagai berikut:
Tangkap, elisitasi 8 , spesifikasi dan analisis kebutuhan (ERS)

Disain
Coding
Pengujian (unit dan integrasi)
Instalasi dan tahap produksi
Pemeliharaan

Dalam langkah di atas mungkin sedikit berbeda nama mereka, atau menjadi lebih global, atau sebaliknya, menjadi lebih halus, seperti keadaan fase tunggal (dokumenter dan tujuan penafsiran) dari “analisis dan desain”, atau dinyatakan sebagai ‘implementasi’ apa yang dikatakan sebagai “coding” namun pada kenyataannya, ada dan mencakup semua pada dasarnya tugas yang sama.

Dalam ayat 4 Pasal ini akan memberikan rincian lebih lanjut dari setiap langkah-langkah yang ditunjukkan.
Model siklus hidup proses atau

Untuk setiap fase atau tahapan pada item yang tercantum di atas, ada sub-tahap (atau tugas). Model proses atau model siklus hidup yang digunakan untuk pembangunan, mendefinisikan urutan tugas atau kegiatan yang terlibat, 6 juga mendefinisikan koordinasi di antara mereka, dan link Anda dan umpan balik. Di antara yang paling dikenal dapat disebutkan: model air terjun atau berurutan, model spiral , inkremental berulang Model . Dari atas ada mengubah beberapa varian atau alternatif, lebih atau kurang diinginkan tergantung pada aplikasi yang diperlukan dan persyaratan nya. 7
Waterfall Model
Hal ini, meskipun lebih sering dikenal sebagai model air terjun juga disebut “model klasik”, “model tradisional” atau “model sekuensial linier.”

Model air terjun murni jarang digunakan karena , untuk ini akan berarti sebelum dan mutlak pengetahuan tentang persyaratan, volatilitas non-langkah yang sama (atau kekakuan) dan selanjutnya bebas dari kesalahan, mungkin berlaku untuk sistem hanya sedikit dan kecil untuk mengembangkan. Dalam keadaan ini, transisi dari satu tahap ke tahap yang lain di atas akan tidak kembali, misalnya bergerak dari desain untuk coding menyiratkan desain yang tepat, kesalahan atau modifikasi kemungkinan atau evolusi: “Saya merancang pengkodean tanpa kesalahan, akan ada sama sekali masa varian. ” Ini tidak realistis, karena secara intrinsik perangkat lunak berkembang alam 9 , berubah dan hampir tidak bebas dari kesalahan, baik selama pengembangan dan operasional selama hidup. 6

Setiap perubahan selama pelaksanaan salah satu dari langkah-langkah dalam model sekuensial akan restart dari awal seluruh seluruh siklus, yang akan mengakibatkan biaya tinggi dan waktu pengembangan. Gambar 2 menunjukkan tata letak kemungkinan model tersebut. 6

Namun, model air terjun di beberapa bentuknya adalah salah satu yang saat ini digunakan sebagian besar 10 , untuk efisiensi dan kesederhanaan, terutama dalam perangkat lunak kecil dan beberapa media berukuran, tetapi tidak pernah (atau sangat jarang) digunakan dalam “bentuk murni”, sebagaimana dinyatakan sebelumnya. Sebaliknya, selalu ada beberapa umpan balik antara tahap, yang tidak sepenuhnya dapat diprediksi atau kaku, hal ini memberikan kesempatan bagi pengembangan produk-produk perangkat lunak di mana terdapat ketidakpastian tertentu, perubahan atau perubahan selama siklus hidup. Misalnya, setelah ditangkap dan ditetapkan persyaratan (tahap pertama) dapat dikirimkan ke desain sistem, tetapi selama ini fase terakhir yang paling mungkin dilakukan penyesuaian terhadap persyaratan (meskipun minimal), baik oleh kegagalan terdeteksi, ambiguitas atau persyaratan sendiri yang telah berubah atau berkembang, sehingga harus kembali ke tahap pertama atau, membuat ulang relevan dan kemudian melanjutkan lagi dengan desain, yang kedua dikenal sebagai umpan balik. Biasanya di model air terjun ini maka penerapan tahap yang sama entah bagaimana makan kembali , sehingga bagian belakang dari sebelumnya (dan bahkan untuk melompat ke sebelumnya beberapa) jika diperlukan.

Apa ini, secara umum, bentuk dan penggunaan model ini, salah satu yang paling sering digunakan dan populer. 6 Umpan balik model air terjun sangat menarik, bahkan yang ideal, jika proyek memiliki kekakuan tinggi (sedikit perubahan, bukan evolusioner direncanakan) Persyaratan jelas dan benar ditentukan. 10

Ada lebih mirip dengan varian model: penyulingan tahap (tahap yang lebih, dan lebih spesifik rendah) layar atau langkah-langkah bahkan lebih sedikit daripada yang disebutkan, meskipun dalam kasus ini hilang berada dalam yang lain. Urutan fase ini ditunjukkan dalam item sebelumnya adalah, logis dan tepat tetapi perhatikan, seperti yang dinyatakan, yang biasanya akan kembali umpan balik.

Model kaskade linier atau paradigma tertua dan banyak digunakan, namun kritik dia (lihat kontra) telah mempertanyakan efektivitasnya. Namun demikian, ia memiliki tempat yang sangat penting dalam rekayasa perangkat lunak dan masih yang paling banyak digunakan, dan itu selalu lebih baik daripada pendekatan acak. 10
Kekurangan dari model air terjun: 6

Perubahan selama pengembangan dapat membingungkan tim profesional di tahap awal proyek. Jika perubahan terjadi pada tahapan matang (coding atau pengujian) dapat menjadi bencana besar untuk sebuah proyek besar.

Hal ini tidak sering bahwa pelanggan atau pengguna akhir persyaratan benar-benar jelas dan eksplisit (tahap awal) dan model linier membutuhkan. Ketidakpastian alam di awal kemudian sulit untuk mengakomodasi. 10

Pelanggan harus memiliki kesabaran karena perangkat lunak tidak akan tersedia sampai akhir proyek. Sebuah kesalahan terdeteksi oleh klien (tahap operasi) bisa menjadi bencana, yang melibatkan restart proyek, dengan biaya tinggi.
Evolusi Model

Perangkat lunak ini berkembang dari waktu ke waktu. November 9 kebutuhan pengguna dan produk sering berubah karena berkembang. Tanggal pasar dan persaingan dimungkinkan tidak menunggu untuk menempatkan produk di pasar cukup lengkap, sehingga disarankan untuk memperkenalkan versi fungsional terbatas dalam beberapa cara untuk mengurangi tekanan kompetitif.

Dalam situasi yang sama ini dan lainnya pengembang perlu model kemajuan yang dirancang untuk mengakomodasi evolusi sementara atau progresif, di mana kebutuhan daya yang diketahui sebelumnya, meskipun tidak didefinisikan dengan baik pada detail.

Dalam model air terjun dan air terjun umpan balik tidak diambil cukup memperhitungkan sifat berkembang dari perangkat lunak 11 , dipandang sebagai statis, dengan persyaratan dikenal dan ditetapkan dari awal. 6

Model evolusi yang berulang versi memungkinkan berkembang semakin kompleks dan lengkap, untuk mencapai tujuan yang diinginkan, berkembang lebih jauh, selama fase operasi.

Model ‘berulang tambahan “dan” spiral “(antara lain) adalah dua tingkat yang paling dikenal dan digunakan evolusi. 10
Iterative model incremental

Secara umum, seseorang dapat membedakan, pada Gambar 4, langkah-langkah umum yang mengikuti proses pengembangan produk perangkat lunak. Dalam model siklus hidup yang dipilih, langkah ini jelas diidentifikasi. Deskripsi dari sistem sangat penting untuk menentukan dan membuat penambahan yang berbeda sampai Anda mencapai produk, akhir keseluruhan. Kegiatan konkuren (spesifikasi, pengembangan dan validasi) merangkum perkembangan rinci meningkat, yang akan terjadi nanti.

Diagram pada Gambar 4 menunjukkan sangat skematis, operasi iteratif siklus tambahan, yang memungkinkan pengiriman demo seperti membangun produk akhir. 6 adalah, sebagaimana didefinisikan mencapai peningkatan masing-masing tahap operasi dan pemeliharaan. Setiap versi menggabungkan meningkat dikeluarkan sebelumnya fungsi dan persyaratan yang perlu dikaji sebagai.

Jenis incremental adalah model evolusi yang didasarkan pada beberapa siklus berulang kali diterapkan Cascade refed dengan filosofi iteratif. 10 Gambar 5 menunjukkan diagram penyulingan sebelumnya di bawah skema temporal, skema untuk akhirnya Model Incremental Iteratif siklus hidup, dengan kegiatan yang terkait generik. Berikut ini jelas terlihat bahwa setiap siklus cascade diterapkan untuk memperoleh peningkatan, yang terakhir diintegrasikan untuk memperoleh produk akhir lengkap. Peningkatan Setiap siklus umpan balik kaskade, meskipun, untuk kesederhanaan, Gambar 5 menunjukkan sebagai sekuensial murni.

Ada mengamati bahwa kegiatan pembangunan (untuk penambahan masing-masing) yang dilakukan secara paralel atau bersamaan, jadi misalnya, pada Gambar tersebut, saat melakukan desain kenaikan pertama rinci dan analisis yang dilakukan di kedua. 5 adalah skema saja, belum tentu kenaikan akan mulai selama fase desain di atas mungkin setelah (dan bahkan sebelum), setiap saat tahap sebelumnya. Setiap kegiatan peningkatan diakhiri dengan “operasi dan pemeliharaan” (dilambangkan sebagai “Operasi” dalam gambar), di mana ada pengiriman produk parsial kepada pelanggan. Waktu mulai selisih masing-masing tergantung pada beberapa faktor: jenis sistem, kemerdekaan atau ketergantungan antara increment (dua benar-benar independen dapat dengan mudah dimulai secara bersamaan jika personel yang cukup tersedia), kapasitas dan jumlah profesional yang terlibat dalam pembangunan, dll.

Dalam model ini, perangkat lunak disampaikan “oleh bagian-bagian fungsional yang lebih kecil”, tapi dapat digunakan kembali, peningkatan disebut. Umumnya kenaikan masing-masing dibangun di atas bahwa yang telah disampaikan. 6
Seperti ditunjukkan dalam Gambar 5, urutan Cascade diterapkan secara bergiliran, seiring waktu berjalan kalender. Setiap urutan linier menghasilkan peningkatan atau Cascade dan sering kenaikan pertama adalah sistem dasar, dengan fungsi tambahan banyak (dikenal atau tidak dikenal) tdk disampaikan.

Klien menggunakan sistem dasar awalnya, sementara itu, hasil dari penggunaan dan evaluasi dapat memberikan kontribusi pada rencana pembangunan / peningkatan berikut (atau versi). Juga berkontribusi terhadap rencana juga faktor-faktor lain, seperti prioritas (tingkat urgensi dalam kebutuhan untuk setiap kenaikan pada khususnya) dan meningkatkan ketergantungan (atau kemerdekaan).

Setelah integrasi masing-masing memberikan produk dengan fungsionalitas lebih banyak dari sebelumnya. Proses ini diulang sampai perangkat lunak akhir lengkap.

Menjadi iteratif, model incremental dengan produk parsial disampaikan beroperasi penuh tetapi masing-masing meningkat , dan bukan bagian yang digunakan untuk mengatur persyaratan (seolah-olah itu terjadi di Model prototyping .) 10
Pendekatan inkremental berguna ketika Anda memiliki staf yang rendah untuk pembangunan juga tidak tersedia jika batas waktu proyek sehingga versi lengkap dikirim ke pengguna tetapi menyediakan fungsionalitas dasar (dan tumbuh). Ini juga merupakan model yang berguna untuk versi evaluasi tujuan.

Catatan: Mungkin perhatian dan membantu setiap saat atau untuk sementara meningkatkan paradigma menggabungkan MCP suplemen dan karena itu memiliki campuran model dan skema meningkatkan pembangunan secara keseluruhan.
Contoh:

Sebuah pengolah kata yang dikembangkan di bawah paradigma Incremental bisa memberikan, pada prinsipnya, mengedit file dasar dan produksi dokumen (sesuatu seperti editor sederhana ). Dalam kenaikan kedua bisa ditambahkan editing yang lebih canggih dan generasi dan pencampuran dokumen . Dalam peningkatan ketiga dapat dianggap penambahan fungsi mantra , skema paging dan template , di keempat kemampuan menggambar sendiri dan persamaan matematika. Seterusnya sampai akhir prosesor yang diperlukan. Dengan demikian, produk tumbuh, mendekati tujuan akhir, tetapi pengiriman kenaikan pertama sejak itu berguna dan fungsional bagi pelanggan, yang menunjukkan respon yang cepat dalam hal pengiriman awal, tanpa mencatat bahwa deadline proyek tersebut dapat tidak dapat dibatasi atau didefinisikan, memberikan marjin operasi dan mengurangi tekanan untuk tim pengembangan.

Seperti mengatakan, Iteratif Tambahan adalah model dari jenis evolusi, yaitu jika diperbolehkan dan diharapkan perubahan mungkin dalam waktu pengembangan persyaratan, yang memberikan waktu ekstra untuk perangkat lunak dapat berkembang 9 . Berlaku ketika persyaratan yang cukup terkenal tetapi tidak sepenuhnya statis dan ditetapkan, pertanyaan jika hal ini sangat diperlukan untuk menggunakan model air terjun.

Model ini cocok untuk pengembangan perangkat lunak yang diamati dalam tahap awal analisis, yang memiliki area cukup didefinisikan dengan baik untuk menutupi, dengan kemandirian yang cukup untuk dikembangkan secara bertahap. Daerah tersebut seringkali harus menutupi berbagai tingkat urgensi sehingga sama harus diprioritaskan dalam analisis sebelumnya, yaitu menentukan yang akan menjadi yang pertama, kedua, dan seterusnya, ini dikenal sebagai “definisi meningkat” dengan berdasarkan prioritas. Mungkin tidak ada prioritas fungsional oleh klien, tetapi pengembang harus mengamankan mereka tetap dan untuk beberapa kriteria, karena berdasarkan pada mereka akan dikembangkan dan disampaikan bertahap berbagai.

Fakta bahwa ada kenaikan fungsional perangkat lunak mengarah langsung berpikir tentang skema pembangunan modular , sehingga model ini memfasilitasi paradigma desain tersebut.

Singkatnya, model inkremental menunjukkan perkembangan modular, dengan perangkat lunak pengiriman produk parsial disebut “bertahap” dari sistem, yang dipilih sesuai dengan prioritas yang telah ditetapkan entah bagaimana. Model ini memungkinkan implementasi dengan perbaikan berturut-turut (upgradeability). Dengan kenaikan masing-masing menambahkan fungsi baru atau persyaratan baru dibahas baik meningkatkan versi sebelumnya dilaksanakan dari produk software.
Model ini memberikan fleksibilitas dalam pengembangan untuk termasuk perubahan dalam kebutuhan pengguna, mengubah persyaratan dapat dianalisis dan disetujui diusulkan dan diimplementasikan sebagai pertumbuhan baru atau mungkin akhirnya menjadi perbaikan / adaptasi dari yang sudah direncanakan . Bahkan jika ada perubahan dalam kebutuhan pelanggan oleh kenaikan sebelumnya yang mempengaruhi sudah selesai (deteksi / terlambat masuk) harus mengevaluasi kelayakan dan membuat perjanjian dengan klien, karena sangat dapat berdampak pada biaya.

Pemilihan model ini memungkinkan pengiriman pelanggan awal fungsional (yang menguntungkan baik bagi dirinya dan bagi kelompok pengembangan). Pengiriman diprioritaskan modul tersebut atau kebutuhan operasional meningkat muncul untuk melakukannya, misalnya informasi preloads, penting untuk peningkatan berikut. 10

Model ini tidak memerlukan tambahan iteratif menentukan dengan presisi dan detail benar-benar semua bahwa sistem harus dilakukan, (dan bagaimana), sebelum dibangun (seperti kasus persyaratan air terjun, beku). Hanya meningkat dalam pembangunan. Hal ini membuat proses lebih mudah dikelola dan mengurangi dampak terhadap biaya. Hal ini karena jika persyaratan mengubah atau mengulang hanya mempengaruhi bagian dari sistem. Meskipun, tentu saja, situasi ini diperparah jika disajikan dengan canggih, yaitu meningkat di masa lalu. akhirnya, model memfasilitasi penggabungan persyaratan baru selama pengembangan.

Dengan paradigma bertahap mengurangi waktu pengembangan awal, karena fungsi parsial diimplementasikan. Hal ini juga memberikan dampak yang menguntungkan kepada pelanggan, yang merupakan pengiriman awal dari bagian operasi perangkat lunak.

Model ini memberikan semua keuntungan dari model umpan balik kaskade, mengurangi kelemahan hanya dalam kenaikan masing-masing.

Model inkremental tidak dianjurkan untuk kasus sistem real-time keamanan, tingkat tinggi, pemrosesan terdistribusi , atau indeks risiko tinggi.

Pola spiral

Model spiral pada awalnya diusulkan oleh Barry Boehm . Ini adalah model evolusioner yang menggabungkan berulang sifat model MCP dengan aspek terkontrol dan sistematis dari model air terjun. Memberikan potensi untuk pengembangan cepat versi tambahan. Dalam perangkat lunak model spiral dibangun pada serangkaian rilis inkremental. Dalam putaran pertama rilis inkremental mungkin menjadi model kertas atau prototipe. Dalam iterasi terakhir terjadi semakin melengkapi versi dari sistem yang dirancang.

Model ini dibagi menjadi beberapa kegiatan kerangka kerja, yang disebut ” daerah tugas . ” Pada umumnya ada 3-6 daerah tugas (ada varian dari model). Gambar 6 menunjukkan garis besar pola spiral dengan enam wilayah. Dalam hal ini menggambarkan varian dari model asli Boehm, seperti diuraikan dalam risalahnya tahun 1988, dan pada tahun 1998 dipamerkan sebuah perjanjian yang lebih baru.

Wilayah yang ditetapkan oleh model gambar adalah:
Wilayah 1 – Angkatan diperlukan untuk menjalin komunikasi antara klien dan pengembang.
Wilayah 2 – Tugas yang melekat dalam definisi sumber daya, waktu dan informasi lain yang berkaitan dengan proyek tersebut.
Region 3 – Tugas yang diperlukan untuk mengevaluasi risiko teknis dan manajemen proyek.
Wilayah 4 – Bekerja untuk membangun satu atau lebih representasi dari perangkat lunak aplikasi.
Wilayah 5 – Kerja untuk membangun aplikasi, menginstal, menguji dan memberikan dukungan pengguna atau pelanggan (misalnya dokumentasi dan praktek).
Wilayah 6 – Tugas untuk umpan balik pelanggan, sebagaimana dinilai oleh dibuat dan dipasang di siklus sebelumnya.

Kegiatan terdaftar untuk kerangka bersifat umum dan berlaku untuk setiap proyek, besar, menengah atau kecil, kompleks atau tidak. Daerah-daerah yang mendefinisikan kegiatan ini terdiri dari “kelompok tugas” kerja: keseluruhan harus beradaptasi dengan karakteristik proyek tertentu untuk melakukan. Perhatikan bahwa item yang tercantum dalam 1-6 adalah set tugas, beberapa dari mereka biasanya tergantung pada apakah atau proyek pembangunan.

Proyek-proyek kecil membutuhkan jumlah rendah tugas dan formalitas. Dalam proyek-proyek besar atau tugas-tugas penting masing-masing daerah mengandung bekerja tingkat yang lebih tinggi formalitas. Dalam hal apapun menerapkan kegiatan perlindungan (misalnya, manajemen konfigurasi perangkat lunak, jaminan kualitas, dll.).

Pada awal siklus, atau proses evolusi, tim engineering berkisar spiral (kiasan berbicara) dimulai di pusat (ditandai 1 pada Gambar 6) dan dalam arah yang ditunjukkan, rangkaian pertama dari pengembangan spiral dapat menghasilkan sebuah spesifikasi produk, langkah-langkah berikut bisa menghasilkan prototipe dan versi semakin lebih canggih dari perangkat lunak.

Setiap langkah dari hasil perencanaan daerah dalam penyesuaian rencana proyek, biaya dan perencanaan makan sesuai dengan evaluasi pelanggan. Manajer proyek harus menyesuaikan jumlah iterasi yang dibutuhkan untuk menyelesaikan pembangunan.

Model spiral dapat disesuaikan dan diterapkan di seluruh siklus hidup perangkat lunak (dalam model klasik, atau air terjun, menghentikan pengiriman perangkat lunak).

Sebuah pandangan alternatif dari model dapat dilihat dengan memeriksa “poros titik proyek masuk.” Setiap lingkaran (๏) tetap sepanjang sumbu mewakili titik awal dari proyek yang berbeda (terkait), yaitu:
Rancangan “pengembangan konsep” dimulai pada awal spiral, membuat beberapa iterasi sampai selesai, daerah ditandai dengan hijau.

Jika ini adalah untuk dikembangkan sebagai produk yang nyata, memulai proyek lain: “Pengembangan Produk Baru”. Mereka berkembang dari iterasi, memuncak, adalah daerah yang ditandai dengan warna biru.

Akhirnya proyek dan juga akan menghasilkan “peningkatan produk” dan “Pemeliharaan Produk” dengan iterasi yang diperlukan di masing-masing wilayah (daerah merah dan abu-abu, masing-masing).

Ketika spiral ditandai dengan cara ini adalah operasi sampai perangkat lunak dihapus , opsional dapat aktif (proses), tetapi ketika perubahan terjadi dalam proses restart titik yang tepat masuk (misalnya, dalam “Perbaikan Produk “).
Model spiral menyediakan software, realistis berkembang seperti 11 , cocok untuk skala besar perkembangan.

Spiral ini menggunakan CCM untuk mengurangi risiko dan memungkinkan penerapannya pada setiap tahap evolusi. Menjaga pendekatan klasik (air terjun) tetapi menggabungkan berulang kerangka kerja yang lebih mencerminkan realitas.
Model ini memerlukan pertimbangan risiko teknis pada semua tahapan proyek harus mengurangi diterapkan dengan benar sebelum mereka adalah masalah nyata.

Model evolusi sebagai Spiral yang sangat cocok untuk pengembangan sistem operasi (kompleks) sistem juga dalam risiko tinggi atau kritis (navigator penerbangan misalnya dan driver) dan mereka dalam kebutuhan untuk manajemen proyek yang kuat dan risiko, teknis atau manajerial.

Mayor kekurangan :

Membutuhkan pengalaman dan keterampilan untuk penilaian risiko, yang diperlukan untuk keberhasilan proyek.
Sulit untuk meyakinkan pelanggan besar dapat mengontrol pendekatan evolusi.

Model ini telah digunakan baik sebagai air terjun (Incremental) atau MCP , sehingga tidak ada ukuran yang baik efektivitasnya, adalah paradigma yang relatif baru dan sulit untuk melaksanakan dan mengendalikan.
Win & Win Model Spiral

Sebuah varian menarik dari Model Spiral sebelumnya terlihat (Gambar 6) adalah “Win-Win Spiral Model” (Barry Boehm). Model spiral sebelum (klasik) menunjukkan komunikasi dengan klien untuk menentukan persyaratan, mereka hanya meminta klien apa yang dia butuhkan dan menyediakan informasi untuk melanjutkan, tapi ini adalah konteks yang ideal dimana jarang terjadi. Biasanya pelanggan dan pengembang masuk ke dalam negosiasi, negosiasi biaya versus fungsi, kinerja, kualitas, dll.

“Jadi memperoleh negosiasi persyaratan mengharuskan berhasil ketika kedua belah pihak menang.”
Negosiasi terbaik dipaksa untuk mendapatkan “Victoria & Victoria” (Win & Win), yaitu pelanggan menang mendapatkan produk yang membayar, dan pengembang juga menang dengan mendapatkan anggaran dan tanggal pengiriman yang realistis. Jelas, model ini memerlukan keterampilan negosiasi yang kuat.

Win-Win Model mendefinisikan serangkaian kegiatan perdagangan pada awal setiap langkah sekitar spiral, kita mendefinisikan kegiatan sebagai berikut:

Sistem ID atau kunci subsistem manajer (*) (mengetahui apa yang mereka inginkan).
Penentuan “kondisi menang” manajer (tahu apa yang mereka butuhkan dan memuaskan)

Negosiasi istilah “kemenangan” dari manajer untuk memperoleh “Victoria & Victoria” (untuk bernegosiasi win-win).
(*) Manajemen: Klien dipilih dengan kepentingan langsung dalam produk, yang dapat diberikan oleh organisasi dikritik jika berhasil atau tidak.

Win & Win Model menekankan negosiasi awal, juga memperkenalkan tiga tonggak dalam proses yang disebut “titik attachment” yang membantu membangun kelengkapan suatu siklus spiral dan memberikan tonggak keputusan sebelum melanjutkan proyek pengembangan perangkat lunak. Tahapan dalam pengembangan perangkat lunak. Capture, analisis dan persyaratan spesifikasi.

Pada saat dimulainya pengembangan (bukan proyek), ini adalah penyelesaian tahap pertama, dan, menurut model proses diadopsi, Anda hampir dapat menyelesaikan untuk maju ke tahap berikutnya (Waterfall Model Untuk umpan balik) atau sebagian dapat kemudian mengambil itu (jika Incremental Model Iteratif atau karakter evolusi lainnya).

Dengan kata sederhana, dan pada dasarnya selama fase ini diperoleh, bersama-sama, dan menentukan fitur fungsional dan non-fungsional yang harus memenuhi program masa depan atau sistem yang akan dikembangkan.

Keuntungan dari karakteristik dari kedua sistem atau program yang akan dikembangkan, dan lingkungannya, arsitektur dan parameter nonfunctional sangat bergantung pada seberapa baik itu dicapai tahap ini. Ini mungkin yang paling penting dan salah satu tahapan yang paling sulit untuk mencapai akurat, itu tidak otomatis, tidak terlalu teknis dan sangat tergantung pada keahlian dan pengalaman dari analis yang berjalan itu.

Berat melibatkan pengguna atau sistem klien sehingga memiliki nuansa yang sangat subjektif dan sulit untuk model akurat atau menerapkan teknik yang “paling dekat di sebelah kanan” (pada kenyataannya ada “ketat yang tepat”). Meskipun beberapa metode telah dirancang, termasuk perangkat lunak pendukung untuk menangkap dan merekam elisitasi persyaratan, tidak ada cara yang sangat mudah atau benar-benar dapat diandalkan, dan harus diterapkan bersama-sama kriteria baik dan akal sehat pada bagian dari atau bertanggung jawab atas analis Tugas, juga penting untuk mencapai komunikasi yang lancar dan tepat dan pemahaman dengan pengguna akhir atau pelanggan sistem.

Artefak yang paling penting yang dihasilkan dari penyelesaian tahap ini adalah apa yang dikenal sebagai spesifikasi persyaratan perangkat lunak dokumen atau hanya ERS.

Seperti disebutkan, kemampuan analis untuk berinteraksi dengan pelanggan merupakan hal yang fundamental itu adalah umum bahwa pelanggan memiliki tujuan keseluruhan atau masalah untuk memecahkan, tahu apa-apa tentang daerah (komputer), atau jargon mereka, bahkan tahu persis apa yang harus produk software (apa dan berapa banyak fungsi) atau, apalagi, bagaimana seharusnya beroperasi. Dalam kasus langka lainnya, klien “berpikir” dia tahu persis apa perangkat lunak harus dilakukan, dan umumnya sangat sebagian berhasil, tapi keras kepala menghalangi tugas elisitasi. Analis harus mampu mengatasi masalah tersebut, termasuk hubungan manusia, harus tahu mengejar ketinggalan dengan pengguna untuk memungkinkan komunikasi yang baik dan pemahaman.

Ada beberapa situasi di mana klien yang tahu pasti dan bahkan memerlukan kelengkapan sistem masa depan mereka, ini adalah kasus yang paling sederhana untuk analis.

Tugas terkait untuk menangkap, elisitasi, pemodelan dan persyaratan pendaftaran, serta menjadi sangat penting, bisa sulit untuk mencapai dan mengambil waktu dengan benar pada proses pengembangan total, proses dan metode untuk melakukan ini set kegiatan biasanya mengambil bagian yang tepat dari rekayasa perangkat lunak , tetapi mengingat kompleksitas di atas, sekarang berbicara dari Teknik Persyaratan 12 , meskipun dia masih tidak resmi ada.

Ada kelompok studi dan penelitian, di seluruh dunia, yang hanya ditakdirkan untuk merancang model, teknik dan proses untuk mencoba untuk mencapai menangkap yang benar, menganalisis dan merekam persyaratan. Kelompok-kelompok ini adalah orang-orang yang biasanya berbicara tentang rekayasa persyaratan, yakni muncul sebagai area atau disiplin tetapi tidak sebagai universitas itu sendiri.

Beberapa persyaratan tidak memerlukan kehadiran pelanggan, yang akan ditangkap dan dianalisis, dalam beberapa kasus, dapat mengusulkan analis yang sama atau bahkan mengambil keputusan sepihak yang dianggap layak (persyaratan fungsional dan non-fungsional). Untuk mengutip contoh kemungkinan: Beberapa persyaratan pada arsitektur sistem, persyaratan non-fungsional seperti yang berkaitan dengan kinerja, tingkat dukungan terhadap kesalahan operasional, platform pengembangan, hubungan internal atau hubungan antara informasi (termasuk catatan atau tabel data) Jika disimpan dalam database atau bank data, dll. Beberapa fungsi seperti opsi sekunder atau dukungan untuk operasi yang lebih baik atau lebih sederhana, dll

Mendapatkan dari spesifikasi pelanggan (atau aktor-aktor lain yang terlibat) adalah proses manusia yang sangat interaktif dan berulang, biasanya sebagai informasi yang ditangkap, itu dianalisa dan makan kembali ke klien, menyempurnakan, polishing dan mengoreksi jika perlu; Apapun metode ERS digunakan. Analis harus selalu mengenal subjek dan masalah untuk memecahkan, menguasai, sampai batas tertentu, ke tingkat bahwa masa depan pembangunan yang menganut sistem. Oleh karena itu, analis harus memiliki kemampuan yang tinggi untuk memahami masalah di berbagai bidang atau bidang kerja (tidak secara khusus milik Anda), jadi misalnya, jika sistem yang akan dikembangkan adalah untuk mengelola informasi dari perusahaan asuransi dan cabang terpencil, analis seharusnya menembus dalam bagaimana dia bekerja dan menangani informasi Anda, dari tingkat yang sangat rendah, bahkan mencapai hingga manajemen. Mengingat berbagai bidang untuk memenuhi, analis sering dibantu oleh spesialis, yaitu orang yang tahu mendalam daerah yang perangkat lunak dikembangkan, ternyata satu orang (analis) tidak dapat menutupi seperti sejumlah besar daerah pengetahuan. Dalam pengembangan produk perangkat lunak besar, adalah umum untuk memiliki analis yang mengkhususkan diri dalam bidang pekerjaan tertentu.

Sebaliknya, itu bukan masalah pelanggan, yakni tidak perlu tahu apa-apa tentang perangkat lunak, atau desain, atau hal-hal terkait lainnya, hanya dibatasi untuk menyediakan data yang obyektif dan informasi (tangan atau mereka sendiri catatan, peralatan , karyawan, dll) dengan analis, dan dipandu oleh dia, bahwa, pertama-tama, mendefinisikan ” semesta wacana “, dan kemudian membuat kertas kerja yang sesuai mencapai ERS .
Hal ini dikenal tekanan pada pengembang untuk memahami sistem dan kebutuhan penyelamatan pelanggan / pengguna. Konteks masalah yang lebih kompleks lebih sulit untuk dicapai, kadang-kadang memaksa pengembang harus menjadi ahli yang menganalisis hampir domain.

Ketika ini terjadi, bukan tidak mungkin untuk menghasilkan satu set persyaratan 13 yang salah atau tidak lengkap dan karena itu produk perangkat lunak dengan tingkat tinggi ketidaksetujuan dari pelanggan / pengguna dan tingginya biaya re-engineering dan pemeliharaan. Apapun tidak terdeteksi, atau disalahpahami dalam tahap awal akan menimbulkan dampak negatif yang kuat pada persyaratan, ini merendahkan saat ini menyebar ke seluruh proses pembangunan dan meningkatkan prasangka mereka adalah deteksi lebih tertunda (Bell dan Thayer 1976) (Davis 1993).
Proses, pemodelan dan persyaratan elisitasi bentuk

Sejak penangkapan, elisitasi dan spesifikasi persyaratan adalah bagian penting dari proses pengembangan perangkat lunak, sebagai tahap ini tergantung pada pencapaian tujuan dimaksudkan akhir, kami telah menyusun berbagai model dan metode kerja untuk tujuan ini. Ada juga alat-alat yang mendukung perangkat lunak yang berhubungan dengan tugas-tugas yang dilakukan oleh insinyur persyaratan.

The IEEE 830-1998 standar menyediakan standar “Praktik Terbaik untuk Spesifikasi Persyaratan Software.” 14
Sebagai persyaratan diperoleh, biasanya menganalisis kemauan, hasil analisis ini, apakah atau tidak pelanggan, yang diwujudkan dalam suatu dokumen yang dikenal sebagai ERS atau Software Spesifikasi Persyaratan , struktur dapat didefinisikan oleh berbagai standar, seperti CMMI .

Langkah pertama dalam pengumpulan informasi adalah pengetahuan dan definisi yang benar apa yang dikenal sebagai “Universe Wacana” dari masalah, yang didefinisikan dan dipahami:

Universe of Discourse (uded) : adalah konteks umum di mana perangkat lunak akan dikembangkan dan akan beroperasi. The uded mencakup semua sumber informasi dan semua orang yang berhubungan dengan perangkat lunak. Orang-orang ini juga dikenal sebagai aktor alam semesta itu. Kenyataannya adalah situasional uded oleh semua yang menggugat tujuan yang telah ditetapkan oleh perangkat lunak.

Dari ekstraksi dan analisis informasi di bidang mereka memperoleh semua spesifikasi yang diperlukan dan jenis persyaratan untuk produk perangkat lunak masa depan.

Tujuan dari persyaratan rekayasa (IR) adalah untuk melakukan sistematisasi proses memungkinkan memperoleh definisi persyaratan, pemodelan dan menganalisis masalah, menghasilkan kompromi antara insinyur persyaratan dan pelanggan / pengguna, karena keduanya terlibat dalam generasi dan definisi persyaratan sistem. IR menyediakan seperangkat metode, teknik dan alat yang membantu kebutuhan insinyur (analis) untuk persyaratan sebagaimana aman, akurat, lengkap dan tepat waktu mungkin, pada dasarnya memungkinkan:

Memahami masalah
Mendapatkan memfasilitasi kebutuhan pelanggan / pengguna
Validasi dengan pelanggan / pengguna
Pastikan spesifikasi persyaratan

Walaupun ada berbagai bentuk, model dan metodologi untuk memperoleh, mendefinisikan dan persyaratan dokumen, Anda tidak bisa mengatakan bahwa salah satu dari mereka lebih baik atau lebih buruk dari yang lain, cenderung memiliki banyak kesamaan, dan semua memiliki tujuan yang sama. Tetapi bagaimana jika Anda dapat mengatakan tanpa keraguan adalah bahwa hal itu penting untuk menggunakan beberapa dari mereka untuk mendokumentasikan spesifikasi produk perangkat lunak masa depan. Sebagai contoh, ada sebuah kelompok riset Argentina selama beberapa tahun telah diusulkan dan dipelajari menggunakan LEL (Bahasa Lexicon Extended) dan skenario sebagai metodologi, di sini 15 menunjukkan salah satu dari banyak referensi dan bibliografi tentang hal itu. Lain, lebih ortodoks, untuk menangkap dan persyaratan dokumen dapat diperoleh secara rinci, misalnya, dalam karya dari University of Sevilla pada “Metodologi untuk Menganalisis Sistem Persyaratan Software.”

Sebuah daftar yang mungkin, tugas direkomendasikan umum dan tertib untuk definisi apa yang harus dilakukan, untuk mendapatkan produk dan teknik yang digunakan selama kegiatan elisitasi persyaratan, di bawah Spesifikasi Persyaratan Software adalah:

Dapatkan informasi tentang domain masalah dan sistem yang sekarang (uded).
Mempersiapkan dan membuat elisitasi untuk pertemuan / negosiasi.
Mengidentifikasi / meninjau tujuan pengguna.
Mengidentifikasi / meninjau tujuan sistem.
Mengidentifikasi / meninjau persyaratan untuk informasi.
Mengidentifikasi / meninjau persyaratan fungsional .
Mengidentifikasi / meninjau persyaratan nonfunctional .

Prioritaskan tujuan dan persyaratan.

Beberapa prinsip-prinsip dasar yang perlu diingat:

Hadir dan sepenuhnya memahami domain informasi dari masalah.
Benar mengatur fungsi yang harus dilakukan oleh Perangkat Lunak.
Mewakili perilaku perangkat lunak untuk konsekuensi dari peristiwa eksternal, individu, bahkan tak terduga.
Persyaratan mengakui tidak lengkap, ambigu atau bertentangan.
Jelas dibagi model yang mewakili informasi, fungsi dan perilaku dan non-fungsional karakteristik.
Klasifikasi dan identifikasi kebutuhan
Dapat diidentifikasi dua bentuk persyaratan:

Kebutuhan pengguna: Persyaratan Pengguna adalah frase dalam bahasa alami dengan diagram dengan layanan sistem harus menyediakan dan kendala dalam yang harus beroperasi.
Persyaratan Sistem: Persyaratan sistem menentukan layanan sistem dan kendala, tetapi secara rinci. Mereka melayani sebagai kontrak.

Artinya, keduanya sama, tetapi dengan berbagai tingkat detail.

Contoh kebutuhan pengguna: Sistem ini harus memberikan pinjaman sistem Contoh persyaratan: Fungsi kredit: masuk kode partner, kode copy, check out: tanggal kembali, dll.

Mereka diklasifikasikan menjadi tiga jenis persyaratan sistem:

Fungsional persyaratan
Persyaratan fungsional menggambarkan:
Layanan yang diberikan oleh sistem (fungsi).
Sistem ini menanggapi masukan tertentu.
Perilaku sistem dalam situasi tertentu.
Nonfunctional persyaratan

Persyaratan nonfunctional pembatasan layanan atau fungsi yang ditawarkan oleh sistem (misalnya dimensi waktu, proses pembangunan, hasil, dll.)

Contoh 1. Perpustakaan Pusat harus dapat hadir secara bersamaan untuk semua perpustakaan dari Universitas
Contoh 2. Waktu respons atas permintaan remote tidak boleh melebihi 1/2 s

Pada gilirannya, ada tiga jenis non-fungsional persyaratan:

Produk Persyaratan. Ditentukan kinerja produk (kinerja misalnya, memori, tingkat kegagalan, dll)
Persyaratan organisasi. Mereka berasal dari kebijakan dan prosedur organisasi klien dan pengembang (misalnya standar proses, bahasa pemrograman, dll.)

Persyaratan eksternal. Faktor eksternal berasal dari sistem dan proses pembangunan (misalnya legislatif, etika, dll.)
Persyaratan domain.

Persyaratan Domain berasal dari domain aplikasi dan mencerminkan karakteristik dari domain tersebut.
Mereka dapat menjadi fungsional atau nonfungsional.

Sistem perpustakaan Ex Universitas harus dapat mengekspor data menggunakan Perpustakaan pergaulan Bahasa Spanyol (Libe). Sistem perpustakaan Ex tidak dapat mengakses perpustakaan dengan bahan disensor.

Desain Sistem

Dalam rekayasa perangkat lunak , desain merupakan fase siklus hidup perangkat lunak . Hal ini didasarkan pada spesifikasi kebutuhan yang dihasilkan oleh analisis kebutuhan (tahap analisis), desain mendefinisikan bagaimana persyaratan ini terpenuhi, struktur yang akan diberikan kepada sistem perangkat lunak untuk direalisasikan.
Desain tetap fase terpisah pemrograman atau coding, yang terakhir sesuai dengan terjemahan dalam tertentu bahasa pemrograman dari asumsi diadopsi dalam desain.

Perbedaan antara kegiatan tersebut sejauh tidak selalu jelas bagaimana mereka ingin dalam teori klasik rekayasa perangkat lunak. Desain, terutama mungkin menggambarkan operasi internal dari suatu sistem pada tingkat detail yang berbeda, masing-masing ditempatkan dalam posisi penengah antara analisis dan encoding.
Biasanya istilah “desain arsitektur” desain “tingkat yang sangat tinggi”, yang hanya mendefinisikan struktur sistem dalam hal modul perangkat lunak yang mencakup makroskopik dan hubungan antara mereka. Pada tingkat formula desain milik sebagai client-server atau “tiga tingkat”, atau, lebih umum, keputusan tentang penggunaan arsitektur hardware khusus yang digunakan, sistem operasi, DBMS , protokol jaringan , dll.

Sebuah tingkat menengah detail dapat menentukan dekomposisi sistem modul, tapi kali ini dengan modus dekomposisi referensi kurang lebih eksplisit yang memberikan tertentu bahasa pemrograman dengan pengembangan akan dilaksanakan, misalnya, dalam desain dibuat dengan teknologi obyek , proyek bisa menggambarkan sistem dalam hal kelas dan hubungan mereka.

Desain rinci, akhirnya, deskripsi sistem ini sangat dekat dengan encoding (misalnya, menggambarkan tidak hanya kelas secara abstrak, tetapi juga atribut dan metode dengan jenis mereka).
Karena sifat software “intangible”, dan tergantung pada peralatan yang digunakan dalam proses, perbatasan antara desain dan coding juga dapat hampir mustahil untuk mengidentifikasi. Sebagai contoh, beberapa alat KASUS mampu menghasilkan kode dari diagram UML, yang secara grafis menggambarkan struktur dari suatu sistem perangkat lunak.

Coding Software

Selama tahap ini melakukan tugas-tugas umum dikenal sebagai pemrograman , pada dasarnya terdiri dari sumber utama, dalam pilihan bahasa pemrograman, semuanya dirancang pada fase sebelumnya. Tugas ini dilakukan oleh pengembang , sesuai dengan pedoman yang dikenakan sepenuhnya pada desain dan selalu mempertimbangkan persyaratan fungsional dan nonfunctional (ERS) ditetapkan dalam tahap pertama.

Hal ini biasanya berpikir bahwa tahap pemrograman atau coding (beberapa implementasi panggilan) yang mengkonsumsi sebagian besar pekerjaan pengembangan perangkat lunak, tetapi hal ini dapat relatif (dan umumnya berlaku untuk sistem berukuran kecil) sebagai tahap sebelumnya sangat penting, penting, dan mungkin diperlukan beberapa waktu lagi. Hal ini biasanya melibatkan perkiraan 30% dari total waktu insumido dalam pemrograman, tetapi angka ini tidak konsisten karena sangat bergantung pada karakteristik dari sistem, kekritisan dan pilihan bahasa pemrograman. 7 Di bawah tingkat tinggi bahasa pemrograman waktu yang dibutuhkan, jadi misalnya itu akan memakan waktu lebih lama untuk mengkodekan suatu algoritma dalam bahasa assembly pada yang sama dijadwalkan bahasa C .

Sementara program aplikasi, sistem, atau perangkat lunak secara umum, juga membuat debugging, ini adalah karya membebaskan kode saya kesalahan yang ditemukan layak pada tahap ini (semantik, sintaksis dan logis). Ada banyak tumpang tindih dengan fase berikutnya karena untuk debug logika unit testing diperlukan, biasanya dengan data uji; jelas adalah bahwa tidak semua kesalahan akan ditemukan hanya dalam tahap perencanaan, akan ada orang lain yang akan ditemui selama selanjutnya tahap. Terjadinya kesalahan fungsional (respon miskin untuk permintaan) akhirnya dapat menyebabkan kembali ke tahap desain sebelum melanjutkan encoding.

Selama fase pemrograman, kode dapat mengambil beberapa negara, tergantung pada cara mereka bekerja dan bahasa yang dipilih, yaitu:

Sumber : yang ditulis langsung oleh programmer di editor teks, yang menghasilkan Program . Berisi set instruksi kode dalam bahasa tingkat tinggi. Paket dapat didistribusikan, prosedur, perpustakaan sumber, dll

Kode objek : kode biner atau hasil pengolahan menengah dari compiler kode sumber. Ini terdiri dari terjemahan penuh dan sekali kedua. Kode objek tidak dipahami oleh manusia (biasanya biner) tapi tidak secara langsung dieksekusi oleh komputer. Ini merupakan representasi perantara antara kode sumber dan kode dieksekusi untuk tujuan dari rutinitas link terakhir perpustakaan dan antara prosedur atau untuk digunakan dengan juru perantara kecil dengan cara melihat beberapa contoh [ EUFORIA , ( antara interpreter), FORTRAN (murni compiler) MSIL (Microsoft Intermediate Language) (interpreter) dan BASIC (interpreter murni, interpreter antara compiler compiler menengah atau murni, tergantung pada versi yang digunakan)].

Kode obyek tidak ada jika programmer bekerja dengan bahasa sebagai penerjemah murni , dalam hal ini artis yang sama bertanggung jawab untuk menerjemahkan baris demi baris dan menjalankan kode sumber (sesuai dengan aliran program) pada saat runtime. Dalam kasus ini juga ada file atau kode dieksekusi . Kelemahan dari pendekatan ini adalah bahwa pelaksanaan program atau sistem yang sedikit lebih lambat daripada jika dilakukan dengan penerjemah, dan jauh lebih lambat daripada jika file atau kode dieksekusi. Itu tidak dalam performa terbaik dalam kecepatan eksekusi. Tapi keuntungan besar dari modus juru murni, adalah bahwa cara kerja membuatnya lebih mudah untuk debug kode sumber (terhadap alternatif melakukannya dengan compiler murni). Seringkali biasanya menggunakan bentuk campuran kerja (jika bahasa pemrograman yang dipilih memungkinkan), yaitu bekerja awalnya sebagai juru murni, dan sekali debugged kode sumber (perbaikan dirilis) digunakan compiler bahasa yang sama memperoleh kode dieksekusi penuh, sehingga mempercepat pemurnian dan kecepatan eksekusi dioptimalkan.

Kode dieksekusi : Kode Biner adalah hasil dari menghubungkan satu atau lebih potongan rutinitas kode obyek dan pustaka yang diperlukan. Merupakan satu atau lebih file biner ke format bahwa sistem operasi dapat memuat ke memori RAM (dan mungkin berpartisipasi dalam memori virtual ), dan melanjutkan ke eksekusi langsung. Oleh karena itu kita mengatakan bahwa kode ini langsung dieksekusi “komputer dibaca”. Kode dieksekusi, juga dikenal sebagai kode mesin , jika tidak ada mode program “juru murni.”

Pengujian (unit dan integrasi)

Di antara berbagai tes yang akan dibuat untuk perangkat lunak dapat dibedakan terutama:
Pengujian Satuan : terdiri membuktikan atau potongan-potongan kecil dari pengujian perangkat lunak, bagian tingkat, prosedur, fungsi dan modul, orang-orang dengan fungsi tertentu. Tes ini digunakan untuk memastikan operasi yang benar dari bagian kode, jauh lebih kecil dari keseluruhan, dan memiliki fungsi tertentu dengan beberapa tingkat kemandirian.
Pengujian integrasi : unit test Setelah Anda selesai diselesaikan dengan sukses , dengan mereka mencoba untuk memastikan bahwa seluruh sistem, termasuk subsistem dalam potongan individu besar perangkat lunak untuk mengoperasikan dan berfungsi dengan baik inteoperar bersama-sama.

Pengujian biasanya dilakukan dengan apa yang disebut data tes , yang merupakan data yang khas ditetapkan dipilih untuk yang sistem dapat dikenakan, modul atau blok kode. Juga memilih: Data kondisi batas yang menyebabkan perangkat lunak untuk menguji toleransi dan ketahanan, data yang berguna untuk mengukur kinerja, data atau menyebabkan kondisi tertentu langka dan bahwa perangkat lunak tidak tunduk tetapi biasanya terjadi , dll. The “data uji” tidak selalu fiktif atau “diciptakan”, tetapi biasanya jika Anda adalah probabilitas rendah kejadian.
Umumnya, ada fase pembuktian final dan lengkap dari perangkat lunak, yang disebut Uji Beta , di mana sistem diinstal pada kondisi operasi normal dan bekerja benar-benar diuji untuk menemukan bug, ketidakstabilan, jawaban yang salah, dll. telah lulus kontrol sebelumnya. Ini biasanya dilakukan oleh teknisi ahli khusus disewa atau terpengaruh karenanya. Setiap kesalahan yang ditemukan dilewatkan ke pengembang untuk debugging. Dalam hal pengembangan perangkat lunak ‘on demand’, pengguna akhir (client) yang melakukan uji Beta, yang tujuan masa percobaan disepakati dengan pengembang.

Instalasi dan tahap produksi

The instalasi perangkat lunak adalah proses dimana program disusun dengan benar ditransfer ke komputer tujuan, diinisialisasi, dan akhirnya mengatur , semua dengan tujuan yang sudah digunakan oleh pengguna akhir. Adalah langkah terakhir dalam pengembangan perangkat lunak itu sendiri. Setelah produk ini akan mulai beroperasi dan tahap produksi, untuk yang dirancang.

Instalasi, tergantung pada sistem yang dikembangkan, dapat salinan sederhana untuk hard disk target (saat ini kasus yang jarang terjadi), atau, lebih umum, dengan kompleksitas menengah di mana berbagai komponen dari file software (executable, perpustakaan , data sendiri, dll) yang membuka ritsleting dan disalin ke lokasi disk yang spesifik preset, termasuk menciptakan hubungan dengan produk lain, selain mereka sendiri sistem operasi . Yang terakhir, biasanya adalah proses yang cukup otomatis yang dibuat dan dipandu dengan Alat-perangkat lunak khusus ( kemasan dan distribusi, installer ).

Dalam produk yang lebih kompleks, alternatif kedua yang digunakan, tetapi dibuat atau dipandu oleh spesialis, bahkan
mungkin diperlukan untuk menginstal di komputer yang berbeda (instalasi didistribusikan).

Juga, dalam kompleksitas perangkat lunak yang tinggi dan menengah biasanya diperlukan suatu proses pengaturan dan memeriksa, yang ditugaskan oleh parameter operasi yang sesuai dan menguji operasi fungsional produk.

Dalam produk pasar massal fasilitas lengkap, jika mereka relatif sederhana, biasanya dilakukan oleh pengguna akhir sendiri (seperti sistem operasi, office suite, utilitas, dll) Dengan alat instalasi sendiri dipandu, termasuk konfigurasi otomatis biasanya . Dalam desain produk tertentu atau “disesuaikan” instalasi dibatasi, biasanya spesialis orang yang terlibat dalam pengembangan perangkat lunak yang bersangkutan.

Setelah berhasil menginstal perangkat lunak, yang sama terjadi pada tahap produksi (operasi), selama memenuhi fungsi untuk yang dikembangkan, yaitu, akhirnya digunakan untuk (atau) pengguna akhir, memproduksi hasil.

Pemeliharaan

The pemeliharaan perangkat lunak adalah kontrol proses, peningkatan dan optimalisasi perangkat lunak yang telah dikembangkan dan diinstal, yang juga termasuk debugging dan cacat yang mungkin telah bocor dari fase kontrol dan uji beta. Fase ini adalah yang terakhir (sebelum iterasi, mengikuti model) diterapkan pada siklus hidup pengembangan perangkat lunak. Fase pemeliharaan adalah salah satu yang datang setelah perangkat lunak adalah operasional dan produksi.

Desain yang baik dan pengembangan dokumentasi akan tergantung pada bagaimana tahap pemeliharaan, baik biaya temporal dan moneter. Modifikasi dibuat untuk perangkat lunak yang dikembangkan dengan dokumentasi yang tidak benar atau miskin dan desain miskin bisa sama atau lebih mahal daripada mengembangkan software dari awal. Oleh karena itu sangat penting karena hormat untuk semua tugas dari tahap pembangunan dan memelihara dokumentasi yang tepat dan lengkap.

Periode tahap pemeliharaan biasanya yang terbesar di seluruh siklus hidup. 7 Fase ini juga melibatkan pembaruan dan perkembangan perangkat lunak, tidak selalu berarti bahwa sistem memiliki kesalahan. Satu atau lebih perubahan dalam perangkat lunak, misalnya, atau adaptasi evolusioner, bahkan dapat menyebabkan meninjau dan beradaptasi dari tahap awal pengembangan awal, mengubah semua yang lain tergantung pada seberapa dalam perubahan. Model air terjun sangat umum dalam pemeliharaan mahal karena kekakuan berarti bahwa setiap perubahan menyebabkan perubahan kembali panggung dan substansial dalam fase lain dari siklus hidup.

Selama masa pemeliharaan, itu adalah umum untuk mendapatkan revisi baru dan versi produk, yang mereka merilis lebih halus, dengan fungsionalitas lebih dan lebih baik, perbaikan kinerja, dll. Ada beberapa aspek yang dapat diubah untuk menyebabkan perubahan yang diinginkan, adaptasi evolusi atau ekstensi dan perbaikan.
Pada dasarnya kita memiliki jenis berikut perubahan:

Perfektif: Mereka yang mengarah pada peningkatan mutu internal dalam semua aspek dari perangkat lunak: Restrukturisasi definisi kode lebih jelas dan sistem dokumentasi, mengoptimalkan kinerja dan efisiensi.
Evolusi: penambahan, modifikasi, penghapusan bahkan diperlukan dalam perangkat lunak untuk memenuhi ekspansi mereka atau perubahan sesuai dengan kebutuhan pengguna.
Adaptif: Perubahan yang mempengaruhi lingkungan di mana sistem beroperasi, seperti perubahan konfigurasi hardware (dengan memperbarui atau memperbaiki komponen elektronik), perubahan dalam basis software, manajer database, komunikasi, dan lain-lain
Korektif: Perubahan yang diperlukan untuk memperbaiki kesalahan dalam produk perangkat lunak yang dikembangkan.
Berkembang sifat perangkat lunak

Perangkat lunak ini adalah produk yang berasal dari proses pembangunan sebagai rekayasa perangkat lunak. Produk ini secara inheren evolusi siklus hidup. Perangkat lunak ini berkembang, secara umum, menghasilkan versi semakin kompleks, kompleks, meningkatkan, dioptimalkan dalam beberapa cara, sesuai dengan platform baru (baik perangkat keras atau sistem operasi, dll).

Ketika sistem gagal untuk berkembang, akhirnya memenuhi siklus hidup mereka, dan pasti datang ke usang, cepat atau lambat, akan diganti dengan produk baru.

Perangkat lunak yang berkembang hanya harus beradaptasi dengan lingkungan yang berubah, fungsional (kebutuhan pengguna), operasional, platform perangkat keras atau arsitektur.

Dinamika evolusi perangkat lunak adalah studi tentang perubahan dalam sistem. Kontribusi utama di daerah ini dilakukan oleh Meir M. Lehman dan Belady , dimulai pada tahun 70-an dan 80-an. Karyanya berlanjut di tahun 1990-an, dengan Lehman dan peneliti lainnya 18 umpan balik relevansi dalam proses evolusi (Lehman, 1996, Lehman et al., 1998, Lehman et al, 2001.). Dari studi ini mengusulkan satu set hukum (dikenal sebagai hukum Lehman ) pada bulan September sehubungan dengan perubahan sistem. Undang-undang (sebenarnya hipotesis) bersifat tetap dan berlaku secara luas.
Lehman dan Belady menganalisis pertumbuhan dan perkembangan dari beberapa berukuran besar sistem software, berasal pada akhirnya, sesuai dengan ukuran Anda, berikut delapan undang-undang:

Flux: Sebuah program yang digunakan dalam lingkungan dunia nyata tentu harus mengubah atau menjadi semakin kurang berguna dalam lingkungan tersebut.

Peningkatan Kompleksitas: Sebagai perubahan program berkembang, strukturnya cenderung semakin kompleks. Harus didedikasikan untuk melestarikan dan ekstra recuersos menyederhanakan estrucutura.
Tentu saja berkepanjangan program: Evolusi program adalah proses self-regulating. Atribut sistem, seperti ukuran, waktu antara pengiriman dan jumlah kesalahan didokumentasikan adalah sekitar invarian untuk setiap rilis sistem.
Stabilitas Organisasi: Selama masa program, kecepatan perkembangannya adalah sekitar konstan dan independen dari sumber daya yang ditujukan untuk pengembangan sistem.

Konservasi keakraban: Selama masa sistem, perubahan inkremental dalam rilis setiap mendekati konstan.
Pertumbuhan yang berkelanjutan: Fungsi yang ditawarkan oleh sistem harus terus meningkatkan untuk mempertahankan kepuasan pengguna.

Penurunan kualitas: Kualitas sistem perangkat lunak mulai menurun kecuali sistem ini untuk beradaptasi dengan perubahan dalam lingkungan operasi.

Sistem umpan balik: proses evolusi menggabungkan sistem multiagen dan umpan balik multiloop dan ini harus diperlakukan sebagai sistem umpan balik untuk mencapai peningkatan yang signifikan dari produk.

Leave a Reply