Wednesday, August 8, 2012


Beyond Industrial Engineering


R.P. Mohanty is General Manager at Associated Cement
Co. Ltd, Mumbai, India.

Abstract
Industrial engineering has been around for 50 years and has stood the test of time: BPR for less than ten. BPR has emerged because the world itself is now different – the pressures on organisations are much greater, having to compete in a global economy. Attempts to describe key features of BPR and factors affecting its successful implementation. Suggests ways in which BPR and IE may need to work together: the two are complementary rather than competitive.


Introduction
The major economic forces affecting countries and organisations over the last decade have been liberalisation, privatisation and globalisation (LPG). In turn, these have lead to a number of influences and pressures on national economies. Chief among these are the powers of:
• customers
• information
• global investors
• market place
• simplicity
• organisation.
The power of customers has been perhaps the most important factor shaping organisations. As a result, organisations have to continually learn, relearn and adapt to changing customers’ choice, and requirement. This power compels an organisation to move from a bureaucratic mode to a responsive mode of operation: to be flexible and lean, able to meet customer demands cost effectively. The power of information (largely arising from advances in communication and information
technology) can help an organisation in this continual learning and adaptation process. With the ability to transfer volumes of data globally from one organisation to another, knowledge networking and knowledge management becomes possible. The power of global investors offers a range of opportunities, no longer bounded by regional or national boundaries. Organisations can also develop by sourcing materials and other resources from a much wider area. The power of the marketplace generates fierce time-based competition. This either motivates an organisation to learn faster, to become better at providing quality and value – or it causes the complacent to fail. The power of simplicity is the move to streamline systems and procedures within the organisation and the move away from a ritualistic culture to an empowering and autonomous structure. This involves the reengineering/redesign of business processes and the forging of organic partnerships to eliminate delays and bottlenecks. The power of organisation is the ability to use self-knowledge, technology, and modern business practices to change the shape of the organisation. It is now possible to create much leaner, more agile organisations based on high performance teams.


In order to satisfy the needs of the customers and improve the performance of organisations, managers (often in partnership with consultants) have resorted to a variety of new methodologies and techniques including TQM, JIT, CIP, KAIZEN, BPR etc. Some, like BPR, have been in existence for some time and have gone through a number of development phases (and sometimes simply re-packagings). Thus BPR has spawned business restructuring, core process redesign, business process management, business process improvement, business transformation, etc. The attraction of BPR is that it can provide the means by which an organisation is able to achieve a radical change in performance. This is achieved by simplifying and streamlining the major business processes, by eliminating all redundant and non-value adding steps, by reducing the number of stages/transfer points of work and by speeding up the work flow – often through the use of information technologies and systems. Thus, fundamental attributes of BPR are that it:
• results in radical change;
• assumes clean slate change;
• focuses on end-to-end processes;
• is top-down directed;
• is information technology enabled.
The benefits of BPR may be simple and unidimensional, but are more likely to be complex and multi-dimensional. Often quoted benefits are improvement in: • Financial performance.
• Customer satisfaction
• Cost reduction
• Product/service quality
• Delivery performance
• Productivity
• Flexibility/responsiveness
• Process times
• Innovation
• Employee development
• Competitiveness
• Organisational flexibility
BPR involves consideration of fundamental questions such as :
• Why are we doing it?
• For whom are we doing it?
• Where should we do it?
• How do we organise and operate in order to do it? Those of you with long memories or a classical industrial engineering/work study education will recognise these as being extraordinarily similar to the basic questions of method study. So, what is the difference between “classical IE” and BPR? Is BPR more than a re-packaging of the old methodology.


Characteristics of BPR
Work that has been subject to BPR should:
• be performed where it makes sense;
• be subject to minimal checking and control;
• involve single activities which were previously distinct and separate;
• focus on the process and not the functional activity;
• involve multi-dimensional jobs;
• be performed by empowered individuals and teams;
• be measured by outcomes and not activity levels;
• be lead by coaches, not traditional supervisors;
• take place within a flat structure;
• be managed by leaders, not scorekeepers.
This is often the result of a much more holistic review than would have been achieved by “simple” method study.

The need for BPR The Indian economy, and organisations within it, are experiencing the same pressures for change as elsewhere, though, of course, with a particular “spin” resulting from its own culture and history. Thus, there are changes in:
• demographics;
• social values;
• the economic environment;
• the information technology available.

These pressures lead to four main imperatives:
(1) manage costs;
(2) improve quality;
(3) improve service levels;
(4) speed up actions.
Although these sound simple, actual projects and change processes involve complex interrelationships between a number of factors. Change projects involve a:
• structural dimension;
• management dimension;
• people dimension;
• system dimension.


All this is taking place in (and as a result of) a  transition from a “providers’ market” to a  “consumers’ market” in which the battle for  customers’ business and loyalty is fought on  the basis of:
• price;
• reaction time;
• quality;
• performance.

Traditional organisation structures (built as  “vertical silos”) did have some advantages. The  clear specialisation and intense supervision  meant that an organisation could make extensive  use of simple, uneducated, unskilled workers  to accomplish most tasks. Everyone had  responsibility for one limited aspect of the task;  the higher levels, (control of) the system was  maintained through a bureaucratic chain of  command. This advantage – of the ability to  exploit unskilled labour – was outweighed by  the inherent inflexibility of those workers – and  therefore of the organisations themselves.  There was a natural tendency for no one person  to take responsible for the whole process,  for errors to occur, and for the control bureaucracy  to lead to long process times.

TQM, JIT and BPR
These shortcomings have been addressed by  some of the more modern approaches to  process and work organisation. Of these, it is  BPR that specifically attacks core business  processes. (A core business process is a set of  interlinked activities that crosses functional  boundaries in addressing the needs and expectations  of the marketplace.)  BPR differs from TQM and JIT in the  following significant ways:
• The adoption of TQM and JIT, though  resulting in the re-balancing of operational  activities and the removal of bottlenecks,  fail to address the organisation barriers to  performance improvement – the bureaucratic  nature and ritualistic pattern of  operating the business.
• BPR is predicated on a re-definition of  operational excellence (and destruction of  old tenets and values) to provide both  internal drive and an external focus.
• BPR pushes the JIT and TQM approach  both upstream and downstream to the  customer and supplier (end-to-end) in  order to either add (additional) value in the  supply chain or to penetrate into markets  more aggressively.  • BPR requires corporate leaders to challenge  the very purpose, principles and  basic assumptions on which current systems  are founded.
• TQM and JIT often fail to break down  functional barriers.  Of course, BPR, as a strategic cross-functional  initiative can take advantage of others – including  TQM and JIT. No approach should be  omitted, no tool should be left unused. Competitiveness  is a complex result of competitive  assets and competitive processes. Perhaps,  BPR, in embracing these other tools and techniques,  can be considered as “TPQM” i.e.  “total productivity and quality management”.

Key elements of BPR
In reviewing processes, there must be a  completely fresh look at all the elements that  make up the process: the people, the management/  leadership, the organisational structure  and culture, the technologies – all in the context  of the outcomes. What is the process  designed to achieve?

People  
It is axiomatic that people are the greatest asset  to any enterprise. Too often, however, this is  merely empty rhetoric. Companies that seek to  create and pursue new paradigms, and attempt  to remove functional barriers by redesigning  process-driven workflows cannot hope to do so  without the active co-operation of the workforce.  The aim is to move beyond “empowerment”,  to the development of truly “renaissance”  employees who can move from one  business process development team to another,  using their skills and knowledge to enhance the  performance of any project (gaining increased  satisfaction for themselves along the way).  Organisational culture  The symbiosis of belief and value systems, and  their interaction with and influencing of behavioural  transactions is the essence of organisational  culture. The kind of organisation that is  more likely to succeed with a BPR initiative is  one that already has a high degree of:
• inspirational leadership – that can articulate  a vision, drive the values and create a harmonious  climate in which business unit  executives, managers, and line personnel.


can all share commitment and flourish equally;
• shared values;
• teamwork at all levels;
• connectivity between the various stakeholders – employees, shareholders, customers and suppliers;
• desire to dominate the market.  

Management and leadership  
Executives involved in BPR must take on the  role of builder. Re-engineering demands new  structures to replace existing non-responsive  monolithic structures. This structural change  must be accompanied by an appropriate culture.  Changing culture requires a long-term  commitment, leadership by example and an  understanding of the all-embracing nature of  culture. Changing culture is not for the fainthearted!

Organisation structure  
The concept of a re-engineered organisation  requires the structure to be closely related to,  and underpinning, the cultural change  required. This normally involves a shift from a  mechanistic organisation to an organic one  (and it is such change that helps distinguish the  BPR approach from the classical IE approach)  see Table I.  This kind of shift obviously has tremendous  implications for human resource management  and development – including the development  of industrial engineers! They need to exhibit:
• Systems thinking – they must be able to take a  holistic view, to integrate hard and soft  information, to combine analysis and intuition  and balance the varied and multiple  interest of the various stakeholders.
• Inter-cultural competence – both within and  without the local organisation. As organisations  become increasingly global and  increase their dependence on other  economies, an understanding of, and sensitivity  to different cultures becomes an  important requirement.

Performance indicators  
Since reengineered processes are transfunctional,  most (previous) key performance indicators  are inappropriate. Concentration on  outcomes, and on core processes actually  simplifies performance measurement.  Resulting measures should be clear and  simple, such as:
• quality;
• lead time;
• cost;
• service.

Tools and techniques of BPR  
The essential tools of BPR are the same ones  that are needed and exploited in a range of  productivity and quality improvement methodologies.  The chief “technique” (if only life and  BPR were that simple) is to manage change.  Change is invariably perceived as a threat to  existing ways of working and to job security.  Industrial engineers, historically have been  “change agents” advising on changes in methods,  systems, procedures etc. Their approach  has been rooted in strong technical skills. If  BPR is to be successful, those strong technical  skills have to be married to a strong understanding  of the needs of the customer (at all  stages of a process) and of the concerns and  fears of those involved in the process. Systems  analysis, value analysis, target costing,  simulation, optimisation, method study, organisational  analysis, scenario planning, environmental  scanning, cause-effect analysis, faulttree  analysis, bench marking etc. all may play  their part – often simultaneously – but in the  context of the transformation of people’s jobs,  roles and place in society.

Implementation of BPR  
It is useful to categorise processes and  activities according to their perceived (or real)  value, and to the costs they consume. Low  value-added processes should obviously be  removed or re-designed – especially if they are  high cost. If, for some reason, it is not possible  to eliminate them, a cost reduction exercise  should be undertaken. Processes that deliver  high value but at the same time incur high cost  should be examined for innovative approaches  to changing the ratio! Even processes that have  high value and low cost should not be excluded  from review: these may be the source of  restructuring or re-investment to bring dramatic  improvements in value.  Within process reviews, the aims are to  achieve dramatic cost reduction, to become  “best in class” and to find “breakpoints” –  where the rules of the game are actually  changed and “the class” itself is changed.  Others then have to emulate this new  standard – clear evidence of superior performance  in one or more value metrics clearly.


Mechanistic model (classical IE based) Organic model (BPR based)
Hierarchical and bureaucratic management Flattened and shortened chain of command
Vertical division of labour Decentralisation and devolution of responsibility
Centralisation of most divisions and of decision making, and fixation of process accountability
Separation of categories by status (manual workers, Blurring of status differences and trend towards
office staff, managerial staff, etc.) more equal status: creation of multifunctional process teams
Atomistic analysis of work and division of labour Enlargement and enrichment of tasks/trend towards
a more professional division of work
Concentration on core processes and outsourcing of
peripheral/support activities
Strict compartmentalisation of functions and services Close integration up and down stream between
functions like research, development, production
and distribution.
Concept of supply chain
Research, development, design and production Structures differentiated by product and product functions are differentiated one from another – lines division and functional structures Concept of value chain
Specialisation and compartmentalisation of Multi-disciplinary team working knowledge
Losse ties with suppliers Connectivity with suppliers and subcontractors Loose ties with consumer Great sensitivity to market demand, to buyers and consumers, and all stockholders,                                                                                                                                                                                                                                                                                                                                           Standardisation products and production processes Structural, technological and organisational flexibility
Overall routines and rigidities Flexible thinking Formalised practices Continuous search for innovation and added value Structural inflexibility Production management is central Human resources development is central Conflict-based industrial relations Consensus-based partnership knowledge, skills, confidence and the right attitude. These staff are available and accessible at all “reasonable” times. A real breakpoint leads to new finishing lines for competition and changes the rules of the corporate Olympics! Searching for these breakpoints through BPR may be considered in three phases.

Phase 1: Discover
During this phase, the company may analyse current performance but more importantly it also discovers its own mission, values and strategic aims – and hence identifies the core processes that add the required value. It, in effect, decides what BPR must achieve.
Phase 2: Redesign
This is the major stage of innovation – using all appropriate investigative and creative techniques,
involving input from a wide variety of people. Ideas are generated and validated. It is here that any breakpoints will be created! This phase must end with a commitment to the change to be made.
Phase 3: Realise
The ideas now have to be translated into real results. This is often the hardest phase – of managing the change, of coping with resistance, of leading into the unknown. There must also be a realisation that BPR is
(hopefully) a revolutionary process – but it must be supported by evolutionary activity. A BPR exercise should try to create a culture, and a facilitating framework, for continuous improvement.

Evaluation of BPR
BPR is a comprehensive change management programme. Too often, companies introduce change management programmes in haste without making proper preparation – perhaps because they are the latest management “fad”. However, there is often only one chance to make real revolutionary change. Although
there is an urgency in the need for transformation in Indian organisations, most of them are not in a position to implement BPR. They mostly lack appropriate knowledge of the basic methodologies and tools, and although they can import this knowledge by employing consultants, they are often too naive to fully enter
into such a project and give the real commitment vital for success. Organisations are ready to implement BPR when :
• They have an appropriate mind-set. This arises from having a combination of the right values, structures, and performance measures that can drive and support change through the existing authority structure of
the organisation.
• There is a sense of urgency for abrupt change. This may be necessary if the organisation needs to redefine the business mission, shake up the existing power structure and/or delayer the existing senior management.
• They recognise, and want to emulate, industry leaders. This strategy can be used to bring about quick changes by identifying and following best industry practices (perhaps by benchmarking and other inter-firm
comparisons).
• They can direct efforts in multiple dimensions. Organisations with very strong core competencies plan their BPR efforts across a broad set of fronts. They design it top-down, focusing primarily on a number of direct
issues to generate the maximum immediate financial impact, and then move forwards to indirect and support issues.
• They can re-design systematically. A major contribution to BPR is the systematic, planned intervention in which efforts are made to analyse, investigate and redesign issue by issue – and then seek integration.
• They can mobilise front-line, high performance action teams. It is important to supplement top-down initiatives by promoting change by means of front-line problem solving teams. Conversely, BPR is likely to fail when:
• There is no compelling imperative for change.
• There is a lack of involvement of most people in BPR because it is seen as just another management-led initiative.
• Organisational power politics restrict the inputs of those with important knowledge or with a major stake in the success.
• Managers are simply looking for a quick fix.
• There is insufficient investment in either IT, IS and/or HRD. No attempt is made to build the organisation’s capacity to sustain change and on-going improvements in the long term.

BPR, like IE, involves the application of scientific thought to the solution of organisational problems. However, BPR can be said to have a broader charter: the integration of knowledge throughout the total organisation as a source of sustainable competitive advantage. The power lies not in knowledge but in the ability to use knowledge for the benefit of the stakeholders. BPR, by the very nature of its process  orientation, requires executives to evaluate knowledge potential, interdepartmental cooperation and
teamworking abilities. However, executives have not developed appraisal systems to measure
the so-called unmeasureables. Traditional measures used as the basis for appraisal will prove both seductive as well as deceptive. Seductive, because organisational development interventions are often conditioned to focus on financial returns and other outcomes, but not on processes to maximise value. Deceptive, because the limited ability to measure improvements in internal processes, often relegates process issues to secondary importance. Summary
Industrial engineering as a discipline has been around in a number of forms and under a number of titles for the last 50 years. It has primarily been concerned with:
• the pursuit of organisational efficiency  through methods improvement and resource-saving;
• organizational reform through business, market and technology development. BPR today borrows much of the approach of traditional IE. However, its aspirations are
much higher. BPR aims not simply at reform and improvement, not at evolutionary change – but at a total transformation of the organisation. IE is certainly not dead – BPR needs the important underpinnings of IR, and needs IE to maintain the results of the BPR exercise and to support the subsequent phase of continuous improvement.








Saturday, August 4, 2012

Risk Management Using Spiral Model for Information Technology

Rajendra Ganpatrao Sabale, Dr. A.R Dani 
Student of Ph.D., Singhania University, Pacheri Bari, Dist. Jhunjhunu( Rajasthan), India International Institute of Informational Techonology,Pune(Maharashtra),India


International Journal of Engineering Research and
Applications (IJERA) ISSN: 2248-9622 www.ijera.com
Vol. 2, Issue 4, June-July 2012, pp.712-716

Abstract 

             Now a day almost everything has been digitized and networked either through Local Area Network or Internet. In this digital era, as organizations use automated information technology (IT) systems to process information for improved support to achieve their objectives, risk management plays a critical role in protecting an organization's information assets, and therefore its aim, from IT-related risk.This paper provides information about IT risk management and good practices to follow to minimize risk. It provides a foundation for the development of an effective risk management policy.

Introduction 

1. An effective risk management process is an important component of a successful IT security program. The risk management process should not be treated primarily as a technical function carried out by the IT experts who operate and manage the IT system, but as an essential management function of the organization. The principal goal of an organization‘s risk management process should be to protect the organization and its ability to perform their objectives. Risk is the net negative impact of the exercise of vulnerability, considering both the probability and the impact of occurrence.


2. Purpose
Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level. This paper provides groundwork for the development of a successful risk management program.


3. Objective
The objective of performing risk management is to enable the organization to accomplish its task
 By better securing the IT systems that store, process, or transmit organizational information
 By enabling management to exercise well-informed risk management decisions to justify the expenditures     that are By assisting management in authorizing (or accrediting) the IT systems on the basis of the supporting documentation resulting from the performance of risk management.


4. Target Addressees
This paper provides a common foundation for experienced and inexperienced, technical, and non-technical
personnel who support or use the risk management process for their IT systems. These personnel include: part of an IT budget
 The Designated Approving Authority whether to allow operation of an IT system
 The IT security program manager, who implements the security program
 Information system security officers (ISSO), who are responsible for IT security
 Business or functional managers, who are responsible for the IT procurement process
 Technical support personnel (e.g., network, system, application, and database administrators; computer
specialists; data security analysts), who manage and administer security for the IT systems
 IT system and application programmers who develop and maintain code that could
affect system and data integrity
 Information system auditors, who audit IT systems (DAA), who is respond
 IT consultants, who support clients in risk management

5. Importance of risk Management
 Risk management encompasses three processes: risk assessment, risk evaluation and. risk mitigation Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures. This process is not unique to the IT environment; indeed it pervades decision-making in all areas of daily routine work. Minimizing negative impact on an organization and need for sound basis in decision making are the fundamental reasons organizations implement a risk management process for their IT systems. sible for the final Effective risk management must be totally integrated into the System Development Life Cycle. Risk management can be performed in support of each system development life cycle phase.

Phase 1—Initiation
• Identified risks are used to support the development of the system requirements, including security requirements, and a security concept.
Phase 2—Development or Acquisition
• The risks identified during this phase can be used to support the security analyses of the IT system that may lead to architecture and design tradeoffs during system development of operations (strategy) decision
Phase 3— The risk management process
• Supports the assessment of the system implementation against its requirements and within its modeled operational environment. Decisions regarding risks identified must be made prior to system operation
Phase 4—Operation or Maintenance
• Risk management activities are performed for periodic system reauthorization (or reaccreditations) or whenever major changes are made to an IT system in its operational, production environment (e.g., new system interfaces)
Phase 5—Disposal
• Risk management activities are performed for system components that will be disposed of or replaced to ensure that the hardware and software are properly disposed of, that residual data is appropriately handled, and that system migration is conducted in a secure and systematic manner

6. Risk Management Process
Risk management process involves:
 Identify Organizational Risks: By surveys, interviews, and solicitation of input across divisions and departments of Probability - The likelihood of risk getting realized
o Inherent Risk - The nature of the risk event
o Mitigation Control Effectiveness - The effectiveness of mitigation plans

6.1 How to identify Risks?
        Risk Management application provides tools to quickly put together surveys and polls for gathering inputs from professionals and employees. This data is then collated into a list of identified risks for the organization. The list can be reviewed periodically and updated based on existing business scenarios. A frequently used technique in security analysis, and in particular in risk identification, is so-called structured brainstorming (HazOp-analysis [18] is a kind of structured brainstorming). It may be understood as a structured ―walk-through‖ of the target of analysis.
        The main idea of structured brainstorming is that a group of people with different competencies and backgrounds will view the target from different perspectives and therefore identify more, and possibly other, risks than individuals or a more heterogeneous group. The input to a brainstorming session is various kinds of target models (e.g. UML models). The models are assessed in a stepwise and structured manner under the guidance of the security analysis leader. The identified risks are documented by an analysis secretary. Construction of a conceptual model based on standardized security risk analysis terminology is first step of developing language model. the most intuitive and common interpretations are used. The conceptual model can be seen as a kind of abstract syntax for the language, and is shown in diagram.





IT system throughout its SDLC. The conceptual model may be explained as follows: stakeholders are those people and organizations who may affect, be affected by, or perceive themselves to be affected by, a decision or activity regarding the target of analysis An asset is something to which a stakeholder directly assigns value, and hence for which the stakeholder requires protection Assets are subject to vulnerabilities, which are weaknesses which can be exploited by one or more threats A threat is a potential cause of an unwanted incident

6.2 Risk Assessment 

          Risk assessment is the first process in the risk management methodology. Organizations use risk assessment to determine the extent of the potential threat and the risk associated with an Risk is a function of the likelihood of a given threat-source’s exercising a particular vulnerability, and the resulting impact of that adverse event on the organization. Consequence is the level of impact that the potential risk event can have on the achievement of business objectives. Consequence will be measured on a 5 level rating Probability is the likelihood of occurrence of the potential risk event which may lead to the assessed consequences. Probability will be measured on a 5 level rating scale in the risk survey (25-Almost Certain, 20-likely, 15-Possible, 10-Unlikely, 5-Rare)

6.2.1 Calculating Inherent Risk
Inherent risk signifies the exposure arising from a specific risk event before any action has been taken to manage it. Inherent Risk = Consequence X Probability Inherent risk rating will be exhibited on a 4 level rating scale (Extreme Risk, High Risk, Moderate Risk, Low Risk)



6.3 Risk Assessment Report
There are different kinds of risk assessment reports. As risk assessment follows risk identification, a lot of these documents will be based on the risk identification reports. Documentation is done in a systematic way and can be from different inputs. Some of stakeholder Analysis - Risk Report: This identifies probable risks posed by take holders and the impact the risk might have on other stakeholders or the project at large. WBS - Risk Report: The work breakdown structure, broken down to work packages can be assessed for risks. It may detail risks at different stages based on cost, schedule, resource and manpower factors. Scope - Risk Report: The scope statement or mission statement may be assessed for risks at the beginning of a project. For example, it could be the impact of a particular project on the community. Cost Evaluation Risk Report: Cost or funds are at constant risk in a project. It has to be maintained and controlled with as little deviation as possible from the forecasted values. Risks related to cost are in the cost evaluation risk reports. Schedule Evaluation Risk Report: Time is luxury that a project cannot afford. It is imperative that time schedules are met with as little delay as possible. Time delays can impact the progress of a project and put it at risk. Such risks are documented in the schedule evaluation risk report. Technical Evaluation Risk Report: Risks related to resources, manpower and departments fall under this category. Risks arising due to quality constraints and those which are due to design errors and poor planning also fall under this group.



6.3. Risk Mitigation
A systematic reduction in the extent of exposure to a risk and/or the likelihood of its occurrence is called risk mitigation. It is also called risk reduction. A solution to mitigate the risk is developed and modeled to determine the level of reduced risk versus the cost to implement. If the solution provides an acceptable level of reduction in risk for the associated cost, then it is considered successful and the process is complete.
 The RMP can be thought of as a spiral model that allows a user to complete the process and then review the results. If the risk mitigation process was successful, then the process stops at the end of the post-mitigation task. If the risk or cost is not acceptable, then the entire process is repeated to determine if it can be improved. Best practices require that the known and perceived risk be analyzed according to the degree and likelihood of the adverse results that are anticipated to take place. Thereafter, all such risks analyzed shall be documented according to their levels of priority in a form known as the risk mitigation plan. After which, the development and integration of the corresponding risk mitigation strategies follows, and shall be referenced against the previously prepared risk management plan.
A risk mitigation plan shall serve as the checklist of the anticipated risks, accordance with degree of their probability, as High, Medium or Low. Some project managers, however, deem it more appropriate to categorize the risks as most Likely, Likely or Unlikely. There are different kinds of risk assessment reports. As risk assessment follows risk identification, a lot of these documents will be based on the risk identification reports. Documentation is done in a systematic way and can be from different inputs. Some of them are discussed below.

7. Good Security Practice
The risk assessment process is usually repeated at least every 3 years. However, risk management should be conducted and integrated in the SDLC for IT systems, not because it is required by law or regulation, but because it is a good practice and supports the organization‘s business objectives. There should be a specific schedule for assessing and mitigating mission risks, but the Periodically performed process should also be flexible enough to allow changes where warranted, such as major changes to the IT system and processing environment due to changes resulting from policies and new technologies. 8. Keys for Success A successful risk management program will rely on
(1) Senior management‘s commitment.
(2) The full support and participation of the IT team
(3) The competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization.
(4) The awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization.
(5) An ongoing evaluation and assessment of the IT-related mission risks.

Reference :
(1) Risk Management guide by National Institute of Standard Technology.
(2) IT security and risk management by Verizon Business.
(3) A graphical approach to risk identification, motivated by Empirical.
















Sunday, July 22, 2012

Spiral Model of Software Development and Enhancement

The traditional software models discouraging the old software models. 

               While the Waterfall Model presents a straightforward view of the software life cycle, this view is only appropriate for certain classes of software development. Specifically, the Waterfall Model works well when the software requirements are well understood (e.g., software such as compilers or operating systems) and the nature of the software development involves contractual agreements. The Waterfall Model is a natural fit for contract-based software development since this model is document driven; that is, many of the products such as the requirements specification and the design are documents. These documents then become the basis for the software development contract.

                According to Boehm, however, this model "does not work well for many classes of software, particularly interactive end-user applications." Specifying the requirements for such applications is notoriously difficult since interface design is highly subjective and clients rarely ever understand the real needs the software should meet. As a result, "document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decision-support functions, followed by the design and development of large quantities of unusable code" [Boehm 1988]. The problem is that a contract is signed before the real requirements of the system are properly understood.

                In addition to this shortcoming, the Waterfall model provides no means for risk assessment and management during the life cycle. Consider the case of the baggage-handling system at the Denver International Airport (DIA) again. Initially, DIA had intended that each individual airline would be responsible for building its own baggage-handling system. However, when American Airlines (AA) decided to use DIA as its second-largest hub airport, AA commissioned BAE Automatic Systems to develop an automated baggage-handling system efficient enough to allow AA to turn aircraft around in under thirty minutes. As the construction of the airport progressed, a larger vision emerged "for the inclusion of an airport-wide integrated baggage-handling system that could provide a major improvement in the efficiency of luggage delivery." To accommodate the vision, DIA negotiated a new contract with BAE to develop the airport-wide baggage system. This new plan, however, "underestimated the high complexity of the expanded system, the newness of the technology, and the high level of coordination required among the entities housed at DIA that were to be served by the system" [Montealegre 1996]. Despite the enormous change in the specifications of the project, no one gave any thought to risk assessment. Had the developers considered the risks involved with changing the system requirements radically at a late stage of development, they may have concluded that the expanded plan was infeasible. In the end, DIA had to settle with a much less ambitious plan, and Montealegre reports that "six months after the de-scaling of the system, the airport was able to open and operate successfully."

                 In 1988, Barry Boehm proposed a more comprehensive life cycle model called the Spiral Model to address the inadequacies of the Waterfall Model. According to Boehm, "the major distinguishing feature of the Spiral Model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties" [Boehm 1988]. Software projects encompass many different areas of risk such as project cost overruns, changed requirements (e.g., the DIA baggage system), loss of key project personnel, delay of necessary hardware, competition from other software developers, technological breakthroughs which obsolete the project, and many others. The essential concept of the Spiral Model is "to minimize risks by the repeated use of prototypes [emphasis added] and other means. Unlike other models, at every stage risk analysis is performed... The Spiral Model works by building progressively more complete versions of the software by starting at the center of the spiral and working outwards. With each loop of the spiral, the customer evaluates the work and suggestions are made for its modification. Additionally, with each loop of the spiral, a risk analysis is performed which results in a 'go / no-go' decision. If the risks are determined to be too great then the project is terminated" [Frankovich 1998]. Thus, the Spiral Model addresses the problem of requirements engineering through development of prototypes, and it addresses the need for risk management by performing risk analysis at each step of the life cycle.
In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].
 TemplateExplanationExample Phase
ObjectivesThe goals of the software projectSignificantly improve software quality
ConstraintsLimitations which the project must meetWithin three years
Without large-scale capital investment
Without radical change to company standards
AlternativesPossible ways to achieve the objectivesReuse existing certified software
Introduce formal specification and verification
Invest in testing and validation tools
RisksPotential risks for this phaseNo cost effective quality improvement possible
Quality improvements may increase costs excessively
New methods might cause existing staff to leave
Risk
Resolution
Strategies for reducing the risksLiterature survey, Pilot project, Survey of potential reusable components, Assessment of available tool support, Staff training and motivation seminars
ResultsResults of applying risk resolution strategiesExperience of formal methods is limited - very hard to quantify improvements
Limited tool support available for company standard development system
Reusable components available but little reuse tool support
PlansDevelopment plans for the next phaseExplore reuse option in more detail
Develop prototype reuse support tools
Explore component certification scheme
CommitmentResources needed to achieve the plansFund further 18-month study phase
Spiral Model Template
In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.
The animation below illustrates how the eight management elements of the Spiral Model template are organized in each phase. Click "Start Tutorial" to view the animation.
The final phase of the Spiral Model is analogous to the Waterfall Model. At this point in the project, the software requirements should be well-understood through the development of several prototypes. The project should also have resolved the major risks involved with building the final version of the software. With these issues resolved, the detailed design of the software enters the last three processes of the Waterfall Model, and the software is created. Although some of the labels in the Spiral Model are different, the same processes are represented. The table below shows the correspondence between the final phase of the Spiral Model and the Waterfall model.
Waterfall ModelSpiral Model
Design SpecificationsDetailed design
ProgrammingCode, Unit test
IntegrationIntegration and test
DeliveryAcceptance test, Implementation
Notice, however, that the maintenance process which appeared as dashed lines in the complete Waterfall Model seems to be missing from the Spiral Model. What happened to this process? Boehm [1988] explains: "The answer to [this question] involves an observation that the spiral model applies equally well to development or [maintenance] efforts. In either case, the spiral gets started by a hypothesis that a particular operational mission could be improved by a software effort." Thus maintenance simply becomes another spiral or phase in the life cycle of the software. Like the previous phase, the maintenance efforts undergo risk assessment to evaluate whether changes are feasible.
References