DOCSLIB.ORG

Chapter 1: Introduction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
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. In a word, it is fascinating. Once you’re hooked, the old easy pleasures of system building are never again enough to satisfy you. This may come as a surprise to you if you have any experience writing computer programs. [1] Programming is enormous fun, and it’s enormously satisfying to see a program execute successfully, especially after spending several hours debugging it. It’s hard to imagine that things could be even more rewarding and exciting when you begin to move away from the computer and the writing of computer programs to study the overall system in which the programs play a part. But by the end of this book, I hope to have convinced you that the real challenge, and the real joy, of working with computer systems is that of carrying out systems analysis. No matter what profession you decide to pursue, it will be important for you to understand what systems analysis is all about. If you work in the computer industry as something other than an electrical engineer or hardware designer, there is a good chance that your career will progress from programmer to systems designer to systems analyst before you finally move on to the ranks of management. [2] www.yourdon.com ©2006 Ed Yourdon - rev. 051406 1.2 Whom this book is intended for This book is intended for two audiences: first, the person who is new to the field of systems analysis, and, second, the experienced systems analyst who needs to acquaint himself with systems modeling tools and techniques that have evolved over the past decade. Many readers will be university computer science students who have completed earlier courses on computer programming; some may be students in a business training program. However, the book should be equally readable by people who have finished their university training and who are now working in industry. Many people in the computer industry spend their first several years working as a computer programmer, and then suddenly find themselves promoted to a position of systems analyst, without ever being told what systems analysis is all about or what a systems analyst does. If you are in such a position, this book is for you. You should also find the book useful if you began working as a systems analyst in the 1970s or 1980s and never had an opportunity to learn about classical analysis methods such as structured analysis, or the newer methods such as object-oriented analysis. More and more often today, people outside the computer profession are finding it necessary to become familiar with the field of systems analysis. If you are a business person or a manager, there is a good chance that you will be involved in a systems analysis activity. You will have systems analysts working for you, spending their time trying to understand what kind of automated system you want them to build. Similarly, if you are an administrator, a clerk, a scientist, a politician, an engineer, or an accountant — or virtually any other professional in today’s society — there is a good chance that you will spend a significant amount of time during your career interacting with systems analysts who will be designing and specifying sophisticated computer systems for you. The more you know about what these people do, and what they expect of you, the better off you will be. Even if you have no expectation of working in a white collar job — that is, even if you expect to be an artist, a writer, a musician, or an athlete — you should know what systems analysis is all about. Citizens in every walk of life are affected by computer systems of all sorts. Even if you never intend to build a computer system or have one built for you, it is inevitable that you will be using computer systems for your banking, for your education, for your interactions with the IRS and Social Security, and for virtually every aspect of your interactions with modern society. As John Gall says in Systemantics (Gall, 1977), No one, these days, can avoid contact with systems. Systems are everywhere: big systems, little systems, systems mechanical and electronic, and those special systems that consist of organized associations of people. In self- defense, we must learn to live with systems, to control them lest they control us. As Humpty Dumpty said to Alice (though in another context): “The question is: which is to be master — that’s all.” To emphasize this point even more, keep in mind that the computer industry represented approximately 8% of the United States GNP in 1985; by 1990, it was expected to represent as much as 15% of the GNP. [3] Almost every product built today by American business has one or more computers embedded within it, and almost every service provided to the marketplace by American business is based on or controlled by a computer system. www.yourdon.com ©2006 Ed Yourdon - rev. 051406 1.3 What this book will do for you A major purpose of this book is to teach you about systems analysis: what it is and how one goes about doing it. But there is more: my real purpose is to excite you, to make you so eager to begin practicing systems analysis that you will want to rush through the last pages of the book and begin working on your first project. Seymour Papert recalls in Mindstorms (Papert, 1980), I found particular pleasure in such systems as the differential gear, which does not follow a simple linear chain of causality since the motion in the transmission shaft can be distributed in many different ways to the two wheels depending on what resistance they encounter. I remember quite vividly my excitement at discovering that a system could be lawful and completely comprehensible without being rigidly deterministic. And as Sir Arthur Stanley Eddington said in Space, Time and Gravitation: An Outline of the General Theory (Eddington, 1987), We have found that where science has progressed the farthest, the mind has but regained from nature that which the mind put into nature. We have found a strange footprint on the shores of the unknown. We have devised profound theories, one after another, to account for its origin. At last we have succeeded in reconstructing the creature that made the footprint. And lo! it is our own. Another purpose of the book is to make you understand and appreciate that we live in a world of systems — and systems within systems, which are part of even larger systems. Thus, everything we do in our personal and professional lives has an impact on the various systems of which we are a part. This “systems thinking” approach is not only vital for professional systems analysts, but for all members of modern society. Alas, this book cannot make you an experienced systems analyst, any more than a book on music theory can make you an experienced pianist. By the end of the book, you will be armed with a tremendous amount of technical information that will help you develop accurate models of complex systems, and you will know the step-by-step techniques for carrying out a systems analysis effort. But you will still need a great deal of real-world work to learn the people skills: how to interview a variety of disparate users to understand the true essence of a system; how to present the results of your systems analysis work so that everyone can see a credible estimate of the costs and benefits of developing a new system; and how to distinguish problems from symptoms. As Barry Boehm pointed out in his classic work, Software Engineering Economics (Boehm, 1981): Each of us as individual software engineers has an opportunity to make a significant positive impact on society, simply by becoming more sensitive to the long-range human relations implications of our work, and by incorporating this sensitivity into our software designs and products. www.yourdon.com ©2006 Ed Yourdon - rev. 051406 It takes some practice to do this well, and to learn how to balance human relations concerns with programming and quantitative economic concerns.
Load more

Recommended publications
  • 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.
    [Show full text]
  • Rugby - a Process Model for Continuous Software Engineering
    INSTITUT FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Forschungs- und Lehreinheit I Angewandte Softwaretechnik Rugby - A Process Model for Continuous Software Engineering Stephan Tobias Krusche Vollstandiger¨ Abdruck der von der Fakultat¨ fur¨ Informatik der Technischen Universitat¨ Munchen¨ zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Helmut Seidl Prufer¨ der Dissertation: 1. Univ.-Prof. Bernd Brugge,¨ Ph.D. 2. Prof. Dr. Jurgen¨ Borstler,¨ Blekinge Institute of Technology, Karlskrona, Schweden Die Dissertation wurde am 28.01.2016 bei der Technischen Universitat¨ Munchen¨ eingereicht und durch die Fakultat¨ fur¨ Informatik am 29.02.2016 angenommen. Abstract Software is developed in increasingly dynamic environments. Organizations need the capability to deal with uncertainty and to react to unexpected changes in require- ments and technologies. Agile methods already improve the flexibility towards changes and with the emergence of continuous delivery, regular feedback loops have become possible. The abilities to maintain high code quality through reviews, to regularly re- lease software, and to collect and prioritize user feedback, are necessary for con- tinuous software engineering. However, there exists no uniform process model that handles the increasing number of reviews, releases and feedback reports. In this dissertation, we describe Rugby, a process model for continuous software en- gineering that is based on a meta model, which treats development activities as parallel workflows and which allows tailoring, customization and extension. Rugby includes a change model and treats changes as events that activate workflows. It integrates re- view management, release management, and feedback management as workflows. As a consequence, Rugby handles the increasing number of reviews, releases and feedback and at the same time decreases their size and effort.
    [Show full text]
  • PMR 5020 Modelagem Do Projeto De Sistemas Aula 2: Sistemas E Seu Processo De Projeto Prof
    PMR 5020 Modelagem do Projeto de Sistemas Aula 2: Sistemas e seu processo de projeto Prof. José Reinaldo Silva [email protected] PMR5020 Escola Politécnica da USP 1 O Design Mecatrônico (Mechatronic Design) Sistema de informação Sistema Mecânico Artefato Mecatrônico Sistema de controle Sistema Eletrônico Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 2 O noso artefato alvo… Sistemas Não tem fronteiras óbvias Não tem um “corpo” material Geralmente acoplado Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 3 Um sistema é um conjunto de objetos distinguíveis – não necessariamente homogêneo – que trabalham em conjunto para atingir um objetivo coletivo. Eventualmente cada um dos elementos constituintes pode ser também um sistema menor do que o sistema que o contém. Assim a definição é recursiva e convergente. Existem uma (ou mais) categorias de elemento constituinte tal que não vale a pena imergir nos detalhes internos deste, isto é, a precisão dos detalhes não contribui em nada seja para o funcionamento do sistema, seja para entender a sua funcionalidade. Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 4 Teoria de sistemas Proposta em 1940 por Ludwig von Bartalanffy Em busca da unificação da ciência X reducionismo Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 5 Sistema: uma definição holônica Um sistema é definido pelo par ordenado S=(A, R) onde A é um conjunto de elementos constituintes (objetos) relevantes A e R o conjunto R de relações definidas entre estes objetos. Eventual- mente um elemento de A tem as mesmas características do sistema e é chamado de sub-sistema de S.
    [Show full text]
  • INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”
    in Proceedings of the 16th Intern. Symposium of the International Council on Systems Engineering (INCOSE'06), Orlando, FL, USA, Jul 2006. The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations Magnus Eriksson1,2, Kjell Borg1, Jürgen Börstler2 1BAE Systems Hägglunds AB 2Umeå University SE-891 82 Örnsköldsvik SE-901 87 Umeå Sweden Sweden {magnus.eriksson, kjell.borg}@baesystems.se {magnuse, jubo}@cs.umu.se Copyright © 2006 by Magnus Eriksson, Kjell Borg and Jürgen Börstler. Published and used by INCOSE with permission. Abstract. This paper describes a use case driven approach for functional analysis/allocation and requirements flowdown. The approach utilizes use cases and use case realizations for functional architecture modeling, which in turn form the basis for design synthesis and requirements flowdown. We refer to this approach as the FAR (Functional Architecture by use case Realizations) approach. The FAR approach is currently applied in several large-scale defense projects within BAE Systems Hägglunds AB and the experience so far is quite positive. The approach is illustrated throughout the paper using the well known Automatic Teller Machine (ATM) example. INTRODUCTION Organizations developing software intensive defense systems, for example vehicles, are today faced with a number of challenges. These challenges are related to the characteristics of both the market place and the system domain. • Systems are growing ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. • Systems have very long life spans, typically 30 years or longer. • Due to reduced acquisition budgets, these systems are often developed in relatively short series; ranging from only a few to several hundred units.
    [Show full text]
  • Structured Analysis
    240 Structured Analysis Tom DeMarco Principal of the Atlantic Systems Guild New York M.S., Columbia, Diplome, University of Paris Bell Labs: ESS-1 project Manager of real-time projects, distributed online banking systems J.D. Warnier Prize, Stevens Prize Fellow of IEEE Major contributions: Structured Analysis, Peopleware Current interests: project management, change facilitation, litigation of software-intensive contracts sd&m Conference 2001, Software Pioneers Eds.: M. Broy, E. Denert, Springer 2002 241 Tom DeMarco Structured Analysis: Beginnings of a New Discipline How it happened When I arrived at Bell Telephone Laboratories in the fall of 1963, I was immediately assigned to the ESS-1 project. This was a hardware/software endeavor to develop the world’s first commercial stored program telephone switch (now installed in telephone offices all over the world). At the time, the project was made up of some 600 persons, divided about half-and-half between hardware and software. There was also a small simulation group (a dozen people?) working to create an early prediction of system perfor- mance and robustness. I was at first assigned to the hardware group. My assignment was to de- velop certain circuits that enabled Emergency Action, the reconfiguration of processors when one was judged to have failed. This was an intriguing assignment since each of the two processors would diagnose the other and then try to decide together and agree on which one was incapable of furt- her processing – but somehow still capable to judge its own sanity. 242 Tom DeMarco To all of our surprise, the software for the project turned out to require a lot more effort than the hardware.
    [Show full text]
  • MAKING DATA MODELS READABLE David C
    MAKING DATA MODELS READABLE David C. Hay Essential Strategies, Inc. “Confusion and clutter are failures of [drawing] design, not attributes of information. And so the point is to find design strategies that reveal detail and complexity ¾ rather than to fault the data for an excess of complication. Or, worse, to fault viewers for a lack of understanding.” ¾ Edward R. Tufte1 Entity/relationship models (or simply “data models”) are powerful tools for analyzing and representing the structure of an organization. Properly used, they can reveal subtle relationships between elements of a business. They can also form the basis for robust and reliable data base design. Data models have gotten a bad reputation in recent years, however, as many people have found them to be more trouble to produce and less beneficial than promised. Discouraged, people have gone on to other approaches to developing systems ¾ often abandoning modeling altogether, in favor of simply starting with system design. Requirements analysis remains important, however, if systems are ultimately to do something useful for the company. And modeling ¾ especially data modeling ¾ is an essential component of requirements analysis. It is important, therefore, to try to understand why data models have been getting such a “bad rap”. Your author believes, along with Tufte, that the fault lies in the way most people design the models, not in the underlying complexity of what is being represented. An entity/relationship model has two primary objectives: First it represents the analyst’s public understanding of an enterprise, so that the ultimate consumer of a prospective computer system can be sure that the analyst got it right.
    [Show full text]
  • The Great Methodologies Debate: Part 1
    ACCESS TO THE EXPERTS The Journal of Information Technology Management December 2001 Vol. 14, No. 12 The Great Methodologies Debate: Part 1 Resolved “Today, a new debate rages: agile software Traditional methodologists development versus rigorous software are a bunch of process- development.” dependent stick-in-the-muds who’d rather produce flawless Jim Highsmith, Guest Editor documentation than a working system that meets business needs. Opening Statement Jim Highsmith 2 Rebuttal Lightweight, er, “agile” Agile Can Scale: Inventing and Reinventing methodologists are a bunch of SCRUM in Five Companies glorified hackers who are going to be in for a heck of a surprise Jeff Sutherland 5 when they try to scale up their “toys” into enterprise-level software. Agile Versus Traditional: Make Love, Not War! Robert L. Glass 12 Business Intelligence Methodologies: Agile with Rigor? Larissa T. Moss 19 Agility with the RUP Philippe Kruchten 27 Extreme Requirements Engineering Larry Wagner 34 Exclusion, Assumptions, and Misinterpretation: Foes of Collaboration Lou Russell 39 Opening Statement by Jim Highsmith In the early 1980s, I participated in rigorous software development. others be able to understand the one round of methodology debate. Agile approaches (Extreme similarities and differences and be Structured analysis and design Programming, Crystal Methods, able to apply the right mix to their champions such as Tom DeMarco, Lean Development, Feature-Driven own organization. Both the SEI and Ed Yourdon, and Tim Lister were Development, Adaptive Software Rational have made wonderful on one side of the debate, while Development, SCRUM, and contributions to software develop- data-driven design aficionados like Dynamic Systems Development ment, but it is important to Ken Orr, Jean-Dominique Warnier, Methodology) populate one camp.
    [Show full text]
  • The Roots of Software Engineering*
    THE ROOTS OF SOFTWARE ENGINEERING* Michael S. Mahoney Princeton University (CWI Quarterly 3,4(1990), 325-334) At the International Conference on the History of Computing held in Los Alamos in 1976, R.W. Hamming placed his proposed agenda in the title of his paper: "We Would Know What They Thought When They Did It."1 He pleaded for a history of computing that pursued the contextual development of ideas, rather than merely listing names, dates, and places of "firsts". Moreover, he exhorted historians to go beyond the documents to "informed speculation" about the results of undocumented practice. What people actually did and what they thought they were doing may well not be accurately reflected in what they wrote and what they said they were thinking. His own experience had taught him that. Historians of science recognize in Hamming's point what they learned from Thomas Kuhn's Structure of Scientific Revolutions some time ago, namely that the practice of science and the literature of science do not necessarily coincide. Paradigms (or, if you prefer with Kuhn, disciplinary matrices) direct not so much what scientists say as what they do. Hence, to determine the paradigms of past science historians must watch scientists at work practicing their science. We have to reconstruct what they thought from the evidence of what they did, and that work of reconstruction in the history of science has often involved a certain amount of speculation informed by historians' own experience of science. That is all the more the case in the history of technology, where up to the present century the inventor and engineer have \*-as Derek Price once put it\*- "thought with their fingertips", leaving the record of their thinking in the artefacts they have designed rather than in texts they have written.
    [Show full text]
  • Value Mapping – Critical Business Architecture Viewpoint
    Download this and other resources @ http://www.aprocessgroup.com/myapg Value Mapping – Critical Business Architecture Viewpoint AEA Webinar Series “Enterprise Business Intelligence” Armstrong Process Group, Inc. www.aprocessgroup.com Copyright © 1998-2017, Armstrong Process Group, Inc., All rights reserved 2 About APG APG’s mission is to “Align information technology and systems engineering capabilities with business strategy using proven, practical processes delivering world-class results.” Industry thought leader in enterprise architecture, business modeling, process improvement, systems and software engineering, requirements management, and agile methods Member and contributor to UML ®, SysML ®, SPEM, UPDM ™ at the Object Management Group ® (OMG ®) TOGAF ®, ArchiMate ®, and IT4IT ™ at The Open Group BIZBOK ® Guide and UML Profile at the Business Architecture Guild Business partners with Sparx, HPE, and IBM Guild Accredited Training Partner ™ (GATP ™) and IIBA ® Endorsed Education Provider (EEP ™) AEA Webinar Series – “Enterprise Business Intelligence” – Value Mapping Copyright © 1998-2017, Armstrong Process Group, Inc., All rights reserved 3 Business Architecture Framework Business Architecture Knowledgebase Blueprints provide views into knowledgebase, based on stakeholder concerns Scenarios contextualize expected outcomes of business architecture work Also inform initial selections of key stakeholders and likely concerns AEA Webinar Series – “Enterprise Business Intelligence” – Value Mapping BIZBOK Guide Copyright © 1998-2017,
    [Show full text]
  • Agile Methods: Where Did “Agile Thinking” Come From?
    Historical Roots of Agile Methods: Where did “Agile Thinking” Come from? Noura Abbas, Andrew M Gravell, Gary B Wills School of Electronics and Computer Science, University of Southampton Southampton, SO17 1BJ, United Kingdom {na06r, amg, gbw}@ecs.soton.ac.uk Abstract. The appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years [16], but in fact many of the “Agile ideas” have been around since 70’s or even before. Many studies and reviews have been conducted about Agile methods which ascribe their emergence as a reaction against traditional methods. In this paper, we argue that although Agile methods are new as a whole, they have strong roots in the history of software engineering. In addition to the iterative and incremental approaches that have been in use since 1957 [21], people who criticised the traditional methods suggested alternative approaches which were actually Agile ideas such as the response to change, customer involvement, and working software over documentation. The authors of this paper believe that education about the history of Agile thinking will help to develop better understanding as well as promoting the use of Agile methods. We therefore present and discuss the reasons behind the development and introduction of Agile methods, as a reaction to traditional methods, as a result of people's experience, and in particular focusing on reusing ideas from history. Keywords: Agile Methods, Software Development, Foundations and Conceptual Studies of Agile Methods. 1 Introduction Many reviews, studies and surveys have been conducted on Agile methods [1, 20, 15, 23, 38, 27, 22].
    [Show full text]
  • A Comparative Analysis of Structured and Object-Oriented Programming Methods
    JASEM ISSN 1119-8362 Full-text Available Online at J. Appl. Sci. Environ. Manage. December, 2008 All rights reserved www.bioline.org.br/ja Vol. 12(4) 41 - 46 A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS. Department of Computer Science, University of Port Harcourt, Port Harcourt, Nigeria. [email protected], [email protected]. 08056023566 ABSTRACT: The concepts of structured and object-oriented programming methods are not relatively new but these approaches are still very much useful and relevant in today’s programming paradigm. In this paper, we distinguish the features of structured programs from that of object oriented programs. Structured programming is a method of organizing and coding programs that can provide easy understanding and modification, whereas object- oriented programming (OOP) consists of a set of objects, which can vary dynamically, and which can execute by acting and reacting to each other, in much the same way that a real-world process proceeds (the interaction of real- world objects). An object-oriented approach makes programs more intuitive to design, faster to develop, more amenable to modifications, and easier to understand. With the traditional, procedural-oriented/structured programming, a program describes a series of steps to be performed (an algorithm). In the object-oriented view of programming, instead of programs consisting of sets of data loosely coupled to many different procedures, object- oriented programs
    [Show full text]
  • 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.
    [Show full text]