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

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

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

For more core processes 4. Programming 5. Validation and Verification

Supporting processes 6. Requirements management 7. Project management

Supporting processes 8. Quality management 9. Configuration Management 10. Documentation

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

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

However, it contains only under a service contract or Werkliefervertrages and the associated formal acceptance the verifiable services and supplies.

It is not their expectations and wishes for a planned product.

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.

According to DIN (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".

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.

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.

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.

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.

According to DIN contains the target specification the "implementation guidelines developed by the contractor due to the implementation of the client's specification".

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 Specification Often not clearly delimited or even used as a synonym.

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.

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.

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.

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.

However, it contains only under a service contract or Werkliefervertrages and the associated formal acceptance the testable services and supplies.

It can, as well as the specifications, not the expectations and wishes for a planned product.

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.

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.

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.

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".

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.

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.

The contractor shall be entitled to such by the Treaty specific confirmation (obligation to cooperate according to §643 BGB).

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? ).

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.

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

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.

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

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

The aim is, the requirements of the contracting authority to the system to be developed (often a application program) to identify and manage.

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.

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.

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.

Collect, analyze

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

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.

Clearly Defined / defined - Precise definitions help to avoid misunderstandings between developers and the customer.

Understandable Described - So that both the payer and the developer with reasonable effort can read and understand the entire request.

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

Identifiable - Each request must be clearly identifiable (for example, on a identifier or number).

Uniformly Documented - The requirements and their sources in different documents are available or should not have different structures.

Necessary - Statutory provisions are essential.

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).

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.

Consistency - Consistency describes the degree to which the defined requirements are consistent with each other.

The result of the requirements elicitation is the Specifications.

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.

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.

For more structured are Functional and non-functional requirements Technically motivated (professional and technical) and technically motivated (only technical) requirements.

The structured requirements must then be agreed between the customer and developers. This vote may be an iterative process in refining the requirements.

Testing and Evaluation

After the structure, and to some extent in parallel with this, the quality of the requirements laid down in these qualities:

Correctly - The requirements must in particular Consistent .

Feasible - The request must be workable.

Necessary - What is not required by the awarding authority, is not a requirement.

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.

Usable, useful - Also in the case of partial implementation should be already a productive system.

Easy to Use - The user-friendliness of the system must be ensured.

The result of the test is the basis for the Performance specification .

Requirements management RM English "requirements management" includes measures to control, monitoring and management of requirements.

This also includes the Manage changes The requirements and their impact on dependent deliverables.

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.

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

2. Analysis - evaluation In Strict Evaluation Or Strict Evaluation (Engl. Kissing 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.

2. Analysis - evaluation In addition to this, there is the Bedarfsauswertung 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).

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

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 Schonfinkeln.

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

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.

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.

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).

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.

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.

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)

You can obtain this standardization in standard processes and involve cross-group Synchronization REACH.

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.

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.

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.

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.

2. The processes Istanalyse For example the following methods will be used: Benchmarking Vulnerability Assessment Workflowanalyse Checklistentechnik Referenzanalyse Vorgangskettenanalyse

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.

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.

The procedure is applicable to nearly any system, including Physics, Biology, Demography, Economy, Geography, Engineering and Information Technology.

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.

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.

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.

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

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:

DFD (Data Flow Diagram) Data Flow Diagram, IS THE processing and storage of the data streams. STD (state transition diagram. Zustandsubergangsdiagramm, Shows temporal behavior.

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.

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).

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, Augenblicksereignissen and physical flow of matter or energy.

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.

The results of the structured analysis is a hierarchically structured technical requirements document for the system behavior.

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 AnalysisHowever, the later has been extended to methods for dynamic 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.

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.

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.

Data Dictionary (Engl. Data Dictionary, short DD): A collection of all data definitions to be used in the analysis.

The first two diagrams use the following graphical elements: Data Flow, shown as an arrow Data, labeling on the arrow

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

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

The OOA-model can be a static and/or dynamic submodel. It can also contain a prototype of the user interface.

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).

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.

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.

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.

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

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).

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.

While design decisions on local aspects within the architectural framework of the Software, the software architecture is a global property of the whole system.

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.

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.

For example: Unified Modeling Language (UML) Fundamental modeling concepts (FMC)

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, and Cachesystemen - see for example Wikipedia, the free encyclopedia itself - which often include charts (e.g. in the Unified Modeling Language) can be used.

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.

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.

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.

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).

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.

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.

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.

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.

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.

Example Customer Management Menu Is divided into Form Customer And CUSTOMER REPORT. Form Customer Is again divided into Update And Umsatzrabatt, CUSTOMER REPORT In Side View And Print.

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.

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.

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.

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.

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).

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.

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:

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. ...

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.

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. ...

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

Since the end of the 1970s, their fundamentals of Siegfried Wendt and his staff and students at the University of Kaiserslautern.

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. ...

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

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

6. Requirements management

7. Project management Risk Management Project Planning Project tracking and control Management of Vendor

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

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

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)

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

Similar presentations

Presentation on theme: "Bachelor's degree computer science (21) Programming Exercises Part 2"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

Presentation on theme: "Bachelor's degree computer science (21) Programming Exercises Part 2"— Presentation transcript:

Similar presentations

About project

Feedback