Study on the Analysis and Optimization of Brake Disc: A Review

207

Copyright © 2016. Vandana Publications. All Rights Reserved.

Volume-6, Issue-6, November-December 2016

International Journal of Engineering and Management Research

Page Number: 207-211

Investigation of Risk Factors in Software Engineering Projects

Biswa Ranjan Mohapatra1, Jaya Krushna Panda2

1_{Research Scholar, P.G Department of Business Administration, Utkal University, Vani Vihar,} Bhubaneswar, Odisha, INDIA

2

Research Supervisor, Dr. Jaya Krushna Panda, P.G Department of Business Administration, Utkal University, Vani Vihar, Bhubaneswar, Odisha, INDIA

ABSTRACT

Normally, there are small, medium, and large software development projects and each of them are affected by risks. Thus, it needs an evaluation process of the potential risk factors involved in different categories of software projects. This may result project failure or loss when they occur. The Success of software development projects lies in identifying of project risks and managing the risks in a practical manner. Project development group and System testing & Integration group should take care of those risk factors to achieve overall project success. Most projects additionally suffered from organizational factors outside the project manager's control. Thus in this study, groups of risk factors are identified and analyzed in a sequential manner with the objective to optimize the quality of the software engineering projects.

Keywords— Risk management, Software engineering, Software project management, Software quality

I.

INTRODUCTION

The development of many software engineering projects has high failure rates and risks during their life cycle [1]. The risk is although controllable but it can’t be always avoidable. Identification of Risk factors is an approach of identifying the risk factors in software development process. Information Technology software projects will be considered successful if they are finished within budget, on time delivery and the final output satisfies the essential customer’s requirements. To avoid unexpected results, the software engineers have to proactively manage the risk factors in software engineering projects. It is important that, the organizational risk factors are to be first identified in order to determine the fundamental root causes.

Organizational issues have been analyzed for the primary root cause which involves with some risk factors

such as lack of top management commitment, past outcomes. Apart from that, lack of risk management is one of the main important factors that lead to the project failure. Thus, risk management is defined as managing the risk by identifying, monitoring, controlling and eliminate software potential risks before they become threats to successful software operation. Risk management involves correlation of various risk factors for proposing strategies to minimize the rate of project failure. Risk identification is defined as the way of identifying the risk in an operation or task of project management process.

.

Figure1: Relationship between Cost and project Risk of IT Industry

The relationship between cost and project risk of IT Industry is shown in the Fig.1 where the X axis represents project risks and the Y axis represents involved in the concerned software project. When the development of the IT project advances, the project risk as well as cost increases. There is also a chance of project failure to occur. The chance of project failure is the difference of cost and return from the software project.

The failure of a software project may be due to lack of technical issues, project management skills and business decisions. During the software development process, the Project managers (PM), the development team, the system integration cum testing team, deal with

Project Cost

Return from Project

Project Risk C

o s t

208

Copyright © 2016. Vandana Publications. All Rights Reserved.

upper level management, internal and external customers and end users, marketing department). The effort, quality and cost of the software project are affected due to these above discussed points. The project failure affects the software developers and software testers. Off late projects normally cause developers and testers to suffer long hours of unpaid overtime manual labor which causes bad impacts on their social lives, leading to motivational loss, mental stress and its associated manpower costs. There are some different types of risks such as Operational Risk, Technical Risk, and Financial Risk. Operational risk involves improper process implementation and external risk factors. Technical risk involves the problems in programming, coding, software and hardware faults. Financial Risk is involved with the problems incurred in the budget of the software projects.

Thus, the objective of this paper is to identify the risk factors and to improve the quality of software engineering projects while evaluating the risks which are affecting the success of software development process. There were 34 common risk factors are identified in the software engineering projects and most of the risk factors are discussed in this paper are carefully chosen for the context of IT companies.

II.

LITERATURE REVIEW

Boehm (1991) reported the widespread research which has been performed on risk management in software engineering projects through identification, analysis and control of risk factors which affects the software enterprise resources. Risk creates a possibility of a threat, failure or any undesired/negative penalty on software engineering projects [1]. Hoodat and Rashidi (2009) initiated a probabilistic model to assess and analyse the risk factors in software engineering projects and also they used a risk tree model to correlate sources of several risk factors to categorize different risk factors [2]. Cerpa et al. (2010) used a logistic regression model to forecast result of the project and analyze effects of various risk factors on the results [3]. López and Salmeron (2012) depicted a checklist of risk factors which affects the software project performance where all risk factors were kept in a four quadrant matrix on the basis of their probability ratings and impact factor [4]. Huang and Han (2008) surveyed the cluster analysis technique application to categorize various risk factors [5]. Nakatsu and Iacovou (2009) considered the effect of important risk factors on project result for outsourced cum off shored software engineering projects using the Delphi method [6]. Keil et al. (2008) examined the risk perception and decision making factors of software practitioners [7]. Jani (2011) projected a simulation-based experiment for assessment of risk factors in software development projects [8]. Kumar et al. (2013) explored the correlation among the awareness level of

customers support, environment-friendly distribution, effective training programme schedule for the customer, recycling and reuse efforts of organization to estimate the customers’ role in green supply chain management model [9]. Hachicha and Elmsalmi (2014) examined using ISM tool for the interaction between risk factors for supply chain network management systems [10]. The identified risk variable factors were then prioritized based on the MICMAC analysis. Raeesi et al. (2013) took a formal evaluation to identify several distortions which create barriers to entrepreneurship and by using the ISM approach; they analyzed the systematic interactions among barriers [11].

III.

IDENTIFICATION OF RISK

FACTORS INVOLVED IN SDLC PHASES

The table 1 highlights the sequence order of 34 important risk factors related to the software engineering projects.

TABLE 1

VARIOUS RISK FACTORS INVOLVED IN SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE) PHASES

Risk Factor

(RF)

Subject Descriptions

RF1 Reduced budget It results poor quality of software project. RF2: Improper feasibility

study is performed

It affects towards forecasting of project duration, resources, software cost,

manpower cost, on time delivery.

RF3: Un acceptance of the Plan in time by client

It is difficult to produce software requirement specifications. RF4: Very complicated to

breakdown the larger projects into proper steps and estimate the required amount of work, time and cost

Difficulty in dividing the large projects into smaller modules.

RF5: Ignorance of Proper inspection of the project planning

It creates bad impact on requirement analysis.

RF6: Very less time given for software

engineering

requirements and the creation of system specifications

It may results difficulty in design the system software.

RF7: Prescribed inspections are often ignored as

209

Copyright © 2016. Vandana Publications. All Rights Reserved.

procedure

RF8: Required technology previously not known

Time overrun for the project may result because longer time needed to understand the new technology. RF9: The user interface

design is given very less resources or less time

It may affect the preliminary software design

RF10: The Test planning is often ignored

More defects in software may result RF11: The chosen

architecture may not be compatible with the selected technology

It causes the difficulty in designing system architecture

RF12: The work that was ignored during the previous stages must be done before the actual execution is done

If Requirement stage work is ignored, then it will give bad impact on next stage i.e. design phase

RF13: The design of Test cases is very difficult

It may difficult to produce software test document

RF14: The Unit-level testing is too often ignored

It affects in software integration testing because more defects may come

RF15: The required drivers for running and testing the

components and sub systems have not been formed

It will be difficult to test the software system

RF16: Test cases and test data may be completely impractical

Customer should provide the valid range of data to software developer otherwise software may hang. RF17: Automation may be

difficult

It results longer time in software execution. RF18: The integration test

plans are missing

It affects software integration testing. RF19: The system test plan

is missing

It affects system testing.

RF20: There may not be actual criteria for acceptance of the system

System acceptance testing will be difficult.

RF21: The understanding of requirements and Test cases based on requirements may be

It results wrong output in unit, integration and system testing.

entirely different

RF22: Schedules are set prior to the project is defined

The uncertainty due to unrealistic schedule can impact the Poor planning, software project performance and control

RF23: Too much schedule pressure

It results long overtime work, late stay for the software developers, testers.

RF24: Change of major requirements done after software requirements stage

It may affect the software architecture design and detailed design.

RF25: Poor project planning, tracking, measurement and estimating methods

Cost overrun and time overrun for the software project may result.

RF26: Poor pretest defect removal techniques

It will affect to software configuration

management. RF27: Insufficient office

space and Inadequate environment

Employees’ retention and ergonomic factor will affect.

RF28: Poor training for management and staff

Project management skills by project manager will be affected. The efficiency by the staff will also be affected.

RF29: Poor support for reusable designs and code

It affects to software development stage developed by software developers.

RF30: Inadequate use of skilled professional

Inexperienced manager cannot make and implement better decision to control the uncertainty situations in software projects. RF31: Domain knowledge is

insufficient

It is very difficult to quantify the hardware and software

requirement for the software projects. Thus it significantly affects the project management skills.

RF32: Insufficient of technology knowledge

210

Copyright © 2016. Vandana Publications. All Rights Reserved.

project planning. RF34: Defectively

engineered software

It affects on quality of the software.

The risk factors mentioned in table 1 are categorized based upon the significant different phases of software development life cycle projects. If those risk factors are considered successful in software development projects, this in turn gives the improvement in the quality of the software projects. There are mainly 5 phases of SDLC, namely 1. Planning phase, 2. Analysis phase, 3. Design phase, 4.Implementation phase and 5. Maintenance phase.

The above risk factors are further categorized into five subgroups as follows:

1. Planning Phase: RF3, RF 4, RF 5, RF 6, RF 8, RF 10, RF 20, RF 22, RF 23, RF 24, RF 25,RF 33,

2. Analysis Phase: RF1, RF 2, RF 7, RF 21, RF 34 3. Design Phase: RF9, RF 11, RF 12, RF 26

4. Implementation phase: RF13, RF 14, RF 15, RF 16, RF17, RF 18, RF 19, RF 27, RF 28, RF 32

5. Maintenance Phase: RF 29, RF30, RF 31 Significance of each phase is explained below:

Planning Phase: The software project team plans for the requirements of each software item. It involves of different components when an external customer gives their requirements to software project team. Each software item consists of the capability and functional specifications, performance, and external interfaces, software qualification requirements, data, database needs, installation and acceptance requirements of the software products to be delivered, user document, end user execution and operation needs. The software requirements shall be planned for the traceability to requirement and design for the system software, external consistency with system software needs, testability and feasibility of system software design [12].

Analysis Phase: The inputs for software analysis are software architecture, interface design document, system architectural design. Then, the SRS (software requirement specifications) document for the software engineering project will be developed by the software developer. The software test team and software developer will do TVPL (test and validation plan) and TVPR (test and validation procedure) based on SRS document. Software review team will perform software requirements review through MOM (minutes of meeting), compliance statement, software change proposal for parent document [12].

Design phase: The software design involves two steps, namely preliminary design and detailed design. The preliminary design steps involve transformation of the requirements for the software items into architecture which identifies the software components and mentions its top level structure. The entire software requirement items are allocated to its software components and further it helps in

detailed design. Software developer will generate an user interface design document for the external interfaces, software design document. Then, software integration schedule shall be formed. The software architectural design shall be evaluated for tracebility to the software requirements, external consistency with the software requirements, internal consistency between the software components, and appropriateness of design methods. This stage develops the guidelines of top level software architecture design for structural and objects oriented design approach, form the template of top level architecture and offer checklist for design review [12].

Implementation phase: In this phase, the risk-management principles and practices should be implemented into software development life cycle management. The Spiral model of SDLC is known as risk driven software development process model. The implementation phase covers the test case design, unit testing, integration testing and system testing, drivers & simulators, automation, and technology knowledge. The implementation of risk management involves the use of the spiral model technique, which decides the overall sequence of life-cycle activities, techniques, plans and specifications [12].

Maintenance phase: The software modules will be integrated with hardware configuration items and manual operations as necessary into the system. The integration testing results shall be documented. For conducting system qualification testing, a set of test case, test procedure, inter case dependencies will be developed and documented for each qualification requirement of the system. The integrated system shall be examined based on the test criteria of system requirements, correctness between actual output and expected output, and achievability of system qualification testing.

The system acceptance test team (external customer) will do system installation testing which delivers system test results. The system software integration team will do system defect isolation that results CSCI (computer software configuration item) wise defect allocation. The software module developer team will do CSCI defect resolution activity which completes system software maintenance.

Research Model:

Figure 2: Research Model for Optimum Risk factors

The flow of risk factors is shown in Fig. 2. This flow ensures the effective software project which

Design phase

Software Project Success

Analysi s phase

Implementation phase

Maintena nce Phase Planning

211

Copyright © 2016. Vandana Publications. All Rights Reserved.

of the software engineering projects. It is an important factor to consider that, if the project manager fails to detect such risks, then software projects may collapse entirely.

IV.

CONCLUSION

This investigation identifies 34 risk factors in the requirement planning phase, analysis phase, design phase, implementation phase and maintenance phase of SDLC process. These risks are existed in each different phases of software development projects which in turn affects the quality of the software projects. By managing these 34 risk factors in software projects of IT industries, the optimum quality of the software engineering projects can be achieved. Further, based on these outputs, the industries may improve the quality of software through implementing all risk factors.

REFERENCES

[1] Boehm BW, Software risk management: principles and practices, IEEE Software, Vol. 8, No. 1, pp. 32-41, 1991.

[2] Hoodat H and Rashidi H, Classification and analysis of risks in software engineering, International Journal of Computer, Electrical, Automation, Control and Information Engineering, Vol. 3, No. 8,pp. 2044-2050, 2009.

[3] Cerpa N, Bardeen M, Kitchenham B and Verner J, Evaluating logistic regression models to estimate software project outcomes, Information and Software Technology, Vol. 52, No. 9,pp. 934-944, 2010.

[4] Lopez C and Salmeron JL, Risks response strategies for supporting practitioners decision-making in software projects, Procedia Technology, Vol. 5, pp. 437-444, 2012. [5] Huang SJ and Han WM, Exploring the relationship between software project duration and risk exposure: a cluster analysis, Information and Management, Vol. 45, No. 3, pp. 175-182, 2008.

[6] Nakatsu RT and Iacovou CL, A comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: a two-panel Delphi study, Information and Management, Vol. 46, No. 1, pp. 57-68, 2009.

[7] Keil MLiL, Mathiassen L and Zheng G, The influence of checklists and roles on software practitioner risk perception and decision-making, The Journal of Systems and Software, Vol. 81, No. 6, pp. 908-919, 2008.

[8] Jani A, Escalation of commitment in troubled IT projects: influence of project risk factors and self-efficacy on the perception of risk and the commitment to a failing project, International Journal of Project Management, Vol. 29, No. 7, pp. 934-945, 2011.

[9] Kumar S, Luthra S and Haleem A, Customer involvement in greening the supply chain: an interpretive

structural modeling methodology, Journal of Industrial Engineering International, Vol. 9, No. 6, pp. 1-13, 2013. [10] Hachicha W, Elmsalmi M, An integrated approach based-structural modeling for risk prioritization in supply network management, Journal of Risk Research, Vol.17, No. 10, 1301-1324, 2014.

[11] Raeesi R, Dastranj M, Mohammadi S and Rasouli E, Understanding the interactions among the barriers to entrepreneurship using interpretive structural modeling, International Journal of Business and Management, Vol. 8, No. 13, pp. 56-72, 2013.