Your SlideShare is downloading. ×
OPS Forum Requirements traceability and software reuse 17.03.2006
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

OPS Forum Requirements traceability and software reuse 17.03.2006

762

Published on

One of the challenges faced by OPS-GD in the area of software requirements is determining which requirements can be satisfied by existing software, be it infrastructure, a dedicated MCS or a 'mission …

One of the challenges faced by OPS-GD in the area of software requirements is determining which requirements can be satisfied by existing software, be it infrastructure, a dedicated MCS or a 'mission family' MCS. This maximises reuse from the start. In the past, however, this has depended on the knowledge of the individual system manager and there has been no supporting electronic repository of knowledge.

Published in: Technology, Business
1 Comment
1 Like
Statistics
Notes
  • I really like this slide, It's helpful to my research,Thanks!!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
762
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Products life cycle stages are :
    New product development stage
    Market introduction stage
    Growth stage
    Mature stage
    Decline stage
  • Transcript

    • 1. OPS-GDOPS-G FORUM17th March, 2006 European Space Agency M. Jones, F. Delhaise, M. Spada (OPS-GD) and S. Scaglioni (OPS-CQ) Requirements Traceability and Software Reuse: An OPS-GD initiative
    • 2. OPS-GDOPS-G FORUM17th March, 2006 Outline • Introduction • Product Life Cycle Management • MDS Reqs management and s/w reuse – Motivation and aims – RENATO, a REquirements MaNAgement TOol – Results: Consolidation of MCS Req. – RENATO extensions • Requirements Management at Ground Segment System Level • Conclusions
    • 3. OPS-GDOPS-G FORUM17th March, 2006 Introduction
    • 4. OPS-GDOPS-G FORUM17th March, 2006 Products and Knowledge Management • At ESOC, we try to build systems by reusing existing components as far as possible (either from infrastructure or missions) • To this end, we produce and maintain products: – infrastructure such as S2K, TDRS, MCCM, WebRM, GDDS, NIS/NCTRS, GFTS. SLE API, TMTCS, Simsat, Emulator Suite, PSS,… – the mission control systems, simulators and other systems based on the above • The products exist in various releases and have interdependencies e.g. GOCE MCS depends on S2K Rel 4.x,… • There is a big Knowledge Management problem in – Effective reuse – Evolution management – Design – Testing – …
    • 5. OPS-GDOPS-G FORUM17th March, 2006 • This is not an ESOC Specific problem • Products are also produced and serviced in the commercial world – example DELL personal computers: • global business • many components • many models • ca. 40 suppliers • product line continuously updated to stay ahead of competition Products and KM (Cont.)
    • 6. OPS-GDOPS-G FORUM17th March, 2006 Product Life Cycle Management (PLM) • Companies like DELL use Product Life Cycle Management (PLM) systems to manage all this information • PLM is software to support product life cycles • PLM was developed in the aerospace and automation industries, and has spread to consumer markets such as: • consumer electronics • clothing • food • Pharmaceuticals • PLM enables designers to make new products • reusing parts of previous designs • minimising new parts & suppliers
    • 7. OPS-GDOPS-G FORUM17th March, 2006 Products and Knowledge Management Conclusion • In the area of mission data infrastructure and mission data systems, we have a problem of managing product knowledge and product lifecycles – not reasonable to suppose that staff responsible for the products can keep the knowledge in their heads – Affects also decision makers (management, MIG, DSTF) and end users • No ready made PLM system available for our use • This Forum presents two initiatives that focus on a particular part of the problem: requirements management
    • 8. OPS-GDOPS-G FORUM17th March, 2006 MDS Requirements Management and Software Reuse
    • 9. OPS-GDOPS-G FORUM17th March, 2006 Motivation To Make Better Software Reuse
    • 10. OPS-GDOPS-G FORUM17th March, 2006 Software Reuse • Strategy followed by ESOC for many years • Two main sources for software reuse: – Infrastructure Kernel (SCOS-2000 for MCS and SIMSAT for Simulator) – Software components across missions • At ESOC: each new MDS is based on the Infrastructure Software • “DELTA” Approach w.r.t. Infrastructure when defining requirements • Identification of potential reuse from previous projects
    • 11. OPS-GDOPS-G FORUM17th March, 2006 Software Reuse (Cont.) Software reuse can lead to: – Cost reduction – Risk reduction If performed with sufficient caution MCS Costs - Planetary and Earth Explorer Families 0 500 1000 1500 2000 2500 3000 3500 Mission DevcelopmentCost(KEuro) Rosetta Mars Express Venus Express Cryosat Goce SCOS-2000 Requirements Rosetta Mars ExpressVenus Express
    • 12. OPS-GDOPS-G FORUM17th March, 2006 Software Reuse (Cont.) Reuse across missions is a delicate operation: the combined effort and risk required to reuse the software has to be less than the effort required to implement again from scratch ! – Is the software component tested, proven, stable? – Is it of sufficient quality? – Is it easy to customize it? – Is it easy to understand its structure? – Does it fully or partly meet project’s needs?
    • 13. OPS-GDOPS-G FORUM17th March, 2006 Avoid building Frankenstein
    • 14. OPS-GDOPS-G FORUM17th March, 2006 • For each new mission previous missions requirements are carefully reviewed to check applicability • A new set of requirements is specified • These requirements are maintained on an individual repository from which an SRS is generated Coping with “Similar” Requirements: The traditional approach • Problem: Number of missions (i.e. source of requirements/reusable software)is ever increasing Therefore this task is – more and more complex – expensive – almost impossible to do exhaustively – exchange between DSMs, developers and end-users from different missions is point-to-point, informal and relies on knowledge and availability of individuals
    • 15. OPS-GDOPS-G FORUM17th March, 2006 OPS-GD Initiative aims • Investigate ways of making MDS reuse more: – FORMAL – COMPREHENSIVE – MANAGEABLE • A Study was initiated (80K budget) to achieve these aims through: 1. A thorough review of the existing MDS requirements and the establishment of a set of common requirements 2. The development of a REquirements MaNAgement TOol (RENATO)
    • 16. OPS-GDOPS-G FORUM17th March, 2006 RENATORENATO A REquirements MaNAgement TOol
    • 17. OPS-GDOPS-G FORUM17th March, 2006 The RENATO Tool • Enables and optimises the systematic management of common and mission specific MDS requirements • Supports the production of the SRS – Less effort (the wheel is not reinvented each time) – More consistency across missions – Overall better quality SRS • RENATO is based on Telelogic DOORS – DOORS incorporates a macro-programming language (DXL) which enables to create tailored functionality
    • 18. OPS-GDOPS-G FORUM17th March, 2006 RENATO Features • One single Database for all projects • One dedicated module per project • Powerful Classification of requirements to support easy searching • Dynamic linking between requirements from different modules • It combines a database facility for storing requirements and high quality word processing for the text: cut, copy, paste, spell-checking, search, Pictures, Diagrams and Tables • Ability to define & save a “View” = particular Display of the data
    • 19. OPS-GDOPS-G FORUM17th March, 2006 RENATO Features (Cont.) • Configuration Control via – Maintenance of Software Change Requests – Definition of Baseline • Export the content of a module to MS Word to generate the SRS document. “WEXP” freeware module has been integrated into RENATO • The usage of WEXP offers an improved version of the standard DOORS output. Example of requirement export: Need Desirable Priority A Traceability OIRD Target delivery D1 Requirement The user shall be able to request the import of the complete SDB Explanation Reuse Yes DBS-FU-150-LPF Note that it is not required to support the import of ‘partial ’SDB versions.
    • 20. OPS-GDOPS-G FORUM17th March, 2006 RENATO (DOORS) View SRS Chapters Text Graphic Requirements
    • 21. OPS-GDOPS-G FORUM17th March, 2006 The Results • Identification of “Common” Requirements • Statistics on Software Reuse
    • 22. OPS-GDOPS-G FORUM17th March, 2006 Analysis of MCS Requirements • As a start RENATO holds requirements of all the SCOS-2000 based MCSs in a single database • Result of systematic review of all requirements coming from: 1. Interplanetary missions: Mars Express, Rosetta, Venus Express 2. Earth exploration missions: Cryosat, Goce, Aeolus, METOP 3. Technology missions Smart-1, Lisa Pathfinder 4. Observatory missions Integral, XMM, Herschel-Planck
    • 23. OPS-GDOPS-G FORUM17th March, 2006 Identification of “Common” Requirements • Identification of “common”requirements used by more than one missions • These requirements result from a process of generalisation and consolidation of mission specific requirements through rewording, terms standardisation or parameterisation • Advantages: – SRS authors can now look in a single place to see which requirements are applicable to which missions – Precious feedback for possible extensions of the infrastructure – To deduce statistics on reuse across missions
    • 24. OPS-GDOPS-G FORUM17th March, 2006 Common Requirements Example 1 OBS-FU-28-COM OBSM shall support 2 types of SCOS-2000 Memory Models: Configuration Tables and Symbol Tables. It shall be possible to attach both a Configuration Table and a Symbol Table to a Memory Image. OBS-FU-C-0.14-001 H/P OBSM shall support 2 types of SCOS-2000 Memory Models, viz. Configuration Tables and Symbol Tables. It shall be possible to attach both a Configuration Table and a Symbol Table to a Memory Image. OBS-FU-R0.8-030 LPF OBSM shall support 2 types of SCOS-2000 Memory Models, Configuration Tables and Symbol Tables. It shall be possible to attach both a Configuration Table and a Symbol Table to a Memory Image. Herschel-Planck module Lisa Pathfinder module Common module
    • 25. OPS-GDOPS-G FORUM17th March, 2006 Common Requirements Example 2 TCS-FU-17-COM A command parameter of type 'Parameter ID' shall be encoded as a <XX> bit unsigned integer parameter containing the on-board Parameter ID as extracted from the database for the specified telemetry parameter. TCS-FU-C-5.2-080 A command parameter of type ‘Parameter ID’ shall be encoded as a 16 bit enumerated parameter containing the on-board Parameter ID as extracted from the database for the specified telemetry parameter. TCS-FU-R6.2-110 A command parameter of type ‘Parameter ID’ shall be encoded as a 32 bit unsigned integer (TBC) parameter containing the on-board Parameter ID as extracted from the MIB (table field PCF_PID) for the specified telemetry parameter. Herschel-Planck module Lisa Pathfinder module Common module
    • 26. OPS-GDOPS-G FORUM17th March, 2006 Common Requirements Example 2 View
    • 27. OPS-GDOPS-G FORUM17th March, 2006 Link to the Requirement Source • Links are provided to the mission specific sources of the common requirements by means of the DOORS dynamic linking functionality: Dynamic Link to original Requirements “common”requirement dynamic link RENATO Common module View
    • 28. OPS-GDOPS-G FORUM17th March, 2006 “Common” Requirements: Results • Common Requirements have been identified for the following MCS subsystems: – Database management – Telemetry monitoring – Spacecraft commanding – Packet Utilization Standard (PUS) service modeling – Mission Planning System – On Board Software Monitoring (OBSM)
    • 29. OPS-GDOPS-G FORUM17th March, 2006 “Common” Requirements: TM SS Example • The following “common” functionality (not part of SCOS) have been identified in the TM SS: – Decompression – Telemetry Replayer – Time Correlation with the use of the OWLT files – Time-Stamping and Time Checks – Extraction of Non-PUS TM through the use of configuration file
    • 30. OPS-GDOPS-G FORUM17th March, 2006 • The following “common” functionality have been identified in the Packet Utilization Standard (PUS) service modeling : – Service 1: TC Verification Service: using live and playback data – Service 3: Missions often request the functionality to support the generation of the Service 3 commands required to create a new housekeeping / diagnostic packet definition onboard – Service 5: Handling of the reception of duplicate on board TM event pkts and ensure that this event is logged and processed once. – Service 11: Onboard Scheduling Service, A frequent request is to extent the SCOS-2000 OBQM to compare the contents of the TM(11,13) summary schedule packets with the on-board schedule maintained by the OBQM. – Service 13: Large File Transfer is required by the most recent mission – Service 18: On-board operations procedures are more and more required. “Common” Requirements: PUS Example
    • 31. OPS-GDOPS-G FORUM17th March, 2006 • Requirements exist for all missions in the following categories: • File import and export • Automatic Planning • Manual Planning • Schedule generation • Plan validation • Re-planning • Rules and constraint management • These categories could form the basis of a requirements baseline for a set of mission planning libraries “Common” Requirements: Mission Planning Example
    • 32. OPS-GDOPS-G FORUM17th March, 2006 Statistics on Reuse Across Mission Families Type of Common Requirements Statistic Distribution Generic 62,06 % Interplanetary 18,58 % Technology 2,77 % Observatory 13,04 % Earth Observation 3,56 % the majority of “common” requirements are generic i.e. not associated directly to a single mission family. Note: These statistics are based on the “common” module and are automatically computed by RENATO!
    • 33. OPS-GDOPS-G FORUM17th March, 2006 Requirements Management Process MDS Infrastructure Common Requirements New Mission SRs ROS/ MEX/ VEX SRs Cryosat Goce SRs Smart-1 SRs Herschel Planck SRs Lisa Pathinder SRs Retrofit Reuse New Mission Metop-1 SRs
    • 34. OPS-GDOPS-G FORUM17th March, 2006 • The “common” SRS is a valuable input for both – MDS Data System Manager of specific missions – the MDS infrastructure TO Requirements Management Process (Cont.) • The utility of this module is kept only if this list of “common” requirements is maintained: – new “common” req. need to be added if reuse by other missions is foreseen – The “common” requirements retrofitted in the SCOS infrastructure, need to be removed from the module after retrofitting.
    • 35. OPS-GDOPS-G FORUM17th March, 2006 Future Extensions • Link the Requirements to the entire SW lifecycle • Integration of Test Plans/Reports • Remote Access Facility
    • 36. OPS-GDOPS-G FORUM17th March, 2006 Link the Requirements to the entire SW Lifecycle • Link requirements to the design: How? By making use of the interface between DOORS and many leading UML tools. Being able to draw UML 2.0 diagrams in DOORS will be a very useful enhancement • Link requirements to the code: How? By making use of the interface between DOORS and many leading configuration control systems
    • 37. OPS-GDOPS-G FORUM17th March, 2006 Integration of Test Plans / Reports • Three options have been evaluated for tests management: – Option 1: Store the tests in a different module within RENATO – Option 2: SVVP, ESOC specific tool based on MS access – Option 3: Rational Test Manager, IBM Application linked to DOORS using an adaptor
    • 38. OPS-GDOPS-G FORUM17th March, 2006 Comparison Results RENATO (DOORS based) SVVP (ESOC MS-Access) Rational Test Manager + Requirements and tests in one applicat. + Test Plan & Report can be handled as a Word document + limit the duplication between missions of tests linked to the same set of requirements + Traceability Matrix - not specifically designed for test plan + specifically designed for test plans - requirements stored in RENATO must be re-imported in the MS- Access Based tool to maintain traceability. + specifically designed for test plans and reports + allows to go towards automatic testing - quite complex for our needs - 3 software are needed: Doors, Doors Test Input Adapter, Test Manager
    • 39. OPS-GDOPS-G FORUM17th March, 2006 Requirements Management at Ground Segment System Level
    • 40. OPS-GDOPS-G FORUM17th March, 2006 Key Issues at GS System Level • Need for traceability of requirements at all levels – From Customer Requirements (in MIRD) down to Subsystem Requirements (in SRSs, SFIRD etc.) – Essential to demonstrate requirements coverage/compliance • to the Customer • during QA audits • Need to demonstrate/document validation of requirements at all levels – Easier if requirements and validation records in a single system • Need to harmonise validation records across sub-systems – Use of common tools
    • 41. OPS-GDOPS-G FORUM17th March, 2006 What does RENATO bring • Need for traceability of requirements at all levels – DOORS usage can be extended to the whole GS • Supports vertical traceability – RENATO can be used at GS Subsystem level • Supports horizontal traceability (across missions/families) • Links to higher requirements levels – The RENATO features supporting reuse can be applied at all GS levels • Need to demonstrate validation of requirements at all levels – RENATO can/should be extended to integrate requirements and validation records
    • 42. OPS-GDOPS-G FORUM17th March, 2006 Overview at GS level MIRD SRD SIM SRS FD CR GS System Level GS Sub-System Level Infra. SFIRD Traceability MCS SRS Design Code Validation RENATORENATO
    • 43. OPS-GDOPS-G FORUM17th March, 2006 Centralised GS Reqts Management System Missions GS Customers DOORS Server DOORS clients DOORS clients Remote access (DOORSnet or via Citrix Server) Firewall DOORS clients Missions GS End-users Mission GS Subsys Teams Industry Teams MIRDs MIPs SRSs SFIRDs CRs
    • 44. OPS-GDOPS-G FORUM17th March, 2006 • OPS-CQ initiated a project in July 2005 aiming at introducing DOORS as the ESA GS Requirements Management System • Project Schedule: – Phase-in (July 05 – July 06) Funded by D/EOP (ESOC and ESRIN) • 6 floating licenses, 15 users, 4 groups (ESOC and ESRIN) • Use DOORS to produce the SENTINEL-1 system levels requirements documents (MIRD, SRD) • GO/NOGO for DOORS usage in June 2006 after MIRD / SRD review • Final presentation from SENTINEL-1 project: June 2006 – Routine phase (July 06 – Dec 07) • Usage of DOORS opened to new projects • Potential users: SWARM and GAIA (not before Oct. 2006) The Roadmap
    • 45. OPS-GDOPS-G FORUM17th March, 2006 • Specification of LPF MCS and Simulator requirements in RENATO (already on-going) • Extension of RENATO to MDS Validation (candidate project LPF) • Extension of RENATO to the whole software lifecycle (Architecture, Design) – Prototyping requires funding • Define and implement RENATO management processes The Roadmap (Cont.)
    • 46. OPS-GDOPS-G FORUM17th March, 2006 Conclusions • RENATO is an elaborated requirements mgt tool – Generates SRS documents with powerful traceability – Direct access to all other missions requirements located in the same database • The “Common” req. module eases the software reuse across missions • Very attractive extensions are possible – Coverage of the whole SW lifecycle – Integration of validation records – Remote-access • A more ambitious goal is to develop an ESA wide centralised GS Requirements Management System
    • 47. OPS-GDOPS-G FORUM17th March, 2006 Any Questions?

    ×