Naive View / Problem Specification —-CODING——> Final Program

Trade-off between *perfection* and *actual needs - considering constraints*

Teamwork

Change is the norm, not the exception

Not constrained by physical laws, but political/social forces

SD Activities:

- Requirements Collection

- often informally, ::incomplete, ambiguous or even incorrect::

- Req. will change, Validation needed throughout the whole software lifecycle

- ::Analysis is the process of identifying what a system will do or needs to do::

- Result: a specification (document)

- Analysis results in models of the system which describe:

- ::Refined use cases, System architecture, Classes, Relationships::

- ::A prototype is a software program developed to test, explore, or validate a hypothesis, that is, to reduce risks::

- ***Exploratory PTT***: throwaway, validate reqs, explore choices

- UI PTT (user reqs)

- Rapid PTT (functional reqs)

- Experimental PTT (technical feasability)

::Eselsbrücke: ***U & I*** im Trans***rapid*** wäre ein lustiges ***Experiment***::

- ***Evolutionary PTT***: made to evolve into a finished product

- Oft, wenn Spezifikationen nicht im Vorraus entwickelt werden können

- > ::System Design::

- > Design is the process of specifying how the system behavior will be realized from software components

- > result: technical architecture and detailed design documents

- > ::Implementation::

- > Is the activity of constructing a software solution to the customers reqs

- > ::Testing::

- > is the process of validating that the solution meets the reqs

All of the Above are **iterative** activities;

- ::Maintenance::

- Is the process of changing a system after it has been deployed for the first time

- Corrective

- Adaptive

- Perfective

- ::Eselsbrücke: 🧢 CAP bro CAP CAP Coradaper Core@Diaper::

- Maintenance Activities: Configuration & Version Mngmt, Reengineering, Documentation Updates




(ongoing & parallel, not sequential phases)


Probleme mit dem Modell:

- Echte Projekte folgen nicht diesem sequentiellem Fluss;

- Requirements können nicht so explizit genannt werden wie vom Modell gefordert

- Kunden müssen starke Geduld haben - MVP ist erst spät da



✨You won't get it right the first time, so

- Integrate,

- Validate,

- Test

→ ⚠️ In der Praxis ist Entwicklung immer iterativ und alle Aktivitäten passieren parallel

→ Ansatz: INKREMENTELLE UPDATES ; immer running version haben, neue functionalities nach validierung against user requirements integraten


→ Evolutionary development

- Planning Game

- Stakeholders meet to plan the next iteration, Business People decide, Developers assess

- Small releases

- MVP, dann release early and often

- Metaphor

- Organizing Metaphor, easy to remember naming conventions

- Simple design

- Always use the simplest design possible

- Testing

- Test first; Write Test, then implement

- Refactoring

- continously done

- Pair programming

- 40h-week

- devs go home on time ; overtime = serious problem

- no tired devs

- On-Site customer

- Coding standards

- everyone has the same standards

- Continuous intergration

- All changes are integrated into the code-base at least daily

- tests have to run 100% before and after the integration

- Collective code ownership

- Any programmer that sees an opportunity to add value to any portion of the code is required to do so at any time

Pros:

- Integrated, simple concept

- Low maangement overhead

- Continuous risk management

- Continuous effort estimation

- Emphasis on testing

Cons:

- scalability bad (big teams)

- big teams need more overhead

- good documentation is necessary