STAKE HOLDER PENGEMBANGAN SISTEM INFORMASI ANALISIS DAN PERANCANGAN SISTEM INFORMASI STMIK AMIKOM YOGYAKARTA 2011.

Slides:



Advertisements
Presentasi serupa
Pengenalan Analisis & Perancangan Sistem
Advertisements

Pengembangan Sistem Informasi
CHAPTER 7 Pengembangan Sistem
Tahapan information engineering
PERTEMUAN II Disampaikan oleh: Ruli Supriati, S.Kom
ANALISIS DAN PERANCANGAN SISTEM
METODE REKAYASA PERANGKAT LUNAK
Analisis dan Perancangan Sistem Informasi
Managing Software Requirements (manajemen kebutuhan perangkat lunak)
RENCANA PENGEMBANGAN PERANGKAT LUNAK (RPPL)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 Review Software Engineering.
© 2007 by Prentice Hall Management Information Systems, 10/e Raymond McLeod and George Schell 1 Management Information Systems, 10/e Raymond McLeod and.
WaterfallPrototyping RAD Incremental Prototyping Pendekatan SDLC.
ANALISA PERANCANGAN SISTEM
Manajemen Proyek Perangkat Lunak (MPPL)
Stake Holder dalam Sistem Informasi
Rekayasa Perangkat Lunak (Software Engineering)
Phase III Rapid Prototyping and Demonstration Prototype
1 INTRODUCTION Pertemuan 1 s.d 2 Matakuliah: A0554/Analisa dan Perancangan Sistem Informasi Akuntansi Tahun: 2006.
SIKLUS HIDUP SISTEM INFORMASI
Management Information Systems, 10/e
Pengelolaan Proyek Sistem Informasi
Software Engineering Process
Review Rekayasa Perangkat Lunak
proses PERANGKAT LUNAK
Analisis dan Desain Sistem
ANALISA SISTEM ( ANALYSIS SYSTEM )
System Development Life Cycle (SDLC)
Pert. 16. Menyimak lingkungan IS/IT saat ini
Notasi Object Oriented System
Anna dara andriana., M.kom
Chapter 2: Rekayasa Web We define it this way:
MANPRO-M13: MUTU PROYEK SISTEM
Pengembangan Sistem Pertemuan 3.
Stake Holder dalam Sistem Informasi
Perancangan Basis Data
Software Engineering Rekayasa Perangkat Lunak
STAKEHOLDER DALAM SISTEM INFORMASI
Pertemuan <<18>> << Penemuan Fakta(01) >>
Pengantar Teknologi Informasi (Teori)
ADBO (Analisa Desain Berorientasi Obyek)
SDLC (System Development Life Cycle)
Anna dara andriana., M.kom
REKAYASA PERANGKAT LUNAK
Review Rekayasa Perangkat Lunak
Phase III Rapid Prototyping and Demonstration Prototype
BAB II STAKEHOLDER DALAM SISTEM INFORMASI
Manajemen Proyek Pengantar
Membangun Sistem Informasi ERP
Dasar-Dasar Sistem Informasi
Membangun Sistem Informasi ERP
Rekayasa Perangkat Lunak Part-5
Review Rekayasa Perangkat Lunak
Review Rekayasa Perangkat Lunak
Iconix Process Doug Rosenberg.
Pengembangan Sistem Informasi
Rekayasa Perangkat Lunak
SOFTWARE ENGGINERING Model Model Siklus Rekayasa Perangkat Lunak
ANALISA SISTEM ( ANALYSIS SYSTEM )
Pengembangan Sistem Kuliah : APSI Oleh : Iwan Abadi, Ir., M.M.
Business Modeling By: U. Abd. Rohim, MT
Pengembangan Sistem Informasi
Sistem Pendukung Keputusan Roni Andarsyah, ST., M.Kom Lecture Series.
Analisis Perencangan Sistem Informasi
Pertemuan 8 RPL Oleh : Syukriya al-Asyik S.Kom
ANALISA SISTEM ( ANALYSIS SYSTEM )
Pertemuan 1 Pengantar Pengembangan Sistem
Software PROCESS & Method
TIM RPL Program Studi Teknik Informatika
Building Information Systems
Transcript presentasi:

STAKE HOLDER PENGEMBANGAN SISTEM INFORMASI ANALISIS DAN PERANCANGAN SISTEM INFORMASI STMIK AMIKOM YOGYAKARTA 2011

Good News  Peluang kerja di bidang Teknologi Informasi dan Komunikasi (TIK) pada tahun-tahun mendatang, diperkirakan akan melonjak drastis, seiring kemajuan teknologi di berbagai bidang yang membutuhkan adaptasi pasaran kerja. Kebutuhan tenaga IT di bidang industri software baik di dalam maupun luar negeri juga terus naik tajam. Tahun 2015 saja, misalnya, kebutuhan tenaga IT di luar negeri mencapai 3,3 juta lapangan kerja. Sedangkan di dalam negeri, kebutuhan tenaga IT diperkirakan mencapai orang. Kebutuhan tenaga profesional IT di dalam negeri itu didasarkan pada proyeksi pertumbuhan industri tahun 2010 yang memiliki target produksi sekitar US $, dengan asumsi produktifitas per – orang.  Sumber :

Stake Holder  Stake Holder adalah orang yang memiliki kepentingan tertentu pada suatu kegiatan bisnis. Di dalam pengembangan sebuah sistem informasi

Kategori Stake Holder: whitten et al membagi stake holder pada pengembanga n sistem informasi menjadi :  Manager SI  System analyst  Programmer  End user  Supporting end user  Business manager  Teknisi SI lainnya

Dasar pemikiran pembagian versi Whitten :  Pembagian ini didasarkan pada perbedaan karakteristik pekerjaan yang mereka lakukan untuk menyelesaikan suatu proyek sistem informasi.  Perbedaan ini bukan berarti salah satu memiliki peran yang lebih penting tetapi bersama-sama saling mendukung penyelesaian suatu proyek system informasi.

MANAJER SISTEM INFORMASI  Manager SI berperan dalam mengalokasikan dan mengawasi proyek pengembangan sistem daripada terlibat langsung dalam proses pengembangan sistem.  Pada departemen IT berskala besar, manager IT biasanya terbagi lagi menjadi manager-manager dengan tanggung-jawab lebih spesifik, misalnya :  Manager untuk keseluruhan departemen SI biasa disebut sebagai Chief Information Officer dan berada dibawah president atau direktur perusahaan.  Manager-manager lain yang memimpin divisi-divisi pada departemen IT misalnya manager pengembangan SI, Manager operasi, manager programmer SI dan lain-lain

Tugas MANAJER SISTEM INFORMASI  Sebagai pemimpin, manager tidak harus terlibat langsung pada proses pembuatan sistem informasi.  Untuk memonitor pekerjaan dari stake holder yang lain manager secara efektif berkomunikasi dengan stake holder yang lain melalui pemain kunci yaitu system analis.

SYSTEM ANALIST SISTEM ANALIS :  Sistem analis adalah profesi yang bagus untuk memulai karir dibidang IT. Pekerjaan sebagai system analis menawarkan tantangan kerja yang dinamis dan variatif.  Sistem analis merupakan individu kunci dalam proses pengembangan sistem. Sistem analis mempelajari masalah dan kebutuhan dari organisasi untuk menentukan bagaimana orang, data, proses, komunikasi dan teknologi informasi dapat meningkatkan pencapaian bisnis.

TUGAS SISTEM ANALIS :  Seorang sistem analis juga merupakan orang yang paling bertanggung jawab pada proses analisis dan perancangan sistem informasi.  Tugas utama dari seorang sistem analis adalah menentukan bentuk sistem yang akan dibangun nantinya. Keputusan ini tidak mudah kesalahan menentukan format sistem yang akan dibangun akan berakibat pada gagalnya proyek yang dikerjakan.

KEAHLIAN YANG DIBUTUHKAN Keahlian analisis  untuk memahami organisasi yang memerlukan sistem informasi yang akan dibangun.  memetakan permasalahan yang dihadapi oleh perusahaan klien yang bisa diselesaikan dengan sistem informasi dan yang tidak.  Kemampuan analisis juga diperlukan untuk memecahkan masalah yang telah ditemukan lagi menggunakan teknologi berbasis komputer.

KEAHLIAN YANG DIBUTUHKAN Keahlian Teknis  menentukan bentuk sistem terkomputerisasi seperti apa yang dapat menyelesaikan masalah  dibutuhkan adalah penguasaan teknologi software maupun hardware.  mengenal dan menguasai software maupun hardware terbaru, mengetahui keunggulan maupun batasan dari teknologi- teknologi tersebut.  membantu analis dalam memilih teknologi yang tepat untuk keperluan klien yang sangat spesifik.  Keahlian teknis bisa diperoleh dari pendidikan formal, pelatihan khusus maupun jam terbang yang panjang dalam mengembangkan proyek Sistem Informasi.

KEAHLIAN YANG DIBUTUHKAN : Keahlian Managerial  Sistem analis bertanggung jawab mengatur sumber daya yang di bawah kendalinya seperti programmer dan teknisi.  Pengalokasian tugas yang tepat sangat berpengaruh pada cepat lambatnya penyelesaian proyek.  Sistem analis juga harus mampu memprediksi resiko dan perubahan factor-faktor eksternal seperti kenaikan harga hardware, perubahan kebutuhan klien, munculnya produk pesaing dan lain-lain.

KEAHLIAN YANG DIBUTUHKAN : Interpersonal skills  Sistem analis adalah pihak yang berkomunikasi aktif keluar dengan klien maupun ke dalam dengan stake holder yang lain.  untuk menjaring informasi yang akurat tentang masalah yang ada pada klien.  Komunikasi juga diperlukan untuk mempresentasikan pekerjaan dari analis maupun stake holder yang lain yang perlu diketahui oleh user.  Dengan menjalin komunikasi secara efektif dengan stake holder yang lain, perkembangan proyek selalu dapat diketahui, perubahan-perubahan terbaru bisa dimonitor dan direspons.

POSISI SISTEM ANALIS DIANTARA STAKE HOLDER LAINNYA: SYSTEM ANALYST SEBAGAI FASILITATOR

PROGRAMMER Individu yang menjadi personil kunci dan menjalankan “dirty work” dalam pengembangan proyek  Tugas utama dari Programmer adalah mengubah Spesifikasi sistem yang diberikan oleh sistem analis ke dalam instruksi yang bisa dijalankan oleh komputer.  Langkah mengubah ke dalam kode yang bisa dijalankan komputer ini disebut coding.  Coding merupakan pekerjaan yang membutuhkan waktu dan ketelitian yang besar. Porsi waktu terbesar dari pengembangan sistem biasanya dihabiskan disini.  Deadline yang pendek dan jam kerja yang ketat merupakan tantangan tersendiri untuk programmer.

Business manager  Kelompok lain dalam pengembangan sistem adalah manajer bisnis misalnya kepala bagian atau kepala departemen atau eksekutif perusahaan.  Manajer-manajer ini penting karena mereka memiliki kekuatan pendanaan pengembangan sistem dan mengalokasikan sumber daya yang diperlukan untuk keberhasilan proyek.

Teknisi Lainnya  Masih banyak lagi teknisi lain yang terlibat dalam pengembangan sistem. Salah satunya adalah database administrator.  Untuk perusahaan besar dengan skala data yang besar, data didalam database harus dijamin terorganisasi dengan baik, sehingga ketika aplikasi lain memerlukan transfer data dari database, bisa dilayani dengan cepat.  Database administrator juga bertanggungjawab pada keamanan data baik dari serangan virus maupun pihak luar yang tidak punya hak akses untuk melihat dan mengubah data.

Teknisi lainnya  Teknisi lainnya adalah teknisi jaringan dan teknisi hardware. Perangkat lunak tidak akan berjalan dengan baik tanpa dukungan hardware yang bekerja dengan baik.  Transfer data juga tidak bisa dilakukan jika media media transfernya mengalami permasalahan. Untuk itu perlu personil khusus yang ditugaskan merawat hardware maupun infrastruktur jaringannya.

Systems Analysis and Design in a Changing World, 4th Edition 20 The Systems Development Lifecycle (SDLC)  Systems development life cycle (SDLC)  Provides overall framework for managing systems development process  Two main approaches to SDLC  Predictive approach – assumes project can be planned out in advance  Adaptive approach – more flexible, assumes project cannot be planned out in advance  All projects use some variation of SDLC

Systems Analysis and Design in a Changing World, 4th Edition 21 Choosing the Predictive vs. Adaptive Approach to the SDLC (Figure 2-1)

Systems Analysis and Design in a Changing World, 4th Edition 22 Traditional Predictive Approach to the SDLC  Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project  Analysis – understand business needs and processing requirements  Design – define solution system based on requirements and analysis decisions  Implementation – construct, test, train users, and install new system  Support – keep system running and improve

Systems Analysis and Design in a Changing World, 4th Edition 23 Information System Development Phases

Systems Analysis and Design in a Changing World, 4th Edition 24 SDLC and Problem Solving  Similar to problem-solving approach in Chapter 1  Organization recognizes problem (project planning)  Project team investigates, understands problem and solution requirements (analysis)  Solution is specified in detail (design)  System that solves problem is built and installed (implementation)  System used, maintained, and enhanced to continue to provide intended benefits (support)

Systems Analysis and Design in a Changing World, 4th Edition 25 “Waterfall” Approach to the SDLC

Systems Analysis and Design in a Changing World, 4th Edition 26 Modified Waterfall Approach with Overlapping Phases (Figure 2-5)

Systems Analysis and Design in a Changing World, 4th Edition 27 Newer Adaptive Approaches to the SDLC  Based on spiral model  Project cycles through development activities over and over until project is complete  Prototype created by end of each cycle  Focuses on mitigating risk  Iteration – Work activities are repeated  Each iteration refines previous result  Approach assumes no one gets it right the first time  There are a series of mini projects for each iteration

Systems Analysis and Design in a Changing World, 4th Edition 28 The Spiral Life Cycle Model (Figure 2-6)

Systems Analysis and Design in a Changing World, 4th Edition 29 Iteration of System Development Activities (Figure 2-7)

Systems Analysis and Design in a Changing World, 4th Edition 30 Methodologies and Models  Methodologies  Comprehensive guidelines to follow for completing every SDLC activity  Collection of models, tools, and techniques  Models  Representation of an important aspect of real world, but not same as real thing  Abstraction used to separate out aspect  Diagrams and charts  Project planning and budgeting aids

Systems Analysis and Design in a Changing World, 4th Edition 31 Some Models Used in System Development

Systems Analysis and Design in a Changing World, 4th Edition 32 Tools and Techniques  Tools  Software support that helps create models or other required project components  Range from simple drawing programs to complex CASE tools to project management software  Techniques  Collection of guidelines that help analysts complete a system development activity or task  Can be step-by-step instructions or just general advice

Systems Analysis and Design in a Changing World, 4th Edition 33 Some Tools Used in System Development

Systems Analysis and Design in a Changing World, 4th Edition 34 Some Techniques Used in System Development

Systems Analysis and Design in a Changing World, 4th Edition 35 Relationships Among Components of a Methodology

Systems Analysis and Design in a Changing World, 4th Edition 36 Two Approaches to System Development  Traditional approach  Also called structured system development  Structured analysis and design technique (SADT)  Includes information engineering (IE)  Object-oriented approach  Also called OOA, OOD, and OOP  Views information system as collection of interacting objects that work together to accomplish tasks

Systems Analysis and Design in a Changing World, 4th Edition 37 Traditional Approach  Structured programming  Improves computer program quality  Allows other programmers to easily read and modify code  Each program module has one beginning and one ending  Three programming constructs (sequence, decision, repetition)

Systems Analysis and Design in a Changing World, 4th Edition 38 Three Structured Programming Constructs

Systems Analysis and Design in a Changing World, 4th Edition 39 Top-Down or Modular Programming

Systems Analysis and Design in a Changing World, 4th Edition 40 Structure Chart Created Using Structured Design Technique

Systems Analysis and Design in a Changing World, 4th Edition 41 Structured Analysis  Define what system needs to do (processing requirements)  Define data system needs to store and use (data requirements)  Define inputs and outputs  Define how functions work together to accomplish tasks  Data flow diagrams (DFD) and entity relationship diagrams (ERD) show results of structured analysis

Systems Analysis and Design in a Changing World, 4th Edition 42 Data Flow Diagram (DFD) Created Using Structured Analysis Technique (Figure 2-15)

Systems Analysis and Design in a Changing World, 4th Edition 43 Entity-Relationship Diagram (ERD) Created Using Structured Analysis Technique

Systems Analysis and Design in a Changing World, 4th Edition 44 Structured Analysis Leads to Structured Design and Structured Programming (Figure 2-17)

Systems Analysis and Design in a Changing World, 4th Edition 45 Object-Oriented Approach to Systems

Systems Analysis and Design in a Changing World, 4th Edition 46 Object-Oriented Approach ( continued )  Object-oriented analysis (OOA)  Defines types of objects users deal with  Shows use cases are required to complete tasks  Object-oriented design (OOD)  Defines object types needed to communicate with people and devices in system  Shows how objects interact to complete tasks  Refines each type of object for implementation with specific language of environment  Object-oriented programming (OOP)  Writing statements in programming language to define what each type of object does

Systems Analysis and Design in a Changing World, 4th Edition 47 Class Diagram Created During OO Analysis

Systems Analysis and Design in a Changing World, 4th Edition 48 Life Cycles with Different Names for Phases (Figure 2-20)

Systems Analysis and Design in a Changing World, 4th Edition 49 Current Trends in Development  More adaptive approaches  The Unified Process (UP)  Extreme Programming (XP)  Agile Modeling  Scrum  Details on each in Chapter 16

Systems Analysis and Design in a Changing World, 4th Edition 50 The Unified Process (UP)  Object-oriented development approach  Offered by IBM / Rational  Booch, Rumbaugh, Jacobson  Unified Modeling Language (UML) used primarily for modeling  UML can be used with any OO methodology  UP defines four life cycle phases  Inception, elaboration, construction, transition

Systems Analysis and Design in a Changing World, 4th Edition 51 The Unified Process (UP) ( continued )  Reinforces six best practices  Develop iteratively  Define and manage system requirements  Use component architectures  Create visual models  Verify quality  Control changes

Systems Analysis and Design in a Changing World, 4th Edition 52 Extreme Programming (XP)  Recent, lightweight, development approach to keep process simple and efficient  Describes system support needed and required system functionality through informal user stories  Has users describe acceptance tests to demonstrate defined outcomes  Relies on continuous testing and integration, heavy user involvement, programming done by small teams

Systems Analysis and Design in a Changing World, 4th Edition 53 Agile Modeling  Hybrid of XP and UP (Scott Ambler); has more models than XP, fewer documents than UP  Interactive and Incremental Modeling  Apply right models  Create several models in parallel  Model in small increments  Teamwork  Get active stakeholder participation  Encourage collective ownership  Model with others and display models publicly

Systems Analysis and Design in a Changing World, 4th Edition 54 Agile Modeling ( continued )  Simplicity  Use simple content  Depict models simply  Use simplest modeling tools  Validation  Consider testability  Prove model is right with code

Systems Analysis and Design in a Changing World, 4th Edition 55 Scrum  For highly adaptive project needs  Respond to situation as rapidly as possible  Scrum refers to rugby game  Both are quick, agile, and self-organizing  Team retains control over project  Values individuals over processes

Systems Analysis and Design in a Changing World, 4th Edition 56 CASE Tool Repository Contains All System Information