Commit 3c735d
| Testseite | |
| @@ 1,16 1,141@@ | |
| - | # Testseite |
| + | # Satz 1 - Intro, SD activities, Iterative Development Lifecycle, EXTREME programming |
| - | # Satz 8 Refactoring to Patterns |
| + | 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 |
| - | Make it work – First! |
| + | > ***„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 |
| + | |
| + |  |
| + | |
| + |  |