1. REKAYASA PERANGKAT LUNAK
PERTEMUAN 2

2. PERENCANAAN PROYEK PERANGKAT LUNAK

3. Pendahuluan
Software project management begins with a set of activities that are called project planning.
Before the project can begin, the manager and the software team must estimate the work to be done, the resources that will be required, and the time that will elapse from start to finish.
Whenever estimates are made, we look into the future and accept some degree of uncertainty as a matter of course.

4. Pendahuluan
Estimation begins with a description of the scope of the product.
The problem is then decomposed into a set of smaller problems and each of these is estimated using historical data and experience as guides.
It is advisable to generate your estimates using at least two different methods (as a cross check).
Problem complexity and risk are considered before a final estimate is made.

5. Tujuan Perencanaan PPL
To provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule.

6. Scope (Ruang Lingkup) PL
The first activity in software project planning is the determination of software scope.
Unambiguous and understandable at the management and technical levels.
A statement of software scope must be bounded.
Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability.

7. Mendapatkan Ruang Lingkup
Conduct a preliminary meeting or interview.
Example questions:
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution?
Is there another source for the solution?

8. Feasibility (Kelayakan)
Scoping is not enough.
“Can we build software to meet this scope? Is the project feasible?”
Four solid dimensions:
Technology — Is it within the state of the art?
Finance — Can development be completed at a cost the software organization, its client, or the market can afford?
Time — Will the project’s time-to-market beat the competition?
Resources — Does the organization have the resources needed to succeed?

9. Resources (Sumber Daya)

10. Perspektif Sumber Daya
Masing-masing sumber daya tersebut dispesifikasikan dengan 4 karakteristik berikut ini:
Deskripsi  Siapa, Apa
Ketersediaan  Jumlah dan kualitas
Waktu  Kapan digunakan
Durasi  Berapa lama dipakai

11. SOFTWARE PROJECT ESTIMATION
To achieve reliable cost and effort estimates, a number of options arise:
Delay estimation until late in the project (obviously, we can achieve 100% accurate estimates after the project is complete!).
Base estimates on similar projects that have already been completed.
Use relatively simple decomposition techniques to generate project cost and effort estimates.
Use one or more empirical models for software cost and effort estimation.

12. Teknik Dekomposisi Software sizing Problem based estimation
LOC based estimation
Function point based estimation
Process based estimation

13. Contoh LOC based

14. Contoh FP based

15. Contoh Process based

16. COCOMO Model COnstructive COst MOdel. Address the following areas:
Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity.
Early design stage model. Used once requirements have been stabilized and basic software architecture has been established.
Post-architecture-stage model. Used during the construction of the software.

17. Keputusan: Beli atau Buat?
Software engineering managers are faced with a make/ buy decision :
(1) software may be purchased (or licensed) off-the-shelf,
(2) “full-experience” or “partial-experience” software components may be acquired and then modified and integrated to meet specific needs, or
(3) software may be custom built by an outside contractor to meet the purchaser's specifications.

19. Outsourcing
Software engineering activities are contracted to a third party who does the work at lower cost and, hopefully, higher quality.
Software work conducted within a company is reduced to a contract management activity.
The decision to outsource can be either strategic or tactical.
(+) Cost savings can usually be achieved by reducing the number of software people and the facilities (e.g., computers, network).
(-) A company loses some control over the software that it needs. A company runs the risk of putting the fate of its competitiveness into the hands of a third party.

20. Six Generic Functions
1. Sizing of project deliverables. Work products include the external representation of software (e.g., screen, reports), the software itself (e.g., KLOC), functionality delivered (e.g., function points), descriptive information (e.g. documents).
2. Selecting project activities. The appropriate process framework is selected and the software engineering task set is specified.
3. Predicting staffing levels. The number of people who will be available to do the work is specified.
4. Predicting software effort. Estimation tools use one or more models (e.g., Section 5.7) that relate the size of the project deliverables to the effort required to produce them.
5. Predicting software cost. Given the results of step 4, costs can be computed by allocating labor rates to the project activities noted in step 2.
6. Predicting software schedules. When effort, staffing level, and project activities are known, a draft schedule can be produced by allocating labor across software engineering activities based on recommended models for effort distribution (Chapter 7).

21. Kesimpulan
The software project planner must estimate three things before a project begins:
How long it will take,
How much effort will be required, and
How many people will be involved.
In addition, the planner must predict the resources (hardware and software) that will be required and the risk involved.

22. Kesimpulan
Decomposition techniques require a delineation of major software functions, followed by estimates of either
(1) the number of LOC,
(2) selected values within the information domain,
(3) the number of person-months required to implement each function, or
(4) the number of person-months required for each software engineering activity.