Process Models (Vorgehensmodelle) — Final Exam

Why process models are important

Problem: software keeps growing in scope and complexity and requirements change ever faster, yet customer expectations must still be met — software must be delivered in sufficient quality, on schedule, and within a given budget.

Solution: use proven, effective and efficient development process models. How software projects are carried out should not be reinvented every time; established, engineering-style practice improves productivity, quality, plannability and predictability (compare design patterns). Different projects (project size, application domain, project type) require selecting the appropriate model.

Benefits of using a standardized process model

Studies show that using proven, standardized process models increases the probability of completing a project successfully by roughly a factor of six.

• Kommunikation (communication): stakeholders gain a common basis for discussion.
• Planbarkeit (plannability): the steps to be taken are exactly known, making them plannable and predictable (checklists).
• Toolunterstützung (tool support): software is available for widespread models to ease their use.
• Erfahrungen (experience): the models have been in successful use for decades, so many problems and solutions are already documented.
• Kunden (customers): some customers — often public/state clients — mandate a specific model (often the V-Model).

Waterfall model (Wasserfallmodell nach Royce)

The most widely used process model, with many variants; first published in the 1980s. Its focus is documentation/management. In its basic form it is fully sequential.

A common variant allows a step back to the directly preceding phase (backtracking). A phase can only be completed once all of its planned deliverables are fully finished (e.g. the "program design" phase starts only after the analysis phase is 100% complete).

• Advantage: many extensions exist (e.g. backtracking to earlier phases).
• Advantage: risk minimization by 'closing' each phase before the next.
• Advantage: wide adoption and high familiarity.
• Advantage: strict separation of phases improves plannability.
• Advantage: usable even by small development teams.
• Disadvantage: all tasks of a phase must be finished (no parallel work across phases).
• Disadvantage: errors in early phases strongly affect the project.
• Problem: each phase becomes very expensive and slow (changing requirements are not foreseen), which pushed iterative/agile approaches.
• Application: needs good knowledge of the requirements domain (No-Surprise Software) and clearly defined, complete requirements, because requirement changes are costly.

Basic V-Model and its successors (V-Modell XT and BVM)

First presented in 1979 and used mainly in public-sector projects; it is the basis for many models such as the V-Modell XT and the BVM. Unlike the waterfall model it separates the specifying phases from the realizing phases, but it is similarly sequential in structure.

Correlating phases: for each constructive phase on the left there is a correlating checking phase on the right, and each project artifact is paired with an individual verification method (e.g. code is checked with unit tests). It was the first such model to integrate test stages. Examples of the pairing (left → right): Code → Unit Test; Detailed/Program Design → Integration & System Test; Product Design → Acceptance Test; Requirements → Installation, Operational Testing & Evaluation.

V-Modell XT: a more flexible, more modular structure than the basic V-Model, allowing adaptation to different project conditions; its central elements are modular, self-contained "Vorgehensbausteine" (process building blocks) included flexibly as the project requires. It is the mandatory model for public-sector IT projects in Germany.

Bundesvorgehensmodell (BVM): a model adapted to the needs of the Austrian federal administration, developed in line with the German V-Modell XT and mostly mandatory for Austrian public-sector projects.

• Advantage: interlocking specification/project phases with matching test phases raises result quality.
• Advantage: foundation for many current development models.
• Disadvantage: clear system requirements must be given completely and early; changes are very costly (like waterfall).
• Disadvantage: high documentation effort; barely usable with unclear or changing requirements.
• Application: large public-sector projects with clearly definable requirements; popular in safety-critical domains (army, police, etc.).

Spiral model (Spiralmodell)

First presented by Boehm in 1988. It accounts for the risks of sequential development and is therefore iterative: the whole process is divided into four phases that are run through multiple times. The number of cycles only emerges during the project and depends on the risks that arise — more iterations mean longer development and higher cost.

On the x-axis the project progress is shown as the software life cycle; the distance from the centre visualizes the rising effort, cost and duration with each iteration. Deterministic planning is only possible for a manageable number of iterations; planning the entire project duration upfront is hard.

• Advantage: the complexity of a system is taken into account.
• Advantage: requirements can change during the project.
• Disadvantage: time and cost plans at project start are hard to produce.
• Disadvantage: risk analysis requires experienced project leaders.
• Disadvantage: choosing the right pace is hard — too cautious lengthens the project, too fast neglects risks.
• Application: especially for very long, very large projects with unclear (undefined or changing) requirements.

Rational Unified Process (RUP)

A phase-oriented, incremental and iterative software process created and continuously developed by IBM Rational; since its 1999 introduction it became a de-facto standard. It rests on six proven practices (Six Best Practices) and distinguishes two dimensions and four basic phases (these four phases are not equivalent to the waterfall phases).

• Best practice: develop software iteratively (early risk identification, accommodate changing requirements).
• Best practice: manage requirements (capture, document, organize, trace changing requirements).
• Best practice: use component-based architectures (reduces size/complexity; more flexible and stable; components swappable).
• Best practice: model software visually (models aid understanding and communication of complex systems).
• Best practice: continuously verify software quality (early defect detection lowers fix cost).
• Best practice: control changes to software (manage, monitor, trace changes).
• Two dimensions: dynamic (horizontal) = time structure (phases, iterations, milestones); static (vertical) = content structure (artifacts, activities, roles grouped into disciplines).
• Advantage: links the real problem to the concrete solution; tool support (e.g. IBM Rational XDE); predefined checklists of required artifacts.
• Disadvantage: very complex and inflexible; many required documents → high documentation effort, feels 'overloaded', limited practicality; almost fully controlled/dominated by IBM.
• Application: large projects, via a holistic process view of the whole project (incl. deployment).

Agile Manifesto and its twelve principles

The basis for agile development processes such as XP and Scrum, written by 17 software developers in 2001. It contains 12 basic principles for modern agile development. Its main goal is to deliver working software quickly to best meet customer wishes, with customer interaction playing a central role. "Agile" does not mean "uncontrolled" — processes and rules still exist and must be kept.

The twelve basic principles (source: agilemanifesto.org):

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
• 1. Highest priority: satisfy the customer through early and continuous delivery of valuable software.
• 2. Welcome changing requirements, even late in development; agile processes harness change for the customer's advantage.
• 3. Deliver working software frequently (weeks rather than months).
• 4. Business people and developers work together daily throughout the project.
• 5. Build projects around motivated individuals; give them environment, support, and trust.
• 6. Face-to-face conversation is the most efficient and effective way to convey information.
• 7. Working software is the primary measure of progress.
• 8. Agile processes promote sustainable development; sponsors, developers and users keep a constant pace indefinitely.
• 9. Continuous attention to technical excellence and good design enhances agility.
• 10. Simplicity — maximizing the amount of work not done — is essential.
• 11. The best architectures, requirements and designs emerge from self-organizing teams.
• 12. At regular intervals the team reflects and tunes its behavior to become more effective.

Scrum — definition and development philosophy

Scrum defines an agile software project from the project-management perspective and is a collection of procedures, roles and methods for successful project execution. Its central values are high productivity, adaptability, and little risk/uncertainty, yielding more comfort for project members. "Scrum" is not an abbreviation; it refers to a rugby strategy and to a hyper-productive product development first used in Japan.

• All functional and non-functional requirements are listed by importance in the Product Backlog; the order is continuously adjusted during a sprint.
• Development is done by small Scrum Teams (recommended 7 ± 2 people).
• Daily Scrum Meeting: led by the Scrum Master, always same time/place; monitors progress and surfaces/removes obstacles.
• Sprint: the central element of Scrum; an 'implementation of one iteration', fixed duration (usually two weeks to 30 days), must end with a finished new functionality; progress tracked via a Burndown Chart maintained by the Scrum Master.
• Sprint Planning Meeting: at the start of a sprint, fixes the sprint's tasks and defines a Sprint Goal; every developer can contribute, raise risks, and vote on features.
• Sprint Review Meeting: at the end of each sprint, presents the new functionality (the increment) and checks the Sprint Goal; then the next sprint starts after defining the new Sprint Backlog.

Scrum — elements and roles

Scrum's artifacts/elements and its three roles.

• Product Backlog: a list of all requirements ordered by urgency, viewable by all; the Product Owner is responsible for it.
• Release Backlog: part of the Product Backlog containing the functionality of a specific release.
• Increment: the product is built in increments; at the latest the second sprint should deliver a runnable system with core functionality.
• Burndown Chart: the Scrum Master enters daily effort estimates for the current sprint into this diagram.
• Role — Product Owner: creates and prioritizes the Product & Release Backlog (represents the customer) and keeps the team free of disturbances.
• Role — Scrum Team: implements the functionality required via the Sprint Backlog and achieves the Sprint Goal.
• Role — Scrum Master: lets Scrum's dynamics unfold by enforcing Scrum's principles/rules and shielding the team from external influences.

eXtreme Programming (XP) — values and principles

"A compact method for developing software in small to medium teams whose work is subject to vague or rapidly changing requirements." Its main goal is the on-schedule delivery of contract-conforming software. XP has its own value system, many principles, and a system of mutually reinforcing techniques.

Value system (shared values for an XP project): Communication (replace documentation with continuous personal discussion of problems/tasks/alternatives, since documentation artifacts are assumed not decisive for success); Simplicity ("what is the simplest thing that could possibly work"); Feedback (on code correctness and project status, at several levels); Courage (to rebuild architecture, throw code away, give negative feedback); Respect (for oneself, the team, and the product).

• Principle — immediate feedback: a short distance between action and feedback improves learning and prevents long unproductive work.
• Principle — strive for simplicity: simple solutions are easy to change for future requirements, faster to build, and easier to understand.
• Principle — incremental change: stepwise development reduces uncontrollable side effects.
• Principle — wanting change: developers should see changes as an advantage, not something unwanted.
• Principle — quality work: deliver the highest-quality work possible.

eXtreme Programming — techniques and roles

Techniques support XP's value system and principles and can be learned and applied easily.

• On-site customer (Kunde vor Ort): the customer works with the whole team and is always available for questions.
• Planning game (Planungsspiel): the content of the next increment is fixed via Story Cards.
• Metaphors: used so everyone (especially non-technical customers) grasps the basic parts and their relationships (e.g. 'beehive' for agent-based systems).
• Short release cycles: provide new/changed versions as often as possible (ideally one day up to four months apart).
• Testing: frequent testing has special importance.
• Simple design: simplicity is a central, ever-present principle.
• Refactoring: first build a working solution quickly to show the customer; once promised, improve/optimize it.
• Pair programming: two developers program together at one computer (e.g. a junior with a senior) to raise quality and spread knowledge.
• Collective ownership: all developers are jointly responsible and anyone may change any code at any time (reduces personnel dependency).
• Continuous integration: changes are integrated constantly.
• Coding standards: must be defined to enable pair programming and collective ownership.
• 40-hour week: limiting hours should foster creativity and commitment.
• Roles: Developer/Programmer, Customer (writes/prioritizes Story Cards, decides via acceptance tests), XP-Trainer (leads team, enforces XP principles), Tracker (collects project-status data), Tester (helps build and run acceptance tests), Consultant (advises on special technologies), Big Boss (gives the team courage and confidence).

Kanban

Kanban limits the number of parallel work items to achieve shorter lead times for few functions and to make problems quickly visible. It has no roles and no meetings; its elements are a Kanban board and a Work-In-Progress (WiP) limit — "the rest is up to you".

Kanban has much in common with Scrum but is not strictly tied to it; one could see Scrum as one possible implementation of Kanban. Main difference: Scrum is team-centred, whereas Kanban primarily optimizes value generation along the value-creation chain.

Traditional vs. agile — which approach fits me?

Agile models established themselves as a counter-model to traditional (plan-driven), often over-regulated models. Neither agile nor plan-driven methods are a "silver bullet"; both have clear advantages for certain areas (e.g. agile is preferable for projects needing fast time-to-market). Both agile and plan-driven aspects will remain important.

Practical tip: it is better to extend an existing process model for your needs than to reduce one. Process models matter, but the real potential "silver bullets" lie in people, values, communication, and managing expectations — a process model alone will not turn a failing project into a successful one.

Boehm and Turner decision factors

The Boehm/Turner decision model helps find a suitable model. How to read it: the more a project lands toward the middle of each factor, the more agile methods suit it; the further toward the extremes, the more plan-driven methods suit it. "Plan-Driven" is another name for the more structured traditional models (e.g. waterfall).

• Personnel (Teamstruktur): agile methods assume a more highly qualified team than plan-driven ones (plan-driven gives precise work instructions with less freedom).
• Dynamism (Dynamik der Anforderungen): the more often requirements change, the easier change must be — this favors agile.
• Culture (Entwicklungskultur): a culture already flexible and comfortable with chaos suits agile.
• Size (Teamgröße): agile is often argued to be more efficient in small to medium teams.
• Criticality (Kritikalität): when e.g. human lives depend on the system, plan-driven models suit better because they enable rigorous checking and excellent traceability at all levels.

Summary — key principles for using process models

Process models are indispensable for successfully developing software in a team.

• A process model gives a framework and describes the WHAT, not the HOW.
• There is no universal model; a model must always be selected and adapted to the context (project, company, etc.).
• Selection and adaptation depend especially on: project criticality, organizational environment, staff culture, team size and distribution, and legal/contractual conditions.
• Agile and traditional methods can be combined — the question is how much agility the project and its environment allow.
• In medium-to-large software companies, process models are often adapted completely company-specifically.

Effort estimation — prototype effort is not product effort

Scenario (6.1): a customer advisor built a small Excel app in three person-days; the boss wants it rolled out department-wide, now reading product/supplier data from company databases, and budgets one work-week — but ten person-weeks were actually needed.

The friend-developer reassures the boss because this course is not unusual: turning a small single-user prototype into a robust, shared, database-integrated production application requires far more effort than the original prototype (integration, multi-user use, robustness, and quality were not part of the three-day version).

Effort estimation pitfalls and UI estimation

Scenario (6.2): a project leader estimates effort linearly — the cumulative effort rises evenly from 0% at project start to 100% at project end.

Real effort does not accrue linearly: phases differ in intensity and unforeseen problems, rework, integration and late changes shift the effort, so the actual curve diverges from a straight line. Comparing a purely linear estimate against real effort is therefore of limited value for monitoring cost development.

Scenario (6.5): offers/applications are driven by UI documentations — hand-made screenshots plus descriptions showing the planned final interface. Given a UI prototype for a seat-reservation system (Ticketline) for concert halls, estimate the development effort.

Approach: derive requirements/features from the prototype and use them as work packages, then assign expected effort to each. The example's specifics drive the packages: each hall has a different seat layout; artists/concerts are read from external services; the customer database is self-managed for data-protection reasons; and reserving a seat checks availability. (Interfaces to internal/external systems are assumed to already exist or need only low integration effort.)

Project scheduling and people-centred decisions

A project's duration depends on the task complexity, the team's skills, and the project/environment conditions. To build a schedule (worksheet 6.3/6.4): (1) define work packages, (2) estimate each package's effort in person-days/weeks, and (3) determine the total duration and the critical dependencies between packages.

Total duration is not simply the sum of all package efforts: with several people working in parallel, the schedule is bounded by the chain of dependent packages (the critical path) and by how many packages can run concurrently. Losing one developer to another project reduces available capacity and therefore lengthens the schedule wherever that capacity sat on the critical path.

Worksheet 6.6 asks how to react in three people-centred scenarios:

• Manager says the estimate is far too high, 'rework it': do not simply lower the number; defend the estimate with its underlying work packages and assumptions, and only revise scope or assumptions transparently rather than the figure alone.
• Customer says the prototype's X, Y, Z do not match expectations: treat this as the intended early feedback of agile working — clarify the deviations and fold the corrections into the next iteration.
• New sales-support software (handling customer enquiries, invoices, offers): actively involve sales-department staff in the phases where their domain knowledge is needed — requirements analysis (to capture real needs) and acceptance/validation (to confirm the result fits).