WIXLIB

Rational Unified Process asImplemented at SNLKaren M. EricksonData Systems Lead EngineerSoftware Product Realization OrganizationDepartment 5522 MS0974Sandia National Laboratorieskmerick@sandia.gov1Topics!!!Overview of SNL Satellite GroundSystem ProjectSoftware Development Process basedon the RUPLessons Learned2

Satellite Ground SystemDescription!Processes satellite telemetry data!!!!Acquire data from multiple satellites anddifferent downlinksExtract, process, store and display dataCombine data into meaningful informationfor the end users to enable their decisionsOperational military system!High rigor, Reliable, Maintainable3Satellite Ground Systems!!!Two Satellite Ground Systems developedin parallel to promote software reuse.Systems are subject to extensivedevelopmental control and testing by ourcustomers.The systems were developed for multiplecustomers whose requirements canconflict!System must be optimized to meet allrequirements4

System Development!Full life cycle development – cradle to grave!!8 years from inception to deploymentObject Oriented Analysis and Design (UML)!!!130 Use Cases5700 ClassesCurrently 1 million LOC in C 5Software DevelopmentOrganization!65 Software Professionals in 15 teams!!!!!!!!!!System EngineeringRequirements AnalysisArchitectureSoftware Design & DevelopmentConfiguration and Build ManagementSystems IntegrationIntegration TestComputer EngineersDeployment Engineers1/3 to ! are developers at any one time6

Complete SystemDevelopment!To develop the system requires additional capabilities!Independent Test Organizations!!!Research & !!!System TestMission Analysis and SimulationSystem AdministrationDevelopment Environment Tool DevelopmentAdditional 60 staff members, creating a multidisciplinary team7Software DevelopmentProcess!The Software Development Process isderived from the Rational UnifiedProcess (RUP)!!!!!IterativeUse Case DrivenArchitecture CentricObject Oriented MethodologySupported by an integrated tool set8

Iterative Development Process!Supports full software development lifecycle from requirements to test everyiteration!!!!!Requirements CaptureArchitecture AnalysisDesignImplementationTest9Use Case Driven!Use Cases!!!!Capture derived requirementsDescribe the interaction of the user orexternal interface with the system toperform a single functionUse cases and scenarios drive the processflow from requirements through testingProvides coherent and traceable threadsthrough both the development and the10delivered system

Architecture Centric!Focuses on early development andbaselining of a robust softwarearchitecture!!!!Facilitates parallel developmentMinimizes reworkIncreases reusabilityIncreases reliability11Object Oriented!!OO Methodology uses concepts of objects,classes, and the associations between classesUnified Modeling Language (UML) is used asthe common notation in the RUP!Booch, Rumbaugh, Jacobson - The UnifiedModeling Language User Guide:!“ a graphical language for visualizing, specifying,constructing, and documenting the artifacts of asoftware-intensive system. The UML gives you astandard way to write a system’s blueprints ”*12

Tool Support!!!The RUP is supported by tools thatautomate large parts of the processTools are used to create and maintainthe various artifacts from each processstepTools support maintaining models todescribe the system design andreplaces paper documentation13Project Implementation ofRUP!Requirements Capture!!!Architectural Analysis!!!System SpecificationUse Case DescriptionsUse Case RealizationsSubsystem Analysis egration Testing toUse CasesSystem Testing to theSystem SpecUse Case DesignClass Design14

Requirements CaptureSystemSpecsMappingICDsUse CaseModelUse CasesStoryBoards15Use Cases include Ground System UserAccesses the SystemGS2 Updates System Status(from Ground System System-Clock Perspective).)!!Describes theinteraction of the useror external interfacewith the system toperform a singlefunctionNo specificarchitecture orimplementationexpressed include GS1 Updates System Status(from Ground System System-Clock Perspective)16

Use Case DescriptionsTypical Flow of EventsActor ActionSystem Response1. This use case begins when theGroundSystem User selects to gain access orchange current access to GS1/GS2as an individual user.1. The ADP Software requests the useridentification, password and user type.2. The Ground System Userenters a user 3. The ADP Software displays theidentificati on, password and user type.appropriate user interface (based on theuser type).4. The Ground System Useroptionally5. The ADP Software displays theselects to change the current user typeappropriate user interface (based on the(with a valid user identification anduser type).password). If not, go to step9.6. The Ground System Useroptionally7. The ADP Software maintains theselects to change the current usercurrent user interface (with a new user).identification and password. If not, goto step 12.8. The Ground System Useroptionallyselects to change the current userpassword.9. The ADP Software requests the user’ scurrent password, the new password,and a confirmation of the newpassword.10. The Ground System Userenters currentpassword, new password, and confirmsthe new password.11. The Ground System Usercan repeatsteps 5 and 7 and 9 as often as needed.12. The Ground System Userselects toterminate their system access.Alternate Flow13. This use case ends when the userinterface is terminated.17Use Case StoryboardsStep 1The user enters his user identification (Tom), password and user type (AMC) and selects“OK”.Figure 1: Log on Window18

Architectural AnalysisUse CaseModelUse CaseDescriptionsUse ysisReport19From Use Case to RealizationTypical Flow of EventsActor ActionSystem Response1. This use case begins whenGroundthe 1. The ADP Software requests the userSystem Userselects to gain access or identification, password and user type.change current access to GS1/GS2as an individual user.2. TheGround System Userenters a user3. The ADP Software displays theidentification, password and user type.appropriate user interface (based on theuser type).4. TheGround System Useroptionally 5. The ADP Software displays theselects to change the current user typeappropriate user interface (based on the(with a valid user identification anduser type).password). If not, go to9. step Realizations shows how the system should behavefrom an internal point of view One Realization for each Use Case Identifies and describes high-level systemcomponents and associated responsibilities The collection of Realizations as a whole representsone view of the Architecture6. TheGround System Useroptionally 7. The ADP Software maintains theselects to change the current user current usererfaceint (with a new user).identification and password. If not, goto step 12.8. TheGround System Useroptionally 9. The ADP Software requests the user’sselects to change the current user current password, the new password,: GS User: Log On Displaypassword.and a confirmation of the newpassword.10.TheGround System Userenters currentpassword, new password, and1: Log On( )thenew password.confirms11.TheGround System Usercan repeatsteps 5 and 7 and 9 as often as needed.12.TheGround System Userselects toterminate their system access.Alternate Flow13.This use case ends when the userinterface is terminated.: User M anager: Authorization Info: System StatusManager: Reporting2: Requ est Log On (user nam e, role, password)3: Authorize( )1) Asynchronousrequest/replypair. Replyindicatessuccess/failure.2) Only ifauthor izationsuccessful.4: Update System Status( )5: Report Log On Status Change( )6: Log On Reply( )20

From Realization to AnalysisClasses: GS UserRealizations identifyanalysis classesAnalysis classes arecaptured in SubsystemAnalysis Reports (SARs): Log On Display: User M anager: Authorization Info: System StatusManager: Reporting1: Log On( )2: Requ est Log On (user nam e, role, password)2) Only ifauthor izationsuccessful.3: Authorize( )1) Asynchronousrequest/replypair. Replyindicatessuccess/failure.4: Update System Status( )5: Report Log On Status Change( )6: Log On Reply( ) Boundary GS Us e r entity Log On Di s play enti ty control Authorization InfoUs e r Ma nage r control Sys te m Status Manage r ut ilit y Re oardsUse CaseDescriptionUse CaseModelSARsDesignModel22

Analysis Classes toDesign Classes Boundary GS Us e r enti ty Log On Di s play control Us e r Ma nage r control Sys te m Status Manage r enti ty Authorization Info ut i li t y Re porting23Design Classes!!!A further elaboration of the ArchitectureLow-level: all details specifiedSuitable for generating source code framework24

Implementation!Implementation consists of!!!Code generation from the modelFilling in .cc files with detailedimplementationCode generation from the model!DesignModelSourceCodeCreates header files (.h)! Data definitions! Class interfaces25Code Inspections!Code Inspections are a two step process!Review the class design in the model!!!!Provides conceptual understanding and contextExamine relationshipsReviews details of dataInspect Code!!Focus on the implementationReviews not necessary for headers because reviewedwith the model26

Unit/Integration Test andDelivery!!Components are controlled and builtUnit testing is based on!!!!Subsystem Analysis Reports (SAR’s)Use Case Realizations (UCR’s)System is built and delivered to integration testbedIntegration testing is based on Use CaseDescriptions27System Test!!System is built and delivered to systemtestbedSystem Testing!!!Based on System specsUse Cases provide guidance and context for howto operate the systemMapping of specs to Use Cases through to designprovides traceability to help determine which testcases to execute!!! 1000 specs 100 Use CasesMany to many mappings28

Requirements TraceabilityUse Case1Spec 1Use Case2Spec 2Use Case3Spec 3Spec 4Realization1Design Class 1Realization2Design Class 2Realization3AnalysisClass 1Design Class 3AnalysisClass 2Design Class 4AnalysisClass 3Design Class 5AnalysisClass 4Design Class 629Site Delivery/Deployment!System Tested release is delivered tosite!!System Verification Testing is performedAcceptance Testing is performed by thecustomer30

Operations & Maintenance!!O&M follows same developmentprocess as original developmentModifications are put in the field at predefined intervals as requested by thecustomer31Lessons Learned?!!!Expectations vs. RealityReflectionsSNL Success with the RUP32

Expectations vs. Reality!RUP expects!!!Small projects built in a short amount oftimeShort iterationsSame people doing most of the steps ofthe process33Expectations vs. Reality!Sandia Reality!!!Largest Software Development Project at SNLCost Estimate predicted 8 years of developmentIterations of 6 months!!!Not long enough to complete a full life cycleTakes us approximately 18 monthsDivision of responsibilities between teams!!No continuity of personnel in steps of processHandoffs between teams more formal than RUPenvisioned34

Reflections!Sandia was one of the original customers of the RUP.!!Our use of the RUP evolved as the RUP itself was evolving.We had a good working relationship with Rational.!!!!Opportunity to provide feedback to Rational and have itincorporated into their product.Biggest project that had ever been built using RUP.Relationship changed when Rational was purchased by IBM.Process/Tool Development!!!The process and tools did not meet our needs out of the boxIt took us several years to fully understand and implement theprocess before we were very productive.We had to integrate a lot of the tools ourselves and makethem fit our version of the process.35SNL Success with the RUP!Once the process was defined and the toolswell integrated we evolved into a highlyproductive organization!!We were able to integrate 14 new staff membersone summer and still meet our deliverables thatiterationThese two satellite ground systems are beingdelivered on time, within budget andmeeting all requirements.36