REKAYASA PERANGKAT LUNAK Software Engineering Pendahuluan Produk l

REKAYASA PERANGKAT LUNAK (Software Engineering) Pendahuluan

Produk l Perangkat Lunak (PL) / Software ? l Serangkaian instruksi/program/struktur data yang dapat di exekusi / untuk memanipulasi suatu informasi. l l l software is engineered software doesn’t wear out software is custom built l software is complex

l Failure (“Bathtub”) Curve for Hardware Failure Rate tidak dipakai lagi Awal produksi Time

l Aplikasi PL l l l System Software (s/w), misalnya s/w yang berupa kumpulan program untuk menunjang pembuatan program Real Time Software, misalnya s/w yang digunakan untuk mengukur / menganalisa / mengontrol proses input data s/d output sesuai dengan keinginan Bussines Software, misalnya s/w yang digunakan dalam aplikasi bisnis

l l Engineering & Scientific Software, misalnya s/w yang digunakan dalam aplikasi teknik Embedded Software, misalnya s/w yang digunakan untuk mengontrol proses dalam pabril & biasanya disimpan didalam ROM Personal Computer Software, misalnya s/w untuk aplikasi komputer Artificial Intellegence Software, misalnya s/w untuk kecerdasan buatan

l Mitos RPL l l l Management l We have new computers l We have standards l We’ll add more people to catch up l I outsourced it, I’m done Customer l We have general objectives, let’s start l Change is easily accommodated Practitioner l We’ll write it and be done l I can’t assess quality until it is running l I only need deliver code l Software engineering is about meaningless documents

l Biaya perubahan

Proses l Kerangka proses RPL Common process framework Framework activities Task Sets tasks milestones, deliverables SQA checkpoints Umbrella Activities

l Kegiatan RPL l l l l Software project management (tracking and control) Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement / pengukuran Risk management

l The Process Model : Adaptability l l the framework activities will always be applied on every project. . . BUT the tasks (and degree of rigor) for each activity will vary based on: the type of project (an “entry point” to the model) l characteristics of the project l common sense judgment; concurrence of the project team l

l Process as Problem Solving / Sekuensial Linier Model Definisi masalah pengembangan status quo teknis solution integration

l The Linear Model System/information engineering analysis design code test

l Waterfall Model Software Reqmts Analysis Software Item 1 System Reqmts System Analysis Architectural Design Software Detailed Design Software Architectural Design Software Integration Software Coding & Testing Software Item n. . . Software Qualification Testing System Integration, Qualification & Release Activities Hardware Items Note: 1) Software Lifecycle Activities are bolded / shaded 2) This model is consistent with IEEE/EIA 12207. 2 - 1997

l Prototyping listen to customer build/revise mock-up customer test-drives mock-up Prototyping

l RAD

l The Incremental Model increment 1 System/information engineering analysis design increment 2 code analysis test design increment 3 analysis delivery of 1 st increment code test design increment 4 analysis delivery of 2 nd increment code delivery of 3 rd increment test design code test delivery of 4 th increment calendar time

l An Evolutionary (Spiral) Model Pla nning Risk Ana lysis Custom er Co m m unic a tio n Eng ineering Custom er Eva lua tion Co nstruc tion & Relea se

l Still Other Process Models l l l WINWIN spiral model - defines negotiating activities and adds anchor points to spiral model Concurrent process model—recognizes that different part of the project will be at different places in the process Component-based development model—the process to apply when reuse is a development objective Formal methods—the process to apply when a mathematical specification is to be developed Cleanroom software engineering—emphasizes error detection before testing

Manajemen Proyek l The 4 P’s l l People — the most important element of a successful project Product — the software to be built Process — the set of framework activities and software engineering tasks to get the job done Project — all work required to make the product a reality

l Software Teams l l l l the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime) the degree to which the problem can be modularized the required quality and reliability of the system to be built the rigidity of the delivery date the degree of sociability (communication) required for the project

l Organizational Paradigms l l closed paradigm—structures a team along a traditional hierarchy of authority (similar to a CC team) random paradigm—structures a team loosely and depends on individual initiative of the team members open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

l Project Management Concerns

l Defining the Problem l l establish scope—a narrative that bounds the problem decomposition—establishes functional partitioning

l Melding Problem and Process

l Software Projects • size • delivery deadline • budgets and costs • application domain • technology to be implemented • system constraints • user requirements • available resources

l Why Projects Fail? • an unrealistic deadline is established • changing customer requirements • an honest underestimate of effort • predictable and/or unpredictable risks • technical difficulties • miscommunication among project staff • failure in project management

l To Get to the Essence / pokok of a Project l l l Why is the system being developed? What will be done? By when? Who is responsible for a function? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource (e. g. , people, software, tools, database) will be needed?