Bachelor's degree computer science (21) Programming Exercises Part 2 - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Bachelor's degree computer science (21) Programming Exercises Part 2

Description:

General Information- Sub-areas of the Software Engineering. Core processes 1. Planning. 2. Analysis. 3. Draft – PowerPoint PPT presentation

Number of Views:95
Avg rating:3.0/5.0
Slides: 163
Provided by: mevi
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Bachelor's degree computer science (21) Programming Exercises Part 2


1
Bachelor's degree computer science
(21) Programming Exercises Part 2
2
General Information- Sub-areas of the Software
Engineering
  • Core processes  
  • 1. Planning
  • 2. Analysis
  • 3. Draft

3
General Information- Sub-areas of the Software
Engineering
  • For more core processes
  • 4. Programming
  • 5. Validation and Verification

4
General Information- Sub-areas of the Software
Engineering
  • Supporting processes
  • 6. Requirements management
  • 7. Project management

5
General Information- Sub-areas of the Software
Engineering
  • Supporting processes
  • 8. Quality management
  • 9. Configuration Management
  • 10. Documentation

6
1. Planning
  • The specification (definition)
  • Performance specification (with technical
    approaches refined specifications) 
  • Note in the preparation synonymous with
    "Planning" use

7
1. Planning - Specifications
  • A Specifications (Also Request-Specification,
    KUndenspezifikation Or Requirements
    Specification) Describes the immediate
    requirements of the customer a product.

8
1. Planning - Specifications
  • However, it contains only under a service
    contract or Werkliefervertrages and the
    associated formal acceptance the verifiable
    services and supplies.

9
1. Planning - Specifications
  • It is not their expectations and wishes for a
    planned product. 

10
1. Planning - Specifications
  • These abstract characteristics were, if not
    through a test to show that hardly any person who
    is to produce the product, so that they would be
    helpful to assess could be taken into account.

11
1. Planning - Specifications
  • According to DIN 69905 (project management terms)
    describes the specifications
  • "All of the claims laid down by the contracting
    authority of the goods and services of a
    contractor within an order". 

12
1. Planning - Specifications
  • As a rule, the customer specification
    describes, What and what for Something must be
    done (concept).
  • The addressees of the technical specifications
    are of the (external or internal) contracting
    entities as well as the contractor. 

13
1. Planning - Specifications
  • In the Software Engineering the Customer
    Specification is the result of the planning phase
    and is usually by mutual agreement of the orderer
    and developers as an initial stage of the revised
    specifications.

14
1. Planning - Specifications
  • A specification to keep it manageable, it is
    preferably taken in almost orientierendem Text in
    tabular form and with itemizations for example,
    supplemented with drawings or graphics. 
  • There are also formalized approaches, such as the
    UML notation.

15
1. Planning - Specifications
  • The performance specification describes
    then, What and what Something is to be realized. 
  • Each request can usually one or more services of
    the specification of the Performance
    Specification. 
  • This is also the order of the two documents in
    the development process The requirements
    (Requirements) By services (Features) ARE MET.

16
1. Planning - Specifications
  • According to DIN 69905 contains the target
    specification the "implementation guidelines
    developed by the contractor due to the
    implementation of the client's specification".

17
1. Planning - Specifications
  • Depending on the field of application and
    industry specifications can vary greatly in
    structure and content. In practice, the terms and
    specifications, Performance specification And Spec
    ification Often not clearly delimited or even
    used as a synonym. 

18
1. Planning - Specifications
  • The Fuzzy use of the terms customer specification
    and the performance specification as well as the
    lack of separation technical information and
    operational intentions is often the cause for
    misunderstandings.

19
1. Planning - Specifications
  • German Civil Code (BGB) to the sales contract to
    433 or a legally equivalent supply contract are
    the criteria of a specification in the rule does
    not apply, since the deliveries in the contract
    by the supplier, one-sided specification in the
    way specified by the buyer unilaterally
    determined quantity.

20
1. Planning - Specifications
  • To a service contract are the criteria of a
    specification in the rule does not apply, since
    the services in the service contract does not
    undergo a formal acceptance.

21
1. Planning - Technical Specifications
  • The Performance specification, ALSO
  • Technical Guidelines,
  • Requirement Specification, 
  • Technical Specification,
  • Fachfeinkonzept, 
  • Target Concept, 
  • Functional Specification, OR 
  • Feature Specification 
  • Describes the immediate requirements of the
    customer in the interpretation of the
    manufacturer for his product. 

22
1. Planning - Technical Specifications
  • However, it contains only under a service
    contract or Werkliefervertrages and the
    associated formal acceptance the testable
    services and supplies. 

23
1. Planning - Technical Specifications
  • It can, as well as the specifications, not the
    expectations and wishes for a planned product. 

24
1. Planning - Technical Specifications
  • Such abstract characteristics were, if not by
    examination or measurement to show, by the person
    who produces the product, also not so effective
    that they assess during the processing of the
    work and final acceptance test could be taken
    into account.

25
1. Planning - Technical Specifications
  • The Performance specification The contractually
    binding is to be drawn up, detailed description
    of a plant, for example the construction of a
    technical system, the design of a tool or the
    creation of a computer program.

26
1. Planning - Technical Specifications
  • The work required is the sole responsibility of
    the manufacturer or supplier, this is not subject
    to the objection raised by the Customer or
    Customer's, unless both are working together on
    the plant to be built.

27
1. Planning - Technical Specifications
  • According to DIN 69905, the target specification
    covers the "implementation guidelines developed
    by the contractor due to the implementation of
    the client's performance specification". 

28
1. Planning - Technical Specifications
  • The contents of the previously prepared Technical
    Specifications (Also known as the rough target
    specification) are now specified, complete and
    comprehensible as well as with technical
    specifications of the operational and maintenance
    environment.

29
1. Planning - Technical Specifications
  • The specifications by the contractor
    (engineering/company) and, at the request
    formulated confirmed by the contracting entity.
    Ideally, you should be only after this
    confirmation the actual development/implementation
    activities begin. 

30
1. Planning - Technical Specifications
  • The contractor shall be entitled to such by the
    Treaty specific confirmation (obligation to
    cooperate according to 643 BGB).

31
1. Planning - Technical Specifications
  • In contrast to the technical design (also
    technical specification - how is it implemented?)
    describes the performance specification the
    proposed technical solution - in our example, the
    software - as a black box (which will be
    implemented? ). 

32
1. Planning - Technical Specifications
  • Accordingly, it is usually not the operational
    solution to the challenges of the contracting
    entity. 
  • It certainly does not describe the (here when
    Softwarebeispiel) implementation issues, but only
    the interfaces which, with its careful
    description is to avoid such problems.

33
1. Planning - Technical Specifications
  • It is good practice for the preparation of a
    specification sheet, the A- and to use
    elimination, i.e. , concrete cases explicitly or
    exclude.

34
1. Planning - Technical Specifications
  • At the time of the delivery of the Software is
    formally a decrease has been completed, the
    execution of the service contract or of the
    contract decides. 
  • The decrease is often performed on an acceptance
    test, the software determines whether or not the
    requirements of the specification in the
    understanding of the purchaser meets the.

35
2. Analysis
  • Requirements Analysis 
  • Evaluation 
  • Mock-up 
  • Process Analysis / Process Model 
  • System Analysis 
  • Structured Analysis (SA) 
  • Object-oriented analysis (OOA) 

36
2. Analysis - Requirements Analysis
  • The engineering expertise Collect the
    requirements (English Requirements Engineering)
    Is a part of the Software and Systementwicklungspr
    ozesses.

37
2. Analysis - Requirements Analysis
  • The aim is, the requirements of the contracting
    authority to the system to be developed (often a
    application program) to identify and manage. 

38
2. Analysis - Requirements Analysis
  • IEEE - Institute of Electrical and Electronics
    Engineers 
  • In requirements elicitation requirements
    elicitation can (Requirements elicitation),
    Requirements Analysis (Requirements
    analysis), Requirement specification
    (Requirements specification) And needs assessment
    (Requirements Validation) BE DIVIDED INTO. These
    steps overlap each other and are often also on
    several occasions - iteratively - carried out.
  • Http//www.ieee.org/index.html

39
2. Analysis - Requirements Analysis
  • That Carnegie Mellon 
  • The Software Engineering Institute at Carnegie
    Mellon University is different in your Capability
    Maturity Model Integration the management of
    requirements, and the development of the
    requirements.

40
2. Analysis - Requirements Analysis
  • Volere 
  • In the requirement specification of the
    Robertson's developed process model exist,
    Stakeholder-Analyse , needs analysis, analysis of
    the prioritization, and the recording of the
    basic requirements.

41
2. Analysis - Requirements Analysis
  • Collect, analyze 

42
2. Analysis - Requirements Analysis
  • During Requirements Gathering (engl. elicitation)
    is the translation process between technical
    specialists and developers of particular
    importance. 

43
2. Analysis - Requirements Analysis
  • Fully - All requirements of the customers must be
    explicitly described, there must be no implicit
    assumptions of the customers on the system to be
    developed. 

44
2. Analysis - Requirements Analysis
  • Clearly Defined / defined - Precise definitions
    help to avoid misunderstandings between
    developers and the customer. 

45
2. Analysis - Requirements Analysis
  • Understandable Described - So that both the payer
    and the developer with reasonable effort can read
    and understand the entire request. 

46
2. Analysis - Requirements Analysis
  • Atomic - There should be only one request per
    section or sentence be described. 
  • The criterion for an "Atom" should be the
    Decidability a request. 

47
2. Analysis - Requirements Analysis
  • Identifiable - Each request must be clearly
    identifiable (for example, on a identifier or
    number). 

48
2. Analysis - Requirements Analysis
  • Uniformly Documented - The requirements and their
    sources in different documents are available or
    should not have different structures. 

49
2. Analysis - Requirements Analysis
  • Necessary - Statutory provisions are essential. 

50
2. Analysis - Requirements Analysis
  • Verifiable - The requirements should be linked
    with acceptance criteria, so that at
    the Acceptance Can be used to assess whether the
    requirements have been met (for the derivation of
    test cases from the acceptance criteria). 

51
2. Analysis - Requirements Analysis
  • Re- and vorwartsverfolgbar - So that on the one
    hand is seen, whether each request was completed
    in full for each functionality is implemented
    and, on the other hand is seen, from which you
    request results, not superfluous is developed. 

52
2. Analysis - Requirements Analysis
  • Consistency - Consistency describes the degree to
    which the defined requirements are consistent
    with each other. 

53
2. Analysis - Requirements Analysis
  • The result of the requirements elicitation is
    the Specifications.

54
2. Analysis - Requirements Analysis
  • Structuring and vote 
  • After the capture must be a structuring and
    classification of the requirements will be made. 
  • So that means that the requirements are clearer. 
  • This in turn increases our understanding of the
    relationships between the requirements. 

55
2. Analysis - Requirements Analysis
  • Criteria are
  • Depending on - Requirements must be checked as to
    whether they can be implemented in unison only or
    whether a request is a prerequisite for a Other. 
  • Affinities - Requirements, professional and
    logically together, should not be realized
    alone. 
  • Role-based - Each user group has its own view of
    the requirements, so that should be supported. 

56
2. Analysis - Requirements Analysis
  • For more structured are
  • Functional and non-functional requirements 
  • Technically motivated (professional and
    technical) and technically motivated (only
    technical) requirements. 

57
2. Analysis - Requirements Analysis
  • The structured requirements must then be agreed
    between the customer and developers. 
  • This vote may be an iterative process in refining
    the requirements.

58
2. Analysis - Requirements Analysis
  • Testing and Evaluation

59
2. Analysis - Requirements Analysis
  • After the structure, and to some extent in
    parallel with this, the quality of the
    requirements laid down in these qualities

60
2. Analysis - Requirements Analysis
  • Correctly - The requirements must in
    particular Consistent . 

61
2. Analysis - Requirements Analysis
  • Feasible - The request must be workable. 

62
2. Analysis - Requirements Analysis
  • Necessary - What is not required by the awarding
    authority, is not a requirement. 

63
2. Analysis - Requirements Analysis
  • Prioritized - It must be possible to identify
    which requirements are most important. 
  • Goal of the prioritization is often required
    before the less frequently used functions. 
  • You can reach it via a quantification of the
    Funktionszweige. 

64
2. Analysis - Requirements Analysis
  • Usable, useful - Also in the case of partial
    implementation should be already a productive
    system. 

65
2. Analysis - Requirements Analysis
  • Easy to Use - The user-friendliness of the system
    must be ensured. 

66
2. Analysis - Requirements Analysis
  • The result of the test is the basis for
    the Performance specification .

67
2. Analysis - Requirements Analysis
  • Requirements management RM
  • English "requirements management" includes
    measures to control, monitoring and management of
    requirements. 

68
2. Analysis - Requirements Analysis
  • This also includes the Manage changes The
    requirements and their impact on dependent
    deliverables.

69
2. Analysis - evaluation 
  • Evaluation (Engl. Evaluation As the description,
    analysis and evaluation) in the computer science
    the process of an expression (possibly in a given
    context of variable bindings) Assign a value.

70
2. Analysis - evaluation 
  • Programming Languages After your boolean are
    distinguishable

71
2. Analysis - evaluation 
  • In Strict Evaluation Or Strict Evaluation (Engl. K
    issing the Frog Or Strict evaluation) Are
    expressions evaluated right away. For example,
    for the calculation of a function are evaluated
    in strict evaluation The Argumentausdrucke
    Funktionsrumpf is evaluated before the. 

72
2. Analysis - evaluation 
  • In addition to this, there is the Bedarfsauswertun
    g Or Delayed Evaluation (Engl. Lazy evaluation),
    The expressions are evaluated only if their value
    in a calculation is required. 
  • This can be for example an infinite large data
    structures (e.g. , the list of all natural
    numbers, the list of all prime numbers, etc. )
    define and certain algorithms can be simplified. 
  • These data structures are called currents
    (engl. Streams). 

73
2. Analysis - evaluation 
  • Some calculations can be with strict evaluation,
    others with Bedarfsauswertung more efficiently.

74
2. Analysis - evaluation 
  • In the evaluation of functions with multiple
    arguments, there is a further Degree of
    Freedom In it, in what order the arguments are
    evaluated. 
  • In the theoretical Computer Science (Lambda
    Calculus) IS FORMALLY shown that the order of
    evaluation is irrelevant, as far as the
    calculated value of the expression, so he can be
    evaluated see also Permits Currying Or Schonfinke
    ln.

75
2. Analysis - evaluation 
  • The Application The function (or function) to the
    arguments put forward are also referred to
    as Application.

76
2. Analysis - evaluation 
  • Closely related to the concept of the evaluation
    is the concept of Semantics, This is a figure, a
    program (usually a Program Text or source code)
    his Predictable Maps feature. 
  • This agrees with the colloquial interpretation of
    the concept of semantics as Bedeutungszuordnung
    agree well.

77
2. Analysis - mock-up
  • A mock-up in software development means a
    rudimentary Wegwerfprototyp the user interface of
    a software to be built. 
  • Mock-ups are used in particular in the early
    stages, to requirements for the user interface in
    co-operation with the customer and users better
    identify. 
  • This is usually a pure basic set-up of the
    controls without any further functionality.

78
2. Analysis - mock-up
  • So-called Mocks When testing be used, what in
    particular when Unit test Is used. 
  • At the beginning of the development you will be
    as a placeholder for not yet used existing
    objects, if the not yet existing components for
    the test of another module are necessary (see
    also Test Driven Development). 

79
2. Analysis - mock-up
  • Mocks come in later phases to application,
    because, for example, the initialization of the
    (existing, functional) object too difficult or
    lack of a connection in a lab environment to
    productive back-end systems is not possible. 

80
2. Analysis - mock-up
  • Another common reason for the use of a
    Mock-Objektes is a nichtvorhersehbares behavior
    of the actual class, for example, the return of
    the current exchange rate or behavior, but the
    result of the object-oriented principle
    of Encapsulation Before the caller of the method
    this is in newer environments such
    as J2EE Especially in the case container
    functions.

81
2. Analysis - Process Analysis
  • As Process Analysis Is defined as the systematic
    study of Business Processes (Lat. procedure
    Progress) and the cutting into its component
    parts, in order to identify weaknesses and areas
    for improvement. (See Generic term analysis)

82
2. Analysis - Process Analysis
  • You can obtain this standardization in standard
    processes and involve cross-group Synchronization 
    REACH.

83
2. Analysis - Process Analysis
  • Especially in the Quality management It is
    essential, when errors occur as quickly to
    discover the cause(s) and initiate corrective
    measures. 
  • This Continuous Improvement Process (CIP) helps
    also in related processes to intervene quickly
    and efficiently, as sub-processes may be similar
    or the same.

84
2. Analysis - Process Analysis
  • Process-oriented thinking and acting is an
    important part of the modern market economy. Only
    in this way can we operate in a flexible manner
    within a short period rather than just react
    (fault prevention before troubleshooting). 
  • By the proactive act problems can usually be
    solved in advance.

85
2. Analysis - Process Analysis
  • The exact description of processes is just as
    important as their constant care and control. 
  • Information provided by the processes with the it
    will also find Key Indicators Made it easier to
    allow a process to assess.

86
2. Analysis - Process Analysis
  • Implementation of process analysis. The process
    analysis will be carried out in two steps
  • 1. Current status of the existing organization
  • This will be evaluated and, where appropriate
    organizational and working papers 
  • Employee interviews carried out. 

87
2. Analysis - Process Analysis
  • 2. The processes Istanalyse 
  • For example the following methods will be used
  • Benchmarking 
  • Vulnerability Assessment 
  • Workflowanalyse 
  • Checklistentechnik 
  • Referenzanalyse 
  • Vorgangskettenanalyse 

88
2. Analysis - systems analysis
  • The System Analysis Is a practical method of
    systems theory. 
  • Designed in the viewer of the system a model of a
    pre-existing or planned system as a black box and
    refined first this in the further course. 

89
2. Analysis - systems analysis
  • The editor has a selection of the relevant
    elements and relations of the system. 
  • The created model is always a limited, reduced,
    abstracted representation of reality, with the
    help of past and future developments and
    behaviors of the system are to be made in certain
    scenarios. 

90
2. Analysis - systems analysis
  • The procedure is applicable to nearly any system,
    including 
  • Physics, 
  • Biology, 
  • Demography, 
  • Economy, 
  • Geography, 
  • Engineering and Information Technology.

91
2. Analysis - systems analysis
  • What is system analysis? 
  • The holistic approach systems analysis is an
    iterative, heuristic and ruckgekoppelter process
    by the dimensions
  • Organization,
  • Technology and Motivation 
  • Can be characterized.

92
2. Analysis - systems analysis
  • Work for a systems analysis
  • Set the system boundaries to distinguish between
    system and environment. 
  • Notice of those system components that the be
    seen as relevant for the question. 

93
2. Analysis - systems analysis
  • Determine those relations between system
    elements, for the question are considered
    relevant. 
  • Determine the System Properties at the macro
    level. 
  • Determine the relationship of the system to the
    environment or to other systems, if the
    consideration of the system as an isolated or
    closed system to an open system is inescapable. 

94
2. Analysis - systems analysis
  • Presentation
  • Representation of the analysis results
  • Qualitative Concept-Map, flowchart,
    Wirkungsdiagramme 
  • Semi-quantitative stretches across (depending
    on-the-relations) 
  • Quantitative x-y, x-t-charts etc. , mathematical
    equations 

95
2. Analysis - systems analysis
  • Formal Methods for system analysis and graphical
    methods will be used.
  • Edwards Taking care of it in his work with the
    following elements, in order to represent various
    Muster-Systeme

96
2. Analysis - systems analysis
  • DFD (Data Flow Diagram) 
  • Data Flow Diagram, IS THE processing and storage
    of the data streams. 
  • STD (state transition diagram. 
  • Zustandsubergangsdiagramm, Shows temporal
    behavior. 

97
2. Analysis - systems analysis
  • ERD (Entity Relationship Diagram) 
  • Entity-relationship model introduced diagram,
    provides data links with each other. 
  • ESTD (Entity State Diagram) 
  • Gegenstands-Zustands diagram, as a hybrid from
    STD and ERD. Displays status changes in relation
    to the time events. 

98
2. Analysis - systems analysis
  • Yet still he shall designate the following
    theoretically possible combinations, but only
    very limited practically useful
  • Mapping between Datenstromdarstellung and data
    stores (for verification). 
  • Temporal Change of data processing by control
    signals (to check). 

99
2. Analysis - systems analysis
  • The derivation of conditions ( "States") by
    events ( "events") and vice versa is possible. 
  • A permanent limitation to a for the respective
    Detailierungsebene meaningful Elementmenge is
    necessary in order to a kick, i.e. transparent
    and thus usable result. 
  • The representation distinguishes between
    Steuerstromen, data streams, Augenblicksereignisse
    n and physical flow of matter or energy.

100
2. Analysis - Structured Analysis (SA)
  • The Structured Analysis (SA) Is a mainly by Tom
    DeMarco developed method to create a formal
    system description in the framework of the
    software development. 
  • It is used during the analysis phase of a
    software project. 
  • The results of the SA Structured Design refined
    so that they can then be implemented. It is a
    method of system analysis.

101
2. Analysis - Structured Analysis (SA)
  • The results of the structured analysis is a
    hierarchically structured technical requirements
    document for the system behavior. 

102
2. Analysis - Structured Analysis (SA)
  • The structured analysis is a graphical analysis
    method, which, with the help of a top-down
    approach in a complex system ever simpler
    functions or processes and, at the same time
    divides a Datenflussmodellierung Performs. 
  • In its basic form is the SA a Static AnalysisHowev
    er, the later has been extended to methods for
    dynamic analysis.

103
2. Analysis - Structured Analysis (SA)
  • Structured Analysis 
  • In the structured analysis will be used
    following elements
  • Context Diagram, (Engl. Context-Diagram) 
  • This chart is the Root The Analyse-Baums . It
    borders the system from its environment and thus
    defines which aspects of the analysis are
    considered and which are not. 

104
2. Analysis - Structured Analysis (SA)
  • Data Flow Diagram (Engl. Data Flow Diagram,
    briefly DFD) A DFD visualized in what
    sub-processes on the DFD process divides and how
    the use of the data in this process works. 

105
2. Analysis - Structured Analysis (SA)
  • Minispezifikation (Engl. Mini-Specification) The
    Mini-Spec is a formal description of a in the
    context of the analysis no longer
    Elementarprozesses further split. 
  • The description is made with the help of
    a Pseudo Code, The non-standardised and is
    generally based on the programming language used
    is based on the later. 
  • Further possibilities of description are
    decision tables and trees. 

106
2. Analysis - Structured Analysis (SA)
  • Data Dictionary (Engl. Data Dictionary, short
    DD) 
  • A collection of all data definitions to be used
    in the analysis. 

107
2. Analysis - Structured Analysis (SA)
  • The first two diagrams use the following
    graphical elements
  • Data Flow, shown as an arrow 
  • Data, labeling on the arrow 

108
2. Analysis - Structured Analysis (SA)
  • Memory, two parallel horizontal lines, in between
    the name of the store 
  • Part and elementary processes, circle with the
    name and number of the sub-process in the center
    of the circle 
  • External receiver/transmitter (only on the
    context diagram,), square with encap Name 

109
2. Analysis - Structured Analysis (SA)
  • Structured Real-Time Analysis (RT) 
  • The structured Real-Time Analysis extends the
    normal structured analysis to a real-time
    component. 

110
2. Analysis - Structured Analysis (SA)
  • This is achieved through the establishment of the
    behavior of the Prozessschicht under all possible
    external and internal conditions and operating
    modes. 
  • The system was designed by Imtiaz A. Pirbhai and
    Derek J. Hatley.

111
2. Analysis - Structured Analysis (SA)
  • Dynamic Analysis 
  • In addition to the definitions of the static
    analysis are defined the following additional
    elements
  • Decision Table (Engl. Decision Table, short DT)
    From several input values in tabular form is
    defined as the baseline is set. 

112
2. Analysis - Structured Analysis (SA)
  • Zustandsubergangsdiagramm (Engl. State Transition
    Diagram, short STD) 
  • States are in this chart as squares and
    transitions depicted as arrows. 
  • The STD has inputs and outputs, depending on the
    set of the transitions and states. 

113
2. Analysis - Structured Analysis (SA)
  • Prozessaktivierungstabelle (Engl. Process
    Activation table, short PAT) 
  • The table describes the activation sequence of
    the processes listed in the table.
  • A DFD always contains only one PAT and as many DT
    and hours. All three of these new elements are
    graphically represented by a vertical line.
    Arrows from the left are the input, the output
    parameter arrows to the right.

114
2. Analysis - Structured Analysis (SA)
  • Kontrollflusse (Engl. Control Flow) 
  • Be shown as dotted arrow on Kontrollflusse only
    data with Boolean Definition sent.
  • These are used to control the DT and STD and
    bear no real data, but serve only the modeling of
    the dynamic process. 

115
2. Analysis - Structured Analysis (SA)
  • Use in practice 
  • One of the largest software projects, with the
    help of the structured analysis undertaken in
    Germany, is the software for the central computer
    of the Tornado fighter jet.

116
2. Analysis - Structured Analysis (SA)
  • Otherwise, the structured analysis in many places
    by the Unified Modeling Language REPLACED, but is
    still used in many projects.
  • Software tools
  • Innovator of MID 
  • Case/4/0 of Microtool 

117
2. Analysis - OO analysis and design 
  • Object-oriented analysis and design (OOAD) Is a
    phase of object-oriented design, which is located
    in the part of the domain modeling (object
    oriented analysis) and the part of the system
    design (Object Oriented Design) which breaks down
    into.

118
2. Analysis - OO analysis and design 
  • In the Analysis It is a question, to record and
    describe the requirements, to be developed by the
    software system should meet. 
  • Greatly simplified expressed during this phase
    is looking for and collects all the facts, and
    examines this is you. 
  • This happens often in the form of a textual
    specifications or the Software Requirements
    Specification. 

119
2. Analysis - OO analysis and design 
  • Based on the object-oriented analysis model
    (OOA-model) is a technical description with
    object-oriented concepts, often with elements
    of Unified Modeling Language (UML) Listed. 
  • It emphasizes the essential and can be
    unimportant way. A reference to information
    technology is particularly undesirable in this
    phase. 

120
2. Analysis - OO analysis and design 
  • The OOA-model can be a static and/or dynamic
    submodel. It can also contain a prototype of the
    user interface.

121
2. Analysis - OO analysis and design 
  • When Object-oriented design The domain model
    created in the analysis and, on that basis
    developed a system design created. 
  • The design takes into account not only the
    technical aspects of the customer from the
    analysis and technical conditions. 
  • The next phase in a Wasserfall-Vorgehensmodell
    object-oriented programming (OOP).

122
2. Analysis - OO analysis and design 
  • Process Models
  • Several authors and manufacturer of commercial
    tools have attempted, the developers through the
    description of process models a collection of
    tools to provide the co-operation of the intended
    to those involved in the development, to improve
    the communication with the customer, to improve
    the understanding of their own draft to
    standardize the documentation and to deepen.

123
2. Analysis - OO analysis and design 
  • UML
  • The success was a, Rational Software Corporation
    in the company as the three dominant authors
    James Rumbaugh, and Ivar Jacobson , Booch Grady
    together a first version of the United modeling
    language Unified Modeling Language (UML) drawn
    up. 

124
2. Analysis - OO analysis and design 
  • They have a common notation for representation of
    modeling results agreed. 
  • UML is now by the Object Management Group (OMG)
    standardized and has proved itself in practice
    and enforced. However, it is also more of a UML
    Tool Box as a clear procedural model.

125
3. Draft
  • Software Architecture
  • Structured Design (SD) 
  • Object-oriented design (OOD) 
  • Unified Modeling Language (UML) 
  • Fundamental modeling concepts (FMC) 

126
3. Draft - Softwaerarchitektur 
  • A Software Architecture Describes the basic
    components and their interaction within a
    software system. 
  • Helmut Balzert describes a definition of the term
    as a "A structured or hierarchical arrangement of
    the system components, as well as description of
    your relations" (Lit. Balzert, p. 716). 

127
3. Draft - Softwaerarchitektur 
  • The described components form a disassembly of
    the entire system, i.e. each Softwareelement is
    uniquely assigned to a architecture.
  • The software architecture is distinguished from
    software design.

128
3. Draft - Softwaerarchitektur 
  • While design decisions on local aspects within
    the architectural framework of the Software, the
    software architecture is a global property of the
    whole system.

129
3. Draft - Softwaerarchitektur 
  • In the context of the software development The
    software architecture represents the earliest
    Softwaredesign-Entscheidung (architectural
    design). 
  • You will be much more by non-functional
    characteristics such as ability, maintainability,
    safety or performance. 

130
3. Draft - Softwaerarchitektur 
  • Once a software architecture is furnished only
    with a great deal of effort later demands this
    absolutely. 
  • The decision on the design is thus one of the
    most critical and most important points in the
    development of software. 
  • Graphical visualization of software
    architectures will use different methods. 

131
3. Draft - Softwaerarchitektur 
  • For example
  • Unified Modeling Language (UML) 
  • Fundamental modeling concepts (FMC) 

132
3. Draft - Softwaerarchitektur 
  • Deals with the evaluation of software
    architectures the Softwarearchitekturbewertung.
  • Example 
  • A Architekturbeschreibung includes approximately
    in the case of a Web application from the
    composition of the system databases,
    web/application deployers, e-mail and
    Cachesystemen - see for example Wikipedia, the
    free encyclopedia itself - which often include
    charts (e.g. in the Unified Modeling Language)
    can be used.

133
3. Draft - Structured Design
  • Structured Design (SD) is a design pattern in
    software engineering after Edward Yourdon and
    Larry Constantine, which modular design supports,
    in addition to the basic capability hierarchy
    also to describe the interactions of parent
    modules. SD will be with the structured analysis
    (SA) used in software engineering.

134
3. Draft - Structured Design
  • The structured design provides a bridge between
    the technology-neutral analysis and the actual
    implementation. 
  • Structured Design will be introduced in the
    Technical boundary conditions and the general
    structure of the system from a technical point of
    view. 
  • Hence, it is planning the content of the
    implementation.

135
3. Draft - Structured Design
  • The methodology is hierarchically using your
    structural diagrams Functional modules and shows
    the individual Aufrufhierarchien the modules to
    each other. 
  • A functional module consists of one or several
    functional abstractions. 

136
3. Draft - Structured Design
  • This in turn is one of the first abstraction
    mechanisms and grouped multiple related program
    instructions to units (functions). 
  • An example would be the calculation of the
    square root sqrt(x). 

137
3. Draft - Structured Design
  • The user must know no details about the
    implementation, but applies the function only. 
  • In order to do this he needs a corresponding
    interface description, the just as much a part of
    the structured design is one such as creating the
    enables you.

138
3. Draft - Structured Design
  • A functional module has no internal Memory- In
    other words, it does not include data (private
    data), the only in the module are visible. 
  • It can only be in global data deposit information
    (for example, when the calculation of a random
    number). 
  • Later on it-based methods, such as the Modular
    Design (MD), abstract data types and data objects.

139
3. Draft - Structured Design
  • In the banking, insurance and even find the
    embedded system developments with many structured
    methods has taken place. 
  • In particular, in the field of m-business (
    mobile business computing systems) are often
    used, the limited resources for the
    object-oriented implementation with your overhead
    is too expensive. 

140
3. Draft - Structured Design
  • Furthermore, in the framework of the integration
    of existing applications in the context of EAI
    often subsystems to realize, not with
    object-oriented languages can be implemented. 
  • Therefore, object-oriented analysis and design
    wrong preparing for the implementation.

141
3. Draft - Structured Design
  • Function-oriented method 
  • Tasks are top-down in sub-tasks disassembled and
    then this on the modules shown (principle of
    modularization).
  • Specification methodology are structural diagrams
    in which the modules and the connections between
    modules are displayed.

142
3. Draft - Structured Design
  • Example
  • Customer Management Menu Is divided into Form
    Customer And CUSTOMER REPORT.
  • Form Customer Is again divided into Update And Ums
    atzrabatt, CUSTOMER REPORT In Side View And Print.

143
3. Draft - OO design
  • Object-oriented analysis and design (OOAD) Is a
    phase of object-oriented design, which is located
    in the part of the domain modeling (object
    oriented analysis) and the part of the system
    design (Object Oriented Design) which breaks down
    into.

144
3. Draft - OO design
  • In the Analysis It is a question, to record and
    describe the requirements, to be developed by the
    software system should meet. 
  • Greatly simplified expressed during this phase
    is looking for and collects all the facts, and
    examines this is you. 
  • This happens often in the form of a textual
    specifications or the Software Requirements
    Specification. 

145
3. Draft - OO design
  • Based on the object-oriented analysis model
    (OOA-model) is a technical description with
    object-oriented concepts, often with elements of
    the Unified Modeling Language (UML) Listed. 
  • It emphasizes the essential and can be
    unimportant way. 

146
3. Draft - OO design
  • A reference to information technology is
    particularly undesirable in this phase. The
    OOA-model can be a static and/or dynamic
    submodel. It can also contain a prototype of the
    user interface.

147
3. Draft - OO design
  • When Object-oriented design The domain model
    created in the analysis and, on that basis
    developed a system design created. 
  • The design takes into account not only the
    technical aspects of the customer from the
    analysis and technical conditions. 
  • The next phase in a Wasserfall-Vorgehensmodell
    object-oriented programming (OOP).

148
3. Draft - UML
  • The Unified Modeling Language (UML, Engl. Unified
    Modeling Language has become) Is one of the
    Object Management Group (OMG) developed and
    standardized language for the modeling of
    software and other IT systems. 
  • In the sense of a language defines the UML this
    identifier for most of the terms are important
    for the modeling, and sets out possible relations
    between these terms. 

149
3. Draft - UML
  • The UML graphical notations are further defined
    for these terms and for models of static
    structures and dynamic processes that you can
    formulate with these terms.
  • UML is one of the dominant languages for the
    modeling of operational application systems
    (Software Systems). 
  • The first contact with the UML is the fact that
    very often in the context of the UML diagrams of
    software projects to create, to understand or to
    assess are

150
3. Draft - UML
  • Project Sponsor and representatives for example
    check and confirm requirements of a system, the
    business analysts in Use Case Diagrams of the
    UML. 
  • Software developers implement workflows, the
    business analysts in cooperation with scholars
    have described in Activity Diagrams. 
  • System engineers install and operate software
    systems based on a layout diagram, there is the
    as a deployment diagram. 
  • ...

151
3. Draft - UML
  • The graphical notation is, however, only one key
    aspect that the UML is regulated. 
  • The UML specifies in the first line, with the
    terms and the relations between these concepts
    so-called Models Be Specified - diagrams of the
    UML only show a graphical view of clippings of
    these models. 

152
3. Draft - UML
  • The UML also proposes a format in the models and
    diagrams between tools can be replaced.
  • A process model, which applies the UML, because
    of the strict formalisation can be no agile
    process.
  • ...

153
3. Draft - fundamental modeling concepts
  • Fundamental modeling concepts (FMC) Is a
    semi-formal methodology for communication via
    complex software systems.

154
3. Draft - fundamental modeling concepts
  • Since the end of the 1970s, their fundamentals of
    Siegfried Wendt and his staff and students at the
    University of Kaiserslautern.

155
3. Draft - fundamental modeling concepts
  • At the 1999 founded under the leadership of
    Siegfried Wendt Hasso-Plattner -Institute at the
    University of Potsdam, these concepts initially
    under the name spikes (STructured PLANS
    for IMproving KNowledge Transfer in EWe develop
    of Systems) taught in 2001, before the name FMC
    (FUndamental MOdeling COncepts) received. 
  • ... 

156
4. Programming
  • Standardized programming 
  • Structured programming 
  • Object-oriented programming (OOP) 
  • Functional Programming 

157
5. Validation and Verification
  • Module Testing ( Low-level test) 
  • Integration tests ( Low-level test) 
  • System tests ( high-level test) 
  • Acceptance Testing (high-level test) 

158
6. Requirements management
159
7. Project management
  • Risk Management
  •  
  • Project Planning
  • Project tracking and control 
  • Management of Vendor 

160
8. Quality management
  • Capability Maturity Model 
  • Spice (Standard) (Software Process Improvement
    and Capability Determination) 
  • Incident Management 
  • Problem Management 
  • Softwaremetrik (measurement software properties) 
  • Static Analysis (calculation of weaknesses) 
  • Software Ergonomics 

161
9. Configuration Management
  • Versioning
  • Change Management / Change Management 
  • Release Management 
  • Application Management (ITIL) 

162
10. Documentation
  • Software-Dokumentationswerkzeug 
  • System documentation (further development and
    troubleshooting) 
  • Operational documentation (carrier/service)
  •  
  • Owner's Manual (User) 
  • Business Processes (concept of development) 
  • Process Documentation (description legally
    relevant software processes) 
About PowerShow.com