ervaring cbd
Download
Skip this Video
Download Presentation
Ervaring CBD

Loading in 2 Seconds...

play fullscreen
1 / 16

Ervaring CBD - PowerPoint PPT Presentation


  • 98 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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

80

85

90

95

98

00

Procedural (structured)

OO

25-30%

Components

CORBA

Java Beans

COM/OLE/ActiveX

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
ad