1Rational Unified Process asImplemented at SNLKaren M. EricksonData Systems Lead EngineerSoftware Product Realization OrganizationDepartment 5522 MS0974Sandia National [email protected]! Overview of SNL Satellite GroundSystem Project! Software Development Process basedon the RUP! Lessons Learned3Satellite Ground SystemDescription! Processes satellite telemetry data! Acquire data from multiple satellites anddifferent downlinks! Extract, process, store and display data! Combine data into meaningful informationfor the end users to enable their decisions! Operational military system! High rigor, Reliable, Maintainable4Satellite 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 allrequirements5System Development! Full life cycle development – cradle to grave! 8 years from inception to deployment! Object Oriented Analysis and Design (UML)! 130 Use Cases! 5700 Classes! Currently ~1 million LOC in C++6Software DevelopmentOrganization! 65 Software Professionals in 15 teams! System Engineering! Requirements Analysis! Architecture! Software Design & Development! Configuration and Build Management! Systems Integration! Integration Test! Computer Engineers! Deployment Engineers! 1/3 to ! are developers at any one time7Complete SystemDevelopment! To develop the system requires additional capabilities! Independent Test Organizations! System Test! Mission Analysis and Simulation! Research & Development! Algorithms! Simulators! Modeling! Support! System Administration! Development Environment Tool Development! Additional 60 staff members, creating a multi-disciplinary team8Software DevelopmentProcess!The Software Development Process isderived from the Rational UnifiedProcess (RUP)! Iterative! Use Case Driven! Architecture Centric! Object Oriented Methodology! Supported by an integrated tool set9Iterative Development Process! Supports full software development lifecycle from requirements to test everyiteration! Requirements Capture! Architecture Analysis! Design! Implementation! Test10Use Case Driven!Use Cases!Capture derived requirements!Describe the interaction of the user orexternal interface with the system toperform a single function!Use cases and scenarios drive the processflow from requirements through testing!Provides coherent and traceable threadsthrough both the development and thedelivered system11Architecture Centric!Focuses on early development andbaselining of a robust softwarearchitecture!Facilitates parallel development!Minimizes rework!Increases reusability!Increases reliability12Object Oriented!OO Methodology uses concepts of objects,classes, and the associations between classes!Unified 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…”*13Tool Support! The RUP is supported by tools thatautomate large parts of the process! Tools are used to create and maintainthe various artifacts from each processstep! Tools support maintaining models todescribe the system design andreplaces paper documentation14Project Implementation ofRUP! Requirements Capture! System Specification! Use Case Descriptions! Architectural Analysis! Use Case Realizations! Subsystem Analysis Reports! Design! Use Case Design! Class Design! Implementation! Coding! Testing! Integration Testing toUse Cases! System Testing to theSystem Spec15Requirements CaptureUse CaseModelSystemSpecsStoryBoardsUse CasesMappingICDs16Use Cases! Describes theinteraction of the useror external interfacewith the system toperform a singlefunction! No specificarchitecture orimplementationexpressedGround System UserGS1 Updates System Status(from Ground System System-Clock Perspective)GS2 Updates System Status(from Ground System System-Clock Perspective)...)Accesses the System<<include>><<include>>17Use Case DescriptionsTypical Flow of Events Actor Action System Response 1. This use case begins when the Ground System User selects to gain access or change current access to GS1/GS2 as an individual user. 1. The ADP Software requests the user identification, password and user type. 2. The Ground System User enters a user identification, password and user type. 3. The ADP Software displays the appropriate user interface (based on the user type). 4. The Ground System User optionally selects to change the current user type (with a valid user identification and password). If not, go to step 9. 5. The ADP Software displays the appropriate user interface (based on the user type). 6. The Ground System User optionally selects to change the current user identification and password. If not, go to step 12. 7. The ADP Software maintains the current user interface (with a new user). 8. The Ground System User optionally selects to change the current user password. 9. The ADP Software requests the user’ s current password, the new password, and a confirmation of the new password. 10. The Ground System User enters current password, new password, and confirms the new password. 11. The Ground System User can repeat steps 5 and 7 and 9 as often as needed. 12. The Ground System User selects to terminate their system access. 13. This use case ends when the user interface is terminated. Alternate Flow 18Use Case StoryboardsStep 1 The user enters his user identification (Tom), password and user type (AMC) and selects “OK”. Figure 1: Log on Window19Use CaseModelUse CaseDescriptionsArchitectural AnalysisArchiModelStoryboardsSubsystemAnalysisReportUse CaseRealizations20From Use Case to Realization : GS Use r : Log On Display : User M anager : System Status Manager : Re porting : Authorization Info1: Log On( )2: Re qu est Log On(user_name, role , pass word)3: Authorize( )4: Update System Status( )5: Re port Log On Status Change ( )6: Log On Reply( )1) Asynchronous reque st/reply pair. Reply indicate s success /failure .2) Only if author ization success ful.• Realizations shows how the system should behavefrom an internal point of view• One Realization for each Use Case• Identifies and describes
View Full Document
Unlocking...