Software Risks management through ACQUISITION STRATEGY (A new approach “SFR Documentation”)

Software Risks management through

ACQUISITION STRATEGY

(A new approach “SFR Documentation”)

1

[email protected],Student of M.Tech(SE) II yr,IT&SE Deptt.,ITM Gurgaon)

2

[email protected], Lecturer CSE deptt. MVN Faridabad (Haryana).

3

[email protected], Student of M.Tech(SE) II yr,IT&SE Deptt.,ITM Gurgaon)  

ABSTRACT

The goal of acquisition planning is to create a roadmap that a program can follow to maximize its chances of successfully fielding a system that meets users’ needs within cost and on schedule. Many programs struggle during acquisition planning because even though a wealth of information exists, the process itself is not clearly defined or understood.

Software acquisition planning is a powerful process that can help define the most promising acquisition options that best mitigate risks in the development of software. Developing an acquisition strategy is a key component of acquisition planning that provides a means of addressing risks through the program structure. Programs need structured ways to reason about software risks, formulate acquisition strategies to mitigate software risk, and evaluate their current acquisition strategy in an ongoing, systematic manner.

In this paper we are trying to define the classification of the various factors through which the acquisition strategy can be easily enhanced. We also trying to show that how these acquisition factors can be used to manage the software risk with a new approach.

INTRODUCTION

The goal of acquisition planning is to provide a route that is required to follow so that the chances to meet with the user’s requirements can be done easily , within the prescribed schedule & budget .

An acquisition plan guides all elements of program execution to transform the mission need into a fully supported, fielded system that delivers the desired capability. Developing an acquisition strategy is a key component of acquisition planning that provides a means of addressing program risks through the program structure. In most cases, however, acquisition planning and acquisition strategy development is done in an ad hoc manner, without consideration of the internal and external factors driving the project.

For software-intensive systems, the acquisition strategy must acknowledge the type and extent of software risk to the program and include plans to actively mitigate those risks. Programs need structured ways to reason about software risks, formulate acquisition strategies to mitigate software risk, and evaluate their current acquisition strategy in an ongoing, systematic manner.

Hence it is very important to find out the classification scheme for the various strategic factors so that it becomes easier for the developers to adhere with it.

What is AQUISITION STRATEGY?

Various definitions for the acquisition strategy are given, but in our view the term acquisition strategy can be simply stated as…………..

“The way to enhance the Software acceptance rate through a managerial & technical approach”. Or it can be better understood as…..

A business and technical management approach designed to achieve program objectives within the resource constraints imposed. It is the framework for planning, directing, contracting for, and managing a program. It provides a master schedule for research, development, test, production, fielding, modification, postproduction management, and other activities essential for program success.

The acquisition strategy is the basis for formulating functional plans and strategies (e.g., Test and Evaluation Master Plan (TEMP), Acquisition Plan (AP),

competition, systems engineering, etc.) [DAU 03]. ACQUISITION STRATEGY BASIC ELEMENTS

While developing an acquisition strategy, a program manager’s first task is to define the elements of that strategy. When defining strategy elements, it is useful to ask the question, “What acquisition choices must I make in structuring this program?” Inevitably, asking this Question leads to more detailed questions such as

• What acquisition approach should I use?

• What type of solicitation will work best?

• How will I monitor my contractor’s activities?

• & many more [ref2]

TABLE:A [ref 3.4]

The Acquisition Approach is a decision that must be made by the program manager—it is a strategy element. By seeing the TABLE:A Lets take some of acquisition strategy considerations for e.g.

Interoperability. This seems not to be here because interoperability doesn’t solely depends on the acquisition process, hence it must be put in some other category such as program driver. Similarly if we see capability it is also not the strategic factor which is supposed to be addressed by the program manager. Hence we can say that there is a requirement to classify the various acquisition factors into their proper categories, so that it becomes easier for understanding & also leads to enhance the overall product success.

STRATEGIC FACTOR CLASSIFICATION

After considering the above table we feel that there is a requirement to classify the various strategic drivers into their respective classes. But before classifying them we are providing some guidelines as written below.

1. This strategic factor classification is standard one in which the variations can be made on the basis of current working scenario.

2. The classified strategic factors are of open limit type, means they are not adhere to their specific class only. 3. All the addressed strategic factors are required to be assigned by the technical & management part of the

organization.

The table below is showing the various classes & their respective Strategic factors. S.NO CLASS OF STRATEGIC FACTORS STRATEGIC FACTOR

1. FEASIBILTY TELOS*

Criticality

2. ACQUISITION ENVIRONMENT Policies

Resource availability

Mandates

Culture

3. PROGRAMMATIC Budget

Schedule

Scope understand level

Customer patience

4. ORGANIZATION Stakeholders

Staff Skills

Staff Stability

Process Focus

Staff Capacity

Level of Agreement

Supplier Staff Skills

Supplier Staff Capacity

Supplier Staff Stability

Supplier Performance to Date

Critical persons

Criticality shifting rate

Dedication

5. DEVELOPMENT LIFE CYCLE Selection of model

Product Definition and

Specification

Architecture and Design

Maintenance& Support

Techniques used

Effort with resources

Flow of work

No of sites

Guarantee or Warranty

Dependencies on supplier & Phases of working

Dependence on Third party work acquisition

6. AFTER SALE Competitor war strategy

Disposal strategy

TABLE: B

*TELOF: Technical Ethical Logical Organizational Financial

HOW TO USE THESE FACTORS IN MANAGING SOFTWARE RISK?

For the purpose of software risk management the above cited classification will play an important role, but before understanding how let make some presumptions as…..

• The strategy factors can be related to the production of risk for the program.[2]

• The strategic factors within strategy classes can be ranked in order of their ability to address the program’s identified classes of risk.

• The strategic choices within strategy classes can mitigate risks generated by specific strategy factors.

SFR DOCUMENTATION

On the basis of above assumptions we can formulate that how we can use these factors as managing risk, There are several steps for it such as……….

1. Initially identify all strategic factors.

2. Assign each of them into its respective class, if one strategic factor span is more than 3 classes than put it into principle strategic factor list.

3. All strategic factors having span 2 or less than 2 are required to be put into the standard strategic factor list.

5. Develop a new document called SFR “strategic factors risk”.In which following fields are required to filled .

6. The SFR construction must be carried in two ways i.e. with the key managers & without key managers but with critical persons of the organization.

7. After construction of both way SFR the main SFR has to be selected, but it doesn’t mean that the candidate SFR is of no use…it can be use once the product developed for the rechecking purpose.

STRATEGIC CLASS STRATEGIC FACTOR RISK ASSOCIATED STANDARD PRINCIPLE LIFE CYCLE Techniques use Technique may

obsolete

YES NO

Architecture &

Design Mismatch of design specification &req. specification YES* YES*

Fig :A “SFR”

8. On the basis of above document the more emphasis is given on those risks for which both yes are present. 9. For this purpose the copy of SFR is supplied to each department, so that they can verify their working

scenario on the basis of the SFR

10. Last but not lest “actively attck the risk else they will attack on you” as by TOM GLIB. CONCLUSION

While concluding this paper we can say that we hope that this approach will be helpful for all the researchers, practioners etc for managing the software risks easily. We hope that our paper will provide a basic set of tools which is highly requisite for the current market scenario in which without taking risks & without managing them it is not possible to sustain.

This paper also provides a way understand the acquisition strategy, it is also helpful in the early detection of the unwanted potential risks.

REFERENCES

[1] Software engg. By Rogger S pressman Edition six.

[2] www.sei.cmu.edu

[3] [Bernard 05] Bernard, Tom; Gallagher, Brian; Bate, Roger; & Wilson, Hal. CMMI Acquisition Module (CMMI-AM), Version 1.1(CMU/SEI-2005-TR-011, ADA441245).

[4] [Brownsword 04] Brownsword, Lisa L.; Carney, David J.; Fisher, David; Lewis,Grace; Meyers, Craig; Morris, Edwin J., Place, Patrick R. H.;Smith, James; & Wrage, Lutz. Current Perspectives on Interoperability(CMU/SEI-2004-TR-009). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University,

2004.http://www.sei.cmu.edu/publications/documents/04.reports/04tr009.html.

[5] [Carney 03] Carney, David J.; Morris, Edwin J.; & Place, Patrick R. H. Identifying Commercial Off-the-Shelf (COTS) Product Risks:

The COTS Usage Risk Evaluation (CMU/SEI-2003-TR-023,ADA418382). Pittsburgh, PA: Software Engineering Institute, Carnegie

Mellon University, 2003. http://www.sei.cmu.edu/publications/documents/03.reports/03tr023.html.

[6] [DAU 03] Defense Acquisition University. Defense Acquisition Definitions and Terms, 11th Edition. Fort Belvoir, VA: Defense Acquisition University Press, September 2003.