DOCSLIB.ORG

36716885.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Calhoun: The NPS Institutional Archive Theses and Dissertations Thesis Collection 1992-12 Information engineering and the Information Engineering Facility verus rapid application development and FOCUS Clark, Lucille Charlotte Monterey, California. Naval Postgraduate School http://hdl.handle.net/10945/23703 piPT.ASSTFTFn T25/791 IURITY CLASSIFICATION OF THIS PAGE REPORT DOCUMENTATION PAGE REPORT SECURITY CLASSIFICATION lb RESTRICTIVE MARKINGS UNCLASSIFIED SECURITY CLASSIFICATION AUTHORITY 3. DISTRIBUTION /AVAILABILITY OF REPORT Approved for public release; distribution DECLASSIFICATION / DOWNGRADING SCHEDULE is unlimited. PERFORMING ORGANIZATION REPORT NUMBER(S) 5. MONITORING ORGANIZATION REPORT NUMBER(S) OFFICE SYMBOL 7a. OF MONITORING . NAME OF PERFORMING ORGANIZATION 6b. NAME ORGANIZATION (If applicable) Naval Postgraduate School 53 Naval Postgraduate School ADDRESS {City, State, and ZIP Code) 7b. ADDRESS (City. State, and ZIP Code) Monterey, CA 93943-5000 Monterey, CA 93943-5000 NAME OF FUNDING /SPONSORING 8b OFFICE SYMBOL 9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMftER ORGANIZATION (If applicable) ADDRESS (City. State, and ZIP Code) 10 SOURCE OF FUNDING NUMBERS PROGRAM PROJECT TASK WORK UNIT ELEMENT NO. NO. NO lACCESSION NO. I. TITLE (Include Security Classification) INFORMATION ENGINEERING AND THE INFORMATION ENGINEERING FACILITY VERSUS RAPID APPLICATION DFVFT.nPMF.NT AND FOCUS (UNCLASSIFIED) , I. PERSONAL AUTHOR(S) Clark. Lucille C, 3a. TYPE OF REPORT 13b. TIME COVERED 14 DATE OF REPORT (Year. Month, Day) 15 PAGE COUNT 231 Master's thesis FROM TO December 1992 5. supplementary notation ^ views expressed in this thesis are those of the author and do not government reflect the official policy or position of the Department of Defense or the U.S. COSATI CODES 18 SUBJECT TERMS (Continue on reverse if necessary and identify by block number) e FIELD GROUP SUB-GROUP E §S Engineering SSffBffiiiMWSiffiSI , I§F? !nfg§ma?f ' Facility, FOCUS, Rapid Application Development, Methodology 9. ABSTRACT (Continue on reverse if necessary and identify by block number) School (NPS) The Management Information Systems Department of the Naval Postgraduate Texas Instrument's is considering using the information engineering methodology with computer-aided software engineering Information Engineering Facility (IEF) , an integrated information toolset, for application development. The costs and benefits of introducing engineering and IEF versus the rapid application development methodology and fourth generation language, FOCUS, were analyzed through a case study developed in both IEF and FOCUS. IEF offers a one model implementation, a standard computerized methodology, consistency checking, management tools for the application developer, and superior diagramming features and screen design whereas FOCUS offers rapid prototyping, numeric functions, a report facility, security within the data model, inherent database management facilities and excellent documentation. The benefits of IEF did not outweigh its respectively costs. RAD and FOCUS were determined to be the methodology and tool of choice for application development for the MIS department. 20 DISTRIBUTION /AVAILABILITY OF ABSTRACT 21. ABSTRACT SECURITY CLASSIFICATION UNCLASSIFIED/UNLIMITED UNCLASSIFIED jjj] SAME AS RPT DTIC USERS 22a NAME OF RESPONSIBLE INDIVIDUAL 22b. TELEPHONE (Include Area Code) *.2c OFFICE SYMBOL 05 Barry A. Frew (408) 646-2392 APR edition DDFORM 1473. 84 mar 83 may be used until exhausted SECURITY CLASSIFICATION OF THIS PAGE All other editions are obsolete U.S. OovtrnrrMnt Prlntlni O'flcti IHHei )». UNCLASSIFIED Approved for public release; distribution is unlimited. Information Engineering and the Information Engineering Facility verus Rapid Application Development and FOCUS by Lucille Charlotte Clark B.A., Princeton University, 1984 Submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE IN INFORMATION SYSTEMS from the NAVAL POSTGRADUATE SCHOOL December 1992 ABSTRACT The Management Information Systems Department of the Naval Postgraduate School (NPS) is considering using the information engineering methodology with Texas Instrument's Information Engineering Facility (IEF), an integrated computer-aided software engineering toolset, for application development. The costs and benefits of introducing information engineering and IEF versus the rapid application development methodology and fourth generation programming language, FOCUS, were analyzed through a case study developed in both IEF and FOCUS. IEF offers a one model implementation, a standard computerized methodology, consistency checking, management tools for the application developer, and superior diagramming features and screen design whereas FOCUS offers rapid prototyping, numeric functions, a report facility, security within the data model, inherent database management facilites and excellent documentation. The benefits of IEF did not outweigh its costs. RAD and FOCUS were determined to be the methodology and tool of choice respectively for application development for the MIS department. nt I a. TABLE OF CONTENTS I. INTRODUCTION 1 A. PROBLEM DESCRIPTION 1 B. RESEARCH QUESTIONS 1 C. INVESTIGATIVE METHODOLOGY 3 D. STRUCTURE OF THE THESIS 4 II. SOFTWARE DEVELOPMENT METHODOLOGIES AND THE LIFE CYCLE 6 A. DEFINITION AND CLASSIFICATIONS 6 B. METHODOLOGY CHARACTERISTICS AND EVALUATION QUESTIONS 9 C. THE SOFTWARE DEVELOPMENT ENVIRONMENT 11 D. THE SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) AND ITS CRITICS 14 E. PROTOTYPING 21 F. INFORMATION ENGINEERING 28 G. RAPID APPLICATION DEVELOPMENT (RAD) 49 H. A TAILORED AND UNIVERSAL METHODOLOGY 56 III. SOFTWARE DEVELOPMENT TOOLS 59 A. RELATIONSHIP OF A TOOL TO ITS METHOD 59 B. FOURTH GENERATION LANGUAGES 60 IV C. FOCUS 66 D. COMPUTER-AIDED SOFTWARE ENGINEERING (CASE) . 72 E. INFORMATION ENGINEERING FACILITY (IEF) .... 80 F. SUMMARY OF METHODOLOGIES AND TOOLS 88 IV. BACKGROUND INFORMATION FOR THE CASE STUDY .... 90 A. MANAGEMENT INFORMATION SYSTEMS' SOFTWARE DEVELOPMENT ENVIRONMENT 90 B. MINOR PROPERTY ACCOUNTABILITY SYSTEM REQUIREMENTS 98 V. EVALUATION 104 A. INTRODUCTION 104 B. INVESTIGATIVE METHODOLOGY 112 C. TOOL EVALUATION 115 1. Data Modeling 116 2. Activity Analysis 131 3. Action Diagramming or Programming 139 4. Dialogue Flow 155 5. Screen/Report Design 165 6. Documentation, Training, and Technical Support 174 D. METHODOLOGY AND TOOL SUPPORT FOR THE METHODOLOGY EVALUATION 176 E. CONCLUSION 187 APPENDIX A: DATA MODELLING 193 APPENDIX B: ACTIVITY ANALYSIS 198 APPENDIX C: PROGRAMMING 201 APPENDIX D: DIALOG FLOW 213 APPENDIX E: SCREEN DESIGN 216 APPENDIX F: IEF SUPPORT FOR INFORMATION ENGINEERING . 218 LIST OF REFERENCES 219 INITIAL DISTRIBUTION LIST 223 VI . I . INTRODUCTION A. PROBLEM DESCRIPTION The Dean of Computer and Information Systems at the Naval Postgraduate School (NPS) is considering using the information engineering methodology with Texas Instrument's (TI) Information Engineering Facility (IEF), an integrated computer-aided software engineering (CASE) toolset for application development. Currently, the programming staff uses a rapid application development (RAD) methodology and the fourth generation language FOCUS. The purpose of this thesis is to determine, through a representative case study, the costs and benefits of introducing information engineering (IE) and IEF versus using the current rapid application- development methodology and tool, FOCUS. The results will determine, in part, which methodology and tool will be used to develop future projects of the Management Information Systems (MIS) Department B. RESEARCH QUESTIONS This thesis does not attempt to devise a radical new approach to application development but rather evaluates how certain methodologies and tools can contribute to the MIS department. It presents an overview of the software development life cycle, the software development environment, and several software development methodologies; an overview of fourth generation languages and computer-aided software engineering (CASE); a specific overview of FOCUS and IEF and the software development environment of the MIS department; and an evaluation of the tools and their associated methodologies based on a case study. The case study consists of a bounded business area of a middle-sized enterprise. A business area is considered to be sufficiently bounded and constrained when (1) the accessed data (2) the processes including their timing and coordination (3) the business relationships with all their intricacies and (4) the business rules and policies affected by the processes and flows are all well known and clearly defined. (Haas, 1991) The business area for the case study is the Minor Property Accountability System and the medium-sized enterprise, the Naval Postgraduate School. The direct and indirect research questions to be answered are the following: 1 . Is it worth the cost and effort to introduce information engineering and CASE as the methodology and tool respectively for a bounded business area for a medium- sized enterprise that uses rapid application development and fourth generation languages? 2 . How does the information engineering methodology with IEF compare to rapid application development with FOCUS in terms of its costs and benefits? 3 . What is the learning curve associated with the Information Engineering Facility (IEF)? 4 . What are some of the effective techniques for evaluating methodologies, tools, and the software development environment? One should not generalize the results of this thesis
Recommended publications
  • Introduction Development Lifecycle Model

    Introduction Development Lifecycle Model

    DeveIopment of a Comprehensive Software Engineering Environment Thomas C. Hartrum Gary B. Lamont Department of Electrical and Computer Engineering Department of Electrical and Computer Engineering School of Engineering School of Engineering Air Force Institute of Technology Air Force Institute of Technology Wright-Patterson AFB, Dayton, Ohio, 45433 Wright-Patterson AFB, Dayton, Ohio, 45433 Abstract The concept of an integrated software development environment The generation of a set of tools for the software lifecycle is a recur- can be realized in two distinct levels. The first level deals with the ring theme in the software engineering literature. The development of access and usage mechanisms for the interactive tools, while the sec- such tools and their integration into a software development environ- ond level concerns the preservation of software development data and ment is a difficult task at best because of the magnitude (number of the relationships between the products of the different software life variables) and the complexity (combinatorics) of the software lifecycle cycle stages. The first level requires that all of the component tools process. An initial development of a global approach was initiated at be resident under one operating system and be accessible through a AFIT in 1982 as the Software Development Workbench (SDW). Also common user interface. The second level dictates the need to store de- other restricted environments have evolved emphasizing Ada and di5 velopment data (requirements specifications, designs, code, test plans tributed processing. Continuing efforts focus on tool development, and procedures, manuals, etc.) in an integrated data base that pre- tool integration, human interfacing (graphics; SADT, DFD, structure serves the relationships between the products of the different life cy- charts, ...), data dictionaries, and testing algorithms.
  • Software Engineering Process Development

    Software Engineering Process Development

    MACHINES, TECHNOLOGIES, MATERIALS. ISSN 1313-0226. ISSUE 11/2013 SOFTWARE ENGINEERING PROCESS DEVELOPMENT M.Sc. Ivanova Milka. Faculty of Mechanical Engineering – Technical University of Sofia, Bulgaria Abstract: A software engineering (SE) process is a set of activities that leads to the production of software product. These activities may involve the development of software from scratch in a standard program language. However new software is developed by extending and modifying existing systems and by configuring and integrating off-the-self software or systems components. In the report they have understand the concept of software engineering, software engineering process models and when these models might be used. Keywords: Software, software product, software engineering, software process, process models Many people equate the term software as a computer programs. But software engineering (CBSE) This technique assumes that parts of software is not just the programs also all associate documentation the system already exist. The system development process focuses and configuration data that is needed to make these programs on integrating these parts rather than developing them from scratch. operate correctly. A software system usually consist of a number of Some examples of the types of software process model that may separate programs, configuration files which are used to set up these be produced are: programs, system documentation witch describe the systems’ structure and user’s documentation which explains how to use the I. THE LINEAR SEQUENTIAL MODEL system and web sites for users to download recent information. Sometimes called the waterfall model, the linear sequential model Software that can be sold to the customer named a software suggests a systematic, sequential approach to software development product; There are fundamental types of software product: that begins at the system level and progresses through analysis, design, coding, testing, and support.
  • Chapter 1: Introduction

    Chapter 1: Introduction

    Just Enough Structured Analysis Chapter 1: Introduction “The beginnings and endings of all human undertakings are untidy, the building of a house, the writing of a novel, the demolition of a bridge, and, eminently, the finish of a voyage.” — John Galsworthy Over the River, 1933 www.yourdon.com ©2006 Ed Yourdon - rev. 051406 In this chapter, you will learn: 1. Why systems analysis is interesting; 2. Why systems analysis is more difficult than programming; and 3. Why it is important to be familiar with systems analysis. Chances are that you groaned when you first picked up this book, seeing how heavy and thick it was. The prospect of reading such a long, technical book is enough to make anyone gloomy; fortunately, just as long journeys take place one day at a time, and ultimately one step at a time, so long books get read one chapter at a time, and ultimately one sentence at a time. 1.1 Why is systems analysis interesting? Long books are often dull; fortunately, the subject matter of this book — systems analysis — is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations. As Tom DeMarco said in his delightful book, Structured Analysis and Systems Specification (DeMarco, 1978), [systems] analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.
  • Formalized Structured Analysis Specifications David L

    Formalized Structured Analysis Specifications David L

    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1991 Formalized structured analysis specifications David L. Coleman Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons, and the Mathematics Commons Recommended Citation Coleman, David L., "Formalized structured analysis specifications " (1991). Retrospective Theses and Dissertations. 9634. https://lib.dr.iastate.edu/rtd/9634 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. INFORMATION TO USERS This manuscript has been reproduced from the microfihn master. UMI fUms the text directly &om the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely afifect reproduction. In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand corner and continuing from left to right in equal sections with small overlaps.
  • Analysis of Methods TECHNICAL REPORT

    Analysis of Methods TECHNICAL REPORT

    Analysis of Methods Final Report Richard J. Mayer, ed. Knowledge Based Systems Laboratory Texas A&M University March 8, 1991 w -o _0 co ! m f_ U cD C 0 Z 0 Cooperative Agreement NCC 9-16 Research Activity No. IM.06: Methodologies for Integrated 0 Information Management Systems r CDOC NASA Johnson Space Center Information Systems Directorate Information Technology Division -J • 0 _D A _OE e._ ,t C I LL -C,-- ::2" I C" m E Research Institute for Computing and Information Systems v;I _0 University of Houston-C/ear Lake TECHNICAL REPORT The RICIS Concept The University of Houston-Clear Lake established the Research lnsUtute for Computing and Information Systems (RICIS) in 1986 to encourage the NASA Johnson Space Center (JSC) and local industry to actively support research in the computing and information sciences. As part of thls endeavor. UHCL proposed a partnership with JSC to Jointly define and manage an integrated program of research in advanced data processing technology needed for JSC's main missions, including administrative, engineering and science responsi- bilities. JSC agreed and entered into a continuing cooperative agreement with UHCL beginning in May 1986, to Jointly plan and execute such research through RICIS. Additionally, under Cooperative Agreement NCC 9-16, computing and educaUonal facilities are shared by the two instituUons to conduct the research. The UHCL/RICIS mission is to conduct, coordinate, and disseminate research and professional level edueaUon in computing and information systems to serve the needs of the government, industry, community and academia. RICIS combines resources ofUHCLand Itsgateway affiliatestoresearch and develop materials, prototypes and publications on topics of mutual interest to its sponsors and researchers.
  • Software Engineering Process Development

    Software Engineering Process Development

    SCIENTIFIC PROCEEDINGS X INTERNATIONAL CONGRESS "MACHINES, TECHNOLОGIES, MATERIALS" 2013 ISSN 1310-3946 SOFTWARE ENGINEERING PROCESS DEVELOPMENT M.Sc. Ivanova Milka. Faculty of Mechanical Engineering – Technical University of Sofia, Bulgaria Abstract: A software engineering (SE) process is a set of activities that leads to the production of software product. These activities may involve the development of software from scratch in a standard program language. However new software is developed by extending and modifying existing systems and by configuring and integrating off-the-self software or systems components. In the report they have understand the concept of software engineering, software engineering process models and when these models might be used. Keywords: Software, software product, software engineering, software process, process models Many people equate the term software as a computer programs. But software engineering (CBSE) This technique assumes that parts of software is not just the programs also all associate documentation the system already exist. The system development process focuses and configuration data that is needed to make these programs on integrating these parts rather than developing them from scratch. operate correctly. A software system usually consist of a number of Some examples of the types of software process model that may separate programs, configuration files which are used to set up these be produced are: programs, system documentation witch describe the systems’ structure and user’s documentation which explains how to use the I. THE LINEAR SEQUENTIAL MODEL system and web sites for users to download recent information. Sometimes called the waterfall model, the linear sequential model Software that can be sold to the customer named a software suggests a systematic, sequential approach to software development product; There are fundamental types of software product: that begins at the system level and progresses through analysis, design, coding, testing, and support.
  • Appendix A: a Practical Guide to Entity-Relationship Modeling

    Appendix A: a Practical Guide to Entity-Relationship Modeling

    Appendix A: A Practical Guide to Entity-Relationship Modeling A Practical Guide to Entity-Relationship Modeling Il-Yeol Song and Kristin Froehlich College of Information Science and Technology Drexel University Philadelphia, PA 19104 Abstract The Entity-Relationship (ER) model and its accompanying ER diagrams are widely used for database design and Systems Analysis. Many books and articles just provide a definition of each modeling component and give examples of pre-built ER diagrams. Beginners in data modeling have a great deal of difficulty learning how to approach a given problem, what questions to ask in order to build a model, what rules to use while constructing an ER diagram, and why one diagram is better than another. In this paper, therefore, we present step-by-step guidelines, a set of decision rules proven to be useful in building ER diagrams, and a case study problem with a preferred answer as well as a set of incorrect diagrams for the problem. The guidelines and decision rules have been successfully used in our beginning Database Management Systems course for the last eight years. The case study will provide readers with a detailed approach to the modeling process and a deeper understanding of data modeling. Introduction Entity relationship diagrams (ERD) are widely used in database design and systems analysis to represent systems or problem domains. The ERD was introduced by Chen (1976) in early 1976. Teorey, Yang, and Fry (1986) present an extended ER model for relational database design. The ERD models a given problem in terms of its essential elements and the interactions between those elements in a problem domain.
  • A Comparative Analysis of Entity-Relationship Diagrams1

    A Comparative Analysis of Entity-Relationship Diagrams1

    Journal of Computer and Software Engineering, Vol. 3, No.4 (1995), pp. 427-459 A Comparative Analysis of Entity-Relationship Diagrams1 Il-Yeol Song Drexel University Mary Evans USConnect E.K. Park U.S. Naval Academy The purpose of this article is to collect widely used entity-relationship diagram (ERD) notations and so their features can be easily compared, understood, and converted from one notation to another. We collected ten different ERD notations from text books and CASE tools. Each notation is depicted using a common problem and includes a discussion of each characteristic and notation. According to our investigation, we have found that ERD features and notations are different in seven features: whether they allow n-ary relationships, whether they allow attributes in a relationship, how they represent cardinality and participation constraints, the place where they specify constraints, whether they depict overlapping and disjoint subclass entity-types, whether they show total/partial specialization, and whether they model the foreign key at the ERD level. We conclude that many of the ER diagrams we studied are different in how they depict the criteria listed above. In order to convert one diagram to another, some notations must be extended and carefully converted from one notation into another. We also discuss the limitations of existing CASE tools in terms of modeling capabilities and supporting diagrams. Keywords: Entity-Relationship Diagrams, ERD, design, modeling, CASE 1Correspondence should be addressed to Il-Yeol Song, College of Information Science and Technology, Drexel University, 32nd and Chestnut Streets, Philadelphia, PA 19104. Email: [email protected] 1 Journal of Computer and Software Engineering, Vol.
  • The Use of Information Engineering As a Framework for Analyzing Records in Electronic Form

    The Use of Information Engineering As a Framework for Analyzing Records in Electronic Form

    THE USE OF INFORMATION ENGINEERING AS A FRAMEWORK FOR ANALYZING RECORDS IN ELECTRONIC FORM by Jayne Bellyk B. G. S., Simon Fraser University, 1981 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF ARCHIVAL STUDIES in THE FACULTY OF GRADUATE STUDIES School of Library, Archival and Information Studies We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA April 1995 ©Jayne Bellyk, 1995 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Departmsht of Li WfrT\j\, CA^cvlyj \/4c^4 \ S^/vv^A/\ ^±Ock\C < The University of British Columbia Vancouver, Canada •ate Afy\\ 3-5-, iqq.5 DE-6 (2788) ABSTRACT This thesis examines an approach and a methodology used by information technology professionals to develop information systems. Information engineering is a methodology for developing information systems following a specific process. It does not set out to create or manage records, yet it does have significance to archivists as a framework for analyzing information and records in electronic form. The framework that information engineering extends to archivists is one that links administrative goals and business functions to individual activities and acts.
  • Structured Analysis and Design

    Structured Analysis and Design

    Structured Analysis and Design Rajib Mall CSE Department IIT KHARAGPUR 1 Introduction • Structured analysis is a top-down decomposition technique: – DFD (Data Flow Diagram) is the modelling technique used – Functional requirements are modelled and decomposed. • Why model functionalities? – Functional requirements exploration and validation – Serves as the starting point for design. Function-oriented vs. Object-oriented Design • Two distinct style of design: – Function-oriented or Procedural • Top-down approach • Carried out using Structured analysis and structured design • Coded using languages such as C – Object-oriented • Bottom-up approach • Carried out using UML • Coded using languages such as Java, C++, C# Structured analysis and Structured Design • During Structured analysis: – High-level functions are successively decomposed: •Into more detailed functions. • During Structured design: – The detailed functions are mapped to a module structure. Structured Analysis • Successive decomposition of high-level functions: – Into more detailed functions. – Technically known as top-down decomposition. SA/SD (Structured Analysis/Structured Design) • SA/SD technique draws heavily from the following methodologies: – Constantine and Yourdon's methodology We largely use – Hatley and Pirbhai's methodology – Gane and Sarson's methodology – DeMarco and Yourdon's methodology • SA/SD technique results in: – high-level design. Functional Decomposition • Each function is analyzed: – Hierarchically decomposed into more detailed functions. – Simultaneous decomposition of high-level data •Into more detailed data. Structured Analysis • Textual problem description converted into a graphic model. – Done using data flow diagrams (DFDs). – DFD graphically represents the results of structured analysis. • The results of structured analysis can be easily understood even by ordinary customers: Structured – Does not require computer knowledge. Analysis – Directly represents customer’s perception of the problem.
  • Process Modeling Bibliography 3.1 Page 1 Provided by Tryon and Associates Brooks, Frederick P

    Process Modeling Bibliography 3.1 Page 1 Provided by Tryon and Associates Brooks, Frederick P

    Process Modeling Series BIBLIOGRAPHY "The man who does not read good books has no advantage over the man who can't read them." - Mark Twain This bibliography is provided as a reference for any outside materials that were used in the development of the Tryon and Associates Process Modeling seminars. This is a partial bibliography in that we provide only the authors name, title of the work and the original date of publication. A short description of the significance of the materials is included with most of the titles. Many of the books listed are also available on cassette tape. Where that specific medium is recommended, it will be indicated with a "CASS" notice. You will also find a private rating system indicating our opinion of the title. "AAA" indicates a must-read and a book that we feel belongs in every professional's library. "AA" tells you this is an important work that should be in a corporate library for frequent reference. "A" identifies a title that should be browsed as soon as possible and read when there is time. We do not list titles below an "A" but will be happy to provide bibliographical information on any other material referenced in our seminars. You may find some of these books in your local bookstore but most of them are easier to find on the Internet. You may want to find a good source for out of print books for some of these titles. Chuck Tryon Adams, Richard. WATERSHIP DOWN, 1972. (AA – Okay, let’s start this list with something FUN.
  • Data Model As an Architectural View

    Data Model As an Architectural View

    Data Model as an Architectural View Paulo Merson October 2009 TECHNICAL NOTE CMU/SEI-2009-TN-024 Research, Technology, and System Solutions Unlimited distribution subject to the copyright. This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2009 Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for inter- nal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. This document may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission.