Ervaring cbd
1 / 16

Ervaring CBD - PowerPoint PPT Presentation

  • Uploaded on

Ervaring CBD. Main software production accents. Quality Effort Turn-around time. Summary Software Development Methods. 80. 85. 90. 95. 98. 00. Procedural (structured). OO. 25-30%. Components. CORBA Java Beans COM/OLE/ActiveX Own Approach. Software Engineering and Production.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Ervaring CBD' - makana

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Main software production accents
Main software production accents

  • Quality

  • Effort

  • Turn-around time

Summary software development methods
Summary Software Development Methods







Procedural (structured)





Java Beans


Own Approach

Software engineering and production
Software Engineering and Production

BOS - Business Opportunity Scanning

Analysis Phase

Requirements definition

Design Phase

  • independent of development method

  • 10 … 1000 designers

  • ISO

  • Individual phases filled

Implementation Phase

Integration Test Phase

System Test Phase

Design Maintenance

Traditional procedural development
(Traditional) Procedural development

  • Use of SDL/CHILL (15 - 20 years experience), C and assembler

    • structured - modular

    • evolving (OO flavours)

  • very well described development & quality rules

  • Full set of Siemens tools

    • CM, error tracking

    • development tools, compilers

    • debugging tools

  • Siemens OS, software frameworks, hardware platforms

  • Most projects are “Huge projects” (200 - 4000 MY)

  • Relative long turn around times per software release

  • High quality

  • Known risks

Object oriented methodology
Object Oriented Methodology

  • Mid eighties we assumed

    • OO reduces turn-around development time

    • OO improves reusability

    • OO improves quality

    • OO improves testability

    • OO improves management of complexity

    • OO offers better tools

  • In general we thought that:OO is the ideal methodology for small, medium, large projects allowing a fast response to the market.

Oo experience 1
OO experience/1

  • Smaller turn-around times: we do not know

    • training (modelling, coding, tools)

    • object modelling (not that simple)

    • we measured shorter coding times

    • we do not measure an improvement of correctness

  • Reusability

    • less redundant code within the project

    • only a fraction of the code (< 10%) can be reused by other projects (lack of a generic approach, concept, framework)

  • Management of complexity

    • Better anticipation of complex requirements

    • Better software structuring (improved adaptability, patterns)

    • But beware for “aesthetic” (coding) complexity and poetic freedoms

Oo experience 2
OO experience/2

  • Quality

    • source code reuse is limited

    • OO/OOP enables to realise software products of increasing complexity but with the same quality expectations. Quality is largely independent of the programming languageex. first release of software product:

      • C - implementation: 2.4 errors/1000 LOCS

      • C++ - implementation: 2.9 errors/1000 LOCS

        source: datanews,

  • Improved testability

    • correct: improved and simplified methods

    • but : OO does not necessarily guaranties correctness and compliance of imposed requirements.

  • Tools: ???

    • Training, type of project, constraints, limitations, complexity, user interface, ….

Oo experience conclusions by consensus
OO experience: conclusions by consensus

  • OO is NOT a revolution. As such it does not free you from traditional development, management and quality problems. Neither does it ensure a faster turn-around time.

  • OOP as part of OO offers a substantial number of benefits but only covers the aspects “programming” and “testing”.

    • Abstraction, encapsulation

    • inheritance

    • polymorphism (dynamic binding)

    • patterns

  • Moving towards OO development requires an extensive amount of training and coaching

  • The main reason to advocate OO is the fact that OO enables you to challenge complex software systems, in a more conforming way than traditional methodologies

Improving development turn around time and quality
Improving development turn-around time and quality

  • Improvements turn-around time, cost and quality are limited

    • despite of methodology

    • despite of improved training of the design team

    • despite of tools

  • But can possibly be improved by

    • reuse of existing and well-proven source code

    • usage of existing and well-proven binaries

    • I.e. components

Component definition
Component definition

Is an encapsulated piece of code (source or binary) which complies with a well defined and known set of generic and specific rules and functions.

  • Generic rules/functions refer to the need for a “framework”

    • initialisation

    • configuration

    • monitoring

    • exception handling

    • interworking with other components

    • persistency

    • real time behaviour

    • memory utilisation

    • portability

  • Specific rules refer to the expected behaviour

Experience commercial software packages 1
Experience : commercial software packages/1

  • Specific functions : OK

    • we save time: we don’t have to worry about specifications and standards

    • but : we need time for evaluation and selection

  • Quality : OK

    • correctness: good

    • interoperability: good

  • Framework

    • no standardisation (vendor specific)

    • training is needed

    • a lot of glue code is needed

    • portability depends on a limited number of operating systems

    • a lot of time is needed to get the packages up and running

Experience commercial software packages 2
Experience : commercial software packages/2

  • Effort gain (at medium to long term)

    • design maintenance

    • rich(er) feature palette from the beginning

    • synchronisation with evolving standardisation (including de-facto standards)

  • Turn-around time to get first release up and running

    • may not be under-estimated

      • environment aspects not covered by the package

      • lack of a standard framework

    • but you will save time at medium to long term

  • Main risks

    • vendor stops supports the product

    • vendor redesigns the basic concept

Experience component frameworks
Experience: component frameworks

  • Non real time applications

    • CORBA

      • application for multi-level service integration for large networks

      • small turn-around time and a complex multi-hosted application

    • (limited : activeX, beans)

  • real time applications

    • no commercial approach

    • use of own-defined frameworks (limitations)

      • based on experience: set of rules, patterns, code, tools

      • improved portability and reuse of software (within product gamma)

      • improved integration turn-around time

      • improved testability

Experience with own defined frameworks
Experience with own defined frameworks

  • A lot of time and effort is needed to realise a stable specification

  • Acceptance is not obvious

  • Training is required

  • Impact on performance

  • But once accepted

    • better focus on the requirements

    • improved work-split

    • improved off-line testability

    • improved integration

  • We expect

    • improved robustness

    • less design maintenance

Advocating a standard framework
Advocating a standard framework

  • High quality software

    • component specialisation

    • application specialisation

  • Lower application specialisation turn-around time

    • reuse of standard components

    • de-coupling between component and application

  • At long term : lower development effort