Choco World

#college #binusian #task #jakarta

UML #2 Diagram (cont.) 1

February10

UML 2 DIAGRAM

Dian Andriani

1601278293

 

 

Deployment Diagram

 

  1. A.     Pengertian Deployment Diagram

Sebuah deployment diagram menunjukkan perangkat keras sistem dan perangkat lunak dalam perangkat keras tersebut.

Diagram Deployment berguna ketika solusi perangkat lunak Anda dikerahkan di beberapa mesin denganmasing-masing memiliki konfigurasi yang unik.

Deployment Diagram mewakili pandangan pengembangan sistem sehingga akan hanya ada satu deployment diagram untuk satu sistem. deployment diagram terdiri dari node-node merupakan perangkat keras fisik yang digunakan untuk menyebarkan aplikasi. deployment diagram banyak di gunakan oleh System Engineer.

Component Diagram

  1. A.    Pengertian Component Diagram 

Diagram yang menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.

posted under PSI | No Comments »

UML #2 (cont.)

February9

UML 2 DIAGRAM

Dian Andriani

1601278293

 

Construction the Analysis  Use-Case Model

  1. A.      Sistem analisis use case

use case yang mendokumentasikan interaksi antara pengguna sistem dan sistem. Hal ini sangat rinci dalam menggambarkan apa yang dibutuhkan tetapi bebas dari sebagian besar rincian pelaksanaan dan kendala .

®     Mengidentifikasi , menentukan , dan mendokumentasikan aktor baru .

®     Mengidentifikasi , menentukan , dan mendokumentasikan kasus penggunaan baru .

®     Identifikasi kemungkinan reuse .

®     Memperbaiki penggunaan – kasus model diagram ( jika perlu ) .

®     Narasi analisis sistem dokumen use case .

Modeling Use-Case Activities

  1. A.      Activity diagram – diagram yang dapat digunakan untuk grafis menggambarkan aliran proses bisnis , langkah-langkah dari use case , atau logika perilaku obyek (metode ) .
  2. B.      Activity Diagram Notations

a)      Initial Node

lingkaran padat mewakili awal dari proses

b)      Actions

bulat persegi panjang yang mewakili langkah-langkah individu, Urutan tindakan , Membentuk aktivitas total.  Ditunjukkan oleh diagram .

c)       Flow 

panah pada diagram menunjukkan perkembangan melalui tindakan , Sebagian besar arus tidak perlu kata-kata untuk mengidentifikasi mereka kecuali keluar dari keputusan .

d)      Decision

bentuk berlian dengan satu aliran masuk dan dua atau lebih mengalir keluar . Arus keluar ditandai untuk menunjukkan kondisi .

e)      Merge

bentuk berlian dengan beberapa arus masuk dan satu aliran keluar . Ini menggabungkan aliran sebelumnya dipisahkan oleh keputusan . Pengolahan berlanjut dengan salah satu aliran yang masuk ke penggabungan .

f)       Fork

Bar hitam dengan satu aliran masuk dan dua atau lebih arus keluar. Tindakan on  Arus paralel  bawah dapat terjadi dalam urutan apapun  Atau  bersamaan .

g)      Join

bar hitam dengan dua atau lebih arus masuk dan satu aliran keluar , mencatat akhir pemrosesan konkuren . Semua tindakan yang masuk ke join harus diselesaikan sebelum proses berlanjut .

h)      Activity final

lingkaran padat di dalam lingkaran berongga mewakili akhir proses .

i)        Subactivity indicator

simbol menyapu dalam aksi menunjukkan bahwa tindakan ini pecah di diagram aktivitas lain yang terpisah . Ini akan membantu Anda menjaga diagram aktivitas dari menjadi terlalu rumit .

j)        Connector 

Sebuah surat dalam lingkaran memberi Anda alat lain untuk mengelola kompleksitas . Aliran masuk ke konektor melompat ke aliran keluar dari konektor dengan huruf yang cocok .

  1. C.      Guidelines for Constructing  Activity Diagrams
  • Mulailah dengan satu node awal sebagai titik awal .
  • Tambahkan partisi jika relevan dengan analisis Anda .
  • Tambahkan aksi untuk setiap langkah utama dari use case ( atau setiap langkah besar seorang aktor memulai .
  • Tambahkan arus dari setiap tindakan untuk tindakan lain , titik keputusan , atau titik akhir . Untuk presisi maksimum makna , setiap tindakan harus memiliki hanya satu aliran masuk dan satu aliran keluar dengan semua garpu, bergabung , keputusan , dan gabungan ditunjukkan secara eksplisit .
  • Tambahkan keputusan di mana arus menyimpang dengan rute bergantian . Pastikan untuk membawa mereka kembali bersama-sama dengan gabungan .
  • Tambahkan garpu dan bergabung di mana kegiatan yang dilakukan secara paralel .
  • Diakhiri dengan notasi tunggal untuk akhir kegiatan .

Sequence Diagrams

  1. A.      Sequence Diagrams

Diagram urutan System – suatu diagram yang menggambarkan interaksi antara aktor dan sistem untuk skenario use case , membantu mengidentifikasi pesan tingkat tinggi yang masuk dan keluar sistem

  1. B.      Notasi

a)      Aktor

aktor memulai dari kasus digunakan akan ditampilkan dengan simbol aktor use case .

b)      System

box menunjukkan sistem sebagai ” kotak hitam” atau secara keseluruhan . The titik dua (:) adalah notasi diagram urutan standar untuk menunjukkan berjalan ” contoh ” dari sistem.

c)       Lifelines

garis vertikal putus-putus memanjang ke bawah dari aktor dan sistem simbol , yang menunjukkan kehidupan urutan .

d)      Aktivasi bar

bar terbenam di atas jalur hidup menunjukkan periode waktu ketika peserta aktif dalam interaksi .

e)      Input messages

panah horisontal dari aktor untuk sistem menunjukkan input pesan . UML konvensi untuk pesan adalah untuk memulai kata pertama dengan huruf kecil dan menambahkan kata-kata tambahan huruf besar awal dan tidak ada ruang . Dalam kurung meliputi parameter , berikut sama konvensi penamaan dan dipisahkan dengan koma .

f)       Output messages

panah horisontal dari sistem ke aktor ditampilkan sebagai garis putus-putus . Karena mereka adalah bentuk web , laporan , e – mail , dll pesan-pesan ini tidak perlu menggunakan notasi standar.

g)      Receiver Aktor

Aktor-aktor lain atau sistem eksternal yang menerima pesan dari sistem dapat dimasukkan.

h)      Frame

Kotak dapat melampirkan satu atau lebih pesan untuk membagi off fragmen dari urutan. Ini dapat menunjukkan loop , fragmen alternatif , atau opsional ( opt ) langkah . Untuk fragmen opsional kondisi ditunjukkan dalam tanda kurung siku menunjukkan kondisi di mana langkah-langkah yang akan dilakukan .

Communication  Diagrams

  1. A.      Communication  Diagrams

Diagram komunikasi memiliki banyak kesamaan dengan diagram urutan . Perbedaan yang paling signifikan antara dua jenis diagram interaksi adalah diagram komunikasi secara eksplisit menunjukkan hubungan antara jalur hidup yang berpartisipasi dalam sebuah kolaborasi . Tidak seperti diagram urutan tidak ada dimensi waktu yang jelas dan jalur hidup yang hanya diwakili oleh empat persegi panjang.

  1. B.      Cara Membuat Communication Diagram
  • Ambil dari Sequence diagram
  • Kemudian urutkan setiap event dengan diberi no
  • Kemudian hubungkan antar class dan tuliskan setiap hubungan yang sudah diberikan nomor

 

posted under PSI | No Comments »

UML #2 Diagram

February9

UML 2 Diagram

Dian Andriani

1601278293

  1. A.      Object Class 

Satu set objek yang berbagi atribut umum dan perilaku . Kadang-kadang disebut sebagai sebuah kelas .

  1. B.      Generalisasi / spesialisasi

Teknik dimana atribut dan perilaku umum untuk beberapa jenis kelas objek dikelompokkan ( atau disarikan ) ke dalam kelas mereka sendiri , yang disebut supertype .

  1. C.      Supertype

Entitas yang berisi atribut dan perilaku yang umum untuk satu atau lebih subtipe kelas . Juga disebut sebagai kelas abstrak atau orang tua .

  1. D.      Subtipe

Kelas objek yang mewarisi atribut dan perilaku dari kelas supertype dan mungkin berisi atribut dan perilaku unik untuk itu lainnya . Juga disebut sebagai kelas anak dan , jika ada di tingkat terendah dari hirarki warisan , sebagai kelas beton .

  1. E.       Hubungan obyek / kelas

Asosiasi bisnis alami yang ada antara satu atau lebih obyek dan kelas .

  1. F.       Multiplicity

Minimum dan jumlah maksimum kejadian dari satu objek / kelas untuk kejadian tunggal dari terkait objek / kelas .

  1. G.     Aggregation

Hubungan di mana satu lebih besar ” seluruh” kelas berisi satu atau lebih kecil ” bagian ” kelas . Sebaliknya, ” bagian ” kelas yang lebih kecil merupakan bagian dari ” seluruh ” kelas yang lebih besar

  1. H.     Composition

Hubungan agregasi di mana ” seluruh ” bertanggung jawab untuk penciptaan dan penghancuran yang Jika “seluruh ” itu mati , “bagian ” akan mati dengan itu ” bagian. ” .

USE CASE DIAGRAM

  • Notasi diagram untuk use case

–          Tongkat sederhana merupakan actor

–          Tangan aktor menunjukkan akses sistem direct

–          Gunakan kasus itu sendiri dilambangkan oleh oval

–          Menghubungkan garis sesuai aktor untuk menggunakan kasus

–          Aktor juga mungkin antarmuka sistem lainnya

–          Dapat diwakili dengan tongkat angka atau persegi panjang

a)       Object Classes

b)      Generalization/Specialization

c)       Object/Class Relationships

d)      Multiplicity

e)       Aggregation

f)        Composition

g)       Contoh pembuatan actor pada Usecase Diagram

ini sebenernya ada gambarnya tapi ga bisa di paste 🙁

posted under PSI | No Comments »

UML

February9

Dian Andriani

1601278293

Summary PSI pertemuan 7

 

Introduction to Object Modeling

Object-oriented analysis (OOA) digunakan untuk mempelajari benda-benda yang ada untuk melihat apakah mereka dapat digunakan kembali atau diadaptasi untuk penggunaan baru, mendefinisikan objek baru atau dimodifikasi yang akan dikombinasikan dengan obyek yang sudah ada ke dalam aplikasi komputasi bisnis yang berguna.

Object modeling suatu teknik untuk mengidentifikasi objek dalam lingkungan sistem dan hubungan antara objek tersebut.

Introduction to the UML

Unified Modeling Language (UML) seperangkat konvensi pemodelan yang digunakan untuk menentukan atau menggambarkan sebuah sistem perangkat lunak dalam hal objek . UML tidak meresepkan metode untuk mengembangkan sistem – hanya notasi yang sekarang diterima secara luas sebagai standar untuk pemodelan objek .

Objects & Attributes

Objects sesuatu yang atau mampu menjadi dilihat, disentuh , atau dirasakan , dan tentang pengguna menyimpan data dan perilaku asosiasi yang .

®     Person, place, thing, or event

®     Employee, customer, instructor, student

®     Warehouse, office, building, room

®     Product, vehicle, computer, videotape

Attribute data yang mewakili karakteristik yang menarik tentang suatu objek .

Objects & Object Instances

Object instance setiap orang tertentu , tempat, benda , atau peristiwa , serta nilai-nilai untuk atribut objek.

Behavior & Encapsulation

Behavior  sekumpulan hal-hal yang objek dapat melakukan itu sesuai dengan fungsi yang bekerja pada objek data (atau atribut ) . Di kalangan berorientasi objek , perilaku obyek sering disebut sebagai metode , operasi , atau jasa .

Encapsulation kemasan beberapa item bersama-sama ke dalam satu unit .

Object Classes satu set objek yang berbagi atribut umum dan perilaku . Kadang-kadang disebut sebagai sebuah kelas .

Inheritance metode konsep dimana dan / atau atribut yang didefinisikan dalam kelas objek dapat diwariskan atau digunakan kembali oleh objek kelas lain.

Generalization/Specialization, Supertype, and Subtype

Generalization/specialization teknik dimana atribut dan perilaku umum untuk beberapa jenis objek kelas dikelompokkan ( atau disarikan ) ke dalam kelas mereka sendiri , yang disebut supertype .

Supertype  entitas yang berisi atribut dan perilaku yang umum untuk satu atau lebih subtipe kelas . Juga disebut sebagai kelas abstrak atau orang tua .

Subtypekelas obyek yang mewarisi atribut dan perilaku dari kelas supertype dan mungkin berisi atribut lainnya dan perilaku unik untuk itu . Juga disebut sebagai kelas anak dan , jika ada pada tingkat terendah dari hirarki warisan , sebagai concrete class.

Messages komunikasi yang terjadi ketika salah satu objek memanggil metode lain objek ( perilaku ) untuk meminta informasi atau beberapa tindakan.

Polymorphism

Polymorphism konsep bahwa objek yang berbeda dapat merespon pesan yang sama dengan cara yang berbeda .

Override teknik dimana subclass ( subtipe ) menggunakan atribut atau perilaku sendiri bukan sebuah atribut atau perilaku yang diturunkan dari kelas ( supertype ) .

posted under PSI | No Comments »

Logical Model

February9

Dian Andriani 1601278293

Summary PSI pertemuan 5

  1. 1.       Model – sebuah representasi bergambar realitas .

Sama seperti gambar bernilai seribu kata , kebanyakan model adalah representasi bergambar realitas.

  • Logical Model – sebuah representasi bergambar nonteknis yang menggambarkan apa sistem ini atau tidak . Sinonim atau model penting , model konseptual , dan model bisnis .
  • Physical model – sebuah representasi bergambar teknis yang menggambarkan apa sistem ini atau tidak dan bagaimana sistem tersebut diimplementasikan . Sinonim model implementasi dan model yang teknis.
  1. 2.       Mengapa Sistem Logical Model?

®     Logical Model menghapus bias yang merupakan hasil dari cara sistem saat diimplementasikan , atau cara bahwa setiap satu orang berpikir sistem akan diimplementasikan . ?

®     Logical Model mengurangi risiko kebutuhan bisnis yang hilang karena kita terlalu sibuk dengan hasil teknis.

®     Logical Model memungkinkan kita untuk berkomunikasi dengan pengguna akhir di non-teknis atau bahasa teknis kurang .

  1. 3.       Proses pemodelan – teknik yang digunakan untuk mengatur dan mendokumentasikan proses suatu sistem .
  • Aliran data melalui proses
  • logika
  • Kebijakan
  • prosedur
  1. 4.       Data flow diagram ( DFD ) – model proses yang digunakan untuk menggambarkan aliran data melalui sistem dan kerja atau pengolahan yang dilakukan oleh sistem. Sinonim grafik gelembung , grafik transformasi, dan model proses . DFD juga telah menjadi alat populer untuk desain ulang proses bisnis .
  1. 5.       Perbedaan Antara DFD Dan Flowchart

v  Proses pada DFD dapat beroperasi secara paralel ( at-the – sama -time )

v  DFD menunjukkan aliran data melalui sistem

v  Proses pada DFD dapat memiliki waktu yang berbeda secara dramatis ( harian, mingguan , on demand )

  • Proses pada flowchart mengeksekusi satu per satu
  • Flowchart menunjukkan aliran kontrol ( urutan dan pemindahan kontrol ) ?
  • Proses pada flowchart adalah bagian dari satu program dengan waktu yang konsisten
  1. 6.       Eksternal agent – orang luar , satuan , sistem , atau organisasi yang berinteraksi dengan sistem . Juga disebut suatu entitas eksternal . Eksternal agent mendefinisikan ” batas ” atau  Lingkup dari sistem yang dimodelkan .
  2. 7.       Data Store – Menyimpan data – data yang disimpan dimaksudkan untuk digunakan nanti . Sinonim berkas dan basis data .
  3. 8.       Proses – pekerjaan yang dilakukan oleh sistem dalam menanggapi arus data yang masuk atau kondisi . Sinonim adalah mengubah.
  4. 9.       proses dekomposisi

®     Dekomposisi – proses membobol sistem menjadi sub – komponen . Setiap tingkat abstraksi mengungkapkan lebih atau kurang detail.

®     Diagram dekomposisi – alat yang digunakan untuk menggambarkan dekomposisi sistem . Juga disebut bagan hirarki .

  1. 10.   Jenis Logical process
  • Fungsi – serangkaian kegiatan terkait dan berkelanjutan bisnis . Sebuah fungsi tidak memiliki awal atau akhir .
  • Event – Unit logis dari pekerjaan yang harus diselesaikan secara keseluruhan . Kadang-kadang disebut transaksi . Dipicu oleh masukan diskrit dan selesai ketika proses telah merespon dengan output yang sesuai . Fungsi terdiri dari proses yang merespon kejadian .
  • Elementary process – diskrit , kegiatan rinci atau tugas yang diperlukan untuk menyelesaikan respon terhadap suatu peristiwa . Juga disebut sebagai proses primitif . Tingkat terendah detail digambarkan dalam model proses .
  1. 11.   Data Flows & Control Flows
  • Data flow – data yang input ke atau output dari sebuah proses .
  • Control Flows  (sebuah aliran data) adalah data dalam gerak. Sebuah aliran data juga dapat digunakan untuk mewakili pembuatan , pembacaan , penghapusan , atau memperbarui data dalam file atau database ( disebut menyimpan data ) .
  • Composite data flow – aliran data yang terdiri dari arus data lainnya .
  • Control flow – suatu kondisi atau nondata peristiwa yang memicu proses. Digunakan hemat pada DFD .
  1. 12.   Aturan untuk Arus data
    1. Sebuah aliran data harus tidak pernah pergi disebutkan namanya .
    2. Dalam pemodelan logis , nama aliran data harus menggambarkan aliran data tanpa menjelaskan pelaksanaan
    3. Semua aliran data harus dimulai dan / atau berakhir pada suatu proses .
posted under PSI | No Comments »

Causes And Effect Analysis

February8

Dian Andriani 1601278293

Summary PSI pertemuan 4

CAUSES AND EFFECT ANALYSIS

Suatu teknik untuk menentukkan penyebab dan efek dari suatu permasalahan.

Effect yaitu gejala dari suatu masalah yang lebih berakar yang harus di analisi sebab dan akibatnya sampai sebab dan akibat tsb tidak menghasilkan masalah yang lain.

CONTEXT DIAGRAM

Sebuah model diagram yang menggambarkan suatu petunjuk bagaimana sistem berinteraksi dengan dunia sekitarnya dan menetapkan secara umum sistem input dan output.

Contoh tabel Causes and Effect Analysis

/data/data/com.infraware.PolarisOfficeStdForTablet/files/.polaris_temp/fImage1452403.jpeg

posted under PSI | No Comments »

Define System Analyst

February8

Summary pertemuan 3

Dian Andriani

1601278293

03 PBY

 

Define System Analisis

  1. 1.      Contoh dari masalah
  1. 2.      Key Term

1)      Cause and effect analysis

suatu teknik di mana masalah yang akan dipelajari untuk menentukan penyebab dan efek.
Dalam prakteknya, efek dapat berupa  gejala dari masalah yang lebih berakar dan  harus dianalisis apa sebab dan akibat sampai sebab dan akibat tidak menghasilkan gejala masalah lain.

2)      Context Diagram

sebuah model bergambar yang menunjukkan bagaimana sistem berinteraksi dengan dunia di sekitarnya dan menetapkan secara umum sistem input dan output.

  1. 3.      Contoh dari masalah analisis
  1. 4.      Pengembangan Sistem Perlu Diperbaiki, karena
    1. Adanya permasalahan yang timbul di system yang lama (ketidakberesan dan pertumbuhan organisasi ),
    2. Untuk meraih kesempatan,
    3. Adanya instruksi .
  1. 5.      Peningkatan Yang Diharapkan Dalam Pengembangan Sistem

®    Performance

®    Information

®    Economy

®    Control

®    Efficiency

®    Services

posted under PSI | No Comments »

The Capability Maturity Model (CMM)

February8

hai teman teman seperjuangan !

this is my 1st post in this blog setelah beberapa lama mempelajari cara buat ngepost haf banget kan

sekedar mau berbagi materi aja nih untuk para saudara saudara rakyat indonesia pembaca setia *apasih* haha

ini dulu tugas summary jaman semester 3 coba di baca aja ya siapa tau bermanfaat, amin Ya Rabb

Summary PSI pertemuan 2

Dian Andriani

1601278293

03PBY

®    The Capability Maturity Model (CMM) adalah framework untuk mengukur tingkat “kematangan” pengembangan sistem informasi dan manajemen proses dan produk suatu organisasi. CMM terdiri dari lima tingkat perkembangan.

®    Capability Maturity Model disingkat CMM adalah suatu model kematangan kemampuan (kapabilitas) proses yang dapat membantu pendefinisian dan pemahaman proses-proses suatu organisasi. CMM dibagi menjadi lima tingkatan ”kematangan” yang mengukur kualitas dari proses pengembangan sistem dan perangkat lunak organisasi (setiap level menjadi pra-syarat bagi level sesudahnya).

      Level 1 – Initial

Hampir setiap organisasi memulai dari level yang seringkali disebut anarki atau kekacauan (chaos) ini. Pengembangan system tidak menggunakan proses yang terstruktur dan tiap developer menggunakan alat dan metodenya masing-masing. Pada tahap ini umumnya proses tidak dapat diprediksi, tidak berulang, sering mengalami krisis, over-budget, dan gagal mencapai target waktu.

      Level 2 – Repeatable

Proses dan praktek manajemen proyek pengembangan system telah dirancang untuk melacak biaya proyek, jadwal, dan kegunaan dari sistem. Pada tahap ini, fokus ditekankan pada manajemen proyeknya, bukan pada pengembangan sistem (pengembangan sistem bervariasi untuk tiap proyek). Kesuksesan dan kegagalan masih bergantung pada kemampuan dan pengalaman dari tim yang mengerjakan proyek. Walaupun begitu, telah terdapat usaha untuk mengulang keberhasilan proyek sebelumnya, dan manajemen proyek yang efektif pun akhirnya menjadi pondasi bagi standardisasi proses level berikutnya.

      Level 3 – Defined

Proses pengembangan sistem standar (umumnya disebut metodologi) telah dimiliki atau dikembangkan dan telah digunakan secara terintegrasi melalui unit sistem atau pelayanan informasi organisasi. Sebagai hasilnya, hasil dari setiap proyek menjadi lebih konsisten, dokumentasi serta penyampaian yang berkualitas tinggi, dan proses menjadi lebih stabil, mampu diprediksi (predictable), dan berulang (repeatable). Meskipun butuh kerja keras untuk mencapai tahap ini, level ketiga seringkali menjadi syarat dari pemerintah (AS) untuk meningkatkan kinerja perusahaan.

      Level 4 – Managed

Telah memiliki tujuan yang terukur untuk kualitas dan produktivitas. Ukuran mendetail mengenai proses pengembangan proses standar dan kualitas produk telah dikumpulkan secara rutin dan disimpan dalam database. Pada tahap ini manajemen lebih proaktif dalam melihat masalah pengembangan sistem. Jadi walaupun proyek menemui masalah atau isu yang tidak diperkirakan, proses masih akan dapat disesuaikan berdasarkan efek dari kondisi yang mampu diprediksi dan terukur.

      Level 5 – Optimized

Proses pengembangan sistem terstandarisasi secara kontinu dimonitor dan ditingkatkan berdasarkan ukuran dan analisa data di level 4. Setiap pembelajaran yang ada disebarluaskan pada seluruh bagian organisasi dengan penekanan pada penurunan ketidakefisienandalam proses pengembangan sistem ketika menjaga kestabilan kualitas. Sebagai kesimpulan, organisasi telah menjadikan peningkatan proses pengembangan sistem yang kontinu bagian dari dirinya.

®    System Life Cycle VS Methodology

  • System life cycle, seumur hidup dari suatu sistem informasi menjadi dua tahap, (1) pengembangan sistem dan (2) sistem operasi dan pemeliharaan.
  • System Development Methodology, pendekatan formal untuk proses pengembangan sistem, proses pengembangan standar yang mendefinisikan (seperti dalam CMM Level 3) serangkaian kegiatan, metode, praktik terbaik, penyerahan, dan alat-alat otomatis yang pengembang sistem dan manajer proyek yang digunakan untuk mengembangkan dan terus meningkatkan sistem informasi dan perangkat lunak.

®    Prinsip Pengembangan Sistem

ü  Mendapatkan pengguna sistem yang terlibat.

ü  Gunakan pendekatan pemecahan masalah.

ü  Menetapkan tahapan dan kegiatan.

ü  Dokumen melalui pengembangan.

ü  Menetapkan standar.

ü  Mengelola proses dan proyek

ü  Meratakan sistem sebagai investasi modal.

ü  Jangan takut untuk membatalkan atau merevisi lingkup.

ü  Membagi dan menaklukkan.

ü  Mendesain sistem untuk pertumbuhan dan perubahan.

 

®    Process Management

kegiatan yang berkelanjutan yang dokumen, mengelola, mengawasi penggunaan, dan meningkatkan memilih metodologi organisasi (“proses”) untuk pengembangan sistem. Proses manajemen berkaitan dengan tahapan, kegiatan, penyerahan, dan standar kualitas harus diterapkan secara konsisten untuk seluruh proyek.

®    Project Management

proses melingkupi, merencanakan, menyediakan staf, mengorganisasi, mengarahkan, dan mengendalikan sebuah proyek untuk mengembangkan sistem informasi dengan biaya minimal, dalam jangka waktu tertentu, dan dengan kualitas yang dapat diterima.

®    Meratakan Sistem Informasi sebagai Investasi Modal

  1. 1.      Cost-effectiveness

Hasil yang diperoleh dari keseimbangan antara biaya seumur hidup mengembangkan, memelihara, dan mengoperasikan sistem informasi dan manfaat yang diperoleh dari sistem tersebut. Efektivitas biaya diukur dengan analisis biaya-manfaat.

  1. 2.      Strategic information systems plan

Rencana strategis formal (3-5 tahun) untuk membangun dan meningkatkan infrastruktur teknologi informasi dan aplikasi sistem informasi yang menggunakan infrastruktur itu.

  1. 3.      Strategic enterprise plan

Rencana strategis formal (3-5 tahun) untuk seluruh bisnis yang mendefinisikan misi, visi, tujuan, strategi, benchmark, dan ukuran kemajuan dan prestasi. Biasanya, rencana strategis perusahaan dilengkapi dengan rencana unit bisnis strategis yang menentukan bagaimana setiap unit bisnis akan memberikan kontribusi pada rencana perusahaan. Informasi rencana sistem adalah salah satu rencana unit-tingkat.

®    Cancel or Revise Scope

ü  Creeping commitment

Strategi di mana kelayakan dan risiko terus dievaluasi melalui sebuah proyek. Anggaran proyek dan tenggat waktu yang disesuaikan.

ü  Risk management

Proses mengidentifikasi, mengevaluasi, dan mengendalikan apa yang mungkin salah dalam proyek sebelum menjadi ancaman bagi keberhasilan penyelesaian proyek atau implementasi sistem informasi. Manajemen risiko berkendara dengan analisis risiko atau penilaian.

®    Where Do Systems Development Projects Come From?

1)      Problems

situasi yang tidak diinginkan yang mencegah organisasi dari sepenuhnya mencapai tujuan, sasaran, dan / atau tujuan.

2)      Opportunity

kesempatan untuk meningkatkan organisasi bahkan tanpa adanya suatu masalah yang diidentifikasi.

3)      Directive

persyaratan baru yang dikenakan oleh manajemen, pemerintah, atau pengaruh eksternal.

®    The PIECES Problem-Solving Framework

  • P                the need to improve performance
  •  I                the need to improve information (and data)
  • E               the need to improve economics, control costs, or increase profits
  • C               the need to improve control or security
  • E               the need to improve efficiency of people and processes
  • S                the need to improve service to customers, suppliers, partners, employees

®    Scope Definition Phase

  • Problem statement
  • Constraint
  • Scope creep
  • Statement of work

®    Logical Design Phase

  • Logical design
  • System model
  • Analysis paralysis

®    Decision Analysis Phase

  • Technical feasibility
  • Operational feasibility
  • Economic feasibility
  • Schedule feasibility
  • Risk feasibility

®    Construct and test system components

  • Software
  • Purchased
  • Custom-built
  • Databases
  • User and System Interfaces
  • Hardware
  • Networks

®    Cross Life-Cycle Activities

  • Fact-finding
  • Documentation and presentation
    • Documentation
    • Presentation
    • Repository
    • Feasibility analysis
    • Process and project management

®    Model-Driven Development Strategy

  • Process modeling
  • Data modeling
  • Object modeling
  • Advantages
    • Persyaratan seringkali lebih menyeluruh
    • Mudah untuk menganalisis secara alternatif
    • Spesifikasi desain sering lebih stabil dan fleksibel
    • Sistem dapat dibangun lebih tepat pertama kalinya
    • Disadvantages
      • Memakan waktu
      • Model hanya sebagai baik sebagai pemahaman pengguna ‘persyaratan
      • Mengurangi peran pengguna karena gambar tidak software
      • Bisa tidak fleksibel

®    Rapid Application Development (RAD)

suatu strategi pengembangan sistem yang menekankan kecepatan pengembangan melalui keterlibatan pengguna yang ekstensif dalam cepat, berulang, dan konstruksi tambahan dari serangkaian berfungsi prototipe dari sebuah sistem yang akhirnya berkembang menjadi sistem final.

  • Prototype,  sebuah skala kecil, perwakilan, atau model kerja kebutuhan pengguna atau desain yang diusulkan untuk sistem informasi.
  • Time Box, pengenaan periode non-diperpanjang waktu, biasanya 60-90 hari, dimana yang pertama (atau berikutnya) versi sistem harus diserahkan ke operasi.
  • Advantage
    • Kebutuhan pengguna sering tidak menentu dan tidak tepat
    • Mendorong pengguna aktif dan partisipasi manajemen
    • Proyek mendapatkan visibilitas yang lebih tinggi dan dukungan
    • Stakeholder melihat solusi yang bekerja lebih cepat
    • Kesalahan terdeteksi sebelumnya
    • Pengujian dan pelatihan yang alami oleh-produk
    • Lebih proses alami karena perubahan diharapkan
    • Disadvantage
      • Dapat mendorong “kode, melaksanakan, memperbaiki” mentalitas
      • Dapat memecahkan masalah yang salah karena analisis masalah adalah disingkat
      • Dapat mencegah analis dari mempertimbangkan alternatif
      • Stakeholder enggan untuk membuang prototipe
      • Penekanan pada kecepatan dapat berakibat buruk kualitas

®    Commercial Application Package

aplikasi perangkat lunak yang dapat dibeli dan disesuaikan untuk memenuhi kebutuhan bisnis dari sejumlah besar organisasi atau industri tertentu. Sinonim adalah off-the-shelf (COTS) sistem komersial.

  • Request for proposal (RFP)dokumen formal yang mengkomunikasikan bisnis, teknis, dan persyaratan dukungan untuk paket aplikasi perangkat lunak untuk vendor yang mungkin ingin bersaing untuk penjualan paket dan layanan aplikasi.
  • Request for quotation (RFQ) dokumen formal yang mengkomunikasikan bisnis, teknis, dan persyaratan dukungan untuk aplikasi paket perangkat lunak untuk satu vendor yang telah ditentukan sebagai mampu menyediakan bahwa paket dan layanan aplikasi.
  • Gap analysis – perbandingan persyaratan teknis untuk paket aplikasi komersial terhadap kemampuan dan fitur dari paket aplikasi komersial spesifik untuk menentukan persyaratan yang tidak dapat dipenuhi bisnis.
  • Advantage
    • Sistem biasanya dilaksanakan lebih cepat
    • Menghindari staf yang dibutuhkan untuk mengembangkan solusi di rumah
    • Umumnya lebih murah
    • Penjual bertanggung jawab untuk perbaikan dan koreksi
    • Banyak fungsi bisnis yang lebih mirip daripada yang berbeda untuk semua bisnis dalam suatu industri tertentu
    • Disadvantage
      • Bergantung pada kelangsungan hidup jangka panjang vendor
      • Jarang mencerminkan solusi ideal
      • Seringkali resistensi terhadap perubahan proses bisnis untuk beradaptasi dengan software

®    Computer-Assisted Software Engineering (CASE)

perangkat lunak otomatis yang mendukung gambar dan analisis model sistem dan spesifikasi yang terkait. Beberapa alat CASE juga menyediakan kemampuan generasi prototyping dan kode.

  • Case Repository,  sistem database pengembang ‘di mana pengembang dapat menyimpan model sistem, deskripsi rinci dan spesifikasi, dan produk lainnya dari pengembangan sistem. Sinonim: kamus dan ensiklopedia.
  •  Forward Engineering, CASE kemampuan alat yang dapat menghasilkan perangkat lunak awal atau kode database secara langsung dari sistem.
  • Reverse Engineering, CASE kemampuan alat yang dapat menghasilkan model sistem awal dari perangkat lunak atau kode database.
posted under PSI | No Comments »