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)