Analisis Terstruktur Tradisional RUP

Document Sample
Analisis Terstruktur Tradisional RUP Powered By Docstoc
					Analisis Terstruktur Tradisional
    Dijelaskan oleh WW Royce,, 1970 IEEE
     WESCON, Mengelola pengembangan
     sistem perangkat lunak besar.
    Dekomposisi dalam hal Fungsi dan Data
    Hanya tersedia pada tingkat file modularity
       o lih. Bahasa C yang statis kata kunci (==

         "lingkup file")
    Data tidak dikemas:
       o Global yang Lingkup

       o Berkas Lingkup

       o Fungsi Ruang Lingkup (otomatis, lokal)

    Air Terjun Metode Analisis dan Desain



             Metode Waterfall
    Analisis Persyaratan
      o   Analisis Spesifikasi
            Spesifikasi desain
               Coding dari Spesifikasi Desain

                   Pengujian Unit

                   Sistem Pengujian

                   UAT Pengujian

                   Kapal ini (????)


   Mengukur batang adalah
    dalam bentuk dokumen resmi
    (spesifikasi).


    Asumsi Proses Air Terjun
   Persyaratan dikenal di depan sebelum desain
   Persyaratan jarang sekali berubah
   Pengguna tahu apa yang mereka inginkan,
    dan jarang membutuhkan visualisasi
   Desain dapat dilakukan dalam ruang yang
    murni abstrak, atau percobaan jarang
    menyebabkan kesalahan
   Teknologi ini semua akan cocok baik ke
    tempatnya ketika saatnya tiba (kiamat)
   Sistem ini tidak begitu kompleks. (Gambar
    adalah untuk pecundang)



Analisis Terstruktur Masalah
   Reuse rumit karena Data bertebaran di
    seluruh fungsi yang berbeda banyak
      o Reuse biasanya didefinisikan sebagai

        menggunakan kembali kode dan
        diimplementasikan melalui memotong
        dan menyisipkan kode yang sama di
        banyak tempat. Apa yang terjadi ketika
        perubahan logika?
           coding perubahan perlu dibuat di

            beberapa tempat berbeda
           mengubah fungsi sering berubah API

            yang memecah fungsi lain
            tergantung pada bahwa API
            perubahan tipe data harus dilakukan
             setiap kali mereka digunakan di
             seluruh aplikasi



Keterbatasan Proses Air Terjun
   Teori Big Bang Pengiriman
   Bukti dari konsep ini diturunkan ke akhir
    dari siklus tunggal yang panjang. Sebelum
    integrasi akhir, dokumen hanya telah
    diproduksi.
   Akhir penyebaran risiko mengintai
    menyembunyikan banyak:
      o teknologi (baik, saya pikir mereka akan

        bekerja sama ...)
      o konseptual (baik, saya pikir itulah yang

        mereka inginkan ...)
      o personil (mengambil begitu lama,

        setengah tim kiri)
     o   Pengguna tidak bisa melihat sesuatu
         yang nyata sampai akhir, dan mereka
         selalu membencinya.
     o   Pengujian sistem tidak terlibat sampai
         nanti dalam proses.



     Rational Unified Process
   RUP merupakan metode mengelola
    Pengembangan Perangkat Lunak OO
   Hal ini dapat dilihat sebagai Kerangka
    Software Development yang extensible dan
    fitur:
       o Pembangunan Iteratif

       o Persyaratan Manajemen

       o Komponen Berbasis Arsitektur Visi

       o Visual Pemodelan Sistem

       o Manajemen Mutu

       o Manajemen Perubahan Kontrol
                 RUP Fitur
   Repositori online Informasi
    Proses dan Deskripsi dalam
    format HTML
   Template untuk semua
    artefak utama, termasuk:
     o   RequisitePro template (persyaratan
         pelacakan)
     o   Firman Template untuk Kasus
         Penggunaan
     o   Proyek Template untuk Manajemen
         Proyek
   Proses Manual yang
    menjelaskan proses-proses
    kunci
                     Fase


    Sebuah Proses Pembangunan
             Iteratif ...
   Mengakui realitas perubahan persyaratan
      o Caspers Jones penelitian pada 8000

         proyek
            40% dari persyaratan akhir tiba

             setelah tahap analisis, setelah
             pembangunan sudah mulai
   Meningkatkan mitigasi risiko dini, dengan
    memecah sistem menjadi mini-proyek dan
    berfokus pada elemen berisiko pertama
   Memungkinkan Anda untuk "merencanakan
    desain, sedikit sedikit, dan kode sedikit"
   Mendorong semua peserta, termasuk
    penguji, integrator, dan penulis teknis untuk
    terlibat sebelumnya pada
   Memungkinkan proses itu sendiri untuk
    memodulasi dengan setiap iterasi,
    memungkinkan Anda untuk memperbaiki
    kesalahan lebih cepat dan dimasukkan ke
    dalam pelajaran praktek belajar pada iterasi
    sebelumnya
   Fokus pada arsitektur komponen, belum
    final penyebaran big bang



Sebuah Proses Pengembangan
       Incremental ...
   Memungkinkan untuk perangkat lunak
    berkembang, tidak diproduksi dalam satu
    upaya besar
   Memungkinkan perangkat lunak untuk
    memperbaiki, dengan memberikan waktu
    yang cukup untuk proses evolusi itu sendiri
   Angkatan perhatian pada stabilitas, karena
    hanya landasan yang stabil dapat
    mendukung beberapa tambahan
   Memungkinkan sistem (subset kecil dari itu)
    untuk benar-benar berjalan lebih cepat
    dibandingkan dengan proses lainnya
   Memungkinkan kemajuan interim untuk
    terus melalui mematikan fungsi
   Memungkinkan untuk pengelolaan risiko,
    dengan mengekspos masalah sebelumnya di
    dalam proses pembangunan



Tujuan dan Fitur Setiap Iterasi
   Tujuan utama dari setiap iterasi adalah untuk
    perlahan-lahan chip jauh di risiko yang
    dihadapi proyek, yaitu:
      o kinerja risiko

      o integrasi risiko (vendor yang berbeda,

        peralatan, dll)
      o konseptual risiko (menemukan

        kelemahan analisis dan desain)
   Lakukan "miniwaterfall" proyek yang
    berakhir dengan pengiriman sesuatu yang
    nyata dalam kode, tersedia untuk
    pengawasan oleh pihak yang
    berkepentingan, yang menghasilkan validasi
    atau koreksi
   Setiap iterasi risiko-driven
   Hasil dari sebuah iterasi tunggal adalah
    kenaikan yang - perbaikan tambahan dari
    sistem, menghasilkan suatu pendekatan
    evolusi



           Manajemen Risiko
   Identifikasi resiko
   Pengembangan iteratif /
    incremental
   Prototipe atau proyek
    percontohan
     o   Booch itu "Tiger Team"
   Awal pengujian dan
    penyebaran sebagai lawan
    untuk pengujian akhir dalam
    metode tradisional


        Fase Pengembangan
   Fase Inception
   Elaborasi Tahap
   Tahap Konstruksi
   Tahap Transisi


             Fase Inception
   Tujuan utama adalah mendapatkan
    dukungan dari semua pihak yang tertarik
   Menangkap persyaratan awal
   Manfaat Analisis Biaya
   Awal Analisis Risiko
   Proyek ruang lingkup definisi
   Mendefinisikan arsitektur kandidat
   Pengembangan prototipe pakai
   Gunakan Kasus Model awal (10% - 20%
    selesai)
   Pertama lulus pada Domain Model



             Elaborasi Tahap
   Persyaratan Analisis dan Capture
     o Gunakan Analisis Kasus

            Gunakan Kasus (80% ditulis dan terakhir pada
             akhir dari fase)
            Gunakan Kasus Model (80% dilakukan)
            Skenario
                Urutan dan Diagram Kolaborasi

                Kelas, Kegiatan, Komponen, Diagram

                  Negara
     o   Daftar kata (sehingga pengguna dan
         pengembang dapat berbicara kosa kata
         umum)
     o   Domain Model
             untuk memahami masalah: kebutuhan sistem saat
              mereka ada dalam konteks dari domain masalah
     o   Rencana Penilaian Risiko direvisi
     o   Arsitektur Dokumen



              Tahap Konstruksi
   Fokus adalah pada implementasi dari desain:
     o kumulatif peningkatan fungsi

     o lebih besar kedalaman implementasi

       (bertopik fleshed keluar)
     o stabilitas yang lebih besar mulai muncul

     o menerapkan semua rincian, tidak hanya

       nilai arsitektur pusat
     o analisis berlanjut, tetapi desain dan

       mendominasi coding
             Tahap Transisi
   Fase transisi terdiri dari transfer sistem
    untuk komunitas pengguna
   Ini termasuk manufaktur, pengiriman,
    instalasi, pelatihan, dukungan teknis dan
    pemeliharaan
   Tim pengembangan mulai menyusut
   Kontrol pindah ke tim pemeliharaan
   Alpha, Beta, dan rilis akhir
   Pembaruan perangkat lunak
   Integrasi dengan sistem yang ada (warisan,
    versi yang ada, dll)



       Elaborasi Tahap Detail
   Gunakan Analisis Kasus
     o Cari dan memahami 80% dari kasus

       penggunaan arsitektur signifikan dan
       aktor
     o Prototipe Antarmuka Pengguna
     o  Prioritaskan Gunakan Kasus dalam
        Model Use Case
      o Detail Gunakan Kasus arsitektur

        signifikan (menulis dan review mereka)
   Siapkan Domain Model arsitektur yang
    signifikan kelas, dan mengidentifikasi
    tanggung jawab mereka dan interface pusat
    (Lihat Kelas Berpartisipasi)



     Gunakan Analisis Kasus
   Apakah Use Case?
     o Sebuah urutan tindakan sistem

       melakukan yang menghasilkan hasil
       yang berharga untuk aktor tertentu.
   Apa Aktor itu?
     o Seorang pengguna atau sistem luar yang

       berinteraksi dengan sistem yang
       dirancang dalam rangka untuk
       mendapatkan beberapa nilai dari
       interaksi yang
   Kasus Gunakan menjelaskan skenario yang
    menggambarkan interaksi antara pengguna
    sistem dan sistem itu sendiri.
   Kasus Gunakan menjelaskan APA sistem
    akan melakukan, tetapi tidak pernah CARA
    itu akan dilakukan.



    Apa dalam Kasus Gunakan?
   Tentukan negara awal dan prasyarat yang
    menyertainya
   Tentukan ketika Use Case dimulai
   Menentukan urutan kegiatan dalam Arus
    Utama Acara
   Mendefinisikan Arus Alternatif Kegiatan
   Mendefinisikan Arus Luar Biasa Acara
   Tentukan Kondisi Pos apapun dan keadaan
    akhir
   Sebutkan masalah desain apapun sebagai
    lampiran
    Mendampingi diagram: Negara, Aktivitas,
     Diagram Urutan
    Lihat Objek Berpartisipasi (Kelas Model
     Analisis yang relevan)
    Logis Lihat: Sebuah Lihat dari Aktor yang
     terlibat dengan Kasus Penggunaan, dan
     Kasus Gunakan apapun yang digunakan atau
     diperpanjang oleh Use Case



Kasus Gunakan Jelaskan Fungsi
       tidak Formulir
    Kasus Gunakan menjelaskan APA sistem akan melakukan,
     tetapi tidak pernah CARA itu akan dilakukan.
    Kasus Gunakan adalah Analisis Produk, Desain Produk
     tidak.




Kasus Gunakan Jelaskan Fungsi
       tidak Formulir
   Kasus Gunakan menjelaskan
    APA sistem harus dilakukan,
    tetapi tidak pernah CARA itu
    akan dilakukan
   Kasus penggunaan adalah
    Analisis produk, bukan
    produk desain


     Manfaat Gunakan Kasus
   Kasus penggunaan adalah kendaraan utama
    untuk kebutuhan menangkap dalam RUP
   Kasus penggunaan dijelaskan menggunakan
    bahasa pelanggan (bahasa domain yang
    didefinisikan dalam glossary)
   Kasus Gunakan menyediakan proses
    pengiriman kontrak (RUP adalah Gunakan
    Kasus Didorong)
   Kasus penggunaan menyediakan mekanisme
    komunikasi mudah dimengerti
   Ketika persyaratan ditelusuri, mereka
    membuat sulit untuk persyaratan untuk jatuh
    melalui celah-celah
   Kasus penggunaan memberikan ringkasan
    singkat dari apa sistem yang harus dilakukan
    pada abstrak (biaya modifikasi rendah)
    tingkat.



      Kesulitan dengan Kasus
           Penggunaan
   Sebagai dekomposisi fungsional, seringkali
    sulit untuk membuat transisi dari deskripsi
    fungsional untuk menolak deskripsi untuk
    desain kelas
   Kembali pada tingkat kelas dapat terhalang
    oleh masing-masing pengembang
    "mengambil Use Case dan berjalan dengan
    itu". Karena UCS tidak berbicara tentang
    kelas-kelas, pengembang sering angin di
    ruang hampa selama analisis objek, dan
    sering dapat angin melakukan hal-hal cara
    mereka sendiri, sehingga sulit kembali
   Kasus menggunakan make menyatakan
    kebutuhan non-fungsional sulit (di mana
    Anda mengatakan bahwa X harus
    mengeksekusi di Y / detik?)
   Fungsi pengujian sangat mudah, tetapi unit
    pengujian implementasi tertentu dan
    kebutuhan non-fungsional tidak jelas



Gunakan Kasus Model Survei
   Kasus Gunakan Survei Model adalah untuk
    menggambarkan, dalam bentuk grafik, alam
    semesta Kasus Gunakan bahwa sistem ini
    dikontrak untuk memberikan.
   Setiap Use Case dalam sistem muncul dalam
    Survei dengan deskripsi singkat tentang
    fungsi utamanya.
     o   Peserta:
           Domain Expert

           Arsitek

           Analis / Designer (Gunakan Kasus

            penulis)
           Pengujian Insinyur




Contoh Use Case Model Survei


             Model Analisis
   Dalam Analisis, kami menganalisis dan
    menyempurnakan persyaratan yang
    dijelaskan dalam Kasus Gunakan untuk
    mencapai pandangan yang lebih tepat dari
    persyaratan, tanpa kewalahan dengan rincian
   Sekali lagi, Model Analisis masih berfokus
    pada APA yang akan kita lakukan, bukan
    BAGAIMANA kita akan melakukannya
    (Model Desain). Tapi apa yang akan kita
    lakukan adalah diambil dari sudut pandang
    pengembang, bukan dari sudut pandang
    pelanggan
   Sedangkan Kasus Gunakan dijelaskan dalam
    bahasa pelanggan, Model Analisis
    dijelaskan dalam bahasa pengembang:
     o   Batas Kelas
     o   Entitas Kelas
     o   Kelas Kontrol




Mengapa menghabiskan waktu
pada Model Analisis, mengapa
 tidak hanya "wajah tebing"?
   Dengan melakukan analisis, desainer murah
    bisa datang ke pemahaman yang lebih baik
    dari persyaratan sistem
   Dengan memberikan gambaran seperti
    abstrak, pendatang baru dapat memahami
    arsitektur keseluruhan sistem efisien, dari
    'pandangan mata burung ", tanpa harus
    terjebak dengan rincian pelaksanaan.
   Analisis Model adalah abstraksi sederhana
    dari apa sistem yang akan dilakukan dari
    sudut pandang pengembang. Dengan
    "bahasa pengembang berbicara",
    pemahaman ditingkatkan dan abstrak,
    kesederhanaan dicapai
   Namun demikian, biaya pemeliharaan AM
    melalui konstruksi ditimbang terhadap nilai
    dari memiliki itu semua bersama.



               Batas Kelas
   Batas kelas digunakan dalam Model
    Analisis Model interaksi antara sistem dan
    aktor nya (pengguna atau sistem eksternal)
   Batas kelas sering diimplementasikan dalam
    beberapa format GUI (dialog, widget,
    kacang, dll)
   Batas kelas sering dapat abstraksi API
    eksternal (dalam kasus seorang aktor sistem
    eksternal)
   Batas setiap kelas harus dikaitkan dengan
    setidaknya satu pelaku:



              Entitas Kelas
   Kelas entitas yang digunakan
    dalam Model Analisis model
    informasi persisten
   Seringkali, kelas entitas
    diciptakan dari obyek dalam
    model obyek bisnis atau
    model domain penuh
             Kelas Kontrol
   Et Cetera Besar
   Kontrol kelas abstraksi model yang
    mengkoordinasikan, urutan, bertransaksi,
    dan sebaliknya kontrol objek lain
   Dalam mekanisme Smalltalk MVC, ini
    adalah pengendali
   Kelas kontrol sering dikemas interaksi
    antara objek lain, karena mereka menangani
    dan mengkoordinasikan tindakan dan aliran
    kontrol.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:66
posted:10/10/2011
language:Indonesian
pages:25
Description: Analisis Terstruktur Tradisional RUP