Computer System Analysis and Design

Computers are fast becoming our way of life and one cannot imagine life without computers in todays 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.

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. Analysis, design, and development systems, products, or services requires answering several fundamental questions: WHAT is a system? What is included within a systems boundaries? WHAT role does a system perform within the Users organization?

 What mission applications does the system perform? WHAT results-oriented outcomes does the system produce? These fundamental questions are often difficult to answer. If you are unable to clearly and concisely delineate WHAT the system is, you have a major challenge. Now add the element of complexity in bringing groups of people working on same problem to convergence and consensus on the answers. This is a common problem shared by Users, Acquirers, and System Developers, even within their own organizations. At the end of this lesson you would be able to know about system's concepts, characteristics and various types of Information Systems. You would also be able to understand the system development process.

What is a System?
The term system originates from the Greek term systema, 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 valueadded 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, lets examine each part in detail. System Definition Rationale The definition above captures a number of key discussion points about systems. Lets 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 systems 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 nonoverlapping 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 validatedeither 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 prescribedthat is, boundedoperating environment.

By with a specified outcome, we mean that system stakeholders (Users, shareholders, owners, etc.) expect systems to produce results. The observed behavior, products, by products, or services, for example, must be outcome-oriented, quantifiable, measurable, and verifiable.

By and probability of success, we mean that accomplishment of a specific outcome involves a degree of uncertainty or risk. Thus, the degree of success is determined by various performance factors such as reliability, dependability, availability, maintainability, sustainability, lethality, and survivability.

You need at least four types of agreement on working level definitions of a system: 1. a personal understanding 2. a program team consensus 3. an organizational (e.g., System Developer) consensus, and 4. most important, a contractual consensus with your customer. Why? Of particular importance is that you, your program team, and your customer (i.e., a User or an Acquirer as the Users technical representative) have a mutually clear and concise understanding of the term. Organizationally you need a consensus of agreement among the System Developer team members. The intent is to establish continuity across contract and organizations as personnel transition between programs. Other Definitions of a System National and international standards organizations as well as different authors have their own definitions of a system. If you analyze these, you will find a diversity of viewpoints, all tempered by their personal knowledge and experiences. Moreover, 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. 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. You should then select one that best fits your business application. Depending on your personal viewpoints and needs, the definition stated in this text should prove to be the most descriptive characterization.

Learning to Recognize Types of Systems

Systems occur in a number of forms and vary in composition, hierarchical structure, and behavior. Consider the next high-level examples.

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, Judicial systems, Revenue systems, Taxation systems, Licensing systems, Military systems, Welfare systems, Public safety systems, Parks and recreation systems, Environmental systems If we analyze these systems, we find that they produce combinations of products, by-products, or services. Further analysis reveals most of these fall into one or more classes such as individual versus organizational; formal versus informal; ground-based, sea-based, air-based, space-based, or hybrid; human-inthe-loop (HITL) systems, open loop versus closed loop; and fixed, mobile, and transportable systems.

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 has its defined tasks. All these work in coordination to achieve the overall objective of the system. System engineering requires development of a strong foundation in understanding how to characterize a system, product, or service in terms of its attributes, properties, and performance. As discussed above, a system is a set of components working together to achieve some goal. 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. Resources can be hardware, software or liveware. Hardware resources may include the computer, its peripherals, stationery etc. 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. Thus these resources make an important component of any system. For instance, a Banking system cannot function without the required stationery like cheque books, pass books etc. such systems also need computers to maintain their data and trained staff to operate these computers and cater to the customer requirements.

Procedures Every system functions under a set of rules that govern the system to accomplish the defined goal of the system. This set of rules defines the procedures for the system to Chapter 1 - Introduction to Systems operate. For instance, the Banking systems have their predefined rules for providing interest at different rates for different types of accounts. Data/Information Every system has some predefined goal. For achieving the goal the system requires certain inputs, which are converted into the required output. The main objective of the System is to produce some useful output. Output is the outcome of processing. Output can be of any nature e.g. goods, services or information.

However, the Output must conform to the customer's expectations. Inputs are the elements that enter the system and produce Output. Input can be of various kinds, like material, information, etc. Intermediate Data Various processes process system's Inputs. Before it is transformed into Output, it goes through many intermediary transformations. Therefore, it is very important to identify the Intermediate Data. For example, in a college when students register for a new semester, the initial form submitted by student goes through many departments. Each department adds their validity checks on it. 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. It helps in building the System in a better way. Intermediate forms of data occur when there is a lot of processing on the input data. So, intermediate data should be handled as carefully as other data since the output depends upon it.

Processes The systems have some processes that make use of the resources to achieve the set goal under the defined procedures. These processes are the operational element of the system. 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. A cheque passes through several stages before it actually gets processed and converted. These are some of the processes of the Banking system. All these components together make a complete functional system. Systems also exhibit certain features and characteristics, some of which are:

Objective Standards Environment Feedback Boundaries and interfaces

Objective Every system has a predefined goal or objective towards which it works. A system cannot exist without a defined objective. For example an organization would have an objective of earning maximum possible revenues, for which each department and each individual has to work in coordination. Standards It is the acceptable level of performance for any system. Systems should be designed to meet standards. Standards can be business specific or organization specific. For example take a sorting problem. There are various sorting algorithms. But each has its own complexity. So such algorithm should be used that gives most optimum efficiency. So there should be a standard or rule to use a particular algorithm. It should be seen whether that algorithm is implemented in the system. Environment Every system whether it is natural or man made co-exists with an environment. It is very important for a system to adapt itself to its environment. Also, for a system to exist it should change according to the changing environment. For example, we humans live in a particular environment. As we move to other places, there are changes in the surroundings but our body gradually adapts to

the new environment. If it were not the case, then it would have been very difficult for human to survive for so many thousand years. Another example can be Y2K problem for computer systems. Those systems, which are not Y2K compliant, will not be able to work properly after year 2000. For computer systems to survive it is important these systems are made Y2K compliant or Y2K ready. Feed Back Feedback is an important element of systems. 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. In fig 1.1, it is shown that a system takes input. It then transforms it into output. 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.

Boundaries and Interfaces Every system has defined boundaries within which it operates. Beyond these limits the system has to interact with the other systems. For instance, Personnel system in an organization has its work domain with defined procedures. If the financial details of an employee are required, the system has to interact with the Accounting system to get the required details. Interfaces are another important element through which the system interacts with the outside world. System interacts with other systems through its interfaces. Users of the systems also interact with it through interfaces.

Therefore, these should be customized to the user needs. These should be as user friendly as possible.

Classifications of System
From previous section we have a firm knowledge of various system components and its characteristics. There are various types of system. To have a good understanding of these systems, these can be categorized in many ways. Some of the categories are open or closed, physical or abstract and natural or man made information systems, which are explained next. Classification of systems can be done in many ways. Physical or Abstract System Physical systems are tangible entities that we can feel and touch. These may be static or dynamic in nature. For example, take a computer center. Desks and chairs are the static parts, which assist in the working of the center. Static parts don't change. The dynamic systems are constantly changing. Computer systems are dynamic system. Programs, data, and applications can change according to the user's needs. Abstract systems are conceptual. These are not physical entities. They may be formulas, representation or model of a real system. Open Closed System Systems interact with their environment to achieve their targets. Things that are not part of the system are environmental elements for the system. Depending upon the interaction with the environment, systems can be divided into two categories, open and closed. Open systems: Systems that interact with their environment. Practically most of the systems are open systems. An open system has many interfaces with its

environment. It can also adapt to changing environmental conditions. It can receive inputs from, and delivers output to the outside of system. An information system is an example of this category. Closed systems:Systems that don't interact with their environment. Closed systems exist in concept only. Man made Information System The main purpose of information systems is to manage data for a particular organization. Maintaining files, producing information and reports are few functions. An information system produces customized information depending upon the needs of the organization. These are usually formal, informal, and computer based. Formal Information Systems: It deals with the flow of information from top management to lower management. Information flows in the form of memos, instructions, etc. But feedback can be given from lower authorities to top management. Informal Information systems: Informal systems are employee based. These are made to solve the day to day work related problems. Computer-Based Information Systems: This class of systems depends on the use of computer for managing business applications. These systems are discussed in detail in the next section.

Information Systems
In the previous section we studied about various classification of systems. Since in business we mainly deal with information systems we'll further explore these systems. We will be talking about different types of information systems prevalent in the industry.

Information system deals with data of the organizations. The purposes of Information system are to process input, maintain data, produce reports, handle queries, handle on line transactions, generate reports, and other output. These maintain huge databases, handle hundreds of queries etc. The transformation of data into information is primary function of information system. These types of systems depend upon computers for performing their objectives. A computer based business system involves six interdependent elements. These are hardware (machines), software, people (programmers, managers or users), procedures, data, and information (processed data). All six elements interact to convert data into information. System analysis relies heavily upon computers to solve problems. For these types of systems, analyst should have a sound understanding of computer technologies. In the following section, we explore three most important information systems namely, transaction processing system, management information system and decision support system, and examine how computers assist in maintaining Information systems.

Types of Information Systems

Information systems differ in their business needs. Also depending upon different levels in organization information systems differ. Three major information systems are
1. 2.

Transaction processing systems Management information systems Decision support systems

3.

Figure 1 shows relation of information system to the levels of organization. The information needs are different at different organizational levels. Accordingly

the information can be categorized as: strategic information, managerial information and operational information. Strategic information is the information needed by top most management for decision making. For example the trends in revenues earned by the organization are required by the top management for setting the policies of the organization. This information is not required by the lower levels in the organization. The information systems that provide these kinds of information are known as Decision Support Systems.

Figure 1 - Relation of information systems to levels of organization

The second category of information required by the middle management is known as managerial information. The information required at this level is used for making short term decisions and plans for the organization. Information like sales analysis for the past quarter or yearly production details etc. fall under this category. Management information system (MIS) caters to such information needs of the organization. Due to its capabilities to fulfill the managerial information needs of the organization, Management Information Systems have become a necessity for all big organizations. And due to its vastness, most of the big organizations have separate MIS departments to look into the related issues and proper functioning of the system.

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. This kind of information is required at the operational level for carrying out the day-to-day operational activities. Due to its capabilities to provide information for processing transaction of the organization, the information system is known as Transaction Processing System or Data Processing System. Some examples of information provided by such systems are processing of orders, posting of entries in bank, evaluating overdue purchaser orders etc. Transaction Processing Systems TPS processes business transaction of the organization. Transaction can be any activity of the organization. Transactions differ from organization to organization. For example, take a railway reservation system. Booking, cancelling, etc are all transactions. Any query made to it is a transaction. However, there are some transactions, which are common to almost all organizations. Like employee new employee, maintaining their leave status, maintaining employees accounts, etc. This provides high speed and accurate processing of record keeping of basic operational processes. These include calculation, storage and retrieval. Transaction processing systems provide speed and accuracy, and can be programmed to follow routines functions of the organization. Management Information Systems These systems assist lower management in problem solving and making decisions. They use the results of transaction processing and some other information also. It is a set of information processing functions. It should handle queries as quickly as they arrive. An important element of MIS is database.

A database is a non-redundant collection of interrelated data items that can be processed through application programs and available to many users. Decision Support Systems These systems assist higher management to make long term decisions. These type of systems handle unstructured or semi structured decisions. 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. These are not of recurring nature. Some recur infrequently or occur only once. A decision support system must very flexible. The user should be able to produce customized reports by giving particular data and format specific to particular situations. Summary of Information Systems
Catagories of Information System Transaction Processing System Characteristices Substitutes computer-based processing for manual procedures. Deals with well-structured processes. Includes record keeping applications. Provides input to be used in the managerial decision process. Deals with supporting well structured decision situations. Typical information requirements can be anticipated. Provides information to managers who must make judgements about particular situations. Supports decision-makers in situations that are not well structured.

Management information system

Decision support system

Brief Introduction to System Analysis and Design

System development can generally be thought of having two major components: systems analysis and systems design. 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. Thus, system analysis is the process of investigating a system, identifying problems, and using the information to recommend improvements to the system.

Stages in building an improved system The above figure shows the various stages involved in building an improved system. System design is the process of planning a new business system or one to replace or complement an existing system. Analysis specifies what the system should do. Design states how to accomplish the objective.

After the proposed system is analyzed and designed, the actual implementation of the system occurs. After implementation, working system is available and it requires timely maintenance. See the figure above.

Role of System Analyst

The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization. Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following
1) System analysis

It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.
2) System analysis and design:

Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.
3) Systems analysis, design, and programming:

Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application. Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses. 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.

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, like desktop operators. Further, end users can be divided into various categories. Very first users are the hands-on users. They actually interact with the system. They are the people who feed in the input data and get output data. Like person at the booking counter of a gas authority. This person actually sees the records and registers requests from various customers for gas cylinders. Other users are the indirect end users who do not interact with the systems hardware and software. However, these users benefit from the results of these systems. These types of users can be managers of organization using that system. There are third types of users who have management responsibilities for application systems. These oversee investment in the development or use of the system.

Fourth types of users are senior managers. They are responsible for evaluating organization's exposure to risk from the systems failure.

Introduction to Systems: Summary and Review Questions

1. Summary 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. 2. 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. Differentiate between a) Open and closed system b) Physical and abstract

8. 9.

Main aim of an information system is to process _________. Transaction processing, __________________ , and decision support system are three types of information system.

10.

State true or false Decision support system is for middle level management.

Closed systems don't interact with their environment. Transaction processing system handles day-to-day operations of the organization.

Management information system deals with strategic information of organization.

Problem solving and interpersonal skills are desirable for system analyst.

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. 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 methodology for system development.

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. 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.

Activities involved Software Development life cycle model (SDLC)

Problem solving in software consists of these activities: 1. Understanding the problem 2. Deciding a plan for a solution 3. Coding the planned solution 4. 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 precedures 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: 1. Requirement Analysis / Determination of System's Requirements 2. Design of system 3. Development (coding) of software 4. System Testing In addition to the activities performed during software development, some activities are performed after the main development is complete. There is often an installation (also called implementation) phase, which is concerned with actually installing the system on the client's computer systems and then testing it. Then, there is software maintenance. Maintenance is an activity that commences after the software is developed. Software needs to be maintained not because some of its components "wear out" and need to be replaced, but because there are often some residual errors remaining in the system which must be removed later as they are discovered. Furthermore, the software often must be upgraded and enhanced to include more "features" and provide more services. This also requires modification of the software, Therefore, maintenance in unavoidable for software systems.

In most commercial software developments there are also some activities performed before the requirement analysis takes place. These can be combined into a feasibility analysis phase. In this phase the feasibility of the project is analyzed, and a business proposal is put forth with a very general plan for the project and some cost estimates. For feasibility analysis, some understanding of the major requirements of the system is essential. Once the business proposal is accepted or the contract is awarded, the development activities begin starting with the requirements analysis phase. Following topics describes the above mentioned phases:
1. 2.

Preliminary Investigation Requirement Analysis / Determination of System's Requirements Design of system Development (coding) of software System Testing Software Maintenance Error distribution with phases

3.

4.

5.

6.

7.

Preliminary Investigation
Fig 2.1 shows different stages in the system's life cycle. It initiates with a project request. First stage is the preliminary analysis. The main aim of preliminary analysis is to identify the problem. First, need for the new or the enhanced system is established. Only after the recognition of need, for the proposed system is done then further analysis is possible. Suppose in an office all leave-applications are processed manually. Now this company is recruiting many new people every year. So the number of employee

in the company has increased. So manual processing of leave application is becoming very difficult. So the management is considering the option of automating the leave processing system. If this is the case, then the system analyst would need to investigate the existing system, find the limitations present, and finally evaluate whether automating the system would help the organization. Once the initial investigation is done and the need for new or improved system is established, all possible alternate solutions are chalked out. All these systems are known as "candidate systems". All the candidate systems are then weighed and the best alternative of all these is selected as the solution system, which is termed as the "proposed system". The proposed system is evaluated for its feasibility. Feasibility for a system means whether it is practical and beneficial to build that system. Feasibility is evaluated from developer and customer's point of view. Developer sees whether they have the required technology or manpower to build the new system. Is building the new system really going to benefit the customer. 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. The feasibility of the system is evaluated on the three main issues: technical, economical, and operational. Another issue in this regard is the legal feasibility of the project.

1- Planning:**User request *Feasibility study

1.

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. Legal feasibility: It checks if there are any legal hassle in developing the system.

2.

3.

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?

*Project plan

*Project proposal

Technical feasibility: Can the development of the proposed system be done with current equipment, existing software technology, and available personnel? Does it require new technology?
4.

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. Legal feasibility: It checks if there are any legal hassle in developing the system.

5.

6.

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, a report detailing the nature and scope of the proposed solution. 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. If the project seems feasible and desirable then the project is finally approved otherwise no further work is done on it.

88888888888888888888888888888888888888888888888888 888888888888888888888888888888888888888888888888 88

Determination of System's requirements: Analysis phase in SDLC

Requirements Analysis is done in order to understand the problem for which the software system is to solve. For example, the problem could be automating an existing manual process, or developing a completely new automated system, or a combination of the two. For large systems which have a large number of features, and that need to perform many different tasks, understanding the requirements of the system is a major task. The emphasis in requirements Analysis is on identifying what is needed from the system and not how the system will achieve it goals. This task is complicated by the fact that there are often at least two parties involved in software development - a client and a developer. The developer usually does not understand the client's problem domain, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirements Analysis. In most software projects, the requirement phase ends with a document describing all the requirements. In other words, the goal of the requirement specification phase is to produce the software requirement specification document. The person responsible for the requirement analysis is often called the analyst. There are two major activities in this phase - problem understanding or analysis and requirement specification in problem analysis; the analyst has to understand the problem and its context. Such analysis typically requires a thorough understanding of the existing system, the parts of which must be automated. Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of document, some specification language has to be selected (example: English, regular expressions, tables, or a combination of

these). The requirements documents must specify all functional and performance requirements, the formats of inputs, outputs and any required standards, and all design constraints that exits due to political, economic environmental, and security reasons. The phase ends with validation of requirements specified in the document. The basic purpose of validation is to make sure that the requirements specified in the document, actually reflect the actual requirements or needs, and that all requirements are specified. Validation is often done through requirement review, in which a group of people including representatives of the client, critically review the requirements specification.
Software Requirement or Role of Software Requirement Specification (SRS)

IEEE (Institute of Electrical and Electronics Engineering) defines as, 1. A condition of capability needed by a user to solve a problem or achieve an objective; 2. A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document. Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capabilities that system, which is yet to be developed, should have. It is because we are dealing with specifying a system that does not exist in any form that the problem of requirements becomes complicated. Regardless of how the requirements phase proceeds, 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?. The basic goal of the requirement phase is to produce the Software Requirement Specification (SRS), which describes the complete external behavior of the proposed 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 phase is the first step in moving from problem domain to the solution domain. The design of a system is perhaps the most critical factor affecting the quality of the software, and has a major impact on the later phases, particularly testing and maintenance. The output of this phase is the design document. This document is similar to a blue print or plan for the solution, and is used later during implementation, testing and maintenance. The design activity is often divided into two separate phase-system design and detailed design. System design, which is sometimes also called top-level design, aims to identify the modules that should be in the system, the specifications of these modules, and how they interact with each other to produce the desired results. At the end of system design all the major data structures, file formats, output formats, 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. 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, which is independent of the target language in which the software will eventually be implemented. In system design the focus is on identifying the modules, whereas during detailed design the focus is on designing the logic for each of the

modules. In other words, in system design the attention is on what components are needed, while in detailed design how the components can be implemented in software is the issue. During the design phase, often two separate documents are produced. One for the system design and one for the detailed design. Together, these documents completely specify the design of the system. That is they specify the different modules in the system and internal logic of each of the modules. A design methodology is a systematic approach to creating a design by application of set of techniques and guidelines. Most methodologies focus on system design. The two basic principles used in any design methodology are problem partitioning and abstraction. A large system cannot be handled as a whole, and so for design it is partitioned into smaller systems. Abstraction is a concept related to problem partitioning. When partitioning is used during design, the design activity focuses on one part of the system at a time. Since the part being designed interacts with other parts of the system, a clear understanding of the interaction is essential for properly designing the part. For this, abstraction is used. An abstraction of a system or a part defines the overall behavior of the system at an abstract level without giving the internal details. While working with the part of a system, a designer needs to understand only the abstractions of the other parts with which the part being designed interacts. The use of abstraction allows the designer to practice the "divide and conquer" technique effectively by focusing one part at a time, without worrying about the details of other parts. Like every other phase, the design phase ends with verification of the design. If the design is not specified in some executable language, the verification has to be done by evaluating the design documents. One way of doing this is thorough

reviews. Typically, at least two design reviews are held-one for the system design and one for the detailed and one for the detailed design.

Development of Software - Coding Stage/Phase in SDLC

Once the design is complete, most of the major decisions about the system have been made. The goal of the coding phase is to translate the design of the system into code in a given programming language. For a given design, the aim of this phase is to implement the design in the best possible manner. The coding phase affects both testing and maintenance profoundly. A well written code reduces the testing and maintenance effort. Since the testing and maintenance cost of software are much higher than the coding cost, the goal of coding should be to reduce the testing and maintenance effort. Hence, during coding the focus should be on developing programs that are easy to write. Simplicity and clarity should be strived for, during the coding phase. An important concept that helps the understandability of programs is structured programming. The goal of structured programming is to arrange the control flow in the program. That is, program text should be organized as a sequence of statements, and during execution, the statements are executed in the sequence in the program. For structured programming, a few single-entry-single-exit constructs should be used. These constructs includes selection (if-then-else), and iteration (while - do, repeat - until etc). With these constructs it is possible to construct a program as sequence of single - entry - single - exit constructs. There are many methods available for verifying the code. Some methods are static in nature that is, that is

they do not involve execution of the code. Examples of such methods are data flow analysis, code reading, code reviews, testing (a method that involves executing the code, which is used very heavily). In the coding phase, the entire system is not tested together. Rather, the different modules are tested separately. This testing of modules is called "unit testing". Consequently, this phase is often referred to as "coding and unit testing". The output of this phase is the verified and unit tested code of the different modules.

System Testing
Testing is the major quality control measure employed during software development. Its basic function is to detect errors in the software. During requirement analysis and design, the output is a document that is usually textual and non-executable. After the coding phase, computer programs are available that can be executed for testing phases. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phases. Thus, the goal of testing is to uncover requirement, design or coding errors in the programs. Consequently, different levels of testing are employed. The starting point of testing is unit testing. In this a module is tested separately and is often performed by the coder himself simultaneously with the coding of the module. The purpose is to execute the different parts of the module code to detect coding errors. After this the modules are gradually integrated into subsystem, which are then integrated themselves eventually form the entire system. During integration of modules, integration testing is performed. The goal of this testing is to detect design errors, while focusing on testing the interconnection between modules. After the system is put together, system testing is performed. 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. Finally, acceptance testing

is performed to demonstrate to the client, on the real life data of the client, the separation of the system. For testing to be successful, proper selection of test cases is essential. There are two different approaches to selecting test cases-functional testing and structural testing. In functional testing the software for the module to be tested is treated as black box, and then test cases are decided based on the specifications of the system or module. For this reason, this form of testing is also called "black box testing". The focus is on testing the external behavior of the system. In structural testing the test cases are decided based on the logic of the module to be tested. Structural testing is sometimes called "glass box testing". Structural testing is used for lower levels of testing and functional testing is used for higher levels. Testing is an extremely critical and time-consuming activity. It requires proper planning of the overall testing process. Frequently the testing process starts with the test plan. This plan identifies all the testing related activities that must be performed and specifies the schedule, allocates the resources, and specify guidelines for testing. The test plan specifies manner in which the modules will integrate together. Then for different test units, a test case specification document is produced, which lists all the different test cases, together with the expected outputs, that will be used for testing. During the testing of the unit, the specified test cases are executed and actual result is compared with the expected output. The final output of the testing phases is to the text report and the error report, or set of such reports (one of each unit is tested). 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.

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. Since the modules are small in size, individual programmers can do unit testing on their respective modules. So unit testing is basically white box oriented. Procedural design descriptions are used and control paths are tested to uncover errors within individual modules. Unit testing can be done for more than one module at a time. 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. Local data structures: these are tested to see if the local data within unit(module) is stored properly by them. Boundary conditions: It is observed that much software often fails at boundary conditions. That's why boundary conditions are tested to ensure that the program is properly working at its boundary conditions. Independent paths: All independent paths are tested to see that they are properly executing their task and terminating at the end of the program.

Error handling paths: These are tested to check if errors are handled properly by them.

See fig. 2.2 for overview of unit testing

Fig 2.2 Unit Testing

Unit Testing Procedure

Fig 2.3 Unit Test Procedure Unit testing begins after the source code is developed, reviewed and verified for the correct syntax. Here design documents help in making test cases. Though each module performs a specific task yet it is not a standalone program. It may need data from some other module or it may need to send some data or control information to some other module. Since in unit testing each module is tested individually, so the need to obtain data from other module or passing data to other module is achieved by the use of stubs and drivers. Stubs and drivers are used to simulate those modules. A driver is basically a program that accepts test case data and passes that data to the module that is being tested. It also prints the relevant results. Similarly stubs are also programs that are used to replace modules that are subordinate to the module to be tested. It does minimal data manipulation, prints verification of entry, and returns. Fig. 2.3 illustrates this unit test procedure.

Drivers and stubs are overhead because they are developed but are not a part of the product. 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. So next stage of testing deals with the errors that occur while integrating modules. That's why next testing done is called integration testing, which is discussed next.

Integration Testing
Unit testing ensures that all modules have been tested and each of them works properly individually. Unit testing does not guarantee if these modules will work fine if these are integrated together as a whole system. 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. Following types of errors may arise:
Data can be lost across an interface. That is data coming out of a module is not going into the desired module. Sub-functions, when combined, may not produce the desired major function. Individually acceptable imprecision may be magnified to unacceptable levels. For example, in a module there is error-precision taken as +- 10 units. In other module same error-precision is used. Now these modules are combined. 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. Global data structures can present problems: For example, in a system there is a global memory. Now these modules are combined. All are accessing the same global memory. Because so many functions are accessing that memory, low memory problem can arise. Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing. The objective is to take unit tested modules, integrate them, find errors, remove them and build the overall program structure as specified by design. There are two approaches in integration testing. One is top down integration and the other is bottom up integration. Now we'll discuss these approaches. Top-Down Integration

Bottom-Up Integration

Top-Down Integration in Integration Testing

Top-down integration is an incremental approach to construction of program structure. In top down integration, first control hierarchy is identified. That is which module is driving or controlling which module. Main control module, modules sub-ordinate to and ultimately sub-ordinate to the main control block are integrated to some bigger structure. For integrating depth-first or breadth-first approach is used.

Fig. 9.6 Top down integration In depth first approach all modules on a control path are integrated first. See fig. 9.6. Here sequence of integration would be (M1, M2, M3), M4, M5, M6, M7, and M8. In breadth first all modules directly subordinate at each level are integrated together. Using breadth first for fig. 9.6 the sequence of integration would be (M1, M2, M8), (M3, M6), M4, M7, andM5.

Bottom-Up Integration in Integration Testing

Bottom-up integration testing starts at the atomic modules level. Atomic modules are the lowest levels in the program structure. Since modules are integrated from the bottom up, processing required for modules that are subordinate to a given level is always available, so stubs are not required in this approach. A bottom-up integration implemented with the following steps: 1. Low-level modules are combined into clusters that perform a specific software subfunction. These clusters are sometimes called builds. 2. A driver (a control program for testing) is written to coordinate test case input and output. 3. The build is tested.

4. Drivers are removed and clusters are combined moving upward in the program structure.

Fig. 9.7 (a) Program Modules (b)Bottom-up integration applied to program modules in (a) Fig 9.7 shows the how the bottom up integration is done. Whenever a new module is added to as a part of integration testing, the program structure changes. There may be new data flow paths, some new I/O or some new control logic. These changes may cause problems with functions in the tested modules, which were working fine previously. To detect these errors regression testing is done. 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. 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. As integration testing proceeds, the number of regression tests can grow quite large. Therefore, regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program functions. It is impractical and inefficient to re-execute every test for every program functions once a change has occurred.

Black Box Testing

Black box testing test the overall functional requirements of product. Input are supplied to product and outputs are verified. If the outputs obtained are same as the expected ones then the product meets the functional requirements. In this approach internal procedures are not considered. It is conducted at later stages of testing. Now we will look at black box testing technique. Black box testing uncovers following types of errors. 1. 2. 3. 4. 5. Incorrect or missing functions Interface errors External database access Performance errors Initialization and termination errors.

The following techniques are employed during black box testing

Equivalence Partitioning
In equivalence partitioning, a test case is designed so as to uncover a group or class of error. This limits the number of test cases that might need to be developed otherwise. Here input domain is divided into classes or group of data. These classes are known as equivalence classes and the process of making equivalence classes is called equivalence partitioning. Equivalence classes represent a set of valid or invalid states for input condition. An input condition can be a range, a specific value, a set of values, or a boolean value. Then depending upon type of input equivalence classes is defined. For defining equivalence classes the following guidelines should be used. 1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined. 2. If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined. 3. If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined. 4. If an input condition is Boolean, then one valid and one invalid equivalence class are defined. For example, the range is say, 0 < count < Max1000. Then form a valid equivalence class with that range of values and two invalid equivalence classes, one with values less than the lower bound of range (i.e., count < 0) and other with values higher than the higher bound( count > 1000).

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. These values often lie on the boundary of the equivalence class. 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. In boundary value analysis, we choose input for a test case from an equivalence class, such that the input lies at the edge of the equivalence classes. Boundary values for each equivalence class,

including the equivalence classes of the output, should be covered. Boundary value test cases are also called extreme cases. Hence, 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. In case of ranges, 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. For example, if the range is 0.0 <= x <= 1.0, then the test cases are 0.0,1.0for valid inputs and 0.1 and 1.1 for invalid inputs. For boundary value analysis, the following guidelines should be used: For input ranges bounded by a and b, test cases should include values a and b and just above and just below a and b respectively. If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits. If internal data structures have prescribed boundaries, a test case should be designed to exercise the data structure at its boundary. Now we know how the testing for software product is done. But testing software is not an easy task since the size of software developed for the various systems is often too big. Testing needs a specific systematic procedure, which should guide the tester in performing different tests at correct time. This systematic procedure is testing strategies, which should be followed in order to test the system developed thoroughly. Performing testing without some testing strategy would be very cumbersome and difficult.

SDLC - 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. As we have mentioned earlier, software often has design faults. The two major forms of maintenance activities are adaptive maintenance and corrective maintenance. It is generally agreed that for large systems, removing all the faults before delivery is extremely difficult and faults will be discovered long after the system is installed. As these faults are detected, they have to be removed. Maintenance activities related to fixing of errors fall under corrective maintenance. Removing errors is one of the activities of maintenance. Maintenance also needed due to a change in the environment or the requirements of the system. The introduction of a software system affects the work environment. This change in environment often changes what is desired from the system. Furthermore, often after the system is installed and the users have had a chance to work with it for sometime, requirements that are not identified during requirement analysis phase will be uncovered. This occurs, since the experience with the software helps the user to define the needs more precisely. There might also be changes in the input data, the system environment and output formats. All these require modification of the software. The maintenance activities related to such modification fall under adaptive maintenance. Maintenance work is based on existing software, as compared to development work, which creates new software. Consequently maintenance resolves around understanding the existing software and spares most of their time trying to understand the software that they have to modify. Understanding the software involves not only understanding the code, but also the related documents. During the modification of the software, 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. To test whether those aspects in the system that are not supposed to be modified are operating as they were before modification, regression testing is done. Regression testing involves executing old

test cases to test that no new errors have been introduced. Thus, maintenance involves understanding the existing software (code and related documents), understanding the effects of change, making the changes - both to the code and documents, testing the new parts (changes), and resetting of the old parts that were not changed. Since often during development, needs of the maintainers are not kept in mind, little support documents are produced during development to aid the maintainer. 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.