P. 1


|Views: 11,753|Likes:
Published by Kamaluddin Azmi

More info:

Published by: Kamaluddin Azmi on Mar 08, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less






  • Types of Information Systems::
  • Brief Introduction to System Analysis and Design
  • What is System Analysis and Design?
  • Role of System Analyst
  • Who are the Users of System (System end Users)?
  • Case Study: Noida Library System
  • Introduction to Systems: Summary and Review Questions
  • Software (System Development) life Cycle Models
  • Introduction to System Development/Software life cycle models
  • Activities involved Software Development life cycle model
  • Preliminary Investigation
  • Determination of System's requirements: Analysis phase in SDLC
  • System/Software Design Phase in SDLC
  • Development of Software - Coding Stage/Phase in SDLC
  • System Testing
  • SDLC - Implementation and Maintenance in Software Life Cycle
  • Error Distribution with Phases in Software Development Life Cycles
  • Different types of Software Development Life Cycle Models (SDLC)
  • Waterfall Software Development Life Cycle Model
  • Advantages and limitations of the Waterfall Model
  • Prototyping Software Life Cycle Model
  • Iterative Enhancement Life Cycle Model
  • The Spiral Life Cycle Model
  • Object Oriented Methodology Life Cycle Model
  • Dynamic System Development Method (DSDM)
  • preliminary Analysis
  • Request Clarification / Software Requirement Specification (SRS)
  • Cost Benefit Analysis
  • Request Approval
  • Software Estimation
  • Lines of Code (LOC)
  • FP Estimation
  • Empirical Estimation
  • COCOMO, COnstructive COst MOdel
  • Preliminary Analysis - Case study: Library Management System
  • Fact Finding and Decision Making Techniques
  • Fact Finding Techniques
  • Getting Cooperation in Fact Finding
  • What Facts to Gather?
  • How to Initiate Fact Gathering - Public Announcement
  • Common Sense Protocol - Where to Get the Facts?
  • Introduction to the Employee at the Work Place
  • Recording Technique
  • A Caution about Instant Improvements
  • How to Keep the Data Organized
  • Various kinds of techniques used in fact techniques
  • Interviews
  • Questionnaires
  • Record Reviews
  • On-Site Observation
  • Decision Making Documentation
  • Decision Trees
  • Decision Tables
  • Structured English
  • Data Dictionary
  • CASE / Computer Aided Software Engineering Tools
  • Fact Finding Techniques - Case Study : Library Management System
  • Functional Modeling
  • Design Elements in Functional Modeling
  • Modules
  • Processes
  • Input(s) and Output(s)
  • Design of Databases and Files
  • Interfaces - Designing the Interfaces
  • Functional Modeling Techniques
  • Data Flow Diagrams (DFD)
  • Elements of Data Flow Diagrams
  • An Example of a DFD for a System That Pays Workers
  • Conventions used when drawing DFD's
  • DFD Example - General model of publisher's present ordering system
  • The procedure for producing a data flow diagram
  • Functional Modeling - Part II
  • Process Specification (PSPEC)
  • Control Flow Model
  • Control Specifications (CSPEC)
  • Structure Charts
  • Structure of Modules
  • Cohesion
  • Coupling
  • Coding
  • Data Modeling Techniques
  • Data Modeling and Data Requirements
  • E-R Data Modeling Technique
  • E-R Model concept
  • Types of Attributes
  • Entity Types
  • Value Sets (domain) of Attributes
  • Entity Relationships
  • Degree of an Entity Relationship Type
  • Designing basic model and E-R Diagrams
  • Relational Data Modeling and Object Oriented Data Modeling Techniques
  • Relational Database Model
  • Different Types of Keys in Relational Database Model
  • Integrity Rules in Relational Database Model
  • Extensions and intensions in Relational Database Model
  • Key Constraints in Relational Database Model
  • Relational Algebra
  • Traditional set operators in Relational Database Model
  • Special Relational Operators in Relational Database Model
  • Object Oriented Model
  • Comparison between Relational Database Model and Object Oriented Model
  • System Testing and Quality Assurance
  • Fundamentals of Software Testing
  • White Box Testing
  • Black Box Testing
  • Strategic Approach towards Software Testing
  • Unit Testing
  • Integration Testing
  • Top-Down Integration in Integration Testing
  • Bottom-Up Integration in Integration Testing
  • Validation Testing
  • Role of Quality in Software Development
  • Software Quality Factors
  • Software Quality Assurance
  • Activities Involved in Software Quality Assurance
  • Application of Technical methods in Software Quality Assurance
  • Conduct of Formal Technical Reviews (FTR)
  • Software Testing
  • Control of change in Software Quality Assurance
  • Measurement - Software Quality Assurance Activities
  • Record keeping and reporting in Software Quality Assurance
  • Software Maintenance

Computers are fast becoming our way of life and one cannot imagine life without computers in today’s

world. You go to a railway station for reservation, you want to web site a ticket for a cinema, you go to a library, or you go to a bank, you will find computers at all places. Since computers are used in every possible field today, it becomes an important issue to understand and build these computerized systems in an effective way. Building such systems is not an easy process but requires certain skills and capabilities to understand and follow a systematic procedure towards making of any information system. For this, experts in the field have devised various methodologies. Waterfall model is one of the oldest methodologies. Later Prototype Model, Object Oriented Model, Dynamic Systems Development Model, and many other models became very popular for system development. For anyone who is a part of this vast and growing Information Technology industry, having basic understanding of the development process is essential. For the students aspiring to become professionals in the field a thorough knowledge of these basic system development methodologies is very important. In this web site we have explored the concepts of system development. The web site starts with the system concepts, making the reader understand what system means in general and what information systems in specific are. The web site then talks about the complete development process discussing the various stages in the system development process. The different types of system development methodologies, mentioned above, are also explained. This tutorial is for beginners to System Analysis and Design (SAD) Process. If you are new to computers and want to acquire knowledge about the process of system development, then you will find useful information in this tutorial. This tutorial is designed to explain various aspects of software development and different techniques used for building the system. This tutorial is a good introductory guide to the need and overall features of software engineering. This tutorial is designed to introduce Software Engineering concepts to the upcoming software professionals. It assumes that its reader does not know anything about the system development process. However it is assumed that the reader knows the basics of computers.

What is Software Engineering?
Software Engineering is the systematic approach to the development, operation and maintenance of software. Software Engineering is concerned with development and maintenance of software products. The primary goal of software engineering is to provide the quality of software with low cost. Software Engineering involves project planning, project management, systematic analysis, design, validations and maintenance activities.

System Analysis and Design Contents
1. Introduction to Systems 2. Software (System) Development Life Cycle Models 3. Preliminary Analysis 4. Fact Finding and Decision Making Techniques 5. Functional Modeling I

6. Functional Modeling II 7. Data Modeling Techniques 8. Relational Data Modeling and Object Oriented Data Modeling Techniques 9. Testing and Quality Assurance

Brief Explanation of the chapters in this tutorial
1. Introduction to Systems - Introduces the concept of systems to the reader and explains what an information system is. It talks about various types of information systems and their relevance to the functioning of any organization. This chapter also gives a brief introduction to system analysis and design. 2. Software (System) Development Life Cycle Models - Explains various activities involved in the development of software systems. It presents the different approaches towards software development. In this chapter, Waterfall Model, Prototype Model, Dynamic System Development Model, and Object Oriented models are discussed. 3. Preliminary Analysis - covers various activities that are performed during the preliminary analysis of the system development. It shows how the feasibility study for the system to be developed is done. Also in the later part of the chapter various software estimation techniques are discussed. 4. Fact Finding and Decision Making Techniques - shows the various techniques used for fact finding during the analysis of the system. In this, interviews, questionnaires, on site observation, and record reviews are presented. This chapter also discusses the decisionmaking and documentation techniques. For this Decision Tables, Decision Tress, Structured English and Data Dictionary is presented. 5. Functional Modeling I - presents the various concepts of system design. Design elements like input-output to the system, processes involved in the system and the database elements of the system are discussed. It also discusses Data Flow Diagrams that are used to represent the functionality of the system. 6. Functional Modeling II - introduces the modular programming concept to the software development. It explains the structure charts that represent the modular structure of various modules of the software being developed. Concepts like Cohesion and Coupling that further enhance the users understanding of modular designing are also presented. 7. Data Modeling Techniques - presents the concepts involve in the data modeling phase of system development where the storage of data and the storage form is discussed. Here Entity Relationship model along with Entity Relationship Diagrams is used to illustrate the data modeling concepts. are discussed. 8. Relational Data Modeling and Object Oriented Data Modeling Techniques - is an extension to the chapter 7 (Data Modeling Techniques). Here two other data models, Relational and Object Oriented Models are discussed. Comparison of the two models is also presented. 9. Testing and Quality Assurance - covers the various testing techniques and strategies employed during the development of the system. Also various quality assurance activities for software development are presented.

What is a System?
The term “system” originates from the Greek term system, which means to “place together.” Multiple business and engineering domains have definitions of a system. This text defines a system as: •
System An integrated set of interoperable elements, each with explicitly specified and bounded capabilities, working synergistically to perform value-added processing to enable a User to satisfy mission-oriented operational needs in a prescribed operating environment with a specified outcome and probability of success.

To help you understand the rationale for this definition, let’s examine each part in detail.

System Definition Rationale
The definition above captures a number of key discussion points about systems. Let’s examine the basis for each phrase in the definition. • • By “an integrated set,” we mean that a system, by definition, is composed of hierarchical levels of physical elements, entities, or components. By “interoperable elements,” we mean that elements within the system’s structure must be compatible with each other in form, fit, and function, for example. System elements include equipment (e.g., hardware and system, system, facilities, operating constraints, support), maintenance, supplies, spares, training, resources, procedural data, external systems, and anything else that supports mission accomplishment.

One is tempted to expand this phrase to state “interoperable and complementary.” In general, system elements should have complementary missions and objectives with no overlapping capabilities. However, redundant systems may require duplication of capabilities across several system elements. Additionally, some systems, such as networks, have multiple instances of the same components. • By each element having “explicitly specified and bounded capabilities,” we mean that every element should work to accomplish some higher level goal or purposeful mission. System element contributions to the overall system performance must be explicitly specified. This requires that operational and functional performance capabilities for each system element be identified and explicitly bounded to a level of specificity that allows the element to be analyzed, designed, developed, tested, verified, and validated—either on a stand-alone basis or as part of the integrated system. By “working in synergistically,” we mean that the purpose of integrating the set of elements is to leverage the capabilities of individual element capabilities to accomplish a higher level capability that cannot be achieved as stand-alone elements. By “value-added processing,” we mean that factors such operational cost, utility, suitability, availability, and efficiency demand that each system operation and task add value to its inputs availability, and produce outputs that contribute to achievement of the overall system mission outcome and performance objectives. By “enable a user to predictably satisfy mission-oriented operational needs,” we mean that every system has a purpose (i.e., a reason for existence) and a value to the user(s). Its value may be a return on investment (ROI) relative to satisfying operational needs or to satisfy system missions and objectives. By “in a prescribed operating environment,” we mean that for economic, outcome, and survival reasons, every system must have a prescribed—that is, bounded— operating environment. By “with a specified outcome,” we mean that system stakeholders (Users, shareholders, owners, etc.) expect systems to produce results. The observed

• •

System Developer) consensus. We see this in specifications and plans. for example. measurable. By “and probability of success. dependability. Moreover. You will be surprised how animated and energized people become over wording exercises. the definition stated in this text should prove to be the most descriptive characterization. lethality. Examples of organizations having standard definitions include: • • • • • • • International Council on Systems Engineering (INCOSE) Institute of Electrical and Electronic Engineers (IEEE) American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA) International Standards Organization (ISO) US Department of Defense (DoD) US National Aeronautics and Space Administration (NASA) US Federal Aviation Administration (FAA) You are encouraged to broaden your knowledge and explore definitions by these organizations. quantifiable... 3. and survivability. 2. you will find a diversity of viewpoints. Thus. You need at least four types of agreement on working level definitions of a system: 1. achievement of a “one size fits all” convergence and consensus by standards organizations often results in wording that is so diluted that many believe it to be insufficient and inadequate. your program team. the degree of success is determined by various performance factors such as reliability. a contractual consensus with your customer. availability. all tempered by their personal knowledge and experiences. However. The intent is to establish continuity across contract and organizations as personnel transition between programs. Obtain consensus on the key elements of substantive . must be outcome-oriented.g.e. You should then select one that best fits your business application. since it is the root of our language and communications. maintainability. perform one step at a time. and Most important. Why? Of particular importance is that you. sustainability. wordsmith grammar has no value if it lacks substantive content. products. Grammar is important. If you analyze these. Closing Point When people develop definitions. Depending on your personal viewpoints and needs. Organizationally you need a consensus of agreement among the System Developer team members. a good definition may sometimes be simply a bulleted list of descriptors concerning what a term is or. and verifiable.• behavior. and your customer (i. Subsequently. Other Definitions of a System National and international standards organizations as well as different authors have their own definitions of a system. if you or your team attempts to create your own definition. For highly diverse terms such as a system. for example. byproducts. 4. People typically spend a disproportionate amount of time on grammar and spend very little time on substantive content. So. a personal understanding a program team consensus an organizational (e. is not. perhaps. they attempt to create content and grammar simultaneously.” we mean that accomplishment of a specific outcome involves a degree of uncertainty or risk. a User or an Acquirer as the User’s technical representative) have a mutually clear and concise understanding of the term. or services. they throw up their hands and walk away.

Environmental systems If we analyze these systems. is typically a physical device or entity that has a specific capability—form. Products and Tools: People often confuse the concepts of systems. Licensing systems. products. Public safety systems. and behavior. Further analysis reveals most of these fall into one or more classes such as individual versus organizational. Consider the next high-level examples. let’s examine each of these terms in detail. . sea-based. and function—with a specified level of performance. or hybrid. products. Welfare systems. operation. These systems typically include humans. byproducts. mobile. hierarchical structure. or support. Learning to Recognize Types of Systems: Systems occur in a number of forms and vary in composition. A system may consist of two or more integrated elements whose combined—synergistic—purpose is to achieve mission objectives that may not be effectively or efficiently accomplished by each element on an individual basis. or services. Parks and recreation systems. • • • • • • • • • • • • • • • • Economic systems Educational systems Financial systems Environmental systems Medical systems Corporate systems Insurance systems Religious systems Social systems Psychological systems Cultural systems Food distribution systems Transportation systems Communications systems Entertainment systems Government systems Legislative systems. To facilitate our discussion. Judicial systems. Let’s define the context of product: a product. open loop versus closed loop. Revenue systems. fit. human-in-the-loop (HITL) systems. as an ENABLING element of a larger system. Product Context Some systems are created as a work product by other systems. Military systems. and transportable systems. Delineating Systems. and fixed. we find that they produce combinations of products. In general. air-based. Taxation systems.content. ground-based. and tools. formal versus informal. human-made systems require some level of human resources for planning. structure the statement in a logical sequence and translate the structure into grammar. Then. and tools to varying degrees. System Context We defined the term system earlier in this section. space-based. intervention.

and function but lacks the ability to apply its self to hammering or removing nails. inputs such as stimuli and cues are fed into a system that processes the inputs and produces an output. Analytical Representation of a System: As an abstraction we symbolically represent a system as a simple entity by using a rectangular box as shown in Figure 1. and developing a system. fit. Example 1. The attributes of the construct—which include desirable/undesirable inputs. 2. you create a system of systems (SoS). Effectively. the system must add value to the input in producing an output. we often relate to equipmentbased products as items you can procure from a vendor via a catalog order number. Nor can products achieve the higher level system mission objectives without human intervention in some form. enables a statistician to efficiently analyze large amounts of data and variances in a short period of time. as a support tool. designing. Functionality only represents the ACTION to be accomplished. not HOW WELL as characterized by performance. the diagram is missing critical information that relates to how the system operates and performs within its operating environment.Products generally lack the ability—meaning intelligence—to self-apply themselves without human assistance. In simple terms. A simple fulcrum and pivot. stakeholders. A statistical software application. In general. this symbolism is acceptable. Example 1. Contextually. from an analytical perspective. when programmed and activated by the pilot under certain conditions. This text employs capability as the operative term that encompasses both the functionality and performance attributes of a system. and desirable/undesirable outputs—serve as a key checklist to ensure that all contributory factors are duly considered when specifying. The result is shown in Figure 2. the words need to more explicitly identify WHAT the system performs. That is. The simple diagram presented in Figure 1 represents a system. Ajet aircraft. . Tool Context Some systems or products are employed as tools by higher level systems. However. We refer to the transformational processing that adds value to inputs and produces an output as a capability. Therefore. however. 2. As a construct. however. Let’s define what we mean by a tool. this is partially correct. to fly. as a system and procurable vendor product. a product may actually be a vendor’s “system” that is integrated into a User’s higher-level system. You will often hear people refer to this as the system’s functionality. enable a human to leverage their own physical strength to displace a rock that otherwise could not be moved easily by one human. is integrated into an airline’s system and may possess the capability. A tool is a supporting product that enables a user or system to leverage its own capabilities and performance to more effectively or efficiently achieve mission objectives that exceed the individual capabilities of the User or system. we expand the diagram to identify these missing elements. A hammer. as a procurable product has form. as tools.

We refer to this as the engineering of systems. design. for example. for example. and wellbeing of the public as well as the environment. and development of a system. and collaborative interactions. principles. and development of both types of systems. mechanical engineering. and performance monitoring that may have an impact on the safety. engineering of systems may be required. efficient. how do you know when the engineering of systems is required? Actually these two categories represent a continuum of systems. or services such as schools. complex interactions. electrical engineering. design. Some systems require the analysis. banking systems. and development of specialized structures. product. may require application of various analytical and mathematical principles to develop business models and performance models to determine profitability and return on investment (ROI) and statistical theory for optimal waiting line or weather conditions. In the case of highly complex systems. or service.Analytical System Entity Construct Systems that Require Engineering: Earlier we listed examples of various types of systems. On the surface these two categories imply a clear distinction between those that require engineering and those that do not. products. design. So. As such.Figure 1 . Some of these systems are workflowbased systems that produce systems. and practices that apply to the analysis. or services that range from making a piece of paper. products. This text provides the concepts. and software engineering .Basic System Entity Construct Figure 2 . which can be complex. and scientific principles may have to be applied. and manufacturers. to developing a system as . you will find that they both share a common set concepts. hospitals. supporting assets. As you investigate WHAT is required to analyze. which may require a mixture of engineering disciplines such as system engineering. analytical. health. mathematical. and develop both types of systems. and effective organizational structures. design. and practices. principles. they require insightful. Business systems. These disciplines may only be required at various stages during the analysis.

or your organization: 1. program teams. experience. and services symbolizes humankind. This definition can be summarized in a key System Engineering (SE) principle: System engineering BEGINS and ENDS with the User. mankind’s survival is very . as we will see. each dependent on an individual’s or organization’s perspectives. System Engineering (SE). For those who prefer a brief. for example. defines the term as follows: • Engineering “[T]he profession in which knowledge of the mathematical and natural sciences gained by study. So. System engineering means different things to different people. high-level definition that encompasses the key aspects of System Engineering (SE). engineering originates from the Latin word ingenerare. Establish a consensus definition. 2. products. the Accreditation Board for Engineering and Technology (ABET). selecting. consider the following definition: • System Engineering (SE) The multidisciplinary application of analytical. The ABET definition of engineering.” Today. includes the central objective “to utilize. the materials and forces of nature for the benefit of mankind. The term.” (Source: Accreditation Board for Engineering and Technology [ABET]) There are a number of ways to define System Engineering (SE). and the like. the response should eliminate the need for additional clarifying questions. However. and minimizes development and life cycle costs while balancing stakeholder interests. the User of systems. as with any definition. economically. and scientific principles to formulating. Defining Key Terms Engineering students often graduate without being introduced to the root term that provides the basis for their formal education. if you have a diver-sity of perspectives and definitions. and developing a solution that has acceptable risk. Perhaps the best way to address the question: What is system engineering? What Is System Engineering? Explicitly System Engineering (SE) is the multidisciplinary engineering of systems.” Applying this same context to the definition of System Engineering (SE). satisfies user operational need(s). is one of those terms that requires more than simply defining WHAT System Engineering (SE) does. However. experiences. what should you do? What is important is that you. mathematical. Document the definition in organizational or program command media to serve as a guide for all.complex as an aircraft carrier or NASA’s International Space Station (ISS). the engineering of a system response evokes two additional questions: What is engineering? What is a system? Pursuing this line of thought. which accredits engineering schools in the United States. let’s explore these questions further. and practice is applied with judgment to develop ways to utilize economically the materials and forces of nature for the benefit of mankind. which means “to create. the definition must also identify WHO/WHAT benefits from System Engineering (SE). Instead. You will discover that even your own views of System Engineering (SE) will evolve over time.

Resources can be hardware. a Banking system cannot function without the required stationery like cheque books. System Engineering (SE) must have a broader perspective than simply “for the benefit of mankind. Intermediate Data . As discussed above.g. the Banking systems have their predefined rules for providing interest at different rates for different types of accounts. Procedures Every system functions under a set of rules that govern the system to accomplish the defined goal of the system. System engineering requires development of a strong foundation in understanding how to characterize a system. the Output must conform to the customer's expectations. a system is a set of components working together to achieve some goal. pass books etc. Output is the outcome of processing. its peripherals. All these work in coordination to achieve the overall objective of the system. However. System Components and Characteristics: A big system may be seen as a set of interacting smaller systems known as subsystems or functional units each of which have its defined tasks. For achieving the goal the system requires certain inputs. such systems also need computers to maintain their data and trained staff to operate these computers and cater to the customer requirements. Data/Information Every system has some predefined goal. services or information. The main objective of the System is to produce some useful output.dependent on a living environment that supports sustainment of the species. Therefore.” System Engineering (SE) must also ensure a balance between humankind and the living environment without sacrificing either. etc. For instance. Hardware resources may include the computer. goods. software or liveware. This set of rules defines the procedures for the system to Chapter 1 Introduction to Systems operate. Inputs are the elements that enter the system and produce Output. For instance. and performance. Output can be of any nature e. Thus these resources make an important component of any system. Software resources would include the programs running on these computers and the liveware would include the human beings required to operate the system and make it functional. The basic elements of the system may be listed as: • • • • • Resources Procedures Data/Information Intermediate Data Processes Resources Every system requires certain resources for the system to exist. stationery etc. properties. or service in terms of its attributes. like material. information. which are converted into the required output. product. Input can be of various kinds.

Systems should be designed to meet standards. Therefore. . There are various sorting algorithms. Each department adds their validity checks on it. Also. So there should be a standard or rule to use a particular algorithm. But each has its own complexity. A system cannot exist without a defined objective. It should be seen whether that algorithm is implemented in the system. intermediate data should be handled as carefully as other data since the output depends upon it. we humans live in a particular environment. For example. All these components together make a complete functional system. Intermediate forms of data occur when there is a lot of processing on the input data. These processes are the operational element of the system. some of which are: • • • • • Objective Standards Environment Feedback Boundaries and interfaces Objective Every system has a predefined goal or objective towards which it works. Finally the form gets transformed and the student gets a slip that states whether the student has been registered for the requested subjects or not. for a system to exist it should change according to the changing environment. For instance in a Banking system there are several processes that are carried out. Consider for example the processing of a cheque as a process. Standards It is the acceptable level of performance for any system. Processes The systems have some processes that make use of the resources to achieve the set goal under the defined procedures. Before it is transformed into Output. Environment Every system whether it is natural or man made co-exists with an environment. there are changes in the surroundings but our body gradually adapts to the new environment. These are some of the processes of the Banking system. in a college when students register for a new semester. As we move to other places. It is very important for a system to adapt itself to its environment. So such algorithm should be used that gives most optimum efficiency. It helps in building the System in a better way. for which each department and each individual has to work in coordination. Standards can be business specific or organization specific. A cheque passes through several stages before it actually gets processed and converted. Systems also exhibit certain features and characteristics. So.Various processes process system's Inputs. the initial form submitted by student goes through many departments. For example. then it would have been very difficult for human to survive for so many thousand years. For example take a sorting problem. For example an organization would have an objective of earning maximum possible revenues. it goes through many intermediary transformations. it is very important to identify the Intermediate Data. If it were not the case.

which are not Y2K compliant. Boundaries and Interfaces Every system has defined boundaries within which it operates. it is shown that a system takes input. Programs. Personnel system in an organization has its work domain with defined procedures. Those systems. open and closed. The dynamic systems are constantly changing. They may be formulas. System interacts with other systems through its interfaces. Computer systems are dynamic system. For instance. which assist in the working of the center. physical or abstract and natural or man made information systems . To have a good understanding of these systems. and applications can change according to the user's needs. Abstract systems are conceptual. Things that are not part of the system are environmental elements for the system. If the financial details of an employee are required. These may be static or dynamic in nature. For example. Feed Back Feedback is an important element of systems. systems can be divided into two categories. Open Closed System Systems interact with their environment to achieve their targets. In fig 1. The output of a system needs to be observed and feedback from the output taken so as to improve the system and make it achieve the laid standards. Users of the systems also interact with it through interfaces. which are explained next. Some of the categories are open or closed. Depending upon the interaction with the environment. For computer systems to survive it is important these systems are made Y2K compliant or Y2K ready. Desks and chairs are the static parts. These are not physical entities. . These should be as user friendly as possible. take a computer center. Classifications of System : From previous section we have a firm knowledge of various system components and its characteristics. Static parts don't change. Classification of systems can be done in many ways. There are various types of system. these should be customized to the user needs. the system has to interact with the Accounting system to get the required details. representation or model of a real system. It then transforms it into output. data. Also some feedback can come from customer (regarding quality) or it can be some intermediate data (the output of one process and input for the other) that is required to produce final output. Therefore.Another example can be Y2K problem for computer systems. will not be able to work properly after year 2000. Beyond these limits the system has to interact with the other systems. Interfaces are another important element through which the system interacts with the outside world. Physical or Abstract System Physical systems are tangible entities that we can feel and touch. these can be categorized in many ways.1.

These are hardware (machines). managers or users). Information system deals with data of the organizations. management information system and decision support system. These are made to solve the day to day work related problems. Types of Information Systems:: Information systems differ in their business needs. Maintaining files. An open system has many interfaces with its environment. Closed systems:Systems that don't interact with their environment. handle on line transactions.Open systems: Systems that interact with their environment. generate reports. we explore three most important information systems namely. and computer based. Closed systems exist in concept only. instructions. Man made Information System The main purpose of information systems is to manage data for a particular organization. These maintain huge databases. Formal Information Systems: It deals with the flow of information from top management to lower management. These systems are discussed in detail in the next section. Three major information systems are 1. Management information systems . Information flows in the form of memos. For these types of systems. etc. Practically most of the systems are open systems. produce reports. software. We will be talking about different types of information systems prevalent in the industry. It can also adapt to changing environmental conditions. procedures. data. and examine how computers assist in maintaining Information systems. Transaction processing systems 2. These are usually formal. Information Systems: In the previous section we studied about various classifications of systems. producing information and reports are few functions. An information system is an example of this category. people (programmers. An information system produces customized information depending upon the needs of the organization. These types of systems depend upon computers for performing their objectives. and delivers output to the outside of system. analyst should have a sound understanding of computer technologies. All six elements interact to convert data into information. and other output. handle queries. But feedback can be given from lower authorities to top management. A computer based business system involves six interdependent elements. maintain data. The transformation of data into information is primary function of information system. The purposes of Information system are to process input. System analysis relies heavily upon computers to solve problems. It can receive inputs from. informal. Also depending upon different levels in organization information systems differ. and information (processed data). Computer-Based Information Systems: This class of systems depends on the use of computer for managing business applications. handle hundreds of queries etc. transaction processing system. Since in business we mainly deal with information systems we'll further explore these systems. In the following section. Informal Information systems: Informal systems are employee based.

etc are all transactions. Due to its capabilities to provide information for processing transaction of the organization. canceling. For example. Booking. The third category of information is relating to the daily or short term information needs of the organization such as attendance records of the employees. Figure 1. This information is not required by the lower levels in the organization.2 . Some examples of information provided by such systems areprocessing of orders. Management information system (MIS) caters to such information needs of the organization. The information needs are different at different organizational levels. For example the trends in revenues earned by the organization are required by the top management for setting the policies of the organization. The information required at this level is used for making short term decisions and plans for the organization. most of the big organizations have separate MIS departments to look into the related issues and proper functioning of the system. And due to its vastness.3. which are common to almost all . This kind of information is required at the operational level for carrying out the day-to-day operational activities. Any query made to it is a transaction. fall under this category. the information system is known as Transaction Processing System or Data Processing System. evaluating overdue purchaser orders etc. Management Information Systems have become a necessity for all big organizations. take a railway reservation system. However. Decision support systems Figure 1. Strategic information is the information needed by top most management for decision making. Transaction can be any activity of the organization. Transactions differ from organization to organization. The information systems that provide these kinds of information are known as Decision Support Systems. Due to its capabilities to fulfill the managerial information needs of the organization. Transaction Processing Systems TPS processes business transaction of the organization. posting of entries in bank. Information like sales analysis for the past quarter or yearly production details etc. Accordingly the information can be categorized as: strategic information. managerial information and operational information.2 shows relation of information system to the levels of organization. there are some transactions.Relation of information systems to levels of organization The second category of information required by the middle management is known as managerial information.

storage and retrieval. maintaining employees accounts. Provides information to managers who must make judgments about particular situations. Management information system Provides input to be used in the managerial decision process. and can be programmed to follow routines functions of the organization. An important element of MIS is database . maintaining their leave status. A decision support system must very flexible. Typical information requirements can be anticipated. A decision is considered unstructured if there are no clear procedures for making the decision and if not all the factors to be considered in the decision can be readily identified in advance. It is a set of information processing functions. Decision Support Systems These systems assist higher management to make long term decisions. Management Information Systems These systems assist lower management in problem solving and making decisions. Deals with well-structured processes.organizations. These are not of recurring nature. These type of systems handle unstructured or semi structured decisions. Some recur infrequently or occur only once. Includes record keeping applications. Like employee new employee. This provides high speed and accurate processing of record keeping of basic operational processes. These include calculation. A database is a non-redundant collection of interrelated data items that can be processed through application programs and available to many users. They use the results of transaction processing and some other information also. The user should be able to produce customized reports by giving particular data and format specific to particular situations. Supports decision-makers in situations that are not well structured. It should handle queries as quickly as they arrive. Decision support system . Deals with supporting well structured decision situations. Summary of Information Systems Categories of Information System Transaction Processing System Characteristics Substitutes computer-based processing for manual procedures. Transaction processing systems provide speed and accuracy. etc.

What exactly System Analysis and Design is? 2. Stages in building an improved system . In System Analysis more emphasis is given to understanding the details of an existing system or a proposed one and then deciding whether the proposed system is desirable or not and whether the existing system needs improvements. Now we will look into the different aspects of how these systems are built. Users of the Systems? What is System Analysis and Design? System development can generally be thought of having two major components: systems analysis and systems design. In case of an organization functioning manually and planning to computerize its functioning. and using the information to recommend improvements to the system. identifying problems. Who is system analyst and what are his various responsibilities? 3. their components. Any change in the existing policies of an organization may require the existing information system to be restructured or complete development of a new information system. The development of any information system can be put into two major phases: analysis and Design. During analysis phase the complete functioning of the system is understood and requirements are defined which lead to designing of a new system. the development of a new information system would be required. So let us now understand 1. system analysis is the process of investigating a system. Hence the development process of a system is also known as System Analysis and Design process. Thus.Brief Introduction to System Analysis and Design Till now we have studied what systems are. information system. classification of system.

In addition to the technical know-how of the information system development a system analyst should also have the following knowledge. 3) Systems analysis. Analysis specifies what the system should do. and programming: Here Analyst is also required to perform as a programmer. Role of System Analyst differs from organization to organization. the actual implementation of the system occurs. Most common responsibilities of System Analyst are following 1) System analysis It includes system's study in order to get facts about business activity. See the figure above. Here the responsibility includes only requirement determination. . System design is the process of planning a new business system or one to replace or complement an existing system. not the design of the system. 2) System analysis and design: Here apart from the analysis work. Due to the various responsibilities that a system analyst requires to handle. design. • • • Business knowledge: As the analyst might have to develop any kind of a business system. working system is available and it requires timely maintenance. After the proposed system is analyzed and designed. where he actually writes the code to implement the design of the proposed application. he should be familiar with the general functioning of all kind of businesses. Role of System Analyst The system analyst is the person (or persons) who guides through the development of an information system. Analyst is also responsible for the designing of the new system/application. he has to be multifaceted person with varied skills required at various stages of the life cycle. Design states how to accomplish the objective. Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.The above figure shows the various stages involved in building an improved system. It is about getting information and determining requirements. After implementation. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.

Library maintains records of these suppliers. Against each card a member can issue one book from library. these users benefit from the results of these systems. There is a membership fee of Rs 400 for a year. The case would be referred to as and where necessary throughout the website and in this process we will be developing the system required. Like person at the booking counter of a gas authority. Each book is to be returned on the specified due date. and supplier’s details. author. Now we know what systems are and what is system analysis and design. Other users are the indirect end users who do not interact with the systems hardware and software. There are other problems also that the library staff is facing. Records for the books in the library are maintained. However. So let us take a case in which we’ll apply the concepts we have learned in the chapter. Maintaining manual records is becoming difficult task. a fine of Rs 2 per day after the due return date is charged. Fourth types of users are senior managers. There are suppliers that supply books to the library. Case Study: Noida Library System Noida Public Library is the biggest library in Noida. These forms are kept in store for maintaining members’ records and knowing the membership period. These records contain details about the publisher. Very first users are the hands-on users. Currently it has about 300 members. Currently all functions of the library are done manually. Accounts are maintained for the membership fees and money collected from the fines. This person actually sees the records and registers requests from various customers for gas cylinders. subject. Approximately 100 members come to library daily to issue and return books. There are 5000 books available out of which 1000 books are for reference and can not be issued. Now day by day members are increasing. Further. There is a form to be filled in which person fills personal details. language. They are the people who feed in the input data and get output data.Who are the Users of System (System end Users)? The system end users of the system refer to the people who use computers to perform their jobs. There are two librarians for books return and issue transaction. These reports are for details of the books available in the library. financial details. Many reports are also produced. He/she has three cards to issue books. . members’ details. These oversee investment in the development or use of the system. etc. There are third types of users who have management responsibilities for application systems. If a member fails to return a book on the specified date. A member can issue a maximum of three books. Whenever a member wishes to issue a book and there are spare cards. Otherwise that request is not entertained. Even the records are maintained on papers. then the book is issued. These types of users can be managers of organization using that system. They actually interact with the system. Like in case of issue of duplicate cards to a member when member or library staff loses the card. end users can be divided into various categories. like desktop operators. They are responsible for evaluating organization's exposure to risk from the systems failure. It is very difficult to check the genuinity of the problem. A person who is 18 or above can become a member. If in case a card gets lost then a duplicate card is issued.

So to perform this kind of search is very difficult in a manual system. A system to automate the functions of record keeping and report generation. in order to provide its members better services. It also plans to increase the membership fees from 400 to 1000 for yearly and 500 for half year. . in terms of books. Fig 1. And which could help in executing the different searches in a faster manner. Management plans to expand the library. For the last two months the library has not entertained requests for the new membership as it was difficult to manage the existing 250 members manually. In our case study Noida Public Library is our system. the management of the library aims to increase its members at the rate of 75 per month. number of members and finally the revenue generated.Sometimes the library staff needs to know about the status of a book as to whether it is issued or not. members. and accounts. With the expansion plans. books in the library. Manually producing the reports is a cumbersome job when there are hundreds and thousands of records. It is observed that every month there are at least 50-100 requests for membership. However. Books issue and return section. Each functional unit has its own task. books record unit. The main objective of library system is to provide books to its members without difficulty. and report generation units are the different functional units of the library. Due to the problems faced by the library staff and its expansion plans. accounts. Every system is a set of some functional units that work together to achieve some objective. Our system has many functional units. Also management requires reports for books issued.4 depicts our library system pictorially. which includes increase in number of books from 3 to 4. Applying the concepts studied in the chapter to the case study: The first thing we studied is systems. members record unit. the management is planning to have a system that would first eradicate the needs of cards. each of these work independently to achieve the overall objective of the library. The system to handle the financial details.

Later in the session, we talked about different components and characteristics of the systems. Data is an important component of any system. Here, data is pertaining to the details of members, books, accounts, and suppliers. Since people can interact with the system this system is an open system. The system is mainly concerned with the management of data it is an information system. If this system were to be automated as conceived by the management, then role of the system analyst would be to study the system, its workings, and its existing problems. Also the analyst needs to provide a solution to the existing problem. Now that the management has decided for an automated system the analyst would perform the above tasks. As the analyst did the study of the system, the following problems were identified • • • • •
Maintaining membership cards Producing reports due to large amount of data Maintaining accounts Keeping records for books in library and its members Performing searches

Now that the analyst has studied the system and identified the problems, it is the responsibility of the analyst to provide a solution system to the management of the library.

Introduction to Systems: Summary and Review Questions
• • • • • • • • • • • • • • • • A system is a set of interdependent components, organized in a planned manner to achieve certain objectives. System interacts with their environment through receiving inputs and producing outputs. Systems can be decomposed into smaller units called subsystems. Systems falls into three categories Physical or Abstract systems Open or closed system depending upon their interaction with environment. Man-made such as information systems. Three levels of information in organization require a special type of information. Strategic information relates to long-term planning policies and upper management. Managerial information helps middle management and department heads in policy implementation and control. Operational information is daily information needed to operate the business. Information systems are of many types. Management Information, transaction processing, and decision support systems are all information systems. Transaction processing system assist in processing day to day activities of the organization Management information systems are decisions oriented. These use transaction data and other information that is developed internally or outside the organization. Decision support systems are built for assisting managers who are responsible for making decisions. System analysis and design refers to the application of systems approach to problem solving.

Review Questions

1. 2. 3. 4. 5. 6. 7.

Define the term ‘System’. What are the various elements of system? Identify two systems in your surroundings. What is system analysis and design? What are the roles of system analyst? Make a list of traits that a system analyst should have. Will the responsibility of a system analyst vary according to:

(a) Organization size( for example small or large business)? (b) Type of organization (business, government agency, non-profit organization)? 8. Differentiate between a) Open and closed system b) Physical and abstract 9. Main aim of an information system is to process _________. 10. Transaction processing, __________________ , and decision support system are three types of information system. 11. State true or false a) Decision support system is for middle level management. b) Closed systems don't interact with their environment. c) Transaction processing system handles day-to-day operations of the organization. d) Management information system deals with strategic information of organization. e) Problem solving and interpersonal skills are desirable for system analyst.

Software (System Development) life Cycle Models
At the end of this lesson you would be able to know the various stages involved in a system life cycle and you would be able to understand the various methodologies available for system development. Introduction to Life Cycle Models Activities involved in any Life cycle Model Preliminary Investigation Determination of System's requirements - Analysis Phase Design of System Development of Software System Testing Implementation and Maintenance Error Distribution with Phases Different Life Cycles Models Traditional/Waterfall Software Development Model Advantages and limitations of the Waterfall Model Prototyping Life Cycle Iterative Enhancement Life Cycle Model Spiral Life Cycle Model Object Oriented Methodology Dynamic System Development Method

Introduction to System Development/Software life cycle models

The trends of increasing technical complexity of the systems, coupled with the need for repeatable and predictable process methodologies, have driven System Developers to establish system development models or software development life cycle models. Nearly three decades ago the operations in an organization used to be limited and so it was possible to maintain them using manual procedures. But with the growing operations of organizations, the need to automate the various activities increased, since for manual procedures it was becoming very difficult, slow and complicated. Like maintaining records for a thousand plus employees company on papers is definitely a cumbersome job. So, at that time more and more companies started going for automation. Since there were a lot of organizations, which were opting for automation, it was felt that some standard and structural procedure or methodology be introduced in the industry so that the transition from manual to automated system became easy. The concept of system life cycle came into existence then. Life cycle model emphasized on the need to follow some structured approach towards building new or improved system. There were many models suggested. A waterfall model was among the very first models that came into existence. Later on many other models like prototype, rapid application development model, etc were also introduced. System development begins with the recognition of user needs. Then there is a preliminary investigation stage. It includes evaluation of present system, information gathering, feasibility study, and request approval. Feasibility study includes technical, economic, legal and operational feasibility. In economic feasibility cost-benefit analysis is done. After that, there are detailed design, implementation, testing and maintenance stages. In this session, we'll be learning about various stages that make system's life cycle. In addition, different life cycles models will be discussed. These include Waterfall model, Prototype model, Object-Oriented Model, spiral model and Dynamic Systems Development Method (DSDM).

Activities involved Software Development life cycle model
Problem solving in software consists of these activities: 1. 2. 3. 4. Understanding the problem Deciding a plan for a solution Coding the planned solution Testing the actual program

For small problems these activities may not be done explicitly. The start end boundaries of these activities may not be clearly defined and not written record of the activities may be kept. However, for large systems where the problem solving activity may last over a few years. And where many people are involved in development, performing these activities implicitly without proper documentation and representation will clearly not work. For any software system of a non-trival nature, each of the four activities for problem solving listed above has to be done formally. For large systems, each activity can be extremely complex and methodologies and procedures are needed to perform it efficiently and correctly. Each of these activities is a major task for large software projects. Furthermore, each of the basic activities itself may be so large that it cannot be handled in single step and must be broken into smaller steps. For example, design of a large software system is always broken into multiple, distinct design phases, starting from a very high level design specifying only the components in the system to a detailed design where the logic of the components is specified. The basic activities or phases to be performed for developing a software system are:

Then. for the proposed system is done then further analysis is possible. 6. all possible alternate solutions are chalked out. So the number of employee in the company has increased.1 shows different stages in the system's life cycle. 4. First. some activities are performed after the main development is complete. If this is the case. 2. 3. Only after the recognition of need. Now this company is recruiting many new people every year. and finally evaluate whether automating the system would help the organization. which is concerned with actually installing the system on the client's computer systems and then testing it. which is termed as the "proposed system". maintenance in unavoidable for software systems. In most commercial software developments there are also some activities performed before the requirement analysis takes place. the development activities begin starting with the requirements analysis phase. . So the management is considering the option of automating the leave processing system. Once the initial investigation is done and the need for new or improved system is established. This also requires modification of the software. Therefore. It initiates with a project request. All these systems are known as "candidate systems". Software needs to be maintained not because some of its components "wear out" and need to be replaced. Error distribution with phases Preliminary Investigation Fig 2. then the system analyst would need to investigate the existing system. First stage is the preliminary analysis. The proposed system is evaluated for its feasibility. 3. In this phase the feasibility of the project is analyzed. Furthermore. Requirement Analysis / Determination of System's Requirements Design of system Development (coding) of software System Testing In addition to the activities performed during software development . but because there are often some residual errors remaining in the system which must be removed later as they are discovered. some understanding of the major requirements of the system is essential.1. find the limitations present. there is software maintenance. Preliminary Investigation Requirement Analysis / Determination of System's Requirements Design of system Development (coding) of software System Testing Software Maintenance 7. and a business proposal is put forth with a very general plan for the project and some cost estimates. 2. Maintenance is an activity that commences after the software is developed. All the candidate systems are then weighed and the best alternative of all these is selected as the solution system. Following topics describes the above mentioned phases: 1. 5. The main aim of preliminary analysis is to identify the problem. the software often must be upgraded and enhanced to include more "features" and provide more services. need for the new or the enhanced system is established. Feasibility for a system means whether it is practical and beneficial to build that system. So manual processing of leave application is becoming very difficult. Once the business proposal is accepted or the contract is awarded. These can be combined into a feasibility analysis phase. Suppose in an office all leave-applications are processed manually. For feasibility analysis. 4. There is often an installation (also called implementation) phase.

Feasibility is evaluated from developer and customer's point of view. 4. Another issue in this regard is the legal feasibility of the project. 1. and operational. economical. Technical feasibility: Can the development of the proposed system be done with current equipment. It consists of the following: • • • Statement of the problem Details of findings Findings and recommendations in concise form Once the feasibility study is done then the project is approved or disapproved according to the results of the study. Determination of System's requirements: Analysis phase in SDLC . Is building the new system really going to benefit the customer. 3. Legal feasibility: It checks if there are any legal hassle in developing the system. The feasibility of the system is evaluated on the three main issues: technical. Does the customer have the required money to build that type of a system? All these issues are covered in the feasibility study of the system. Economic feasibility: Are there sufficient benefits in creating the system to make the costs acceptable? An important outcome of the economic feasibility study is the cost benefit analysis. existing software technology. Developer sees whether they have the required technology or manpower to build the new system. a report detailing the nature and scope of the proposed solution. Operational feasibility: Will the system be used if it is developed and implemented? Will there be resistance from users that will undermine the possible application benefits? The result of the feasibility study is a formal document. and available personnel? Does it require new technology? 2. If the project seems feasible and desirable then the project is finally approved otherwise no further work is done on it.

in which a group of people including representatives of the client critically review the requirements specification. The phase ends with validation of requirements specified in the document. the problem could be automating an existing manual process. Validation is often done through requirement review. and that need to perform many different tasks. There are two major activities in this phase . the Software Requirement Specification (SRS) is a document that completely describes what the proposed software should do without describing how the system will do it?. or other formally imposed document. Once the problem is analyzed and the essentials understood. The requirements documents must specify all functional and performance requirements. The basic goal of the requirement phase is to produce the Software Requirement Specification (SRS). outputs and any required standards. which describes the complete external behavior of the proposed software. some specification language has to be selected (example: English. 1. actually reflect the actual requirements or needs. regular expressions. the parts of which must be automated. The developer usually does not understand the client's problem domain. This task is complicated by the fact that there are often at least two parties involved in software development . the capabilities that system. This document is similar to a . 2. or developing a completely new automated system. For example. should have. The basic purpose of validation is to make sure that the requirements specified in the document. and all design constraints that exits due to political. tables. Note that in software requirements we are dealing with the requirements of the proposed system. The output of this phase is the design document. the goal of the requirement specification phase is to produce the software requirement specification document. The emphasis in requirements Analysis is on identifying what is needed from the system and not how the system will achieve it goals. or a combination of the two. and security reasons. or a combination of these). This phase is the first step in moving from problem domain to the solution domain. the formats of inputs. which is yet to be developed.problem understanding or analysis and requirement specification in problem analysis. Regardless of how the requirements phase proceeds. Such analysis typically requires a thorough understanding of the existing system. A condition or capability that must be met or possessed by a system to satisfy a contract. For requirement specification in the form of document. particularly testing and maintenance. standard. Software Requirement or Role of Software Requirement Specification (SRS) IEEE (Institute of Electrical and Electronics Engineering) defines as. and that all requirements are specified. For large systems which have a large number of features. economic environmental.a client and a developer. that is. It is because we are dealing with specifying a system that does not exist in any form that the problem of requirements becomes complicated.Requirements Analysis is done in order to understand the problem for which the software system is to solve. the requirement phase ends with a document describing all the requirements. which has to be adequately bridged during requirements Analysis. the requirements must be specified in the requirement specification document. In other words. In most software projects. and has a major impact on the later phases. and the client often does not understand the issues involved in software systems. The person responsible for the requirement analysis is often called the analyst. specification. A condition of capability needed by a user to solve a problem or achieve an objective. the analyst has to understand the problem and its context. understanding the requirements of the system is a major task. The design of a system is perhaps the most critical factor affecting the quality of the software. System/Software Design Phase in SDLC The purpose of the design phase is to plan a solution of the problem specified by the requirement document. This causes a communication gap.

If the design is not specified in some executable language. Hence. The use of abstraction allows the designer to practice the "divide and conquer" technique effectively by focusing one part at a time. During this phase further details of the data structures and algorithmic design of each of the modules is specified. The logic of a module is usually specified in a high-level design description language. these documents completely specify the design of the system. A large system cannot be handled as a whole. Most methodologies focus on system design. the goal of coding should be to reduce the testing and maintenance effort. Development of Software . which is independent of the target language in which the software will eventually be implemented. during coding the focus . and how they interact with each other to produce the desired results. in system design the attention is on what components are needed. abstraction is used. the aim of this phase is to implement the design in the best possible manner. testing and maintenance. and so for design it is partitioned into smaller systems. a designer needs to understand only the abstractions of the other parts with which the part being designed interacts. Typically. which is sometimes also called top-level design. a clear understanding of the interaction is essential for properly designing the part. The design activity is often divided into two separate phase-system design and detailed design. During the design phase. A well written code reduces the testing and maintenance effort. aims to identify the modules that should be in the system. The goal of the coding phase is to translate the design of the system into code in a given programming language . the design activity focuses on one part of the system at a time. While working with the part of a system. output formats. In system design the focus is on identifying the modules. the design phase ends with verification of the design. the specifications of these modules. For a given design. Since the part being designed interacts with other parts of the system. Together. When partitioning is used during design. Abstraction is a concept related to problem partitioning. Since the testing and maintenance cost of software are much higher than the coding cost. A design methodology is a systematic approach to creating a design by application of set of techniques and guidelines. An abstraction of a system or a part defines the overall behavior of the system at an abstract level without giving the internal details. and is used later during implementation. Like every other phase. At the end of system design all the major data structures. In other words. That is they specify the different modules in the system and internal logic of each of the modules. The two basic principles used in any design methodology are problem partitioning and abstraction. the verification has to be done by evaluating the design documents. without worrying about the details of other parts. whereas during detailed design the focus is on designing the logic for each of the modules. file formats.Coding Stage/Phase in SDLC Once the design is complete. often two separate documents are produced. at least two design reviews are held-one for the system design and one for the detailed and one for the detailed design. One for the system design and one for the detailed design.blue print or plan for the solution. most of the major decisions about the system have been made. For this. as well as the major modules in the system and their specifications are decided. During detailed design the internal logic of each of the modules specified in system design is decided. while in detailed design how the components can be implemented in software is the issue. System design. One way of doing this is thorough reviews. The coding phase affects both testing and maintenance profoundly.

do. which is used very heavily). There are many methods available for verifying the code. Rather. The final output . Its basic function is to detect errors in the software. In this a module is tested separately and is often performed by the coder himself simultaneously with the coding of the module. which lists all the different test cases. the specified test cases are executed and actual result is compared with the expected output. and specify guidelines for testing. and iteration (while . the entire system is not tested together. allocates the resources. code reviews. That is. An important concept that helps the understandability of programs is structured programming. Consequently. the statements are executed in the sequence in the program. For this reason. The focus is on testing the external behavior of the system. on the real life data of the client. integration testing is performed. acceptance testing is performed to demonstrate to the client. and then test cases are decided based on the specifications of the system or module.entry . For testing to be successful. Structural testing is used for lower levels of testing and functional testing is used for higher levels. After the coding phase. The purpose is to execute the different parts of the module code to detect coding errors. The test plan specifies manner in which the modules will integrate together. code reading. system testing is performed. Examples of such methods are data flow analysis. program text should be organized as a sequence of statements. During integration of modules. a test case specification document is produced. the output is a document that is usually textual and non-executable. Finally. this phase is often referred to as "coding and unit testing". Testing is an extremely critical and time-consuming activity. proper selection of test cases is essential. but also errors introduced during the previous phases. Thus. testing (a method that involves executing the code. During requirement analysis and design. In the coding phase. The starting point of testing is unit testing. The goal of this testing is to detect design errors. Some methods are static in nature that is. The output of this phase is the verified and unit tested code of the different modules. Structural testing is sometimes called "glass box testing". System Testing Testing is the major quality control measure employed during software development . Here the system is tested against tech system requirements to see if all the requirements are met and the system performs as specified by the requirements.until etc).should be on developing programs that are easy to write. while focusing on testing the interconnection between modules. the different modules are tested separately. There are two different approaches to selecting test cases-functional testing and structural testing. this form of testing is also called "black box testing". that will be used for testing. a few single-entry-single-exit constructs should be used. In structural testing the test cases are decided based on the logic of the module to be tested. which are then integrated themselves eventually form the entire system. It requires proper planning of the overall testing process. This plan identifies all the testing related activities that must be performed and specifies the schedule. together with the expected outputs. repeat . the goal of testing is to uncover requirement. Consequently. After the system is put together. In functional testing the software for the module to be tested is treated as black box. Frequently the testing process starts with the test plan. These constructs includes selection (if-then-else). This implies that testing not only has to uncover errors introduced during coding. For structured programming. and during execution.single exit constructs. Then for different test units. the separation of the system. different levels of testing are employed. design or coding errors in the programs. computer programs are available that can be executed for testing phases. This testing of modules is called "unit testing". Simplicity and clarity should be strived for. After this the modules are gradually integrated into subsystem. that is they do not involve execution of the code. during the coding phase. The goal of structured programming is to arrange the control flow in the program. With these constructs it is possible to construct a program as sequence of single . During the testing of the unit.

This occurs. As we have mentioned earlier. Maintenance activities related to fixing of errors fall under corrective maintenance. regression testing is done. Each test report contains the set of such test cases and the result of executing the code with these test cases The error report describes the errors encountered and action taken to remove those errors. There might also be changes in the input data. Furthermore. All these require modification of the software. and resetting of the old parts that were not changed. but also the related documents. The introduction of a software system affects the work environment. Maintenance also needed due to a change in the environment or the requirements of the system. the system environment and output formats. they have to be removed. The two major forms of maintenance activities are adaptive maintenance and corrective maintenance. removing all the faults before delivery is extremely difficult and faults will be discovered long after the system is installed. needs of the maintainers are not kept in mind. Consequently maintenance resolves around understanding the existing software and spares most of their time trying to understand the software that they have to modify. Regression testing involves executing old test cases to test that no new errors have been introduced. testing the new parts (changes). Maintenance work is based on existing software. maintenance involves understanding the existing software (code and related documents). requirements that are not identified during requirement analysis phase will be uncovered. understanding the effects of change. since the experience with the software helps the user to define the needs more precisely.Implementation and Maintenance in Software Life Cycle Maintenance includes all the activity after the installation of software that is performed to keep the system operational. which creates new software. often after the system is installed and the users have had a chance to work with it for sometime. software often has design faults. as compared to development work. Understanding the software involves not only understanding the code. Removing errors is one of the activities of maintenance. System testing is explained further in the chapter entitled "Testing and Quality Assurance" SDLC . and is in operation for five to twenty years before it is withdrawn. Error Distribution with Phases in Software Development Life Cycles A typical software product may take months to a few years for development. To test whether those aspects in the system that are not supposed to be modified are operating as they were before modification. the effects of the change have to be clearly understood by the maintainer since introducing undesired side effects in the system during modification is easier. little support documents are produced during development to aid the maintainer. As these faults are detected.of the testing phases is to the text report and the error report. Thus. The maintenance activities related to such modification fall under adaptive maintenance. making the changes . Since often during development. The complexity of the maintenance task is coupled with the neglect of maintenance concerns during development which makes maintenance the most cost effective activity in the life of a software product. During the modification of the software. For software. the cost of development . This change in environment often changes what is desired from the system. or set of such reports (one of each unit is tested).both to the code and documents. It is generally agreed that for large systems.

Both testing and maintenance depend heavily in the design and coding of the software.50% The exact number will differ with organization and the type of the project.30% Coding . then the design and the code will get affected. maintenance cost can be reduced if maintenance concerns are kept in forefront during development. the issues in our minds should be "can the design be easily tested". for enhancing or for updating the software. The first is that the goal of design and coding should reduce the cost of design and coding. These require alternate designs and may increase the cost of the design and coding. it is generally accepted that the cost of maintenance is likely to be higher than the development cost. as it is the oldest activity in software development and offers many opportunities for committing errors. The cost of maintenance is the cost of modifying the software due to residual faults in the software. 30/70 or even lower. coding and testing. Therefore. if corrected after coding is completed. Since maintenance depends critically on the software characteristics that are decided during development.20% Testing . it is imperative that the software be developed so the maintenance is easy. the greater the delay in detecting an error after it occurs. but should be to reduce the cost of testing and maintenance. The reason for this is fairly obvious. The development cost. and are often not at all concerned with the maintenance. a typical distribution of effort with the different phases is Requirement . However the cost of correcting different phases is not the same and depends on when the error is detected and corrected. at the expense of increasing design and coding cost. As one old expect.50% As we can see. Hence. errors occur throughout the development process. the more expensive it is to correct it. Therefore. during design and implementation. One of the reasons why this is often not done is that the development cost is done by the developers while maintenance is often done by the users. If there is an error in the requirements. It is now realized that errors can occur at any stage during development. design. Error that occur during the requirements phase. But this additional costs pay dividends in the later phases. the development cost is the total cost incurred before the product delivery.20% Design . Error Distribution The notion that programming is the central of activity during software development is largely because normally programming has been considered to be difficult task and sometimes an "art". A typical distribution of error occurrences by is Requirement Analysis . However. for reduction in overall cost of software. This cost is spread over the operational years of the software. Another consequence of this kind of thinking is the belief that errors largely occur during programming.10% Design . There are some observations we can make from the data given above.20% Coding . can cost many times more than correcting the error during the requirements phase itself. The ratio of development to maintenance cost has been variously suggested as 40/60. However.is the incurred during requirement analysis. and "can it be easily modified". the developers do not have much incentive for increasing the development effort in order to reduce the maintenance cost. . Software engineers generally agree that the total cost of maintenance is more than the cost of development of software. And these costs can be considerably reduced if the software is designed and coded to make testing and maintenance easier.

the sequence of activities that will produce such software. which states that the phases are organized in a linear order. the coding that is done would require both the design and the code to be changed there by increasing the correction. reliance on testing as the primary source for error detection. In a software development effort the goal is to produce high quality software. the system is installed. Error detection and correction should be a continous proces that is done throughout software development. The development process is. Once the programming is completed. A software development life cycle model is broken down into distinct activities. 3. 1. Waterfall Software Development Life Cycle Model Prototyping Software Development Life Cycle Model Iterative Enhancement Model The Spiral Model Object Oriented Methodology Dynamic System Development Method Waterfall Software Development Life Cycle Model The simplest software development life cycle model is the waterfall model. 2. On the successful demonstration of the feasibility analysis. After this the regular operation and maintenance of the system takes place. will also result in unreliable software. A project begins with feasibility analysis. 5. the requirements analysis and project planning begins. Different types of Software Development Life Cycle Models (SDLC) A Software Development Life Cycle Model is a set of activities together with an ordering relationship between activities which if performed in a manner that satisfies the ordering relationship that will produce desired product. the code is integrated and testing is done. Software Development Life Cycle Model is an abstract representation of a development process . A software development life cycle model specifies how these activities are organized in the entire software development effort.To correct the error. . 4. In terms of the development phases what this means is that we should try to validate each phase before starting with the next. 6. therefore. We discuss each software development life cycle model in detail. The design starts after the requirements analysis is done. In reality. On succeeful completion of testing. The following figure demonstrates the steps involved in waterfall life cycle model. due to the limitations of testing. And coding begins after the design is done. sometimes testing is the sole point where errors are detected. Besides the cost factor. So we should attempt to detect errors in the previous phase and should not wait until testing to detect errors. This is not often practiced.

which must be produced in order to produce a successful product. There are a number of intermediate outputs. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system. Some certification mechanism has to be employed at the end of each phase.This brings us to the need for configuration control or configuration management. project planning. The certified output of a phase that is released for the best phase is called baseline. Linear ordering of activities has some important consequences. First. detailed design. Project Output in a Waterfall Model As we have seen. However. when the activities of a phase are completed. coding and unit testing. The configuration management ensures that any changes to a baseline are made after careful review. keeping in mind the interests of all parties that are affected by it. Therefore. system integration and testing. For a successful project resulting in a successful product. the activities performed in a software development project are requirements analysis. the output is the code. From this point of view. changing requirements cannot be avoided and must be faced. Any different ordering of the phases will result in a less successful software product. These changes have to made in a controlled manner after evaluating the effect of each change on the project. Since changes performed in the output of one phase affect the later phases. the output of a project employing the waterfall model is not just the final program along with documentation to use it. This is usually done by some verification and validation. The outputs of the earlier phases are often called intermediate products or design document. there should be an output product of that phase and the goal of a phase is to produce this product. The set of documents that forms the minimum that should be produced in each project are: . the output of a software project is to justify the final program along with the use of documentation with the requirements document. all phases listed in the waterfall model must be performed anyway.The Waterfall Software Life Cycle Model With the waterfall model. test plan and test results. that might have been performed. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall model. For the coding phase. Another implication of the linear ordering of phases is that after each phase is completed and its outputs are certified. The consequences of the need of certification is that each phase must have some defined output that can be evaluated and certified. system design. to clearly identify the end of a phase and beginning of the others. project plan. these outputs become the inputs to the next phase and should not be changed or modified. design document.

Prototyping Software Life Cycle Model The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. coding and testing. Development of the prototype obviously undergoes design. but for general marketing. in which the requirements are likely to be determined largely by developers . By using this prototype. determining the requirements is difficult. a throwaway prototype is built to understand the requirements. This is clearly not desirable for such expensive software. the . This is possible for systems designed to automate an existing manual system. an then later enhance the system in phase. 4. But for absolutely new system. The review reports are the outcome of these reviews. it is quite likely that the final software will employ a hardware technology that is on the verge of becoming obsolete. Easy to explain to the user Stages and activities are well defined Helps to plan and schedule the project Verification at each stage ensures early detection of errors / misunderstanding Limitations of the Waterfall Life Cycle Model The waterfall model assumes that the requirements of a system can be frozen (i. This is often done for software products that are developed not necessarily for a client (where the client plays an important role in requirement specification). since other certification means are frequently not available. In some situations it might be desirable to first develop a part of the system completely. having unchanging (or changing only a few) requirements is unrealistic for such project.e. In order to certify an output product of a phase before the next phase begins. as the user himself does not know the requirements. The basic idea here is that instead of freezing the requirements before a design or coding can proceed. Freezing the requirements usually requires choosing the hardware (since it forms a part of the requirement specification). The waterfall model stipulates that the requirements should be completely specified before the rest of the development can proceed. reviews are often held. But each of these phases is not done very formally or thoroughly. basedline) before the design begins. This prototype is developed based on the currently known requirements. Reviews are formal meeting to uncover deficiencies in a product. 2. Therefore.) Review reports Except for the last one. A large project might take a few years to complete. 3. Reviews are necessary especially for the requirements and design phases. installation manual etc. then due to the speed at which hardware technology is changing.• • • • • • • • Requirement document Project plan System design document Detailed design document Test plan and test report Final code Software manuals (user manual. If the hardware is selected early. • Advantages and limitations of the waterfall life cycle model Advantages and limitations of the Waterfall Model Advantages of Waterfall Life Cycle Models 1. these are all the outputs of the phases.

client can get an "actual feel" of the system. Disadvantages 1. 5. Prototyping Model The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. The basic idea is that the software should be developed in increments. the users get a better understanding of the system being developed. since the interactions with prototype can enable the client to better understand the requirements of the desired system. Leads to implementing and then repairing way of building systems. as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. Advantages of Prototyping 1. this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. On the other hand. However. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. The goal is to provide a system with overall functionality. the cost of testing and writing detailed documents are reduced. where each increment adds some . It provides a better system to users. some argue that prototyping need not be very costly and can actually reduce the overall development cost. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system. Users are actively involved in the development 2. the experience of developing the prototype will very useful for developers when developing the final system. These factors help to reduce the cost of developing the prototype. 4. The process model of the prototyping approach is shown in the figure below. 2. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraint can be met or that algorithms can be developed to implement the requirements. Errors can be detected much earlier as the system is mode side by side. Since in this methodology a working model of the system is provided. 3. Iterative Enhancement Life Cycle Model The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. The prototype is usually not complete systems and many of the details are not built in the prototype. In addition. Quicker user feedback is available leading to better solutions. Practically.

simulation and prototyping. In the first step of iterative enhancement model. Next. The spiral has many cycles. and should be simple enough to be completely understood. Furthermore. The tasks in the list can be including redesign of defective components found during analysis. The process is iterated until the project control list is empty. The Iterative Enhancement Model The project control list guides the iteration steps and keeps track of all tasks that must be done. at the time the final implementation of the system will be available. the software is developed by keeping in mind the risks. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement. A project control list is created which contains. in an order. An advantage of this approach is that it can result in better testing. and which forms a useful and usable system. implementation phase and analysis phase. since testing each increment is likely to be easier than testing entire system like in the waterfall model. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. . Each entry in that list is a task that should be performed in one step of the iterative enhancement process. The process involved in iterative enhancement model is shown in the figure below. the increments provide feedback to the client which is useful for determining the final requirements of the system. Each step consists of removing the next step from the list. Finally the next stage is planned. coding and testing the implementation. The structure of the spiral model is shown in the figure given below. Designing the implementation for the selected task. These three phases are called the design phase. The Spiral Life Cycle Model This is a recent model that has been proposed by Boehm. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints.functional capability to the system until the full system is implemented. The next step is to develop strategies that resolve the uncertainties and risks. At each step extensions and design modifications can be made. a simple initial implementation is done for a subset of the overall problem. Selecting tasks in this manner will minimize the chances of errors and reduce the redesign work. all the tasks that must be performed to obtain the final implementation. The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives and constraints. as in prototyping. This will also involve identifying uncertainties and risks involved. This project control list gives an idea of how far the project is at any given step from the final system. This step may involve activities such as benchmarking. and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. the activities in this model can be organized like a spiral. As the name suggests.

the concept is equally applicable to systems. its performance or userinterface risks are considered more important than the program development risks. verify. if the program development risks dominate and previous prototypes have resolved all the user-interface and performance risks. hardware. Spiral Model Description The development spiral consists of four quadrants as shown in the figure above Quadrant 1: Determine objectives. simulation-oriented or some other approach.The next step is determined by remaining risks. including plans for the next cycle. Quadrant 4: Plan next phases. An important feature of the model is that each cycle of the spiral is completed by a review. prototype-oriented. Quadrant 3: Develop. identify. On the other hand. The next step may be evolutionary development that involves developing a more detailed prototype for resolving the risks. The spiral model works for developed as well as enhancement projects. alternatives. the next step will follow the basic waterfall approach. is oriented toward software development. . resolve risks. The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented. next-level product. Although the spiral. For example. and constraints. let’s briefly address each one. To better understand the scope of each spiral development quadrant. which covers all the products developed during that cycle. for example. and training. Quadrant 2: Evaluate alternatives. as depicted.

the basic “waterfall” approach may be employed—meaning concept of operations. and risk constraints. support. and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral. more detailed prototyping may need to be added before progressing to the next quadrant. Dr. As a result. Next-Level Product If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs. Resolve Risks Engineering activities performed in this quadrant select an alternative approach that best satisfies technical. next-level product are performed. the option of writing specifications would be addressed but not exercised. reuse. . verify. Each cycle of the model culminates with a technical review that assesses the status.Quadrant 1: Determine Objectives. Investigate constraints imposed on the alternatives—namely technology. design.e. The outcome of the evaluation determines the next course of action. activities to develop. The focus here is on risk mitigation. progress. and Constraints Activities performed in this quadrant include: 1. Alternatives. the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) . support.. 2. and risk. maturity. Quadrant 2 (Evaluate alternatives. If appropriate. Verify. benchmarking. . external and internal) risks remain. analytic modeling. and resolve risks) is performed. resolves critical operational and/or technical issues (COIs/CTIs). reference checking. risk. If critical operational and/or technical issues (COIs/CTIs) such as performance and interoperability (i. alternatives. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. . cost. cost. incremental development approaches may also be applicable. functionality. administering user questionnaires. merits. Quadrant 2: Evaluate Alternatives. and ability to accommodate change. and procure/ modify 3. schedule. of development efforts to date. integration. This may involve prototyping. development. Boehm notes that if the alternative chosen is “operationally useful and robust enough to serve as a low-risk base for future product evolution. schedule. . Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations. Boehm describes these activities as follows: . or combinations of these and other risk resolution techniques. simulation. and constraints are understood. Once the system or product’s objectives. Establish an understanding of the system or product objectives—namely performance.” This brings us to Quadrant 3. and test of the next system or product iteration. technology. Identify. Quadrant 4: Plan Next Phases The spiral development model has one characteristic that is common to all models—the need for advanced technical planning and multidisciplinary reviews at critical staging or control points. Quadrant 3: Develop. Investigate implementation alternatives—namely design. identify. procure. .

In simple terms. At this stage the implementation details are not taken care of. how they behave over time or in response to events. and implementation of the system. Object-oriented analysis has the analyst look at all the objects in a system. The basic steps of system designing using Object Modeling may be listed as: • • • • System Analysis System Design Object Design Implementation System Analysis As in any other system development model. These objects exist in nature. an object-oriented view has come into picture for creation of computer software. manipulated and created. Based on this system study. the analyst prepares a model of the desired system. in that it also follows a sequential process of system designing but with a different approach. Object-Oriented development requires that object-oriented techniques be used during the analysis. organized. Therefore. While designing the system as a set of interacting subsystems.Object Oriented Methodology Life Cycle Model We live in a world of objects. in business. System Design System Design is the next development stage where the overall architecture of the desired system is decided. This methodology asks the analyst to determine what the objects of the system are. In this phase. An object-oriented approach to the development of software was proposed in late 1960s. and in the products that we use. the coding of the system is done. Only the model of the system is prepared based on the idea that the system is made up of a set of interacting objects. and how the system needs to manipulate the objects. system analysis is the first phase of development in case of Object Modeling too. This model is purely based on what the system is required to do. . and even an account is an object. The important elements of the system are emphasized. their commonalties. a chequebook is an object. Once this is done. first the system to be developed is observed and analyzed and the requirements are defined as in any other method of system development. in man-made entities. For example in case of a Banking System. combined. difference. Object Oriented Process The Object Oriented Methodology of Building Systems takes the objects as the basis. They can be categorized. Object Modeling is somewhat similar to the traditional approach of system designing. a customer is an object. and what responsibilities and relationships an object has to other objects. described. The system is organized as a set of sub systems interacting with each other. Object Modeling is based on identifying the objects in a system and their interrelationships. For this. the developer interacts with the user of the system to find out the user requirements and analyses the system to understand the functioning. the objects in the required system are identified. the analyst takes care of specifications as observed in system analysis as well as what is required out of the new system by the end user. Once this is done.

Of all these. To implement this concept. a bigger system may also be seen as a set of interacting smaller subsystems that in turn are composed of a set of interacting objects. A new type of class can be defined using a similar existing class with a few new features. but it only creates a template.As the basic philosophy of Object-Oriented method of system analysis is to perceive the system as a set of interacting objects. pen type etc. The designer also decides on whether the classes need to be created from scratch or any existing classes can be used as it is or new classes can be inherited from them. its shape and size etc. the details of the system analysis and system design are implemented. As already discussed. For example. Inheritance: Inheritance is another important concept in this regard. similarly. This would save the developers time and effort as the classes already existing are reused without much change. the characteristics of concern to the system under observation are picked up and the class definition is made. we can define a data type called pen and then create and use several objects of this data type. Object Design In this phase. in the Object Designing phase of the Development process. the attributes of concern might be the pen color. where a set of similar objects are observed and their common characteristics are listed. For instance. Class: A class is a collection of similar objects. the stress lies on the objects comprising the system and not on the processes being carried out in the system as in the case of traditional Waterfall Model where the processes form the important part of the system. Let us here deviate slightly from the design process and understand first a few important terms used in the Object-Oriented Modeling. whereas a pen class for a manufacturing firm would be containing the other dimensions of the pen like its diameter. The class defines the basic attributes and the operations of the objects of that type. while defining a pen class for a stationery shop. in case of objects certain data types are predefined. This is known as abstraction. The attributes of no concern to the system are left out. the process-based structural programming is not used. instead objects are created using data structures. Abstraction: Classes are built on the basis of abstraction. ink color. Just as every programming language provides various data types and various variables of that type can be created. Defining a class does not define any object. While designing the system. This concept is used to apply the idea of reusability of the objects.. a class vehicle can be defined with the basic functionality of any vehicle and a new class called car can be derived out of it with a few modifications. The Objects identified in the system design phase are designed. the designer decides onto the classes in the system based on these concepts. The abstraction of an object varies according to its application. It is a template where certain basic characteristics of a set of objects are defined. For objects to be actually created instances of the class are created as per the requirement of the case. Object Oriented Philosophy is very much similar to real world and hence is gaining popularity as the systems here are seen as a set of interacting objects as in the real world. Implementation . Coming back to our development process. This concept is known as creating a class. Here the implementation of these objects is decided as the data structures get defined and also the interrelationships between the objects are defined. For instance.

Programmer has to spend less time and effort and can concentrate on other aspects of the system due to the reusability feature of the methodology. OO modeling provides many benefits. all the three models together describe the complete functional system.During this phase. Among other benefits. The methodology supports and uses three basic Models: • • • Object Model . While the Object Model is most important of all as it describes the basic element of the system. The databases are made and the complete system is given a functional shape. This model observes all the objects as static and does not pay any attention to their dynamic nature. every object exhibits some characteristics and behavior. As compared to the conventional system development techniques. Inheritance . considering a Window on the screen as an object. the analyst makes use of certain models to analyze and depict these objects. Dynamic Model . This is achieved by defining classes and putting them into a library of classes where all the classes are maintained for future use.The classes once defined can easily be used by other applications. Because of this. Data Hiding . This describes the flow of data and the changes that occur to the data throughout the system. it can be picked up directly from there.Encapsulation is a technique that allows the programmer to hide the internal functioning of the objects from the users of the objects. the size of the window gets changed when resize button of the window is clicked. Here the clicking of the button is an event to which the window responds by changing its state from the old size to the new size. It portrays the changes occurring in the states of various objects with the events that might occur in the system. Therefore. Some of these are: • Reusability .This model describes the objects in a system and their interrelationships. the class objects and the interrelationships of these classes are translated and actually coded using the programming language decided upon.This model basically describes the data transformations of the system.The concept of inheritance helps the programmer use the existing code in another way. For example. While developing systems based on this approach. Functional Model . . The objects in the system are immune to requirement changes. allows changes more easily. When observed closely. where making small additions to the existing classes can quickly create new classes. Whenever a new class is needed the programmer looks into the library of classes and if it is available. The complete OO methodology revolves around the objects identified in the system. The objects recognize and respond to certain events. The systems designed using this approach are closer to the real world as the real world functioning of the system is directly mapped into the system designed using this approach. there are all the benefits of using the Object Orientation.This model depicts the dynamic aspects of the system. the objects. it is easier to produce and understand designs. Encapsulation separates the internal functioning of the object from the external functioning thus providing the user flexibility to change the external behavior of the object making the programmer code safe against the changes made by the user. • • • • Advantages of Object Oriented Methodology • • Object Oriented Methodology closely represents the problem domain.

. Dynamic System Development Method (DSDM) Dynamic System Development Method is another approach to system development. in that it can be used with both structured analysis and design approach or objectoriented approach. This method is particularly useful for the systems to be developed in short time span and where the requirements cannot be frozen at the start of the application building. It provides nice structures for thinking and abstracting and leads to modular design. the development continues. Only if the RAD is found as a justified approach for the desired system. New applications can use the existing modules. as the name suggests. Dynamic System Development Method (DSDM) has a five-phase life cycle as given the following figure Feasibility study In this phase the problem is defined and the technical feasibility of the desired application is verified. develops the system dynamically. Object Oriented Methodology approach is more natural. thereby reduces the development cost and cycle time. which.• • Object Oriented Methodology designs encourage more re-use. Apart from these routine tasks. In Dynamic System Development Method (DSDM). design and development phase can overlap. Like at one time some people will be working on some new requirements while some will be developing something for the system. In Dynamic System Development Method (DSDM). Whatever requirements are known at a time. it is also checked whether the application is suitable for Rapid Application Development (RAD) approach or not. This methodology is independent of tools. analysis. The Dynamic System Development Method (DSDM) is dynamic as it is a Rapid Application Development method that uses incremental prototyping. requirements evolve with time. design for them is prepared and design is developed and incorporated into system.

there are four possibilities. so return to business study phase and repeat the whole process A less essential part of the project was missed out due to time constraint and so development returns to the functional model iteration. taking the feedback and incorporating the changes. Functional Model Iteration This is one of the two iterative phases of the life cycle. so no further development required. Implementation Implementation is the last and final development stage in this methodology. The prototype is improved through demonstration to the user. . Once this is done. Therefore. the current step need be completed only enough to move to the next step. as a result.Business study In this phase the overall business study of the desired system is done. Some non-functional requirement was not satisfied. At the end of this phase. The two phases. may simultaneously continue. so development returns to the design and build iterations phase. as depicted by figure : • • • • Everything was delivered as per the user demand. so any further work would have been wasted. The systems designed using Rapid Application Development (RAD) should be highly maintainable. A new functional area was discovered. since it can be finished in a later iteration. The software components designed during the functional modeling are further refined till they achieve a satisfactory standard. Dynamic System Development Method (DSDM) assumes that all previous steps may be revisited as part of its iterative approach. The product of this phase is a tested system ready for implementation. The maintainability level of the system is also identified here so as to set the standards for quality control activities throughout the development process. This premise is that the business requirements will probably change anyway as understanding increases. as they are based on the incremental development process . In this phase the users are trained and the system is actually put into the operational environment. The main focus in this phase is on building the prototype iteratively and getting it reviewed from the users to bring out the requirements of the desired system. This cycle is repeated generally twice or thrice until a part of functional model is agreed upon. There is no clear line between these two phases and there may be cases where while some component has flown from the functional modeling to the design and build modeling while the other component has not yet been started. The business requirements are specified at a high level and the information requirements out of the system are identified. The end product of this phase is a functional model consisting of analysis model and some software components containing the major functionality Design and Build Iteration This phase stresses upon ensuring that the prototypes are satisfactorily and properly engineered to suit their operational environment. the basic architectural framework of the desired system is prepared.

DSDM ensures rapid deliveries. However. There should be enough expertise available for hardware and software for doing analysis. Both of the above factors result in reduced project costs preliminary Analysis The main objectives of preliminary analysis is to identify the customer's needs. This does not follow the fundamental assumption of making a perfect system the first time. This approach has proved to be very useful under time constraints and varying requirements. the analyst should report the findings to management. perform economic and technical analysis. there can be an analysis team. • How much time should be spent on it? As such. the following questions arise. contractual obligation are few parameters on which it should be decided. perform cost benefit analysis and create system definition that forms the foundation for all subsequent engineering works. there are no rules or formulas available to decide on this. application field. complexity. resources are fixed while the requirements are allowed to change. While performing analysis. Well an experienced well-trained analyst should do it. Request Clarification Feasibility Study Technical Feasibility Economic Feasibility Cost Benefit Analysis Operational Feasibility Legal Feasibility Request Approval Estimation Lines of code (LOC) FP Estimation Empirical Estimation COCOMO . the time is fixed.According to this approach. the time is taken as a constraint i.e. but provides a usable and useful 80% of the desired system in 20% of the total development time. For large project. with recommendations outlining the acceptance or rejection of the proposal. size. • After the preliminary analysis. It is not very common. DSDM Model Limitations • It is a relatively new model. Other major question that arises is who should do it. evaluate system concept for feasibility. end-use. DSDM Model Advantages • • • Active user participation throughout the life of the project and iterative nature of development improves quality of the product. So it is difficult to understand.

But no such methods exists for such systems for which manual processes do not exist (example. As the information in their minds is by very nature not formally stated or organized. The requirement analyst has to identify the requirements by talking to these people and understanding their needs. Now. When inputs from multiple people are to be gathered. it is also very error prone. as is more often the case. Some of the difficulties is the scope of this phase. A condition or capability that must be met or possessed by a system to satisfy a contract. identifying requirements necessarily involves specifying what some people have in their minds (or what will come to their minds when they visualize it). which are frequently added when automating an existing manual process. that is. The main assumption was that the developers understood the problem clearly when it was explained to them. Feasibility Study . should have. Software Requirement (or) Role of Software Requirement Specification IEEE (Institute of Electrical and Electronics Engineers) defines as. these inputs are likely to be inconsistent as well. As system grew more complex. 1. Regardless of how the requirements phase proceeds. The software project is initiated by clients needs. A condition of capability needed by a user to solve a problem or achieve an objective 2. standard. These needs are in the minds of various people in the client organization. It is because we are dealing with specifying a system that does not exist in any form that the problem of requirements becomes complicated. the need for a more rigorous requirement analysis phase arose. generally informally. The software requirement specification phase translates the ideas in the minds of the client (the input). and is likely to be incomplete. for large systems. Thus. into a set of formal documents (the output of the requirement phase). many of the needs can be understood by observing the current practice. as the emphasis was on coding and design. capabilities that system.Case study : Library Management system Request Clarification / Software Requirement Specification (SRS) Software Requirement Specification (SRS) is the beginning point of the software development activity. Software requirement is one such area to which little importance was attached in the early days of software development. which hopefully are complete and consistent. the output of the phase is a set of formally specified requirements. software for a missile control system) or for a "new features". Many software engineers believe that the software engineering discipline is the weakest in this critical area. requirements analysis is perhaps the most difficult and intractable activity. it became evident that the goals of the entire system could not be easily comprehended. which is yet to be developed. the input to the software requirement specification phase is inherently informal and imprecise. specification or other formally imposed document. Note that in software requirements we are dealing with the requirements of the proposed system. the Software Requirement Specification (SRS) is a document that completely describes what the proposed software should do without describing how the system will do it?. In situations where the software is to automate a currently manual process. Thus. Therefore.

Often. Although the costs of conducting a study may seem high. and not outside investors. If these ideas make it to the operational stage. Why Prepare Feasibility Studies? Developing any new business venture is difficult. Many cooperative business projects are quite expensive to conduct. It is an analysis of possible solutions to a problem and a recommendation on the best solution to use. Most ideas. The projects involve operations that differ from those of the members’ individual business.A feasibility study is a preliminary study undertaken before the real work of a project starts to ascertain the likelihood of the project's success. The proposed project usually requires both risk capital from members and debt capital from banks and other financiers to become operational. A feasibility study is defined as an evaluation or analysis of the potential impact of a proposed project or program. Feasibility studies permit planners to outline their ideas on paper before implementing them. or even merge with another business. they are relatively minor when compared with the total project cost. It involves evaluating how the solution will fit into the corporation. whether from a cooperative or invest or owned business. Lenders typically require an objective evaluation of a project prior to investing. build or remodel facilities. can decide whether an order processing be carried out by a new system more efficiently than the previous one. change methods of operation. Potential members should evaluate the returns of a cooperative project to see how it would affect the returns of all of their business operations. A feasibility study assists decision makers whenever they need to consider alternative development opportunities. Applying the lessons gained from a feasibility study can significantly lower the project costs. The small initial expenditure on a feasibility study can help to protect larger capital investments later. are the most common. add new products. so the appropriate economic rate of return for a cooperative project may be lower than those required by projects of investor-owned firms. Evaluations of a new business venture both from new groups and established businesses. cooperative businesses’ operations involve risks with which the members are unfamiliar. The acceptable level of return and appropriate risk rate will vary for individual members depending on their personal situation. but not the only usage. The study presents the risks and returns associated with the project so the prospective members can evaluate them. The feasibility study will contain extensive data related to financial and operational impact and will include advantages and disadvantages of both the current situation and the proposed plan. It. The feasibility study is based on extensive research on both the current practices and the proposed project/program and its impact on the selected organization operation. most fail within the first 6 months. A feasibility study is conducted to assist decision-makers in determining whether or not to implement a particular project or program. for example. A feasibility study conducted by someone without a vested interest in the project outcome can provide this assessment. This can reveal errors in project design before their implementation negatively affects the project. Studies can help groups decide to expand existing services. do not develop into business operations. they must determine if it can be economically viable and then decide if investment advantages outweigh the risks involved. Feasibility studies are useful and valid for many kinds of projects. Cooperatives serve the needs and enhance the economic returns of their members. . Before the potential members invest in a proposed business project. There is no "magic number" or correct rate of return a project needs to obtain before a group decides to proceed. The study allows groups to preview potential project outcomes and to decide if they should continue. Taking a project from the initial idea through the operational stage is a complex and time-consuming effort.

Feasibility studies contain standard technical and financial components. Although few businesses would not benefit from a computerized system at all. will provide data upon which to base a decision. the process of carrying out this feasibility study makes the purchaser/client think carefully about how it is going to be used. Emphasis can be placed on various sections of an individual feasibility study depending upon the needs of the group for whom the study was prepared. equipment. Technological advancement may have rendered the current system redundant.). The feasibility study is conducted to assist the decision-makers in making the decision that will be in the best interest of the school food service operation. The study also shows the sensitivity of the business to changes in these basic assumptions. In this various aspects like whether it is technically or economically feasible or not. wages etc. The business is expanding.What Is a Feasibility Study? This analytical tool used during the project planning process shows how a business would operate under a set of assumptions — the technology used (the facilities. Cooperative members use it to be successful in enhancing their personal businesses. The exact appearance of each study varies. so a study conducted for a cooperative must address how the project will impact members as individuals in addition to how it will affect the cooperative as a whole. The perceived objectivity of the evaluation is an important factor in the credibility placed on the study by potential investors and financiers. so they must be designed to serve everyone’s needs. as discussed in more detail later in this report. After request clarification. allowing it to cope with extra work load. which could be used because: • • • • • The current system may no longer suit its purpose. analyst proposes some solutions. This depends on the industry studied. So depending upon the aspect on which feasibility is being done it can be categorized into four classes: • • • • Technical Feasibility Economic Feasibility Operational Feasibility Legal Feasibility . etc. For these reasons. the critical factors for that project. The extensive research. A feasibility study could be used to test a new working system. After that for each solution it is checked whether it is practical to implement that solution. production process. and the budget.) and the financial aspects (capital needs. outside consultants conduct most studies. the creation of the study requires a strong background both in the financial and technical aspects of the project. The study is the first time in a project development process that the pieces are assembled to see if they perform together to create a technical and economically feasible concept. conducted in a non-biased manner. This is done through feasibility study. Customers are complaining about the speed and quality of work the business provides. Also. the methods chosen to conduct the study. Most studies have multiple potential uses. The feasibility study evaluates the project’s potential for success. cost of goods. with one exception. Feasibility studies for a cooperative are similar to those for other businesses. volume. Competitors are not winning a big enough market share due to an effective integration of a computerized system.

programmers. In economic feasibility.Software and hardware Once the technical feasibility is established. then they will welcome the change and the new system. Economic Feasibility. • • Is there an alternate way to do the job in a better way? What is recommended? Technical Feasibility. It should answer the following issues. In economic feasibility. the most important is cost-benefit analysis. economic feasibility of the proposed system is carried out.The outcome of the feasibility study should be very clear. • • Whether the required technology is available or not Whether the required resources are available . Whether there will be resistance from users that will effect the possible application benefits? The essential questions that help in testing the operational feasibility of a system are following. Economic analysis is used for evaluating the effectiveness of the proposed system. Cost Benefit Analysis Operational Feasibility Operational feasibility is mainly concerned with issues like whether the system will be used if it is developed and implemented. it is an analysis of the costs to be incurred in the system and benefits derivable out of the system. it is important to consider the monetary factors also. cost benefit analysis is done in which expected costs and benefits are evaluated. Since it might happen that developing a particular system may be technically possible but it may require huge investments and benefits may be less. the system can be judged to be economically feasible. . Legal Feasibility Technical Feasibility In technical feasibility the following issues are taken into consideration. testers & debuggers . As the name suggests. Have the users been involved in the planning and development of the project? Early involvement reduces the probability of resistance towards the new system.Manpower. Economic Feasibility For any system if the expected benefits equal or exceed the expected costs. Operational Feasibility. Click on the link below which will get you to the page that explains what cost benefit analysis is and how you can perform a cost benefit analysis. • • • Does management support the project? Are the users not happy with current business practices? Will it reduce the time (operation) considerably? If yes. For evaluating this.

personnel. The development cost is basically the costs incurred during the various stages of the system development. it carries risks.• Will the proposed system really benefit the organization? Does the overall response increase? Will accessibility of information be lost? Will the system effect the customers in considerable way? Legal Feasibility It includes study concerning contracts. and supply costs. However. facility. Cost benefit determines the benefits and savings that are expected from the system and compares them with the expected costs. Some examples are : • • • • • Personnel Equipment Supplies Overheads Consultants' fees Cost and Benefit Categories In performing Cost benefit analysis (CBA) it is important to identify cost and benefit factors. • • Wages Equipment . Cost and benefits can be categorized into the following categories. The development costs are one time investment whereas maintenance costs are recurring. In a broad sense the costs can be divided into two types 1. It usually involves comparing alternate investments. There are several cost factors/elements. These are hardware . benefits and risks. because in some cases an estimate can be wrong. Each phase of the life cycle has a cost. Since after developing that application it provides the organization with profits. Cost benefit analysis helps to give management a picture of the costs. Profits can be monetary or in the form of an improved working environment. violations. And the project might not actually turn out to be beneficial. Development costsDevelopment costs that are incurred during the development of the system are one time investment. The cost of an information system involves the development cost and maintenance cost. Cost Benefit Analysis Developing an IT application is an investment. and legal other traps frequently unknown to the technical staff. liability. operating.

Operating costs. . disks. Facility costs: Expenses incurred during the preparation of the physical site where the system will be operational. and air conditioning.2. direct or indirect. Supply costs: These are variable costs that vary proportionately with the amount of use of paper. ribbons.Costs Benefits can be accrued by : . conveyance allowance. e. These expenditures include salaries. This includes the maintenance of the system. or .both The system will provide some benefits also. That can be in the form of maintaining the hardware or application programs or money paid to professionals responsible for running or maintaining the system. lighting. . the first task is to identify each benefit and assign a monetary value to it. and it's peripherals. and the like. etc. These should be estimated and included in the overall cost ofthe system.g. or . Operating costs: Operating costs are the expenses required for the day to day running of the system. Wages Supplies Overheads Another classification of the costs can be: Hardware/software costs: It includes the cost of purchasing or leasing of computers costs involves required software costs. Software Personnel costs: It is the money. Benefits can be tangible or intangible. flooring. These can be wiring. acoustics. Benefits We can define benefit as Profit or Benefit = Income .Increasing income.Decreasing costs. In cost benefit analysis. other benefits such as health insurance. spent on the people involved in the development of the system.

For example. if the proposed system that can handle more transactions say 25% more than the present system then it is direct benefit. maintenance. software cost are all tangible costs. Insurance. They are identified and measured. Depreciation of hardware. salaries for professionals. The purchase of hardware or software. Fixed costs don't change. heat. Fixed benefits don't change. Performing Cost Benefit Analysis (CBA) Example: Cost for the proposed system ( figures in USD Thousands) . and employee salaries are example of tangible costs. Direct costs are having rupee value associated with it. light. personnel training. Insurance. Further costs and benefits can be categorized as Tangible or Intangible Costs and Benefits Tangible cost and benefits can be measured. improved company status. Fixed or Variable Costs and Benefits Some costs and benefits are fixed. etc are all fixed costs. Benefits are also tangible or intangible. Variable benefits are realized on a regular basis. They are proportional to the work volume and continue as long as system is in operation. producing error free output such as producing reports are all tangible benefits. Recurring period may be weekly or monthly depending upon the system. For example. Direct benefits are also attributable to a given project. Costs whose value cannot be measured are referred as intangible costs. Direct or Indirect Costs and Benefits From the cost accounting point of view. more customer satisfaction. Variable costs are incurred on regular basis. Hardware costs. The cost of breakdown of an online system during banking hours will cause the bank lose deposits. etc are all intangible benefits. air conditioning are all indirect costs. Whereas improved response time.. Both tangible and intangible costs and benefits should be considered in the evaluation process. the costs are treated as either direct or indirect.The two main benefits are improved performance and minimized processing costs. Indirect costs result from the operations that are not directly associated with the system.

Benefit for the propose system

Profit = Benefits - Costs = 300, 000 -154, 000 = USD 146, 000 Since we are gaining , this system is feasible. Steps of CBA can briefly be described as: • • • • •
Estimate the development costs, operating costs and benefits Determine the life of the system When will the benefits start to accrue? When will the system become obsolete? Determine the interest rate This should reflect a realistic low risk investment rate.

Select Evaluation Method
When all the financial data have been identified and broken down into cost categories, the analyst selects a method for evaluation. There are various analysis methods available. Some of them are following. 1. 2. 3. 4. 5. 6. Present value analysis Payback analysis Net present value Net benefit analysis Cash-flow analysis Break-even analysis

Present value analysis:
It is used for long-term projects where it is difficult to compare present costs with future benefits. In this method cost and benefit are calculated in term of today's value of investment. To compute the present value, we take the following formula Where,

i is the rate of interest & n is the time

Example: Present value of $3000 invested at 15% interest at the end of 5th year is calculates as P = 3000/(1 + .15)5 = 1491.53 Table below shows present value analysis for 5 years Estimation Future Cumulative present Present Value Value Value of Benefits 3000 3000 3000 3000 3000 2608.69 2268.43 1972.54 1715.25 1491.53 2608.69 4877.12 6949.66 8564.91 10056.44

Year 1 2 3 4 5

Net Present Value : NPA
The net present value is equal to benefits minus costs. It is expressed as a percentage of the investment. Net Present Value= Costs - Benefits % = Net Present Value/Investments Example: Suppose total investment is $50000 and benefits are $80000 Then Net Present Value = $(80000 - 50000 80000 - 50000 ) = $30000 % = 30000/80000 =.375

Break-even Analysis:
Once we have determined what is estimated cost and benefit of the system it is also essential to know in what time will the benefits are realized. For that break-even analysis is done. Break -even is the point where the cost of the proposed system and that of the current one are equal. Break-even method compares the costs of the current and candidate systems. In developing any candidate system, initially the costs exceed those of the current system. This is an investment period. When both costs are equal, it is break-even. Beyond that point, the candidate system provides greater benefit than the old one. This is return period.

Fig. 3.1 is a break-even chart comparing the costs of current and candidate systems. The attributes are processing cost and processing volume. Straight lines are used to show the model's relationships in terms of the variable, fixed, and total costs of two processing methods and their economic benefits. B' point is break-even. Area after B' is return period. A'AB' area is investment area. From the chart, it can be concluded that when the transaction are lower than 70,000 then the present system is economical while more than 70,000 transaction would prefer the candidate system.

Cash-flow Analysis:
Some projects, such as those carried out by computer and word processors services, produce revenues from an investment in computer systems. Cash-flow analysis keeps track of accumulated costs and revenues on a regular basis.

Request Approval
Those projects that are evaluated to be feasible and desirable are finally approved. After that, they are put into schedule. After a project is approved, it's cost, time schedule and personnel requirements are estimated. Not all project proposals turn out to be feasible. Proposals that don't pass feasibility test are often discarded. Alternatively, some rework is done and again they are submitted as new proposals. In some cases, only a part is workable. Then that part can be combined with other proposals while the rest of it is discarded. After the preliminary analysis is done and if the system turns out to be feasible, a more intensive analysis of the system is done. Various fact finding techniques are used for this purpose. In the next chapter, we'll look into these fact finding techniques. When we do the economic analysis, it is meant for the whole system. But for the people who develop the system, the main issue is what amount of their effort goes into the building the system. So how much should be charged from the customer for building the system. For this, estimation is done by the developer. In estimation, software size and cost is estimated. Now we will study, the various techniques used in the software estimation.

Software Estimation

human. Indirect measures of the software process include measurement of resulting features of the software.Software measurements. In the starting era of computers . just like any other measurement in the physical world.can affect the ultimate cost of software and effort applied to develop it. These methods can be categorized into Decomposition techniques and Empirical Estimation models. Finally the consolidated estimate is the clubbed up entities resulting from all the individual components. From statement of software scope software is decomposed into problem functions that can each be estimated individually.) and then the cost and effort estimation of each component can be achieved in a stepwise manner. quality. it is important and necessary to understand software scope and estimate its size. can be categorized into Direct measures and Indirect measures. execution speed. technical. In order to make a reliable cost and effort estimation there are lot of techniques that provide estimates with acceptable mount of risk. It is assumed that there is a very small probability that the actual size results will fall outside the optimistic or pessimistic value. Spess stand for the pessimistic estimate. Cost overruns can be disastrous for the developer. Too many variables . . Further Empirical Estimation models are used to offer a valuable estimation approach. But. Direct measures of the software process include measurement of cost and effort applied. software cost was a small proportion of the cost for complete computer based system. According to Decomposition techniques the software project is broken into major functions and software engineering activities (like testing. Sm stands for the most likely estimate. maintainability etc. Two methods under this head are Lines of Code (LOC) and Function Points (FP) Estimation. In contrast. • • • • EV stand for the estimation variable. Direct measures of a product include Lines Of Code (LOC) produced. Before an estimate for software is made. complexity. efficiency. environmental. Lines of Code (LOC) Lines of Code (LOC) method measures software and the process by which it is being developed. An expected value is then computed using the following formula. Lines of Code (LOC) is a direct approach method and requires a higher level of detail by means of decomposition and partitioning. reliability. where. Today software is the most expensive element in many computer-based systems. and defects reported over some set of time. Sopt stand for the optimistic estimate. memory size. coding etc. Estimation is not an exact science. and political . Indirect measures of the product include its functionality. LOC or FP (estimate variables) is then calculated for each function. An error in estimation of software didn't have a major impact. Function Points (FP) is indirect an approach method where instead of focusing on the function it focuses on the domain characteristics (discussed later in the chapter). which is based on historical data (experience). Large cost estimation errors can make the difference between profit and loss.

In case for return. historical LOC or FP data are applied and person months. 2. costs etc are calculated using the following formula. KLOC stand for no. Defects stand for Total Number of errors discovered Example: Problem Statement: Take the Library management system case. Major software functions identified. Person-month stand for is the time(in months) taken by developers to finish the product.Once the expected value for estimation variable has been determined. Productivity = KLOC / Person-month Quality = Defects / KLOC Cost = $ / LOC Documentation = pages of documentation / KLOC Where. 3. of lines of code (in thousands). Issuing and returning will require some validity checks. Software developed for library will accept data from operator for issuing and returning books. 1. Other operations include maintaining database and generating reports at regular intervals. All the interactions will be through user interface . User interface Database management Report generation For user interface Sopt : 1800 Sm : 2000 Spess : 4000 EV for user interface EV = (1800 + 4*2000 + 4000) / 6 EV = 2300 For database management Sopt : 4600 Sm : 6900 Spess : 8600 EV for database management EV = (4600 + 4*6900 + 8600) / 6 EV = 6800 For report generation Sopt : 1200 Sm : 1600 Spess : 3200 . For issue it is required to check if the member has already issued the maximum books allowed. if the member is returning the book after the due date then fine has to be calculated.

Incidental 2 . Is performance critical? 5. Are master files updated on-line? 12. we use FP = count-total X [ 0. Are data communications required? 3.Moderate 3 .2 Fi(I= 1 to 14) are complexity adjustment values based on response to questions(1-14) given below. Are there distributed processing functions? 4. Albrecht first proposed function point method. outputs. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. To compute function points. Is the internal processing complex? 10. Five information domain characteristics are determined and counts for each are provided and recorded in a table. Each entry can be simple. a complexity value is associated with each count. or inquiries complex 9.65 + 0. Are the inputs. Is the system designed for multiple installations in different organizations? 14. The constant values in the equation and the weighing factors that are applied to information domain are determined empirically. Will the system run in an existing. count-total is the sum of all entries obtained from fig. average or complex. Depending upon these complexity values is calculated. which is a function oriented productivity measurement approach. Does the system require on-line entry? 7. Fi 1. files. 3. Is the application designed to facilitate change and ease of use by the user? Rate each factor on a scale of 0 to 5 0 .Average 4 . Does the system require reliable backup and recovery? 2. • • • • • Number of user inputs Number of user outputs Number of user inquires Number of files Number of external interfaces Once the data have been collected.01 * SUM(Fi) ] Where. heavily utilized operational environment? 6. Is the code designed to be reusable? 11.No influence 1 .Essential .EV for report generation EV = (1200 + 4*1600 + 3200) / 6 EV = 1800 FP Estimation Function oriented metrics focus on program "functionality" or "utility". Are conversion and installations included in the design? 13.Significant 5 .

quality. cost and documentation can be evaluated. Factor Backup Recovery Data Communication Distributed processing Value 4 1 0 . Once function points have been calculated. productivity.2 . Productivity = FP / person-month Quality = defects / FP Cost = $ / FP Documentation = pages of documentation / FP Fig 3.Computing function-point metrics Example: Same as LOC problem Information Domain Values Number of Inputs Number of Outputs Number of Inquiries Number of Files Number of external interfaces Count Total est Account 10 8 12 6 2 Opt likely Pess 4 4 5 3 2 10 7 12 6 2 16 16 19 9 3 wt 4 5 4 10 7 FP Account 40 40 48 60 14 202 Complexity weighing factors are determined and the following results are obtained.Count-total is sum of all FP entries.

64 person-month Total Cost = Development cost * person-month = 8000 * 3.01 * sum(Fi) ] FPestimated = 206 From historical data. empirically derived formulas are used to predict data that are a required part of the software project-planning step.2per FP Empirical Estimation In this model. productivity is 55.5 FP/person-month and development cost is $8000 per month.64 =$29100 Cost per FP = Cost/FP = 29100/202 = $144.65 + . project duration. or other pertinent project data.5 = 3. There are four classes of resource models: • Static single-variable models • Static multivariable models • Dynamic multivariable models • Theoretical models .Perfomance Critical Existing Operating Environment On-line data entry Input transaction over multiple screens Master file updated online Information domain values complex Internal processing complex Code design for reuse Conversion/Installation in design Multiple installations Application designed for change Sum ( Fi ) Estimated number of FP : 3 2 5 5 3 3 2 0 1 3 5 37 FPestimated = count-total * [0. These equations are used to predict effort (in person-month). Resource models consist of one or more empirically derived equations. The empirical data are derived from a limited sample of projects. Productivity = FP/ person-month person-month = FP/Productivity = 202/55.

The basic version of the Constructive Cost Model.... Model 1: Basic COCOMO model is static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code. effort (if estimated). resource requirements are projected as a function of time. COCOMO can be applied to the following software project's categories. Organic mode: . Model 2: Intermediate COCOMO model computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product. Barry Boehm introduced COCOMO models. Where ei is the ith software characteristics and ci1. each step may be divided into tasks. etc.. design... In dynamic multivariable models... Further. Resource could be effort. personnel. A typical model of this category takes the form Resource = c11e1 + c12e2+ . like analysis. There is a hierarchy of these models. resources are defined in a series of time steps that allocate some percentage of effort (or other resource) to each step in the software engineering process.ci2 are empirically derived constants for the ith characteristics. or COCOMO. presented in the next section is an example of a static-variable model. If the model is derived empirically.. project duration. A theoretical approach to dynamic multivariable modeling hypothesizes a continuous "resource expenditure curve" and from it. Model 3: Advanced COCOMO model incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step. COnstructive COst MOdel is static single-variable model. COnstructive COst MOdel COCOMO. derives equations that model behavior of the resource. and project attributes. Estimated characteristics is line of code.. or lines of software documentation.. c1 and c2 are constants derived from data of past projects... or other software characteristics. hardware ... staff size.Static single-variable model has the following form Resource = c1 X (estimated characteristics c2) Where. Static multivariable models also use historical data to derive empirical relationships. COCOMO..

Embedded mode: Software projects that must be developed within a set of tight hardware. and operational constraints. The team has a good application experience work to a set of less than rigid requirements. flight control software for aircraft. 1. 2. The ab and cb and the exponents bb and db are given in the table below. . c) Size of application database. Hardware attributes a) Run-time performance constraints. software. These attributes can be grouped together into four categories. Product attributes a) Required software reliability. Here the team has mixed experience to meet a mix of rigid and less than rigid requirements. For example. A thermal analysis program developed for a heat transfer group is an example of this. The basic COCOMO model takes the form where. KLOC is the estimated number of delivered lines ( expressed in thousands ) of code for project. b) Volatility of the virtual machine environment. A transaction processing system with fixed requirements for terminal hardware and database software is an example of this. Basic COCOMO The basic model is extended to consider a set of "cost drivers attributes".These projects are very simple and have small team size. Semi-detached mode: These are intermediate in size and complexity. E is the effort applied in person-month. b) Complexity of the project. D is the development time in chronological month.

d) Application experience. c) Required development schedule. 4.Case study: Library Management System .2.9 E = ab (KLOC)exp(bb) = 2. d) Memory constraints. b) Use of software tools.5)exp(. b) Software engineer capability.9 to 1.38) = 9. 3.4. Example : Problem Statement same as LOC problem refer section 3.1 KLOC = 10. Each of the 15 attributes is rated on a 6-point scale that ranges from "very low" to "very high" in importance or value. Project attributes a) Application of software engineering methods.4(10. Personnel attributes a) Analyst capability.c) Required turnaround time. Based on the rating. The product of all multipliers results in an effort adjustment factor (EAF). Intermediate COCOMO Preliminary Analysis .5(29.9)exp(1. E = ai(LOC)exp(bi) X EAF Where.04 months The intermediate COCOMO model takes the following form. Typical values of EAF range from 0. E is the effort applied in person-months. c) Virtual machine experience. an effort multiplier is determined from the tables given by Boehm. e) Programming language experience. The coefficient ai and the exponent bi are given in the table below.05) = 29.5 person-month D = Cb(E)exp(db) = 2. LOC is the estimated number of delivered lines of code for the project.

it is very difficult for the analyst to know what exactly the customer wants. It will have modules for handling issue and return functions. the analyst visits the library site and meets the staff of the library. books. So our solution is technically feasible. Library staff is going to be the end user of the system. It will also store the data relating to books.trained manpower. Solution: The desired system can be implemented with Oracle RDBMS in the back end with Visual Basic as the front end. So manpower is readily available. First technical feasibility is done. is big IT Company. Analyst asks various questions from the staff so that the exact requirements for the system become clear. Technical feasibility doesn't guarantee if the system will be beneficial to the system if developed. What they stated in their request was that they needed a system for their library that could automate its various functions. generating reports. In our case. From this request statement. The software is available with the company since it has already worked with the same software earlier also. Oracle and Visual Basic . For this economic feasibility is done. the analyst proposes solution system. and suppliers in some structured way. for their request for the new automated system. the data will be maintained in a relational way. So in order to get information about the system. Major issues in technical feasibility are to see if the required resources. It has developed similar projects using Oracle and VB. we now apply to it the concepts that we have studied in this chapter. Preliminary Analysis: Request Clarification. the analyst is able to identify the following requirements for the new system: • • • • • • Function for issue of books Function for return of books that can also calculate the fine if the book is returned after the due date Function for performing different queries Report generation functions Function for maintaining account s Maintaining the details for members. It has a special team that is formed to work in this combination of projects. Feasibility Study Now the next stage in preliminary analysis is to determine whether the proposed solution is practical enough to be implemented. ABC Software Ltd. that is. performing checks. . and suppliers in a structures way. Now that the requirements are known.Again referring back to our "Library management system " discussed in earlier chapters. For this feasibility study is done. and maintaining accounts. software and hardware are available or not. members. And provide faster response. From this activity. First the management of the library approached this ABC Software Ltd.

First task that is done in economic analysis is to identify the cost and benefit factors in the system proposed. In our case, the analyst has identified the following costs and benefits. First task that is done in economic analysis is to identify the cost and benefit factors in the system proposed. In our case, the analyst has identified the following costs and benefits. Costs Cost Software Oracle Visual Basic Windows Server 2003 Windows XP professional Hardware Central Computer Client Machine Development Analyst Developer Training Data Entry Warranty ( 1 month) Professional Total Cost Benefits According to new policy: A member is required to pay Rs 500 for a half yearly membership and Rs 1000 for a year membership. Expected increase in number of members : 75 per month 40 new members for 1 year and 35 new members for half year Free collected from new members in one year = 12 (40 * 1000 + 35 * 500) = Rs 6,90,000 = 4 * 6,90,000 = 27,60,000 20,000 1 20,000 5,55,000 100,000 50,000 50,000 50,000 20,000 20,000 5,000 1 4 1 1 2 1 1 100,000 50,000 50,000 50,000 40,000 20,000 5,000 50,000 30,000 15,000 5,000 1 1 1 4 50,000 30,000 15,000 5,000 Cost per unit Quantity Total Cost

For four years

Now using Net present value method for cost benefit analysis we have, Net present value( or gain ) = Benefits - Costs = 27,60,000 - 5,55,000 = 22,10,000 = Net present value / investment = 22,10,000 / 5,55,000

Gain %

= 4.018 Overall Gain = 401.8 % in four year

For each year First year Investment Benefit Net present value for first year Gain % = 5,50,000 = 6,90,000 = 6,90,000 - 5,50,000 = 1,40,000 = 1,40,000 / 5,50,000 = .254 = 25.4 % in first year

Second Year Investment Benefit Net present value for second year Gain % = 5,50,000 = 13,80,000 = 13,80,000 - 5,50,000 = 8,30,000 = 830000/550000 = 1.50 = 150 % at the end of second year Third Year Investment Benefit Net present value for third year = 5,50,000 = 20,70,000 = 20,70,000 - 5,50,000 = 15,20,000 = 1520000/550000 = 2.76 = 276 % at the end of third year Fourth Year Invetment Benefit Net Present Value for fourth year = 550,000 = 2760000 = 2760000 - 550000 = 2210000

Gain %

Gain %

= 2210000 / 550000 = 4.018 = 401.8 % at end of fourth year

From CBA we have found that it is economically feasible since it is showing great gains(about 400%). After economic feasibility, operational feasibility is done. In this, major issue is to see if the system is developed what is the likelihood that it'll be implemented and put to operation? Will there be any resistance from its user? It is very clear that the new automated system will work more efficiently and faster. So the users will certainly accept it. Also they are being actively involved in the development of the new system. Due to this fact they will know the system well and will be happy to use a new improved system. So our system is operationally feasible. After the feasibility study has been done and it is found to be feasible, the management has approved this project. So further work can de done that is the design of system that will be discussed in the later chapters.

Fact Finding and Decision Making Techniques
At the end of this chapter you would be able to know the various fact finding techniques and you would also be able to understand techniques used for decision making.

Fact finding techniques Getting Cooperation What Facts to Gather How to Initiate Fact Gathering? Common Sense Protocol - Where to Get the Facts? Introduction to the Employee at the Work Place Recording Technique A Caution about Instant Improvements How to Keep the Data Organized? Various kinds of techniques used in fact techniques Interviews Structured Interviews Unstructured Interviews Questionnaires Open-Response Based Questionnaires Closed-Response Based Questionnaires Record Reviews On-site Observation Decision making and Documentation Decision Trees Decision Tables

Structured English Data Dictionary CASE Tools Fact Finding Techniques . Not quite so obvious is the fact that eliminating tasks does not have to mean reducing staff. In this stage.Where to get the facts? • Introduction to the employee at the work place • Recording technique • Keeping the data organized Getting Cooperation in Fact Finding The cooperation of operating people is crucial to fact gathering. often eliminating tasks. When organizations are truly commited to their people . Various kinds of techniques are used and the most popular among them are interviews. no one is in a better position to improve the work than the people who know it first hand. Two people can go into the same area to gather facts and experience entirely different results. This session outlines some of the things a person can do to achieve the latter. record reviews. Of course process improvements will change the work. This is obvious. The analyst needs data about the requirements and demands of the project undertaken and the techniques employed to gather this data are known as fact-finding techniques. managers and customers. And. Various methods are used for this and these are known as fact-finding techniques. questionnaires. the functioning of the system is to be understood by the system analyst to design the proposed system. not the least of which could be further improvement work. We get this by commitment to developing improvements that simultaneously serve the interests of employees while they serve the interests of owners. it is naïve to expect them to help.Case Study : Library Management System Fact Finding Techniques Fact-finding is an important activity in system investigation. Process improvement projects should be undertaken with the object of making the company as good as it can be. However. The analyst needs to fully understand the current system. It covers: • Getting user cooperation • Choosing the facts to gather • Initiating fact gathering • Common sense protocol . The key to obtaining cooperation is two-way loyalty and trust. if the operating people believe that the purpose of the fact gathering is to make changes in the work with the object of reducing staff. Each of these techniques is further dealt in next pages. not reducing staff. One spends weeks and gets incomplete and misleading data. case tools and also the personal observations made by the analyst himself. It can mean having resources available at no additional cost to do any number of things needed by the organization. The other is finished in a few hours and has complete and solid facts.

Another social change that is very important to process improvement is the increasing acceptance of involving operating level employees in the improvement process. Young people are being exposed to computers early in their education. if we then asked “How do you do that? How do you know what to write as the diagnosis?”. This was certainly not so a generation ago. This article is written for companies that want to capture the enormous potential of enthusiastic employees embracing new technology. The popularization of computers stands high among the factors that have contributed to recent social change. Knowing what facts not to gather is just as important as knowing the facts that are needed. For instance. in effect “to gather all of the facts”. Those people possess the organizational memory. when. It has become rather commonplace to form teams of operating people. Distinguishing Between Facts and Skill No matter how carefully facts are gathered. as they need it. They have accumulated detailed knowledge that is available to them alone. Facilitators learn how to study work processes. When executives say this sort of thing publicly but then treat their people as expenses to be gotten rid of at the first opportunity.” However. Along with the increasing acceptance of employee involvement has come a dramatic change in the role of the internal consultant who is learning new skills for working with teams. . It goes like this. why. When they are dumped. But. This article addresses the role of the facilitator who gathers facts about work processes to use with an improvement team. This pattern focuses on the information that is relevant for process improvement and avoids that which is not. There is a pattern to fact gathering that is particularly helpful during process improvement. The facilitator follows a work process as it passes through departmental boundaries and prepares an As-is Chart. Facilitators are a great help as they gather and organizing the facts of work processes and guide the study of those facts by improvement teams.and their people know this. their people can relax and enthusiastically commit themselves to continuous improvement. How it accomplishes this is not completely obvious. We simply cannot gather it. we would be asking for detail that took years to accumulate. Then an improvement team made up of people from the departments involved in the process studies the As-is Chart and develops a To-be Chart. they will never match the understandings of people who have experienced the work first hand for years. They cannot accomplish this with lip service. The employees of an organization are its most valuable resource. trust dissolves. “I examine the patient and enter a diagnosis on the patient record form. in a fashion that has the feel of common sense. Resources should be maintained and utilized. When a people do not know what they are looking for but attempt to learn everything they can. What Facts to Gather? Knowing what facts you want to gather is crucial to effective fact gathering. that is lip service. we could ask an experienced medical doctor what he does when he visits a patient and expect a general answer like. During those years this detail has been transformed from myriads of individual facts to intuitively available skill. Meanwhile the people and their society have changed significantly in the last few decades. where. A sizeable portion of the work force is comfortable working with computers. They access this knowledge intuitively. It makes use of the standard journalism questions: what. not dumped. they embark on endless and often fruitless effort. they cannot simply explain it to someone else. who and how.

We organize these facts on charts as effective reminders of the steps in a process. When these charts are used by people who are skilled at performing those steps. Our object in process improvement should be to incorporate into our changes the finest skills available. And. we have the knowledge we need for improvement. as needed. So we use teams of the best experienced employees we have. This is the fundamental strength of employee teams. In all lines of work there are differences of skill levels. don’t think for a moment that medical doctors have skill but clerks don’t. Answer it for the very first step of the process and then every time the location changes and you will always know location. It becomes most important when we study the process for improvement but while we are fact gathering. Ask it throughout the fact gathering. Instead we leave this information to be provided by the team. Where – This question deals specifically with location. this question generally means how long. Rather than attempt to gather the skill and settling for simplistic/superficial data we acknowledge that that information is not accessible to the fact gatherer. Just gather facts. Using the Description Pattern The description pattern provides facts. This tells us what the step is and provides the necessary reminder for the team. Later as a team we will question the why of each of them. . It is evaluative rather than descriptive. Therefore: What – Answer this question at every step. making note of all delays and particularly time-consuming steps. We should rarely get into it. not skills. this information is critical to effective improvement. “How?”. Why – This question is different. Who – This question deals specifically with who is performing each step. The information that cannot be provided because it resides in the realm of skill answers the question. The easiest way to collect and display this information is to note every time a new person takes over.The information that the doctor and for that matter all employees can readily provide answers the question. They provide the organizational memory. To do otherwise invites superficiality. In order to get at it. “What?”. However. we must invite the people who have it to join in the improvement development activity. How – This question is important but it changes the fact gathering to skill gathering. When – When dealing with processes. it is premature.

How to Initiate Fact Gathering .) If it is addressed.Follow this pattern and: • You will always show what is happening. It is also helpful for the executive to introduce the analyst and the team members who have been assigned to the project.Public Announcement A public announcement can go a long way towards inspiring cooperation. this is not a guarantee that there will be no loss of employment. It can also provide an opportunity to forestall the anxieties just discussed. (This senior executive should be a person whose authority spans the entire project. there is a pretty certain guarantee that there will be loss of employment. (Or.) . it should be answered directly and forcefully. who is involved in it. (Note. The people working in the areas affected by the project are informed that a five or ten minute meeting will be held at the end of a work shift and that a senior executive has an important announcement. • You will show who is doing the work whenever a person is involved. its objective. • You will show when most of the processing time is occurring." This is not a difficult guarantee for executives who genuinely believe that their people are their most valuable resource.) The meeting includes an announcement of the project. • You won’t bog your readers down with how the individual steps are done. If we fail to improve our work. • You won’t bog your readers down with how the individual steps are done. The issue of staff cuts may be introduced by the executive or may surface as a question. "I guarantee there will be no loss of employment because of work improvement. It is conducted by the executive mentioned above because it is important that statements about the intent of the project be made by someone who has the authority to stand behind his or her words. it may not arise at all in organizations where loss of employment is a non-issue. non flow detail. non flow detail. • You will always show where the work is happening. a request for the support of all employees and an invitation for questions.

Simultaneously. This could be motivated by a sincere desire to help. the quality of the analysis suffers. their anxiety levels will rise all the higher. If someone puts you off repeatedly. Typically you have a number of places to visit. Don't be surprised if the employee appreciates it and is waiting for you with materials set out when you return. When the time is not convenient. the quality of the work suffers and. the employee is seriously inconvenienced but for some reason does not speak up about it. Assume the person is honestly inconvenienced and simply come back later. agree to come back later. in the worst cases. Or. but professionals should not try to slide by. Give the employees the benefit of the doubt. Fantasy replaces reality. Unfortunately.This meeting can also have constructive side effects. everywhere you go people are accommodating you. to be on the safe side it helps to ask. This means going where the work is done and learning from the people who are doing it. Sometimes an analyst arrives in the supervisor's office (a proper practice when visiting a department for the first time) and the supervisor wants to provide the information rather than having the analyst bother the employee who does the work. However. Pick a more convenient time and return. Unfortunately. If there are a number of people doing the same work. Guesses replace facts. each time an analyst settles for collecting data at a distance from reality. And. Regardless of the motive. Where the differences are large the analyst may be seriously embarrassed. interrupting their work to help you do your work. encouraging more non-cooperation. Whatever the reasons. when employees learn (and they will) that secret projects are underway in their areas. Where the differences are small the analyst may slide by. A sensitive analyst may notice this. it separates the analyst from the work place and the person doing the work. don't start suspecting that every time a person puts you off that person is trying to scuttle your work or is a difficult employee. Occasionally this may be for no better reason than that the analyst is too lazy to go where the work is done. Sometimes. the analyst may have been instructed to keep the project a secret because management wants to avoid stirring up concern about job loss. they may simply assume data to avoid having to go after it. one who is particularly knowledgeable should be selected or several may be interviewed. The least you can do is show that you are willing to return the favor. One is that the analyst gets a public introduction to the people from whom he or she will be gathering data. analysts often try to collect data in indirect ways. They are often tempted to use written procedures as their source of data rather than going directly to the operating people. it is still a minor inconvenience as long as you have data to collect elsewhere. Introverts tend to be attracted to research type work and they also tend to find excuses to avoid meeting people. everyone is informed of the reason for the project. "Is this a convenient time?" Coming back later is usually a minor problem. Introduction to the Employee at the Work Place When we are gathering data. however. The supervisor may also want to slant the data. If you do in fact run into a genuinely uncooperative and eventually have to impose a time. it is . making it unnecessary for the analyst to explain this at each interview. major commitments to work methods are made based on faulty premises. Common Sense Protocol . the explanation carries the assurances of the boss rather than an analyst. Or. Occasionally an employee will suggest that it is an inconvenient time and ask that you come back later. Whatever you do. Meanwhile. knowing that every time you accommodate them their debt to you grows.Where to Get the Facts? It is critical that the analyst go where the facts are to learn about them.

an analyst can suggest criticism or even ridicule of the way the work is being done. file clerks. Later we can search out better ways and invite knowledgeable operating people to join us in that effort. Respect Most of the time analysts gather data from people at the operating levels who happen to be junior in status (i. Be careful not to act superior. etc. This is unacceptable behavior. Since the purpose. Don't do it! Go to people to find out what is happening. you must be able to find facts and know how to record them. a sports event. the organization has serious trouble. Record without a preference. As you are about to start the interview the employee may bring up a subject for idle conversation such as the weather. At such times you will also appreciate the project-announcement meeting when the senior executive brought everyone together. • A Caution about Instant Improvements Recording Technique Recording Data The keys to effective data recording are a reverence for facts and knowing how to look for them. One thing you can do to help with this is to set in your mind that wherever you gather data you are talking to the top authority in the organization. without leaving things out. Don't treat this subject lightly. follows its flow. You do not go into data collection with a preconceived notion of the design of the final procedure. is to find out what you are like you will do well to join in the conversation politely and respectfully. messengers. . not to judge what is happening.e. not what should happen or could happen. step by step. This is done by breaking down the procedure into steps and listing them in proper sequence. the flip side of this conditioning leads to treating people in lesser positions with limited respect. Record what is actually happening. You let the facts tell you what shape the procedure should take. We all receive a good deal of conditioning to treat people in superior positions with special respect. data entry clerks). etc. After all. described the importance of the project and asked for support. When later you have them neatly organized and present them for study the facts will assert their authority as they tell their story. on the part of the employee. perhaps with a comment about not wanting to take up too much of the employee's time. Wash the wishes from your eyes and let the facts speak for themselves. The bottom line is that the analyst. People often do this when they first meet in order to size up one another (on a subject that doesn't matter) before opening up on subjects that are important. In various ways. The analyst keeps his or her attention on the subject being charted. The analyst is usually eager to discover opportunities for improvement. smile. First get the facts. a new building renovation. if the top authority on filing in the organization is the CEO.nice to be able to remind that person of how many times you have rescheduled for his or her benefit. with only a few minutes observing the work. and is not distracted by other subjects that could easily lead off onto tangents. The analyst becomes immersed in the data collection. act surprised. shift to the subject of the interview. one flow at a time. Unintentionally. analysts frequently show disrespect for operating employees by implying that the way they do their work is foolish. Then when it has continued for an appropriate amount of time. When something appears awkward or unnecessarily time-consuming the analyst is likely to frown. Unfortunately. is implying that he or she knows how to do it better than a person who has been doing it for years. But.

or deny reality we are hurt. and the five people who do the work each have five years of experience. Save yourself a lot of time and grief by not bothering to record the details of the individual steps and concentrate on the flow of the work. a tape recorder doesn't capture what is seen. It sits. No matter how many times you go back. The better we are able to organize our methods of work in harmony with reality. your results will be deficient in the eyes of these more experienced people. There is no way to match that experience by interviewing. when it comes time to analyze and you invite in those five people. Just note the steps in their proper sequence. We are the ones who care. The other authority system is reality itself. When we are unable to discover reality. while the latter is attended to when time permits. use it after you have left the interview site. they bring with them their twenty-five years of detailed experience. Then. That one goes to them. Reality simply does not care. Voila! You have the big picture and you have the detail. whether we come to grips with the facts or not. For instance. And. Level of Detail As covered earlier while explaining the Description Pattern. Observation A person who has been doing a job for years will have an understanding of the work that goes well beyond his or her ability to describe it. 'Reality is' . A person might be able to show you how the task is done in minutes but could talk about it for hours. it is indifferent to us. but it enforces its will continuously. You have all that you need to discover the opportunities that are there.whether we are in touch with it or not. It is copied. Never mind the detail of how they do the different steps. This part goes there. if you redesign the procedure based solely on your scanty information. Then. If you are going to use a tape recorder. It is not pleased or flattered or thankful when we discover it. It goes here. It is not hurt when we ignore it. One is a social authority set up for the convenience of arranging people and desks and telephones. your data collection will be interminably delayed. Most people are able to speak more comfortably to a human being than to a machine. If you attempt to gather enough information to redesign a procedure without the help of experienced employees. We demonstrate respect for the people who are closest to reality. there will still be new things coming up. Sometimes it is a lot easier for a person to show you what he or she does than to describe it. Don't expect operating people to describe perfectly and don't credit yourself with hearing perfectly. Too often the former is revered and feared and attended to constantly. Yet. Furthermore. the more we prosper.The Authority of the Facts There are two authority systems in every organization. And. they enforce themselves with an unyielding will of steel. dividing up the work and making decisions. you can gather facts but not skill. if you are studying a procedure that crosses five desks. It can help you capture a lot of detail while it is fresh in your mind without causing the employee to be ill at ease. we do our best to carefully record the unvarnished truth. We care when reality crushes us. They do this. We care when reality rewards us. . It doesn't do any good to complain that they didn't tell you about that after you have designed a defective procedure. together they have a quarter of a century of first-hand experience. A demonstration may save a good deal of time. Period! So we enter into data collection with respect for reality.

The credit goes to the fact that the analyst was the first person with the opportunity to follow the records through their flow. 1901-1989. During data collection. The analyst discovers. This may delude the analyst into believing that he or she is really capable of redesigning the procedure without the help of the employees. Their experience is brought into improvement meetings. When the consultants arrive at the workplace trying to glean information from the employees so that they can use it to develop their own answers. an analyst is likely to treasure it. "I am a lot better at this than those employees. they have been doing this work all these years and never made these discoveries. this slight becomes an insult. Mogensen. These discoveries can be clearly beneficial to the organization. The people processing redundant records had no idea that other people were doing the same thing. opportunities for improvement of a certain type surface immediately. These people tend to feel slighted. it is not at all difficult to discover some things that those people are unaware of. things that involve multiple workplaces. there is a clear statement that their experience is not considered of value. "The person doing the job knows far more than anyone else about the best way of doing that job and therefore is the one person best fitted to improve it. It is perceived as support for two judgments. Some of them are outstanding. When the organization then pays consultants who have never done the work to develop improvements. how do you expect the employees to react? Do you think they will be enthusiastic about providing the best of their inside knowledge to these consultants? "Here. Instead we honestly accept the cardinal principle of employee empowerment which is. The only reason these opportunities were not discovered earlier by the employees is that the records had never been followed through the several work areas." and "Employees in general are not capable of seeing these kinds of things. for instance. I found them so quickly." Most people spend a great deal of their lives seeking confirmation of their worth. If any one of those employees had done the same thing. The problem lies in the fact that the analyst discovers them. However. Time-consuming duplication of unneeded records is found. the father of Work Simplification. The analyst is apt to alienate the employees if he or she grabs the credit for these discoveries. that records and reports are being maintained that are destroyed without ever being used. you also reduce the risk of getting distorted or misleading data. These instant improvements simply weren't visible from the limited perspective of one office. When something like this presents itself. "After all. It becomes a personal accomplishment." Both of these judgments are wrong. unaltered. Information is delivered through roundabout channels creating costly delays. I must be very bright." Allan H. let me help you show my boss how much better you can figure out my work than I can?" Really! We don't have to get into this kind of disagreeable competition. If this prompts the analyst to proceed with the entire redesign of the procedure . The people preparing the reports had no idea that the people receiving them had no use for them and were destroying them.Defused resentment When people who have been doing work for years are ignored while their work is being improved. If they get excited about helping to develop the best possible process they will have little reason to distort or withhold the data. By involving operating people in the improvement process. they can be devastating for the relationship between the analyst and the operating employees. the odds are that the results would have been the same. A Caution about Instant Improvements While the analyst cannot match the employees' detailed knowledge of what happens at their workplaces.

Capturing data the same day that it is gathered Using the Tools of the Profession with Discipline In this respect. Professionals have to be able to leave a project frequently and pick it up again without losing ground. The keys to doing this well are: 1. Soon they make these obvious discoveries for themselves and this encourages them to become involved and excited about the project. For instance. 3. Taking credit for these early discoveries can also alienate employees even if they are invited into the improvement activity. An analyst who realizes that the enthusiastic involvement of the team members is much more important than the credit for one idea or another will want to keep quiet about early discoveries until after the employees get a chance to study the chart.without the help of the employees. a three-ring binder may do more good than another certificate. Two things we can do to avoid this are: 1. who are for the moment intensely involved in some activity. Select certain places to put tools and materials and do so consistently. that person may turn out to be yourself. One way of avoiding this is to label and assemble data as if it will be worked on by someone who has never seen it before. there is more professionalism in a well conceived set of file names and directories than there is in a wall full of certificates belonging to a disorganized person. to assume that the clear picture of it that they have today will be available to them tomorrow or a week later or months later. the analyst does this in order to get the credit for the discoveries before the team members spot them. rather than grabbing the credit for the first few ideas in a project that fails for lack of support. it is not uncommon for an analyst who is about to go over a new process chart with a group of users to start by telling them about the discoveries made while preparing the chart. A word about absentmindedness may be appropriate. Instinctively. To find it again they must think back to the last time they used it and then look around where they were at that time. When people are goal-oriented and extremely busy they frequently find themselves looking for something they had just moments before. Develop the discipline of closure so that activities are wrapped up. In doing this the analyst positions himself or herself to provide professional support to knowledgeable employees. he or she will be cut off from hundreds of finer details. For that matter. 2. Believe it or not. This can appear very innocent. any one of which could seriously compromise the effort. but the fact is. Working quickly. How to Keep the Data Organized One important characteristic of professional performance is the ability to work effectively on many assignments simultaneously. 2. A professional simply keeps track of the information that he or she gathers. It makes it theirs. In the end the analyst shares the credit for a successful project. Knowing the tools of the profession and using them in a disciplined manner. . the analyst knows that as soon as the employees see the chart those discoveries will be obvious to them as well. Perhaps the worst enemy of data organization is the tendency on the part of intelligent people. The reason is that when they put it down their mind was on something else and they did not make a record of where they put it.

2. One very essential aspect of conducting the interview is that the interviewer should first establish a rapport with the interviewee. Skill in rapid note-taking can be developed over time. in this regard. the quality of the results suffers. See the rough notes following. Their value as reminders deteriorates rapidly. A simple rule for maximizing the value of these notes is to see that they are carefully recorded in a form that is clear and legible. Speed in recording is important in order to keep up with the flow of information as the employee describes the work. The greatest memory loss usually occurs in the first 24 hours. But. you don't have to write tedious sentences. thank the employee for his or her help. Quite the contrary. Or. when you are actually recording data you do it quickly and keep your attention on the person. This causes further inconvenience to the employee and creates an unprofessional impression. You can help yourself. This does not mean that you rush the interview. . Address the person from whom you are gathering information calmly and patiently. 4. the better. to avoid the risk of guessing. 3. Interviews Questionnaires Record reviews Personal observations made by the analyst himself. If this is postponed. The sooner after the interview this is done. While the interview is fresh in mind these notes can bring forth vivid recall. the same day as the interview. The charting technique provides you with a specialized shorthand (using the symbols and conventions of process charting in rough form). These notes serve as reminders of what has been seen and heard. the analyst goes back to the employee for clarification. at the time of the interview becomes vague or completely forgotten. What was clear. Each of these techniques is further dealt with Interviews Interview is a very important data gathering technique as in this the analyst directly contacts system and the potential user of the proposed system. It should also be taken into account that the interviewee may or may not be a technician and the analyst should prefer to use day to day language instead of jargon and technical terms. Various kinds of techniques used in fact techniques Various kinds of techniques are used and the most popular among them are 1. It also shortens the interview. For process analysis data gathering. and it reduces the probability that something will come up that forces the interview to be terminated prematurely. of course. making the interruption less burdensome to the employee. At the close of the interview it is a good idea to review the notes with the employee. Where the notes are not clear the analyst resorts to guessing about things that were obvious a few days earlier. Details are overlooked or mixed up. Same Day Capture of Data The analyst then returns to his or her office with sketchy notes. holding them in clear view for the employee to see and then. As time passes they lose this power. hastily written. by scheduling to keep the latter part of the work day free for polishing up notes on days when you are collecting data.Working Quickly An analyst should take notes quickly.

Be a good listener. the analyst should be sensitive to their needs and nature. 2. Set the stage for the interview. It is easier to evaluate objectively since answers obtained are uniform. Interviewing should be approached. The interviews are of two types namely structured and unstructured. The advantage of interviews is that the analyst has a free hand and he can extract almost all the information from the concerned people but then as it is a very time consuming method. All interviewees are asked the same set of questions. Also he should try to gather maximum relevant information and data. etc. This method is less time consuming and the interviewer need not be a trained person. Structured Interview 2. 5. 1. As the number and type of respondents vary. as he needs to be beforehand aware of what exactly needs to be asked and to what depth. This is of a much more flexible nature than the structured interview and can be very rightly used to gather general information about the system. 1.For the interview to be a success the analyst should be appropriately prepared. An example of such a question might be "Are you satisfied with the current leave processing methods?" or "Do you think that the manual leave processing procedure be changed with some automated procedure?" Unstructured Interview The unstructured interviews are undertaken in a question-and-answer format. Here the respondents are free to answer in their own words. as logically as possible and from a general point of view the following guides can be very beneficial for a successful interview. On the other hand a high level of structure and mechanical questions are posed which may earn the disliking of . Unstructured Interview Structured Interview Structured interviews are those where the interviewee is asked a standard set of questions in a particular order. which limits the respondents to opt their answer from a set of already prescribed choices. avoid arguments. record reviews. Structured Vs Unstructured Interviews Each of the structured and unstructured interview methods has its own merits and demerits. So the interviewer gets a bigger area to further explore the issues pertaining to a problem. Phrase questions clearly and succinctly. put the interviewee at ease. Establish rapport. The questions are further divided in two kinds of formats for conducting this type of interview. 3. The first is the open-response format in which the respondent is free to answer in his own words. An example of open-response is "Why are you dissatisfied with the current leave processing method?" The other option is of closed-response format. This may also help the analyst to verify and validate the information gained. In this way their views are not restricted. We will consider the structured format first and that too its advantages. Evaluate the outcome of the interview. he should also employ other means such as questionnaires. 4.

The analyst should sensibly design and frame questionnaires with clarity of it's objective so as to do justice to the cost incurred on their development and distribution. Dichotomous i. This form is also used to learn about the feelings. In unstructured interviews the respondents are free to answer and present their views. In that case the respondent can express views on that issue also. The closed questions can be of various types and the most common ones are listed below. Also this kind of structure may not be appropriate for all situations and it further limits the respondent spontaneity. in that case also questionnaires are useful. 3. 2. It is not possible to interview each individual. Ranking scale questions ask the respondents to rank a list of items in the order of importance or preference. and experiences of the respondents.e. It gives an insight in how the people dealing with the system behave and how comfortable are they with it. Just like the interviews and on the same lines questionnaires are of two types i. Closed-Response Based Questionnaires The objective of closed-response questionnaire is to collect the factual information of the system.e. If the anonymity of the respondent is guaranteed by the analyst then the respondent answers the questionnaires very honestly and critically. 1. Also there may be case that some issue might surface spontaneously while answering some other question. But at times. The questionnaire may not yield the results from those respondents who are busy or who may not give it a reasonable priority. .the respondents. Questionnaires are useful when the analyst need to gather information from a large number of people. open-response based and the closed-response based. opinions. Open-Response Based Questionnaires The objective of open-response questionnaire is to gather information and data about the essential and critical design features of the system. Thus the respondent can express their liking for the most favorable one from the possible alternatives. Questionnaires Questionnaires are another way of information gathering where the potential users of the system are given questionnaires to be filled up and returned to the analyst. So the analyst should be careful while conducting interviews. Fill-in-the-blanks. Yes or No type. This information helps in the making the system effective because the analyst can offer subsequent modifications as per the knowledge gained. The open-ended question requires no response direction or specific response. In this case the respondents have to choose from a set of given responses. Also if the time is very short. it may happen that the interview goes in some undesired direction and the basic facts for which the interview was organized do not get relieved.

Open-ended questionnaires are useful when it is required to explore certain situation. 5. Records and reports may have a limitation if they are not up-to-date or if some essential links are missing. So analyst should be careful in gathering in gathering information using this method On-Site Observation On-site observations are one of the most effective tools with the analyst where the analyst personally goes to the site and discovers the functioning of the system. This technique is also time-consuming and the analyst should not jump to conclusions or draw inferences from small samples of observation rather the analyst should be more patient in gathering the information. Multiple-choice questions which offer respondents few fixed alternatives to choose from. Open Vs Closed Questionnaires The basic comparison between the two can be made on the grounds of the format used. The care should be taken to ensure that all the parts of the form are easy to understand for the respondents so that they can answer with clarity. All the changes. thus the analyst gets closer to the system. Closed questions are quick to analyze but typically most costly to prepare but they are more suitable to obtain factual and common information. processes of the system on-site. This method is however less effective for learning about people's perceptions. As an observer.4. Open form offers more flexibility and freedom to the respondents whereas the closed form is more specific in nature. This information is very meaningful as it is unbiased and has been directly taken by the analyst. This can also put light on the requirements of the system and the modifications it has undergone. Closed questionnaires are used when factual information is required. may not be recorded. Here the respondent is asked to rate certain alternatives on some given scale. Rating scale questions are an extension of the multiple-choice questions. hence here the role of an analyst is of an information seeker. which the system suffers. . This exposure also sheds some light on the actual happenings of the system as compared to what has already been documented. It is the job of the analyst to decide which format should be employed and what exactly should be it's objective. One drawback of using this method for gathering information is that practically the functioning of the systems is generally different from the procedure shown in records. Record Reviews Records and reports are the collection of information and data accumulated over the time by the users about the system and it's operations.They also require a lot of time of the analyst for evaluation. feelings and motivations. The analyst may scrutinize the records either at the beginning of his study which may give him a fair introduction about the system and will make him familiar with it or in the end which will provide the analyst with a comparison between what exactly is/was desired from the system and it's current working. the analyst can gain first hand knowledge of the activities. operations.

The decision sequence starts from the root of the tree that is usually on the left of the diagram. This decision tree representation form is very beneficial to the analyst. Documentation comes as an aid in this condition based decision process. This has to be done without harming the logical structure involved. Thus decisions have to be made and set procedures are to be followed as the subsequent actions.Decision Making Documentation Decision-making is an integral part of any business no matter how small. decision tables. which are usually used. Once all of the parameters are objectively represented the decision process becomes much simpler. they keep on varying time to time and object to object and based only on these conditions the decisions are made therefore conditions are also put as decision variables. Therefore at every node of the tree represented conditions are considered to determine which condition prevails before moving further on the path. straightforward and almost error free. analyst also needs to identify and document any decision policies or business rules of the system being designed. thing. The nodes are the decision junctions. which are available to the analyst. simple or big and complex it may be. like decision trees. are decision trees. it is known as a tree. The first advantage is that by using this form the analyst is able to depict all the given parameters in a logical format which enables the simplification of the whole decision process as now there is a very remote chance of committing an error in the decision process as all the options are clearly specified in one of the most simplest manner. A series of decisions are taken. decision tables or structured English. • • • • • Decision Trees Decision Tables Structured English Data Dictionary CASE Tools Decision Trees Decision tree is a tree like structure that represents the various conditions and the subsequent possible actions.e. Tools. It also shows the priority in which the conditions are to be tested or addressed. place. The path to be followed to traverse the branches is decided by the priority of the conditions and the respectable actions. There are various tools and techniques available to the analyst for this. . as the branches are traversed from left to right. Conditions are always in a flux i. Structured English and the various CASE tools. To analyze procedures and decisions the first step to be taken is to identify conditions and actions of all possible activities. After each decision point there are next set of decisions to be considered. Thus while analyzing and designing a business system. Each of its branches stands for any one of the logical alternatives and because of the branch structure. As the whole web of all the possible combination of conditions and decisions is usually very large and cumbersome it becomes extremely important to document these so that there are no mistakes committed during the decision process. or any event. which can be a person. their possible combinations and the subsequent decisions. Conditions are the possibilities or the possible states of any given entity. The basic role of these tools is to depict the various conditions. Here comes the role of documenting tools.

The decision policy for discount percentage can be put in the form of a decision tree displayed in the following figure. Representing a very complex system with this tool may lead to a huge number of branches with a similar number of possible paths and options. Consider for example the discount policy of a saree manufacturer for his customers. According to the policy the saree manufacturer give discount to his customers based on the type of customer and size of their order. . The decision trees are not always the most appropriate and the best tool for the decision making process. For 13 to 48 sarees order. In our day-to-day life. only if the order size is 12 or more. which can only be taken when couple or more conditions should hold true together for there may be a case where other conditions are relevant only if one basic condition holds true. They also point out the required data. Whereas in case of shopkeeper or retailers. All the data used in the decision making should be first described and defined by the analyst so that the system can be designed to produce correct output data. the discount is 30%. the discount policy is different. the manufacturer gives a discount of 50% and for less than 12 sarees the discount is 30%. For the individual. many a times we come across complex cases where the most appropriate action under several conditions is not apparent easily and for such a case a decision tree is a great aid. for 49 to 84 sarees 40% and for more than 85 sarees the discount is 50%.Secondly it also aids the analyst about those decisions. which surrounds the decision process. If the order is less than 12 then there is 15% discount. Hence this representation is very effective in describing the business problems involving more then one dimension and parameters.

Fill the decision rules in the table. In the decision trees. Decision Tables A decision table is a table with various conditions and their corresponding actions. Every decision should be given a name and the logic of the decision table is independent of the sequence in which condition rules are written but the action takes place in the order in which events occur. It is divided into four parts. Determine the most possible steps that can take place under varying conditions and not just under current condition. Entries in a decision table are filled as Y/N and action entries are generally marked as "X". Action stub shows the various actions taken against different conditions. Calculate all the possible combinations of conditions. Condition entry is used for specifying which condition is being analyzed. duplication of terms and meaning should be avoided and only the standardized language must be used. And action entry is used to find out which action is taken corresponding to a particular set of conditions. 4. For every N number of conditions there are 2*2*2…. 2. There are certain conditions whose values do not affect the decision and always result in the same action. and action entry. Developing Decision Tables Before describing the steps involved in building the decision table it is important to take a note of few important points. 1. These rules can be consolidated into a single rule. The right side columns of the table link conditions and actions and form the decision rules hence they state the conditions that must be fulfilled for a particular set of actions to be taken. At times notes are added below the table to indicate when to use the table or to distinguish it from other decisions tables. a fixed ordered sequence is followed in which conditions are examined. This will identify the conditions involved in the decision. . (N times) combinations to be considered. Impossible rules are eliminated. which must be true. Wherever possible.For a complex problem. This step will identify the actions. Decision tree is a two dimensional matrix. But this is not the case here as the decision rule incorporates all the required conditions. The steps to be taken for a certain possible condition are listed by action statements. Firstly figure out the most essential factors to be considered in making a decision. condition entry. Action entries display what specific actions to be undertaken when selected conditions or combinations of conditions are true. Only those conditions should be selected which have the potential to either occur or not but partial occurrences are not permissible. action stub. condition stub. For the conditions that are immaterial a hyphen "-" is generally put. The steps of building the concerned tables are given below. Condition stub shows the various possible conditions. See the first figure listed below. Decision table is further simplified by eliminating and consolidating certain rules. 3. analyzing various situations is very difficult and can confuse the analyst.

. Y . Condition Entry 3 4 . . . . . Y . Condition Stub Customer is individual ? Customer shopkeeper or retailer ? Order-size 85 copies or more ? Order-size 49-84 sarees ? Order-size 13-48 copies ? Order-size 12 or more ? Order-size less than 12? Allow 50% discount Allow 40% discount Allow 30% discount Allow 15% discount Decision table-Discount Policy The first decision table for the problem stated above can be drawn as shown in the figure below. . . . 2 Y . 1 Y . . Y . . . . . X . . Y Y Y . Y . make him/her Management Trainee otherwise Manager. . X . . . 5 . . . . If the Person is from Computer Science and having experience equal to or greater than three years. Y . Y . . take him/her as Team leader and if the experience is less than that then take the person as Team member. . having experience less than three years. . . Y . . X . . It the applicant is a BE then recruit otherwise not. 6 . . . .Example: Consider the recruitment policy of ABC Software Ltd. If the person is from Computer Science. X . put him/her in the software development department and if the person is from non-computer science background put him/her in HR department. If the person recruited is from non Computer Science background. X . X .

It comes as an aid against the problems of ambiguous language in stating condition and actions in decisions and procedures.This table can further be refined by combining condition entries 2. 6. Here no trees or tables are employed. The simplified table is displayed in the figure below. and 8. Structured English Structured English is one more tool available to the analyst. rather with narrative statements a . 4.

Data dictionary is a collection of data to be captured and . Once the condition is determined the actions are unconditional. The analyst is first required to identify the conditions that occur in the process. An example of Structured English 3. subsequent decisions. There are no special symbols or formats involved unlike in the case of decision trees and tables. Usually numerous such instructions are used together to describe a process. Developing Structured Statements Three basic types of statements are employed to describe the process.Here action sequences described are often included within decision structures that identify conditions.these are those structures. Iteration Structures. Thus it does not show but states the decision rules. Sequence Structures . In this structured description terms from the data dictionary are widely used which makes the description compact and straight.A sequence structure is a single step or action included in a process. in routing operations such as DO WHILE statements. It is independent of the existence of any condition and when encountered it is always taken.procedure is described. "ELSE" and "So" statement decisions are made. 1. Here the steps are clearly listed in the order in which they should be taken. 2. also the entire procedure can be stated quickly as only English like statements are used. which are to be made and the alternative actions to be taken. Therefore these structures occur when two or more actions can be taken as per the value of a specific condition. data structures etc. The decision structure of example discussed in previous sections may be given in structured English as in the figure shown above. "THEN". Structured English borrows heavily from structured programming as it uses logical construction and imperative statements designed to carry out instructions for actions. Decision Structures . Using "IF". Data Dictionary As the name suggests the data dictionary is a catalog or repository of data terms such as data elements. which are repeated.

This poses a potential problem for the analyst and thus developing and using a well-documented dictionary can be a great help. It requires a lot of effort. For the job of the analyst both these procedures and decision-making processes of the business system under investigation are equally important. description. A data dictionary is always an added advantage for the system analysis. In a system there is data volume flow in the form of reports. it does not guarantee if the reader will . These data elements are related to one another and together they stand for some meaning. is known as a data element. Thus they help in evaluating the system and in locating the errors about the system description. Moreover. Now consider a case where everyone concerned with the system derives different meanings for the same data items. Most of the organizations have to follow some kind of procedures and they are required to make all sorts of decisions from time to time. Data element The smallest unit of data. There is a very little chance that only by them data element can convey some meaning. Data structures are used to define or describe the system's components. So let's first know more about what are these data elements and structures. The analyst uses case tool to represent and assemble all the information and the data gathered about the system. Data element is the data at the most fundamental level. In these transactions either the existing data is used or new data items are created. For each item the dictionary records its name. The complete and correct description of the system is as important as the system itself. inputs to the systems and outputs generated by the systems. alias and its length.stored in the system. These elements are used to as building blocks for all other data in the system. data stores and processes. CASE / Computer Aided Software Engineering Tools A tool is any device. It very reasonable to know why the data dictionary is so essential. For example any number digit or an alphabet will qualify to be data elements. At times data elements are also referred as data item. Data structure Data elements when clubbed together as a group make up a data structure. Expressing business processes and rules in plain text is very cumbersome and difficult process. There are numerous important reasons. From the data dictionary one can determine about the need of the new features or about the changes required. This problem can continue until the meaning of all data items and others are well documented so that everyone can refer to the same source and derive the same common meaning. The data dictionary takes its shape during the data flow analysis and its contents are used even till the system design. which takes place when the contents of the dictionary are themselves not up to the mark. elementary item or just as field. object or a kind of an operation used to achieve a specific task. which can not be further decomposed. Documentation in data dictionary is further carried on to record about the circumstances of the various process of the system. documents etc. Data dictionary entries consist of a set of details about the data used or produced in the system such as data flows.

So representing these things graphically is a good choice. Efficient and better CASE tools collect a wide range of facts. The analyst also inspected the place where the cards are stored and from that it was seen that it was a real mess. Some CASE tools are designed for creating new applications and not for maintaining or enhancing existing ones hence if an organization is in a maintenance mode.understand it well. we discussed how the analyst performed the preliminary analysis. There are no restrictions. Tools for DFD or a data flow diagram is a perfect example of a good CASE tool and it will be dealt in the later sessions. The analyst also saw the records for books. you can be as much open you want. . and accounts.Case Study : Library Management System In chapter 3 Preliminary Analysis . After this. report layouts and screen designs. Librarian: Hello. do come in. In the next section we'll look at these interviews. members. So analyst visited the library for two days and observed librarian issuing and returning books. So CASE Tools are useful in representing business rules and procedures of organization in graphical way. Analyst: I'll come straight to the point. during the information gathering stage of the development of our library system. Analyst's interview with Librarian Analyst: Hi. we will see how our analyst employed these methods. But we didn't look into the actual methods that the analyst employed to gather the information about the system. I have come to talk to you regarding the functioning of your library. Fact Finding Techniques . Given below is the interview between the analyst and one of the librarians. To see if a particular book is already issued. Interviews Interviews are useful to gather information from individuals. diagrams. Many a times the large projects are too big to be handled by a single analyst thus here the CASE too must be compatible enough to allow for partitioning of the project. interviewed the staff members and used questionnaires for both staff and members of the library. It requires less effort and it is easy to understand. it is a difficult and effort intensive process. I was expecting you. the analyst performed some personal interviews of library staff and few members. it must have a CASE tool that supports the maintenance aspect of the software developed. Now. In our case the analyst used on-site observations. Don't hesitate. From site visit our analyst had a good understanding of the functioning of the system. The CASE tool must format the collected data into a meaningful document ready to use. and rules. Fact Finding Techniques On-site Observation Our analyst wanted to see the functioning of library.

So we don't have any such facility presently. the management hopes to earn huge revenues. It is an overhead. Analyst: How many books are there? Librarian: About 5000 books Analyst: Do you people keep records for them? Librarian: Yes. Analyst: Do you have different member categories? Librarian: No. we plan to get huge revenues after we have an automated system. So in this way. It'll be easy for us to check how many books we have already to a particular member. Analyst: Would you prefer online registration for users rather than the printed form? . There is a membership fees to be paid. It is planning to increase fee from 400 to 500 for half yearly and 1000 for the whole year. Member can lie about it so that he/she gets an extra card. From this system. After the new system is built. Analyst: Do you want facility of booking a particular title in advance? Librarian: No we don't want any such facility. I do. we will open membership to our library. Management is planning to change the membership criteria. But there is a flaw in it. At about 50 to 100 members in a month. There are so many of them. Analyst: Could you explain how? Librarian: Look every month we get about 50-100 memberships requests. Analyst: What do you think be ideal solution to this? Librarian: There should be no cards at all. Very much. It is difficult to find out if it is genuinely the case. After all it's gonna reduce our loads of work. Analyst: Will you elaborate on it? Librarian: Major problem is managing the cards of members. Analyst: How often you get new members? Librarian: Very often. And we can't do anything about it. All are treated at par. Analyst: How do you categorise your books? Librarian : By subject. All the information should be put into computer.Librarian: I'll give you my whole contribution Analyst: Tell me are you excited about the idea of having an automated system for your library? Librarian: Yes. Many times cards get lost. Then we have to issue a duplicate card for it. But for two months we have freezed the membership because it is already very difficult to manage the existing 250 members. But if this whole system gets computerised then we'll open the membership. we don't have any categorisation for members.

Analyst: Do you have some format for them? Librarian: Yes we do have and we want that the same format be used by the new system. Analyst: Do you know the library people are planning to have an automated system? Member: Yes . I need to ask you few questions. Analyst: What you do think. Member: Sure. I pleasure. You have already covered all the fields. Also the number of days a book can be kept by member should also be increased. If you are free.Librarian: Yes . I do and I'm feeling good about it. Analyst: Reports? I completely forgot about them. Analyst interview with one member Venue: Reading Room Analyst: Hello. Then in that case. Our analyst took interviews of few members of the library in order to know about their viewpoint about the new system. Any other suggestions? Librarian: No. Analyst: Well as far as I know they are planning to hike the membership fee from 400 to 500 for half year and 1000 for full year. What reports you people produce presently? Librarian: Well first is for books in the library. another for members listing. they should increase the number of books to be issued. Analyst: Thanks for your co-operation. it should matter. . one for our current supplier of books. Sometimes we lose these forms then we don't have any information about that particular member. Analyst : Yes we'll take care of that. One of such interview is given below. It will be better to have it on computer. Analyst: Are you ready to pay more if there is a computerised system? Member: In the overall functioning is going to improve then I think no one will object to paying more. Member: That would be too much. It should help us finding the books easily. Librarian: My pleasure. how much books to be allowed for issue and for how many days. and reports for finance. It was nice talking to you. we really would. But by what amount. Analyst: Do you have any other expectation or suggestion for the new system? Librarian: It should be able to produce reports faster. Bye.

Analyst: And how many of them have actually become its members? Member: 25 people. or to your acquaintances? Member: Yes I very often do. Analyst: Yes. Analyst: On what basis a book should be categorised? Member: Well. Presently it is for 10 days. It should be 14 days. It was nice talking to you. Member: Then it should not bother members. they have such plans. Analyst: Have you ever recommended this library to your friends. Analyst: Till now. Analyst: That's really nice. . Analyst: How often you visit this library? Member: Daily Analyst: Do you think magazines and cassettes should be made available in the library? Member: I think it's a good idea. People actually take your recommendation very seriously. Member: Thank You. That's why I come here daily. to how many you have recommended? Member: About 30 people. It'll be a good practice. Thank You. very much. And the number of days for which a book is kept should be increased by 4 days. Analyst: What do you think on what basis a search for a particular book can be done? Member: It can be searched using subject or title. I never have felt the need to reserve a book in advance. Analyst: Should there be a facility to reserve a book in advance? Member: Presently they have many copies of a single title.Member: Well these people should increase number of books from 3 to at least 4. relatives. it should be on the basis of subject. Usually a book is always available. Analyst: Are you keen on online registration of members instead of normal paper one? Member: Yes. Only then the fee hike will be justified. Analyst: Do you like this library? Member: Yes.

Do you have data of book entered into some kind of database ? Yes\No 8. ________________________________________________________ ________________________________________________________ Questionnaire for library members . 1. author name or by subject) ? _____________________ _____________________ _____________________ 5. Do you want facility of booking a title in advance Yes\No 7. How many books are there in library? ____________________ 4. a) better cataloguing b) better managing of users c) better account and books management d) computer awareness e) any other _____________ 2. The questionnaire for library staff Instructions: Answer as specified by the format. Would you like online registration for users rather than printed form? Yes/No 10.After interviewing different people. Put NA for non-applicable situation. Do you already have some existing categorization of books on the basis as specified in question 4 above Yes/ No 11. How you want the books to be categorized for searching (like by title. Any other specific suggestion / expectation out of the proposed system. the analyst distributed questionnaires to all of them. How do you want users to be categorized? __________________ or __________________ 9. Questionnaires Since the time was less it was not practical to interview every library staff. What are your expectations out of the new system (computer based)? Rate the following on a scale of 1-4 giving a low value for low priority. How many users are you expecting? _____________________ 3. Is there any difference in the roles (privileges) of two members? Yes\No Please specify if Yes ________________________________________________________________ ________________________________________________________________ 6. analyst got to know about their opinions. So to get the opinion of all staff.

by title. Are you willing to pay extra for a library if it is fully computerized and eases finding of book. Analyst identified the following business rules. How many titles do you feel should be issued to a single member? ______________ 5. to how many you recommended and out of them how many actually became the members) Recommended :_____________ Became Members : _________________ Now we'll look at the techniques that the analyst employed to document the various business rules of the library. Put NA for non-applicable situation.In order to get the views of the existing members.8 . First is for 6 months and other is for 1 year. or acquaintances? Yes/No (if yes. Are you keen on online registration instead of the normal paper one. 1) Procedure for becoming a member of library. etc.…. What should be the maximum duration for the issue of certain book to a member? _______ Days. the analyst also distributed questionnaires to the member also. How often do you visit the library? Choose One. Should magazines and cassettes be included in the library Yes/No 10. relatives. by author . Should there be a facility to reserve a book on phone? Yes/No 9. Anyone whose age is 18 or more than that can become a member of library. 6 months membership fee is Rs 500 and 1 year membership fee is Rs 1000. The decision tree illustrating the business rule is given below. Instruction: Answer as specified by the format. Yes\No ___________________ ( if Yes. There are two types of memberships depending upon the duration of membership. The questionnaires used by analyst for the library members is shown in fig 4. Do you recommend this library to your friends. 6. What you feel should be necessary for a book to be searched? ( by topic. Should there be a facility to reserve a book in advance? Yes/No 7. . how much extra are you willing to pay) 2. a) daily b) once in two days c) weekly d) bi-weekly e) monthly 8. Yes/No 4. 1. ) ___________________ ___________________ ___________________ ___________________ 3.

1000 Y .Is Age < 18 Age > = 18 Is Memebership for 6 months ? Is Memebership for 12 months ? Grant Membership Deny Membership Charge Membership Rs. X . .10 Decision table for membership rule 2) Rule for Issuing Books If the number of books already issued is equal to 4 then no more books is issued to that member. Now the analyst has a good understanding of the requirements for the new system. . Y X . Functional Modeling . X Fig 4. X . Y . . . Design of the system will be discussed in the later chapters. X . . . . we can move to the designing. Y Y . If it is less than 4 then that book is issued. 500 Charge Membership Rs.

Data Stores An Example of a DFD for a System That Pays Workers Conventions used when drawing DFD's DFD Example . These include 1. a large system actually consists of various small independent subsystems that combine together to build up the large systems. External Entities. Lower level modules are generally smaller in scope and size compared to higher level modules and serve to partition processes into separate functions. the complete system is divided into small independent modules which may further be divided if the need be. Modules Processes Inputs and Outputs Design of Databases and Files Interfaces Modules As discussed in lesson 1 . 2. While designing the system too. it should be made as a hierarchy of modules. 5. Functional Requirements Design elements Modules Processes Input(s) and Output(s) Design of Databases Interfaces Functional Modeling Techniques Data Flow Diagrams Elements of Data Flow Diagrams .At the end of this chapter you will be able to know about functional modeling of system. Data Flow.Processes.General model of publisher's present ordering system Data Dictionary The procedure for producing a data flow diagram Design Elements in Functional Modeling This section describes the various design elements. For the better understanding and design of the system. You will also be able to know about the design elements of the system.Introduction to Systems. 3. Such independent modules are designed and coded separately and are later combined together to make the system functional. 4. Following factors should be considered while working on modules: Size: .

The number of instructions contained in a module should be limited so that module size is generally small. Each of these subsystems carries out a specific function and each of these functions may in turn be consisting of one or more processes. as: • • A process is a specified activity in an enterprise that is executed repeatedly. for example. in case of a warehouse. • • • . A process is not based on organizational structures and is carried out irrespective of this structure.1. as depicted by fig. This means that the processes are ongoing. generation of bills may be labeled as a process for a warehouse as it is repeatedly carried out A process can be described in terms of inputs and outputs. not how. a system consists of many subsystems working in close coordination to achieve a specific objective. For designing of any system. follow up order etc are few examples of processes. Processes As already discussed. but established in a single module that can be invoked by any other module when needed. For example. This information is taken as input and the bills generated are the output of the process. 5. information related to the sale of various items is required for generation of bills. A process has definable starting and ending points. Every process would have certain inputs required which are transformed into a certain output. A process identifies what is done. Fig 5.1 . Thus the system's functions can be subdivided into processes. Shared use: Functions should not be duplicated in separate modules.Functional Decomposition Source: Information Engineering: Planning & Analysis by James Martin Every process may be different from the other but each of them has certain common characteristics. these processes need to be identified as a part of functional modeling. A process is a specific act that has definable beginning and ending points. Create purchase requisition. A process has identifiable inputs and outputs.

historical data. During design of input. decides onto the various file-relating issues before the actual development of the system starts. inputs and outputs are an important part of any system. Most end-users will not actually operate the information system or enter data through workstations. so while designing a system inputs and outputs of the system as a whole need to be identified and the inputs and outputs for the various processes of the system need to be listed down. he also has to decide upon the data to be maintained by the system and for the system. The output design is specified on layout forms. during the design of the system.e. Don't leave it blank." Data items and transactions needing validation to detect errors Methods for performing input validation and steps to follow when errors occur The design decisions for handling input specify how data are accepted for computer processing. etc. The data is maintained in the form of data stores. The design of files includes decisions about the nature and content of the file itself such as whether it is to be used for storing transaction details.e. or reference information. "It is required. how many lines to plan on a printed page. Output refers to the results and information that are generated by the system. In many cases. the following factors should be considered: • • • • Determine what information to present Decide on the mode of output. The design of inputs also includes specifying the means by which end-users and system operators direct the system in performing actions. output is the main reason for developing the system and the basis on which the usefulness of the system is evaluated. sheets that describe the location characteristics (such as length and type). Each database may further be composed of several files where the data is actually stored. the analyst should decide on the following details: • • • • • • • What data to input What medium to use How data should be arranged How data should be coded i. informative messages that should be provided when the user is entering data. The analyst. Design of Databases and Files Once the analyst has decided onto the basic processes and inputs and outputs of the system. or whether to use graphics and color. While designing the output of system.e. such as whether to use preprinted forms when preparing reports and documents.Input(s) and Output(s) As discussed earlier. whether to display. or "speak" the information and select the output medium Arrange the presentation of information in an acceptable format Decide how to distribute the output to intended recipients These activities require specific decisions. data representation conventions The dialogue to guide users in providing input i. Following decisions are made during file design: . print. i. Like saying. which actually comprise of databases. but they will use the output from the system. and format of the column heading.

indexed.menus. network. such as sequential. or object oriented database model. relational. Interfaces .2 Basic Steps in system design . etc. hierarchical. the analyst decides upon the database model to be implemented.Designing the Interfaces Systems are designed for human beings to make their work simpler and faster. or relative) In database design. The analyst should be careful enough to design the human element of the system in such a manner that the end user finds the system friendly to work with.• • • Which data items to include in a record format within the file? Length of each record. Interface design implies deciding upon the human computer interfaces. Hence interaction of any system with the human being should be an important area of concern for any system analyst. based on the characteristics of the data items The sequencing or arrangement of records within the file (the storage structure.Database model can be traditional file based. It includes designing screens. How the end user or the operator will interact with the system. Fig 5. These data models are discussed in detail in lesson 7 on Data Modeling.

let us take a look at the modeling techniques that are used for designing the systems. command input. So a DFD shows the movement of data through the different transformation or process in the system. The agent that performs the transformation of data from one state to another is called a process (or a bubble). Deactivate commands that are inappropriate in the context of current actions. and placement) should be carried over to the input domain. The DFD aims to capture the transformations that take place within a system to the input data so that eventually the output data is produced. Interaction should be flexible but also tuned to user's preferred mode of input. It views a system as a function that transforms the inputs into desired outputs. Display only that information that is relevant to the current context. and data display. color. text size. Reduce the amount of information that must be memorized between actions. • • • • • • Data Flow Diagrams Elements of Data Flow Diagrams . As the name suggests.. Produce meaningful error messages. it is a diagram depicting the flow of data through the system. .The following factors should be considered while working on interfaces. They were in use long before the software engineering decipline begin. Any complex system will not perform this transformation in a "single step". Data Flow Diagrams (DFDs) are quite general and are not limited to problem analysis for software requirements specification.Processes. External Entities. Data Flow. A DFD shows the flow of data through a system. Provide undo or reversal functions. Data Flow Diagrams are used for functional modeling. we'll explore this technique in detail.General model of publisher's present ordering system Data Dictionary The procedure for producing a data flow diagram Data Flow Diagrams (DFD) Data Flow Diagrams . The visual characteristics of the display (e. DFDs are very useful in understanding a system and can be effectively used during analysis. Provide help facilities that are context sensitive. • • • • • • • • • • Use of a consistent format for menu. Produce meaningful error messages.g. Data Stores An Example of a DFD for a System That Pays Workers Conventions used when drawing DFD's DFD Example . indentation. and a data will typically undergo a series of transformations before it becomes the output. Use simple action verbs or short verb phrases to name commands. Maintain consistency between information display and data input. and text grouping to aid in understanding. In the coming sections.DFD (also called data flow graphs) are commonly used during problem analysis. Provide help to assist with all input actions Functional Modeling Techniques Now that we are familiar with the various design elements. Use upper and lower case. Provide the user with visual and auditory feedback to ensure that two-way communication is established.

etc. Physical DFDs are used in the analysis phase to study the functioning of the current system. In some (rare) cases. Naming Processes . They are external to the system being studied. The Data Flow symbol represents movement of data. These go on margins/edges of data flow diagram. Each process may have dramatically different timing: yearly. They are often beyond the area of influence of the developer. reorders. Thus. The Data Store symbol represents data that is not moving (delayed data at rest). • • • • The External Entity symbol represents sources of data to the system or destinations of data from the system. External Entities External entities determine the system boundary. Processes Processes are work or actions performed on incoming data flows to produce outgoing data flows.DFDs are basically of 2 types: Physical and logical ones. data inputs or outputs will only be shown at more detailed levels of the diagrams. Data coming into a process must be "worked on" or transformed in some way. Each process in always "running" and ready to accept data. These can represent another system or subsystem. Logical DFDs are used in the design phase for depicting the flow of data in proposed system. Major functions of processes are computations and making decisions. daily. These show data transformation or change.). all processes must have inputs and outputs. External entities are named with appropriate name.General model of publisher's present ordering system Elements of Data Flow Diagrams Data Flow Diagrams are composed of the four basic symbols shown below. Any system can be represented at any level of detail by these four symbols. converts. The Process symbol represents an activity that transforms or manipulates the data (combines. weekly. • • • • Elements of Data Flow Diagrams An example of a DFD for a system Coventions used when drawing DFD's DFD Example .

There can be two or more systems that share a data store. the rate of payment and overtime are obtained. Like customers. Name is not to include the word "process". and products. not to include the word "file". .3. In this DFD there is one basic input data flow. which is contained in the time sheet. using the employee ID. Levels of detail are shown by decimal notation. complaint. Data Flow Data flow represents the input (or output) of data to (or from) a process ("data in motion"). Using only the minimum essential data reduces the dependence between processes. Represent the minimum essential data the process needs. If there is an "and" in the name. payment.update customer and create Order Processes are numbered within the diagram as convenient. Data flows are always named. Names should consist of plural nouns describing the collection of data. orders. Only processes may connect with data stores. and next level with Processes 14. These are detailed in the data dictionary or with data description diagrams. For example. Data flows must begin and/or end at a process. you likely have more than one function (and process). Should be given unique names. next level of detail Processes 14.6. Processes should generally move from top to bottom and left to right. get invoice . first the employee's record is retrieved. For example. This can occur in the case of one system updating the data store. while the other system only accesses the data. An Example of a DFD for a System That Pays Workers An example of a Data Flow Diagram . not control.DFD for a system that pays workers is shown in the figure below. top level process would be Process 14. the sink for which is also the worker.1-14. These may be duplicated. which originates from the source worker. Each process should represent one function or action. Name is not to include the word "data".1-14. Data flows only data. order. These are common link between data and process models. Data Stores or Data Stores are repository for data that are temporarily or permanently recorded within the system. For example.Processes are named with one carefully chosen verb and an object of the verb.4. Names should be some identifying noun. In this system. The basic output is the pay check.3. Data stores are named with an appropriate name. There is no subject. the weekly time sheet. It is an "inventory" of data. From the employee record.

The need for multiple data flow by a process is represented by a * between the data flows. The amount paid is also recorded in company records. information from the tax rate file is used. The symbol represents the AND relationship. The amount of tax deducted is recorded in the employee and company records. So. . taxes are deducted. Similarly. it means that A AND B are needed for the process. the OR relationship is represented by "+" between the data flows. DFD of a system that pays workers. For example. while flow chart shows the flow of control. For example. It should be pointed out that a DFD is not a flowchart. the paycheck is issued for the net pay. Assuming the example DFD explained earlier all external files such as employee record. Conventions used when drawing DFD's Some conventions used when drawing DFD's should be explained. To computer the tax deduction. A DFD represents that flow of data.These rates and the regular and overtime hours (from the time sheet) are used to complete the payment. as shown in the DFD. company record and tax rates are shown as a one side open rectangle. while drawing a DFD. Finally. After total payment is determined. A DFD does not represent procedural information. one must not get involved in procedural details. if there is a * between the two input data flow A and B for process. and procedural thinking must be consciously avoided. In the DFD. for the process "weekly pay" the data flow "hours" and "pay rate" both are needed.

work towards the outputs. If you get stuck. 3. Make use of * and + operation and show sufficient detail in the data flow graph. Such DFDs together are called a leveled DFD set. 4. Inputs and outputs of each transform should be carefully identified. Label each arrow with proper data elements. If you find yourself thinking in terms of loops and decisions. One way to construct a DFD is to start by identifying the major inputs and outputs. Only some directions can be provided. Then starting from the inputs. Klork your way consistently from the inputs to the outputs. which helps in progressively partitioning and analyzing large systems. DFDs can be hierarchically organized. 2.General model of publisher's present ordering system Following are the set of DFDs drawn for the General model of publisher's present ordering system. DFD Example . Many systems are too large for a single DFD to describe the data processing clearly. How those transforms are performed is not an issue while drawing the data flow graph. reverse direction. 5.Consideration of loops and decisions must be ignored. Try drawing alternate data flow graphs before setting on one. It is necessary that some decomposition and abstraction mechanism be used for such systems. Minor inputs and outputs (like error messages) should be ignored at first. or vice versa. In drawing the DFD the designer has to specify major transforms in the path of the data flowing from the input to output. Start with a high level data flow graph with few major transforms describing the entire transformation from the inputs to outputs and then refine each transform with more detailed transformation. Following are some suggestion for constructing a data flow graph 1. First Level DFD . and designer should not worry about such as issues while drawing the DFD). identifying the major inputs (remember that is is important that procedural information like loops and decision not be shown in DFD. Never try to show control logic. it is time to stop and start again. There are no detailed procedures that can be used to draw a DFD for a given problem.

Showing Order Verification & credit check Third Level DFD .Second Level DFD .Elaborating an order processing & shipping .

Further expansion of the DFD focuses on the steps in billing the bookstore shown in the fourth level DFD. author's names. It is shown in the third level DFD diagram. Data Dictionary . From the level one it shows the publisher's present ordering system. Showing Account Receivable Routine. a clerk batches the order by assembling all the book titles ordered by the bookstore. Following the order verification and credit check. Let's expand process order to elaborate on the logical functions of the system. called "Bookstore Orders". First. incoming orders are checked for correct book titles. It is shown in the second level DFD diagram. the credit status of each book stores is checked before shipment is authorized. The batched order is sent to the warehouse with authorization to pack and ship the books to the customer. Each shipment has a shipping notice detailing the kind and numbers of booked shipped. Also. The details of the order are normally available in a special file or data store. additional functions related to accounts receivable. and other information and then batched into other book orders from the same bookstore to determine how may copies can be shipped through the ware house. This is compared to the original order received (by mail or phone) to ascertain its accuracy.Fourth level DFD : Completed DFD.

we have to somehow verify that they are "correct". 3. Missing data flows: Information required by a process is not available. It should also be ensured that none of the data flows is actually carrying control information. thy do not give details.tuple consisting of regular hours and overtime hours. our interest is to build some structures place to keep details of the contents of data flows. There can be no formal verification of a DFD. Extraneous data flows: Some information is not bein used in the process Consistency not maintained during refinement Missing processes Contains some control information The DFDs should be carefully scrutinized to make sure that all the processes in the physical environment are shown in the DFD. different notations are used. Unlabeled data flows. Draw a context DFD Defines the scope and boundary for the system and project . A data dictionary is a structured repository of data about data. The data dictionary entry for weekly timesheet specifies that this data flow is composed of three basic data entities . Human processes and rule of thumb must be used for verification. we have given names to data flows. employee ID and many occurrences of the two . 2. processes and data stores. To define the data structure. because what the DFD is modeling is not formally specify anywhere against which verification can be done. Identify and list inputs from/outputs to external entities.In our data flow diagrams. Some common errors are 1. processes and data stores. Some of the most obvious ones are not shown here. The data dictionary for this DFD is shown below: Weekly timesheet = Emplyee_Name + Employee_ID + {Regular_hours + overtime_hours} Pay_rate = {Horly | Daily | Weekly} + Dollar_amount Employee_Name = Last + First + Middle_Initial Employee_ID = digit + digit + digit + digit Most of the data flow in the DFD are specified here. Selection ( represented by vertical bar "|" ) means one or the other. Essentially. The last entity represents the daily working hours of the worker.the employee name. Although the names are descriptive of the data. In addition to the walkthrough with the client. So following the DFD. 4. These are similar to the notations for regular expression. and repitition ( represented by "*" ) means one or more occurances. besides sequence or composition ( represented by + ) selection and iteration are included. The data dictionay also contains entries for specifying the different elements of a data flow. Once we have constructed a DFD and its associated data dictionary. It is a set of rigorous definitions of all DFD data elements and data structures. the analyst should look for common errors. 6. The procedure for producing a data flow diagram • • • Identify and list external entities providing inputs/receiving outputs from system. 5.

Identify any external data stores 6. Rules for Data Flows . Processes should use imperative verbs to project action.Must show all appropriate primitive data stores and data flows verify all data flows have a source and destination. data storage.Explode the composite processes Draw primitive-level DFDs . ask end-users what responses must be produced by the system 5.Consolidate all data stores into a composite data store Draw middle-level DFDs . or the same net contents from the parent process serve as the initial inputs and final outputs for the child diagram or the data in the parent diagram is split in the child diagram Rules for Drawing DFDs • • • • • • • • A process must have at least one input and one output data flow A process begins to perform its tasks as soon as it receives the necessary input data flows A primitive process performs a single well-defined function Never label a process with an IF-THEN statement Never show time dependency directly on a DFD Be sure that data stores. review with "informed". Begin/end data flows with a bubble. Ignore the inner workings of the container 3.Exploding processes should add detail while retaining the essence of the details from the more general diagram .Detail the primitive processes . For each event. All processes receive and generate at least one data flow. Draw the context diagram i. Balancing DFDs • • • • • Balancing: child diagrams must maintain a balance in data content with their parent processes Can be achieved by either: exactly the same data flows of the parent process enter and leave the child diagram. Only show those data flows that represent the main objective or most common inputs/outputs identify the business functions included within the system boundary. trace and record what happens to each of the data flows entering the system (data movement.• • • • • • • • • • • 1. Think of the system as a container (black box) 2.Shows the major subsystems and how they interact with one another . data processes have descriptive titles. data transformation/processing) Draw an overview DFD . verify data coming out of a data store goes in. identify the data connections between business functions. data flows. Ask end-users for the events the system must respond to 4. explode and repeat above steps as needed. confirm through personal contact sent data is received and vice-versa. Use only one process ii.

etc). The index/outline will be "fleshed out" in the data dictionary.• • • • • A data store must always be connected to a process Data flows must be named Data flows are named using nouns " Customer ID. Think of data flow not control flow. Number each process (1. Think about what data is needed to perform a process or update a data store. This means that no inputs and outputs are changed. It summarizes the entire system as one bubble and shows the inputs and outputs to a system Each lower level DFD must balance with its higher level DFD. Data flows are pathways for data. A data flow diagram is not a flowchart and should not have loops or transfer of control. The diagram should serve as index and outline. Think about the data flows.0. Some of these issues are addressed in this chapter. Name each data flow with a noun that describes the information going into and out of a process.0. Data stores. Do not try to put everything you know on the data flow diagram. Process bubbles should be arranged from top left to bottom right of page. 2. Also name the process with a verb that describes the information processing activity. Student information Data that travel together should be one data flow Data should be sent only to the processes that need the data Use the following additional guidelines when drawing DFDs • • • • • • • • Identify the key processing steps in a system. sources and destinations are also named with nouns. All the basic elements of DFD are further addressed in the designing phase of the development procedure . Realize that the highest level DFD is the context diagram. What goes in should be different from what comes out. and procedure specification techniques • Functional Modeling . data processes. A processing step is an activity that transforms one piece of data into another form. data structure diagrams. and data storage that are needed to move a data structure through a system. You will also be able to know how to make structure charts.Part II At the end of this chapter you will able to know about the modular design of the system. Process Specification (PSPEC) Control Flow Model Control Specifications (CSPEC) Structure Charts Top Down Structure of Modules Cohesion Coupling Coding DFDs pay a major role in designing of the software and also provide the basis for other design-related issues.

The CSPEC contains a state transition diagram that is sequential specification of behavior. the PSPEC indicates restrictions and limitations imposed on the process (function). . and that process information with heavy concern for time and performance. The CFD contain the same processes as the DFD. Control flow diagrams show how events flow among processes and illustrate those external events that cause various processes to be activated. A data flow model is stripped of all data flow arrows. Control Flow Model The Hatley and Pirbhai extensions focus on the representation and specification of the control-oriented aspects of the software. control flow diagram is created. The process specification describes the input to a function. Control Specifications (CSPEC) The Control Specifications (CSPEC) is used to indicate (1) how the software behaves when an event or control signal is sensed and (2) which processes are invoked as a consequence of the occurrence of the event. Moreover. It also contains a process activation table (PAT) -a combinatorial specification of behavior. Events and control items are then added to the diagram a "window" (a vertical bar) into the control specification is shown. Such an application requires the use of control flow modeling in addition to data flow modeling. there exists a large class of applications that are driven by events rather than data that produce control information rather than reports or displays. and design constraints that may influence the way in which the process will be implemented. but shows control rather than data flow. The relationship between process and control model is shown in the figures in the sections Control Specification and Structure Charts. process specification is used to describe the inner workings of a process represented in a flow diagram.Process Specification (PSPEC) A process specification (PSPEC) can be used to specify the processing details implied by a bubble within a DFD. For this purpose. Drawing a control flow model is similar to drawing a data flow diagram. In other words. the algorithm. performance characteristics that are relevant to the process. The control specification (CSPEC) contains a number of important modeling tools. The control specification represents the behavior of the system in two ways.

It shows which module within a system interacts and graphically depicts the data that are communicated between various modules. A structure chart is a design tool that pictorially shows the relation between processing modules in computer software . which are any mechanism used to invoke a particular module. the basic infrastructure of the program layout is prepared based on the concepts of modular programming. the complete system is coded as small independent interacting modules. the system is given shape through programming. They are not intended to express procedural logic. Structure charts show the relation of processing modules in computer software.1 . Prior to this. They identify the data passes existing between individual modules that interact with one another. Notation Program modules are identified by rectangles with the module name written inside the rectangle. In modular programming. The design for these modules is prepared in the form of structure charts. Includes analysis of input-to-output transformations and analysis of transaction.Fig 6. Describes the hierarchy of components modules and the data are transmitted between them. Arrows indicate calls. Each module is aimed at doing one specific task. . This task is left to flowcharts and pseudocode. They don't describe the actual physical interface between processing functions. Structure charts are developed prior to the writing of program code. It is a design tool that visually displays the relationships between program modules.The relationship between data and control models Structure Charts Once the flow of data and control in the system is decided using tools like DFDs and CFDs.

Data identified as X and Y are passed to module B. while N is called on the basis of the iterative processing loop (noted by the arc at the start of the calling arrow. . the calling module can send data to the called module so that it can perform the function described in its name. 6.3 also shows module L calling subordinate modules M and N.2 . The called module can produce data that are passed back to the calling module.Fig 6.3. In fig.Annotations and data passing in structure charts A calling module can interact with more than one subordinate module. which in turn passes back Z. M is called on the basis of a decision point in L (indicated by the diamond notation). Data passing When one module calls another. 6. Fig 6.3 . Fig. we see that modules A and B interact. Annotations on the structure chart indicate the parameter that are passed and the direction of the data movement.Notation used in structure charts.

Loosely coupled modules are weakly connected. In addition. Cohesion is a natural extension of the information-hiding concept. For instance. The modular structure should reflect the structure of the problem. Cohesion is a measure of the amount of such grouping. 1. . . A brief annotation describes the type of information passed. we make a program as a collection of small functions. errors or end-of-conditions. as the name suggests. say. This property of software is termed as modularity. 3. requiring little interaction with procedures being performed in other parts of a program. Modularity is a very important feature of any software and allows a program to be intellectually manageable. While designing the modular structure of the program. different programs may use them. A program for finding average of three numbers may make use of a function for calculating the sum of the numbers. It should have the following properties. A small arrow with an open circle at the end is used to note the passing of data parameters. several issues are to be paid ention. Cohesion Cohesion.Part I that a system may be seen as a combination of everal small independent units. Thus modularity in software provides several advantages apart from making the program more manageable. Each of these can be called as a separate module and may be written by a different programmer. while coding small programs in 'C' also. A cohesive module performs a single task within a software procedure. Structure of Modules We have discussed in the previous chapter Functional Modeling . is the adherence of the code statements within a module. But once such modules are created. Inter module property: Coupling Modules should be as loosely interconnected as possible. control information (flag data) is also passed. parameter data. while designing software also.Highly coupled modules are strongly interconnected.Structures that tend to group highly related elements from the point of view of the problem tend to be more modular. Intra-module property: Cohesion Modules should be cohesive. So. are items of data needed in the called module to perform the necessary work. A small arrow with a closed circle indicates the control information. It is a measure of how tightly the statements are related to each other in a module. . . Structure chart is a tool to assist the analyst in developing software that meets the objectives of good software design. 2. Its purpose is to assist in the control of processing by indicating the occurrence of. The first. Cohesion is the degree to which module serves a single purpose. it is designed as a collection of separately named and addressable components called modules.Two types of data are transmitted. There should be always high cohesion. A module should capture in it strongly related elements of the problem.De-coupled modules exhibit no interconnection.

If the predicate of the sentence does not contain a single specific object following the verb (such as "edit all data"). we get sequential cohesion. this combines a linear chain of successive transformations. Here it doesn't provide any guidelines on how to combine them into modules. If the sentence must be compound sentence. 3. We have to use our judgement for this. the module is probably performing more than one function.Cohesion: modules should interact with and manage the functions of a limited number of lower-level modules. all elements of the module are related to erpforming a single function. 2. fully and accurately. Words like "Initialize and setup" imply temporal cohesion. Sequential Cohesion When the elements are together in a module because the output of one forms the input to another. Function like "computer square root" and "sort the away" are clear examples of functionally cohesive modules. 1. and probably has sequential or communicational cohesion. "after". The following test can be made. etc. Fig 6.4 . "next". The module probably has logical cohesion. . or has more than one verb. the function or purpose of the module. In a functionally bound module. A useful technique for determining if a module has a functional cohesion is to write a sentence that describes. If the sentence contains words relating to time like "first". There are various types of cohesion Functional Cohesion Sequential Cohesion Communicational Cohesion Procedural Cohesion Temporal Cohesion Logical Cohesion Coincidental Cohesion Functional Cohesion Functional cohesion is the strogest cohesion. Then the module probably has sequential or temporal cohesion.P and Q modules show sequential cohesion In terms of DFD. 4. This is acceptable. if it contains comma. How does one determine the cohesion level of a module? There is no mathematical formula that can be used. "when".

the elements are together because they operate on the same input or output data. A module with only procedural cohesion may contain only part of a complete function.Example: 1. often cuts accross functional lines. Fig 6. or parts of a several functions. Procedural Cohesion A procedurally cohesive module contains elements that belong to a common precedural limit. That is. Communicational cohesivemodule consists of all processing elements. . An example of this could be a module to "print and puch record". WRITE RECORD Update the current inventory record and write it to disk Communicational Cohesion A module with communicationl cohesion has elements that are related by a reference to the same input or output data. However. in a communicationl bound module. 2. For example: a loop or a sequence of decision procedurally cohesive modules often occur when module structure is determined from some form to flowchart. which act upon the same input data set and/or produce the same output data set. READ-PROCESS. communicational cohesion is sufficiently big so as to be generally acceptable if alternate structures with higher cohesion cannot be easily identified. It is commonly found in business or commercial applications where one asks what are the things that can be done with this data set.5 .Communicational Cohesion P and Q form a single module. Communicational cohesive modules may be performing more than one function. Module is defined in terms of the problem structure as captured in the DFD. procedural cohesion.

temporal cohesion is higher than logical cohesion. There is no logical reasoning behind this.6 .Fig 6. since the elements are all executed together. etc. Eventhough the elements in a temporally bound module are logicaly related. if possible.Procedural Cohesion Often found when modules are defined by cutting up flowcharts or other procedural artifacts. For example. Logical Cohesion is module formation by putting together a class of functions to be performed. Modules that perform activities like "initigation". terminal. Temporal Cohesion Temporal cohesion is the same as logical cohesion. In general. . and are executed together. Since elements of processing shall be found in various modules in a poorly structured way. "cleanup". It should be avoided. Fig 6. It is not acceptable. Display_error on file. logically cohesive modules should be avoided.6 illustrates this. and the elements perform function that fall in the same logical class. In this all the elements that are being used in the procedure 2 are put in the same module. printer. and "termination" are usually temporarilly bound. Logical Cohesion A module has logical cohesion if there is some logical relationship between the elements of a module. except that the elements are also related in time. and the code is usually simpler. This will avoid the problem of passing the flag.

Here function Display_error is for files. simply it is Strength of the connections between modules Coupling can be represented. . some major factors can be identified as influencing coulping between modules.Fig 6. and what data pass across the interface. Among them the most important are the type of connection between modules and the complexity of the interface. It is number of different items that increase the complexity not the amount of data. Coupling depends on the interface complexity between modules. Modules are joined by strong interconnections. for being able to solve and modify a module separately. Since the function is to display error. all three functions are put into same modules. So. the more we must know about module A in order to understand module B. As the number of different items being passed (not amount of data) rises the module interface complexity rises. Coupling in an abstract concept and is as yet not quantifiable. no formulas can be given to determine the coupling between two modules. the more closely connected A is to B "Highly coupled". Or. terminals. Same code is recognized as occurring in some other module.7 Logical Cohesion Fig 6. and the type of information flow between modules. Coincidental Cohesion Coincidental Cohesion is module formation by coincidence.7 shows logical cohesion. we would like the module to be loosely coupled with other modules. Coincidental cohesion can occur if an exixting program is "modularized" by chopping into pieces and making different pieces of modules. Pull that code into a separate module. and printers. Coupling Coupling is a measure of interconnection among modules in a program structure. This type of cohesion should be avoided since it does not reflect problem structure. "loosely coupled" modules have weak interconnections. Independent modules have no interconnections. the point at which entry or reference is made to a module. However. In general.

An interface of a module is used to pass information to and from modules. 1. Therefore. Stamp Coupling . In this type of coupling only data flows across modules. which makes it more difficult to understand the module and provide its abstraction. Coupling may also be represented on a spectrum as shown below: Coupling No Direct Coupling No direct coupling between M1 and M2 The modules are subordinated to different modules. There are two kinds of information that can flow along an interface. 2. Data coupling is minimal. no direct coupling Data Coupling In this the argument list data that is passed to the module.Coupling increases with the complexity and abscurity of the interface between modules. And minimize the complexity of each interface. Transfer of data information means that a module passes as input some data to another module and gets in return some data as output. To keep coupling low we would like to minimize the number of interface per module. data control Passing or recieving back control information means that the action of the module will depend on this control information.

That is there are modules using data that are global.In stamp coupling dta structure is passed via argument list Control Coupling Control is passed via a flag (1 bit) Common Coupling Common coupling occurs when there are common data areas. passing pointer can be considered as content coupling or branch into the middle of a module. Content Coupling If there is data access within the boundary of another. . It should be avoided. For example. One module makes use of data or control information maintained within the boundary of another module.

From here. The data model focuses on what data should be stored in the database . which discusses the data related design issues of the system. Data Modeling Techniques At the end of this chapter you will be able to understand the concepts involve in the data modeling of a system. Tools like flow charts and algorithms are used for coding the programs. Program should also include comment lines to increase the readability and modifiability of the program. Programmer codes each and every module of the system. The programs should be written such that they are simple. understand and modify. See fig 7. The other is the data model. this phase may involve installation and modification of the purchased software packages according to the system requirements. Contents Data Modeling and Data Requirements E-R Data Modeling Technique E-R Model concept. In some cases. From here the system analyst takes a backseat and programmer comes into action. You will also be able to understand the Entity Relationship Model used for data modeling. Coding phase is aimed at converting the design of the system prepared during the design phase onto the code in a programming language .Coding Structure charts provide the framework for programmers to code the various modules of the system by providing all the necessary information about each module of the system.1. easy to read. Entities and Attributes Types of Attributes Entity Types Value Sets (domain) of Attributes Entity Relationships Degree of an Entity Relationship Type Designing basic model and E-R Diagrams E-R diagrams constructs E-R Diagram for library management system Data Modeling and Data Requirements Last chapter discusses about one part of the conceptual design process. which performs the tasks as per the design requirements and is executable by a computer. the system goes for testing. which gives a physical shape to the system. the functional model.

the basic layout of the proposed system is depicted in the form of a logical DFD. Functional requirements are user defined operations or transaction like retrievals. • • • Object-based logical models Record-based logical models Physical-models . Physical database design. Basic data model operations are used to specify user functional requirements. It includes description of data types. It includes design of internal storage structures and files. While the system is being studied. the DFD can provide the basis in the form of the data flows and the Data Stores depicted in the DFD of the proposed system. In addition to this. By this process they are able to understand their data requirements. which make the foundation of the system under development. we'll look into details of data modeling. The Data Stores from the DFD are picked up and based on the data being stored by them the Data Model of the system is prepared. our main concern is data model.1 .Overall Database Design Process In this chapter. • • • • Fig 7.Elements of conceptual design We have already discussed the Data Flow Diagrams. (Also see figure below 7. etc. Even at the Data Modeling phase. Actual implementation of database. we'll talk of basics of database design process. Taking this DFD as the basis the system is further developed.2 . that are applied on the database. functional requirements are also specified. They fall in three different groups. Prior to data modeling. It is the description of data requirements of the users. Conceptual schema: Conceptual schema is created. The database design process can be described as a set of following steps.2 Overall Database Design Process) • Requirement collection: Here the database designer interviews database users.while the function model deals with how the data is processed. Fig 7. Results of this process are clearly documented. In this chapter. There are various data models available. relationships and constraints. updates. the physical DFDs are prepared whereas at the design phase.

• • • Relational model Network model Hierarchical model Relational Model This model uses a collection of tables to represent both data and relationship among those data.3 . They are following.4 represent a simple network database. Record-Based Logical Models Records-based logical models are used in describing data at the logical and view levels. The object-oriented model is covered in the next chapter. Fig 7. Many different models fall into this group. Figure shows a simple relational database. Each record type defines a fixed number of fields. data is represented by collection of records. or attributes. Each table has multiple columns. • • Entity-relationship model Object-oriented model In this chapter. The use of fixed-length records simplifies the physical-level implementation of the database. and each column has a unique name.A sample relational model Network Model In network database. The following models fall in this group. we’ll discuss Entity-Relationship model in detail. The records are organized as a collection of arbitrary graphs. They are used to specify the overall logical structure of the database and to provide a higher-level description of the implementation. The main characteristic of these models is that they provide flexible structuring capabilities and allows data constraints to be specified explicitly. the database is structured in fixed-format records of several types. and each field is usually of a fixed length. Figure 7. In record-based models. and relationships among data are represented by links. .Object-Based Logical Models Object-based logical models are used in describing data at the logical and view levels.

To understand the process of data modeling we'll study Entity Relationship model. Peter P. Like network model. E-R Data Modeling Technique Now we know various data models available.4 .5 represents a simple database. Two such models are: • • Unifying model Frame-memory model Physical data models capture aspects of database-system implementation. Fig 7. records and links represent data and relationships among data respectively.Fig 7. It differs from the network model in that the records are organized as collections of trees rather than arbitrary graphs. Chen originally proposed the Entity- .A sample network model Hierarchical Model The hierarchical model is similar to the network model. Physical Data Models Physical data models are used to describe data at the lowest level. A few physical data models are in use.

In the last. We can compare ER diagram with a flowchart for programs. Entities contain descriptive information. In ER modeling. car. similarly ERD is a tool for designing databases. relationships.Physical and Abstract Entity . entity types. relationship types. we will apply ER modeling to our case study problem "Library management system ". E-R Model concept The ER data modeling techniques is based on the perception of a real world that consists of a set of basic objects called entities. Later. entities and attributes are discussed. We will look into relational model in the next chapter. we'll look at E-R model concepts. Flow chart is a tool for designing a program. and attributes. house. These objects can be person. employee etc. are abstract entities. In the following section. job.6 . thing. are all physical entities whereas a company. data is described as entities. A basic component of the model is the Entity-Relationship diagram. Entities and Attributes One of the basic components of ER model is entity. Each entity is distinct. a book. event or a concept. Fig 7. or a university course. A person. The constructs used in ER model can easily be transformed into relational tables. ER model is easy to understand. their key attributes. their structural constraints. and of relationships among these objects.Relationship (ER) model in 1976. An entity is any distinguishable object about which information is stored. where other data models are discussed. Also an ER diagram shows the kind and organization of the data that will be stored in the database in the same way a flowchart chose the way a program will run. The ER modeling technique is frequently used for the conceptual design of database applications and many database design tools employ its concepts. which is used to visually represent data objects. An entity may be physical or abstract. Moreover it maps easily to relational model. and weak entity types are discussed. In the following section. The ER model is a conceptual data model that views the real world as a construct of entities and associations or relationships between entities. place.

An independent entity is one.8 .Entity and its attributes In the above figure. Attributes can be categorized as: . take the license entity. DeptId.Another classification of entities can be independent or dependent (strong or weak) entity. we'll look at different types of attributes. For example. and DeptManager as its attributes. A car entity can have modelno. or through its attributes. Attributes After you identify an entity. The value of one or more attributes can uniquely identify an entity. These are called weak entity types. Attributes are basically properties of entity. data value> pairs. Designation and Department are its attributes. For example. Name. For example take an organization scenario. Fig 7. which does not rely on another entity for identification. An entity set may have several attributes. ntities are classified as independent or dependent (in some methodologies. A dependent entity is one that relies on another entity for identification. It exists for existing depts. There won't be any department manager for which there is no dept. Formally each entity can be described by set of <attribute. then you describe it in real terms. respectively). In this section. brandname. We can use attributes for identifying and expressing entities. Entities belonging to a weak entity type are identified by being related to specific entities from another entity type in combination with some of their attribute values. A particular instance of an attribute is a value. the terms used are strong and weak. It can't exist unless it is related to a person entity. For example.7 . Department manager is a dependent entity. EmpNo. Fig 7. Dept entity can have DeptName. employee is the entity. Some entity types may not have any key attributes of their own. "Bhaskar" is one value of the attribute Name. and color as its attributes.Employee entity and its attribute values Types of Attributes Attributes can be of various types. An independent entity exists on its own whereas dependent entity exists on the existence of some other entity. Employee number 8005 uniquely identifies an employee in a company. Here department is independent entity.

ProdId is the key attribute. A person can’t have more than one age value. For example. For example. EmpNo is the key attribute since no two employees can have same employee number. we must have a value for it. There may be a case when one single attribute is not sufficient to identify entities. and Last_name. there is an attribute EmpNo (for employee no. We can divide it into sub-parts like First_name. For example. We can form a group of more than one attribute and use this combination as a key attribute. age of a person is a single-values attribute.• • • • • Key or non key attributes Required or optional Attributes Simple or composite Attributes Single-valued and multi-valued Attributes Stored. This attribute uniquely identifies the individual entity. for Product entity type. Then a combination of attributes can solve this purpose. An entity usually has an attribute whose values are distinct for each individual entity. Simple and composite Attributes Composite attributes can be divided into smaller subparts. Middle_name. This is required attribute since here would be no employee having no employee no. Similarly. When it's optional. If such an attribute doesn't exist naturally. . Coded or derived Attributes Key or non-key attributes Attributes can be classified as identifiers or descriptors. Therefore. Employee's spouse is optional attribute because an employee may or may not have a spouse. A descriptor describes a non-unique characteristic of an entity instance. identifying key attribute is very important. a new attribute is defined for that purpose. take Name attributes. in the Employee entity type. These subparts represent basic attributes with independent meanings of their own. When it's required. we could have a value for it. Age of a person is a simple attribute. A multi-valued attribute can have more than one value at one time. EmployeeNumber is a simple attribute. a value must be known for each entity occurrence. Attributes that can’t be divided into subparts are called Simple or Atomic attributes. for example an ID number or code. Required or optional Attributes An attribute can be required or optional. For example. When identifying attributes of entities. Identifiers. more commonly called keys or key attributes uniquely identify an instance of an entity. Such an attribute is called a key attribute. a value may be known for each entity occurrence. For example.) of entity employee. Composite Attributes Single-valued and multi-valued Attributes Attributes that can have single value at a particular instance of time are called singlevalued. That is known as a composite key attribute.

as well as which attributes are required or optional. Where appropriate. Fig. we can simply use the interest formula Interest=NPR/100. Stored. entity sets Employee and InternetGroup are not disjoint. Take the example of age. the value Gender might use the letters "M" and "F" as values rather than "Male" and "Female". a bank may limit the number of addresses recorded for a single customer to two. upper and lower bounds may be placed on the number of values in a multi-valued attribute. we can define an entity set Employee. In this case. Entity Types An entity set is a set of entities of the same type that share the same properties. or derived Attributes There may be a case when two or more attributes values are related. Later they can weed out those that are not applicable to the application. . In the above example. interest is the derived attribute whereas principal amount(P). every employee entity has its own values for each attribute. The attribute from which another attribute value is derived is called stored attribute. Difference between the two gives the value of age. In InternetGroup we will have some entries that are there in Employee entity set. A name and a list of attributes describe each entity type. An entity type defines a set of entities that have same attributes. For example. The individual entities that constitute a set are called extension of the entity set. Take another example. if we have to calculate the interest on some principal amount for a given time. date of birth is the stored attribute. In this case. For example. Entity sets don’t need to be disjointed. The participants come to an agreement. time(N) and rate of interest(R) are all stored attributes. 7. However. all individual software engineers of in the Internet projects are the extensions of the entity set InternetGroup. or attributes. employees of a company share the same attributes. Therefore. on which attributes belong with an entity. For example. A database usually contains groups of entities that are similar. or those clients are not prepared to spend the resources on to collect and maintain. The attributes reflect the need for the information they provide. For example. A coded value uses one or more letters or numbers to represent a fact. In the analysis meeting. An employee may or may not be working on some Internet projects. age is the derived attribute. the participants should list as many attributes as possible. and for a particular rate of interest. Age of a person can be can be calculated from person’s date of birth and present date. Thus. Derived attributes are usually created by a formula or by a summary operation on other attributes.10 shows two entity types Employee and Product. For example. A few members of each entity type are shown. coded. Their attribute list is also shown. all software engineers working in the department involved in the Internet projects can be defined as the entity set InternetGroup.degree of a person is a multi-valued attribute since a person can have more than one degree.

7. linkage. For example. Value Sets (domain) of Attributes Each attribute of an entity type is associated with a value set. The domain of Name is a character string. 7. we can specify the value set for designation attribute as <“PM”. and cardinality. “DM”. Member borrows book Each relationship has a name. Once the relationships are identified their degree and cardinality are also specified. We can say a relationship is any association. the next stage in ER data modeling is to identify the relationships between these entities. Entity Relationships After identification of entities and their attributes.Fig. member and book. Suppose there are two entities of our library system. The value set specifies the set of values that may be assigned for each individual entity. This value set is also called domain. Degree of an Entity Relationship Type Relationships exhibit certain characteristics like degree. These concepts will be discussed next. The entity set is also called the extension of the entity type. The domain of an attribute is the collection of all possible values an attribute can have. “SE”>. degree and cardinality. See fig 7. We can specify “Name” attribute value set as <strings of alphabetic characters separated by blank characters>. in the section E R Model Concept An entity type is basically the schema or intension or structure for the set of entities that share the same structure whereas the individual entities of a particular entity type are collectively called entity set. Typically. a relationship is indicated by a verb connecting two or more entities. . “Assit”. then the relationship between them can be “borrows”.10 Two entity types and some of the member entities of each An entity type is represented in ER diagrams as rectangular box and the corresponding attributes are shown in ovals attached to the entity type by straight lines. or connection between the entities of interest to the business. connectivity.

The values of connectivity are "one" or "many". there are zero. For example. or many instances of entity B but for one instance of entity B.11 shows a binary relationship between member and book entities of library system Fig. Fig 7. or many instances of entity A. there is only one instance of entity A. each employee is assigned to one department. The connectivity of a relationship describes the mapping of associated entity instances in the relationship. A one-to-many (1:N) relationship is when for one instance of entity A. Many modeling approaches recognize only binary relationships. Connectivity and Cardinality By connectivity we mean how many instances of one entity are associated with how many instances of other entity in a relationship. Cardinality is used to specify such connectivity. one-to-many. 7. and 3. is when for one instance of entity A. where each office is held by one member and no member may hold more than one office. or many instances of entity B and for one instance of entity B there are zero. Ternary or n-ary relationships are decomposed into two or more binary relationships. An example is employees may be assigned to no more than three projects at a time. there are zero. An example of a 1:N relationships is a department has many employees. one. Binary relationships.Degree: The degree of a relationship is the number of entities associated with the relationship. one.11 Binary Relationship A ternary relationship involves three entities and is used when a binary relationship is inadequate. A many-to-many (M:N) relationship. respectively. one. The cardinality of a relationship is the actual number of related occurrences for each of the two entities. and ternary. take the relationship between board members and offices. sometimes called non-specific. . The n-ary relationship is the general form for degree n. Special cases are the binary . and many-tomany. A one-to-one (1:1) relationship is when at most one instance of an entity A is associated with one instance of entity B. every project has at least two employees assigned to it. the association between two entities are the most common type in the real world. The basic types of connectivity for relations are: one-to-one. where the degree is 2.

If only few member of an entity type is related to some entity type via a relationship type. and relationships. Attaching a 1. If a relationship can have a cardinality of zero. from projects to employees. For example. Mandatory relationships. For example. the modeler must analyze the information gathered during the requirement analysis for the purpose of: and • • • • • classifying data objects as either entities or attributes. attributes. are indicated by words such as must have.Here the cardinality of the relationship from employees to projects is three. Multivalued attributes are shown in double ovals. on the other hand. Attributes are shown in ovals. policy and procedure documents. Derived attributes are shown in dotted ovals. we’ll apply the concepts of E-R modeling to our “Library Management System ” and draw its E-R diagram. the relationship is mandatory. Finally draw its ER diagram. entity types are represented by squares. If it must have a cardinality of at least one. Relationship types are shown in diamond shaped boxes attached to the participating entity types with straight lines. the participation is partial. The participation constraints specify whether the existence of an entity depends on its being related to another entity via the relationship type. if lucky. documenting this information in the data document. design documents from the current information system. Optional relationships are typically indicated by the conditional tense. a student must register for at least three courses in each semester. identifying and defining relationships between entities. this relationship can be classified as a many-tomany relationship. M. In this section. The participation constraint is specified by a single line for partial participation and by double lines for total participation. Therefore. and each attribute is attached to its entity type or relationship type by a straight line. . If every entity of an entity set is related to some other entity set via a relationship type. Weak entity types are distinguished by being placed in double rectangles and by having their identifying relationship placed in double diamonds. the cardinality is two. naming and defining identified entities. then the participation of the first entity type is total. E-R diagrams constructs In E-R diagrams. An employee may be assigned to a project. To accomplish these goals the modeler must analyze narratives from users. In order to begin constructing the basic model. notes from meeting. Key attributes have their names underlined. or N on each participating edge specifies cardinality ratio of each binary relationship type. it is an optional relationship. See the table below. Designing basic model and E-R Diagrams E-R diagrams represent the schemas or the overall organization of the system. and.

have meaning to the end-user. Mem_date (date of membership). the following entities and attributes can be identified. Street. . For entities and attributes. and Available (y or n) as its attributes. Name. Author.ENTITY TYPE WEAK ENTITY TYPE RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE DERIVED ATTRIBUTE TOTAL PARTICIPATION OF E2 IN R Cardinality Ratio 1:N FOR E1:E2 IN R Structural Constraint(Min. E-R Diagram for library management system In the library Management system. Each book has a Book-id. Name. City. City. Publisher-the set of all the publishers of the books. Zip_code. Expiry_date. Street. names are singular nouns while relationship names are typically verbs. and Zip_code. Mem_type. contain the minimum number of words needed to uniquely and accurately describe the object. Member-the set all the library members.Max) On Participation Of E In R Naming Data Objects The names should have the following properties: • • • unique. The member is described by the attributes Member_id. Title. Price. Attributes of this entity are Pub_id. • • • Book -the set all the books in the library.

we'll take relational model and object oriented model. 7.In the last chapter we saw one data modeling technique. In this section. relational and object oriented databases. hierarchical. City. Assumptions: a publisher publishes a book. Members borrow the book (only issue). Name.13 E-R Diagram of Library Management System. Relational Data Modeling and Object Oriented Data Modeling Techniques At the end of this chapter. Network. Street. and Zip_code. Relational Database Model Different Types of Keys in Relational Database Model Integrity Rules .• Supplier-the set of all the Suppliers of the books. There are many data models available. Entity Relationship data model. Return of book is not taken into account Fig. Having the basic knowledge of data modeling we can now explore other methods for data modeling. Attributes of this entity are Sup_id. you will be able to know about relational data modeling and Object Oriented data modeling techniques. Supplier supplies book to library.

That is. and Persistence Comparison Between Relational Database Model and Object Oriented Model Relational Database Model E. each item in a particular column is of same type. Fig. which we studied in the ER model. Understanding a relational model is very simple since it is very similar to Entity Relationship Model. a relation is a two-dimensional table. Also attributes are represented as columns of the table. In relational model. The entities and relationships. 8. A table exhibits certain properties. See fig 8. Fig 8. The basic concept in the relational model is that of a relation. It shows two columns for EmpNo and Name. Table can be used to represent some entity information or some relationship between them. Rows in the table represent records.1 Structure of a relation in a relational model. are similar to relations in this model.F. These things are discussed in detail in the following section. and columns show the attributes of the entity. It is a column homogeneous. Only from the type of information given in the table can tell if the table is for entity or relationship. Methods.1 shows structure of a relation in a relational model. In simple language. It is very simple and easily understandable by information systems professionals and end users.2. Even the table for an entity information and table for relationship information are similar in form. In . The relational database model is the most popular data model. tables represent all the entities and relationships identified in ER model. In ER model data is represented as entities similarly here data in represented in the form of relations that are depicted by use of two-dimensional tables.Codd proposed this model in the year 1970.Extensions and intensions Key Constraints Relational Algebra Traditional set operators Special Relational Operators Object oriented Model Encapsulation of Operations.

.. See fig.. See fig.... For example.. Similarly for Name column only alphabetic values are allowed.. See fig 8.... Since it is the only column where the values are all distinct... or last name. There must be some column having distinct value in all rows by which one can identify all rows. Ordering is immaterial for both rows and columns.3.2 Columns are homogeneous Another important property of table is each item value is atomic. Jason William Tony Bruce White Turner ... DName SD HR FIN DeptID 1 2 3 Manager Smith William Jonathan .... 15-Jul1998 is same for three row no 1.. Similarly in Name column it has alphabetic entries...............3 Table columns can have atomic values Every table must have a primary key.4........ MiddleName.. If we use DOJ as primary key then there would be three records that have same DOJ so there won’t be any way to distinguish these three records.. take a name item. In this we can place them under.. and 4. It can have first name. FirstName MiddleName LastName .. 8.. middle name... 8.. and LastName.... That is. EmpNo Name . That is... All the three parts are placed in three different columns.. FirstName.... Primary key is some column of the table whose values are used to distinguish the different records of the table. EmpNo can be used as a primary key..... For similar reasons..... say Name.. Next property we are going to discuss is for ordering of rows and columns within a table. Since these would be three different strings so they can’t be placed under one column. It is not possible for EmpNo to have some nonnumeric value (like alphabetic value)...5. .4 Table with primary key “EmpNo” and degree “3” In this table.. 8.3... EmpNo 1001 1002 1002 EName Jason William William DOJ 20-Jun-2007 12-Jul-2007 20-Jul-2007 1010 Smith 20-Jul-2007 Fig. ........ 1001 1002 1003 Jason William Mary 1004 Sarah Fig. Whereas in Ename there are two William and in DOJ column... item can’t be further divided...........the EmpNo column it has only employee numbers that is a numeric quantity... all rows should be unique... Jack Pirate Sparrow .. We’ll take up primary key topic later in the session.. 8.. 8. Fig... Ename cannot be used as primary key.. For this DOJ can’t be a primary key for this table...... Table (a) and (b) represent the same table....

“Trainee”.1. 8. each tuple of a relation is unique with respect to that relation. Since sets don’t contain duplicate elements. See fig. etc. Total number of columns in a table specifies its degree. In practice it is not usually necessary to involve all the attributes-some lesser combination is normally sufficient. For example there is an Employee table in which there is a Designation attribute. These attributes as a group is called composite primary key. Different Types of Keys in Relational Database Model Now we’ll take up another feature of relational tables. Domain in Relational Model Domain is set of all possible values for an attribute. A combination consisting of a single attribute is a special case. Similarly for name attribute can take alphabetic strings. There can be a possibility that some combination of attribute when taken together have the unique identification property. Primary key Within a given relation. which is not acceptable. Tuples represent entities in the real world. A table with n columns is said to have degree n. Hence. Since a column specifies a attribute. Table represented there is of degree 3. or “Developer”. Existence of such a combination is guaranteed by the fact that a relation is a set. . namely Primary keys. So domain for name attribute will be set of all possible valid alphabetic strings. having two columns with same name mean that we are specifying the same property in two columns. An attribute represents the use of a domain within a relation. Then we can say all these values make the domain for the attribute Designation. The different types of keys are described below. That is different type of keys. There are different types of keys. 8. Suppose. there can be one attribute with values that are unique within the relation that can be used to identify the tuples of that relation. “AGM”.5 Ordering of rows and columns in a table is immaterial Names of columns are distinct. Thus.EDU DName William Mary Jason 4 DeptID HR EDU FIN Jason Manager 2 7 4 Smith SD 1 Fig. at least the combination of all attributes has the unique identification property. It is not possible to have two columns having same name in a table. Primary key serves as a unique identifier for those entities. Designation attribute can take “PM”. every relation does have a primary (possibly composite) key. Composite primary key Not every relation will have single-attribute primary key. That attribute is said to be primary key for that relation. alternate keys.

are called candidate keys. If two entities are not distinguishable from each other. there can be more than one attribute combination possessing the unique identification property. This ensures that the consistency is maintained across the relations. it was not distinguishable from other entities. It would be like there was some entity that did not have any unique identification. That is.Candidate key In a relation. a tuple in one relation that refers to another relation must refer to the existing tuple in that relation. An identifier that was wholly null would be a contradiction in terms. 8. The referential integrity constraint states that. Integrity rule 2: Referential integrity The referential integrity constraint is specified between two relations and is used to maintain the consistency among tuples of the two relations. All entities must be distinguishable. then by definition there are not two entities but only one.6 if EmpNo is primary key then SocSecurityNo is the alternate key. they must have a unique identification of some kind. Integrity Rules in Relational Database Model Integrity rule 1: Entity integrity It says that no component of a primary key may be null. 8. Primary keys perform unique identification function in a relational database. That is. Suppose we wish to ensure that value that appears in one relation for a given set of attributes also appears for a certain set of attributes in another. Table A DeptID DeptName F-1001 S-2012 H-0001 Financial Software HR DeptManager Nathan Martin Jason . These combinations. In fig. which can act as primary key. This means that the referential integrity is a constraint specified on more than one relation. EmpNo 1011 1012 1013 SocSecurityNo 2364236 1002365 1056300 Name Harry Sympson Larry Age 21 19 24 Fig.6 Table having “EmpNo” and “SocSecurityNo” as candidate keys Alternate key A candidate key that is not a primary key is called an alternate key. This is referential integrity.

It is the permanent part of the relation. It corresponds to what is specified in the relational schema. Extension The extension of a given relation is the set of tuples appearing in that relation at any given instance. destroyed. The intension thus defines all permissible extensions. The intension is a combination of two things : a structure and a set of integrity constraints. The extension thus varies with time.Table B EmpNo 1001 1002 1003 See Also DeptID F-1001 S-2012 H-0001 EmpName Tommy Will Jonathan Extensions and intensions in Relational Database Model A relational in a relational database has two components. an extension and an intension. . Relation: Employee at time= t1 EmpNo EmpName Age 1001 1002 1003 1004 Jason William Jonathan Harry 23 24 28 20 Dept SD HR Fin Fin Relation: Employee at time= t2 after adding more records EmpNo EmpName Age Dept 1001 1002 1003 1004 1005 1006 1007 Jason William Jonathan Harry Smith Mary Sarah 23 24 28 20 22 19 23 SD HR Fin Fin HR HR SD Relation: Employee at time= t2 after adding more records EmpNo EmpName Age Dept 1001 1002 Jason William 23 24 SD HR Intension The intension of a given relation is independent of time. and updated. It changes as tuples are created.

Relational algebra is a collection of operations on relations. Each operation takes one or more relations as its operand(s) and produces another relation as its result. In arithmetic algebra . there are operators that operate on operands( data values) and produce some result. Key Constraints in Relational Database Model Key constraint is implied by the existence of candidate keys. Special relational operators that includes selection.The naming structure consists of the relation name plus the names of the attributes (each with its associated domain name). Examples salary >= 10000 Relational Algebra Once the relationships are identified. and division . and other constraints. Each of these specifications implies a uniqueness constraint(by definition of candidate key). intersection. difference. We can compare relational algebra with traditional arithmetic algebra. Referential constraints Referential constraints are constraints implied by the existence of foreign keys. Relational algebra can be divided into two groups: 1.in addition primary key specification implies a nonulls constraint( by integrity rule 1). Other constraints Many other constraints are possible in theory. Employee(EmpNo Number(4) Not NULL. the operations are performed with the help of relational algebra. The integrity constraints can be subdivided into key constraints. The intension includes a specification of the attribute(s) consisting the primary key and specification of the attribute(s) consisting alternate keys. Traditional set operators that includes union. Similarly in relational algebra there are relational operators that operate upon relations and produce relations as results. and Cartesian product. EName Char(20). For example. then operations that are applied on the relations are also identified. Dept Char(4) ) This is the intension of Employee relation. Age Number(2). 2. if any. referential constraints. Each of these specifications implies a referential constraint ( by integrity rule 2). In relational model. The intension includes a specification of all foreign keys in the relation. projection.

A MINUS B = The set of employees whose department is S/W development and not having age less than 30 years. Example: A = The set of employees whose department is S/W Development B = The set of employee whose age is less than 30 years.bm+n).. Example: A = The set of employees whose department is S/W Development B = The set of employee whose age is less than 30 years. am) and tuple b=(bm+1 . am. ……. Difference: The difference between two relations A and B( in that order) is the set of all tuples belonging to A and not to B. Example: A = The set of employees whose department is S/W Development B = The set of employee whose age is less than 30 years. A UNION B = The set of employees whose are either in S/W development department or having age less than 30 years.. ……. A INTERSECTION B = The set of employees whose are in S/W development department having age less than 30 years. bm+1.in that order. A TIMES B = is the set of all possible employee no/department ids pairs .. …. bm+n). Cartesian Product: The Cartesian product of two relations A and B is the set of all tuples t such that t is the concatenation of a tuple a belonging to A and a tuple b belonging to B. Intersection: The intersection of two relations A and B is the set of all tuples t belonging to both A and B. ……….Traditional set operators in Relational Database Model Union: The union of two relations A and B is the set of all tuples belonging to either A or B (or both).is the tuple t =(a1.. The concatenation of a tuple a = (a1. Example: A = The set of employees whose department is S/W Development B = The set of employee whose age is less than 30 years..

Special Relational Operators in Relational Database Model Selection: The selection operator yields a 'horizontal' subset of a given relation .that is. each term being a simple comparison that can be established as true or false for a given tuple by inspecting that tuple in isolation. in a specified left-to-right order. and then eliminating duplicate tuples within the attributes selected. the subset of tuples within the given relation for which a specified predicate is satisfied. Example: Issue [BookId. ReturnDate] BookID q-110 w-990 f-100 r-800 q-501 ReturnDate 20-May-2008 21-Jun-2008 23-Jun-2008 27-Jun-2008 15-Jul-2008 Book [Book Name] Book Name Software Concepts Data Structures Programming Assembly Language . the subset obtained by selecting specified attributes.that is. The predicate is expressed as a Boolean combination of terms. Book WHERE Author = ‘Kruse’ BookID BookName A-112 C-12 F-348 Algorithms Data Mining Author Jack Jack Software Engineer Jack Employee WHERE Desig=’Manager’ AND Dept =’SD’ EmpNo 2001 2002 2003 EmpName Morrison Steve Fleming Designation Manager Manager Manager Depat SD SD SD Projection: The projection yields a 'vertical' subset of a given relation.

It is easy to relate the objects to the real world. Object oriented concepts have their roots in the object oriented programming languages . place. An object can be any physical or abstract thing. there are relations similarly we have objects in OO data modeling. y> and B a set of single values. Object Oriented Model Nowadays people are moving towards the object oriented approach in many fields. development technologies.SSAD PC-Troubleshooting Compiler Design Now we know about the constructs of relational data model. We now take up another data model that is entirely different from relational model. Only thing we need to know at this stage is object can store information and behavior in the same entity i. These fields include programming. everything is modeled as objects. Let A be set of pairs of values <x. So today it is a common practice to use object-oriented concepts in data modeling. When these concepts became widely popular and accepted. So first thing that is done in OO model is to identify the objects for the systems. These include objects. It can be a person. . Encapsulation is discussed later in the chapter. In this session we’ll try to look at the process of applying object oriented concepts to data modeling. Suppose a car is being modeled using this method. thing. As in E-R model we have entities and in relational model. etc. In the section that follows we will try to understand the basic concepts of OO data model. other areas started to implement these ideas in them. An object can be used to model the overall structure not just a part of it. y> appears in A for all values y appearing in B. Objects and object identity: In this model. software engineering. Since programming languages were the first to use these concepts in practical sense. an object. We also know how to specify constraints and how to use relational algebra for illustrating various functions. and produces a result relation of degree m. or a concept. Then we can have an object ‘Car’ that has the following information. Other important task is to identify the various operations for these objects. Examining the problem statement can do it. Division: The division operator divides a dividend relation A of degree m+n by a divisor relation B of degree n. polymorphism. Object oriented data Modeling Concepts As discussed earlier Object oriented model has adopted many features that were developed for object oriented programming languages.is the set of values x such that the pair <x. and encapsulation. Also the behavior of the thing that is being modeled is also specified in the object. implementation of databases. In object-oriented model main construct is an object. It became possible due to the fact the object-oriented concepts try to model things as they are.that is A DIVIDEDBY B. inheritance. <y>. This feature is called encapsulation. Then the result of dividing A by B .e.

i2. which distinguishes it from all other object. No of gates. OID is used internally by the system to identify each object uniquely and to create and manage inter-object references. The main properties of OID: 1. These objects may be represented as a triple t(i. It is immutable: The value of OID for a particular object should not change. There can be several constructors.. each object has a unique identity.c. in). every object is given an identity. depending upon or the OO system. Another feature of OO databases is that objects may have a complex structure. set. It is due to contain all of the significant information that describes the object. An object value v is interpreted on the basis of the value of the constructor c in the triple (i. character strings. .…………. In contrast. Capacity. which are the identifiers (OIDs) for a set of objects that are typically of the same type. 8.……. The internal structure of an object includes the specification of instance variables.. There is also a domain D that contains all basic atomic values that are directly available in the system. and any other data types that the system supports directly. See fig. system generated object identifier (OID). Identity is the property of an object. dates. These include integers. This unique identity is implemented via a unique. The basic constructors are the atom.12. 2. In OO databases. c. in traditional database systems. real numbers. If c = set. the values (or states) of complex objects may be constructed from other objects. Model No. For this purpose. Gears. the value is an atomic value from domain D of basic values supported by the system. c is a constructor (that is. In OO databases. an indication of how the object value is constructed). The value of OID doesn’t depend upon any attributes of the object since the values of attributes may change. the value v is a set of objects identifiers {i1.v) that represents the object. and array constructors. where i is a unique object identifier. All this information is sufficient to model any car.. an:in). which hold the values. This preserves the identity of the real world object being represented. Brand. Engine Cylinders. It leads to loss of direct correspondence between a real-world object and its database representation. the value v is a tuple of the form <a1:i1. But its value is not visible to the user. v). OID should not be based on the physical address of the object in memory since physical reorganization of the database could change the OID. that defines the internal state of the object. Boolean. list. All the objects should be unique. and v is the object value (or state).Car: Color. information about a complex object is often scattered over many relations or records. If c = atom. It is used only once: Even if an object is removed its OID is not assigned to other objects. If c= tuple. where each aj is an attribute name( sometimes called an instance variable name in OO terminology) and each ij is an object identifier(OID). tuple. There should be some mechanism for generating OIDs.

For c = array.If c = list.DNUMBER:i8.atom. We compare model representation capabilities. languages. It is useful when related records from more than one relation are often accessed together. SE) O6 = (i6. Consider the following example: O1 = (i1. Jane) O3 = (i3. It allows the user to specify dynamically on each file a single primary or clustering index and any number of secondary indexes. NEPZ) O7 = (i7. They are physically not connected. If the does not specify any storage structure. each base relation is implemented as a separate file. Some RDBMSs give the user the option of mixing records from several base relations together.ENAME:i3>) O8 = (i8. The Object Oriented model supports complex object structures by using tuple. In relational model. the value v.1) Here value of object 4 is constructed from object values of objects O1. They employ indexing techniques to locate disk pages that store the object.………. Goerge) O4 = (i4. is an array of object identifier.tuple. set. Comparison between Relational Database Model and Object Oriented Model Now we know about both relational and object oriented approach. and integrity constraints.<DNAME:i5. atom.. . atom. most RDBMS will store the tuples as unordered records in the file. O6. and O8. atom. O3. Storage Structures In relational model. we compare the relational model and object oriented model. list. Object Oriented systems provide persistent storage for complex-structured objects. It supports the specification of methods and the inheritance mechanism that permits creation of new class definitions from existing ones. set. system storage structures. and the object structure is reconstructed after copying the disk pages that contain the object into system buffers. In this way the related records may be retrieved in most efficient way possible. This is in a way similar to foreign keys but internal system identifiers are used rather than user-defined attributes.LOCATION:i6. we can now compare these two models. atom. Roger) O2 = (i2. It is the responsibility of user to chObject Orientedse the attributes on which the indexes are set up. These constructors can be used to define the data structures for an OO database schema. In object oriented model. and other constructors. and O3. atom. Data Model Representation Different database models differ in their representation of relationships.i2. connections between two relations are represented by foreign key attribute in one relation that reference the primary key of another relation. This clustering of records physically places a record from one relation followed by the related records from another relation. Similarly value of object 7 is constructed from the value of O1. Relational model uses logical references. The objects are often stored as byte strings. in] of the same type. Individual tuples having same values in foreign and primary key attribute are logically related. In this session. relationships are represented by references via the object identifier (OID).i3}) O5 = (i5. O2. the value v is an ordered list of object identifiers[i1.. {i1.i2.

reactor monitoring). In Object Oriented systems. flight control. The constraints supported by Object Oriented systems vary from system to system.Integrity Constraints Relational model has keys. testing can cost 3 to 5 times as much as all other activities combined. software development must be accompanied by quality assurance activities. but no complete detailed standard has emerged as yet. Contents Fundamentals of Software Testing White Box Testing Black Box Testing Equivalence Partitioning Boundary Value Analysis Strategic Approach towards Software testing . and referential integrity. In software development project. System Testing and Quality Assurance At the end of this chapter you will be able to know about system testing and testing strategies employed during the testing phase of software development . For lifecritical software (e. no technique is perfect. entity integrity. Work on a standard Object Oriented model and language is progressing. The main causes of errors are 1. Data manipulation Languages There are languages such as SQL . and QBE are available for relational systems. such as C++.g. not getting the requirements right. These are based on the relational calculus. the DML is typically incorporated into some programming language. The destructive nature of testing requires that the developer discard preconceived notions of the correctness of his/her developed software. errors can be come in at any stage during development. You will also be able to understand the various quality assurance activities employed for maintaining the overall quality of the system. and humans being as error prone as they are. not translating the requirements in a clear and understandable manner so that programmers implement them properly. 2. and 3. the structures of both stored persistent objects and programminglanguage transient objects are often compatible. There are techniques available for detecting and eliminating errors that originate in various stages. However. The inverse relationship mechanism supported by some Object Oriented systems provides some declarative constraints. Software development is not a precise science. This means that testing must be done from an entirely different perspective from that of a developer. QUEL. Hence. not obtaining the right requirements. Query languages have been developed for Object Oriented databases. It is typical for developers to spend around 40% of the total project time on testing.

wrong design. In the section that follows we'll try to understand those techniques. All these errors need to be discovered before the system is implemented at the customer's site. This output can be some numeric or alphabetic value. Because having a system that does not perform as desired be of no use. For different types of errors there are different types of testing techniques. there is an error. A test case is a particular made up artificial situation upon which a program is exposed so as to find errors.Unit Testing Integration Testing Top-Down Integration Bottom-Up Integration Validation Testing Alpha and Beta testing System testing . If testing is done properly. And it is equally important and crucial as any other stage of system development. When we apply this concept to software products then we say whenever there is difference between what is expected out of software and what is being achieved. So testing is done. test cases are designed. if it differs from what was required. Security Testing Role of Quality in Software Development Software Quality Factors Software Quality Assurance Activities Involved in Software Quality Assurance Application of Technical methods FTR (Formal Technical Review) Software Testing Control of change Measurement Record keeping and reporting Software Maintenance Fundamentals of Software Testing Testing is basically a process to detect errors in the software product. it uncovers errors and after fixing those errors we have software that is being developed according to specifications. Before going into the details of testing techniques one should know what errors are. or some fault on developer's part. or some specific behavior from the system. For the output of the system. In case of an error there may be change in the format of out. . some formatted report. or some value different from the expected is obtained. This definition is quite vast. We can define testing as a process of executing a program with the aim of finding errors. Stress Testing. In day-to-day life we say whenever something goes wrong there is an error. These errors can due to wrong analysis. To perform testing.Recovery Testing. All the effort put in to build it goes waste. it is due to an error. some unexpected behavior from system. So a good test case is one that finds undiscovered errors. Objectives of testing First of all the objective of the testing should be clear.

design specifications and source code of program. It is more intensive than black box testing. Here the internal functioning of the product is tested. The other approach is called white box testing. test cases are integral part of testing. Test cases are required to know what specific situations need to be tested. Second is test configuration. Each procedure is tested for its accuracy. test results are compared with actual results and if there is some error. The most desired or obvious expectation from a test case is that it should be able to find most errors with the least amount of time and effort. There should be sufficient number of tests in both categories to test the overall product.Test Information Flow Testing is a complete process. Software configuration is required so that the testers know what is to be expected and tested whereas test configuration is testing plan that is. It includes software requirement specification.1 Testing Process Test Case design We now know. then debugging is done to correct the error. In the first approach only the overall functioning of the product is tested. It also specifies if any tools for testing are to be used. First is software configuration. Testing is a way to know about quality and reliability. Inputs are given and outputs are checked. Error rate that is the occurrence of errors is evaluated. A software product can be tested in two ways. When tests are evaluated. the way how the testing will be conducted on the system. It is basically test plan and procedure. But for the overall product both these techniques are crucial. This data can be used to predict the occurrence of errors in future. This approach is called black box testing. It specifies the test cases and their expected value. For testing we need two types of inputs. It does not care about the internal functioning of the product. So we need to know more about test cases and how these test cases are designed. For this different procedures are tested. White Box Testing White box testing focuses on the internal functioning of the product. Fig 9. White box testing tests the following • • • Loops of the procedure Decision points Execution paths .

This notation is known as flow graph. Flow graph depicts control flow and uses the following constructs. We will illustrate how to use this technique.For performing white box testing. it is important to know the simple notation used for the repres4enttation of control flow. Flow graph Notation Before basic path procedure is discussed. . These tests guarantee to execute every statement in the program at least one time during testing.It was proposed by Tom McCabe. Each node that contains a condition is called a predicate node. in the following section. Basis Path Testing Basic path testing a white box testing technique . basic path testing technique is used. Basic set is the set of all the execution path of a procedure. These individual constructs combine together to produce the flow graph for a particular procedure Sequence - Until - If - While - Case - Basic terminology associated with the flow graph Node: Each flow graph node represents one or more procedural statements.

even if the node does not represent any useful procedural statements. V(G).Edge: Edge is the connection between two nodes. 3. Cyclomatic complexity: Independent path is an execution flow from the start point to the end point. An edge must terminate at a node. Thus it provides a upper bound for number of tests that must be produced because for each independent path. Cyclomatic complexity. a test should be conducted to see if it is actually reaching the end point of the procedure or not. R= 6 Number of Nodes = 13 . The numbers of regions of the flow graph correspond to the Cyclomatic complexity. The edges between nodes represent flow of control. Since a procedure contains control statements. Region: A region in a flow graph is an area bounded by edges and nodes. So Cyclomatic complexity provides the number of such execution independent paths. Example: Consider the following flow graph Region. V(G). there are various execution paths depending upon decision taken on the control statement. 2. Cyclomatic complexity. for a flow graph G is defined as V(G) = E – N + 2 where E is the number of flow graph edges and N is the number of flow graph nodes. for a graph flow G is also defined as V(G) = P + 1 Where P is the number of predicate nodes contained in the flow graph G. Cyclomatic Complexity Cyclomatic Complexity for a flow graph is computed in one of three ways: 1.

Each edge is represented by some letter (as given in the flow chart) to distinguish it from other edges. Graph Matrices Graph matrix is a two dimensional matrix that helps in determining the basic set. V(G) of this flow graph using any of the formula discussed above. then the testing for the overall functionality of program structure is tested. Prepare test cases that will force execution of each path in the basis set. Then for each row sum of the entries is obtained and 1 is subtracted from it. Then each edge is provided with some link weight. In this approach internal procedures are not considered. V(G) can be determined by counting the number of conditional statements in the code and adding one to it. 0 if there is no connection and 1 if there is connection. Black box testing uncovers following types of errors. It is conducted at later stages of testing. If the outputs obtained are same as the expected ones then the product meets the functional requirements. Or V(C) = Predicate Nodes + 1 =5+1 =6 Or V( C)= E-N+2 = 17-13+2 Deriving Test Cases The main objective of basic path testing is to derive the test cases for the procedure under test. Input are supplied to product and outputs are verified. Now the value so obtained for each row is added and 1 is again added to get the cyclomatic complexity. Now the graph matrix is called connection matrix. Each row with two entries represents a predicate node. Now we will look at black box testing technique. . The process of deriving test cases is following 1. 2. Determine the Cyclomatic complexity. derive a flow graph. For providing weights each letter is replaced by 1 indicating a connection. It has rows and columns each equal to number of nodes in flow graph. Once the internal working of the different procedure are tested. Entry corresponding to each node-node pair represents an edge in flow graph. Black Box Testing Black box testing test the overall functional requirements of product. · Even without a flow graph. V( C) : V( C ) = R = 6. · Each test case is executed and compared to the expected results. 3. For this black box testing techniques are used which are discussed in the following pages.Number of edges = 17 Number of Predicate Nodes = 5 Cyclomatic Complexity. From the design or source code.

If an input condition requires a specific value. 2. if the range is 0. Equivalence classes represent a set of valid or invalid states for input condition. a specific value. then the test cases are 0.0. An input condition can be a range. These classes are known as equivalence classes and the process of making equivalence classes is called equivalence partitioning.1 and 1. 5. then one valid and one invalid equivalence class are defined. Then depending upon type of input equivalence classes is defined. a test case is designed so as to uncover a group or class of error. the following guidelines should be used: . The following techniques are employed during black box testing Equivalence Partitioning In equivalence partitioning. 3. 3. then one valid and two invalid equivalence classes are defined. In boundary value analysis.0for valid inputs and –0.1 for invalid inputs. For boundary value analysis.. 1. including the equivalence classes of the output. In case of ranges. then one valid and one invalid equivalence class are defined. Boundary value test cases are also called “extreme cases”. If an input condition specifies a range. such that the input lies at the edge of the equivalence classes. 4. 2. Here input domain is divided into classes or group of data. For defining equivalence classes the following guidelines should be used. a set of values.e. If an input condition specifies a member of a set. should be covered. 0 < count < Max1000. or a boolean value.1. These values often lie on the boundary of the equivalence class. For example.0.1. This limits the number of test cases that might need to be developed otherwise. Test cases that have values on the boundaries of equivalence classes are therefore likely to be error producing so selecting such test cases for those boundaries is the aim of boundary value analysis. one with values less than the lower bound of range (i. Boundary Value Analysis It has been observed that programs that work correctly for a set of values in an equivalence class fail on some special values. count < 0) and other with values higher than the higher bound( count > 1000). Hence. one valid and two invalid equivalence classes are defined. we choose input for a test case from an equivalence class. the range is say. Incorrect or missing functions Interface errors External database access Performance errors Initialization and termination errors. for boundary value analysis it is useful to select boundary elements of the range and an invalid value just beyond the two ends (for the two invalid equivalence classes. Boundary values for each equivalence class. If an input condition is Boolean. Then form a valid equivalence class with that range of values and two invalid equivalence classes.0 <= x <= 1. 4. For example. a boundary value test case is a set of input data that lies on the edge or boundary of a class of input data or that generates output that lies at the boundary of a class of output data.

The developer of the software conducts testing and if the project is big then there is a testing team: All programmers should test and verify that their results are according to the specification given to them while coding. Performing testing without some testing strategy would be very cumbersome and difficult. test case design. In such an environment. a test case should be designed to exercise the data structure at its boundary. test cases should include values a and b and just above and just below a and b respectively. This systematic procedure is testing strategies. Strategic Approach towards Software Testing Developers are under great pressure to deliver more complex software on increasingly aggressive schedules and with limited resources. Earlier the bugs are identified. Testers are expected to verify the quality of such software in less time and with even fewer resources. There are different techniques for detecting and eliminating bugs that originate in respective phase. But testing software is not an easy task since the size of software developed for the various systems is often too big. Various software-testing strategies have been proposed so far. Testing aims to finds the errors whereas debugging is the process of fixing those errors. responsibilities for testing lies with the team as a whole. Integration testing etc. Things that are common and important in these strategies are Testing begins at the module level and works “outward” : tests which are carried out. If internal data structures have prescribed boundaries. In a software development life cycle. Testing strategies are discussed the following pages of this chapter. different testing methodologies are to be used which will be the decisive factor for software robustness and scalability. more cost saving it has.) and the purpose of testing. Different testing techniques are appropriate at different points in time: Under different circumstances. But debugging should be incorporated in testing strategies. test execution. All provide a template for testing. In cases where programs are big enough or collective effort is involved for coding. solid. Software testing strategy integrates software test case design techniques into a wellplanned series of steps that result in the successful construction of software. repeatable. Any test strategy incorporate test planning. which should guide the tester in performing different tests at correct time. and the resultant data collection and evaluation. Testing needs a specific systematic procedure. Circumstance essentially means the level at which the testing is being done (Unit testing.For input ranges bounded by a and b. and practical testing methods and automation are a must. system testing. . test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits. Debugging and testing are altogether different processes. If an input condition specifies a number of values. Testing is a set of activities. These activities so planned and conducted systematically that it leaves no scope for rework or bugs. Now we know how the testing for software product is done. bug can be injected at any stage. are done at the module level where major functionality is tested and then it works toward the integration of the entire system. which should be followed in order to test the system developed thoroughly.

That is in which manner testing should be performed.3 Sequence of Tests . This activity is carried out in a simulated environment so that actual results could be obtained without taking any risks. ensuring that each module performs the function for which it was designed. Only after the software architecture is complete does an independent test group(ITG) become involoved. Verification and Validation in Software Testing Verification is a process to check the deviation of actual results from the required ones. When developer and ITG work together. First developer should test the product after that ITG can do it. Testing Strategies Once it is decided who'll do testing then the main issue is how to go about testing. He is the most knowledgable person with context his own program. Here system is treated as one entity and tested as a whole.A software strategy must have low-level tests to test the source code and high-level tests that validate system functions against customer requirements. Validation may continue for several months. Continued use may produce additional failures and the need for still more changes. ITG test the product very thoroughly.3 first unit testing is performed. Now we'll take up these different types of tests and try to understand their basic concepts. the product is tested thoroughly and unbiased. 9. Fig 9. other high order tests like system tests are performed. As shown in fig. Because of natural reasons a developer would like to declare his program as bug free. Planning for Testing One of the major problem before testing is while planning. Validation refers by the process of using software in a live environment in order to find errors. Unit testing focuses on the individual modules of the product. In this case since the developer knew that there are other people who will again test their product they'll conduct tests thoroughly. failure may occur and the software will be changed.a testing step that leads to the construction(and testing) of thecomplete program structure. the developer also conducts integration testing. Integration testing uncovers those errors. Therefore. During the course of validating the system. he is always responsible for testing the individual units (modules) of the program. The feedback from the validation phase generally produces changes in the software to deal with bugs and failures that are uncovered. After that integration testing is performed. Both the developer and ITGs should be made responsible for testing. But this does not esantially mean that the pragrammer himself should not test his program. After integration testing. In many cases. When modules are integrated into bigger program structure then new errors arise often. These tests focus on the overall system.

So unit testing is basically white box oriented.4 Unit Testing Unit Testing Procedure Fig 9. individual programmers can do unit testing on their respective modules. Since in unit testing each module is tested individually. Here design documents help in making test cases. Stubs and drivers .Unit Testing We know that smallest unit of software design is a module. Unit testing is performed to check the functionality of these units. it is done before these modules are integrated together to build the overall system. Independent paths: All independent paths are tested to see that they are properly executing their task and terminating at the end of the program. It may need data from some other module or it may need to send some data or control information to some other module.4 for overview of unit testing Fig 9. Local data structures: these are tested to see if the local data within unit(module) is stored properly by them. so the need to obtain data from other module or passing data to other module is achieved by the use of stubs and drivers. Error handling paths: These are tested to check if errors are handled properly by them. 9. reviewed and verified for the correct syntax. See fig. Though each module performs a specific task yet it is not a standalone program. Boundary conditions: It is observed that much software often fails at boundary conditions.5 Unit Test Procedure Unit testing begins after the source code is developed. Procedural design descriptions are used and control paths are tested to uncover errors within individual modules. The following are the tests that are performed during the unit testing: • • • • • Module interface test: here it is checked if the information is properly flowing into the program unit and properly coming out of it. Unit testing can be done for more than one module at a time. Since the modules are small in size. That's why boundary conditions are tested to ensure that the program is properly working at its boundary conditions.

may not produce the desired major function. • • Top-Down Integration Bottom-Up Integration Top-Down Integration in Integration Testing Top-down integration is an incremental approach to construction of program structure. Drivers and stubs are overhead because they are developed but are not a part of the product. For integrating depth-first or breadth-first approach is used. Now we'll discuss these approaches. It does minimal data manipulation. in a module there is error-precision taken as +. Unit testing does not guarantee if these modules will work fine if these are integrated together as a whole system. In top down integration. 9. remove them and build the overall program structure as specified by design. All are accessing the same global memory. Similarly stubs are also programs that are used to replace modules that are subordinate to the module to be tested. which is discussed next. Now these modules are combined. Now these modules are combined. Main control module. find errors. One is top down integration and the other is bottom up integration. This overhead can be reduced if these are kept very simple. Once the individual modules are tested then these modules are integrated to form the bigger program structures. For example. Following types of errors may arise: • • • Data can be lost across an interface. A driver is basically a program that accepts test case data and passes that data to the module that is being tested. low memory problem can arise. Fig. Suppose the errorprecision from both modules needs to be multiplied then the error precision would be +-100 which would not be acceptable to the system. when combined. Because so many functions are accessing that memory. integrate them. That is data coming out of a module is not going into the desired module. That is which module is driving or controlling which module. So next stage of testing deals with the errors that occur while integrating modules. Global data structures can present problems: For example. . first control hierarchy is identified. modules sub-ordinate to and ultimately subordinate to the main control block are integrated to some bigger structure.are used to simulate those modules. Sub-functions. That's why next testing done is called integration testing. It is observed that many errors crop up when the modules are joined together. Integration testing uncovers errors that arises when modules are integrated to build the overall system. Individually acceptable imprecision may be magnified to unacceptable levels.10 units. It also prints the relevant results. Integration Testing Unit testing ensures that all modules have been tested and each of them works properly individually. The objective is to take unit tested modules. There are two approaches in integration testing. in a system there is a global memory. In other module same error-precision is used. and returns. prints verification of entry. • Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing.5 illustrates this unit test procedure.

3. 9. M6). Atomic modules are the lowest levels in the program structure. so stubs are not required in this approach.6 the sequence of integration would be (M1. 4. Since modules are integrated from the bottom up. M7. which we discuss in the following page. M2. M4. M6. See fig. Bottom-Up Integration in Integration Testing Bottom-up integration testing starts at the atomic modules level. A bottom-up integration implemented with the following steps: 1. Using breadth first for fig. 9. 9. In breadth first all modules directly subordinate at each level are integrated together.6. M7. and M8. M8). M5. These clusters are sometimes called builds. (M3. 2. Another approach for integration is bottom up integration.Fig.6 Top down integration In depth first approach all modules on a control path are integrated first. Low-level modules are combined into clusters that perform a specific software subfunction. The build is tested. Drivers are removed and clusters are combined moving upward in the program structure. A driver (a control program for testing) is written to coordinate test case input and output. processing required for modules that are subordinate to a given level is always available. Here sequence of integration would be (M1. M3). andM5. M2. M4. .

which were working fine previously. regression test suite should be designed to include only those tests that address .Fig. Whenever a new module is added to as a part of integration testing. the number of regression tests can grow quite large.7 shows the how the bottom up integration is done.7 (a) Program Modules (b)Bottom-up integration applied to program modules in (a) Fig 9. Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects in the programs. 9. To detect these errors regression testing is done. some new I/O or some new control logic. Therefore. There may be new data flow paths. These changes may cause problems with functions in the tested modules. the program structure changes. As integration testing proceeds. Regression testing is the activity that helps to ensure that changes (due to testing or for other reason) do not introduce undesirable behavior or additional errors.

validation testing begin. Most software product builders use a process called alpha and beta testing to uncover errors that only the end user seems able to find. Here. it is impractical to perform formal acceptance tests with each one. acceptance testing can be conducted over a period of weeks or months. The developer records errors and usage problem. The beta test is conducted at one or more customer sites by the end user(s) of the software. Deviation or error discovered at this stage in a project can rarely be corrected prior to scheduled completion. After each validation test case has been conducted. At this stage a final series of software tests. If software is developed as a product to be used by many customers. developer is not present. Expectations are defined in the software requirement specification identified during the analysis of the system. Because of problems reported during beta test. When custom software is built for one customer. one of two possible conditions exists: The function or performance characteristics conform to specification and are accepted. The specification contains a section titled “Validation Criteria” Information contained in that section forms the basis for a validation testing. The software is used in a natural setting with the developer. It is impractical and inefficient to re-execute every test for every program functions once a change has occurred. and a test procedure defines specific test cases that will be used in an attempt to uncover errors in the conformity with requirements. thereby uncovering cumulative errors that might degrade the system over time. It is often necessary to negotiate with the customer to establish a method for resolving deficiencies. Acceptance test is conducted by customer rather than by developer. and the output that seemed clear to the tester may be unintelligible to a user in the field.one or more classes of errors in each of the major program functions. The customer records all problems that are encountered during beta testing and reports these to the developer at regular intervals. In fact. Customer conducts the alpha testing at the developer’s site. or A deviation from specification is uncovered and a deficiency list is created. Therefore. It can range from an informal “test drive” to a planned and systematically executed series of tests. a series of acceptance tests are conducted to enable the customer to validate all requirements. strange combination of data may be regularly used. Alpha tests are conducted in a controlled environment. There is a test plan that describes the classes of tests to be conducted. Validation Testing After the integration testing we have an assembled package that is free from modules and interfacing errors. it is difficult to foresee how the customer will really use a program. Software validation is achieved through a series of black-box tests that demonstrate conformity with requirements. Validation succeeds when software functions in a manner that can be expected by the customer. Instructions for use may be misinterpreted. Major question here is what are expectations of customers. the beta test is a live application of the software in an environment that cannot be controlled by the developer. the software developer . Alpha and Beta testing For a software developer.

System Testing Software is only one element of a larger computer-based system. (1) special tests may be designed that generate 10 interrupts are seconds. If the recovery requires human intervention. During security testing. Stress testing executes a system in a manner that demands resources in abnormal quantity. The role of the system designer is to make penetration cost greater than the value of the information that will be obtained in order to deter potential threats. The tester may attack the system with custom software designed to break down any defenses that have been constructed. For example. These tests fall outside the scope of software engineering process and are not conducted solely by the software developer. Recovery Testing Many computer-based systems must recover from faults and resume operation within a prespecified time. processing faults must not cause overall system function to cease. a system failure must be corrected within a specified period or severe economic damage will occur. In other cases. System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. thereby denying service to others. that is. (3) test cases that require maximum memory or other resources may be executed. It the recovery is automated (performed by system itself). data recovery. all work to verify that all system elements have been properly integrated and perform allocated functions. may overwhelm the system. In the following section. frequency. software is incorporated with other system elements and a series of system integration and validation tests are conducted. The testers attempt to break the program. . good security testing will ultimately penetrate a system. when one or two is the average rate. the tester plays the role of the individual who desires to penetrate the system. Security testing attempts to verify that protection mechanism built into a system will protect it from unauthorized penetration. different system tests are discussed.makes modifications and then prepares for release of the software product to the entire customer base. Although each test has a different purpose. and restart are each evaluated for correctness. re-initialization mechanisms. Ultimately. or volume. Security Testing Any computer-based system that manages sensitive information or causes actions that can harm or benefit individuals is a target for improper or illegal penetration. or (5) test cases that may cause thrashing in a virtual operating system may be designed. a system may be fault tolerant. (4) test cases that may cause excessive hunting for disk resident data may be created. In some cases. Stress Testing Stress tests are designed to confront program functions with abnormal situations. the mean time to repair is evaluated to determine whether it is within acceptable limits. Given enough time and resources. and so on. (2) input data rates may be increased by an order of magnitude to determine how input functions will respond. hoping to find the key to system entry. may purposely cause system errors. Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed.

it must be sold in order to survive in this dynamic software industry. We employ software to solve and simplify our real-life problems and it goes without saying that it should be of high class i.e. straight. software project management practices are adequately utilized and software development undergoes a more refined process. Pennsylvania has devised a quality model known as Capability Maturity Model CMM. Software quality assurance is an umbrella activity. quality software.all projects use an organized.Role of Quality in Software Development Till now in this chapter we have talked about the testing of the system. Quality enforcement is very important in system development. Here mainly software system and quality is considered. The dominant nature of the software market is its dynamic growth. but it is only a small part of the quality assurance activities. explicitly documented development standards and implicit characteristics that are expected of all professionally developed software. For quality.implementation of project management tools. In CMM . Specified standards define a development criteria which displays the manner in which the software is engineered. documented and standardized set of activities that are implemented throughout the project life cycle. . to further make it more simple for our understanding we can focus on the points given below. LEVEL 3 : Defined . thus here the software quality and it's assurance come into the picture. New application areas are continually emerging along with birth of new technologies. the process capability of a company is understood in five advancing maturity levels. The goal of CMM is that a firm's process capability is reflected to the extent to which it plans for and monitors software quality and customer satisfaction. As organizations grow. This model is based on the principles of Total Quality Management(TQM) for improving the entire software development process. Software Engineering Institute Carnegie Mellon University. In this part we'll study how we can apply quality factors in order to produce a quality system. But this leads us to few questions such as how to define quality and what exactly it is with respect to software. which are employed for achieving the good quality and error free system. Also these companies should always try for continuous improvement in quality. For software developers whatever they produce .processes are not adequately defined and documented. Though this definitions speak a volume about the matter. a brief overview of them is given below: LEVEL 1 : Initial . Any deviation from the given criteria will result into lack of the quality. which must be applied throughout the software engineering process. Software requirements have to be met by the newly developed system and thus any lack of conformance in them will be serious quality lag. honest and frank the client may be but then there are always a set of implicit requirements which are not mentioned but they should be met. No matter how much vocal. Hence it becomes a subjective issue but then there are some basic do's and don’ts to be taken care of during the course of software cycle which if applied thoroughly will lead to a reasonable quality software and that is what the following definition of software quality statesConformance to explicitly stated functional and performance requirements. LEVEL 2 : Repeatable . Testing is one process to have a error free system. New methods of information processing and new programming environments have created a dilemma in management of software development . We have not yet talked about quality of system produced.

effort required to locate and fix an error in a program. The classification is done on the basis of measurability.Cn*Mn where Fq is the software quality factor.Specific process and quality outcome measures are implemented. prepare input and interpret output of a program Maintainability. Interoperability. operate.labor required to understand. A set of matrices is defined and is used to develop expressions for each of the factors as per the following expression Fq = C1*M1 + C2*M2 + ……………. Efficiency . Reusability. protocols and bandwidth are used. which influence the software.effort needed to modify an operational program. The CMM has become tool to evaluate the potential of an organization to achieve high quality in software development. Metrics used in this arrangement is mentioned below. We also looked at CMM in brief. another method was evolved to measure out the quality. Accuracy.extent to which a program satisfies its specification and fulfills the client's objective. Testability. Usability. technology changes management and process change management is implemented. Integrity .effort required to couple one system to another.precision of computations and control Communication commonality. .Continuous process improvement is adopted in the entire organization. We need to know various quality factors upon which quality of a software produced is evaluated.amount of computing and code required by a program to perform its function. These factors are given below. LEVEL 5 : Optimized . • • • • • • • • • • • Correctness . Each software company should aim to achieve high CMM level.extent to which access to software and data is denied to unauthorized users. Portability. They can be broadly divided into two categories.LEVEL 4 : Managed .effort required to test the programs for their functionality. • • • Auditability. The various factors. Software Quality Factors Till now we have been talking software quality in general.degree to which standard interfaces.ease with which the conformance to standards can be verified. What it means to be a quality product.effort required to run the program from one platform to other or to different hardware. Few factors of quality are available and they are mentioned below. Flexibility.extent to which a program is supposed to perform its function with the required precision. Therefore. Sophisticated methods of defect prevention. Cn are regression coefficients and Mn is metrics that influences the quality factor.extent to which the program or it’s parts can be used as building blocks or as prototypes for other programs. are termed as software factors. The first category of the factors is of those that can be measured directly such as number of logical errors and the second category clubs those factors which can be measured only indirectly for example maintainability but the each of the factors are to be measured to check for the content and the quality control. Reliability . Now as you consider the above-mentioned factors it becomes very obvious that the measurements of all of them to some discrete value are quite an impossible task.

Consistency. Expandability. Self-documentation. Supportability combines the ability to extend the program. Modularity. Reliability.program’s compactness in terms of lines of code. Conciseness. Data commonality. response time. systematic sequential actions that enable the quality of the software produced. Functionality is measured via the evaluation of the feature set and the program capabilities. Software system independence.degree to which a program is understandable without much difficulty. Hardware independence. Considering human factors. resource consumption.degree to which the program monitors its own operation and identifies errors that do occur. overall aesthetics. the accuracy of output results. serviceability or in other terms maintainability and also testability. Execution efficiency. Performance is measured by measuring processing speed. throughput and efficiency. Security. There are various ‘checklists’ for software quality. Instrumentation. operating system characteristics and other environment constraints. consistency and documentation assesses usability. Operability.degree to which full implementation of functionality required has been achieved. adaptability.ability to trace a design representation or actual program component back to initial objectives. Traceability.control and protection of programs and database from the unauthorized users. Training. configurability and the ease with which a system can be installed. Simplicity.use of uniform design and documentation techniques throughout the software development . the mean time between failure (MTBF). Software Quality Assurance Software quality assurance is a series of planned.functional independence of program components.• • • • • • • • • • • • • • • • • Completeness. Error tolerance – damage done when program encounters an error. the generality of the functions that are derived and the overall security of the system. Performance and Supportability. Usually all software development units have their own Software quality assurance (SQA) team.run-time performance of a program. .degree to which one can extend architectural.ease of programs operation. One of them was given by Hewlett-Packard that has been given the acronym FURPS – for Functionality. Usability.degree to which the software is de-coupled from its operating hardware. Reliability is figured out by evaluating the frequency and severity of failure.degree to which the software is user-friendly to new users.degree to which program is independent of nonstandard programming language features.degree to which the source code provides meaningful documentation. data and procedural design. the ability to recover from failure and the predictability of the program.use of standard data structures and types throughout the program. compatibility.

measurement and record keeping and reporting.This Software quality assurance (SQA) team takes care of the quality at the high end that is the overall product and at the lower order the quality is the sole responsibility of the individual who may engineer. conducting of Formal Technical Reviews (FTR). Activities Involved in Software Quality Assurance Application of Technical methods FTR (Formal Technical Review) Software Testing Control of change Measurement Record keeping and reporting Activities Involved in Software Quality Assurance Software quality assurance clubs together various tasks and activities. It is initiated with the help of technical methods and tools that enable the analyst to achieve a high quality specification and help the designer to develop a high-quality design. . We can always point specifications ( or the prototype ) and the design are individually checked for quality. There are seven major activities namely application of technical methods. Fig. Software Quality Assurance (SQA) starts early along with the process of software development . Software quality has to be a characteristic of the software produced and thus it is designed into it rather than to be imposed later. This practice can improve the quality of all the software produced by the organization. review and test at any level. Formal Technical Reviews (FTR) is employed for this purpose and by its means the members of the technical staff undergo a meeting to identify the quality problems. It is the duty of every individual in the software development team that quality is maintained even before some formal quality assurance procedures are applied. control of change. 9. Many-a-times reviews are found to be equally effective just as the testing of uncovering defects in software.9 The adoption of the philosophy of Continuous Improvement in the software development life cycle. software testing.

Some errors remain uncovered. Hence to minimize these effects. this will invariably result in the increase in the software cost. Change control is applied during software development and also later during the maintenance phase. Nothing bothers the whole of the software engineering process more than the changes. Hence we have to look up to other measures also but this should not diminish the importance of software testing. The documents of reviews. documented and maintained for reference purposes. Either the standards are self-imposed in the whole of the software engineering process by the software development team or they are carried out as per the client’s dictation or as a regulatory mandate. Hence the importance of a well-defined specification and detail design are again highlighted. Any and every change to software will almost incorporate an error or trigger side effects that will propagate errors. Application of formal and systematic standards and procedures vary from project to project and company to company. We now know various activities involved in quality assurance activity. These metrics encompass a broad array of technical and management oriented measures. Also an assessment of this compliance must be regularly undertaken either by the means of Formal Technical Reviews (FTR) or as an Software Quality Assurance (SQA) group audits which the team may do on its own. results of Formal Technical Reviews (FTR). welldocumented standards are not available then it becomes imperative to initiate an Software Quality Assurance (SQA) activity so that the standards are complied with. audits. Application of Technical methods in Software Quality Assurance . It is believed that the software testing can dig out most of the errors but practically as the fact goes no matter how rigorous the testing may be it is unable to uncover all the errors. It contributes to the software quality by formalizing the requests for change by evaluating its nature and also controlling its impact. If formal i. testing and other Software Quality Assurance (SQA) activities become a part of the project and can be referred by the development staff on a need to know basis. The ill influence of changes can vary with nature of the change and it also depends at which stage they are to be incorporated. Now we’ll take one activity at a time and look into it in detail. change control. So it comes into action here also. Software metrics is used to track software quality and to evaluate the impact of methodological and procedural changes. Any doubts or requests should be taken into account then and there only. Records are usually developed. Therefore both the client and the software development team should be sure of the design developed before they freeze it and the process goes to the next step. Needless to add. which are taken into design at a later stage. Early changes are much less harmful than the ones. written. Measurement is such an activity that it cannot be separated from any engineering discipline as it is an integral part of it.e.The next step in the software testing which involves a series of test case design methods to enable effective error detection. change control process activity is used. Thus record keeping and recording enable the collection and distribution of Software Quality Assurance (SQA) information. Before the coding starts these designs are to be freezed and all the software development process after the detail design takes the design skeleton as the base on which the software is built. This is so because any change in the specification or the design will demand a re-lay out of all the work done so far and in the subsequent plans. Any further request to add new features from the client will lead to changes in the design and it will result in more effort and time requirements on the software development team’s behalf.

Modeling During software requirements analysis. . consistency and accuracy of the specification. well coded but a poorly analyzed and specified program will always be a problem for the end-user and bring disappointment to the developer. 1. interfaces and information must be fully understood before successive layers of detail are specified. The model is the base/foundation for the design and thus it serves as the representation of the software that can be “mapped” into an implementation context. Partitioning Quite often problems are too large and complex to be grasped as a whole and then it is very reasonable to partition/divide them into smaller parts so that they individually become much easier to understand and in the end one can establish interfaces between the parts so that the overall function can be accomplished. These models are a great help in the following manner…. behavior and it’s other information thus making the analysis task easier and systematic. models of the system to be built are created and these models focus on what the system must do and not on how it has to do. No matter how well designed. The ability to absorb pertinent facts from conflicting or confused sources. the specification is a description of what is desired rather than how it is to be realized/implemented. During the requirement analysis the information. major functions. The ability to apply the hardware and/or software system elements to the user/client environments.There are two major objectives to be achieved by employing technical methods. The analyst plays the major role in the requirements analysis phase and he must exhibit the following traits… • • • • The ability to grasp abstract concepts. reorganize into logical divisions and synthesize “solutions” based on each division. The model aids the analyst in understanding about the system’s function. The model is the standard entity for review and it is the key to determine completeness. Software requirements must be uncovered in a “top-down” manner. Separate functionality from implementation: As per the definition. Requirements are represented in such a manner that leads to successful software implementation. functional and behavioral domains of software can be partitioned. The ability to understand the user/client environment.. Blazer and Goldman proposed eight principles of good specification and they are given as follows. Firstly we will take up the specification part. There is no doubt on the fact that a complete understanding and clarity of software requirements is essential for the appropriate and suitable software development . firstly the analyst should achieve a high quality specification and the designer should develop a high quality design. Specification Principles Specification methods irrespective of the modes via which they are carried out are basically a representation process.

The above-mentioned methods are different FTR (Formal Technical Review) formats.Specification can have two forms. to verify that the software under review meets its requirements. In this situation the environment is dynamic and its changes affect the behavior of some entity interacting with the environment. To express the same we have to use process-oriented description in which the what specification is expressed by specifying a model of the required behavior in the terms of functional responses to various inputs from the environment. logic or implementation for any representation of the software. The individual or the team that has developed that specific module or product intimates the product is complete and a review may take place. The first form is that of mathematical functions in which as per the given set of inputs a particular set of outputs is produced. to achieve software that is developed in a uniform manner and to make projects more manageable. Similarly. Conduct of Formal Technical Reviews (FTR) The FTR (Formal Technical Review) is a software quality assurance activity with the objectives to uncover errors in function. Thus the result is the mathematical function of the input. It is easier and more productive to review in small parts like each module one by one rather than to review the whole thing in one go. Review meetings Review meeting is important form of FTR (Formal Technical Review) and there are some essential parameters for the meeting such as there should be reasonable number of persons conducting the meeting and that too after each one of them has done his/her homework i. 4. FTR (Formal Technical Review) is also a learning ground for junior developers to know more about different approaches to software analysis. some preparation and the meeting should not be carried out very long which may lead to wastage of time but rather for duration just enough to churn out some constructive results. 3. Now such kind of process-oriented specifications. 2. have been usually excluded from the formal specification languages but one can not do without them if more complex dynamic situations are to be expressed. It also serves as a backup and continuity for the people who are not exposed to the software development so far. Stimulus to active objects or agents as they are called are given by the dynamic relationships and to these the agents respond which may further cause changes to which again the agents respond. In such specifications .e. FTR (Formal Technical Review) activities include walkthroughs. A specification must encompass the system of which the software is a component. design and implementation. a single module. Interacting components make up a system. The description of each component is only possible in the complete context of the entire system therefore usually a system can be modeled as collection of passive and active components. Then the project leader forwards the request to the review leader who further informs the reviewers who undertake the task. FTR (Formal Technical Review) is effective when a small and specific part of the overall software is under scrutiny. These objects are interrelated and their relationship to each other is time-variant. inspection and round robin reviews and other technical assessments. Here no mathematical function can express the behavior. which represent the model of the system behavior. The . the result to be obtained is entirely expressed in a what rather than how form. A process-oriented systems specification language is required: Here we will take up the second form of the specification. to ensure that the software has been represented according to predefined standards. the environment in which the system operates and with which it interacts must be specified. This is similar to the case of embedded computer system. The target of the FTR (Formal Technical Review) is on a component of the project. A specification must encompass the environment in which the system operates.

members of the review meeting are reviewers who undertake the task. The members of the review meeting are reviewers, review-leader, product developers ( or the module leader alone ) and there one of the reviewers takes up the job of the recorder and notes down all the important issues raised in the meeting. At the end of each review meeting the decision has to be taken by the attendees of the FTR (Formal Technical Review) on whether to accept the product without further modification or to reject the product due to severe errors or to accept the product provisionally. All FTR (Formal Technical Review) attendees sign off whatever decision taken. At the end of the review a review issues list and a review summary is report is generated.

Software Testing
System Quality Assurance (SQA) is incomplete without testing and testing is carried out to verify and confirm that the software developed is capable enough to implement, carry out the tasks for which it has been developed. Tests carried should be able to determine any previous undetected errors that might hamper the smooth functioning of the system. There are two different approaches to it. First is the classroom testing where we test and retest the program until they work but in our business environment a more professional approach is taken where we actually try to make the programs fail and then continue testing until we cannot deliberately make them fail any more. Hence the objective is to take care of all possible flaws so that no null, void, vague case or doubt remains before it is installed at the client’s site. The data used for testing can either be an artificial or mock data when the system is new or it can be taken from the old system when a new system has replaced it. The volume of data required is very high for adequate testing. This is because all the data used may not be able to mirror all the real situations that the system will encounter later. Testing is such an important stage in the software development that usually 30% of the software development cycle time is dedicated to it.

Control of change in Software Quality Assurance
During the development of software product, changes are difficult to avoid. There is always a need for some change in the software product. Though these changes must be incorporated into software product, but there should be a specific procedure that must be followed for putting the changes in the product. Before a change is implemented, the required change should be thoroughly analyzed, recorded and reported to people who are responsible for controlling them for quality and errors. For all these activities there is software configuration management(SCM). It is applied throughout the software engineering process as changes can occur at any stage of software development . SCM activities identifies and control changes and ensures that these changes are properly implemented. A typical change control process that is followed in many software development process is illustrated in fig 9.10. First thing is need for change is recognized and request of change is submitted. Developers analyze the request and makes a change report and it is submitted to change control authority. It is up to the authority to grant permission or deny request. In case change request is denied, the user is informed about it. If permission is granted then an Engineer Change Order (ECO) is generated which contains details of the changes to be made. The individual software engineer is assigned the configuration object that requires change. These objects are taken out of system, changes are made upon them and finally changes are reviewed and again they are put into system.

Testing strategy is finalized. Quality assurance and testing activities are performed. Changes done to the system are promoted. New version of software is built. Changes made to the software product are again reviewed and finally the new version with the required changes is distributed. There are two more activities in SCM. These are ‘check in’ and ‘check out’ processes for access control and synchronization control. Access control determines which software engineer has the authority to change and modify a configuration object. More than one software engineer can have the authority over a particular object. Access control is very important it is not advisable to grant access to objects to everyone. Then everybody can make changes to the object Synchronization controls the parallel changes, done by two or more developers. It ensures one developer is not writing over the work of the other developer.

Fig. 9.10 Change Control Process

Fig. 9.11 Access and synchronization control Once it is assigned to a software engineer for change then it is locked for other software engineers who might also have access for it. This process is check-out for that object. The software engineer modifies the object and it is reviewed. It is then check in. That lock that has been put on the object is unlocked and can be given to other software engineers if required. In this way there is no chance of one developer writing over the work of other developer.

Measurement - Software Quality Assurance Activities
Earlier in this chapter we discussed what is the objective and meaning of the quality with respect to software development . We defined a set of qualitative factors of the software quality measurement. Since there is no such thing as absolute knowledge we can’t expect to measure software quality exactly. Therefore SQ metrics is developed and employed to figure out the measure, content of the quality. A set of software metrics is applied to the quantitative assessment of software quality. In all cases these metrics use indirect measures therefore quality as such in itself is never measured but rather some manifestation of it. There are a number of software quality indicators that are based on the measurable design characteristics of a computer program. Design structural quality index (DSQI) is one such measure. The following values must be ascertained to compute the DSQI S1 = the total number of modules defined in the program architecture S2 = the number of modules whose correct function depends on the source of data input or that produces data to be used elsewhere {in general control modules (among others) would not be counted as part of S2} S3 = the number of modules whose correct function depends on prior processing S4 = the number of database items (includes data objects and all attributes that define objects) S5 = the total number of unique database items S6 = the number of database segments ( different records or individual objects)

then wi = 0.(S7/S1) With the intermediate values determined. the product begins to stabilize . IEEE Standard 982.0. the effect of those changes on DSQI can be calculated. and Swi = 1 ( if all Di are weighted equally.(S3/S1) Database size : D4 = 1..1-1988 suggests a software maturity index (SMI) that provides an indication of the stability of a software product ( based on changes that occur for each release of the product). where D1 is defined as follows: If the architectural design was developed using a distinct method( e.g. wi is the relative weighting of the importance of each of the intermediate values. data flow-oriented design or object oriented design). if major changes are to be made to an existing design. The following information is determined: MT = the number of modules in the current release Fc = the number of modules in the current release that have been changed Fa = the number of modules in the current release that have been added Fd = the number of modules from the preceding release that were deleted in the current release The software maturity index is computed as : As SMI approaches 1.S7 = the number of modules with a single entry and exit ( exception processing is not considered to be a multiple exit) When all these values are determined for a computer program. then D1 = 1. the following intermediate values can be computed: Program structure: D1. the DSQI is computed in the following manner: DSQI = Swi Di Where i = 1 to 6. Module independence: D2 = 1 -(S2/S1) Module not dependent on prior processing: D3 = 1.167).(S6/S4) Module entrance/exit characteristic: D6 = 1. further design work and review is indicated. otherwise D1 = 0. If the DSQI is significantly lower than average. Similarly. The value of DSQI for past designs can be determined and compared to a design that is currently under development.(S5/S4) Database compartmentalization: D5 = 1.

Technical Review Summary Report Review identification : Project: XXX00 Date : 11th July'1996 Review Number : X-00012 Location: Old Bldg. Penalty rules Review Team: 1. it is the responsibility of reviewer (or recorder) to record all issues that have been raised. It is applied to During the FTR.Record keeping and reporting in Software Quality Assurance Record keeping and reporting are another quality assurance different stages of software development . 3. Griffin (Leader) 2. This becomes an important document and may be distributed to project leader and other interested parties. A simple review summary report is also compiled. 2. At the end of review meeting. What was reviewed? Who reviewed it ? What were the findings and conclusions? Following figure shows a sample summary report. Watson Product Appraisal: Accepted : as is ( ) with minor modifications ( ) Not Accepted: major revision ( ) minor revision () Review Not completed: ( Explanation follows ) Supplementary material attached: Issue list( ) Annotated Materials ( ) Other (describe) Signature . Material Reviewed : ( note each item separately ) 1. activities. a review issue list that summarizes all issues. Room# 4 Time: 10:00 AM Product Identification Material Reviewed : Detailed Design module for penalty collection Producer : Griffin Brief Description : Penalty collection module for books returned after due date. Hardy (Recorder) 3. A review summary report answers the following questions. is produced. 1.

To serve as an action item checklist that guides the producer as corrections are made. Corrective maintenance Adaptive maintenance Perfective maintenance Follwing figure illustrates the maintenance effort distributionin software maintenance. This is how various techniques and procedures may be used for delivering a quality system to the vendors Software Maintenance It is impossible to produce systems of any size.The review issue list serves the following purpose. . Review Number : XX10 Date of Review : 07-07-98 Review leader : Griffin ISSUE LIST Recorder : Hardy 1. 1. may merge and require repair. Review issue list provides the basis for the follow-up procedure to be carried out. 1. Error. Once all this is done and review findings are incorporated. The process of changing of a system after it has been delivered and is in use is called Software maintenance. After the follow-up procedure. To identify problem areas within the product. really means evolution. Review team recommends a modification in the penalty rules module. There are three types of software maintenance with very blurred distinction between them. in this context. The system's environment will change as new hardware is introduced. undiscovered during system validaton. 2. Penalty rules ambiguous. Over the lifetime of a system. more extensive changes to correct design errors or significant enhancement to correct specification errors or accomodate new requirements. review issue list can be used to cross-check the corrections made. which do not need to be changed. the quality of the system is ensured. 3. 2. Needs more clarity. The penalty rules are not clear. Maintenance therefore. Follwong figure shows a issue list. its original requirements will be modified to reflect changing user and customer needs. It is the process of changing a system to maintain its ability to survive. It is important to establish a follow-up procedure to ensure that items on the issue list have been properly corrected. The changes may involve simple changes to correct coding errors.

which trigger further change requests. 4. There are a number of reasons for this: 1. This makes the system harder to understand and makes further changes difficult as the program becomes less cohesive. New faults may be introduced because the complexity of the system may make it difficult to access the effects of a change. design errors are more expensive as they may involves the rewriting of several programs components. A survey by Lientz and Swanson (1980) discovered that about 65% of maintenance was perfective. These are generated by software customers as their organization are business changes. Requirements errors are the most expensive to repair because of the extensive system redesign with may be necessary. Maintenance has a poor image among software engineers. Maintenance staffs are often relatively inexperienced and unfamiliar with the applications domain.Maintenance Effort Distribution Corrective Maintenance Corrective Maintenance is concerned with fixing reported errors in the software. 18% adaptive and 17% corrective shown in figure. . 2. The costs of adding functionality to a system after it has been put into operation are usually much greater than providing similar functionality when software is originally developed. 3. Changes made to a program may introduce new faults. Perfective maintenance Perfective maintenance involves implementing ne wfunctional or non-functional system requirements. Coding errors are usually relatively cheap to correct. It is seen as a less skilled process than system development and is often allocated to the most junior staff. The program being maintained may have been developed many years ago without modern software engineering techniques. Thay may be unstructured and optimized for efficiency rather than understandability. It is difficult to find up-to-date figures for their relative effort devoted to these different types of maintenance. And also Lientz and Swanson found that large organizations devoted at least 50% of their total programming effort for maintaining existing systems. its structure tends to degrade. Adaptive maintenance Adaptive maintenance means changing the software to new environment such as different hardware platform or for use with a different operating systems. As a system is changed. The software functionality does not radically change.

The links between a program and its associated documentation are sometimes lost during the maintenance process. reviews and test preparation. Boehm (1983) suggested several steps that can improve maintenance staff motivation. Structure naturally degrades with changes. Organizations must plan to invest extra effort and resources in preventive maintenance with the aim of maintaining the structure. 2. Involve maintenance staff early in the software process during standard preparation. which allows the maintenance team to decide when to re-engineer parts of the software. 4. Good software engineerign practice such as the use of information hiding or object-oriented development helps minimize the structure degradation but effort for structure maintenance is still required. management must demonstrate to engineer that maintenance is of equal value and is as challenging as original software development . Create a discretionary. 1. . The best designers and programmers should be challenged and motivated by system maintenance. namely unstructured code. Couple software maintenance rewards to organizational performance Integrate software maintenance personnel into operational teams. Preventive maintenance means making changes to the software. The documentation may therefore be an unreliable aid to program understanding. preventive maintenance budget. can be tackled using reengineering and design recovery tecniques. 5. 3. The second of the above problems. The first of these problems can only be tackled by organization adapting enlightened maintenance management policies. Couple software objectives to organizational goals. The other maintenance problems are process problems.5. which improve its structure so that future maintenance is simplified.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->