1. XP extreme programming
   
   
2. Scrum (30 day iteration, daily meeting with 3/4 specific questions per person)
   
   
3. UP Unified Process
   
   
4. EVO
   
   

• iterative lifecycle
  
  
• risk driven development
  
  

1. requirements
   
   
2. design
   
   
3. implementation
   
   
4. test
   
   
5. show/feedback
   
   
6. requirements

• identify & drive down high risks
  
  
• architecture-centered in early iterations

• timeboxed
• iterative
• evolutionary refinement
• plans
• requirements
• design
• adaptation planning
• incremental delivery

• short timeboxed iterative
  
  
• evolutionary
  
  
• adaptive
  
  

1. inception feasable?
   
   
2. elaboration core architecture & high risk
   
   
3. costruction low risk & prepare deployment
   
   
4. transition beta, deployment
   
   

• common vision
  
  
• basic scope
  
  
• Envision
  
  
• product scope
• vision
• business case
• Do stakeholders agree
• vision
• worth investigating

• Functional
  
  
• Usability
  
  
• Reliability
  
  
• Performance
  
  
• Supportability
  
  
• + implementation, interface, operations, packaging, legal
  
  

• functional (behavioral)
  
  
• non-functional (rest)
  
  

• sequence of actions and interactions
  
  
• one path through the use-case
  
  
• successor failure
  
  

• brief (early req)
  
  
• casual (early req)
  
  
• fully dressed (after most use-cases are identified)
  
  
• during req workshop (10%)

• simple
  
  
• accessible to users
  
  

• primary: fulfills user-goals
  
  
• uses services of SuD
  
  
• why? find user goals
  
  
• supporting: provides a service to the SuD
  
  
• why? find external interfaces and protocols
• offstage: has interest in behavior
• why? find all necessary interests (identified & satisfied)

• essential: early requirements
• no UI
• intentions of user
• responsiblities of system
• NOT concrete actions
• concrete: GUI design
• concrete actions
  
  
• UI embedded in text

• describe Responsibilities (not workings)

• focus on actors (goals, typical situations)
• focus valuable result for actor

• Boss: "What have you done all day?"
  
  
• EBP: Elementary Business Process
  
  
• task
• 1 person
• 1 place
• 1 time
• response to event
• adds value
• leaves data in consistent state
• Size: fully dressed is 3-10 pages
• Exception: separate use case for less text duplication

• functional requirements use mainly use-cases
  
  
• use cases are important part of iterative planning
  
  
• use case realizations drive design
  
  

• supplementary specification
  
  
• glossary
  
  
• terms & definitions
• data dictionary
• vision
  
  
• executive summary
• > communicates the big ideas
• buisiness rules/domain rules
  
  

• programmed
  
  
• tested

• discovered
  
  
• stabilized
  
  

• mitigated (less serious/gravity)
  
  
• retired (solved)
  
  

• is a production subset of final system
  
  
• not discardable experiment
  
  

• domain model: visualization of domain concepts
  
  
• design model: set of diagrams of logical design (class, interaction, package) diagrams
  
  
• software architecture document: key architecture issues + resolution in design
  
  
• data model: DB schema's, mapping objet <> non-object
  
  
• use-case storyboards,UI prototypes: description UI, navigation paths, usability, ...
  
  

• Risk: technical complexity, ...
• Coverage: all major parts touched in early iterations, "wide & shallow"
• Criticality: high business value

• most important/used model in OOA
  
  
• illustrates noteworthy concepts
  
  
• inspiration >> design objects
• input >> other artifacts

• not diagrams of software objects
• not domain layer of software architecture
• not software objects with responsibilities(=methods)

1. domain objects or conceptual classes
2. associations
3. attributes

• software objects (Java, C#)
  
  
• software artifacts (unless this is the domain eg. GUI)
• responsibilities or methods

• symbol: name eg. "Sale"
• intension: definition eg. "event of purchase transaction"
• extension: all examples eg. "all sale instances in the universe"

1. find conceptual classes
2. draw them in UML class diagram
3. add associations & attributes

1. reuse/modify existing models
2. category list
3. noun phrase

• imprecision of natural language
• some may refer to conceptual classes that are ignored in this iteration

• ONLY if there is a practical reason to maintain it
• UML CASE tool

• :-( only duplication/derrived information
  
  
• :-) special role? (handle return)
  
  

• use existing names of the territory
• exclude irrelevant/out-of-scope features
• don't add things that are not there

• duplication (space, errors)
• if all instances are removed, info is not available

• description of item/service is independent of current existence
• deleting instance => loss of information that must be maintained
• reduces redundant or duplicated information

• knowledge of relationship needs to be preserved for some time
  
  
• derived from 'Common Associations List

• requirements imply "need to remember information"
  
  

visibility name : type multiplicity = default {property-string}

/derrived-attribute // calculated from other values