EXPLORATIVE UML MODELING Comparing the Usability of UML Tools

Total Page:16

File Type:pdf, Size:1020Kb

EXPLORATIVE UML MODELING Comparing the Usability of UML Tools EXPLORATIVE UML MODELING Comparing the Usability of UML Tools Martin Auer, Ludwig Meyer and Stefan Biffl Institute of Software Technology and Interactive Systems, Vienna University of Technology, Favoritenstr. 9-11, A-1040 Vienna, Austria Keywords: Usability measures, UML tools, user interface design, UML modeling. Abstract: UML tools are used in three main ways: (1) to exploratively sketch key system components during initial project stages; (2) to manage large software systems by keeping design and implementation synchronized; and (3) to extensively document a system after implementation. Professional tools cover (3) to some extent, and attempt to cover (2), but the vast number of languages, frame- works and deployment procedures makes those tasks all but impossible. By aiming at these two goals, tools must enforce formal UML language constructs more rigorously and thus become more complicated. They can become unsuitable for (1). This paper looks at explorative modeling with the leading UML tool Rational Rose and the open-source sketching tool UMLet. We define usability measures, assess both tools’ performance for common UML design tasks, and comment on the consequences for the application of UML tools. 1 INTRODUCTION of generating diagrams from existing code, and of propagating changes from one artifact to others. The The Unified Modeling Language (UML) (Booch models and diagrams must conform to formal crite- et al., 2005) has become the standard graphical no- ria; only in this way are the tools able to handle the tation in software engineering. Different diagram relations between diagrams and code. types support most phases and workflows of the soft- Finally, such round-trip engineering tools are also ware process, including requirement engineering, de- able to effortlessly generate UML documentation sign, implementation and deployment. UML is sup- from large existing code bases. This is an easy way ported by a variety of tools trying to deliver on the to provide clients with a seemingly vast amount of elusive promise of computer-aided software engineer- system documentation, which is often required by ing (Eichelberger, 2002). contract but seldom maintained consistently during a In practice, UML is applied in three main scenar- project’s lifetime. ios. First, UML is the notation of choice when cre- This paper looks at the first application scenario— ating early drafts of requirement specifications, and UML sketching—, and more precisely at tools sup- software or database designs. Use case diagrams and porting the sketching process. We argue that UML design sketches are often created from scratch and is applied differently in that scenario, and that tools modified over several iterations. The diagrams do not aimed at providing formal UML support and complex have to adhere to the strict UML standards; they are round-trip-engineering might be inadequate to cover used in an explorative way (Rumbaugh et al., 2004). it. We compare the commercial UML tool Ratio- Second, in large-scale software engineering en- nal Rose to the open-source tool UMLet (Auer et al., vironments, software design and implementation are 2003) and quantitatively assess the tools’ usability for kept in sync using sophisticated round-trip engineer- explorative sketching. Rational Rose was chosen be- ing tools (Medvidovic et al., 1999). These are capa- cause it is the leading UML modeling tool in large- ble of generating code stubs from design blueprints, scale industrial environments. UMLet, on the other 466 Auer M., Meyer L. and Biffl S. (2007). EXPLORATIVE UML MODELING - Comparing the Usability of UML Tools. In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 466-473 DOI: 10.5220/0002351804660473 Copyright c SciTePress EXPLORATIVE UML MODELING - Comparing the Usability of UML Tools hand, provides a low-complexity user interface and Artisan’s Real-Time Studio thus a baseline for our comparison. (http://www.artisansw.com), or Borland’s To- We assess the tools’ usability by measuring the gether (http://www.borland.com/together). These complexity of 16 common UML modeling patterns, tools provide round-trip-engineering capability, or use cases. Examples for such use cases are i.e., they can produce code stubs from diagrams, changing class attributes, modifying dependencies, or diagrams from existing source code, and ways to adding messages in a UML diagram. The applied us- keep them in sync when one artifact changes. Other ability measures rely on concepts outlined in (Raskin, tools, e.g., UMLet (http://www.umlet.com) or Violet 2000). (http://www.horstmann.com/violet/) focus on the fast The remaining paper is structured as follows: Sec- creation of UML sketches (Chen et al., 2003; Auer tion 2 provides links to related work. Section 3 gives a et al., 2003). An extensive overview of UML tool short introduction to Rational Rose and UMLet, high- features is available at http://www.jeckle.de. lighting their user interface principles and features. Section 4 discusses the three usage types of UML User interface design (Raskin, 2000; Tidwell, tools. Section 5 gives an overview on the method and 2005) is not a strictly quantitative engineering disci- use cases on which our evaluation is based. Section pline: it requires intuition of users’ habits and envi- 6 discusses the results. Section 7 concludes and gives ronments, common sense, an understanding of graph- an outlook on further research. ical representations and their effects, and attention to psychological processes during user tasks. An ubiquitous aspect of user interfaces—used widely in 2 RELATED WORK any windows-based operating system—are so-called modal dialogs. Such dialogs are windows that pop up to request a user input, while freezing input to UML (Booch et al., 2005) was originally developed the rest of the application. These disruptive dialog by Grady Booch, James Rumbaugh, and Ivar Jacob- windows are described by Quan et al. (Quan et al., son in 1994. The main reason was to standardize the 2003) as follows: “Dialog boxes that collect parame- many existing graphical notations like Booch, OMT, ters for commands often create ephemeral, unnatural or ERM, and to provide a unified way of describ- interruptions of a program’s normal execution flow.” ing different software artifacts (classes, components, Many developers, too, seem to become aware of this packages, etc.) arising in different software environ- intrusive effect; several well-known applications, like ments (object-oriented platforms, real-time systems, Microsoft’s suite of development tools or the Firefox state machines, etc.). Typical types of UML diagrams Web browser, for example, now rely on non-modal are use case, class, or activity diagrams (Fowler, windows or unobtrusive task bars to provide docu- 2003). UML has become a de-facto standard since ment search functionality. then. The Object Management Group (OMG), a non- profit industry consortium, is responsible for defin- For applications with a largely graphical user ing and maintaining the UML language specifica- interface, Moran et al. (Moran et al., 1997) imple- tion (The Object Man Group, 2006). As of early mented and refined an alternative user interaction 2006, the various parts of UML are being upgraded approach—a pen based gesture recognition. While to version 2.0. the gesture-based approach requires some initial UML has been applied in many different areas of learning effort, the authors report that users found it software engineering. Evans and Wellings (Evans and understandable and easy to use. Chen et al. (Chen Wellings, 1999) report on the application of UML in et al., 2003) apply a whiteboard approach to the real-time systems. Kohler et al. (Kohler et al., 2000) creation of UML diagrams in early project stages. use a subset of UML in describing a decentralized Auer et al. (Auer et al., 2003) describe a text-based production control system. Astesiano and Reggio ap- user interface to modify the graphical representation ply UML in the context of distributed systems; they of UML diagrams. Several other authors report rely on the language’s standardized extension features on possible user interface improvements for UML to adapt it to their specific domain. UML is also be- tools (Tenzer, 2004; Zhang and sho Chen, 2005; ing taught in many software engineering courses; for Lahtinen and Peltonen, 2003). an experience report please refer to (Dagdeviren et al., 2004). It is notoriously tricky to quantify how good a Many tools attempt to provide UML user interface is. Users with different background, support, e.g., IBM’s Rational Rose experience levels, and goals can’t possibly agree on (http://www.ibm.com/software/rational), a single “best” user interface. Yet several user inter- 467 ICEIS 2007 - International Conference on Enterprise Information Systems face guidelines attempt to provide formal criteria that Model Views and Round-Trip Engineering should at least minimize bad interface choices and provide some cross-platform standardization (Apple Rational Rose uses a formal model framework to store Computer Inc., 1992). all design elements and their relationships. This way, Other authors, most notably Raskin (Raskin, Rational Rose can create different views of the design 2000), attempt to provide metrics to measure the qual- and ease the transformation of one diagram type to ity or usability of user interfaces. Indeed, a whole another. As an example, if the user changes the name family of so-called GOMS methods (goals, operators, of an element in one diagram view, it changes consis- methods, selection rules) try to measure usability. For tently in all other diagrams. example, KLM-GOMS relies on 6 primitive opera- Rational Rose allows one to create a model from tions (pressing a key, moving the mouse pointer, drag- scratch or to start from a set of predefined models. ging the mouse pointer, mental preparation, moving Users can select from model templates like Java, VC- hands, and waiting for command execution), and em- MFC, VB, etc.
Recommended publications
  • 07 Requirements What About RFP/RFB/Rfis?
    CMPSCI520/620 07 Requirements & UML Intro 07 Requirements SW Requirements Specification • Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,”
    [Show full text]
  • Using the UML for Architectural Description?
    Using the UML for Architectural Description? Rich Hilliard Integrated Systems and Internet Solutions, Inc. Concord, MA USA [email protected] Abstract. There is much interest in using the Unified Modeling Lan- guage (UML) for architectural description { those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural descrip- tion for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471. Keywords: IEEE P1471, architectural description, multiple views, view- points, Unified Modeling Language 1 Introduction The Unified Modeling Language (UML) is rapidly maturing into the de facto standard for modeling of software-intensive systems. Standardized by the Object Management Group (OMG) in November 1997, it is being adopted by many organizations, and being supported by numerous tool vendors. At present, there is much interest in using the UML for architectural descrip- tion: the techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. Such techniques enable architects to record what they are doing, modify or ma- nipulate candidate architectures, reuse portions of existing architectures, and communicate architectural information to others. These descriptions may the be used to analyze and reason about the architecture { possibly with automated support.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • PART 3: UML Dynamic Modelling Notations • State Machines/Statecharts • Collaboration Diagrams • Sequence Diagrams • Activity Diagrams
    PART 3: UML Dynamic Modelling Notations • State machines/statecharts • Collaboration diagrams • Sequence diagrams • Activity diagrams. Chapter 19 of the textbook is relevant to this part. 1 State machines • State machines describe dynamic behaviour of objects, show life history of objects over time + object communications. • Used for real-time system design (eg., robotics); GUI design (states represent UI screens/modes). Example shows simple state machine with two states, On and Off and transitions between them. 2 Switch Off swon swoff On Simple state machine 3 State machines Elements of a state machine are: States: Rounded-corner boxes, containing state name. Transitions: Arrows from one state, source of transition, to another, target, labelled with event that causes transition. Default initial state: State of object at start of its life history. Shown as target of transition from initial pseudostate (black filled circle). Termination of state machine can be shown by `bullseye' symbol. 4 State machines UML divides state machines into two kinds: 1. Protocol state machines { describe allowed life histories of objects of a class. Events on transitions are operations of that class, transitions may have pre and post conditions. Transitions cannot have generated actions (although we will allow this). 2. Behaviour state machines { describe operation execution/implementation of object behaviour. Transitions do not have postconditions, but can have actions. State machines describe behaviour of objects of a particular class, or execution processing of an operation. 5 State machines • Class diagrams describe system data, independently of time. • State machines show how system/objects can change over time. • Switch state machine is protocol state machine for objects of Switch class.
    [Show full text]
  • UML : Introduction
    UML : introduction Achref El Mouelhi Docteur de l’universite´ d’Aix-Marseille Chercheur en programmation par contrainte (IA) Ingenieur´ en genie´ logiciel [email protected] H & H: Research and Training 1 / 16 UML : introduction Achref El Mouelhi Docteur de l’universite´ d’Aix-Marseille Chercheur en programmation par contrainte (IA) Ingenieur´ en genie´ logiciel [email protected] H & H: Research and Training 2 / 16 UML © Achref EL MOUELHI © Pour construire cette maison Il faut etablir´ un plan avant H & H: Research and Training 3 / 16 UML La realisation´ d’une application peut passer par plusieurs etapes´ Definition´ des besoins Analyse Conception Developpement´ Test Validation© Achref EL MOUELHI © Deploiement´ Maintenance ... H & H: Research and Training 4 / 16 UML Ou` est UML dans tout c¸a ? UML permet de modeliser´ toutes les etapes´ du developpement´ d’une application de l’analyse au deploiement´ (en utilisant plusieurs diagrammes). © Achref EL MOUELHI © H & H: Research and Training 5 / 16 UML UML : Unified Modeling Language Un langage de modelisation´ unifie´ Ce n’est pas un langage de programmation Independant´ de tout langage de programmation (objet ou autre) Un langage base´ sur des notations graphiques Constitues´ de plusieurs graphes (diagrammes) permettant de visualiser© la Achref future application EL MOUELHI de plusieurs angles © differents´ Une norme maintenue par l’OMG (Object Management Group : organisation mondiale cre´ee´ en 1989 pour standardiser le modele` objet) H & H: Research and Training 6 / 16 Exemple
    [Show full text]
  • UML Tutorial: Part 1 -- Class Diagrams
    UML Tutorial: Part 1 -- Class Diagrams. Robert C. Martin My next several columns will be a running tutorial of UML. The 1.0 version of UML was released on the 13th of January, 1997. The 1.1 release should be out before the end of the year. This col- umn will track the progress of UML and present the issues that the three amigos (Grady Booch, Jim Rumbaugh, and Ivar Jacobson) are dealing with. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and nota- tions presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta- model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site2.
    [Show full text]
  • UML Tutorial: Sequence Diagrams
    UML Tutorial: Sequence Diagrams. Robert C. Martin Engineering Notebook Column April, 98 In my last column, I described UML Collaboration diagrams. Collaboration diagrams allow the designer to specify the sequence of messages sent between objects in a collaboration. The style of the diagram emphasizes the relationships between the objects as opposed to the sequence of the messages. In this column we will be discussing UML Sequence diagrams. Sequence diagrams contain the same information as Collaboration diagrams, but emphasize the sequence of the messages instead of the relationships between the objects. The Cellular Phone Revisited Here again is the final collaboration diagram from last column’s Cellular Phone example. (See Figure 1.) 1*:ButtonPressed() :DigitButton Digit:Button 1.1:Digit(code) Adapter 2:ButtonPressed() :SendButton Send:Button :Dialler Adapter 2.1:Send() 1.1.2:EmitTone(code) 2.1.1:Connect(pno) 1.1.1:DisplayDigit(code) 2.1.1.1:InUse() :Cellular display display:Dialler :Speaker Radio :CRDisplay Display Figure 1: Collaboration diagram of Cellular Phone. The Sequence diagram that corresponds to this model is shown in Figure 2. It is pretty easy to see what the diagrams in Figure 2 are telling us, especially when we compare them to Figure 1. Let’s walk through the features. First of all, there are two sequence diagrams present. The first one captures the course of events that takes place when a digit button is pressed. The second captures what happens when the user pushes the ‘send’ button in order to make a call. At the top of each diagram we see the rectangles that represent objects.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language
    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
    [Show full text]
  • A Study on Process Description Method for DFM Using Ontology
    Invited Paper A Study on Process Description Method for DFM Using Ontology K. Hiekata1 and H. Yamato2 1Department of Systems Innovation, Graduate School of Engineering, The University of Tokyo, 5-1-5, Kashiwanoha, Kashiwa-city, Chiba 277-8563, Japan 2Department of Human and Engineered Environmental Studies, Graduate School of Frontier Sciences, The University of Tokyo, 5-1-5, Kashiwanoha, Kashiwa-city, Chiba 277-8563, Japan [email protected], [email protected] Abstract A method to describe process and knowledge based on RDF which is an ontology description language and IDEF0 which is a formal process description format is proposed. Once knowledge of experienced engineers is embedded into the system the knowledge will be lost in the future. A production process is described in a proposed format similar to BOM and the process can be retrieved as a flow diagram to make the engineers to understand the product and process. Proposed method is applied to a simple production process of common sub-assembly of ships for evaluation. Keywords: Production process, DFM, Ontology, Computer system 1 INTRODUCTION (Unified Resource Identifier) is assigned to all the objects, There are many research and computer program for and metadata is defined for all objects using the URI. supporting optimization of production process in Metadata is defined as a statement with subject, shipyards. And knowledge of experienced engineers is predicate and object. The statement is called triple in embedded into the system. Once the knowledge is RDF. Two kinds of elements, Literal or Resource, can be embedded into computer system, the knowledge is not a component of a statement.
    [Show full text]
  • Extreme Programming and Rational Unified Process – Contrasts Or Synonyms?
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Research Papers in Economics EXTREME PROGRAMMING AND RATIONAL UNIFIED PROCESS – CONTRASTS OR SYNONYMS? Ionel IACOB, PhD Faculty of Computer Science for Business Management, Romanian – American University, Bucharest, Romania ABSTRACT The agile movement has received much attention in software engineering recently. Established methodologies try to surf on the wave and present their methodologies a being agile, among those Rational Unified Process (RUP). In order to evaluate the statements we evaluate the RUP against eXtreme Programming (XP) to find out to what extent they are similar end where they are different. We use a qualitative approach, utilizing a framework for comparison. RUP is a top-down solution and XP is a bottom-up approach. Which of the two is really best in different situations has to be investigated in new empirical studies. 1. INTRODUCTION The agile movement has appeared the last years as an alternative direction for software engineering [1]. Among the agile methodologies, eXtreme Programming (XP) is the most well known [2]. In the current agile boom, many established software engineering methodologies try to present themselves as being agile. The Rational Unified Processes (RUP) [16] is among those, providing “plugins” to RUP for eXtreme Programming1. Thereby they offer a downsized version of RUP, which is stated to be lightweight, agile style. Both methodologies share some common characteristics; they are iterative, customer-oriented and role- based. RUP is generally not considered agile; rather it is criticized for being too extensive and heavyweight [21]. RUP comprises 80 artifacts while XP only stresses the code.
    [Show full text]
  • Course Structure & Syllabus of B.Tech Programme In
    Course Structure & Syllabus of B.Tech Programme in Information Technology (From the Session 2015-16) VSSUT, BURLA COURSE STRUCTURE FIRST YEAR (COMMON TO ALL BRANCHES) FIRST SEMESTER SECOND SEMESTER Contact Contact Theory Hrs. Theory Hrs. CR CR Course Course Subject L .T .P Subject L. T. P Code Code Mathematics-I 3 - 1 - 0 4 Mathematics-II 3 - 1 - 0 4 Physics/Chemistry 3 - 1 - 0 4 Chemistry/ Physics 3 - 1 - 0 4 Engineering Computer /CS15- CS15- Mechanics/Computer 3 - 1 - 0 4 Programming/Engineering 3 - 1 - 0 4 008 008/ Programming Mechanics Basic Electrical Engineering/ Basic Electronics/Basic 3 - 1 - 0 4 3 - 1 - 0 4 Basic Electronics Electrical Engineering English/Environmental Environmental 3 - 1 - 0 4 3 - 1 - 0 4 Studies Studies/English Sessionals Sessionals Physics Laboratory/ Chemistry Lab/ Physics 0 - 0 - 3 2 0 - 0 - 3 2 Chemistry Lab Laboratory Workshop-I/Engineering Engineering Drawing/ 0 - 0 - 3 2 0 - 0 - 3 2 Drawing Workshop-I Basic Electrical Engineering Basic Electronics Lab/Basic 0 - 0 - 3 2 0 - 0 - 3 2 Lab/Basic Electronics Lab Electrical Engineering Lab Business Communication Programming Lab/ /CS15- CS15- and Presentation Skill/ 0 - 0 - 3 2 Business Communication 0 - 0 - 3 2 984 984/ Programming Lab and Presentation Skill Total 15-5-15 28 Total 15-5-15 28 SECOND YEAR THIRD SEMESTER FOURTH SEMESTER Contact Contact Theory Hrs. Theory Hrs. CR CR Course Subject L .T .P Course Code Subject L. T. P Code Mathematics-III Computer Organization 3 - 1 - 0 4 CS15-007 and Architecture 3 - 1 - 0 4 Digital Systems 3 - 1 - 0 4 CS15-032 Theory
    [Show full text]