Software Development Process

Slides:



Advertisements
Similar presentations
Virtualization in Bizagi is a data-level integration mechanism t hat allows the Process data model to connect t o external data sources. Connect Introduction.
Advertisements

1 Lecture 2: Processes, Requirements, and Use Cases.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
Systems development life cycle & development methodologies
Drawing System Sequence Diagrams
Lifecycle Phases time InceptionElaborationConstruction Transition  Define the scope of the project and develop business case  Inception Define the scope.
Case Study The NextGen POS System
Tutorial Week 7 PPM feedback PSR and Project Review Report.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
1/31 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2005] January 22, 2009.
1 Lecture 1: Processes, Requirements, and Use Cases.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Unified Modeling Language 7/12/2015B.Ramamurthy1 The Unified Modeling Language™ (UML) was developed jointly by Grady Booch, Ivar Jacobson, and Jim Rumbaugh.
1 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2002] January 26, 2006.
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
USE Case Model.
Software Engineering Chapter 12 The Generic Iteration Workflow Fall 2000.
The Rational Unified Process
Chapter – 6. Requirements Capture - Difficult A System has many Users. Each of them know what to do but no one knows the entire picture. Users do not.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Message Analysis Table.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
USE CASE Bayu Adhi Tama, MTI Faculty of Computer Science, University of Sriwijaya Slides are adapted from Petrus Mursanto
Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.
1 Analysis Extracting from Use Cases to Create Diagrams.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
♦ Use Case Model  Detailled use case - Important  Use case diagram- Refactoring Use case diagram  > 1 Last Lectures.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
2 2009/10 Object Oriented Technology 1 Topic 2: Introduction to Object-Oriented Approach Reference: u Ch.16 Current Trends in System Development (Satzinger:
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
COMP-350 Object-Oriented Analysis and Design Drawing System Sequence Diagrams Reference: Larman, Chapter 9.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
The Rational Unified Process 1 EECS810: Software Engineering.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix A Object-Oriented Analysis and Design A.1.
Basic Characteristics of Object-Oriented Systems
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Elaboration: Iteration 3. Elaboration: Iteration 3 Basics Inception and iteration-1 explored many basic OOA/D modeling basics. Iteration-2 narrowly emphasized.
Using Use Case Diagrams
The Basics of OOP Design
What is UML? What is UP? [Arlow and Neustadt, 2005] October 5, 2017
Unified Modeling Language
Use Case Model Use case diagram.
UML: Unified modeling language
Unified Modeling Language
Introduction to Software Engineering
Use Case Realization Describes a collaboration among analysis classes that shows how a specific use case is realized Consists of flow-of-events analysis,
Rational Unified Process
BBI 3423 LANGUAGE AND ICT.
Unified Modeling Language
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4th edition, Prentice Hall, Hans Van Vliet, Software Engineering:
Chapter 20 Object-Oriented Analysis and Design
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Appendix A Object-Oriented Analysis and Design
Analysis models and design models
Unified Modeling Language
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Using Use Case Diagrams
Business Modeling - Domain Analysis
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Engineering Quality Software
Design Yaodong Bi.
Use Case Analysis – continued
Appendix A Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Presentation transcript:

Software Development Process Aditya P. Mathur Purdue University Analysis: June 7-8, 1999 Design: June 9-11, 1999 @ Raytheon Technical Services, Indianapolis. Graduate Assistants: Sudipto Ghosh Matt Baarman Last update: June 6, 1999 Design Part I

Topics to be covered Review: Actors and use cases Development process Design Basic principles Collaboration diagrams Principles and guidelines (again) Class diagrams Deployment diagrams June 9-11, 1999 Software Design

Actors (1) Who is an actor? An entity “external” to the system. This entity participates in some way in at leas one domain process. This entity typically stimulates the system with input events or receives something from it. June 9-11, 1999 Software Design

Actors (2) Initiator Actor: Participating actor: Actors are usually: One who initiates a domain process. Participating actor: One who participates in a domain process. Actors are usually: Humans playing a role computer systems electrical or mechanical devices…anything remains ? June 9-11, 1999 Software Design

Actors (3) How to choose an actor? Identify a least one user who can enact an actor. Maintain a minimum overlap between the roles that instances of different actors play in relation to the system. Avoid two or more actors having the same or similar roles. June 9-11, 1999 Software Design

Use cases What is a use case? A domain process. We give it a name. We identify an actor that initiates this domain process and gets value out of this domain process. June 9-11, 1999 Software Design

Discussion Is the internet an actor ? Is a weapon an actor ? Compare the internet with the communication system used by POST to send logging information to a central computer in the store. Is a weapon an actor ? Compare the weapon with the Point of Sale Terminal (the actual cash register). Compare a commander-weapon pair with a buyer-seller pair. Any differences? Similarities? June 9-11, 1999 Software Design

A development process (1) Phases Workflows Iterations June 9-11, 1999 Software Design

A development process (2) Phases Inception Elaboration Construction Transition June 9-11, 1999 Software Design

A development process (3) Workflows Requirements Analysis Design Implementation Test June 9-11, 1999 Software Design

A development process (4) Iterations: Each phase might go through one or more iterations. Examples: Requirements might go through two iterations during the inception phase. In the elaboration phase one might go through two iterations of R, A, D, I, and T. June 9-11, 1999 Software Design

Workflows-Phases Inception Elaboration Construction Transition R A D I Iter# 1 Iter# 2... Iterations June 9-11, 1999 Software Design