Session 1b: Overview of systems analysis methodology
|
|
- Lee Lambert
- 6 years ago
- Views:
Transcription
1 Session 1b: Overview of systems analysis methodology The system specification (ESD) Ways of documenting an ESD Criteria to be satisfied Historical survey Comp 320 / 420, spring, 2018 Alternative names for the main product of systems analysis Functional specifications (Detailed) User requirements External system design (ESD) Whatever we call it, it must describe: everything about what the proposed new application system will do nothing (or as little as possible) about how. Why not? Criteria for the ESD This is (or should be) non-controversial! 1. Must be understandable in complete detail by How do we know? 3. Must provide a reasonable basis for estimating the rest of the project. Experts may disagree about how well a particular technique supports the criteria, but let's agree on the criteria themselves. Why? A non-criterion for the ESD "The ESD is final. The specifications are frozen until the new system is installed." We hear this one not as a serious proposal, but more often as a canard accusation from those who favor doing away with rigorous specifications altogether! No matter what technique we choose for documenting the ESD, we must be able to respond at any time during the project to: new insights changing environment discovering errors or omissions COMP 320 / copyright Conrad Weisert
2 Rough chronology of ESD documentation methodology ~1959: Iterative development ~1966: "Victorian novel" ~1980: Structured analysis ~1990: Object-oriented analysis ~1996: Unified Modeling Language ~1999: Discrete requirements list ~2004: Use-cases stories ~2008: Iterative development! Which ones satisfy our criteria for the ESD? Iterative software development Programmer and sponsoring end user confer; programmer takes notes. Programmer develops partial "solution" based on understanding of the problem Programmer shows output to sponsor. What needs to be changed or added? Programmer revises program accordingly Which ESD criterion does this violate? nothing Done Criteria for the ESD 1. Must be understandable in full detail by 3. Must provide a reasonable basis for estimating cost and time for development. (NOTE: "Iterative development" violates this criterion) "Victorian novel" approach Analyst prepares a collection of documents consisting of: narrative description of everything the proposed system is to do, usually in processing sequence. flow charts showing processing sequence and decision logic record layouts for master files, work files, input transations, and output reports. Derogatory term coined by Tom DeMarco reflects massive size, especially of the narrative sections. Which ESD criteria does this violate? COMP 320 / copyright Conrad Weisert
3 Criteria for the ESD 1. Must be understandable in full detail by 3. Must provide a reasonable basis for estimating. The structured revolution ~1972: Structured programming publicized by Harlan Mills et al. as a systematic approach to software organization It consisted of Structured coding (go-to-less flow control) Structured design (highly modular with minimal coupling, etc.) Top-down stepwise refinement deveopment sequence It put a floor under how bad programs could be. It was considered a huge success. But systems analysis was still a major impediment to smooth, predictable software development. More structured revolution ~1975: We ought to be able to do for analysis something similar to SP ~1979: Structured analysis Published by: Gane & Sarson Tom DeMarco (others) Not directly related to structured programming Not a way of doing analysis, but just of documenting the results, i.e. the System specification Characteristics of SA Centered on a system model Emphasis on graphical rather than narrative documentation. Hierarchical organization A definite place to start Every component is tied to its context We know when the specification is complete The dataflow diagram ties everything together provides an understandable picture of the system COMP 320 / copyright Conrad Weisert
4 Structured specification components 1. Dataflow diagrams showing a. processes b. data stores c. interfaces to users and to other systems d. dataflows between pairs of the above 2. Data dictionary showing a. composition of composite data items b. rigorous definition of elementary data items 3. Process specifications a. algorithms b. decision rules Which ESD criteria does this violate? Criteria for the ESD 1. Must be understandable in full detail by 3. Must provide a reasonable basis for estimating. Object-oriented analysis (OOA) ~1990: Object-oriented programming was becoming well established. By analogy with structured programming inspiring structured analysis, experts tried to apply object oriented concepts to systems analysis What object-oriented concepts? Early OOA books Coad & Yourdon (1991) Booch (1994) Rumbaugh (1991) Object-oriented characteristics Emphasis on the data model Class structure (Abstract Data Type) Always Hidden internal representation Encapsulated operations (methods, functions) Potential for Inheritance Polymorphism What do all of those mean? Why are they desirable? COMP 320 / copyright Conrad Weisert
5 Shortcomings of early OOA Incomplete set of tools for modeling a system specification. Emphasis was on the data model (class hierarchy). Weak on processes Confusing competing approaches (especially graphical symbols). OOA was initially a flop. What could be done to rescue it? UML OOA was considered a good idea, but the confusion of different versions slowed acceptance. Unified Modeling Language eliminated differences among competing OOA versions Booch & Rumbaugh both hired by Rational; told to cooperate on a single set of graphical conventions Blessed as a standard by OMG Who's that? UML has been immune from most criticism "It's not a methodology, only a language." Therefore UML promoters reject criticisms on methodology grounds. "It's not for system specification, but for system modeling." Therefore UML promoters reject criticisms on understandability grounds. Which ESD criteria does UML fail to satisfy? Criteria for the ESD 1. Must be understandable in full detail by 3. Must provide a reasonable basis for estimating. (more to come about UML) COMP 320 / copyright Conrad Weisert
6 Repairing UML It was clear that UML's diagrams were incomprehensible to non-technical people without special training. In response Ivar Jacobson suggested adding use-case scenarios to UML. He had also joined Rational and contributed with Booch & Rumbaugh to UML BUT there is nothing object-oriented about use cases! You can do OOA without use cases You can use use cases without OOA What are use cases? A return to sequential narratives that were popular in the 1960s More modern notations Emphasis on mainline process; worry about exceptions later cf. agile "stories" Unstructured; hard for a reader to know where to start, when to stop, how individual use cases are related Let's look at UML with use cases Is the UML a methodology component Of course. When UML gurus claim it's not, they mean only that it's not a standard process or system development life cycle. Actually it is closely tied to its own standard life cycle! It's called the UP (but it has nothing to do with a part of Michigan). The UML's Life Cycle Since UML is process-independent, UML gurus advise that it's OK to follow any SDLC you like, as long as that life cycle is: use-case driven architecture centric iterative and incremental By the way, here's one ("Objectory" -- Jacobson): 1. inception phase 2. elaboration phase 3. construction phase 4. transition phase Rational has renamed it. RUP 5 COMP 320 / copyright Conrad Weisert
7 Objectory (UP) project phases 1. Inception phase: Like traditional "project initiation" + "business requirements" Defines: project scope initial justification 2. Elaboration phase: Is this where we do most of the systems analysis? Like traditional "functional specifications" or "external design" "During the elaboration phase you need to get a good handle on the requirements and their relative priorities." - Fowler p. 17 Objectory phases (continued) Elaboration phase (another view): "... usually uses one iteration cycle and involves the following activities: Elaborate the specification of the effort from the previous phase. Baseline and completely delimit scope, objectives, and requirements. Baseline the business case by solidifying the vision, solidifying success criteria, and mitigating the highest risks. Baseline the plan with a schedule. Distribute the requirements among multiple iteration cycles within the construction phase. more... Objectory phases (continued) Elaboration phase (continued): Focus on understanding or forming a notion of the problem to determine the requirements that the problem imposes on its solution..., establishing and verifying the foundation for the overall solution (architectural design) and distributing the requirements among the iteration cycles of the construction development phase. - Alhir, p. 23 Clearing it all up "During the elaboration phase, as we have already noted, we build the architecture. We identify the use cases that have a significant impact on the architecture. We realize these use cases as collaborations. It is in this way that we identify most of the subsystems and interfaces -- at least the ones that are architecturally interesting. Once most of the subsystems and interfaces are identified, we flesh them out, that is, write the code that implements them. Some of this work is done before we release the architectural baseline and it continues throughout all of the workflows." - Ivar Jacobson COMP 320 / copyright Conrad Weisert
8 Objectory phases (continued) 3. Construction phase (Fowler p. 15): "... consists of many iterations, in which each iteration builds production quality software... that satisfies a subset of the requirements....each iteration contains all the usual life-cycle phases of analysis, design, implementation, and testing. In principle you can start at the beginning: Pick some functionality and build it, pick some other functionality, and so forth. However it is worthwhile to spend some time planning." Wait! There's more. Objectory phases (continued) 3. Construction phase (UML UG p. 34): "... the third phase of the process, when the software is brought from an executable architectural baseline to being ready to be transitioned to the user community. Here also, the system's requirements and especially its evaluation criteria are constantly reexamined against the business needs of the project, and resources are allocated... to actively attack risks to the project." Which version do we like better? Objectory phases (continued) 4. Transition phase: Like the traditional "installation phase" + ongoing maintenance + more "iterations". When does the project end? Objectory phases (concluded) Summary: A little of this and a little of that in each phase. Emphasis on system architecture from the start poses serious problems: obscures the business problem or opportunity blurs distinction between analysis and design What else? Descriptions by gurus marred by vagueness and lack of rigor ("get a handle on", "form a notion of", etc.) COMP 320 / copyright Conrad Weisert
9 Hold everything! We forgot something important A widespread policy for application system development in organizations "We will develop custom application software only when it is shown that no suitable packaged software product exists." Not a variant, but the mainstream in many, probably most, user organizations since ~1980 This policy is foreclosed when requirements "emerge" by iteration. Is that obvious? How does it affect systems analysis? Five views of a system Design view Process view use-case view Implementation view Deployment view from UML Users' Guide, p. 31 What ties them all together? Who makes sure they're consistent? Modeling different views "When you model a system from different views, you are in effect constructing your system simultaneously from multiple dimensions.... If you do a poor job of choosing these views or if you focus on one view and the expense of all others, you run the risk of hiding issues and deferring problems that will eventually destroy any chance of success." - UML UG p. 98 How do you decide? So, which ESD criteria are satisfied by UML with use-cases? COMP 320 / copyright Conrad Weisert
10 Criteria for the ESD 1. Must be understandable in full detail by 3. Must provide a reasonable basis for estimating. Lots more kinds of UML diagram Class diagrams Object diagrams Package diagrams Activity diagrams Interaction diagrams sequence diagrams collaboration diagrams State-transition diagrams Deployment diagrams What's the problem with that? Class diagrams "Static design view" of a system One point of similarity between UML and other versions of OOA (e.g. Coad & Yourdon) For each type of data item, specifies: Its attributes (components / "has-a" hierarchy) Its behavior (methods / interface) For related classes: Inheritance ("is-a" hierarchy) Entity-relationships Logical database design Some UML issues (?) Assumes custom architecture and in-house software development; little provision for evaluating, selecting, and integrating application program packages There's no clear starting point: for creating the specification for reading the specification-+ There's no sure way of knowing when the model is complete. Relies on the system modeler to keep multiple independent diagrams and other documents consistent with one another COMP 320 / copyright Conrad Weisert
11 A giant step backward After it became clear that UML, even with use-cases, was incomprehensible to most non-technical audiences, UML promoters: did not suggest any ways of improving UML, but instead recommended separating requirements (before we start UML) from modeling & design This has led to yet another approach to documenting requirements: The discrete requirements list. Another phase before UML's 4 phases! Discrete requirements list Unstructured list, usually numbered, of prescriptive English statements in a form like: "The system shall... Some are functional; others "non-functional" What's that? Which ESD criteria does that satisfy? Criteria for the ESD 1. Must be understandable in full detail by It all sounds plausible, so they think they've understood. 3. Must provide a reasonable basis for estimating. A recommended 2018 methodology for documenting the results of systems analysis Continue using a modernized Structured Systems Analysis (e.g. per De Marco, 1978) as the framework. Use O.O. class diagrams, in the data dictionary encapsulated behavior where appropriate, inheritance. What else? Continue following a disciplined SDLC. What SDLC? COMP 320 / copyright Conrad Weisert
12 A sample Life Cycle for Application System Development 1. Project definition 2. Business requirements specification 3. External design What are other names for this phase? 4. System architecture 5. Construction 6. Installation 7. Review In this course, we don't care what happens in these later phases. The Waterfall Approach There's no such thing among responsible and knowledgeable project managers! The term was coined as a pejorative by methodologists trying to discredit the phased SDLC. It implies extreme inflexibility: Once the deliverables from phase N are approved, you must move on to phase N+1; you can't return to phase N or an earlier phase! Until the deliverables from phase N are approved, you may not start on phase N+1! Examine phase deliverables Re-do part of phase, or.. End-of-phase decisions Satisfactory? Y Review budget & schedule for next phase N Content Funding Review Review Y More funds available? N Abort project N Assess costs, benefits, & risks Justified? Y Next phase Alternatives to a formal ESD A. "Emergent specifications" A return to iterative development Test-driven development can use the test cases as specifications. What's wrong with that? B. Users' manual If you have to prepare a manual anyway, why not use it as the specification? What kind of system would that work for? Do all modern applications have a detailed users' manual? COMP 320 / copyright Conrad Weisert
13 Methodology choices for this course We've seen that the practice of systems analysis in 2018 is characterized by vigorous disgreements among practitioners and even "experts". In this course we shall: Follow mainstream approaches that have been shown to work well. Describe some of the popular alternatives to those approaches, citing pros and cons. Other alternatives for course assignments & examinations What if you strongly prefer some alternative approach, because: you work for a company that has adopted it? you took some other course that persuasively recommended it? you've formed your own well-thought-out independent judgment? That's all right, as long as you: Understand the mainstream methods we present in this course. Can explain why your approach is more appropriate than the methods presented in the course. Raise questions if you're unsure. COMP 320 / copyright Conrad Weisert
Session 8: UML The Unified Modeling (or the Unstructured Muddling) language?
Session 8: UML The Unified Modeling (or the Unstructured Muddling) language? A few observations, opinions, pros & cons COMP 320 / 420 Spring, 2018 Mr. Weisert Where did the UML come from? Object-oriented
More informationSession 2b: structured specifications Purpose and criteria Structured specification components Introduction to dataflow diagrams
Session 2b: structured specifications Purpose and criteria Structured specification components Introduction to dataflow diagrams COMP 320 / 420, Spring, 2018 Conrad Weisert Criteria for the ESD (from session
More informationIntroduction. Chapter 1. What Is Visual Modeling? The Triangle for Success. The Role of Notation. History of the UML. The Role of Process
Quatrani_Ch.01.fm Page 1 Friday, October 27, 2000 9:02 AM Chapter 1 Introduction What Is Visual Modeling? The Triangle for Success The Role of Notation History of the UML The Role of Process What Is Iterative
More informationUNIT-I Introduction of Object Oriented Modeling
UNIT-I Introduction of Object Oriented Modeling - Prasad Mahale Object Oriented Modeling and Reference Books: Design 1. Grady Booch, James Rumbaugh, Ivar Jacobson Unified Modeling Language User Guide,
More informationHistory of object-oriented approaches
Prof. Dr. Nizamettin AYDIN naydin@yildiz.edu.tr http://www.yildiz.edu.tr/~naydin Object-Oriented Oriented Systems Analysis and Design with the UML Objectives: Understand the basic characteristics of object-oriented
More informationSystems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, Fourth Edition Systems Analysis and Design in a Changing World, 4th Edition Learning Objectives Explain the purpose and various phases of the systems development
More informationSession 2. Getting started with a well-structured system specification
Session 2 Getting started with a well-structured system specification COMP 320/420 Spring, 2018 Conrad Weisert The situation A representative approaches us. (or vice versa) He or she may be a. an executive
More informationManaging Change and Complexity
Managing Change and Complexity The reality of software development Overview Some more Philosophy Reality, representations and descriptions Some more history Managing complexity Managing change Some more
More informationSoftware Development. Modular Design and Algorithm Analysis
Software Development Modular Design and Algorithm Analysis Functional Decomposition Functional Decomposition in computer science, also known as factoring, refers to the process by which a complex problem
More informationDefining Data Items Conrad Weisert (2003)
Defining Data Items Conrad Weisert (2003) Background -- one more missing component The failed-project documentation I described last month 2 lacked not only output specifications, but, worse, any data
More informationObject Oriented System Development
Object Oriented System Development Ratna Wardani Semester Genap, 2012 2/26/2012 Ratna W/PSBO2012 1 About This Course It shows how to apply OOAD technique to analyze and develop systems.. It gives you an
More informationCS2353 OBJECT ORIENTED ANALYSIS AND DESIGN UNIT- I
CS2353 OBJECT ORIENTED ANALYSIS AND DESIGN UNIT- I Introduction to OOAD What is OOAD? What is UML? What are the United process(up) phases - Case study the NextGen POS system, Inception -Use case Modeling
More informationCS487 Midterm Exam Summer 2005
1. (4 Points) How does software differ from the artifacts produced by other engineering disciplines? 2. (10 Points) The waterfall model is appropriate for projects with what Characteristics? Page 1 of
More informationSession 3b: Defining data items
Session 3b: Defining data items Sources of data items Establishing a project data dictionary Defining an elementary item Defining a composite data item COMP 320 / 420, Spring, 2018 Mr. Weisert Q: Which
More informationSoftware Engineering
Software Engineering A systematic approach to the analysis, design, implementation and maintenance of software. Software Development Method by Jan Pettersen Nytun, page 1 Software Engineering Methods Most
More informationSystems Analysis & Design
Systems Analysis & Design Dr. Ahmed Lawgali Ahmed.lawgali@uob.edu.ly Slide 1 Systems Analysis & Design Course Textbook: Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition
More informationSoftware Service Engineering
Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language
More informationLecture 34 SDLC Phases and UML Diagrams
That Object-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur Lecture 34 SDLC Phases and UML Diagrams Welcome
More informationRequirements and Design Overview
Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationLecture 2: Software Engineering (a review)
Lecture 2: Software Engineering (a review) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Credit where Credit is Due Some material presented in this lecture is
More informationWays of documenting Session 5: detailed requirements The Data Dictionary one any The Project A data dictionary Data Dictionary may be maintained
Session 5: The Data Dictionary relationship to systems analysis methodologies relationship to project management data definition vs. data representation taxonomy of data types COMP 477 /377, Spring, 2017
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical
More informationStructured Analysis and Structured Design
Structured Analysis and Structured Design - Introduction to SASD - Structured Analysis - Structured Design Ver. 1.5 Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr http://dslab.konkuk.ac.kr References Modern
More informationAns 1-j)True, these diagrams show a set of classes, interfaces and collaborations and their relationships.
Q 1) Attempt all the following questions: (a) Define the term cohesion in the context of object oriented design of systems? (b) Do you need to develop all the views of the system? Justify your answer?
More informationChapter 1: Programming Principles
Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key
More informationSRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A
SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A 1. What is an object? An object is a combination of data and logic; the representation of some realworld
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationObject-Oriented Systems Development: Using the Unified Modeling Language
Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 4: Object-Oriented Methodologies Goals Object-Oriented Methodologies The Rumbaugh et al. OMT The Booch methodology Jacobson's
More informationWays of documenting Session 5: detailed requirements The Data Dictionary one any The Project A data dictionary Data Dictionary may be maintained
Session 5: The Data Dictionary relationship to systems analysis methodologies relationship to project management data definition vs. data representation taxonomy of data types COMP 477 /377, Fall, 2018
More informationSoftware Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationCHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview
CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1:
More informationSession 4b: Review of Program Quality
Session 4b: Review of Program Quality What makes one program "better" than another? COMP 170 -- Fall, 2013 Mr. Weisert What is a good program? Suppose we give the same assignment to two programmers (or
More informationSoftware Process. Software Process
Software Process What is SW process? Definition, Development, Support phases Process models: Waterfall Prototyping Spiral, Incremental & iterative (best practices) UP process model What is it? How does
More informationUNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach?
Department: Information Technology Questions Bank Class: B.E. (I.T) Prof. Bhujbal Dnyaneshwar K. Subject: Object Oriented Modeling & Design dnyanesh.bhujbal11@gmail.com ------------------------------------------------------------------------------------------------------------
More information*ANSWERS * **********************************
CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO
More informationSOFTWARE ENGINEERING. Lecture 6. By: Latifa ALrashed. Networks and Communication Department
1 SOFTWARE ENGINEERING Networks and Communication Department Lecture 6 By: Latifa ALrashed Outline q q q q q q q q Define the concept of the software life cycle in software engineering. Identify the system
More informationThe Web Service Sample
The Web Service Sample Catapulse Pacitic Bank The Rational Unified Process is a roadmap for engineering a piece of software. It is flexible and scalable enough to be applied to projects of varying sizes.
More informationSOFTWARE DESIGN COSC 4353 / Dr. Raj Singh
SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a
More informationVO Software Engineering
Administrative Issues Univ.Prof. Dr. Peter Auer Chair for Information Technology Email: auer@unileoben.ac.at Lecture Thursday 10:15 11:45 Project Lab Montag 16:00 19:00 Literature Helmut Balzert, Lehrbuch
More informationReducing the costs of rework. Coping with change. Software prototyping. Ways to Cope with change. Benefits of prototyping
Coping with change Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations
More informationThe Analysis and Design of the Object-oriented System Li Xin 1, a
International Conference on Materials Engineering and Information Technology Applications (MEITA 2015) The Analysis and Design of the Object-oriented System Li Xin 1, a 1 Shijiazhuang Vocational Technology
More informationSoftware Design and Implementation. Example Architecture KIWC
Software Design and Implementation Example Architecture KIWC Previously on SDI What is design? What is traceability? What is architecture? Why architectures are important? Architectural styles KWIC The
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationUML- a Brief Look UML and the Process
UML- a Brief Look UML grew out of great variety of ways Design and develop object-oriented models and designs By mid 1990s Number of credible approaches reduced to three Work further developed and refined
More informationINTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2
INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:
More informationVragen. Intra-modular complexity measures. The uses relation. System structure: inter-module complexity
Vragen Intra-modular complexity measures Wat wordt bedoeld met het ontwerpsprincipe: Anticipate obsolence? Wat is het voordeel van strong cohesion en weak coupling? Wat is het gevolg van hoge complexiteit
More informationUML big picture. Perdita Stevens. School of Informatics University of Edinburgh
UML big picture Perdita Stevens School of Informatics University of Edinburgh Plan Whence UML? Parts of UML How it all fits together UML as a language Consistency: what does it mean, do we need it? Defining
More informationOutline of UML and Unified Process. Object Oriented Analysis/Design/Programming UML1.5. Koichiro Ochimizu, JAIST. UML&UP outline 1.
Outline of UML and Unified Process Koichiro OCHIMIZU School of Information Science JAIST Schedule Feb. 27th 13:00 Scope and Goal 14:30 Basic Concepts on Representing the World (object, class, association,
More informationOutline of Unified Process
Outline of Unified Process Koichiro OCHIMIZU School of Information Science JAIST Schedule(3/3) March 12 13:00 Unified Process and COMET 14:30 Case Study of Elevator Control System (problem definition,
More informationObject-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur
Object-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur Lecture 06 Object-Oriented Analysis and Design Welcome
More informationBuilding the User Interface: The Case for Continuous Development in an Iterative Project Environment
Copyright Rational Software 2002 http://www.therationaledge.com/content/dec_02/m_uiiterativeenvironment_jc.jsp Building the User Interface: The Case for Continuous Development in an Iterative Project Environment
More informationSystem Analysis and Design
System Analysis and Design 1 Introduction to Software Engineering Building Software is a complex exercise. Software is produced in several stages. Each stage attempts to deal with a different aspect of
More informationBDSA Introduction to OOAD. Jakob E. Bardram
BDSA Introduction to OOAD Jakob E. Bardram Programming is Fun Developing Quality Software is Hard. Craig Larman in [OOAD] book 2 Object-Oriented Analysis & Design (OOAD) This Lecture Unified Modeling Language
More informationChange Management Process on Database Level within RUP Framework
Change Management Process on Database Level within RUP Framework ZELJKA CAR*, PETRA SVOBODA**, CORNELIA KRUSLIN** *Department of Telecommunications Faculty of Electrical Engineering Computing, University
More informationUp and Running Software The Development Process
Up and Running Software The Development Process Success Determination, Adaptative Processes, and a Baseline Approach About This Document: Thank you for requesting more information about Up and Running
More informationUML 2.0 State Machines
UML 2.0 State Machines Frederic.Mallet@unice.fr Université Nice Sophia Antipolis M1 Formalisms for the functional and temporal analysis With R. de Simone Objectives UML, OMG and MDA Main diagrams in UML
More informationFrom Craft to Science: Rules for Software Design -- Part II
From Craft to Science: Rules for Software Design -- Part II by Koni Buhrer Software Engineering Specialist Rational Software Developing large software systems is notoriously difficult and unpredictable.
More informationExamples. Object Orientated Analysis and Design. Benjamin Kenwright
Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision
More informationMethods for requirements engineering
Methods for requirements engineering Objectives To explain the role of methods and techniques in requirements engineering To introduce data-flow modelling To introduce semantic data modelling To introduce
More informationDEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A (UML Notations has to be used wherever necessary)
More informationIntroduction to Software Engineering
Chapter 1 Introduction to Software Engineering Content 1. Introduction 2. Components 3. Layered Technologies 4. Generic View of Software Engineering 4. Generic View of Software Engineering 5. Study of
More informationI am Stephen LeTourneau from Sandia National Laboratories Sandia s National Security Missions include: Nuclear Weapons Defense Systems & Assessments
I am Stephen LeTourneau from Sandia National Laboratories Sandia s National Security Missions include: Nuclear Weapons Defense Systems & Assessments Energy, Climate & Infrastructure Security International,
More informationNow on Now: How ServiceNow has transformed its own GRC processes
Now on Now: How ServiceNow has transformed its own GRC processes Increasing scalability, lowering risk, and slashing costs by $30,000 START 1 Introduction When your business is growing at 0% a year, it
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review 1 Responsibility-Driven Design (RDD) Introduced in 1990; a UML-based
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 5: Modelling with Classes
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes 5.1 What is UML? The Unified Modelling Language is a standard graphical language
More informationThe Need for Agile Project Management
The Need for Agile Project Management by Mike Cohn 21 Comments originally published in Agile Times Newsletter on 2003-01-01 One of the common misperceptions about agile processes is that there is no need
More informationPlan. Modelling and design. What is a model? Note on spelling
Plan Modelling and design Perdita Stevens School of Informatics University of Edinburgh What is meant by modelling in software design, and in SE more generally? Why is modelling important? History of modelling
More informationA PROPOSAL FOR MODELING THE CONTROL SYSTEM FOR THE SPANISH LIGHT SOURCE IN UML
A PROPOSAL FOR MODELING THE CONTROL SYSTEM FOR THE SPANISH LIGHT SOURCE IN UML D. Beltran*, LLS, Barcelona, Spain M. Gonzalez, CERN, Geneva, Switzerlan Abstract CELLS (Consorcio para la construcción, equipamiento
More informationSystem Development Life Cycle Methods/Approaches/Models
Week 11 System Development Life Cycle Methods/Approaches/Models Approaches to System Development System Development Life Cycle Methods/Approaches/Models Waterfall Model Prototype Model Spiral Model Extreme
More informationENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL
INTERNATIONAL DESIGN CONFERENCE - DESIGN 2000 Dubrovnik, May 23-26, 2000. ENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL N. Pavković, D. Marjanović Keywords: object oriented methodology, design process
More informationOO Requirements to OO design. Csaba Veres Alan M. Davis (1995), Colorado
OO Requirements to OO design Csaba Veres Alan M. Davis (1995), Colorado Alan Davis? Guru? Academic and professional www.omni-vista.com? Controversial article on research into requirements engineering Requirements
More informationEarly programming languages ca. 1960
Session 5: Intro. to Java collections History Collection / container concept Shortcoming of original version Parameterized collections Example: ArrayList Comp 271, Spring, 2012 Mr. Weisert Early programming
More informationA Tutorial on Agent Based Software Engineering
A tutorial report for SENG 609.22 Agent Based Software Engineering Course Instructor: Dr. Behrouz H. Far A Tutorial on Agent Based Software Engineering Qun Zhou December, 2002 Abstract Agent oriented software
More information1 Introduction. 1.1 Introduction
1 Introduction 1.1 Introduction This book introduces and guides you through the use of the Unified Modeling Language (UML) and the Unified Process (both originally devised by Grady Booch, James Rumbaugh
More informationOrganizing Database Project Work. (Chapter 4)
Organizing Database Project Work (Chapter 4) 1 Learn the rules like a pro, so you can break them like an artist Pablo Picasso 2 Database Life Cycle The life cycle starts when the need is identified and
More informationOrganizing Database Project Work
Organizing Database Project Work (Chapter 4) 1 Learn the rules like a pro, so you can break them like an artist Pablo Picasso 2 Database Life Cycle The life cycle starts when the need is identified and
More informationA STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN
A STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN GARJE RAKESH RAMESHRAO RESEARCH SCHOLAR, DEPT. OF COMPUTER SCIENCE CMJ UNIVERSITY, SHILLONG, MEGHALAYA INTRODUCTION Object-oriented Analysis and Design is
More information02291: System Integration
02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring 2012 Contents 1 General Information 1 2 Overview 3 3 Introduction to UML 11 4 Summary 16 1 General Information System Integration Type
More informationUnified Modeling Language (UML)
Unified Modeling Language (UML) Troy Mockenhaupt Chi-Hang ( Alex) Lin Pejman ( PJ ) Yedidsion Overview Definition History Behavior Diagrams Interaction Diagrams Structural Diagrams Tools Effect on Software
More informationCHAPTER 9 DESIGN ENGINEERING. Overview
CHAPTER 9 DESIGN ENGINEERING Overview A software design is a meaningful engineering representation of some software product that is to be built. Designers must strive to acquire a repertoire of alternative
More informationSchedule(3/3) March 18th 13:00 Unified Process and Usecase-Driven Approach. (problem definition, use case model)
Schedule(3/3) March 18th 13:00 Unified Process and Usecase-Driven Approach 14:30 Case Study of Elevator Control System (problem definition, use case model) March 19th 13:00 Case Study of Elevator Control
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationLecture c, Process Mapping: Yourdon Notation for Data Flow Diagrams, covers Yourdon notation for data flow diagrams.
WORKFLOW ANALYSIS Audio Transcript Component 10 Unit 3 Lecture C Fundamentals of Health Workflow Process Analysis & Redesign Interpreting and Creating Process Diagrams Process Mapping Yourdon Notation
More informationThis tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.
i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give
More informationCS 575: Software Design
CS 575: Software Design Introduction 1 Software Design A software design is a precise description of a system, using a variety of different perspectives Structural Behavioral Packaging Requirements, Test/Validation
More informationRUP for Systems Z and other Legacy Systems
IBM Software Group RUP for Systems Z and other Legacy Systems Susan M Burk Senior Managing Consultant IBM smburk@us.ibm.com 413-726-9361 2006 IBM Corporation Agenda Objectives A Quick Introduction to RUP
More informationWelcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas
Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas What is this class about? While this class is called Design Patterns, there are many other items of critical
More informationMeDUSA Method for Designing UML2-based Embedded System Software Architectures
MeDUSA Method for Designing UML2-based Embedded System Software Architectures Alexander Nyßen 1, Horst Lichter 1, Jan Suchotzki 2, Lukas Kurmann 3 1 Introduction MeDUSA (Method for Designing UML2-based
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review (Part 1) 1 Coad-Yourdon Two-phase introduction: Object-Oriented Analysis
More information1 OBJECT-ORIENTED ANALYSIS
UML and Patterns.book Page 3 Sunday, August 9, 200 2:50 PM Chapter OBJECT-ORIENTED ANALYSIS AND DESIGN The shift of focus (to patterns) will have a profound and enduring effect on the way we write programs.
More informationSOFTWARE LIFE-CYCLE MODELS 2.1
SOFTWARE LIFE-CYCLE MODELS 2.1 Outline Software development in theory and practice Software life-cycle models Comparison of life-cycle models 2.2 Software Development in Theory Ideally, software is developed
More informationRequirements Analysis
Requirements Analysis Software Requirements A software (product) requirement is is a feature, function, capability, or property that a software product must have. Software Design A software design is is
More informationGetting a Quick Start with RUP
Getting a Quick Start with RUP By: Doug Rosenberg and Jeff Kantor, ICONIX Software Engineering, Inc. Abstract Many people want the rigor of an industrial-strength process like the RUP but aren't quite
More informationDESIGN AS RISK MINIMIZATION
THOMAS LATOZA SWE 621 FALL 2018 DESIGN AS RISK MINIMIZATION IN CLASS EXERCISE As you come in and take a seat What were the most important risks you faced in a recent software project? WHAT IS A RISK? WHAT
More informationChapter : Analysis Modeling
Chapter : Analysis Modeling Requirements Analysis Requirements analysis Specifies software s operational characteristics Indicates software's interface with other system elements Establishes constraints
More informationObjectives. Connecting with Computer Science 2
Objectives Learn how software engineering is used to create applications Learn some of the different software engineering process models Understand what a design document is and how it should be used during
More informationdefined. defined. defined. defined. defined. defined. defined. defined. defined.
Table of Contents Week 1 Software Development... 2 Software Eng Life-Cycle Development Phases... 2 Methodologies... 2 Week 2 - XP, Scrum, Agile... 3 Extreme Programming (XP)... 3 Values of XP Programming...
More informationSoftware Engineering with Objects and Components Open Issues and Course Summary
Software Engineering with Objects and Components Open Issues and Course Summary Massimo Felici Software Engineering with Objects and Components Software development process Lifecycle models and main stages
More informationOO Analysis and Design with UML 2 and UP
OO Analysis and Design with UML 2 and UP Dr. Jim Arlow, Zuhlke Engineering Limited Clear View Training 2008 v2.5 1 UML principles Clear View Training 2008 v2.5 2 1.2 What is UML? Unified Modelling Language
More information