Satz 1 - Intro, SD activities, Iterative Development Lifecycle, EXTREME programming

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

What ist SE?

*“state of the art of developing quality software on time and within budget”*

*„Multi-Person construction of Multi-Version software“* - Dave Parnas

*„SE is different from other engineering disciplines“* - Ian Sommerville

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

The Iterative Development Lifecycle

(ongoing & parallel, not sequential phases)

Classical Software Lifecycle: (is unrealistic)

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

*“You should use iterative development only on projects that you want to succeed.”* – Martin Fowler (UML Distilled)

→ ⚠️ 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

Extreme Programming

→ 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