SW Development in Network Solutions & Communication Services

1. Jos Huybrighs (ICN NC SD) joseph.huybrighs@siemens.atea.be SW Developmentin Network Solutions &Communication Services

2. ICN NS/CS: Development Domains • Enterprise systems: • Inter-PBX Signaling Protocol Conversion • PSTN/ISDN Signaling Protocol Conversion • Telecommuting • DECT • VPN • PBX-to-PBX signaling tunneling through PSTN/ISDN/Internet/Intranet • Carrier systems: • VPN combined with VoIP: VPN-IP • Residential Gateway

3. Facts and Figures • ICN NS/CS • Number of SW designers: 30 • > 5 years experience: 20 • OO experience: 90% • Architects / System Designers: 3 • SW/HW Integration specialists: 4 • Development split (effort) • HW (including layout, mechanical eng.): 10% • SW: 90% • Team organization • HW: 1 person • SW: 8..15 persons • Development Cost versus Total Cost • Total Cost = Development Cost x 

4. Enterprise Applications + VPN Wireless Server CDG Leased Line DECT/Line Interface Protocol Conversion Up0 Up0 VPN: PNE Telecommuting Server Wireless Domain DECT ECG signaling Telecommuting Client PSTN/ISDN PSTN/ISDN S0 Card Protocol Conversion Up0 OTO PSTN/ISDN Domain Inter-PBX Signaling

5. Enterprise Applications:DECT Line Card (CMI) • HW: Motorola 683xx • RTOS: COSMOS (own Siemens RTOS) • SW: All own development, ‘C’ • Main characteristics: • Protocol handling towards DECT basestations (ISDN-like) • DECT handset signalling conversion to Optiset protocol (stimulus) • Tools: Greenhills • Cost Constraints: • Memory size • Issues: • Hard real-time constraints during initialization • Multi-site development • Cost (Siemens Atea): • 10 developers • 30 PY

6. Enterprise Applications:VPN (PNE) • HW: AMD ELAN • RTOS: Own asynchroneous method schedular • SW: Mostly own development, except C++ Booch Components, C++ • Main characteristics: • Inter-PBX protocol handling (30 channels) • Bearer/Signaling separation and tunneling over a number of data transport networks (x.25, IP, modem, in-band). • Remote management using proprietary protocols. • Tools: • OMT Modeling: StP • Cadul • Cost constraints: • Not really • Issues: • 1st OO/C++ project • Testability • Hard real time constraints in some type of applications (e.g. in-band tone detection) • Cost: 30 PY

7. Enterprise Applications:Protocol Conversion (CDG) • HW: Intel 80188 • RTOS: COSMOS • SW: All own development, ‘C’ • Main characteristics: • Signaling protocol conversion between different inter-PBX protocols • Remote management using proprietary protocols. • Tools: • Microsoft C, Linker/Locator (Intel) • Intel ICE • Cost constraints: • Not really • Issues: • More or less hard real time constraints, depending on protocols • Cost: 20 PY

8. Enterprise Applications:Protocol Conversion - ECG • Based on the PNE platform • Reuse of hardware and software • Main characteristics: • Signaling protocol conversion between ‘old’ PSTN protocols and ISDN. • Cost constraints: • Not really • Issues: • More or less hard real time constraints when capturing incoming line signals • Cost: 10 PY

9. Clarent IP Gateway Clarent IP Gateway Managed IP-network ISDN / PSTN Clarent IP Gateway VPN-IP VoIP / H323 Q.SIG/DPNSS Tunneling EDSS1 Internet Access PSR -Private Signaling Router PSR -Private Signaling Router Q-SIG/ DPNSS1 PBX PBX EDSS1 PBX P S R

10. VPN-IP: Characteristics • VPN-IP • Based on PNE platform and functionality • Main characteristics: • Idem as PNE, but transport of voice and data over IP • VoIP through external Clarent gateway • PNE hardware doesn’t have Ethernet interface - Special V.24 interface needed to the external VoIP gateway to pass signaling through an IP network. • Cost constraints: none • Issues: relatively straightforward • Cost: 5 PY

11. VoIP Gateway Residential Gateway PSTN Gatekeeper Call Agent Carrier IP Multimedia Network Feature Server Residential Gateway(MGCP) Cable, xDSL, Ethernet Local LAN ... Small PBX ? POTS Fax POTS phones Wireless Local PCs

12. Residential Gateway: Characteristics • HW: Infineon Tricore platform (RISC/DSP) • RTOS: VxWorks or Infineon’s RTOS • SW • Own (all C++): Telephony SW • Other (buy): IP components (DHCP, SNMP, etc..) • Main characteristics: • Decomposed gateway architecture with external Call Agent (master/slave) • Remote management using open protocols (SNMP). • Security issues: kerberos tickets, encryption (IPSec), SNMPv3 • Tools: • Rational Rose RealTime for UML modeling, Active Object services and iterative development • Visual C++ (simulation environment) • Tasking toolset or Tornado (GNU) on the target • No ICE • Cost constraints: • Very hard: < $200 • Issues: we are still learning, but IP routing has to be fast • Cost (estimate): 20 PY

13. Why OO? • Drivers are: • Speedup product development • Flexible, extensible and reusable architectures are fundamental • Better way to deal with complexity • OO provides abstractions to keep complexity under control • Better manageable development process • Better division of labor • Important issues: • Disciplined analysis and design process is needed. • Evolutionary and more iterative development will reduce risks • However, we are not there yet!

14. How do we do Project Management? • Effort estimation: • It is still largely based on experience • Metrics needed! • Staffing. How? • Project leader who knows about OO • Experts who have already done at least 2 OO projects • Architect • Team workers • Required skills: • Prio1: Training in OO modeling (abstraction, ..).Methodology: OMT (past projects), UML (new projects) • Then: Training in OO language.C++ because of real-time critical products.

15. How do we do Project Management? • Process Issues: • Based on PPR/PPG • The final goal however is: INCREMENTAL DEVELOPMENTThat’s how developers work! • Progress Tracking: • We set the following milestones: • Requirements • OOA/D • Component Test • Integration Test • It turns out that tracking is easier due to better division of labor.

16. Our Product Cycle:1. Definition Phase • System Definition and Requirements Capturing • This is key to develop quality software • Documentation: • FDB1: business case • FDB2: requirements specification • FDB3: user interface issues • FDB4: system specification • Definition phase ends with a “go/no-go” statement and the definition of 1 or more product packages/releases. • Current Definition Cycle doesn’t support appropriate OO modeling during system definition / analysis.Lack of resources/budget don’t allow upfront Use Case modeling and OO Analysis.

17. Our Product Cycle:2. Realization Phase: Step 1 • Start with Specification • Design starts with the specification documents from the Definition Cycle (FDB1..FDB4). • FDB3/4 from Definition Cycle don’t provide enough detail to serve as an unambiguous functional specification.Therefore: we introduce an additional specification step: • Create a Functional Specification • Output document: FDB5 • Formal inspection.

18. Our Product Cycle:2. Realization Phase: Step 2 • OO Analysis • Deals with: • Architecture • Analysis Modeling = “Ideal World Modeling” • Ignores platform, single or multi processor system, .. • Important: come up with a software architecture which is robust, extensible, and resistant to changes in functionality. • Analysis = Teamwork • But, don’t involve too many! • Analysis Documentation: • Through OMT/UML Case tool for creating the models • Informal inspection

19. Our Product Cycle:2. Realization Phase: Step 3 • OO Design • Deals with: • Adding details to the logical and physical architecture • Design of interfaces, data structures, state machines, .. • Identification of new and existing reusable components, patterns, frameworks • Consider test strategy • Design = Teamwork • Design Documentation: • Expanded and completed models, created by case tool • Design document: FDB6 • Test Concept Document: FDB8 • Formal inspection

20. Our Product Cycle:2. Realization Phase: Step 4 • Implementation • Principle: “Code a little, Test a little” • Documentation: Source Files • Inspections: • No systematic code reading • Code reading is however important for ‘newcomers’. • There is no implementation description document. It doesn’t make too much sense.

21. Our Product Cycle:2. Realization Phase: Step 5 • Component Test • Local, designer test using: • Stubs, and/or • TestManager test scenarios generator • Debugging and Testing Tools: • TestManager, • Debugger, • Heap Checker

22. Our Product Cycle:2. Realization Phase: Step 6 • Design Integration Test • Test Specification: FDB10 • Formal inspection • Test itself: • Simulation test, through TestManager scenarios • Real, lab tests with the actual system

23. Our Product Cycle:2. Realization Phase: Step 7 • System Test • Feature Integration Test • Regression Test • Load/Stress Test • Tests are done by a separate team (no developers) • Field Trials

24. Our Experience with:OO Implementation • Knowing C++ is not enough. • OO Modeling must be learned. • Keep it simple • Restrict C++ to the basics • Don’t use compiler specific features • Set-up and use programming guideline and rules. Make them part of the software development methodology • Reuse common design patterns

25. Our Experience with:Patterns • Try to make use of existing patterns • The ‘GOF’ Book • The ‘Siemens’ Book • Create ‘own’ patterns. We currently have the following: • Interface Classes: restrict visibility of classes • Smart Pointers: reference counting on heap objects (derived from documented C++ concepts) • Asynchronous C++ method invocation • Interworking ports and distributed objects (comparable with concept of ‘proxy’ agents) • Finite State Machines: objectification of states and events • They are hard to design • They become stable after being used in +/- 3 projects

26. Our Experience with:Frameworks • We have built a number of frameworks: • Generic OSI 7-layer framework • Access communication layers through ‘Service Access Points’ and standard OSI primitives • Currently applied for: • X.25 • EDSS1 (ISDN Layer3) • LAP-D • WinSocket (TCP/IP) • Q.SIG • Operation and Maintenance Agent with ‘Manageable Objects’ • They are very hard to design

27. Our Experience with: Reuse • Component Reuse • We have a library of domain-specific components • Areas: Foundation, system, containers, signalling and inter-object messaging, fsm, devices, interrupt handling, .. • Do-able • But, ‘Reuse Mindset’ is needed, • It takes at least 3 tries to create a reusable component • Key to success: documentation and distributionPrinciple: intranet • Subsystem Reuse • Hard to do because of application specific details • Patterns and Frameworks must help in facilitating this kind of reuse. • Reuse, must be planned and taken into account at the project level.

28. Our Experience with: OO Testing • Old, well-known practices still apply • Design for testability • Add tracepoints throughout the application • Perform component and integration test • etc. BUT • Finding, and solving errors in OO systems tend to be harder • There are no ‘globals’ which makes it difficult to locate the path to an error • Objects are continuously created and destroyed and so don’t leave any marks

29. Important Issues For Us • Documentation • How and when • Separate from design? • Is Rose RealTime the solution? • Metrics • Effort estimation still too much based on experience and ‘just guessing’