System and it s Components

Transcription

1 System and it s Components A system is simply a set of components that interact with each other to accomplish some purpose or a particular goal. I.e. physical sensation is a complex nervous system, it is a set of brain, spinal cord, nerves and special sensitive cells under your skin, that work together to make you fill hot, cod and so on. System of words and symbols, economic system. A business is also a system. Its components are marketing, manufacturing, sales, research, shipping, accounting and personnel all work together to create a profit that benefits the employees and stock holders of the firm. Each of these components is itself a system and it is called subsystem. I.e. the accounting department may consist of accounts payable, account receivable, billing, auditing and so on. Environment : Are the entity outside the boundaries of the system. To achieve their purpose, system interact with their environment. The systems that interact with their environment (receive input & produce output) are called open system. The system that do not interact with their surroundings are called closed systems. In real life all systems are open system. Thus closed systems exists only as a concept. Any system use a basic control model consists of - A standard for acceptable performance. - A method of measuring actual performance. - A means of comparing actual performance against the standard. - A method of feedback. A system that can adjust their activities to acceptable levels continue to function. Those can not eventually stop. System boundary System component Input Actual Standard Output Means of comparison Feedback of result of comparison For example, if a business, produces as output products or services that are at high priced and of low quality people will probably be not continue to buy them. Low sales figures are feedback, telling managements, it needs to adjust the products and the way they are produced to improve performance and bring it into the line with expectation. Information system Every business system depends on a more or less abstract entity called an information system. This system is the means by which data flow from one person/department to

2 another. Information system helps all the system of business, linking the different component in such a way that they effectively work towards the same purpose. The purpose of an information systems are to process input, maintain data and produces information, reports and other output. It consists of subsystems including hardware, software, and data storage for files and database. The particular set of subsystems used the specific equipment, programs, files and procedures constitutes an information systems applications. System analysis and design It refers to the process of examining a business situation with the intent of improving it through better procedures and methods. System development process can be thought of having two major components (i) System analysis and (ii) System design System analysis : It is the process of gathering and interpreting facts, diagnosing problems and using the information to recommend improvements to the system. System design : It is the process of planning a new business system or one to replace or complement an existing system. The system design is like the blue print for a building, it specified all the features that are to be in the finished products. Analysis specifies what the system should do. Design states how to accomplish the objectives. Classical system development life cycle (SDLC) System development process consists of two major steps i.e. system analysis and system design. SDLC is a classical thought of as the set of activities that analysts, designers, and users carry out to develop and implement an information system. SDLC consist of the following six activities : (1) Preliminary investigation (2) Determination of system requirement (3) Design of system (4) Development of software (5) System testing (6) Implementation and evaluation (1) Preliminary investigation : A request is made by a manager, an employee or a system specialist for information system. From this point the first system activity, the preliminary investigation starts. It consists of three parts

3 - Request clarification : The users or the persons who wants the information system, their request are not clear, therefore before any system investigation can be consider, the project request must be examined to determine precisely what the originator wants. - Feasibility study : When ever any user request is clarified, then it is very much important to determine whether the system request is feasible or not. There are three aspects in the feasibility study i.e. Technical feasibility : Can the work for the project be doe with current equipment, existing software technology and available person? Economic feasibility : Are there sufficient benefits in creating the system to make the cost acceptable? Operational feasibility : will the system be used if it is developed and implemented? The feasibility study is carried out by a small group of people who are familiar with information system techniques as well as the routine and detail activities of the organization. - Request approval : All requested projects are not desirable or feasible. However, those projects that are both feasible and desirable should be put into a schedule. If the systems developer are free then the development process will be immediately started otherwise, the proposal will be put into the priority queue depending upon the important. (2) Determination of system requirements : The detailed understanding of all important facts of the business area under investigation is the key point or heart of the system analysis. The analyst must study the business process, so that the questions related to study, can be answered. For these the system analyst has to work with variety of persons to gather details about the business process. As the details are gathered, the analyst study the requirement data to identify features the new system should have. (3) Design of system : The design of information system produces the details that state how a system will meet the requirements identified during systems analysis. Some times this stage is called logical design. In controls to the process of development program software, which is referred to as physical design. System analyst begins the design process by identifying reports and other outputs, usually designer sketch it to appear when the system is complete. This may be done on paper. The system design also describes the data to be input, calculated or stored. Individual data items and calculation procedure are written in detail.

4 The detailed design information is passed on to the programmers with complete and clearly outlined software specifications. As programming starts, designers are available to answer questions, clarify fuzzy areas & handle problems that confront the programmers when using the design specifications. (4) Development of software Software developers may install purchased software or they may write new, custom designed programs. The choice depends on the cost of each option, the time available to write software and the availability of programmers. Programmers are also responsible for documenting the program, providing an explanation of how and why certain procedures are coded in specific ways. (5) System testing In testing, the system is used experimentally to ensure that the software does not fail. I.e. that it will run according to its specifications and in the way users expect. Special test data are inputted for processing, and the result examined. A limited number of users may be allowed to use the system so analyst can see whether they try to use it in unforeseen ways. In many organization testing is performed by persons other than those who wrote the original programs to ensure more complete and unbiased testing and more reliable software. (6) Implementation & evaluation Implementation is the process of having systems personnel check out and put new equipment into use, train users, install he new applications and construct any files of data needed to use it. Evaluation of the system is perform to identify its strengths and weakness. The evaluation process can be categorized in following three way : (i) (ii) (iii) (iv) Operational evaluation : In this, it will determine how system is functioning, it also includes ease of use, response time, suitability of information formats, overall reliability and level of utilization. Organizational impact : Identification and measurement of benefits to the organization in such area as financial concerns (cost, revenue and profit), operational efficiency and competitive impact. User manager assessment : Evaluation of the attitudes of senior and user managers within the organization, as well as end users. Development performance : It measure overall development time and effort, conformance to budgets and standards, and other project management criteria, includes assessment of development methods and tools.

5 What is requirement determination? It studies the current business system to find out how it works and where improvement should be made? These study consider both manual and computer methods A requirement is a feature that must be included in a new system. It may include a way of capturing or processing data, producing information, controlling a business activities or supporting management. Fact finding techniques The analyst does not know the working process of the user for which, he is going to develop information system. The analyst uses specific method for collecting data about requirements are called fact-finding techniques. It includes the interview, questionnaire, record review and observation. Analyst usually employ more than one of these technique to help an accurate and comprehensive investigation. (i) Interview : Analyst use the interview to collect information from individuals or from groups. The respondents are the user of the investigated system. Some analyst always prefer the interview method compare to other fact finding techniques, it is not always best that to collect the data about the application. Because if the number of the user are very high then this process is time consuming, so at that time other fact finding technique should be adopted. In this method respondents and system analyst converse during the interview. Interviews provide analyst with opportunity for gathering information from respondents who have been chosen for their knowledge of the system under study. This method is frequently the best source of qualitative information. This method of fact finding can be especially helpful for gathering information from individuals who do not communicate effectively in writing or who may not have the time to complete questionnaires. It allows the analyst to discover area of misunderstanding, unrealistic expectations, and even indication of resistance to the proposed system. Interview can be structure or unstructured. Unstructured interviews uses a questions and answers format when the analyst want to get the general information about the system. Structured interviews use standardized questions in either an open response or in close response and the answer must be in the pre formatted. Structured interview Advantages - Ensure uniform wording of questions for all respondents - Easy to administer and evaluate - Result in shorter interviews - More objective evaluation of both interviewer and respondent. - Limited interview training needed Disadvantages - Cost of preparation is high - Respondent has to give the answer Unstructured interview Advantages - Interviewer has greater flexibility in wording question to suit respondent - Interviewers can pursue the area that arise at the time of interview. - It may produce the information about the areas that were overlooked or not thought at all. Disadvantages - It may waste the time of both

6 into required and pre define format. - Analyst has to prepare before interviewing. - While taking the interview, the biases may appear. - Some information will be gathered which is of no use. - It takes extra time to collect the actual facts. (ii) Questionnaire : The use of questionnaire allows the analyst to collect the information various aspect of the system from a large number of the users. The use of standard question will leads to collect the more reliable and important data of the studied system. However this method does not allow the system analyst to study the expression of the users. In addition the response may be limited. Analyst often uses the open-ended questionnaire to study the expression or feeling of the system user. To prepare the questions analyst has to work hard and also look for the cost for preparing the questions. (iii) Record review : Many kinds of records and reports can used by the analyst to extract the required information regarding the system and the user of the system. This process is performed at the beginning of the system study. Records include written policy manuals, regulations and standard operating procedures use by the most organization as a guide for managers and employees. (iv) Observation : Observation allows analyst to gain information they can not obtain by any other fact finding technique. Though through observation analyst can secure the first hand activity process. This method is very much useful when analyst needs to actually observe that how the documents are handled, how process are carried out and whether specified steps are actually followed. Experience analyst can gain a lot of thing from the observation, some time which is nearer to impossible collect from other fact finding techniques. Tools for documenting procedure and decisions A tool is any device, object or operations used to accomplish a specific task. System analyst rely on such type of tools. There tools help analyst in so many different ways (i.e. To collect data, present data, explain processes etc.) To explain the procedures or documenting the procedures there are three tools : - Decision tree - Decision table - Structured English When analyst starts the study of any information system, the first question is about, what are possibilities? or what can happen? Means he/she is asking about the condition to take any appropriate action. In real situation the problem is not same, hence the conditions vary for different problems and different situations, so some time it is referred as decision variable. When all possible conditions are known, the analyst next determines what to do when certain condition occurs. Actions are alternatives, the steps, activities or procedures that an

7 individual may decide to take when confronted with a set of conditions. The actions will be simple or it may be complex in different situation. Decision tree : A single matter can be explained in so many different ways, for example, a company might give discount amount on three different values for the condition on size of order (i.e. over 10,000 4 %, in between 5000 to % and below %) and the payment occurs within 10 days or not. The same process can be explained in following different ways. - Greater than 10,000. greater than or equal to 5000 but less than or equal to 10,000 and below Not less than 10,000, not more than 10,000 but at least 5000 and not 5000 or more. Having different ways of saying the same thing can create difficulties in communications during system study. Decision tree is one of the method for describing decisions, while avoiding difficulties in communications. A Decision tree is diagram that presents conditions and actins sequentially and thus shows which conditions to consider first, which second and so on. It is also a method of showing the relationship of each condition and its permissible actions. The diagram resembles branches on a tree. Action Condition Action Condition Action Root Condition Condition Action Action Condition Condition Action Action

8 Action Decision tree The root of the tree, on the left of the diagram, is the storing point of the decision sequence. The particular branch to be followed depends on the conditions that exists and the decision to be made. Progression from left to right in any branch will give the sequence of decision. One decision point will lead to the another decision point. The nodes of the three thus represents conditions and indicates that a determination must be made about which condition exists before the next path can be chosen. The right side of the tree list the actions to be taken, depending upon the sequence of condition that is followed. Developing decision tree is very much beneficial i.e. The need to describe conditions and actions forces analyst to formally identify the actual decision that must be made. It also force analyst to consider the sequence of condition. Over % Within 10 days 5000 to % Below % After 10 days Full payment Decision trees may not always be the best tools for decision analysis. A decision tree for a complex system with many sequence of steps and combination of conditions will be unwieldy. A large number of branches with many paths through them will could rather than aid analysis. When these problem arise, decision table should be considered. Decision table A decision table is a matrix of rows and columns, rather than a tree, that shows conditions and actions. Decision rules, included in a decision table, state what procedure to follow when certain conditions exists.

9 The decision table is made up of four sections : Condition statements, condition entry, action statements, actions entries. The condition statement identifies relevant conditions. Condition entries tell which value, if any applies for a particular condition. Action statements list the set of all steps that can be taken when a certain condition occurs. Action entries shows what specific actions in the set to take when selected conditions or combinations of conditions ate true. Sometimes notes are added below the table of indicate when to use the table or to distinguish it from other decision tables. Condition Decision rules Condition statements Action statements Condition entry Action entry The columns on the right side of the table, linking conditions and actions; form decision rules, which state the conditions that must be satisfied for a particular set of actions to be taken. Condition C1 : Patient has health insurance C2 : Patient has social health ins. Y Y N N Y N Y N Decision rules A1 : Pay only visit charge X A2 : Pay nothing X X A3 : full payment X Structured Analysis The word structure in structured analysis means : - The method attempts to structure the requirements determination process, beginning with documentations of the existing system. - The detailed process that describes the current system. - It is easy to verify when relevant details have been omitted. - Identifies requirements that will include best solutions and strategies for system development opportunities. What is data flow analysis?

10 While developing a system, analyst wants to know the answer to four specific questions : - What processes make up a system? - What data are used in each process? - What data are stored? - What data enters and leaves the system? Data drives the business activities. Systems analyst recognizes the central role of business data in organization. Data flow analysis study the use of data in each activity (i.e. process, stores, retrieved, used, changed & output). Data Flow Diagram (DFD) graphically shows the relation between processes and data. Data dictionary, which formally describes the system data and where they are used. Data flow diagram (DFD) A graphical tool used to describe and analyze the movement of data through a system including the processes, stores of data and delays in the system. DFD are the central tool and the basis from which other components are developed. The transformation of data from input to output, through process, may be described logically and independently of the physical components are called logical DFD. In contrast, physical DFD show the actual implementation and the movement of data between people, departments and workstations. Logical DFD can be completed using only four simple notations. The symbols are developed by two different organizations (i.e. Yourdon and Gane & Sarson). The symbols are as follow (i) Data Flow : It shows the direction of data flow, from an origin to a destination in the form of document, letter, telephone call. Yourdon Gane & Sarson (ii) Processes : People, procedures or device that use or produce data. Yourdon Gane & Sarson (iii) Source & Destination : External sources or destination of data, which may be people, programs, organizations or other entities interact with the system bur are outside its boundary. The term source or sink are interchangeably used with origin & destination.

11 Yourdon Gane & Sarson (iv) Data store : Here data are stored or referenced by a process in the system. Yourdon Gane & Sarson Each component in a DFD is labeled with a descriptive name. Process name are identified with a number. The umber assigned to a specific process does not represent the sequence of process. It is strictly for identification and will take on added value when we study the components that, make up a specific process. D. flow 1 D.F. - 4 Source P1 Destination D F - 2 D F - 5 P2 D F -3 Data store Several data flow can be going on simultaneously. In above DFD d. flow 1 & d; flow 2 may occur I parallel. As the name suggest, DFD concentrate on the data moving through the system, not on device or equipment. Analyst explain why the data are being input or output and what processing s done. It is just as important to determine when data enter the application area and when they leave. Sometimes data are stored for later use or retrieved from previous storage. DFD also show this. Developing Data Flow Diagram : System analyst must first study the current system, that is, the actual activities and processes that occur. In the terminology of structured analysis, this is a study of the physical system. The physical system is translated into a logical description that focus on data and processes. It emphasize data and processes in order to focus on actual activities that occur and the resources needed to perform them, rather than on who performs the work.

12 Data flow diagrams are of two type : - Physical data flow diagram : It is an implementation dependent view of the current system, showing what task are carried out and how they are carried out and how they performed. Its characteristics includes (name of people, form and document names or numbers, names of dept, master & transaction file, equipment & device used, locations, name of procedures etc.) - Logical data flow diagram : It is an implementation independent view of a system, focusing on the flow of the data between processes without any concern of specific devices, storage location or people in the system. Drawing context diagram : The first steps in requirement analysis is to learn about the general characteristics of the business process under investigation. The data flow diagram (fig 1) describes account payable processing at a very general or top level. Account Payable Balance Vendor Invoice Check Account payable Mailing address Vendor data Data dictionary When the volume of data is very large, it is very much difficult for analyst to manage the data definitions. If the information system is very big, then more than one person are working on the same data, at that time, any data defined by any person, can be used by the other person, hence they need the definition or description of the data. Data dictionaries are an integral component of structured analysis, it provides additional information about the system. A data dictionary is a catalog a repository of the elements in a system. As the name suggest, these elements center around data and the way they are structured to meet user requirements and organization needs. It contains a list of all the elements composing the data flowing through a system. The major elements are data flows, data stores and processes. The data dictionary stores details and descriptions of these elements. If data dictionary is developed properly, then any data related questions answer can be extracted from data dictionary.

13 It is developed during data flow analysis and assists the analysts. The stored details are used during system design. Definition of Software Engineering Software Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machine. Fritz Bauer Software Engineering is the application of systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software. Testing System testing is an expensive but critical process that can take as much as 50 percent of the budget from program development. The common view of testing held by users is that it is performed to prove that there are no errors in a program. Therefore the most useful and practical approach is with the understanding that testing is the process of executing a program with the explicit intention of finding errors, that is making the program fail. The tester who may be an analyst, programmer or specialist trained in software testing. It is actually trying to make the program fail. A successful test then is one that finds an error. Code testing : The code testing strategy examines the logic of the program. To follow this testing method, the analyst develops test cases that result in executing every instruction in the program or module, that is every path through the program is tested. Code testing seems to be an ideal method for testing software. However, even if code testing can be performed in its entirety it does not guarantee against software failures. This testing strategy does not indicate whether the code meets its specifications not does it determine whether all aspects are even implemented. Code testing also does not check the range of data that the program will accept even though when software failures occur in actual use. Special testing : To perform special testing, analyst examines the specifications stating what the program should do and how it should perform under various conditions. Then the test case are developed for each condition or combination of conditions and submitted for processing. By examining the result analyst will determine whether the program is working as per the required specification? This strategies treats the program as if it were a black box. The analyst does not look into the program to study the code and is not concerned about whether every instruction or path through the program tested. In that sense specification test is not complete test. However, the assumption is that, if the program meets the specifications, it will not fail.

14 Neither code nor specification testing strategy is ideal. However the specification testing is more efficient strategy, since it focuses on the way software is expected to be used. Unit test : In unit testing the analyst test the programs making up a system. Unit testing focus first on the modules, independently of one another, to locate errors. This enables the tester to detect errors in coding and logic that are contained within that module alone. Unit testing can be performed from the bottom up, starting with the smallest and lowest level modules and proceeding one at a time. Top down testing as the name implies begins with the upper level modules and continue up to the lower level. System testing : System testing performs the testing of integration of each module in the system. It also tests to find discrepancies between the system and its original objective, current specifications and system documentation. The primary concern is the compatibility of individual modules. Analyst are trying to find areas where modules have been designed with different specifications for data length, type and data element name. Peak load testing : There are critical times in many systems, particularly online systems. For example, in banking system, analysts want to know what will happen if all tellers sign on at their terminals at the same time before the start of the business day. Will the system handle them one at a time without incident, will it attempt to handle them at once and be so confused that it locks up. And must be restarted. So such type of testing is looking at real situation. Storage testing : Analyst specify a capacity for the system when it is designed and constructed. Capacities are measured in terms of the number of records that a disk will handle or a file can contain. These capacities are linked to disk space and the size of indices, records keys and so on. Storage testing often requires entering data until the capacity is reached. Comparing the actual and claimed capacities will verify the accuracy of the documentation on the one hand and allow a judgment about actual capacity at the same time. Many of the live systems are not tested in these way, then after implementing the system when it is in running mode, after few days user will realize that the system is not capable to handle the volume of data in master file as well as transaction file. Performance time testing : when analysts are developing a design, their concerns are more on reports, inputs, files and processing sequence than on performance time, although this changes with experience. Performance time testing is conduct prior to implementation to determine how long it takes to receive a response to an inquiry, make a backup copy of a file, or send a transmission and receive a response. It also include test runs to time indexing or restoring of large files of the size the system will have during a typical run or to prepare a report. A system that runs well with only a handful of test transactions may be unacceptably slow when fully loaded.

15 Recovery testing : Analyst must always assume that the system will fail and data will be damaged or lost. Even though plans and procedures are written to cover these situations, they also must be tested. By creating a failure or data loss event where the users are forced to reload and recover from a backup copy, analysts can readily determine whether recovery procedures are adequate. The best designed plans usually are adjusted or augmented after this test. Procedure testing : Documentation and run manuals telling the user how to perform certain functions are tested quite easily by asking the user to follow them exactly through a series of events. Analyst concentrate on the major and critical details of a systems design and include them in the documentation. They also pay attention to the little details. This type of testing not only shows where they are needed but also where they are wrong, that is where actions suggested in the documentation do not match those that must actually be taken to make the system run. Verification and validation Like testing verifications is also intended to find errors. It is performed by executing a program in a simulated environment. Validation refers to the process of using software in a live environment in order to find errors. Verification test is some times called the alpha test. The feedback from the validation phase generally produce changes in the software to deal with errors and failures that uncovered. Then as set of user sites is selected that puts the system into use on a live basis. These beta test site use the system in day-to-day activities. They process live transactions and produce normal system output. The system is live in every sense of the word. Validation may continue for several months. During the course of validation the system, failure may occur and the software will be changed. Continued use may produce additional failures and the need for still more changes. What is Software quality? Explain ISO In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. Whereas quality of conformance is concerned with implementation (see Software Quality Assurance), quality of design measures how valid the design and requirements are in creating a worthwhile product. Software Quality Consist following points conformance to requirements or program specification; related to Reliability Scalability

16 Correctness Completeness Absence of bugs Fault-tolerance Extensibility Maintainability Documentation ISO 9000 is a family of standards for quality management systems. ISO 9000 is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies. Some of the requirements in ISO 9001 (which is one of the standards in the ISO 9000 family) include a set of procedures that cover all key processes in the business; monitoring processes to ensure they are effective; keeping adequate records; checking output for defects, with appropriate and corrective action where necessary; regularly reviewing individual processes and the quality system itself for effectiveness; and facilitating continual improvement A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9000 standard does not guarantee any quality of end products and services; rather, it certifies that formalized business processes are being applied. Indeed, some companies enter the ISO 9001 certification as a marketing tool Although the standards originated in manufacturing, they are now employed across several types of organizations. A "product", in ISO vocabulary, can mean a physical object, services, or software. In fact, according to ISO in 2004, "service sectors now account by far for the highest number of ISO 9001:2000 certificates - about 31% of the total." ISO 9000:2000, Quality management systems Fundamentals and vocabulary. Covers the basics of what quality management systems are and also contains the core language of the ISO 9000 series of standards. A guidance document, not used for certification purposes, but important reference document to understand terms and vocabulary related to quality management systems. In the year 2005, revised ISO 9000:2005 standard has been published, so it is now advised to refer to ISO 9000:2005. Explain Project Management with 3Ps. Effective software project management focuses on the four P's: people, product, process, and project. The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management. A manager who fails to encourage comprehensive

17 customer communication early in the evolution of a project risks building an elegant solution for the wrong problem. The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum. The manager who embarks without a solid project plan jeopardizes the success of the product. 1 The People The cultivation of motivated, highly skilled software people has been discussed since the In fact, the "people factor" is so important that the Software Engineering institute has developed a people management capability maturity model (PM-CMM), "to enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability" [CUR94]. The people management maturity model defines the following key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development. Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective software engineering practices. The PM-CMM is a companion to the software capability maturity model that guides organizations in the creation of a mature software process. Issues associated with people management and structure for software projects are considered later in this chapter. 2 The Product

18 Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress. The software developer and customer must meet to define product objectives and scope. In many cases, this activity begins as part of the system engineering or business process engineering and continues as the first step in software requirements analysis. Objectives identify the overall goals for the product.(from the customer's point of view) without considering how these goals will be achieved. Scope identifies the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these Characteristics in a quantitative manner. Once the product objectives and scope are understood, alternative solutions are considered. Although very little detail is discussed, the alternatives enable managers and practitioners to select a "best" approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and other factors. 3 The Process A software process provides the framework from which a comprehensive plan for software Development can be established. A small number of frame work activities are applicable to all software projects, Regardless of their size or complexity. A number of different task sets-tasks, milestones, work products, and quality assurance points-enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally, umbrellaactivitie

19 such as software quality assurance, software configuration management, and measurement-overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process. 4 The Project We conduct planned and controlled software projects for one primary reason-it is the only known way to manage complexity. And yet, we still struggle. in 1998, industry data indicated that 26 percent of software projects failed outright and 46 percent experienced cost and schedule overruns. Although the success rate for software projects has improved somewhat, our project failure rate remains higher than it should be. In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the project. Explain the Project Planning. In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right. in an excellent paper on software projects, John Reel [REE99] defines ten signs that indicate that an information systems project. 1. Software people don't understand their customer's needs. 2. The product scope is poorly defined. 3. Changes are managed poorly. 4. The chosen technology changes. 5. Business needs changed or are ill-defined. 6. Deadlines are unrealistic. 7. Users are resistant. 8. Sponsorship is lost lor was never properly obtained 9. The project team lacks people with appropriate skills. 10. Managers [and practitioners] avoid best practices and lessons learned.

20 The following are the points of software project. Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objects and expectations for everyone who will be involved in the project. it is reinforced by building the right team (Section 3.2.3) and giving the team the autonomy, authority, and technology needed to do the job. Maintain momentum. Many projects get off to a good start and then slowly disintegrate. To maintain momentum, the project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team's way. Track progress. For a software project, progress is tracked as work products (e.g., specifications, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. in addition, software process and project measures (Chapter 4) can be collected and used to assess progress against averages developed for the software development organization. Make smart decisions. In essence, the decisions of the project manager and the software team should be to "keep it simple." Whenever possible, decide to use commercial off-the-shelf software or existing software components, decide to avoid custom interfaces when standard approaches are available, decide to identify and then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks (You'll need every minute). Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback from team members and customers, and record findings in written form. Explain Risk Management A risk is something that may happen and if it does, will have a positive or negative impact on the project. A few points here. "That may happen" implies a probability of

21 less then 100%. If it has a probability of 100% - in other words it will happen - it is an issue. An issue is managed differently to a risk and we will handle issue management in a later white paper. A risk must also have a probability something above 0%. It must be a chance to happen or it is not a risk. Risk Management Plan There are four stages to risk management planning. They are: Risk Identification Risks Quantification Risk Response Risk Monitoring and Control Risk Identification In this stage, we identify and name the risks. The best approach is a workshop with business and IT people to carry out the identification. Use a combination of brainstorming and reviewing of standard risk lists. There are different sorts of risks and we need to decide on a project by project basis what to do about each type. Business risks are ongoing risks that are best handled by the business. An example is that if the project cannot meet end of financial year deadline, the business area may need to retain their existing accounting system for another year. The response is likely to be a contingency plan developed by the business, to use the existing system for another year. Generic risks are risks to all projects. For example the risk that business users might not be available and requirements may be incomplete. Each organization will develop standard responses to generic risks. Risks should be defined in two parts. The first is the cause of the situation (Vendor not meeting deadline, Business users not available, etc.). The second part is the impact (Budget will be exceeded, Milestones not achieved, etc.). Hence a risk might be defined as "The vendor not meeting deadline will mean that budget will be exceeded". If this format is used, it is easy to remove duplicates, and understand the risk.

22 Risk Quantification Risk need to be quantified in two dimensions. The impact of the risk needs to be assessed. The probability of the risk occurring needs to be assessed. For simplicity, rate each on a 1 to 4 scale. The larger the number, the larger the impact or probability. By using a matrix, a priority can be established. Note that if probability is high, and impact is low, it is a Medium risk. On the other hand if impact is high, and probability low, it is High priority. Risk Response There are four things you can do about a risk. The strategies are: Avoid the risk. Do something to remove it. Use another supplier for example. Transfer the risk. Make someone else responsible. Perhaps a Vendor can be made responsible for a particularly risky part of the project. Mitigate the risk. Take actions to lessen the impact or chance of the risk occurring. If the risk relates to availability of resources, draw up an agreement and get sign-off for the resource to be available. Accept the risk. The risk might be so small the effort to do anything is not worth while. A risk response plan should include the strategy and action items to address the strategy. The actions should include what needs to be done, who is doing it, and when it should be completed. Risk Control The final step is to continually monitor risks to identify any change in the status, or if they turn into an issue. It is best to hold regular risk reviews to identify actions outstanding, risk probability and impact, remove risks that have passed, and identify new risks. The second thing to consider from the definition is "will have a positive or negative impact". Most people dive into the negative risks but what if something goes right Risk management is not a complex task. If you follow the four steps, you can put together a risk management plan for a project in a short space of time. Without a plan, the success of the project, and your reputation as a Project Manager, are on the line. Follow these steps and you will increase your chances of success.