Sequentielle Vorgehensmodelle

Transcription

1 Sequentielle Vorgehensmodelle SS 09 Oliver Hummel Seite 1

2 Bringing Order to Process Models Sequenzielle Modelle Phasenmodell Wasserfall-Modell V-Modell Formale Entwicklungsmodelle Prototypische Modelle Iterative Modelle Spiralmodell Inkrementelle Modelle Agile Entwicklungsansätze Scrum, XP... Evolutionäre Modelle Wiederverwendungsorientierte Modelle Rekursive Modelle KobrA Seite 2

3 Phasen- bzw. Wasserfall-Modell requirements Analysis specification Design "Hoffentlich sind die iterativen Interaktionen zwischen den Phasen auf aufeinander folgende Schritte beschränkt." [Royce70] architecture/design Implementation and Unit Testing code Integration and System Testing system Operation and Maintenance Seite 3

4 Meilensteine Stufenweises Phasenmodell: [Benington56] Herbert D. Benington. Production of Large Computer Programs. In: Proceedings of the ONR Symposium on Advanced Programming Methods for Digital Computers, June Wasserfallmodell: [Royce70] Winston W. Royce. Managing the Development of Large Software Systems. Proceedings of the IEEE WESCON Conference, August 1970, pp IEEE, Seite 4

5 More Accurate Waterfall Model requirements Analysis Operation and System Maintenance specification Analysis Analysis Design Design Design Architecture/design Implementation and Unit Testing code Integration and System Testing Implementation and Unit Testing Analysis code Integration and System Testing Design Implementation and Unit Testing code Integration and System Testing.. Implementation and Unit Testing code Integration and System Testing Seite 5

6 Waterfall Model Characteristics Advantages Concrete activities with complete, well-defined products (inputs and outputs) Simple process model for managers Disadvantages premature freezing of artefacts inflexible partitioning of the project into distinct stages insensitive to changing customer requirements high-risk due to big bang integration unrealistic model of the role of maintenance Applicability only feasible when the requirements are well-understood requires large experience with development techniques and tools must include extensive feedback cycles when used in practice Seite 6

7 V-Model waterfall model with elaborated view of validation Requirements analysis Specification validated against validated against Tested System Used System use design Architecture/ Design Tested Modules integration/testing implementation /unit testing Code integration/testing Operation and Maintenance Seite 7

8 Historische Entwicklung des V-Modells Erste Idee kam 1979 von Barry Boehm 1986 wurde es in Deutschland als Entwicklungsstandard bei der Bundeswehr (weiter)entwickelt 1993 als IT-Standard des Bundes auch für zivile Projekte festgeschrieben 1997 wurde das V-Modell 97 mit Anpassungen (z.b. an OO) veröffentlicht 2005 erschien dann das V-Modell XT (für Extreme Tailoring) 2009 in Version 1.3 veröffentlicht regelt, wer wann was im Projekt zu tun hat Seite 8

9 Verification vs. Validation Verification: "Are we building the product right [Boehm] The software should conform to its specification Validation: "Are we building the right product [Boehm] The software should do what the user really requires V & V is a whole life-cycle process must be applied at each stage in the software process has two principal objectives the discovery of defects in a system the assessment of whether or not the system is usable in an operational situation Seite 9

10 Detailliertere Darstellung des V-Modells User's expectations System operation Deployed system User requirements Acceptance test Usable system Requirements specification System testing Executable system System design Integration testing Component specifications Component testing Executable components Component design Component implementation Seite 10

11 V-Model Characteristics Advantages Improved model of verification and validation activities compared to the simple waterfall model Disadvantages Same as waterfall model Applicability Same as waterfall model Seite 11

12 Software Prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options typically used in sequential process models its development is typically also carried out sequentially but, e.g. the spiral model allows for prototypes, too A prototype can e.g. be used in: the requirements engineering process to help with requirements elicitation and validation design processes to explore options and develop a UI design the testing process to run back-toback tests Boehm s second law Prototyping (significantly) reduces requirement and design errors, especially for user interfaces. Seite 12

13 The Prototyping Process Establish prototype objectives De fine prototype func tio nality Develop prototype Evalua te prototype Prototyping plan Outline definition Executa b le prototype Evalua tion report Potential benefits of applying prototyping Improved system usability A closer match to users real needs Improved design quality Improved maintainability Reduced development effort Seite 13

14 Prototypen Prototypen können unterschiedlich realisiert werden, z.b. als UI-Skizze auf Papier oder in PPT ( Slideware ) Ausführbare Prototypen Anpassung eines Altsystem Neuentwicklung Mock-up ausführbare Anforderungsnotation (z.b. SDL) Auswahl erfordert meist eine Abwägung zwischen Aufwand und Nutzen Seite 14

15 Throw-away Prototypes Prototyping can sometimes conflict with incremental development since prototypes may be abused as system increments The objective of incremental development is to deliver a working system to end-users The development starts with those requirements which are best understood The objective of prototyping is to validate or derive the system requirements The prototyping process starts with those requirements which are poorly understood Prototypes should be discarded after development as they are not a good basis for a production system: The prototype s structure is usually degraded through rapid change The prototype probably will not meet normal organisational quality standards and are normally unddocumented It may be impossible to tune the system to meet non-functional requirements Seite 15

16 Formal Specification and Formal Methods Formal specification is part of a more general collection of techniques that are known as formal methods These are all based on mathematical representation and analysis of software and include Formal specification Specification analysis and proof Transformational development Program verification Formal methods have limited practical applicability Their principal benefits are in reducing the number of errors in systems so their main area of applicability is critical (embedded) systems In this area, the use of formal methods is most likely to be cost-effective Bauer-Zemanek hypothesis Formal methods significantly reduce design errors, or eliminate them early. Seite 16

17 Cost of Formal Specification Formal specification involves investing more effort in the early phases of software development This reduces requirements errors as it forces a detailed analysis of the requirements Incompleteness and inconsistencies can be discovered and resolved Hence, savings are made as the amount of rework due to requirements problems is reduced C o s t D e s i g n a n d I m p l e m e n t a t i o n V a l i d a t i o n V a l i d a t i o n D e s i g n a n d I m p l e m e n t a t i o n S p e c i f i c a t i o n S p e c i f i c a t i o n W i t h o u t f o r m a l s p e c i f i c a t i o n Seite 17 W i t h f o r m a l s p e c i f i c a t i o n

18 Acceptance of Formal Methods Formal methods have not become mainstream software development techniques as was once predicted Other software engineering techniques have been successful at increasing system quality Hence the need for formal methods has been reduced Market changes have made time-to-market rather than software with a low error count the key factor Formal methods do not reduce time to market The scope of formal methods is limited They are not well-suited to specifying and analysing user interfaces and user interaction Formal methods are hard to scale up to large systems They require specially trained personnel Domain experts are typically not able to understand the used notations Seite 18

19 Formal Systems Development Similar to the waterfall method based on the transformation of a formal specification through different representations to an executable program The software requirements specification is refined into a detailed formal specification expressed in mathematically profound notations The development steps of design, implementation and unit testing are replaced by transformation steps Transformations are correctness-preserving so it is straightforward to show that the program conforms to its specification F o r m a l t r a n s f o r m a t i o n s T 1 T 2 T 3 T 4 F o r m a l s p e c i f i c a t i o n R 1 R 2 R 3 E x e c u t a b l e p r o g r a m P 1 P 2 P 3 P 4 P r o o f s o f t r a n s f o r m a t i o n c o r r e c t n e s s Seite 19

20 Formal Systems Development Algebraic approach The system is specified in terms of its operations and their relationships Model-based approach The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences Operations are defined by modifications to the system s state Seite 20

21 The Structure of an Algebraic Specification Defining an abstract data type < SPECIFICATION NAME > (Generic parameter) sort < name > imports < LIST OF SPECIFICATION NAMES > Informal description of the sort and its operations Operation signatures setting out the names and the types of the parameters to the operations defined over the sort Axioms defining the operations over the sort Seite 21

22 Specification Components Introduction Defines the sort (the type name) and declares other specifications that are used Description Informally describes the operations on the type Signature (syntax) Defines the syntax of the operations in the interface and their parameters Axioms (semantics) Defines the operation semantics by defining axioms which characterise behaviour Seite 22

23 Kinds of Operations Constructor operations Operations which create or change entities of the type being specified they always deliver a result of the type itself Inspection operations Operations which evaluate entities of the type being specified Typically deliver results of a primitive type To specify behaviour, define the inspector operations for each constructor operation, i.e. n*m axioms At times, complex constructors may defined by using more primitive ones Seite 23

24 2. Example of an Algebraic Specification Specifying a COORD data structure COORD sort Coord imports INTEGER, BOOLEAN Defines a sort representing a Cartesian coordinate. The operations defined on Coord are X and Y which evaluate the x and y attributes of an entity of this sort and Equals which compares two entities of sort Coord for equality. Create (Integer, Integer) -> Coord X (Coord) -> Integer Y (Coord) -> Integer Equals (Coord, Coord) -> Boolean X (Create (x, y)) = x Y (Create (x, y)) = y Equals (Create (x1, y1), Create (x2, y2)) = ((x1 = x2) and (y1 = y2)) Seite 24

25 Operations on a List ADT Constructor operations which evaluate to sort List Create, Cons and Tail Inspection operations which take sort list as a parameter and return some other sort Head and Length. Tail can be defined using the simpler constructors Create and Cons. No need to define Head and Length with Tail Seite 25

26 Specifying a List ADT sort LIST imports INTEGER LIST (Elem: [Undefined -> Elem] Defines a list where elements are added at one end and are removed from the other end. Operations of List are Create, which brings an empty list into existence, Cons, which creates a new list with an additional member added to the end, Length, which evaluates the size of the list, Head, which evaluates the front element of the list, and Tail, which evaluates to a new list with the head element removed. Create -> List Cons (List, Elem) -> List Tail (List) -> List Head (List) -> Elem Length (List) -> Integer Head (Create) = Undefined exception (empty list) Head (Cons (L, v)) = if L = Create then v else Head (L) Length (Create) = 0 Length (Cons (L, v)) = Length (L) + 1 Tail (Create) = Create Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v) Seite 26

27 Formal Systems Development Advantages High quality software High-level of confidence in software correctness Disadvantages Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Applicability mainly embedded systems where safety or security is critical Seite 27

28 Zusammenfassung Sequentielle Vorgehensmodelle durchlaufen die Phasen der Software- Entwicklung nacheinander und gemäß der Grundidee genau ein Mal in den meisten Modellen finden sich allerdings iterative Elemente Prototyping kann in allen Vorgehensmodellen eingesetzt werden um unklare Anforderungen oder deren Umsetzung zu erproben Prototypen sollten danach entsorgt werden (throw away!) Formale Entwicklungsmethoden nutzen formalisierte Modelle versuchen dadurch ein bessere Systemqualität zu erreichen erfordern spezielle Kenntnisse meist für eingebettete und kritische Systeme eingesetzt bei gleichen Qualitätsanforderungen aller Erfahrung nach kaum/nicht teurer als andere Ansätze Morgen (B05) in H0607 beschäftigen wir uns mit den Grundlagen iterativer und agiler Vorgehensmodelle Seite 28