1. Process Model

2. A method is a disciplined procedure for generating a set of models that describe various aspects of a software system under development, using some well-defined notation.
A methodology is a collection of methods applied across the software development lifecycle and unified by process, practices, and some general, philosophical approach.

3. Model Proses Software Llinear Evolutionaire/iteration Hybrid model
Agile
Rekayasa Perangkat Lunak - Citra N.,S.Si, MT

4. Model Waterfall
Rekayasa Perangkat Lunak - Citra N.,S.Si, MT

5. The Systems Engineering Process
* Software Engineering 7th ed, Ian Sommerville

6. SDLC Prototype

7. Evolutionary development
Exploratory development
Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.
Throw-away prototyping
Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.
Rekayasa Perangkat Lunak - Citra N.,S.Si, MT

8. Prototype Evolusioner
Identifikasi Kebutuhan Pengguna
Mengembangkan
Prototipe
Tidak
Memenuhi
Syarat?
Delivery
Sistem
Ujicoba Sistem
Prototipe Ya

9. Prototipe Throw-away Persyaratan Outline Buat Prototype
Evaluasi Prototype
Spesifikasi Sistem
Kembangkan
Software
Validasi Sistem
Delivery
Reusable
Komponen

10. Evolutionary development…

11. Incremental

12. Incremental development…

13. Spiral development
Process is represented as a spiral rather than as a sequence of activities with backtracking
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required
Risks are explicitly assessed and resolved throughout the process

14. Spiral model of the software process
Rekayasa Perangkat Lunak - Citra N.,S.Si, MT

15. RAD

16. Extreme programming
New approach to development based on the development and delivery of very small increments of functionality
Relies on constant code improvement, user involvement in the development team and pairwise programming
Good for small teams

17. eXtreme Programming phase
Exploration: Determine feasibility, understand key “stories” for the first release, and develop exploratory prototypes.
Planning: Agree on the date and stories for the first release.
Iterations to release: Implement and test selected stories in a series of iterations. Refine the iteration plan.
Productionizing: Prepare supporting materials (documentation, training, marketing), and deploy the operational system.
Maintenance: Fix and enhance the deployed system.

18. RUP phase model

19. BOOM
Initiation
Make the business case for the project.Work also begins on the user experience and on drafts of architectural proof of concepts. The prototyping effort during the Initiation phase should be risk-driven and limited to gaining confidence that a solution is possible.
Discovery
Conduct investigation leading to an understanding of the solution’s desired behavior. (On iterative projects, requirements analysis peaks during this phase but never disappears entirely.) During this phase, architectural proofs of concept are also constructed.

20. Construction
Complete the analysis and design, code, integrate, and test the software. (On iterative projects, these activities are performed for each iteration within the phase. Design and coding appear in all phases, but peak during this phase.)
Final Verification and Validation (V&V)
Perform final testing before the product or service is transitioned into production. (While final testing occurs in this phase, testing activities may occur throughout the SDLC—for example, before design or as a replacement for it.)
Closeout
Manage and coordinate deployment into production and close the IT project.2

21. The Scrum Framework
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.  (Ken Schwaber and Jeff Sutherland)

22. The Scrum lifecycle
Planning: Establish the vision, set expectations, secure funding, and develop exploratory prototypes.
Staging: Prioritize and plan for the first iteration. Develop exploratory prototypes.
Development: Implement requirements in a series of sprints, and refine the iteration plan.
Release: Prepare supporting materials (documentation, training, marketing), and deploy the operational system.

23. Scrum Roles
Product Owner: The Product Owner should be a person with vision, authority, and availability. The Product Owner is responsible for continuously communicating the vision and priorities to the development team. It’s sometimes hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.
Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and the team. The Scrum Master does not manage the team. The Scrum Master works to remove any impediments that are obstructing the team from achieving its sprint goals. This helps the team remain creative and productive while making sure its successes are visible to the Product Owner. The Scrum Master also works to advise the Product Owner about how to maximize ROI for the team.
Team: According to Scrum’s founder, “the team is utterly self managing.” The development team is responsible for self organizing to complete work. A Scrum development team contains about seven fully dedicated members (officially 3-9), ideally in one team room protected from outside distractions. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.

25. A product owner creates a prioritized wish list called a product backlog.
During sprint planning, the team pulls a small chunk from the top of that wish list,
a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time — a sprint (usually two to four weeks) —
to complete its work, but it meets each day to assess its progress (daily Scrum).
Along the way, the ScrumMaster keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable: ready to hand
to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog
and begins working again.

26. A Sprint (or iteration) is the basic unit of development in Scrum
A Sprint (or iteration) is the basic unit of development in Scrum. The Sprint is a timeboxed effort; that is, it is restricted to a specific duration.[25 The duration is fixed in advance for each Sprint and is normally between one week and one month, with two weeks being the most common.
Each Sprint starts with a Sprint Planning event that aims to define a Sprint Backlog, identify the work for the Sprint, and make an estimated commitment for the Sprint goal. Each Sprint ends with a Sprint Review and Sprint Retrospective, that reviews progress to show to stakeholders and identify lessons and improvements for the next Sprints.
Scrum emphasizes work that is really done at the end of the Sprint. In the case of software, this likely includes that the software has been fully integrated, tested and documented, and is potentially shippable.