1. REKAYASA PERANGKAT LUNAK (Software Engineering)
Pendahuluan

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

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

5. Aplikasi PL
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

6. 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

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

8. Biaya perubahan

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

10. Kegiatan RPL 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

11. The Process Model : Adaptability
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)
characteristics of the project
common sense judgment; concurrence of the project team

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

13. The Linear Model analysis design code test System/information
engineering

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

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

16. RAD

17. The Incremental Model calendar time increment 1 delivery ofs i d e g c o t S m / f r
increment 2
increment 3
increment 4
increment 1
delivery of
1st increment
2nd increment
3rd increment
4th increment
calendar time

18. An Evolutionary (Spiral) ModelC u s t o m e r n i c a P l g
& R E v k A y

19. Still Other Process Models
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

20. Manajemen Proyek The 4 P’s
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

21. Software Teams 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

22. Organizational Paradigms
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 compartment-alization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

23. Project Management Concerns

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

25. Melding Problem and Process

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

27. 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

28. To Get to the Essence / pokok of a Project
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?