Analisis dan Perancangan Sistem

Posted on

Pengembangan sistem (system development) dapat diartikan sebagai suatu kegiatan mengembangkan sistem yang baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki sistem yang telah ada.

Suatu sistem perlu dikembangkan tidak hanya karena terdapat masalah pada sistem tersebut, akan tetapi adanya perintah dan kebijakan, baik dari dalam organisasi maupun dari luar organisasi. Pertumbuhan organisasi serta adanya peluang bagi organisasi untuk menuju ke arah perkembangan yang baik juga dapat menjadi alasan sebuah sistem dapat dikembangkan.

Proses pengembangan proyek sistem yang besar memerlukan sejumlah orang dalam bentuk tim kerja. Tim tersebut terdiri atas tim analis pada berbagai bidang, seperti bidang bisnis, bidang sistem, bidang infrastruktur, dan bidang manajemen perubahan, serta tim pemrogram. Tim kerja tersebut dipimpin oleh seorang Manajer Proyek.

Analis memiliki peran sentral dalam pengembangan sistem. Analis sebagai pemecah masalah (bisnis, sistem, infrastruktur, manajemen, dan etika) yang berkesinambungan dalam siklus hidup sistem, baik di tingkat proyek maupun di tingkat organisasi. Analis menjembatani kepentingan pengguna sistem (manajemen dan end user) dengan pembuat sistem (programmer). Di tingkat proyek, analis juga sebagai perantara komunikasi antara manajer proyek dengan tim proyek lainnya. Dengan demikian, dalam lingkup proyek pengembangan sistem yang kecil dan sederhana, kemungkinan hanya terdapat seorang analis sistem yang merangkap sebagai manajer proyek dan pemrogram.

Proses pengembangan sistem melewati beberapa tahapan (fase), dimulai dari fase perencanaan, analisis, desain, sampai dengan sistem tersebut diimplementasikan, dioperasikan, dan dipelihara. Bila dalam operasi sistem masih timbul permasalahan- permasalahan yang tidak dapat diatasi dalam tahap pemeliharaan sistem, maka sistem tersebut perlu ditinjau kembali untuk dikembangkan dengan mengimplementasikan kembali tahap awal. Proses ini membentuk sebuah siklus yang dikenal dengan nama siklus hidup pengembangan sistem (system development life cycle/SDLC). SDLC menjadi dasar munculnya berbagai ragam metodologi pengembangan lain yang telah disesuaikan dengan kebutuhan pengembangan sistem.

Munculnya berbagai istilah yang digunakan dalam pengembangan sistem informasi seringkali membuat bingung bagi pemakainya, terutama kerancuan dan kekaburan makna dari istilah metode dan metodologi. Pengertian metode dan metodologi bahkan sering saling dipertukarkan (bermakna sama) atau mempunyai makna yang berbeda pada situasi yang berbeda. Namun beberapa pakar di bidang sistem informasi berpandangan bahwa secara pragmatis pengertian metodologi dapat dianggap sama dengan pengertian metode. Demikian juga dengan ragam metodologi pengembangan sistem, seringkali membuat bingung dalam mempelajari dan memahaminya. Munculnya ragam metodologi pengembangan sistem informasi diakibatkan oleh adanya perbedaan sudut pandang para penyusun metodologi dalam merumuskan metodologi tersebut, seperti sudut pandang latar belakang maupun pendekatan yang digunakan dalam pengembangan sistem, sudut pandang filosofi, tema pengembangan, serta objek pengembangan (model proses atau objek proses).

Meskipun berbeda, pada dasarnya setiap metodologi pengembangan sistem berusaha mencapai suatu tujuan yang sama yaitu harapan untuk mendefinisikan secara akurat apa yang menjadi kebutuhan pengguna, memantau dan mengendalikan proyek pengembangan sistem dengan baik, serta menghasilkan sistem dengan sumber daya pengembangan yang efisien.

Proses pengembangan sistem melewati beberapa tahapan (fase), dimulai dari fase perencanaan, analisis, desain, sampai dengan sistem tersebut diimplementasikan, dioperasikan, dan dipelihara. Bila dalam operasi sistem masih timbul permasalahan- permasalahan yang tidak dapat diatasi dalam tahap pemeliharaan sistem, maka sistem tersebut perlu ditinjau kembali untuk dikembangkan dengan mengimplementasikan kembali tahap awal. Proses ini membentuk sebuah siklus yang dikenal dengan nama siklus hidup pengembangan sistem (system development life cycle/SDLC). SDLC menjadi dasar munculnya berbagai ragam metodologi pengembangan lain yang telah disesuaikan dengan kebutuhan pengembangan sistem.

Munculnya berbagai istilah yang digunakan dalam pengembangan sistem informasi seringkali membuat bingung bagi pemakainya, terutama kerancuan dan kekaburan makna dari istilah metode dan metodologi. Pengertian metode dan metodologi bahkan sering saling dipertukarkan (bermakna sama) atau mempunyai makna yang berbeda pada situasi yang berbeda. Namun beberapa pakar di bidang sistem informasi berpandangan bahwa secara pragmatis pengertian metodologi dapat dianggap sama dengan pengertian metode. Demikian juga dengan ragam metodologi pengembangan sistem, seringkali membuat bingung dalam mempelajari dan memahaminya. Munculnya ragam metodologi pengembangan sistem informasi diakibatkan oleh adanya perbedaan sudut pandang para penyusun metodologi dalam merumuskan metodologi tersebut, seperti sudut pandang latar belakang maupun pendekatan yang digunakan dalam pengembangan sistem, sudut pandang filosofi, tema pengembangan, serta objek pengembangan (model proses atau objek proses).

Mendefinisikan proyek-proyek sistem adalah bagian dari perencanaan sistem setelah suatu proyek sistem prioritas ditentukan dan analis sistem telah ditunjuk. Pada kegiatan ini analis melakukan suatu studi untuk mencari alternatif-alternatif pemecahan terbaik yang paling layak untuk dikembangkan. Kegitan tersebut meliputi kegiatan mengidentifikasi kembali ruang lingkup dan sasaran proyek sistem, melakukan studi kelayakan, dan menilai kelayakan proyek sistem.

Ruang lingkup dan sasaran proyek-proyek sistem perlu didefinisikan kembali oleh analis dengan cara berdiskusi dengan manajemen untuk mengkaji kembali mengenai ruang lingkup dan sasaran sistem. Tim analis dapat memberikan usulan- usulan tambahan bila dipandang perlu. Ruang lingkup dan sasaran dari proyek sistem harus betul-betul dipahami terlebih dahulu oleh tim analis, karena hal ini sangat erat hubungannya terutama dalam perencanaan biaya dan waktu pengembangan sistem yang akan diperkirakan oleh analis.

Tujuan utama perencanaan proyek sistem adalah menyediakan sebuah kerangka kerja yang memungkinkan manajer proyek atau analis membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya, dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek sistem informasi dan diperbaharui secara teratur selagi proyek sedang berjalan. Meskipun estimasi juga merupakan suatu seni seperti juga pada sains, aktivitas ini tidak dilakukan secara serampangan. Terdapat teknik-teknik tertentu yang dapat digunakan untuk melakukan estimasi.

Analisis kelayakan digunakan untuk memberikan rincian lebih lanjut tentang risiko yang terkait dengan sistem yang diusulkan, mencakup kelayakan teknis, ekonomi, dan organisasi. Kelayakan teknis berfokus pada apakah sistem dapat dibangun, dengan memeriksa risiko yang terkait dengan keakraban pengguna dan analis dengan aplikasi, keakraban dengan teknologi, ukuran proyek, dan kompatibilitas dengan sistem yang ada. Kelayakan ekonomi membahas apakah sistem harus dibangun. Ini mencakup analisis biaya-manfaat dari biaya pengembangan, biaya operasional, manfaat berwujud, dan biaya dan manfaat tidak berwujud. Analisis kelayakan organisasi menilai seberapa baik sistem akan diterima oleh penggunanya dan integrasikan ke dalam operasi organisasi yang sedang berlangsung. Penyelarasan strategis proyek dan analisis pemangku kepentingan dapat digunakan untuk menilai dimensi kelayakan ini.

Faktor penentu keberhasilan manajemen proyek adalah memulai dengan menilai secara realistis pekerjaan yang perlu diselesaikan dan kemudian mengelola proyek sesuai dengan rencana. Ini dapat dicapai dengan mengikuti beberapa langkah dasar manajemen proyek, berupa: pemilihan metodologi pengembangan sistem yang sesuai dengan karakteristik proyek, membuat perkiraan jangka waktu berdasarkan ukuran sistem yang dikembangkan, serta membuat daftar penugasan.

Terdapat beberapa metodologi yang merupkan pendekatan formal yang dapat digunakan dalam manajemen pengembangan sistem informasi. Metodologi tersebut merupakan standar formal yang digunakan oleh lembaga pemerintah, sementara yang lain telah dikembangkan oleh perusahaan konsultan untuk dijual kepada klien. Banyak organisasi juga menggunakan metodologi internal mereka sendiri yang telah didefinisikan selama bertahun-tahun. Siklus hidup pengembangan sistem (System Development Life Cycle/SDLC) menyediakan landasan bagi metodologi-metodologi tersebut dalam pengembangan sistem informasi.

Beberapa metodologi utama adalah Waterfall dan variasinya berupa model Parallel dan V-model; Rapid Application Development (RAD) yang terdiri atas model Iterative, System Prototyping dan Throwaway Prototyping; dan model Agile termasuk Extreme Programming. Manajer proyek mengevaluasi karakteristik proyek melalui beberapa faktor, seperti kejelasan kebutuhan pengguna, keakraban dengan teknologi, kompleksitas, keandalan, kerangka waktu, dan visibilitas jadwal, untuk memilih metodologi yang paling tepat digunakan dalam pengembangan proyek.

Manajer proyek kemudian memperkirakan kerangka waktu untuk proyek tersebut. Pengalaman masa lalu, standar industri, dan teknik seperti analisis function- point, memberikan bantuan dalam tugas ini. Metodologi proyek menyediakan daftar tugas dan sasaran proyek, yang diubah oleh manajer proyek, tergantung pada kebutuhan proyek tertentu. Untuk membuat rencana kerja, manajer proyek merevisi tugas-tugas menjadi struktur rincian kerja, perkiraan waktu penugasan, serta informasi lainnya dimasukkan ke dalam rencana kerja.

Analisis berfokus pada kegiatan menjaring kebutuhan (persyaratan) bisnis untuk sistem. Analisis mengidentifikasi “apa” yang perlu ada pada sistem, dan itu akan bermuara pada langkah awal dalam fase desain, yaitu “bagaimana” sistem ditentukan. Hasil yang diperoleh selama fase analisis yaitu definisi kebutuhan, termasuk kasus penggunaan, model proses, dan model data. Pada akhir analisis, semua hasil ini bersama dengan dokumen perencanaan awal yang telah direvisi, digabungkan ke dalam proposal sistem dan diserahkan kepada komite persetujuan untuk keputusan mengenai apakah proyek akan dilanjutkan ke fase desain.

Penentuan kebutuhan adalah bagian dari analisis di mana tim proyek mengubah kebutuhan bisnis secara umum yang dinyatakan dalam permintaan sistem menjadi daftar kebutuhan yang lebih terperinci. Kebutuhan adalah pernyataan tentang apa yang harus dilakukan sistem atau karakteristik apa yang perlu dimiliki. Kebutuhan bisnis menggambarkan tujuan keseluruhan sistem serta kontribusi “apa” yang akan dihasilkan bagi keberhasilan organisasi, dan kebutuhan sistem menggambarkan “bagaimana” sistem akan dilaksanakan. Kebutuhan pengguna menjelaskan hal-hal yang dilakukan pengguna sebagai bagian integral dari operasi bisnis. Kebutuhan fungsional berhubungan langsung dengan proses yang harus dilakukan sistem atau informasi yang perlu dikandungnya, sedangkan kebutuhan nonfungsional mengacu pada properti perilaku yang harus dimiliki sistem, seperti kinerja dan kegunaan. Semua kebutuhan bisnis fungsional dan nonfungsional yang sesuai dengan ruang lingkup sistem ditulis dalam definisi kebutuhan.

Validasi kebutuhan berkenaan dengan pengidentifikasian bahwa kebutuhan benar-benar mendefinisikan sistem yang diinginkan pengguna. Validitas kebutuhan dilakukan melalui serangkaian pemeriksaan terhadap dokumen kebutuhan yang meliputi pemeriksaan validitas, pemeriksaan konsistensi, pemeriksaan kelengkapan, pemeriksaan realisme, dan kemampuan untuk dapat diverifikasi. Validasi kebutuhan penting karena kesalahan pada dokumen kebutuhan dapat menimbulkan biaya pengerjaan ulang yang ekstensif jika ditemukan pada saat pengembangan atau setelah sistem dipakai.

Lima teknik dapat digunakan untuk memperoleh kebutuhan bisnis untuk sistem yang diusulkan: wawancara, pengembangan aplikasi bersama, kuesioner, analisis dokumen, dan observasi. Wawancara melibatkan pertemuan dengan satu atau lebih orang dan mengajukan pertanyaan kepada mereka. Ada lima langkah dasar untuk proses wawancara: memilih orang yang diwawancarai, merancang pertanyaan wawancara, mempersiapkan wawancara, melakukan wawancara, dan tindak lanjut pascal wawancara. Pengembangan aplikasi bersama (Joint Application Development/JAD) memungkinkan tim proyek, pengguna, dan manajemen untuk bekerja sama mengidentifikasi kebutuhan untuk sistem. Electronic JAD berupaya mengatasi masalah umum yang terkait dengan grup dengan menggunakan groupware. Kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu. Kuesioner sering digunakan ketika ada sejumlah besar orang yang menjadi sumber informasi atau pendapat. Analisis dokumen mencakup peninjauan dokumentasi yang ada dan memeriksa sistem itu sendiri. Ini dapat memberikan wawasan ke dalam sistem formal dan informal. Pengamatan, tindakan mengamati proses yang dilakukan, adalah alat yang kuat untuk mengumpulkan informasi tentang sistem saat ini karena memungkinkan analis untuk melihat realitas situasi secara langsung.

Analis sering harus membantu pengguna bisnis berpikir kritis tentang kebutuhan sistem baru mereka. Beberapa strategi sangat membantu. Analisis masalah dan analisis akar masalah adalah dua strategi yang dapat membantu pengguna bisnis dalam memahami masalah dan masalah sistem saat ini yang memerlukan perbaikan. Analisis durasi dan penghilangan aktivitas adalah strategi analisis populer yang membantu tim menemukan proses yang paling membutuhkan desain ulang. Analisis hasil, analisis teknologi, dan benchmarking adalah tiga strategi yang dapat digunakan untuk “memaksa” pengguna bisnis untuk memikirkan proses penyempurnaan bisnis dengan cara-cara baru, atau mungkin menemukan cara yang sepenuhnya baru untuk menyelesaikan proses bisnis.

Terdapat empat simbol yang digunakan pada DFD yaitu: proses, arus data, penyimpanan data, dan entitas luar. Suatu proses adalah kegiatan yang melakukan sesuatu. Setiap proses memiliki nama (frasa kata kerja), deskripsi, dan angka yang menunjukkan keterkaitan dengan proses lain dan proses turunannya. Setiap proses harus memiliki setidaknya satu output dan biasanya memiliki setidaknya satu input. Aliran data adalah potongan data atau objek, memiliki nama (kata benda) dan deskripsi, bermula atau berakhir pada suatu proses (atau keduanya). Penyimpanan data adalah file manual atau file komputer, memiliki nomor pengenal, nama (kata benda), dan setidaknya terdapat satu aliran data input dan satu aliran data output. Entitas luar adalah orang, organisasi, atau sistem di luar ruang lingkup sistem, memiliki nama (kata benda)
dan deskripsi.

Setiap set DFD dimulai dengan diagram konteks, DFD level 0, dan memiliki beberapa DFD level 1, DFD level 2, dan seterusnya. Setiap elemen pada DFD level yang lebih tinggi (misalnya: aliran data, penyimpanan data, dan entitas eksternal) harus muncul pada DFD level yang lebih rendah. Jika tidak, maka antara level tidak akan
seimbang.

DFD dibuat dari use cases atau merujuk pada proses bisnis organisasi. Pertama, tim membangun diagram konteks yang menunjukkan semua entitas luar dan data yang mengalir masuk dan keluar dari sistem. Kedua, tim membuat fragmen (penggalan) DFD untuk setiap kasus penggunaan yang menunjukkan bagaimana kasus penggunaan pertukaran data dengan entitas luar dan penyimpanan data. Dapat juga terlebih dahulu dibuat hierarchy chart untuk memetakan proses-proses secara bertingkat dan lebih rinci dalam sistem. Ketiga, fragmen DFD ini disusun menjadi DFD level 0. Keempat, mengembangkan DFD level 1 dan level-level seterusnya berdasarkan hierarchy chart. Kelima, menggabungkan semua proses yang digambar secara terpisah pada level 1 atau level-level di bawahnya dalam 1 gambar yang utuh. Keenam, memvalidasi set DFD untuk memastikan bahwa DFD sudah lengkap dan benar dan tidak mengandung kesalahan sintaks atau semantik.

Analis jarang membuat DFD secara sekaligus dengan hasil yang sempurna, jadi pembuatan dengan model iterasi per proses yang menghasilkan DFD pada multipage penting dilakukan untuk memastikan jelas dan mudah dibaca, sebelum disatukan secara lengkap dalam satu halaman.

DFD dengan deskripsi teks sederhana yang menyertainya dapat menyajikan prosedur proses yang cukup untuk mendukung kegiatan dalam fase desain (desain fisik sistem). Namun, kadang-kadang terdapat suatu proses yang cukup rumit sehingga harus dituangkan dalam deskripsi proses yang lebih rinci (terutama proses keputusan dan proses perulangan) menggunakan beberapa tools pendukung, termasuk di dalamnya adalah flowchart. System flowchart menggambarkan kerja atau apa yang sedang dikerjakan di dalam sistem atau sub sistem secara menyeluruh dan menjelaskan urutan dari prosedur- prosedur yang ada di dalamnya. Document flowchart menggambarkan arus dari formulir, baik formulir input maupun formulir output termasuk tembusan-tembusannya, sedangkan program flowchart menggambarkan secara rinci langkah-langkah dari proses program komputer.

Penggambaran flowchart menggunakan simbol-simbol yang standar dan mengikuti beberapa aturan dasar seperti: memulai penggambaran dari atas ke bawah dan dari kiri ke kanan, menunjukkan titik awal dan titik akhir penggambaran, serta dalam urutan proses yang logis (urutan yang semestinya).

Teknik berorientasi objek memandang sistem sebagai kumpulan objek mandiri yang mengandung/mengintegrasikan data dan proses. Ide-ide yang mendasari teknik berorientasi objek adalah ide-ide lama yang berevolusi dari pendekatan tradisional. Ide- ide ini sekarang menjadi praktis karena rasio antara biaya (yang murah) dan peningkatan kinerja perangkat keras komputer modern, jika dibandingkan dengan rasio sebaliknya atas kedua hal tersebut di masa lalu. Saat ini, biaya pengembangan perangkat lunak modern terutama terdiri dari biaya yang terkait dengan pengembang perangkat lunak itu sendiri dan bukan biaya untuk perangkat komputernya. Oleh karena itu, pendekatan berorientasi objek untuk mengembangkan sistem informasi sangat menjanjikan dalam mengendalikan biaya ini.

Objek adalah orang, tempat, atau benda yang akan diperoleh informasinya. Setiap objek memiliki atribut yang memberi gambaran tentang objek tersebut dan perilakunya, yang dijelaskan oleh method yang menentukan apa yang dapat dilakukan objek. Objek dikelompokkan ke dalam kelas, yang merupakan kumpulan objek berupa berbagi atribut dan method umum. Kelas-kelas dapat diatur dengan cara hierarkis di mana kelas tingkat
rendah atau subkelas mewarisi atribut dan method dari super kelas di atasnya, untuk mengurangi redundansi dalam pembangunan sistem. Objek berkomunikasi satu sama lain dengan mengirim pesan, yang memicu method. Polimorfisme memungkinkan pesan untuk ditafsirkan secara berbeda oleh berbagai jenis objek. Bentuk komunikasi ini memungkinkan kita untuk memperlakukan objek sebagai kotak hitam dan mengabaikan cara kerja dalam objek. Enkapsulasi dan penyembunyian informasi memungkinkan suatu objek menyembunyikan proses dan data di dalamnya dari objek lain.

Analisis dan desain berorientasi objek menggunakan UML memungkinkan analis untuk menguraikan masalah kompleks menjadi komponen yang lebih kecil dan lebih mudah dikelola melalui serangkaian notasi yang diterima secara umum. UML adalah seperangkat teknik diagram yang menyediakan representasi grafis yang cukup kaya untuk memodelkan proyek pengembangan sistem apapun, mulai dari analisis hingga implementasi. Biasanya, pendekatan analisis dan desain yang paling obyektif saat ini adalah menggunakan UML untuk menggambarkan sistem yang dikembangkan. Pengguna tidak berpikir dalam hal data atau proses, melainkan hanya melihatnya. sebagai kumpulan objek yang berkolaborasi. Dengan demikian, analisis dan desain yang berorientasi objek menggunakan UML memungkinkan analis untuk berinteraksi dengan pengguna, menggunakan objek dari lingkungan pengguna, dan menggantikan serangkaian sistem yang memisahkan proses dan data.

Diagram use case menggambarkan fungsi-fungsi utama suatu sistem dan berbagai jenis pengguna yang berinteraksi dengannya. Diagram terdiri atas actor, yang merupakan orang atau sistem lain yang terkoneksi dan mendapatkan manfaat langsung dari sistem, dan menggunakan case yang mewakili fungsionalitas sistem. Actor dan use case dipisahkan oleh batas sistem dan dihubungkan oleh garis yang mewakili asosiasi. Kadang-kadang actor merupakan jenis actor khusus dari actor yang lebih umum (inheritance). Demikian pula, use case dapat memperluas fungsinya dengan memasukkan perilaku use case lainnya (extend), atau menyertakan fungsinya pada use case lainnya (include).

Membangun diagram use case terdiri dari lima langkah utama yaitu: analis mengidentifikasi use case dari proses bisnis sistem atau activity diagram, menggambar batas sistem, menambahkan use case ke diagram, mengidentifikasi actor, dan akhirnya, menambahkan asosiasi yang sesuai untuk menghubungkan use case dengan actor.

Setelah dibuat, use case sering dapat digunakan untuk mendapatkan kebutuhan fungsional yang lebih rinci untuk sistem baru, sehingga memerlukan penjelasan lebih lanjut, yang sering disebut dengan use case description. Use case description berisi semua informasi yang diperlukan untuk membangun diagram-diagram lain yang mengikutinya. Mengenai yang mana harus dibuat pertama (deskripsi use case atau diagram use case) secara teknis, sebenarnya tidak masalah. Keduanya harus dilakukan untuk menggambarkan kebutuhan yang harus dipenuhi oleh sistem informasi.

Dari sudut pandang pengembangan sistem berorientasi objek, pemodelan proses bisnis telah terbukti bermanfaat. Salah satu kelemahan dari pemodelan proses bisnis adalah kecenderungan memfokuskan proses pengembangan sistem ke arah dekomposisi fungsional. Namun, jika digunakan dengan hati-hati, ini dapat meningkatkan pengembangan sistem berorientasi objek. UML (khususnya UML 2.0) mendukung pemodelan proses menggunakan activity diagram. Activity diagram terdiri dari aktivitas atau tindakan, objek, aliran kontrol, aliran objek, dan satu set node kontrol yang berbeda (awal, aktivitas akhir, aliran akhir, keputusan, penggabungan, percabangan, dan penggabungan). Selanjutnya, swimlane dapat digunakan untuk meningkatkan keterbacaan diagram. Diagram aktivitas sangat berguna untuk membantu analis dalam mengidentifikasi use case yang relevan untuk sistem informasi yang dikembangkan.

Kekuatan activity diagram terletak pada kemampuannya mendukung lingkungan atau situasi yang paralel. Hal ini yang menyebabkan activity diagram menjadi peranti yang bagus untuk menggambarkan aliran kerja dan pemodelan proses. Konsep percabangan dan join memberikan keuntungan ketika menggambarkan algoritma paralel untuk program yang bersamaan.

Model struktural menggambarkan struktur data yang mendasari sistem berorientasi objek. Model struktural memberikan pandangan statis internal dari sistem yang berkembang (misalnya bagaimana objek disusun dalam sistem). Pada titik ini dalam pengembangan sistem, model struktural hanya mewakili model logis dari domain masalah yang mendasarinya. Salah satu tujuan utama dari model struktural adalah untuk menciptakan kosakata yang memungkinkan pengguna dan pengembang untuk berkomunikasi secara efektif tentang masalah yang sedang diselidiki. Model struktural biasanya direpresentasikan oleh class diagram, yang dalam beberapa kasus disempurnakan menggunakan object diagram.

Class diagram menunjukkan kelas dan hubungan (asosiasi) antar kelas yang tetap konstan dalam sistem, seiring waktu. Blok bangunan utama class diagram adalah kelas, yang menyimpan dan mengelola informasi dalam sistem. Kelas memiliki atribut yang menangkap informasi tentang kelas dan tentang operasi, yang merupakan tindakan dapat dilakukan kelas. Ada tiga jenis operasi: konstruktor, kueri, dan pembaruan. Kelas terkait satu sama lain melalui asosiasi, yang memiliki nama dan multiplisitas yang menunjukkan contoh minimum dan maksimum yang berpartisipasi dalam hubungan. Ada kalanya hubungan itu sendiri mengandung informasi, yang disebut class asosiasi. Terdapat tiga tipe dasar hubungan yang biasanya digambarkan pada model struktura (agregasi, generalisasi, dan asosiasi) yang terkandung dalam diagram. Dua asosiasi khusus, agregasi dan generalisasi, digunakan ketika kelas terdiri dari kelas lain atau ketika satu subclass mewarisi sifat dan perilaku dari superclass, masing-masing.

Class diagram dibuat dengan mengidentifikasi kelas pertama, bersama dengan atribut dan operasi mereka. Kemudian hubungan ditarik di antara kelas untuk menunjukkan asosiasi. Selanjutnya, notasi khusus digunakan untuk menggambarkan asosiasi agregasi dan generalisasi.

Dalam sistem dunia nyata yang dapat memiliki begitu banyak kelas, class diagram dapat menjadi terlalu rumit digambarkan. Untuk penyederhanaan diagram, mekanisme pembatasan tampilan dapat digunakan. Tampilan membatasi jumlah informasi yang digambarkan pada diagram. Beberapa pandangan yang bermanfaat adalah: menyembunyikan semua informasi tentang kelas kecuali namanya.

Diagram interaksi (interaction diagram) digunakan untuk menggambarkan bagaimana objek berkolaborasi untuk mendukung use case. Ada dua jenis interaction diagram: sequence diagram dan communication diagram. Kedua diagram menyediakan model dinamis yang menggambarkan interaksi antara objek yang terkait dengan use case. Perbedaan utama antara kedua diagram tersebut adalah sequence diagram berfokus pada pengurutan waktu atau urutan pesan yang dikirim antar objek, sedangkan communication diagram menyoroti aliran kontrol atas sekumpulan objek yang berkolaborasi.

Sequence diagram menggambarkan contoh kelas yang berpartisipasi dalam use case dan pesan yang lewat di antara mereka dari waktu ke waktu. Objek ditempatkan secara horizontal di atas sequence diagram, masing-masing memiliki garis putus-putus, yang disebut garis hidup, secara vertikal di bawahnya. Fokus kontrol, diwakili oleh persegi panjang tipis, ditempatkan di atas garis hidup untuk menunjukkan saat objek mengirim atau menerima pesan. Pesan adalah komunikasi antar objek yang menyampaikan informasi dengan ekspektasi bahwa aktivitas akan terjadi, dan pesan ditampilkan dengan panah yang menghubungkan dua objek yang menunjuk ke arah pesan tersebut disampaikan. Untuk membuat sequence diagram, pertama-tama identifikasi kelas yang berpartisipasi dalam use case, lalu tambahkan pesan yang lewat di antaranya. Terakhir, perlu menambahkan garis hidup dan fokus kontrol. Sequence diagram berguna untuk memahami spesifikasi waktu nyata dan untuk skenario kompleks dari sebuah use case.

Communication diagram menyoroti sifat kolaborasi dari objek yang mendukung use case. Communication diagram pada dasarnya adalah diagram objek yang menggambarkan hubungan dalam pengiriman pesan, bukan hubungan struktural. Untuk membuat communication diagram, pertama-tama identifikasi objek (aktor) dan asosiasi yang menghubungkan objek yang berpartisipasi dalam kolaborasi, lalu letakkan objek dan asosiasi mereka pada diagram. Tambahkan pesan yang lewat di antaranya. Terakhir, lakukan validasi terhadap diagram, untuk menjamin bahwa diagram dengan tepat menggambarkan proses yang mendasarinya.

Behavioral state machine menunjukkan status berbeda yang dilalui oleh kelas tunggal selama fase hidupnya sebagai respons terhadap peristiwa, bersama dengan respons dan tindakan. Status (state) adalah sekumpulan nilai yang mendeskripsikan objek pada titik waktu tertentu, dan mewakili sebuah titik dalam kehidupan suatu objek di mana ia memenuhi beberapa kondisi, melakukan beberapa tindakan, atau menunggu sesuatu terjadi. Peristiwa adalah sesuatu yang terjadi pada titik waktu tertentu dan mengubah nilai yang mendeskripsikan suatu objek, yang pada gilirannya, mengubah status objek. Saat objek bergerak dari satu status ke status lain, mereka mengalami transisi.

Saat menggambar behavioral state machine, seperti diagram perilaku lainnya, hal pertama adalah menetapkan konteks diagram: sistem, subsistem, kumpulan kelas, atau kelas individu. Kemudian, persegi panjang dengan sudut membulat ditempatkan model untuk mewakili berbagai status/keadaan yang akan diambil konteksnya. Selanjutnya, panah ditarik di antara persegi panjang untuk menunjukkan transisi, dan label peristiwa ditulis di atas panah untuk menjelaskan peristiwa yang menyebabkan terjadinya transisi. Biasanya, behavioral state machine digunakan untuk menggambarkan aspek dinamis dari kelas yang kompleks.

Entity Relationship Diagram (ERD) adalah teknik paling umum untuk menggambar model data, cara formal untuk merepresentasikan data yang digunakan dan dibuat oleh sistem bisnis.

Ada tiga elemen dasar dalam bahasa pemodelan data, yang masing-masing diwakili oleh simbol grafik yang berbeda. Entitas adalah blok bangunan dasar untuk model data. Ini dapat berupa orang, tempat, atau benda yang datanya dikumpulkan. Atribut adalah jenis informasi yang ditangkap dari suatu entitas. Atribut yang secara unik dapat mengidentifikasi satu contoh dari suatu entitas disebut pengenal. Relasi, menunjukkan asosiasi antar entitas. Relasi antar entitas memiliki kardinalitas (banyaknya instance dari suatu entitas yang terkait dengan entitas lainnya) dan modalitas (keharusan untuk berpartisipasi dalam sebuah relasi).

Selama fase desain, tim proyek perlu mempertimbangkan tiga pendekatan untuk mengakuisisi sistem baru, yaitu mengembangkan sendiri aplikasi secara khusus (kustom); membeli sistem yang dikemas (paket) dan menyesuaikannya dengan kebutuhan; dan mengandalkan vendor eksternal, pengembang, atau penyedia sistem untuk membangun dan/atau mendukung sistem (outsourcing).

Pengembangan secara kustom memungkinkan pengembang menjadi fleksibel dan kreatif dalam cara mereka memecahkan masalah bisnis, dan membangun pengetahuan teknis dan fungsional dalam organisasi. Namun, banyak organisasi memiliki staf pengembangan yang berkomitmen untuk tetap memenuhi banyak permintaan sistem yang sedang berjalan saat ini, sehingga mereka tidak punya waktu untuk mencurahkan waktu bagi proyek baru yang akan dikembangkan. Jauh lebih efisien untuk membeli program paket, diuji, dan dibuktikan; dan sistem paket dapat dibeli dan dipasang dalam waktu yang relatif singkat, jika dibandingkan dengan pengembangan secara kustom.

Strategi akuisisi ketiga adalah melakukan outsourcing proyek dan membayar vendor eksternal, pengembang, atau penyedia layanan untuk membuat sistem. Ini bisa menjadi alternatif yang baik untuk pengembangan sistem baru. Namun, itu tidak dapat terwujud tanpa biaya. Jika sebuah organisasi memutuskan untuk menyerahkan pembuatan sistem baru di tangan orang lain, organisasi harus berhati-hati dalam hal informasi rahasia dan kehilangan kendali atas pengembangan di masa depan.

Sistem perangkat lunak dapat dibagi menjadi empat fungsi dasar: penyimpanan data, logika akses data (misalnya SQL), logika aplikasi (yang merupakan logika yang didokumentasikan di DFD dan kebutuhan fungsional), dan logika presentasi (antarmuka pengguna).

Ada tiga arsitektur dasar yang menempatkan fungsi dasar perangkat lunak pada perangkat komputer yang berbeda. Dalam arsitektur berbasis server, server melakukan semua fungsi. Dalam arsitektur berbasis klien, komputer klien bertanggung jawab atas logika presentasi, logika aplikasi, dan logika akses data, dengan data yang disimpan di server file. Dalam arsitektur klien-server, klien bertanggung jawab atas logika presentasi dan server bertanggung jawab atas logika akses data dan penyimpanan data. Dalam arsitektur thin client-server, server menjalankan logika aplikasi, sedangkan dalam arsitektur thick client-server, logika aplikasi dibagi antara server dan klien. Dalam arsitektur klien-server dua tingkat, terdapat dua kelompok komputer: satu klien dan satu set server. Dalam arsitektur klien-server tiga tingkat, terdapat tiga kelompok komputer: klien, satu set server aplikasi, dan satu set server database.

Virtualisasi dan cloud computing adalah dua jenis perkembangan teknologi yang memunculkan opsi-opsi baru arsitektur sistem.

Pembuatan desain arsitektur merujuk pada kebutuhan nonfungsional. Kebutuhan operasional menentukan lingkungan operasi di mana sistem harus bekerja dan bagaimana hal tersebut dapat berubah dari waktu ke waktu (yaitu lingkungan teknis, integrasi sistem, portabilitas, dan pemeliharaan). Kebutuhan kinerja berfokus pada masalah kinerja seperti kecepatan sistem, kapasitas, serta ketersediaan dan keandalan. Kebutuhan keamanan berupaya melindungi sistem informasi dari gangguan dan kehilangan data (misalnya nilai sistem, kontrol akses, enkripsi dan autentikasi, dan pengendalian virus). Kebutuhan budaya dan politik adalah kebutuhan yang terkait dengan wilayah tempat sistem akan digunakan (misalnya multibahasa, kustomisasi, norma yang tidak tertulis, dan hukum).

Elemen utama dari desain antarmuka pengguna adalah tata letak layar, formulir, dan laporan, yang biasanya digambarkan dengan bentuk persegi panjang dengan area atas untuk navigasi, area tengah untuk input dan output, dan area status di bagian bawah. Desain harus membantu pengguna menyadari konten dan konteks, baik di antara berbagai bagian sistem saat mereka menavigasi maupun dalam satu formulir atau laporan. Semua antarmuka harus menyenangkan secara estetika dan perlu menyertakan area kosong yang cukup, menggunakan warna dengan hati-hati, dan font konsisten. Kebanyakan antarmuka harus dirancang untuk mendukung pengguna pemula serta pengguna berpengalaman. Konsistensi dalam desain (baik di dalam sistem dan di seluruh sistem lain yang digunakan oleh pengguna) penting untuk setiap kontrol navigasi, terminologi, dan tata letak formulir dan laporan. Semua antarmuka harus berusaha meminimalkan upaya pengguna, misalnya, dengan tidak memerlukan lebih dari tiga klik dari menu utama untuk melakukan sebuah tindakan.

Prosedur pengembangan desain antarmuka: pertama, analis mengembangkan skenario penggunaan yang menggambarkan pola tindakan yang umum digunakan yang akan dilakukan pengguna. Kedua, analis merancang struktur antarmuka melalui ISD berdasarkan DFD. Ketiga, analis mendefinisikan standar antarmuka, yang terdiri atas objek, tindakan, dan ikon. Elemen-elemen ini digabungkan dengan desain template antarmuka dasar untuk setiap bagian utama dari sistem. Keempat, analis membuat dan menguji prototipe antarmuka, serta mengevaluasinya untuk mengidentifikasi peningkatan mengarah ke prototipe antarmuka yang lebih sempurna.

Desain navigasi ditujukan untuk membuat sistem sesederhana mungkin dengan mencegah pengguna dari membuat kesalahan. Bahasa perintah dan manipulasi langsung digunakan dalam navigasi, tetapi pendekatan yang paling umum adalah menu (dalam berbagai bentuk). Pesan kesalahan, pesan konfirmasi, pesan pengakuan, pesan penundaan, dan pesan bantuan adalah jenis pesan yang umum dalam menavigasi.

Tujuan dari desain masukan adalah untuk secara sederhana dan mudah menangkap informasi yang akurat untuk sistem, biasanya dengan menggunakan pemrosesan online atau batch, menangkap data pada sumbernya, dan meminimalkan penekanan tombol. Desain masukan mencakup desain layar masukan dan semua formulir pracetak yang digunakan untuk mengumpulkan data sebelum dimasukkan ke dalam sistem informasi. Ada banyak jenis masukan, seperti text field, number field, check box, radio button, on-screen list box, drop-down list box, dan slider. Sebagian besar masukan divalidasi dengan beberapa kombinasi pemeriksaan kelengkapan, pemeriksaan format, pemeriksaan rentang, pemeriksaan digit, pemeriksaan konsistensi, dan pemeriksaan database.

Tujuan desain keluaran adalah untuk menyajikan informasi kepada pengguna sehingga mereka dapat memahaminya secara akurat dengan sedikit usaha, biasanya dengan memahami bagaimana laporan akan digunakan dan merancangnya untuk meminimalkan informasi yang berlebihan dan bias. Desain keluaran berarti mendesain layar dan laporan di media lain, seperti kertas dan Web. Ada banyak jenis laporan, seperti laporan detail, laporan ringkasan, laporan pengecualian, dan grafik.