You are on page 1of 23

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.

1. 0 Software Engineering Paradigms 1.1 Software Characteristics : S et of instructions written in a
Wear Out Time Failure Curve for Hardware
Wear Out
Time
Failure Curve for Hardware
Ideal Curve Failure Rate
Ideal Curve
Failure Rate
1. 0 Software Engineering Paradigms 1.1 Software Characteristics : S et of instructions written in a

Time Failure Curve for Software

Failure Rate
Failure Rate
1. 0 Software Engineering Paradigms 1.1 Software Characteristics : S et of instructions written in a

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 Practitioner’s 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 project’s 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.

∑ Artificial Intelligence software : These softwares make use of non-numerical algorithms to solve complex problems.

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

Software engineering principles: These principles use two important techniques to reduce problem complexity: abstraction and decomposition.

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.

Software engineering principles: These principles use two important techniques to reduce problem complexity: abstraction and decomposition.

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.

1.5 Causes of and solutions for software crisis : Software engineering appears to be among the

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

between program and software product.

: The following table shows a comparision

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

The programmer himself is the sole user

 

of the entire organization. Most users are not involved with the

The user

interface

may

not

be

very

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

programmer’s individual style of

software engineering principles.

development,

 

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

Tools Methods Process A quality Focus
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

requirements gathering and

System / Information Design Analysis Engineering
System / Information
Design
Analysis
Engineering
Code
Code
Test
Test

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 :

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 satisfaction of the customer.

till

the

Listen to Build / Revise Customer Mockup Customer Test Drive Mockup
Listen to
Build / Revise
Customer
Mockup
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 customer’s 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

Team #2 Business Modeling
Team #2
Business
Modeling
  • Data

Team #3

  • Business Modeling

Data Modeling Process Modeling Application Generation Testing
Data
Modeling
Process
Modeling
Application
Generation
Testing
  • Data

Process Modeling Application Generation Testing
Process
Modeling
Application
Generation
Testing

Modeling

Process Modeling Application Generation Testing
Process
Modeling
Application
Generation
Testing

Modeling

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 Engineering Analysis Design Code Test Analysis Design Code Test Analysis Design Code Test
System / Information
Engineering
Analysis
Design
Code
Test
Analysis
Design
Code
Test
Analysis
Design
Code
Test
Analysis
Design
Code

Increment-1

Increment-2

Increment-3

Test
Test

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.

∑ Spiral Model : The Spiral model of software development is shown in the following figure.

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

(Computer Aided Software Engineering) tool is a generic

term used to denote any form of automated support for

software engineering.

In

a

more restrictive sense, a CASE tool means any tool used to

automate some activity associated with software development. Many CASE

tools are available.

Some of

these CASE tools assist in

phase related

tasks

such

as

specification,

structured

analysis,

design,

coding,

testing, etc.; and others to non-

Project Managemen Coding and t Facilities Support Prototyping Activity Consistency Configuratio and Complete n Analysis Management
Project
Managemen
Coding and
t Facilities
Support
Prototyping
Activity
Consistency
Configuratio
and Complete
n
Analysis
Management
Facilities
Document
Structured
Generation
Diagram
Central
Repository
Facilities
Document
Generation
Query &
Report
Transfer
Facilities
facility in
Structured
different
Analysis
format
Facilities
1.8 Process Iteration : System requirements ALWAYS evolve in the course of a project so process

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

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 engineer’s 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

 

Editing Tools

PERT tools, Estimation tools and Spread Sheets Text Editors, Diagram Editors and word Processors

   

Change Management Tools Configuration management tools

Requirements Traceable tools, change control systems Version management tools, system building tools

Prototyping tools

Very high level language tools, user interface generators

Method support tools

Design editors, data dictionary, code generators

   

Language processing tools Program Analysis Tools

Compilers, interpreters etc. Cross Reference generator, Static analyzer, Dynamic

analyzer

Testing Tools

Test Data generator, filecomparator etc.

 

Interactive Debugging systems

Debugging Tools Documentation Tools

 

Re-engineering Tools

Page Layout programs, image editors 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 P’s: people, product, process,

and project.

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

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

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 loop

end if

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.

∑ Monitoring and reporting mechanisms Activity organization ∑ Activities in a project should be organised to

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

∑ Estimating the difficulty of problems and hence the cost of developing a solution is hard

The following diagram shows an activity network :

The following diagram shows an activity network : The following diagram shows activities timelines: The following

The following diagram shows activities timelines:

The following diagram shows an activity network : The following diagram shows activities timelines: The following

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

Risk Type

 

Staff Turnover

Project

Description Experienced staff will leave the project before

Management Change

Project

its completion. Team members of the management has been

Hardware

Project

changed The requires hardware may not be available in the market.

Unavailability Requirements Change

Project

&

There

is

a

large

no.

of

changes

in

the

Product

 
   

requirements.

requirements.

Specification Delays

Project

Product

&

Specification f essential interfaces are not available on schedule.

Size underestimate

Project

&

The

size

of

the

system

has

been

Product

underestimated.

 

CASE

tool

Product

CASE

tools

do

not

perform

as

it

was

underperformance

anticipated

 
 

Business

 

Technology Change Product competition

Business

There is a drastic change in the technology Another identical product is available in the market.

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
Identificatio
n
List of potential risks
List of potential
risks
Risk Risk Risk

Risk

Risk Risk Risk
Risk Risk Risk

Risk

Risk Risk Risk

Risk

Analysis

Planning

Monitoring

 
Risk Risk Risk Analysis Planning Monitoring Risk avoidance Prioritized Risk Kist and contingency plans Risk Assessment
Risk Risk Risk Analysis Planning Monitoring Risk avoidance Prioritized Risk Kist and contingency plans Risk Assessment
Risk Risk Risk Analysis Planning Monitoring Risk avoidance Prioritized Risk Kist and contingency plans Risk Assessment
     

Risk avoidance

     

Prioritized Risk

Kist

and contingency

plans

Risk Assessment

Risk Identification : It is the first stage.

Technology risks

The database used in the system cannot process as many transaction

as expected.

   

People risks Organizational risks

It is impossible to recruit staff with skill required. The organization is restructured. Hence Management has been

Tools Risks

changed The CASE tools are inefficient

   

Requirement Risks Estimation Risks

There is a change in the requirements The Time, Rate and size of the software is underestimated.

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

Probability

Effects

Organizational Financial problems forces reductions in

Low

Catastrophic

the project budget. It is impossible to recruit staff with the skills required

High

Catastrophic

for the project.

 

Moderate

Serious

Key staff are ill at critical times in the project Software components which should be reused contain

Moderate

Serious

defects which limit their functionality Changes to requirement which require major design

Moderate

Serious

rework are proposed Organization is restructured so that different

High

Serious

management are responsible for the project The database used in the system cannot process as many transactions per second as expected

Moderate

Serious

The tie required underestimated

to

develop

the

software

is

High

Serious

CASE tools cannot be integrated

 

High

Tolerable

 

Moderate

Tolerable

Required training for staff is underestimated Customer failed to understand the impact of change in requirements

Moderate

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

Strategy Prepape a document showing importance and benefits to the

Recruitment problems

orgnnization to top lelevel management. Alert customer of potential difficulties and the possibilities of

Staff illness

delays Reorganise the team so that more overlap of the work and people

therefore understand each other’s job.

   

Defective components Requirement changes

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.