Team Skill 6: Building the Right System From Use Cases to Implementation (25)

Slides:



Advertisements
Similar presentations
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advertisements

Virtual University - Human Computer Interaction 1 © Imran Hussain | UMT Imran Hussain University of Management and Technology (UMT) Lecture 16 HCI PROCESS.
Chapter 2 – Software Processes
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Outline About author. The problem that discussed in the article.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
PRJ270: Essentials of Rational Unified Process
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Week 8 Implementation Design Alex Baker. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Chapter 6 View Alignment Techniques and Method Customization (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 1 The Systems.
Effective Methods for Software and Systems Integration
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
UML - Development Process 1 Software Development Process Using UML (2)
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
INFO 637Lecture #81 Software Engineering Process II Integration and System Testing INFO 637 Glenn Booker.
INFO 637Lecture #61 Software Engineering Process II Designing with Teams INFO 637 Glenn Booker.
Object Oriented Analysis and Design Introduction.
An Introduction to Software Architecture
INFO 627Lecture #81 Requirements Engineering and Management INFO 627 Building the Right System Glenn Booker.
Understand Application Lifecycle Management
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Architecting Web Services Unit – II – PART - III.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Lecture 7: Requirements Engineering
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
Computer Science 340 Software Design & Testing Software Architecture.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
CPSC 871 John D. McGregor Module 8 Session 1 Testing.
Software Engineering Principles Practical Advice and Steps for Managing Your Project.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
4+1 View Model of Software Architecture
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Software Architecture Architecture represents different things from use cases –Use cases deal primarily with functional properties –Architecture deals.
OBJECT ORIENTED VS STRUCTURED WHICH ONE IS YOUR CHOICE.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
CPSC 372 John D. McGregor Module 8 Session 1 Testing.
 System Requirement Specification and System Planning.
Unified Modeling Language
The Systems Engineering Context
Software Quality Engineering
Recall The Team Skills Analyzing the Problem (with 5 steps)
Applying Use Cases (Chapters 25,26)
Applying Use Cases (Chapters 25,26)
From Use Cases to Implementation
Logical Architecture & UML Package Diagrams
Presentation transcript:

Team Skill 6: Building the Right System From Use Cases to Implementation (25)

Use Cases to Implementation What we have done so far ▫Defined requirements ▫Specified them clearly ▫Ensure they have good quality Now we need to ensure that the system reflects the requirements we have designed 2

Use Cases to Implementation As a SW development company we to confirm that the stated requirements are implemented Ensure no unneeded/undocumented changes are made during development Deal with change during development ▫Change control Process ▫Bug process 3

Use Cases to Implementation System Customer Needs Defined Requirements VerificationValidation Verification vs. Validation 4

Use Cases to Implementation Verification should confirm ▫Use Cases and requirements which are derived from features really do support the intended features ▫Use cases are reflected in the design ▫The design supports both functional and nonfunctional aspects of the system’s behavior ▫Code conforms to the design ▫Testing covers all use cases and requirements 5

Use Cases to Implementation Verification ▫Verification is often done through traceability ▫Key concept for verification is that every activity looks back to the previous step and makes sure nothing got left behind, or forgotten ▫Other verification methods include inspection and review 6

Use Cases to Implementation Cost of verification ▫Balance the amount of time spent doing verification,  Don’t overdo it  Don’t miss something important ▫Verification applies to all phases of the life cycle, but is most critical early on 7

Use Cases to Implementation Verification ▫Testing is also mostly a verification activity ▫Verification is done by many members of the project team  Not just a QA ▫A process for verification needs to built into the life cycle to ensure it is consistently performed 8

Use Cases to Implementation Validation ▫The act of proving that the system you are creating meets the needs of the customer ▫Can map user needs to product features, another form of traceability ▫Validation is often done at major milestones  End of life cycle phases  End of iterations ... 9

Use Cases to Implementation Validation ▫Need to demonstrate the product in the customer’s environment to assess the subjective “are they happy with it” criterion ▫Main reason for validation is to ensure the customer needs didn’t change from when the requirements were captured 10

Use Cases to Implementation While software development has been able to accomplish realization of functionality ▫Getting from requirements to implementation is not a simple matter Sometimes it is hard to prove that a particular piece of code fulfills a requirement 11

Use Cases to Implementation Sometimes it is straightforward To make some requirements easier to implement write them with detail to guide the developer, by invoking familiar concepts ▫Task progress status ▫Role or organization-based security modeling ▫Citing specific math concepts or algorithms 12

Use Cases to Implementation The toughest requirements to implement are ▫Too vague, little idea of what  Level of complexity  Control is desired ▫Non-functional requirements,  Often process-oriented, but the code itself is a logical structure 13

Use Cases to Implementation Difficult requirements can also focus on scale issues such as system-level requirements ▫Can be addressed by the systems engineering approach we discussed earlier Requirements which are distributed throughout the system are also often difficult (e.g. use of interface standards) 14

Use Cases to Implementation Key ways to address difficult requirements are through using proven design patterns or metaphors ▫Talked about throughout INFSCI

Use Cases to Implementation Use of object-oriented methods can help resolve some orthogonality issues, by combining data structure with process-oriented methods Beware that direct mapping of functions to objects can result in non-OO structures 16

Use Cases to Implementation Use Case can help ▫Defining use cases can help see the big picture of the system’s role ▫Prevents focusing too closely on a particular function 17

Use Cases to Implementation Modeling the system ▫Software systems can involve thousands of modules and millions of lines of code ▫To help break down their complexity we need a good modeling tool ▫We need to hide the details and understand the high level 18

Use Cases to Implementation Our need to understand software at a high level is similar to other fields’ needs ▫In astronomy  Cosmology tries to understand the structure and evolution of the universe ▫In physics  Various unified field theories try to relate all of the electromagnetic forces 19

Use Cases to Implementation We use system architecture to understand ▫What the system does ▫How it works ▫The role of each part of the system And be able to support ▫Extension or expansion of the system ▫Reuse of the system 20

Use Cases to Implementation 4+1 architecture ▫Phillipe Kruchten (Written before UML)  Helps capture the architecture by looking at different aspects of the system ▫Like a house architect might have different drawings to capture  Structure,  Wiring  Plumbing ... 21

Use Cases to Implementation The 4+1 views are ▫Logical view, such as the subsystems and classes within the system ▫Implementation or Development view, which is the structure of the code in its environment ▫Process view, to capture timing and coordination issues ▫Deployment or Physical view, the hardware 22

Use Cases to Implementation The +1 part are scenarios or use cases, which tie all of the parts together Logical Process Implementation Deployment Use Cases 23

Use Cases to Implementation Logical view ▫The structure of the data and objects needed to support system functionality ▫Appears as a class diagram or entity-relationship diagram (ERD) 24

Use Cases to Implementation Implementation View ▫The structure of the code is often shown by grouping modules ▫From large to small  Subsystem  Component  Packages 25

Use Cases to Implementation Process View ▫The process view mostly helps understand non- functional characteristics  Timing  Synchronization  Concurrency  Fault tolerance ▫UML Diagrams  Sequence  Activity diagrams  State chart 26

Use Cases to Implementation Deployment View ▫The deployment view focuses on how the system is physically located on computer systems ▫Hence this helps focus on installation and networking issues ▫Shown with a deployment diagram 27

Use Cases Tie It All Together As the four main views are being developed, the use cases or scenarios can help ensure the models are all consistent with each other Trace how each scenario appears from each view’s perspective ▫Response Startegies 28

Use Cases to Implementation Summary ▫The best way to get from requirements to code is to define a set of inter-related models ▫Capturing  Logical  Implementation  Process  Deployment characteristics  And how they all relate 29