1 / 16

Ervaring CBD

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.

makana
Download Presentation

Ervaring CBD

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ervaring CBD

  2. Main software production accents • Quality • Effort • Turn-around time

  3. Summary Software Development Methods 80 85 90 95 98 00 Procedural (structured) OO 25-30% Components CORBA Java Beans COM/OLE/ActiveX Own Approach

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

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

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

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

  8. 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, ….

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

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

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

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

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

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

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

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

More Related