Process Model
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.
Llinear
Evolutionaire/iteration Hybrid model
Agile
Model Proses Software 3
Model Waterfall 4
The Systems Engineering Process
System integration Sub-system
development System
design Requirements
definition
System installation
System evolution
System
decommissioning
* Software Engineering 7th ed, Ian Sommerville
5
SDLC Prototype
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.
Evolutionary development 7
Prototype Evolusioner
Identifikasi Kebutuhan
Pengguna Identifikasi
Kebutuhan Pengguna
Mengembangkan Prototipe
Mengembangkan Prototipe
Ujicoba Sistem Prototipe Ujicoba Sistem
Prototipe
Delivery Sistem Delivery
Sistem Memenuh
i Syarat?
Memenuh i
Syarat?
Tida k
Ya
Prototipe Throw-away
Persyaratan Outline Persyaratan
Outline Buat
Prototype Buat
Prototype Evaluasi Prototype Evaluasi Prototype
Spesifikasi Sistem Spesifikasi
Sistem
Kembangkan Software Kembangkan
Software
Validasi Sistem Validasi
Sistem Delivery Delivery
Reusable Komponen
Evolutionary development…
Validation Final
version
Development Intermediate
versions
Specification Initial
version
Outline description
Concurr ent activities
Incremental
Incremental development…
Validate increment Develop system
increment
Design system architecture
Integrate
increment Valida te
system Define outline
requirements Assign requirements to increments
System incomplete
Final system
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
Spiral model of the software process
Risk analysis Risk
analysis analysisRisk
analysis Proto-Risk type 1
Prototype 2
Prototype 3 Opera- tional protoype
Concept of Operation
Simulations, models, benchmarks S/W
requirements Requirement
validation Design
V&V
Product
design Detailed design Code Unit test Integr ation Acceptance test
Service test Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives
alternatives and constraints
Plan next phase
Integration and test plan Development
plan Requirements plan
Life-cycle plan REVIEW
14
RAD
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
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.
RUP phase model
Phase iteration
Inception Elaboration Construction Transition
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.
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
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)
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.
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.
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.
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.
