Software Engineering Paradigms : Software Characteristics, Software myths, Software Applications, Software Engineering Definitions, Various Software Process

Models, Process iteration, Process activities, The Rational Unified Process, Computer-aided software engineering Project Management, Management activities, Project planning, Project scheduling, Risk management Software Requirements, Functional and non-functional requirements, User requirements, System requirements, Interface specification, software requirement document Requirements Engineering Processes, Feasibility studies, Requirements elicitation and analysis, Requirements validation, Requirements management System Models, Critical Systems Specification, Risk-driven specification, Safety specification, Security specification, Software reliability specification Software Metrics and Measures Process Metrics, Project metrics, Software Project Planning, Empirical, Putnam, COCOMO. Risk Identification and Projection: RMMM, Project Scheduling and Tracking. Application Architectures Data processing systems, Transaction processing systems, Event processing systems, Language processing systems, User Interface Design Design issues, The user interface design process, User analysis, User interface prototyping, Interface evaluation Rapid Software Development Agile methods, Extreme programming, Rapid application development, Software prototyping. Software Reuse Design patterns, Generator-based reuse, Application frameworks, Application system reuse, Software Evolution Verification and validation, Verification and Validation Planning verification and validation, Software inspections, Automated static analysis, Verification and formal methods. Software Testing System testing, Component testing, Test case design, Test automation. Software Cost Estimation Software productivity, Estimation techniques, Algorithmic cost modeling, Project duration and staffing. Quality Management Process and product quality, Quality assurance and standards, Quality planning, Quality control, Software measurement and metrics Process Improvement Process and product quality improvement, Process classification, Process measurement Process analysis and modeling, Process change, The CMMI process improvement framework.

1. 0 Software Engineering Paradigms 1.1 Software Characteristics : Set of instructions written in a sequence to carry
out any specific task is called Program. Set of such programs is called software. It also includes data structures that enable the programs to adequately manipulation information and documents that describe the operation and use of the programs. Software is logical rather than physical system element. It possess the following characteristics : Software is developed or engineered, it is not manufacture in the classical sense. Therefore some separate care is to be done for its development. Software does not wear out but it detoriates. The failure rate of hardware is bit high where as that of the software is not high. The failure curve of hardware is represented using bathtub curve. Software is not susceptible to environment maladies that causes hardware to wear out. Failure Rate

Failure Rate

Wear Out

Ideal Curve Time Failure Curve for Software

Time Failure Curve for Hardware

Although the industry is moving toward component based assembly, most software continues to be custom built.

1.2 Software Myths : There are some mis-conception about Software called software
Myths. The software myths propagate misinformation and confusions. These myths ar classified into three categories viz. Management Myths, Customer Myths and Practitioners Myths. a. Management Myths : The Manager with software responsibility are under pressure to maintain budgets, keep schedule etc. Some of the myths related to this categories are as follows : There is a book consisting of standard procedure for building software. It will be sufficient for the development of the software. (As a real fact it is yet to determine that practioners are aware of it or not. Does it reflect modern development proccedures or not etc.) State-of-art software development tools are available. (As a real fact the development professionals even require it to use them efficiently, simple availability will not be sufficient.) If the development is lacking its schedule then by arranging more programmmer will catch the schedule properely. (As a real fact adding more programmer at later stage will add more delay in it.)

 By outsourcing the software development, the manager can get relax. (As a real fact the manager will now be in more trouble). b. Customer Myths : These Myths leads to false expactation and ultimately results in dis-satisfaction. There are following myths of this nature. A general statement of objectives is sufficient to begin writing of programs and the details can be filled later. (As a real fact the poor definition always results in improper development.) The projects requirement regularly change and these changes can easily be accomodated later. (As a real fact no ammendments are practically possile after development of the software.) c. Practioner Myths : Following are some myhs of this nature. Once a program is written and has started to work then the job is over. (As a real fact the job of maintenance starts at this stage). The qualiy of software can be assessed only after its development. (As a real fact the quality can be anticipated before its development). Software engineering will create un-necessary documentation. (As a real fact documents created are all essential).

1.3 Software Application : The software may be applied to many segments of our
life. Information contents and determinancy are two important factors used to determine nature of software application. Contents refers to the meaning and form of incomming and out going information. Information determinancy refers to the predictability of the order and timing of information. Following are the area of application for software. System Software : System software is a collection of programs written toservice other programs. e.g. compilers, editors, operating systems, linkers, loaders, drivers etc. The system software are characterized by heavy interaction with the computer hardware, heavy usange by multi users, concurrent operation etc. Real-Time Software : The softwares which controls the events / data as and when they occurs are called real-time softwares. Hence these software are characterized by quick response or reaction without any delay. Business Software : It is the larges application area. Various tasks of business like payroll, inventory, accounting and different MIS softwares as per requirements are some of the examples of this nature. Engineering and Scientific Software : These software ar characterized by number crunching algorithms. These software performs large complicated operation with a set of small data. E.g. CAD, CAM etc. Embeded Software : These softwares rside in the read only memory provided with the industrial product. Generally these softwares are used to automate the operations of the product. E.g. automation of washing machine, microware oven etc. Personel Computer Software : Some applications like word processing, spread sheets, graphics, multi-media, DBMS etc are examples of personnel computer softwares. Web-based software : Various web enabled softwares which supports the user to interact with the system by providing the data and getting required results. E.g. online banking etc. These software are in the form of a collection of web pagaes.

Artificial Intelligence software : These softwares make use of non-numerical algorithms to solve complex problems. E.g. Expert System, Neural Networks, various games are some of the examples of such softwares.

1.4 Software Engineering :

Definition : Software engineering (SE) is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software. It is an engineering discipline that is concerned with all aspects of software production. Software engineering is the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines. Software Engineering includes knowledge, tools, and methods for defining software requirements, and performing software design, computer programming, user interface design, software testing, and software maintenance tasks. It also draws on knowledge from fields such as computer science, computer engineering, management, mathematics, project management, quality management, software ergonomics, and systems engineering.

Need : Software is often

found in products and situations where very high reliability is expected, even under demanding conditions, such as monitoring and controlling nuclear power plants, or keeping a modern airliner aloft. Such applications contain millions of lines of code, making them comparable in complexity to the most complex modern machines. For example, a modern airliner has several million physical parts (and the space shuttle about ten million parts), while the software for such an airliner can run to 4 million lines of code. Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs increase exponentially with their sizes as shown in the following figure. For example, a program of size 1,000 lines of code has some complexity. But a program with 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out to be 100 times more difficult unless software engineering principles are used. In such situations software engineering techniques come to rescue. Software engineering helps to reduce the programming complexity. Hence to make the taks simple and less complex the software engineering principles are employed which helps the developer to improve quality of the software product as well as productivity of development team.

Software engineering principles: These principles use two important techniques to

reduce problem complexity: abstraction and decomposition. The principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem.

Fig. : A hierarchy of abstraction

The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem is as shown in the following figure. It should minimize interactions among various components. If the different subcomponents are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will not be realized.

Fig. : Decomposition of a large problem into a set of smaller problems.

1.5 Causes of and solutions for software crisis : Software engineering appears
to be among the few options available to tackle the present software crisis. To explain the present software crisis in simple words, consider the following. The expenses that organizations all around the world are incurring on software purchases compared to those on hardware purchases have been showing a worrying trend over the years as shown in the following figure. Organizations are spending larger and larger portions of their budget on software. Not only are the software products turning out to be more expensive than hardware, but they also present a host of other problems to the customers: software products are difficult to alter, debug, and enhance; use resources non-optimally; often fail to meet the user requirements; are far from being reliable; frequently crash; and are often delivered late. Among these, the trend of increasing software costs is probably the most important symptom of the present software crisis. Remember that the cost we are talking of here is not on account of increased features, but due to ineffective development of the product characterized by inefficient resource usage, and time and cost over-runs. There are many factors that have contributed to the making of the present software crisis. Factors are larger problem sizes, lack of adequate training in software engineering, increasing skill shortage, and low productivity improvements.

1.6 Program vs. software product : The following table shows a comparision
between program and software product.

Program

Software Product

It is developed by individuals for their It is developed by a Team of experts. personal use Small in size and have limited functionality Extremely large and full fills requirements of the entire organization. The programmer himself is the sole user Most users are not involved with the development. The user interface may not be very User interface must be carefully designed important, because the programmer is the and implemented because developers of that sole user product and users of that product are totally different Very little documentation is expected. It must be well documented It can be developed according to the It must be developed using the accepted programmers individual style of software engineering principles. development,

: Software Engineering is a layered technology. The following diagram shows the layered approach of software engineering.
1.7 Process
Tools

Methods

Process

A quality Focus
The engineering approach, including software engineering generally rests on quality commitment. The major point that supports software engineering is quality focus. The foundation for software engineering is the process layer. It holds technology layers together. It defines a framework for key process areas. Software engineering methods provide the technical way for development of the software. Software engineering tools provide automated or semi-automated support for process and methods. Thus process is framework consisting of a number of task sets each consisting of work tasks, project milestone, work products and quality assurance point.

Process Models : It is also called software engineering paradigm. It is an approach

used by software engineer which encompasses process, methods and tools. There are many types of process models available. Some of then are as follows :

Linear Sequential Model : This is similar to classical life cycle approach. It has a
linear sequential approach for development of the software. The phases of software development are used one after another in a sequential manner. The following diagram shows this model.

System / Information Engineering : It encompasses Test Design System Code Analysis / Information requirements gathering and Engineering system view to interact with hardware and other components of the system. Analysis : It is Software Requirement Analysis. It supports to understand the nature of programs to build, function and behaviour of the software to be built etc. Design : It focuses on Data Structure, software architecture, interface and various procedures. Coding : It is concerned about writing programs for the software. Testing : It focuses on logical internals of software. It ensures that the statement of programs will perform correct output when used.

Prototyping Model : If a customer defines a set of general objectives but does not
include details, the developer is not sure about efficiency of the programs and its adoptability by the operating system, or when developer is not very much aware of type of software and customer is not aware of development strategies then in such cases it is better to have prototyping paradigm. It is as shown in the following diagram :
Listen to Customer Build / Revise Mockup

Prototyping Paradigm begins with requirements gathering. The developer and the customer both jointly define the overall objectives of the software. A quick design leads to construction of a prototype. The prototype is evaluated by the customer / user and used to refine the software to be developed. The process is iteratively repeated till the satisfaction of the customer.

Customer Test Drive Mockup

A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function, for example, may produce the desired results by using a table look-up instead of performing the actual computations. A prototype usually turns out to be a very crude version of the actual system. There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customers needs: how the screens might look like how the user interface would behave how the system would produce outputs This is something similar to what the architectural designers of a building do; they show a prototype of the building to their customer. The customer can evaluate whether he likes it or not and the changes that he would need in the actual product. A similar thing happens in the case of a software product and its prototyping model. Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many researchers and engineers advocate that if you want to develop a good product you must plan to throw away the first version. The experience gained in developing the prototype can be used to develop the final product. A prototyping model can be used when technical solutions are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues

associated with the product development. Often, major design decisions depend on issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical issues. RAD Model : It is called Rapid Application Development Model. It is high speed adoption of the linear sequential model. The activities are accomplished using component based construction. Multiple RAD teams works on different components and due to parallel work the software is developed quickly. The following diagram shows the RAD Model : Team #1 Business Modeling Data Modeling Process Modeling Application Generation Team #2 Business Modeling Data Modeling Process Modeling Application Generation Team #3 Business Modeling Data Modeling Process Modeling Application Generation

Testing

Testing

Testing

Incremental Model : It is a kind of Evolutionary software process Model. The evolutionary software process models are iterative. The linear model cpmbines elements of the linear sequential model with iterative methodology. In the first increment, basic requirements are addressed. Therefore it is called core product. But later on many supplementary features are added. The following diagram shows the incremental model.

System / Information Analysis Engineering Design

Code

Test

Increment-1

Analysis

Design Design

Code

Test

Increment-2 Increment-3
Test

Analysis

Code Code

Test

Analysis

Design

Increment-4

Spiral Model : The Spiral model of software development is shown in the following figure. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. Each phase in this model is split into sectors. These sector are numbered from 3 to 6. The following activities are carried out during each phase of a spiral model. Customer Communication : Effective communication between customer and developed is maintained at his point. Planning : Tasks required to define resources, timeliness, and other project related information are carried out at this point. Risk Analysis: Technical and Management risks are evaluated at this point Engineering : One or more representation of the application is created. Construction and Release : Testing, installation etc are varied out at this point. Customer Evaluation : Customer feedback is obtained.

The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models this is probably a factor deterring its use in ordinary projects.

1.8 Process Iteration : System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. Iteration can be applied to any of the generic process models like Incremental development, Spiral development. Process Activities : The process is the foundation layer for software. It defines a framework for a set of key process areas which are used to deliver effective software engineering technology. These key process areas are sufficient enough for management to control the over all development of the software. The major process activities include : Elicitation Requirements Process, Such As Marketing Feasibility Studies. Analysis Specification Design Testing and Validation

1.9 Computer Aided Software Engineering (CASE) : A CASE

Prototyping (Computer Aided Software Engineering) tool is a generic term used to denote any form Consistency Configuratio n of automated support for and Complete Analysis Management software engineering. In a Facilities more restrictive sense, a CASE tool means any tool used to Document Structured automate some activity Generation Diagram Central associated with software Facilities Repository development. Many CASE tools are available. Some of Document Generation these CASE tools assist in Query & phase related tasks such as Report Transfer Facilities specification, structured facility in Structured analysis, design, coding, different Analysis format testing, etc.; and others to nonFacilities phase activities such as project management and configuration management. The primary reasons for using a CASE tool are: To increase productivity To help produce better quality software at lower cost

Coding and Support Activity

Project Managemen t Facilities

Although individual CASE tools are useful, the true power of a tool set can be realized only when these set of tools are integrated into a common framework or environment. CASE tools are characterized by the stage or stages of software development life cycle on which they focus. Since different tools covering different stages share common

information, it is required that they integrate through some central repository to have a consistent view of information associated with the software development artifacts. This central repository is usually a data dictionary containing the definition of all composite and elementary data items. Through the central repository all the CASE tools in a CASE environment share common information among themselves. Thus, a CASE environment facilitates the automation of the step-by-step methodologies for software development. A schematic representation of a CASE environment is shown in the following figure. Benefits of CASE : Some of those benefits are as follows : A key benefit arising out of the use of a CASE environment is cost saving through all development phases. Different studies carry out to measure the impact of CASE put the effort reduction between 30% to 40%. Use of CASE tools leads to considerable improvements to quality. This is mainly due to the facts that one can effortlessly iterate through the different phases of software development and the chances of human error are considerably reduced. CASE tools help produce high quality and consistent documents. Since the important data relating to a software product are maintained in a central repository, redundancy in the stored data is reduced and therefore chances of inconsistent documentation is reduced to a great extent. CASE tools take out most of the drudgery in a software engineers work. For example, they need not check meticulously the balancing of the DFDs but can do it effortlessly through the press of a button. CASE tools have led to revolutionary cost saving in software maintenance efforts. This arises not only due to the tremendous value of a CASE environment in traceability and consistency checks, but also due to the systematic information capture during the various phases of software development as a result of adhering to a CASE environment. Introduction of a CASE environment has an impact on the style of working of a company, and makes it oriented towards the structured and orderly approach. Structured analysis and design with CASE tools : Several diagramming techniques are used for structured analysis and structured design. The following supports might be available from CASE tools. A CASE tool should support one or more of the structured analysis and design techniques. It should support effortlessly drawing analysis and design diagrams. It should support drawing for fairly complex diagrams, preferably through a hierarchy of levels. The CASE tool should provide easy navigation through the different levels and through the design and analysis. The tool must support completeness and consistency checking across the design and analysis and through all levels of analysis hierarchy. Whenever it is possible,

the system should disallow any inconsistent operation, but it may be very difficult to implement such a feature. Whenever there arises heavy computational load while consistency checking, it should be possible to temporarily disable consistency checking. Code generation and CASE tools : As far as code generation is concerned, the general expectation of a CASE tool is quite low. A reasonable requirement is traceability from source file to design data. More pragmatic supports expected from a CASE tool during code generation phase are the following: The CASE tool should support generation of module skeletons or templates in one or more popular languages. It should be possible to include copyright message, brief description of the module, author name and the date of creation in some selectable format. The tool should generate records, structures, class definition automatically from the contents of the data dictionary in one or more popular languages. It should generate database tables for relational database management systems. The tool should generate code for user interface from prototype definition for X window and MS window based applications. Test case generation CASE tool : The CASE tool for test case generation should have the following features: It should support both design and requirement testing. It should generate test set reports in ASCII format which can be directly imported into the test plan document. Following is a table consisting of various tools used in different process activities at various levels of the software management : Tool type Examples Planning Tools PERT tools, Estimation tools and Spread Sheets Editing Tools Text Editors, Diagram Editors and word Processors Change Management Tools Requirements Traceable tools, change control systems Configuration management Version management tools, system building tools tools Prototyping tools Very high level language tools, user interface generators Method support tools Design editors, data dictionary, code generators Language processing tools Compilers, interpreters etc. Program Analysis Tools Cross Reference generator, Static analyzer, Dynamic analyzer Testing Tools Test Data generator, filecomparator etc. Debugging Tools Interactive Debugging systems Documentation Tools Page Layout programs, image editors Re-engineering Tools Cross Reference systems, Program Re-structuring Systems

Project Management

The software project management is helpful in controlling budget and schedule considerations. Therefore the Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. Software engineering is different from other types of engineering project in the following manner : The software project is intangible. The development of the software cannot be seen physically nor it can be touched. The software manager simply relay on the documentation prepared during its development of various activities. There are no standard software processes. Large software are often one-off projects. Effective software project management focuses on the four Ps: people, product, process, and project.

Management Activities
fixed.

: The job of a software manager is versatile. It cannot be

Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel selection and evaluation Report writing and presentations

Following are the management commonalities : These activities are not peculiar to software management Many techniques of engineering project management are equally applicable to software project management Technically complex engineering systems tend to suffer from the same problems as software systems Following considerations are taken care off for staff engaged in project management. May not be possible to appoint the ideal people to work on a project o Project budget may not allow for the use of highly-paid staff o Staff with the appropriate experience may not be available o An organization may wish to develop employee skills on a software project Managers have to work within these constraints especially when (as is currently the case) there is an international shortage of skilled IT staff
Project planning : Project planning includes the following :

Probably the most time-consuming project management activity Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget. Some of the plans are as shown in the following table :

Project planning process is as shown below :

Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverables while project has not been completed or cancelled loop o Draw up project schedule o Initiate activities according to schedule o Wait ( for a while ) o Review project progress o Revise estimates of project parameters o Update the project schedule o Re-negotiate project constraints and deliverables o if ( problems arise ) then Initiate technical review and possible revision o end if end loop Project plan structure is as follows : Introduction Project organisation Risk analysis Hardware and software resource requirements Work breakdown Project schedule

 Monitoring and reporting mechanisms Activity organization Activities in a project should be organised to produce tangible outputs for management to judge progress Deliverables are project results delivered to customers The waterfall process allows for the straightforward definition of progress milestones Milestones are the end-point of a process activity. The following diagram shows some milestones in a project.

Project scheduling : Project scheduling includes the followings :

Split project into tasks and estimate time and resources required to complete each task Organize tasks concurrently to make optimal use of workforce Minimize task dependencies to avoid delays caused by one task waiting for another to complete Dependent on project managers intuition and experience

Scheduling problems

Estimating the difficulty of problems and hence the cost of developing a solution is hard Productivity is not proportional to the number of people working on a task Adding people to a late project makes it later because of communication overheads The unexpected always happens. Always allow contingency in planning

Bar charts and activity networks

Graphical notations used to illustrate the project schedule Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two Activity charts show task dependencies and the the critical path Bar charts show schedule against calendar time

Following table shows various tasks and their dependencies :

The following diagram shows an activity network :

The following diagram shows activities timelines:

The following diagram shows the allocation of staff :

Risk Management

: The software manager anticipates various risks which might affect the project schedule or the quality. He / She also takes some actions to avoid these risks. Identifying the risks and drawing up plans to minimize the effect of these risks on the project is called Risk Management. The risks can be broadly be divided in to three categories. Project risks : Which affects the schedule or resources of the project. Product Risks : which affects the quality of the software product. Business Risks : which affects the organization developing the software.

The following table shows various types of risks along with their category. Risk Staff Turnover Management Change Hardware Unavailability Requirements Change Risk Type Project Project Project Description Experienced staff will leave the project before its completion. Team members of the management has been changed The requires hardware may not be available in the market. & There is a large no. of changes in the requirements. & Specification f essential interfaces are not available on schedule. & The size of the system has been underestimated. CASE tools do not perform as it was anticipated There is a drastic change in the technology Another identical product is available in the market.

Project Product Specification Delays Project Product Size underestimate Project Product CASE tool Product underperformance Technology Change Business Product competition Business

The entire process of risk management involves various stages. These are Risk identification, risk analysis, risk planning and risk monitoring. It is shown as follows :

Risk Identificatio n List of potential risks

Risk Analysis

Risk Planning Risk avoidance and contingency plans

Risk Monitoring

Prioritized Risk Kist

Risk Assessment

Risk Identification : It is the first stage. The database used in the system cannot process as many transaction as expected. It is impossible to recruit staff with skill required. The organization is restructured. Hence Management has been changed The CASE tools are inefficient There is a change in the requirements The Time, Rate and size of the software is underestimated.

Technology risks People risks Organizational risks Tools Risks Requirement Risks Estimation Risks

Risk Analysis : Each identified risk is considered to judge its seriousness. The judgment of the risk is converted into a numeric figure. Very Low : < 10% Low : 10 25 % Moderate : 25 50% High : 50-75% Very High : > 75%

The effect of the risk might be assessed as catastrophic, serious, tolerable or insignificant. The result of such analysis is tabulated. The following table shows an example of the risk analysis. Risk Organizational Financial problems forces reductions in the project budget. It is impossible to recruit staff with the skills required for the project. Key staff are ill at critical times in the project Software components which should be reused contain defects which limit their functionality Changes to requirement which require major design rework are proposed Organization is restructured so that different management are responsible for the project The database used in the system cannot process as many transactions per second as expected The tie required to develop the software is underestimated CASE tools cannot be integrated Required training for staff is underestimated Customer failed to understand the impact of change in requirements Probability Low High Moderate Moderate Moderate High Moderate High High Moderate Moderate Effects Catastrophic Catastrophic Serious Serious Serious Serious Serious Serious Tolerable Tolerable Tolerable

Risk Planning : It considers each of the key risks which have been identified and identifies strategies to manage the risk. These strategies fall into following three categories : Avoidance strategies : It reduces the probability of the risk. E.g. strategies for dealing with defective components should be avoided. Minimising Strategies : Minimises the impact of the risk. E.g. strategies for staff illness. Contingency strategies : In case of worst case the thighs must be replaced. e..g organizational financial problems. The following table shows some of the risk and their corresponding strategies to be adopted.

Risk Organizational Financial Problems Recruitment problems Staff illness Defective components Requirement changes

Strategy Prepape a document showing importance and benefits to the orgnnization to top lelevel management. Alert customer of potential difficulties and the possibilities of delays Reorganise the team so that more overlap of the work and people therefore understand each others job. Replace them with newer ones Trace the information changes cautiously

Risk Monitoring : It involves each of the identified risks to decide whether or not that risk is becoming more or less probable and whether the effect of the risk has been reduced. It is a continuous process through the organization all level and each activity of the project.