Dorte, Ida, Janne, Nikolaj, Alexander og Erla

Præsentationer af emnet: "Dorte, Ida, Janne, Nikolaj, Alexander og Erla"— Præsentationens transcript:

1 Dorte, Ida, Janne, Nikolaj, Alexander og Erla
Software Processes Dorte, Ida, Janne, Nikolaj, Alexander og Erla

2 Hvad er en software proces?
Et struktureret sæt af AKTIVITETER, hvis mål er udvikling af software. En software proces model er en abstrakt repræsentation af en software proces.  (beskrives af gruppe 11)

3 AKTIVITETER Software specification, krav er definerede og afgrænsede
Software development, design og udvikling Software validation, undersøger om produktet er efter kundens ønsker Software evolution, tilpasset til kunder og markedet

4 Software specification
Processen er med til at fastslå hvilke funktioner er nødvendige og hvilke begrænsninger der er i systemets drift og udvikling

5 Requirements engineering proces
Forundersøgelse Krav håndtering og analyse Krav specifikation Krav validering

6 Software development The process of converting the system specification into an executable system. Design is developed iteratively Design process activities: architectural design: Sub-systems and their relationships abstract specification: Services and constraints for each sub-system interface design: The interface for each sub-system is defined component design: Services are allocated to components and component interfaces are designed Data structure Algorithm design

7 Structured methods Is represented as seperate documents
Graphical representations (fx in UML) Examples class diagrams sequence diagrams state diagrams component / deployment diagram dataflow diagram

8 Software validation er produktet efter kundens ønsker?
Component (unit testing) This is normally carried out by programmers(XP) System testing. Functional and non functional requirements. Emerging properties. Multistage process. This is planned. Acceptance testing. Customers data. Reveals requirements problems. The system does not meet the user’s needs. Performance is unacceptable. This is planned. (alpha testing)

9 Software evolution Evolution is concerned with modifying the system after it is in use. Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. The implementation processes contains software preparation and transition activities (forberedelse) The problem and modification analysis process (analyse) Considering the implementation of the modification itself (overvej implementation) The process acceptance of the modification (godkendelse) The migration process (e.g. to another platform without any change in functionality) (overføre til nyt system) Retirement of a piece of software. (slette gammelt)

10 Evolution process Software er fleksibelt of kan ændre sig. Når krav ændrer sig eftersom forretnings omstændigheder ændrer sig, må softwaren som støtter forretningen udvikle sig og ændres. Dette bliver mere og mere irrelevant da færre systemer er helt nye.

11 Proces modeller Waterfall Phase: Operation and maintenance
This phase is virtually never ending phase (Very long). Generally, problems with the system developed come up after its practical use starts, so the issues related to the system are solved after deployment of the system.   - fulfill the changing customer need - adapt to accommodate change in the external environment - correct errors and oversights previously undetected in the testing phase. - enhance the efficiency of the software  Has difficulty accommodation change. Evolutionary: Since this is for short life-times systems, it is not concerned with maintenance (lack of visibility). Component based: The last phase is integration – but does not concern itself with maintenance. Some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.

12 Vandfald vs. Evolutionær
Vandfaldsmodellen: Deler projektet op i faste faser, som ikke overlapper hinanden - modsat evolutionær udvikling. Kravene gennemarbejdes fra starten, hvilket gør det ufleksibelt overfor kundernes ændrede krav. Det er dumt fordi kunderne ofte ikke ved, hvad de vil have og udviklerne måske skal opbygge domæneviden for at finde ud af det for dem. Man skal kun bruge denne model, hvis det er velkendte krav fra starten. Fordelen er at programmets struktur/opbygning bliver bedre og måske mere veldokumenteret.

13 Evolutionær 1/2 Evolutionær bygger på at man udvikler kravene undervejs. Så man starter med dele af kravene og herefter bygger på. Faserne er ikke lige så faste, men overlapper hinanden. Derfor er det en fordel når kundens ønsker udvides/udvikles. Ulempen er at systemet måske bliver bygget lidt roddet fordi det bliver omstruktureret hele tiden. Det er sværere at vedligeholde noget som er ustruktureret og hvor der måske er en del lappeløsninger hist og pist.

14 Evolutionær 2/2 De to typer: Prototype vs. Explorativ Explorativ:
Arbejder tæt sammen med kunden og starter med at udvikle de dele, der er godt forstået, bygger videre på herefter indtil det færdige software. Prototype: Formålet er her at lære kundens krav bedre at kende. Prototypen drejer sig om de dele, der ikke er særlig godt forstået. Ulempe: Svært at vide hvor langt man er nået.