RUP - Rational Unified Process

Eigenschaften:

• iterativ
• UseCase getrieben
• Architektur zentriert

4 Phasen

1. Konzept - Inception
2. Entwurf - Elaboration
   - UseCase Model (80%)
   - Architektur Beschreibung
   - Architektur Prototype
3. Kontruktion - Construction
4. Übergang - Transition

5 Workflows

1. Geschäftsprozessmodellierung (Business Modelling)
2. Anforderungs Mgt. (Requirements Mgt.)
3. Analyse & Design (Analysis & Design)
4. Implementierung (Implementation)
5. Verteilung (Deployment)

Support Workflows

• Configuration & Change Mgt.
• Project Mgt.
• Environment

Process Essentials

• Vision Statement
  • Glossar & Schlüsselbegriffe
  • Problem Statement
  • Stakeholder
  • Key Features
  • Use Cases
  • Non-Fuctional Requirements
  • Boundaries
• Software Development Plan
• Risk Assessment
• Business Case
• Architecture
• Prototype
• Evaluation of results
• Mgt. of change requests
• User Support

Qualitätsziele für Software und Einsatz ( siehe DIN 66272)

• Funktionalität
  • Realisierung der geforderten Funktionen
• Zuverlässigkeit
  • Robustheit
  • Fehlertoleranz
  • Konsistenz
  • Wiederherstellbarkeit
• Benutzbarkeit
  • Benutzeroberfläche
  • gemäß Benutzerdokumentation
  • Bedienbarkeit, Handhabung, Komfort
• Effizienz
  • Zeit-/Antwortverhalten
• Einhaltung von Vorschriften
  • Gesetze
  • Firmenspez. Vorschriften
• Wirtschaftlichkeit
  • Pflege-/Wartungsaufwand
• Sicherheit
  • Identifikation, Autorisierung
  • Zugriffssteuerung, Zugriffsüberwachung
  • Übertragungssicherheit (Datenverschlüsselung)
  • Rechteverwaltung (Festlegung von Rollen und Zugriffsrechten)

Feature Driven Development

Six Key Roles

1. Project Manager
2. Chief Architect
3. Development Manager
4. Chief Programmer
5. Class Owner

The five processes of FDD

1. Develop an overall model
2. Build a feature list
3. Plan by feature
4. Design by feature
5. Build by feature

Design by feature
       1% domain walkthrough      
     40% design
       3% design inspection
Build by feature
     45% code
     10% code inspection
       1% promote to build

Feature
    

Meine Idee für eine Systemdokumentation (ähnlich Pflichtenheft)

• Intro
• Context (Diagram)
• Use Cases
• Interfaces
• Data Structure (DB Schema)
• Aspects
  • Logging
  • Security
    • Authentication
    • Authorization
    • Transport
  • Data Consistency (e.g. transaction handling)
• Service
  • Garbage collection (e.g. removal of old data from DB)
  • Updates
  • Configuration
  • History / Revision
• Laws / company rules

Es schneit wie bloede

IEEE 829 Testplan Template

1. Test Plan Identifier
2. Introduction
3. Test Items
4. Features To Be Tested
5. Features Not To Be Tested
6. Approach
7. Item Pass/Fail Criteria
8. Suspension Criteria And Resumption Requirements
9. Test Deliverables
10. Testing Tasks
11. Environmental Needs
12. Responsibilities
13. Staffing And Training Needs
14. Schedule
15. Risks And Contingencies
16. Approvals

Lastenheft - Inhalt

1. Ausgangssituation und Zielsetzung
2. Produkteinsatz
3. Produktübersicht
4. Funktionale Anforderungen
5. Nicht funktionale Anforderungen
   • Benutzbarkeit
   • Zuverlässigkeit
   • Effizienz
   • Änderbarkeit
   • Übertragbarkeit
   • Wartbarkeit
6. Risikoakzeptanz
7. Skizze des Entwicklungszyklus und der Systemarchitektur oder auch ein Struktogramm
8. Lieferumfang
9. Abnahmekriterien

Test case outline

• Introduction/overview contains general information about Test case.
  • Identifier is unique identifier of test case for further references, for example, while describing found defect.
  • Test case owner/creator is name of tester or test designer, who created test or is responsible for its development
  • Version of current Test case definition
  • Name of test case should be human-oriented title which allows to quickly understand test case purpose and scope.
  • Identifier of requirement which is covered by test case. Also here could be identifier of use case or functional specificationitem.
  • Purpose contains short description of test purpose, what functionality it checks.
  • Dependencies
• Test case activity
  • Testing environment/configuration contains information about configuration of hardware or software which must be met while executing test case
  • Initialization describes actions, which must be performed before test case execution is started. For example, we should open some file.
  • Finalization describes actions to be done after test case is performed. For example if test case crashes database, tester should restore it before other test cases will be performed.
  • Actions step by step to be done to complete test.
  • Input data description
• Expected results contains description of what tester should see after all test steps has been completed

Sun Tzu

Sun Tzu said: "If words of command are not clear and distinct, if orders are not thoroughly understood, then the general is to blame."
So he started drilling them again, and this time gave the order "Left turn," whereupon the girls once more burst into fits of laughter. Sun Tzu: "If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders ARE clear, and the soldiers nevertheless disobey, then it is the fault of their officers."
So saying, he ordered the leaders of the two companies to be beheaded.

The Rules of Stand Up

1. The first rule of Stand Up is, you do not talk while someone else is talking. 
2. The second rule of Stand Up is, you DO NOT talk while someone else is talking. 
3. You talk fast and you keep it moving fast. 
4. Tell us what you did yesterday. 
5. Tell us what you FAILED to do yesterday. 
6. Tell us what you will do today. 
7. Tell us who is BLOCKING you today. 
8. If this is your first day at Stand Up, you have to talk.

from:- i am pretty sorry, but i do not recall where i found it! I would be happy to link the right source!