Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Vorlesung "Software-Engineering" zVorige Vorlesung yQualitätsmerkmale  Produkte und Leistungen yProjektphasen und Vorgehensmodelle zHeute yFortsetzung.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Vorlesung "Software-Engineering" zVorige Vorlesung yQualitätsmerkmale  Produkte und Leistungen yProjektphasen und Vorgehensmodelle zHeute yFortsetzung."—  Präsentation transkript:

1 1 Vorlesung "Software-Engineering" zVorige Vorlesung yQualitätsmerkmale  Produkte und Leistungen yProjektphasen und Vorgehensmodelle zHeute yFortsetzung Projektphasen und Vorgehensmodelle yLastenheft yBeginn: Verfahren zur Aufwandsschätzung Prof. Ralf Möller, TUHH, Arbeitsbereich STS

2 2 Vorgehensmodelle (Wdhlg.) zWasser- fall- Modell

3 3 Das Prototypen-Modell (Wdhlg.) zEin fertiges Software-Produkt besteht aus vielen Komponenten und Ebenen. zUnterscheidung zwischen horizontalen und vertikalen Prototypen: Benutzungsoberfläche Systemsoftware vertikaler Prototyp horizontaler Prototyp Anwendung DatenhaltungNetzanbindung

4 4 Projektetablierung Das evolutionäre/inkrementelle Modell zBeobachtung: Software-(Weiter) Entwicklung unterliegt Änderungen zLernen zwischen Entwicklern und Anwendern nötig, da yVeränderungen im technischen und Einsatzkontext stattfinden ysich durch den Einsatz des Systems neue Anforderungen ergeben  Systementwicklung in Ausbaustufen, inkrementelle Entwicklung, Prototyping Revisionsetablierung Projektabschluß System- spezifikation Software- Realisierung Umfeld- Vorbereitung SystemgestaltungPflegeNutzung System- Version Herstellung Einsatz Entwickleraufgabe Nutzeraufgabe

5 5 Risiken bei der Software-Entwicklung

6 6 Das Spiralmodell (1) zFür jedes (Teil-)Produkt sind zyklisch vier Schritte zu durchlaufen: zSchritt 1: yIdentifizierung der Ziele des Teilprodukts (Leistung, Funktionalität, Anpaßbarkeit,...) yAlternative Möglichkeiten zur Realisierung des Teilprodukts finden. yRandbedingungen bei verschiedenen Alternativen finden zSchritt 2: yEvaluierung der Alternativen unter Berücksichtigung aller Alternativen yIdentifizieren und ggf. Überwinden von Risiken (durch Prototypen, Simulation,...) zSchritt 3: yAbhängig vom Risiko wird ein Prozeßmodell festgelegt (oder eine Kombination). yAnwendung des Modells zSchritt 4: yPlanung des nächsten Zyklus, Überprüfung der nächsten 3 Schritte im nächsten Zyklus, Einverständnis mit Beteiligten sichern. zDas Spiralmodell ist eigentlich ein Modell höherer Ordnung

7 7 Das Spiralmodell (2)

8 Das Spiralmodell (3)

9 9 Das Spiralmodell (4) z Eigenschaften yRisikogetriebenes Modell, da Hauptziel die Minimierung des Risikos ist. yZiel: Beginne im Kleinen, halte die Spirale so eng wie möglich und erreiche das Ziel mit minimalen Kosten. z Vorteile: yPeriodische Überprüfung und ggf. Neufestlegung des Prozeßmodells yProzeßmodell ist nicht für die gesamte Dauer des Projekts festgelegt. yFlexibel, leichtere Umsteuerung yErleichtert Wiederverwendung von Software durch Betrachtung von Alternativen. z Nachteile: yHoher Managementaufwand yFür kleine und mittlere Projekte weniger gut geeignet. yWissen über Identifizierung und Management von Risiken ist noch nicht sehr verbreitet.

10 10 OO-Modell: Unified Process (1) z Unified Process: Der UML-Software-Entwicklungsprozeß: yDer Einstieg etabliert das Geschäftsziel und legt den Umfang des Projektes fest. yIn der Erarbeitungsphase werden detaillierte Anforderungen gesammelt, Analyse betrieben und Entwurf grundsätzliche Architekturentscheidungen getroffen sowie der Plan für die Konstruktion gemacht. (use case diagrams) yDie Konstruktion ist ein iterativer und inkrementeller Prozeß. Jede Iteration dieser Phase baut Software- Prototypen mit Produktqualität, die getestet werden und einen Teil der Anforderungen des Projekts umsetzen. (use-case driven) yDie Überleitungsphase enthält den Beta-Test, Leistungssteigerung und Benutzer-Training. Einstieg Erarbeitung Überleitung Konstruktion

11 11 Konstruktion ausführbare Module OO-Modell: Unified Process (2) Erarbeitung Anforderungen bindende Verträge Überleitung Projekt- auslieferung Debugging Kodierung Demonstration Integration Analyse Entwurf

12 12 Wdhlg.: Zeitaufwand je nach Entwicklungsphase

13 13 Konsequenz zErfahrungsgemäß hohe Kosten bei Änderungen in späten Phasen rechtfertigen hohen Aufwand in frühen Phasen zur Vermeidung von späteren Änderungen zEinfluß auf vorgeschlagene „klassische“ Vorgehensmodelle zAber: Kostenreduktion durch aufwendiges Vorgehen in frühen Phasen umstritten zThese: Änderungen sind kaum vermeidbar zDurch neue Vorgehensweisen soll Änderungsflexibilität erhalten bleiben

14 14 Neuere Entwicklungen zExtreme Programming zAgile Modeling zSoftware Product Lines zComponent-Oriented Software Engineering zModel-Driven Archicture z... Wir greifen diese Themen etwas später wieder auf.

15 15 Produktplanung (1) zProduktauswahl Trendstudien, Marktanalysen, Forschungsergebnisse, Kundenanfragen, Vorentwicklungen,... zVoruntersuchung des Produkts yu.U. gezielte Ist-Aufnahme, wenn bereits Vorgängerprodukt vorhanden; anschließend Ist-Analyse yFestlegen der Hauptanforderungen xFestlegen der Hauptfunktionen xFestlegen der Hauptdaten xFestlegen der Hauptleistungen xFestlegen der wichtigsten Aspekte der Benutzungsschnittstelle xFestlegen der wichtigsten Qualitätsmerkmale.

16 16 Produktplanung (2) zDurchführbarkeitsuntersuchung yPrüfen der fachlichen Durchführbarkeit (softwaretechnische Realisierbarkeit, Verfügbarkeit von Entwicklungs- und Zielmaschinen,...) yPrüfen alternativer Lösungsvorschläge (Beispiel: Kauf und Anpassung von Standardsoftware vs. Individualentwicklung) yPrüfen der personellen Durchführbarkeit: Verfügbarkeit qualifizierter Fachkräfte für die Entwicklung yPrüfen der Risiken zPrüfen der ökonomischen Durchführbarkeit yAufwands- und Terminschätzung yWirtschaftlichkeitsrechnung make or buy?

17 17 Problemanalyse und Planung zAnalyse des Ist-Zustandes (Aufgabenbereiche) zSystemabgrenzung yFestlegung, welche Teile zum System gehören und damit Gegenstand der weiteren Untersuchung sind yErmittlung der Umgebungsbedingungen des Systems (Schnittstellen) zSystemerhebung ySammeln und Strukturieren von Informationen über das System und seine Eigenschaften (insbes. Anforderungen u. Änderungswünsche)

18 18 Erhebungstechniken zInterview-Technik yDirekte Befragung der Benutzer/Auftraggeber durch den Analytiker zSchriftliche Befragung yVerteilen, Einsammeln und Auswerten von Fragebögen zBeobachtung yErfassung von Fakten durch den Analytiker ohne direkten Kontakt mit dem beobachteten Aufgabenträger/Arbeitsprozeß zBerichte ySchriftliche Darstellung von Tätigkeitsbereichen

19 19 Gliederung der Systemerhebung zStrukturanalyse zAufgaben- / Ablaufanalyse zKommunikationsanalyse zDokumentenanalyse zDatenanalyse zSchwachstellenanalyse (nach Pomberger/Blaschek)

20 20 Strukturanalyse (auch Organisationsanalyse ) zErfassung und Darstellung des organisatorischen Aufbaus und der damit verbundenen Regelungen (Verantwortlichkeiten, Kompetenzen) zNachweis der einzelnen bearbeitenden Stellen zErfassung des logistischen Zusammenhangs von Aufgaben in der Organisationsstruktur zArbeits- und Darstellungsmittel: yOrganigramme yStellenbeschreibungen yStellenbezogene Prozeßablaufdiagramme

21 21 Organigramm – Beispiel

22 22 Bereiche der Systemerhebung zStrukturanalyse zAufgaben- / Ablaufanalyse zKommunikationsanalyse zDokumentenanalyse zDatenanalyse zAblaufanalyse zSchwachstellenanalyse

23 23 Aufgabenanalyse (auch Prozeßanalyse) zErfassung und Darstellung der anfallenden Operationen/Prozesse zur Erledigung von Aufgaben und ihrer internen Charakteristika zFür jede Operation Angaben zu ybenutzten Daten yproduzierten Daten yAblauf der Operation (Verarbeitungsalgorithmus) zBeispiele für Arbeitstechniken und Hilfsmittel: yEinfache Ablaufpläne/Struktogramme yBlack-Box-Analysen yEntscheidungstabellen y...

24 24 Bereiche der Systemerhebung zStrukturanalyse zAufgaben- / Ablaufanalyse zKommunikationsanalyse zDokumentenanalyse zDatenanalyse zSchwachstellenanalyse

25 25 Kommunikationsanalysen (1) zGegenstand u. Ziele yDarstellung der Austauschbeziehungen von Informationen und Daten zwischen Elementen der organisatorischen Struktur (Aufgaben, Aufgabenträgern) yQuantifizierung der Kommunikation (Volumen, Zeiten, Aufwand/Kosten) yErmittlung qualitativer Merkmale der Kommunikation (Sicherheit, Rechtzeitigkeit etc.) zUnterscheidbare Elemente der Kommunikation: yKommunikationspartner yKommunikationsträger yKommunikationskanäle

26 26 Kommunikationsanalysen (2) zVerschiedene Hilfsmittel zur Erfassung und Darstellung der Kommunikationsbeziehungen, z.B.: yGraphische Kommunikationsnetze yKommunikationsdiagramme (Kommunikationsmatrix) S1 K11 K21 K Kn1 S2 K12 K22 K32 Kn2 E1 E2 E3... En Sm K1m K2m K3m Knm E:Empfänger S:Sender K:Kenndaten der Kommunikationsbeziehung

27 27 Bereiche der Systemerhebung zStrukturanalyse zAufgaben- / Ablaufanalyse zKommunikationsanalyse zDokumentenanalyse zDatenanalyse zSchwachstellenanalyse

28 28 Dokumentenanalyse zErhebung aller im untersuchten System verwendeten und produzierten Dokumente zGrundlage für die Gestaltung von Ein-/Ausgabemasken oder -formularen zInhalt der Dokumentenbeschreibung: yBezeichnung yInhalt yZweck yGrad der Formalisierung yVerteiler yArchivierung

29 29 Datenanalyse (1) zZiel: Klarheit über Art und Umfang der zu verarbeitenden Daten gewinnen zTeilbereiche: yFormale, einheitliche Darstellung aller Datenbestände (Struktur, Wertebereiche) yErfassung der Verarbeitungscharakteristika derDaten (Speicherungsformen, Zugriffsarten, Sicherheitsbedingungen, Datenträger)

30 30 Datenanalyse (2) zErfassung des Datenvolumens (Einzeldaten und Dateien, Wachstum) und Prognose zHäufigkeit und Art der Verarbeitung (Nutzung) und Änderung (Transaktionsanalyse) zAbhängigkeiten zwischen den Daten (Relationen, Konsistenzbedingungen, Reihenfolge der Erstellung etc.)

31 31 Ablaufanalyse zErfassung der Reihenfolge der Operationen und des zInformationsflusses zwischen diesen ("Informationsflußanalyse") zKeine Beschreibung der Operation und der ausgetauschten Daten zZahlreiche graphische Notationen zur Darstellung

32 32 Schwachstellenanalyse zErmittlung von systematischen Mängeln im System zBasis: andere Ergebnisse der Ist-Analyse zSystematische Mängel: Lücken, Redundanzen, Abweichungen von Plan- und Vergleichswerten zIndikatoren für Schwachstellen: yLange Durchlaufzeiten bei Prozessen yHohe Lagerbestände yAbteilungsweise Datenhaltung, yMedienbrüche bei der Datenübermittlung yBezugsgrößen: Planwerte oder Vergleichswerte aus Literatur, früheren Erhebungen, von anderen Unternehmungen

33 33 Lastenheft: Produktanforderungen yAufgabe: Zusammenfassung aller fachlichen Basisanforderungen aus Sicht des Auftraggebers yAdressat: Auftraggeber sowie Auftragnehmer (Projektleiter, Marketing,...) yInhalt: Basisanforderungen („Was?“, nicht „Wie?“) yForm: standardisiertes, numeriertes Gliederungsschema (s. Beispiel) ySprache: verbale Beschreibung yUmfang: wenige Seiten Pflichtenheft: Systemanforderungen

34 34 Beispiel für ein Lastenheft: Seminarorganisation (1) z1 Zielbestimmung yDie Firma Teachware soll durch das Produkt in die Lage versetzt werden, die von ihr veranstalteten Seminare rechnerunterstützt zu verwalten. z2 Produkteinsatz yDas Produkt dient zur Kunden- und Seminarverwaltung der Firma Teachware. Außerdem sollen verschiedene Anfragen beantwortet werden können. yZielgruppe: die Mitarbeiter der Firma Teachware. VersionAutorQSDatumStatusKommentar 2.1SchmidtHupe2/03akzeptiert 2.2SchmidtHupe3/03akzeptiert/LF40/ gelöscht Versions- historie informell

35 35 Beispiel für ein Lastenheft: Seminarorganisation (2) z Produktfunktionen y/LF10/ Ersterfassung, Änderung und Löschung von Kunden (Teilnehmer, Interessenten) y/LF20/ Benachrichtigung der Kunden (Anmeldebestätigung, Abmeldebestätigung, Änderungsmitteilungen, Rechnung, Werbung) y/LF30/ Ersterfassung, Änderung und Löschung von Seminarveranstaltungen und Seminartypen... y/LF70/ Erstellung verschiedener Listen (Teilnehmerliste, Umsatzliste, Teilnehmerbescheinigungen) y/LF80/ Anfragen der folgenden Art sollen möglich sein: Wann findet das nächste Seminar X statt? Welche Mitarbeiter der Firma Y haben das Seminar X besucht? Label /LF.../ zur Referenzierung von Funktionen

36 36 Beispiel für ein Lastenheft: Seminarorganisation (3) z4 Produktdaten y/LD10/ Es sind relevante Daten über die Kunden zu speichern. y/LD20/ Falls ein Kunde zu einer Firma gehört, dann sind relevante Daten über die Firma zu speichern. y/LD30/ Es sind relevante Daten über Seminarveranstaltungen, Seminartypen und Dozenten zu speichern. y/LD40/ Bucht ein Kunde eine Seminarveranstaltung, dann sind entsprechende Buchungsdaten zu speichern. Label /LD.../ zur Referenzierung von Daten

37 37 Beispiel für ein Lastenheft: Seminarorganisation (4) z5 Produktleistungen y/LL10/ Die Funktion /LF80/ darf nicht länger als 15 Sekunden Interaktionszeit benötigen, alle anderen Reaktionszeiten müssen unter 2 Sekunden liegen. y/LL20/ Es müssen maximal Teilnehmer und maximal Seminare verwaltet werden können. Label /LL.../ zur Referenzierung von Leistungen

38 38 z6 Qualitätsanforderungen z7 Ergänzungen [keine] Produktqualität sehr gutgut normal irrelevant Funktionalität x Zuverlässigkeit x Benutzbarkeit x Effizienz x Änderbarkeit x Übertragbarkeit x Beispiel für ein Lastenheft: Seminarorganisation (5)

39 39 Faustregel: Personalkosten: 50 Tsd EUR / Jahr pro Mitarbeiter Verrechnungspreise: 100 – 150 Tsd EUR / Jahr pro Mitarbeiter Aufwandsschätzung zSicht des Software-Herstellers bzw. des Auftragnehmers: zKosten eines Software-Systems: Entwicklungskosten yHauptanteil der Entwicklungskosten: Personalkosten yAnteilige Umlegung der CASE-Umgebungskosten (einschließlich Hardware und Systemsoftware) für die Produktentwicklung yKosten für andere Dienstleistungen, Büromaterial, Druckkosten, Dokumentation, Reisekosten usw. sind im Verhältnis zu den Personalkosten eher gering.

40 40 Methoden zur Kosten- und Terminschätzung zDie meisten Modelle basieren auf dem geschätzten Umfang des zu erstellenden Software-Produktes in „Anzahl der Programmzeilen“ bzw. in Lines of Code (LOC). yBei höheren Sprachen werden z.B. alle Vereinbarungs- und Anweisungszeilen geschätzt. yDer geschätzte Umfang wird durch einen Erfahrungswert für die Programmierproduktivität (in LOC) eines Mitarbeiters pro Jahr oder Monat geteilt. yErgebnis: geschätzter Aufwand in Personenjahren (PJ, auch MJ) oder Personenmonaten (PM, auch MM) y1 PJ = 9 PM oder 10 PM (Urlaub, Krankheit, Schulung,...) yDer so ermittelte Aufwand wird durch die nach der Terminvorgabe zur Verfügung stehende Entwicklungszeit geteilt. yErgebnis: Anzahl der einzusetzenden, parallel arbeitenden Mitarbeiter.

41 41 Einflussfaktoren der Aufwandsschätzung (1) yQuantität yQualität yEntwicklungsdauer yKosten bedingen einander  Teufelsquadrat

42 42 in Planungsphase unbekannt früh bekannt Einflussfaktoren der Aufwandsschätzung (2) zQuantität yGröße des Programmtextes xMaß „Anzahl Programmzeilen“ (LOC) xlineare oder überproportionale Beziehung zwischen LOC und dem Aufwand yFunktions- und Datenumfang xMaß unabhängig von einer Programmiersprache yevtl. zusätzliche Gewichtung mit Komplexität xqualitative Maße, z.B. „leicht“, „mittel“ und „schwer“ xAbbildung auf Zahlenreihe. Beispiel: Noten zwischen 1 und 6. zQualität yJe höher die Qualitätsanforderungen, desto größer ist der Aufwand. yEs gibt nicht die Qualität, sondern es gibt verschiedene Qualitätsmerkmale. yJedem Qualitätsmerkmal lassen sich Kennzahlen zuordnen.

43 43 Zusammenfassung, Kernpunkte zVorgehensmodelle zPlanungs- und Analysephase zIst-Analyse zLastenheft zDurchführbarkeitsuntersuchung yEinfache Techniken der Aufwandsschätzung

44 44 Was kommt beim nächsten Mal? zErweiterte Techniken der Aufwandsschätzung yCOCOMO-Methode yFunction-Point-Methode


Herunterladen ppt "1 Vorlesung "Software-Engineering" zVorige Vorlesung yQualitätsmerkmale  Produkte und Leistungen yProjektphasen und Vorgehensmodelle zHeute yFortsetzung."

Ähnliche Präsentationen


Google-Anzeigen