Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements
|
|
- Christine Watson
- 1 years ago
- Views:
Transcription
1 Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements to be testable? EAssign.pdf Online!!! Deadline: 31 st of October 2011 / Faculteit Wiskunde en Informatica PAGE 0 / Faculteit Wiskunde en Informatica PAGE 1 Techniques for Gathering Requirements Gathering and Analysing Requirements Observation Read documents and discuss requirements with users Shadowing important potential users as they do their work Session video recording Interviewing Conduct a series of interviews Ask about specific details Ask about the stakeholder s vision for the future Ask if they have alternative ideas Ask for other sources of information Ask them to draw diagrams Brainstorming Prototyping The simplest kind: paper prototype. a set of pictures of the system that are shown to users in sequence to explain what would happen The most common: a mock-up of the system s UI Written in a rapid prototyping language Does not normally perform any computations, access any databases or interact with any other systems May prototype a particular aspect of the system / Faculteit Wiskunde en Informatica PAGE 2 / Faculteit Wiskunde en Informatica PAGE 3
2 Gathering and Analysing Requirements Level of detail required in a requirements document Use case analysis Determine the classes of users that will use the facilities of this system (actors) Determine the tasks that each actor will need to do with the system How much detail should be provided depends on: size of the system need to interface to other systems readership stage in requirements gathering level of experience with the domain and the technology cost that would be incurred if the requirements were faulty / Faculteit Wiskunde en Informatica PAGE 4 / Faculteit Wiskunde en Informatica PAGE 5 Representation of requirements Reviewing Requirements Each individual requirement should Have benefits that outweigh the costs of development Be important for the solution of the current problem Be expressed using a clear and consistent notation Be unambiguous Be logically consistent Lead to a system of sufficient quality Be realistic with available resources Be verifiable Be uniquely identifiable Does not over-constrain the design of the system / Faculteit Wiskunde en Informatica PAGE 6 / Faculteit Wiskunde en Informatica PAGE 7
3 Requirements Review Checklist Requirements Review Checklist (cont.) 1. Does each user requirement have a unique identifier? 2. Is each user requirement atomic and simply formulated? (Single sentence. Composite requirements can best be split.) 3. Are user requirements organized into coherent groups? (If necessary, hierarchical; not more than about ten per group.) 4. Is each user requirement verifiable (in a provisional acceptance test)? (Where possible, quantify.) 5. Is each user requirement prioritized? 6. Are all unstable user requirements marked as such? (TBC=`To Be Confirmed') 7. Are all user requirements necessary? 8. Are the user requirements complete? Can everything not explicitly constrained indeed be viewed as developer freedom? Is a product that satisfies every requirement indeed acceptable? (No requirements missing.) 9. Are the user requirements consistent? (Non-conflicting.) 10. Are the user requirements sufficiently precise and unambiguous? (Which interfaces are involved, who has the initiative, who supplies what data; avoid passive voice.) 11. Are the user requirements understandable to those who will need to work with them later? 12. Are the user requirements realizable within budget? / Faculteit Wiskunde en Informatica PAGE 8 / Faculteit Wiskunde en Informatica PAGE 9 Requirements Review Checklist (cont.) Requirements Review Checklist (cont.) 13. Do the user requirements express actual customer needs (in the language of the problem domain), rather than solutions (in developer jargon)? 14. Are the user requirements not overly restrictive? (Allow enough developer freedom.) 15. Is overlap among user requirements pointed out explicitly? (Redundancy; cross-reference.) 16. Are dependencies between user requirements pointed out explicitly? Are these consistent with the priorities? 17. Are the characteristics of users and of typical usage described in sufficient detail? (No user categories missing.) 18. Is the operational environment described in sufficient detail, including e.g. relevant data flows in the "outside" world that do not interact directly with the system? (No external interfaces missing. No capabilities missing. Diagram included.) / Faculteit Wiskunde en Informatica PAGE 10 / Faculteit Wiskunde en Informatica PAGE 11
4 Requirements documents Managing Changing Requirements The document should be: sufficiently complete well organized clear agreed to by all the stakeholders Traceability: Requirements change because: Business process changes Technology changes The problem becomes better understood rationale Requirements document 1.11 XXXX... because 1.2 YYYY Design document...due to requirement 1.2 / Faculteit Wiskunde en Informatica PAGE 12 / Faculteit Wiskunde en Informatica PAGE 13 Managing Changing Requirements V model for software development Requirements analysis never stops Continue to interact t with the clients and users The benefits of changes must outweigh the costs. Certain small changes (e.g. look and feel of the UI) are usually quick and easy to make at relatively little cost. Larger-scale changes have to be carefully assessed Forcing unexpected changes into a partially built system will probably result in a poor design and late delivery Some changes are enhancements in disguise Avoid making the system bigger, only make it better / Faculteit Wiskunde en Informatica PAGE 14 / Faculteit Wiskunde en Informatica PAGE 15
5 The Process of Design Design as a series of decisions Definition: Design is a problem-solving process whose objective is to find and describe a way: To implement the system s functional requirements... While respecting the constraints imposed by the quality, platform and process requirements... including the budget And while adhering to general principles of good quality A designer is faced with a series of design issues These are sub-problems of the overall design problem Each issue normally has several alternative solutions: design options: software vs hardware The designer makes a design decision to resolve each issue This process involves choosing the best option from the alternatives / Faculteit Wiskunde en Informatica PAGE 16 / Faculteit Wiskunde en Informatica PAGE 17 Making decisions From requirements to implementation To make each design decision, the software engineer uses: Knowledge of the requirements the design as created so far the technology available software design principles and best practices what has worked well in the past System: A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both. A system can have a specification which is then implemented by a collection of components. A system continues to exist, even if its components are changed or replaced. The goal of requirements analysis is to determine the responsibilities of a system. Subsystem: A system that is part of a larger system, and which has a definite interface / Faculteit Wiskunde en Informatica PAGE 18 / Faculteit Wiskunde en Informatica PAGE 19
6 From requirements to implementation From requirements to implementation Component: Any piece of software or hardware that has a clear role A component can be isolated, allowing you to replace it with a different component that has equivalent functionality Many components are designed to be reusable Conversely, others perform special-purpose functions Module: A component that is defined at programming language level For example: classes and packages are modules in Java Function: Unit at programming level with specific behaviour For example: methods in Java, functions in C / Faculteit Wiskunde en Informatica PAGE 20 / Faculteit Wiskunde en Informatica PAGE 21 Top-down and bottom-up design Top-down and bottom-up design Top-down design First design the very high level structure of the system Then gradually work down to detailed decisions about low- level constructs Finally arrive at detailed decisions such as: the format of particular data items; the individual algorithms that will be used Bottom-up design Make decisions about reusable low-level utilities Then decide how these will be put together to create high- level constructs A mix of top-down and bottom-up approaches are normally used: Top-down design is almost always needed to give the system a good structure Bottom-up design is normally useful so that reusable components can be created / Faculteit Wiskunde en Informatica PAGE 22 / Faculteit Wiskunde en Informatica PAGE 23
7 Different aspects of design UML and SysML Architecture design: The division into subsystems and components, How these will be connected How they will interact Their interfaces. Class design: The various features of classes User interface design Algorithm design: The design of computational mechanisms Protocol design: The design of communications protocol Based on the slides of Professor Insup Lee (University of Pennsylvania) / Faculteit Wiskunde en Informatica PAGE 24 / Faculteit Wiskunde en Informatica PAGE 25 The Unified Modeling Language g (UML) is A standard language for specifying, visualizing, constructing and documenting the artifacts of software systems, as well as for business modeling and other non-software systems The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems Six diagram types represent static application structure: Class Diagram Object Diagram Component Diagram Composite Structure Diagram Package Diagram Deployment Diagram / Faculteit Wiskunde en Informatica PAGE 26 / Faculteit Wiskunde en Informatica PAGE 27
8 Three diagram types represent general types of behavior: Use Case Diagram Activity Diagram State Machine Diagram Four diagram types represent different aspects of interactions Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram / Faculteit Wiskunde en Informatica PAGE 28 / Faculteit Wiskunde en Informatica PAGE 29 UML2 Super structure specification Structure diagrams: Class diagram Class diagram shows the relationships between the various classes in the System.The Classes being identified using the OOD paradigm. It s a static diagram and hence does not show the way in which the interaction happens. association -- an instance of one class must know about the other in order to perform its work. ( ) aggregation -- an association in which one class belongs to a collection. ( ) composition -- an association in which one class is composed of other classes.( ) generalization -- an inheritance link indicating one class is a superclass of the other. ( ) / Faculteit Wiskunde en Informatica PAGE 30 / Faculteit Wiskunde en Informatica PAGE 31
9 Structure diagrams: Class diagram Structure diagrams: Object diagram The relationships is shown in terms of the instances created of the objects that we defined The various objects instantiated are shown as well the relationships between th bj t those objects / Faculteit Wiskunde en Informatica PAGE 32 / Faculteit Wiskunde en Informatica PAGE 33 Structure diagrams: Package diagram Package diagram shows the hierarchy in which the system will be modeled in the implementation It gives a high level view for the distribution that can be created within the ifi d j t d if th k i ibilit specified project and specify the package visibility Structure diagrams: Composite Structure diagram Composite Structure diagram reflects the internal collaboration of classes, interfaces or components to describe a functionality Composite Structure diagrams are similar to Class diagrams, except that they model a specific usage of the structure Composite Structure diagram is used to express run-time architectures, usage patterns, and the participating elements' relationships, which might not be reflected by static diagrams / Faculteit Wiskunde en Informatica PAGE 34 / Faculteit Wiskunde en Informatica PAGE 35
10 Structure diagrams: Composite Structure diagram Structure diagrams: Deployment diagram Deployment diagram shows how and where the system will be deployed. Physical machines and processors are reflected as nodes, and the internal construction can be depicted by embedding nodes or artifacts / Faculteit Wiskunde en Informatica PAGE 36 / Faculteit Wiskunde en Informatica PAGE 37 Structure diagrams: Component diagram Component diagram illustrates the pieces of software, embedded controllers, etc. that will make up a system. Component diagram has a higher level of abstraction than a Class diagram - usually a component is implemented by one or more classes (or objects) at runtime Behavior diagrams: Use case diagram Use cases diagram basically are a substitute of the requirements being Modeled into the architecture. The external viewpoint as to what the System should do rather how / Faculteit Wiskunde en Informatica PAGE 38 / Faculteit Wiskunde en Informatica PAGE 39
11 Behavior diagrams: Activity diagram Activity diagrams are used to model the behaviors of a system, and the way in which these behaviors are related in an overall flow of the system The logical paths a process follows, based on various conditions, concurrent processing, data access, interruptions and other logical path distinctions, are all used to construct a process, system or procedure Behavior diagrams: Activity diagram / Faculteit Wiskunde en Informatica PAGE 40 / Faculteit Wiskunde en Informatica PAGE 41 Behavior diagrams: State Machine diagram A State Machine diagram illustrates how an element, often a class, can move between states classifying its behavior, according to transition triggers, constraining guards and other aspects of State Machine diagrams that depict and explain movement and behavior Interaction diagrams: Sequence diagram Sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when Sequence diagrams are organized according to time expressed in the sequential order along the vertical plane / Faculteit Wiskunde en Informatica PAGE 42 / Faculteit Wiskunde en Informatica PAGE 43
12 Interaction diagrams: Sequence diagram Interaction diagrams: Communication/Collaboration diagram Communication diagram shows the interactions between elements at runtime in much the same manner as a Sequence diagram. Communication diagrams are used to visualize inter-object relationships, while Sequence diagrams are more effective at visualizing processing over time / Faculteit Wiskunde en Informatica PAGE 44 / Faculteit Wiskunde en Informatica PAGE 45 Interaction diagrams: Communication/Collaboration diagram Interaction diagrams: Timing diagram Timing diagram defines the behavior of different objects within a time-scale Provides a visual representation of objects changing state and interacting over time. Used for defining hardware-driven or embedded software components / Faculteit Wiskunde en Informatica PAGE 46 / Faculteit Wiskunde en Informatica PAGE 47
13 Interaction diagrams: Interaction Overview diagram Interaction Overview diagrams visualize the cooperation between other interaction diagrams to illustrate a control flow serving an encompassing purpose Interaction ti Overview diagrams are a variant of activity it diagrams, most of the diagram notation is similar, as is the process in constructing the diagram Interaction elements display an inline Interaction diagram, which can be a Sequence diagram, Communication diagram, Timing diagram, or Interaction Overview diagrams Interaction diagrams: Interaction Overview diagram / Faculteit Wiskunde en Informatica PAGE 48 / Faculteit Wiskunde en Informatica PAGE 49
4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java
4.1 Domain Analysis Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing The process by which a software engineer learns about the domain to better
4.4 What is a Requirement? 4.5 Types of Requirements. Functional Requirements
4.4 What is a Requirement? It is a statement describing either 1) an aspect of what the proposed system must do, or 2) a constraint on the system s development. In either case it must contribute in some
What is Automotive Software Engineering? What is Automotive Software Engineering? What is Automotive Software Engineering?
Process models: Capability Maturity Model Integration (CMMI) Software Process Improvement and Capability Determination (SPICE) V-Model Standards: MISRA-C standard AUTOSAR Configuration management Product
QUESTION BANK. Dhulapally, Secunderabad Class : IT III. Subject: OBJECT ORIENTED ANALYSIS AND DESIGN GROUP - A (SHORT ANSWER QUESTIONS)
St.MARTIN S ENGINEERING COLLEGE Dhulapally, Secunderabad-500 014 Subject: OBJECT ORIENTED ANALYSIS AND DESIGN Class : IT III QUESTION BANK GROUP - A (SHORT ANSWER QUESTIONS) UNIT I 1. Define UML. 2. Explain
Object-Oriented Systems Analysis and Design with UML
Object-Oriented Systems Analysis and Design with UML OBJECTIVES: Understand the basic characteristics of objectoriented systems. Be familiar with the Unified Modeling Language (UML), Version 2.0. Be familiar
Requirements engineering
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
Principles Leading to Good Design. Techniques for making design decisions. Using cost-benefit analysis to choose. Writing a Good Design Document
Principles Leading to Good Design Techniques for making design decisions Overall goals of good design: Increasing profit by reducing cost and increasing revenue Ensuring that we actually conform with the
SysML vs. UML 2: A Detailed Comparison. Pascal Roques MoDELS 11 Tutorial October 16th, 2011
SysML vs. UML 2: A Detailed Comparison Pascal Roques MoDELS 11 Tutorial October 16th, 2011 The Speaker: Pascal Roques Senior Consultant & Trainer, > 20 years experience in modeling SADT, OMT, UML, SysML
Unified Modeling Language (UML) for Database Systems and Computer Applications
Unified Modeling Language (UML) for Database Systems and Computer Applications Sunguk Lee * Research Institute of Industrial Science and Technology Pohang, Korea sunguk@rist.re.kr *Correspondent Author:
Software Engineering. Oriented Design. Based on Software Engineering, 7 th Edition by Ian Sommerville
Software Engineering Object-Oriented Oriented Design Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain how a software design may be represented as a set of interacting
Applying 4+1 View Architecture with UML 2. White Paper
Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was
i. Node Y Represented by a block or part. SysML::Block,
OMG SysML Requirements Traceability (informative) This document has been published as OMG document ptc/07-03-09 so it can be referenced by Annex E of the OMG SysML specification. This document describes
Chapter 8 The Enhanced Entity- Relationship (EER) Model
Chapter 8 The Enhanced Entity- Relationship (EER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 Outline Subclasses, Superclasses, and Inheritance Specialization
Software Engineering Reference Framework
Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of
INSTITUTE OF AERONAUTICAL ENGINEERING (Autonomous) Dundigal, Hyderabad
Title Code Regulation INSTITUTE OF AERONAUTICAL ENGINEERING (Autonomous) Dundigal, Hyderabad - 500 043 INFORMATION TECHNOLOGY QUESTION BANK OBJECT ORIENTED ANALYSIS AND DESIGN A60524 R13 Structure Lectures
The Role of the Software Architect
IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation
RUP Design Workflow. Michael Fourman Cs2 Software Engineering
RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall
Integration of ArchiMate and UML. Harmen van den Berg & Henk Jonkers
Integration of ArchiMate and UML Harmen van den Berg & Henk Jonkers What is UML? The Unified Modeling Language (UML ) is a visual language for specifying, constructing, and documenting the artifacts of
MLR Institute of Technology
MLR Institute of Technology Dundigal, Hyderabad - 500 043 COMPUTER SCIENCE AND ENGINEERING QUESTION BANK Title OBJECT ORIENTED ANALYSIS AND DESIGN Code 56028 Regulation R09 Structure Lectures Tutorials
Aerospace Software Engineering
16.35 Aerospace Software Engineering Software Architecture The 4+1 view Patterns Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Why Care About Software Architecture? An architecture provides a vehicle
Chap 1. Introduction to Software Architecture
Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)
UML TUTORIALS THE USE CASE MODEL
UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between
CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective:
CS 487 Week 8 Reading: 1. Ian Sommerville, Chapter 3. Objective: 1. To check the understandibility of the students in life cycle and process model for development of a software product. 2. To check if
The MCSE Methodology. overview. the mcse design process. if a picture is worth a thousand words, an executable model is worth a thousand pictures
The MCSE Methodology overview if a picture is worth a thousand words, an executable model is worth a thousand pictures The MCSE methodology the mcse methodology (méthodologie de conception des Systèmes
Using UML Part One Structural Modeling Diagrams
UML Tutorials Using UML Part One Structural Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,
Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville
Software Engineering System Models Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain why the context of a system should be modeled as part of the RE process To describe
Requirements engineering and quality attributes
Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................
Problem Analysis : Concepts and Techniques
4 Problem Analysis : Concepts and Techniques Problem Analysis Definition: the process of understanding the real-world problems and users needs and proposing abstract solutions to those problems. Goal:
Systems Analysis and Design
Systems Analysis and Design Slides adapted from Jeffrey A. Hoffer, University of Dayton Joey F. George, Florida State University Joseph S. Valacich, Washington State University Modern Systems Analysis
Designing Real-Time and Embedded Systems with the COMET/UML method
By Hassan Gomaa, Department of Information and Software Engineering, George Mason University. Designing Real-Time and Embedded Systems with the COMET/UML method Most object-oriented analysis and design
Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces
Software Engineering, Lecture 4 Decomposition into suitable parts Cross cutting concerns Design patterns I will also give an example scenario that you are supposed to analyse and make synthesis from The
TOGAF usage in outsourcing of software development
Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky
Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011
Use Cases Massimo Felici Use Cases 1 Support requirements engineering activities and the requirement process Capture what a system is supposed to do, i.e., systems functional requirements Describe sequences
What is a life cycle model?
What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each
To introduce software process models To describe three generic process models and when they may be used
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
Open S-BPM: Goals and Architecture
Open S-BPM: Goals and Architecture Albert Fleischmann Werner Schmidt Table of Content 1 Introduction... 2 2 Mission, Vision and Objectives... 2 3 Research and Development Areas... 3 4 Open S-BPM Architecture...
11 Tips to make the requirements definition process more effective and results more usable
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
Object Oriented Design
Object Oriented Design Kenneth M. Anderson Lecture 20 CSCI 5828: Foundations of Software Engineering OO Design 1 Object-Oriented Design Traditional procedural systems separate data and procedures, and
TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.
CH04 Capturing the Requirements Understanding what the customers and users expect the system to do * The Requirements Process * Types of Requirements * Characteristics of Requirements * How to Express
SysML Modelling Language explained
Date: 7 th October 2010 Author: Guillaume FINANCE, Objet Direct Analyst & Consultant UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling
Structural specification: beyond class diagrams
2IW80 Software specification and architecture Structural specification: beyond class diagrams Alexander Serebrenik Before we start Match the pairs 1 Association A 2 Aggregation B 3 Composition C 4 Implementation
Adaptive Radio. Cognitive Radio
What are Cognitive Radio and Dynamic Spectrum Access SDR can act as a key enabling technology for a variety of other reconfigurable radio equipments commonly discussed in the advanced wireless market 1.
Mastering increasing product complexity with Collaborative Systems Engineering and PLM
Mastering increasing product complexity with Collaborative Systems Engineering and PLM Thierry Ambroisine Dassault Systèmes 10 rue Marcel Dassault, 78140 Vélizy Villacoublay, France thierry.ambroisine@3ds.com
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which
Software Development in the Large!
Software Development in the Large! Peter Eeles Executive IT Architect, IBM peter.eeles@uk.ibm.com IBM Rational Software Development Conference 2007 2007 IBM Corporation Agenda IBM Rational Software Development
Architecture for an Online Learning System
Architecture for an Online Learning System Utrecht University Vincent Vonk Michel Wasmann Diana Sidharta January 14, 2008 Contents 1. Introduction... 3 2. Stakeholders and Concerns... 3 2.1 Stakeholders...
Architectural Design
Software Engineering Architectural Design 1 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural
Vragen. Architecture presentations in practice. Some terms (from IEEE standard)
Vragen Architecture presentations in practice Waarom is software architectuur belangrijk? Waarom schiet de volgende definitie tekort? The architecture of a software system defines that system in terms
Requirement Analysis with UML
Requirement Analysis with UML Pierre-Alain Muller pa.muller@uha.fr V 2.0 Requirement Analysis 1 Pierre-Alain Muller 15+ years experience in OO modeling Assistant professor at ENSISA (a French school of
A complete software development process of a general report publication service implemented using Web Services
A complete software development process of a general report publication service implemented using Web Services Anders Nilsson & Klas Fahlberg February 1, 2008 Master s Thesis in Computing Science, 2*30
Fourth generation techniques (4GT)
Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some
Masters of Science in Software & Information Systems
Masters of Science in Software & Information Systems To be developed and delivered in conjunction with Regis University, School for Professional Studies Object Oriented Design Table of Contents January
JOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2007 Vol. 6, No. 1, January-February 2007 CM Configuration Change Management John D.
Object Oriented Programming. Risk Management
Section V: Object Oriented Programming Risk Management In theory, there is no difference between theory and practice. But, in practice, there is. - Jan van de Snepscheut 427 Chapter 21: Unified Modeling
Requirements Engineering Process
Software Engineering Requirements Engineering Process Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To describe the principal requirements engineering activities and d their
The SPES Methodology Modeling- and Analysis Techniques
The SPES Methodology Modeling- and Analysis Techniques Dr. Wolfgang Böhm Technische Universität München boehmw@in.tum.de Agenda SPES_XT Project Overview Some Basic Notions The SPES Methodology SPES_XT
SOFTWARE ENGINEERING INTERVIEW QUESTIONS
SOFTWARE ENGINEERING INTERVIEW QUESTIONS http://www.tutorialspoint.com/software_engineering/software_engineering_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Software Engineering
Software Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 5 Integrated Object-Oriented Methodologies: OPM and Catalysis 1 Object Process Methodology (OPM) Introduced by Dori in 1995 Primarily intended
Engineering Process Software Qualities Software Architectural Design
Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical
Object-Oriented Systems Analysis and Design
Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS
An Introduction to Design Patterns
An Introduction to Design Patterns 1. Introduction The philosophy behind design patterns is to document the experiences of software developers in designing software systems and reuse solutions found to
Information Science 1
Topics covered Information Science 1 Terms and concepts from Week 05 The software development process Program'Development /Algorithms'and'Problem'Solving/'' ' software software life cycle life-cycle models
Meta-Model specification V2 D602.012
PROPRIETARY RIGHTS STATEMENT THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR
Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville
Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when
1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...
1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand
Compliance and Requirement Traceability for SysML v.1.0a
1. Introduction: Compliance and Traceability for SysML v.1.0a This document provides a formal statement of compliance and associated requirement traceability for the SysML v. 1.0 alpha specification, which
Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions
Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group
Introduction to software architecture
Learning Unit 1 Introduction to software architecture Contents Introduction............................................... 7 1.1 What is software architecture?................................. 7 1.1.1
Overview. Software Design Principles and Guidelines 9/16/08. Adam Porter Sept. 16, Design Principles. Design Guidelines
Software Design Principles and Guidelines Adam Porter Sept. 16, 2008 Overview Design Principles Important design concepts Useful design principles Design Guidelines Motivation Design Rules 1 Goals of the
Using UML Part Two Behavioral Modeling Diagrams
UML Tutorials Using UML Part Two Behavioral Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,
Classical Software Life Cycle Models
Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation
CSE 5324: Software Engineering I (Analysis, Design, Creation)
CSE 5324: Software Engineering I (Analysis, Design, Creation) Review Preview Brooks Book Chapter New stuff What is important What is next... Last class(es): Software Engineering is... Introduction, Terms,
Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis
Requirements engineering processes Requirements Engineering Processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the.
Non-Functional Requirements
IBM Software Group Non-Functional Requirements Peter Eeles peter.eeles@uk.ibm.com Agenda IBM Software Group Rational software Definitions Types of requirement Classifying requirements Capturing NFRs Summary
An Approach to Software Architecture Description Using UML
An Approach to Software Architecture Description Using UML Henrik Bærbak Christensen, Aino Corry, and Klaus Marius Hansen Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N,
Design of UML models and their simulation using ARENA
Design of UML models and their simulation using ARENA ARTIS TEILANS and ARNIS KLEINS Exigen Services DATI 17a Ganibu Dambis, LV-1045, Riga LATVIA artis.teilans@exigenservices.com arnis.kleins@exigenservices.com
CHAPTER 13 OBJECT-ORIENTED ANALYSIS
Lecture Software Engineering CHAPTER 13 OBJECT-ORIENTED ANALYSIS Lecture Software Engineering Topics Introduction The Analysis Workflow Extracting the Entity Classes Object-Oriented Analysis: The Elevator
Java Programming (10155)
Java Programming (10155) Rationale Statement: The world is full of problems that need to be solved or that need a program to solve them faster. In computer, programming students will learn how to solve
Application of UML in Real-Time Embedded Systems
Application of UML in Real-Time Embedded Systems Aman Kaur King s College London, London, UK Email: aman.kaur@kcl.ac.uk Rajeev Arora Mechanical Engineering Department, Invertis University, Invertis Village,
Software Design and Class Diagrams
Software Design and Class Diagrams Massimo Felici Software Design 1 The SEOC course is concerned with software design in terms of objects and components, in particular, object-oriented design Object-oriented
Interactive system specification. Interactive system definition. Issues to be taken into account for interactive systems
Interactive system specification From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 1 Interactive system definition Interactive systems can be defined as
Software Architecture Document
Software Architecture Document Natural Language Processing Cell Version 1.0 Natural Language Processing Cell Software Architecture Document Version 1.0 1 1. Table of Contents 1. Table of Contents... 2
JAIN tm, a set of Java tm APIs for Integrated Networks
JAIN tm, a set of Java tm APIs for Integrated Networks JAIN JAVA CALL CONTROL (JCC) APPLICATION PROGRAMMING INTERFACE (API) Version 0.. Overview of the API September 1, 000 Copyright 000 Sun Microsystems,
Introduction. UML = Unified Modeling Language It is a standardized visual modeling language.
UML 1 Introduction UML = Unified Modeling Language It is a standardized visual modeling language. Primarily intended for modeling software systems. Also used for business modeling. UML evolved from earlier
Component Based Development in Software Engineering
Component Based Development in Software Engineering Amandeep Bakshi, Rupinder Singh Abstract--In today s world, Component Based development is an active research area for more than a decade in software
Chapter 4 Software Lifecycle and Performance Analysis
Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and
Establishing Great Software Development Process(es) for Your Organization. By Dale Mayes DMayes@HomePortEngineering.com
Establishing Great Software Development Process(es) for Your Organization By Dale Mayes DMayes@HomePortEngineering.com Class: ETP-410 Embedded Systems Conference San Francisco 2005 Abstract: There are
1 UML Tutorial. The Unified Modeling Language has quickly become the de-facto standard for building Object-Oriented software.
1 UML Tutorial The Unified Modeling Language has quickly become the de-facto standard for building Object-Oriented software. The OMG specification states: "The Unified Modeling Language (UML) is a graphical
JOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,
CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping
Requirements Engineering Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1
Requirements Engineering Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1 Objectives To describe the principal requirements engineering activities and their relationships
UML-based Test Generation and Execution
UML-based Test Generation and Execution Jean Hartmann, Marlon Vieira, Herb Foster, Axel Ruder Siemens Corporate Research, Inc. 755 College Road East Princeton NJ 08540, USA jeanhartmann@siemens.com ABSTRACT
Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics:
Organization of DSLE part Domain Specific Language Engineering Tooling Eclipse plus EMF Xtext, Xtend, Xpand, QVTo and ATL Prof.dr. Mark van den Brand GLT 2010/11 Topics: Meta-modeling Model transformations
Configuration & Build Management
Object-Oriented Software Engineering Using UML, Patterns, and Java Configuration & Build Management Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration
Object-Oriented Design Guidelines
Adaptive Software Engineering G22.3033-007 Session 8 Sub-Topic 3 Presentation Object-Oriented Design Guidelines Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute
Software Engineering in a Nutshell
Overview of Software Engineering Principles 1 Software Engineering in a Nutshell Development of software systems whose size/ complexity warrants a team or teams of engineers multi-person construction of
Design methods. List of possible design methods. Functional decomposition. Data flow design. Functional decomposition. Data Flow Design (SA/SD)
Design methods List of possible design methods Functional decomposition Data Flow Design (SA/SD) Design based on Data Structures (JSD/JSP) OO is good, isn t it Decision tables E-R Flowcharts FSM JSD JSP
Lesson 8: DESIGN PROCESSES AND DESIGN METRIC FOR AN EMBEDDED-SYSTEM DESIGN
Lesson 8: DESIGN PROCESSES AND DESIGN METRIC FOR AN EMBEDDED-SYSTEM DESIGN 1 Abstraction Each problem component first abstracted. For example, Display picture and text as an abstract class Robotic system
Acknowledgement. Software Engineering. CS 3141: Team Software Project Introduction
CS 3141: Team Software Project Introduction Ali Ebnenasir Department of Computer Science Michigan Technological University Acknowledgement Betty H.C. Cheng Software Engineering Systematic approach for