1. Manajemen Proyek Sistem Informasi
Politeknik Elektronika Negeri Surabaya
2016

2. Pendahuluan
Manajemen Perangkat Lunak

3. Software Engineering in Practice #2
Q. #1
Are you sure that the software you built will run properly in accordance with the requirements?
a. Yes, off-course
b. Not sure
c. Don’t know
Software Engineering in Practice #2

4. Software Engineering in Practice #2
The “Rock” Problem
Software Engineering in Practice #2

5. Software Engineering in Practice #2
The “Rock” Problem
Software Engineering in Practice #2

6. Software Engineering in Practice #2
The “Rock” Problem
The “Rock” Problem gives us a perspective that it is almost impossible to catch and equate the requirement definition to all stake-holders.
It means: software development will build a software that is never completed at the eyes of stake-holders.
Software development is never finished. It is a long-life development cycle.
Software Engineering in Practice #2

7. Software Engineering in Practice #2
Q. #2
How confident are you that the software you built will run properly in accordance with the requirements?
Number 50
100
Level of Confidence (%)
Software Engineering in Practice #2

8. Software Engineering in Practice #2
Success Rate *)
Based on Chaos Report of Standish
The Standish Group research shows a staggering 31.1% of projects will be cancelled before they ever get completed.
Further results indicate 52.7% of projects will overcost 189% of their original cost estimates.
The average overrun is 222% of the original time estimate.
The success rate was only 16.2%.
*) Success means “on time, on budget, on spec.”
Software Engineering in Practice #2

9. Software Engineering in Practice #2
Success Rate *)
Based on Ambysoft.com Survey on Dec, 2008
*) Success means NOT on time, on budget, meeting the specs.
Software Engineering in Practice #2

10. Software Engineering in Practice #2
Success Rate *)
Based on Ambysoft.com Survey on Dec, 2008
TIME: Which is more important?
Delivering on time according to the schedule
Delivering when the system is ready to be shipped
It does’n matter to me
39,5%
57,5%
3,0%
Software Engineering in Practice #2

11. Software Engineering in Practice #2
Success Rate *)
Based on Ambysoft.com Survey on Dec, 2008
FUNCTIONALITY: Which is more important?
Building the system to the specification
Meeting the actual needs of stakeholders
It does’n matter to me
15,5%
83,4%
1,1%
Software Engineering in Practice #2

12. Software Engineering in Practice #2
Success Rate *)
Based on Ambysoft.com Survey on Dec, 2008
QUALITY: Which is more important?
Delivering systems on time and on budget
Delivering high quality, easy to maintain systems
It does’n matter to me
16,6%
81,9%
1,5%
Software Engineering in Practice #2

13. Software Engineering in Practice #2
Success Factor
Very important to meet and match the success factors between all stakeholders in developing system.
Software Engineering in Practice #2

14. Q. #3
What factors affect the level of your belief in the success of software that you built?
Unit Testing
Quality Assurance
Problem Definition
Requirement Definition
Architecture Design
Database
Design
User Interface
Design
Schedule
Budget
Planning
Software Engineering in Practice #2

15. Software Engineering in Practice #2
#1. Problem Definition
Without a good problem definition, you might put effort into solving the wrong problem. Be sure you know what you’re aiming at before you shoot.
Software Engineering in Practice #2

16. Software Engineering in Practice #2
#2. Requirement
Without good requirements, you can have the right general problem but miss the mark on specific aspects of the problem.
Software Engineering in Practice #2

17. Software Engineering in Practice #2
#3. Architecture
Without good software architecture, you may have the right problem but the wrong solution. It may be impossible to have successful construction.
Software Engineering in Practice #2

18. Info. Strategic Planning
#4. Schedule
M-1
M-2
M-3
M-4
M-5
M-6
Info. Strategic Planning
Requirement Analysis
System Design
System Construction
Project
Start
System Testing
Implementation
Data Acquisition
Documentation
Maintenance
Software Engineering in Practice #2

19. Info. Strategic Planning
#4. Schedule
M-1
M-2
M-3
M-4
M-5
M-6
Info. Strategic Planning
Requirement Analysis
Requirement Analysis (cont’)
System Design
System Design (cont’)
System Construction
System Construction (cont’)
Project
Start
System Testing
Syst. Testing (cont’)
Implementation
Data Acquisition
Data Acq. (cont’)
Documentation
Maintenance
Software Engineering in Practice #2

20. Software Engineering in Practice #2
The Real Happened
Software Engineering in Practice #2

21. The Irony of Construction
Code Complete of McConnell
Requirements can be assumed rather than developed; architecture can be shortchanged rather than designed; and testing can be abbreviated or skipped rather than fully planned and executed.
Software Engineering in Practice #2

22. Software Engineering in Practice #2
S/W Failure Curve
Development
Parallel-run
Go-live
Software Engineering in Practice #2

23. Software Engineering in Practice #2
Generating “Risk”
Loss of time
Loss of money
Risk
Loss of opportunity
Loss of reputation
Software Engineering in Practice #2

24. Referensi
“Introduction to Risk Management” , BAHTIAR H. SUHESTA, IT Consultant, Writerpreneur, and Founder of An-Nabwah Group