In this chapter, we will discuss a scheme used by Boehm et al.~\cite{boehm99m} for conflict resolution in project requirements. This is followed by study that investigates the effectiveness of this scheme compared to just using default analysis within STAR. Note that this study was redone with SEESAW (\subsub{otherapp}) in a paper presented at {\bf ICSE'09}: {\em How to avoid drastic software process change}. \cite{menzies09}

\section{Conflict Analysis with S-Cost}\label{sec:scost}
Boehm et al.~\cite{boehm99m} describe a system called S-Cost. The purpose of this system to semi-automate the process of finding conflicts in cost - quality requirements of software systems. This system also works to facilitate the process of resolving those conflicts by presenting stakeholders in the software project with several strategies for the purpose of finding a proper compromise for all parties. In this section, we will present this system, describing briefly how it operates and explaining the strategies that it presents to stakeholders.

\subsection{The problem}\label{sub:scostprob}
Quality in software products was being attributed to service oriented customer satisfaction, which caused some qualities to be neglected (e.g. maintainability) and placed too much emphasis on usability. To remedy this, this was expanded to include the evaluation for not only the customer, but also the all the other stakeholders in a software product. This allowed considering cost, maintainability, interoperability and other software qualities as parts of what describe software quality. However, this also introduced the problem of coordinating all the stakeholders needs, causing cost-quality conflicts to emerge. This is exasperated by the complex dependencies that software cost has with the software quality attributes, as well as the large resolution space that is available to find solutions to these cost-quality conflicts. S-Cost was introduced as a semi-automated system in order to assist the stakeholders in visualizing and resolving conflicts by applying certain strategies to different modules of the software product.

\subsection{S-Cost}\label{sub:scost}
S-Cost combines two separate systems to provide its semi-automated risk resolution capabilities: USC-CSE WinWin system and the Qarcc tool. WinWin is based on a spiral model that aims at resolving conflicts between stakeholder needs, otherwise called as ``win conditions", and making everyone a ``winner". This system is manually manipulated, making it hard on stakeholders in larger products to identify the conflicts in their win conditions. Qarcc is a knowledge-based tool that identifies conflicts in software quality requirements, by using predefined stakeholder/quality-attribute relationships, and notifies stakeholders of these possible conflicts. Neither of these systems has the ability to get the effect of conflict resolution on development costs. S-Cost adds this ability, combining both systems to be able to find win-win solutions to quality conflicts, all while using COCOMO (COnstructive COst MOdel) to indicate cost estimates. This allows S-Cost to help resolve cost-quality conflicts as well as quality conflicts between different stakeholders. S-Cost is able to give suggestions (or strategies) for the stakeholder to apply to resolve cost conflicts, while keeping keeping affected stakeholders of the implications of these resolutions. Visualization and negotiation aids are provided as well by S-Cost.

\subsection{The strategies}\label{sub:scoststrat}

\input{figures/misc/dchange}

There are several strategies that S-Cost presents to the stakeholder, giving the stakeholder the option of choosing the degree to which to apply it to the different modules of the software product. Each strategy influences a subset of the COCOMO (in this case COCOMO II) software cost attributes, and each has its own pros and cons that are presented to the stakeholder. These strategies are the following:

\begin{itemize}
\item\textbf{Reduce/defer Functionality: }\textit{KDSI, DATA} - Reducing the functionality of the product will reduce size, hence reducing cost and easing maintenance. This however reduces the abilities of the product which influences customer satisfaction.
\item\textbf{Reduce/defer Quality: }\textit{RELY, DOCU, TIME, CPLX} - Reducing quality will drive costs and development time down, but will increase maintenance costs especially for products that will have longer life cycles.
\item\textbf{Improve tools, techniques or platform: }\textit{TIME, STOR, PVOL, TOOL, SITE} - Improving tools and the platform will cause training and platform costs to increase, but will improve maintainability and will reduce software cost and schedule in the long run.
\item\textbf{Relax the delivery schedule constraint: }\textit{SCED} - Tightening the delivery schedule will allow development time and cost to decrease but may negatively influence product capabilities.
\item\textbf{Improve personnel capabilities: }\textit{ACAP, PCAP, PCON, AEXP, PEXP, LTEX, KSLOC/PM} - Improving capabilities of analysts and programmers and transferring more experienced ones to the project would reduce the cost of the product while improving its quality. This would mean however that other products will lose skilled personnel, negatively influncing them, and the cost per person will increase due to using more skilled personnel.
\item\textbf{Reuse software assets: }\textit{ADSI, DM, CM, IM} - Reusing software code will allow the cost of the development to decrease, however the effect on the product's quality depends solely on the quality of the software being reused. 
\item\textbf{Improve coordination via team building: }\textit{TEAM} - Team building allows for removing interpersonal overhead, which drives down the schedule and the cost. This factor isn't always controllable however.
\item\textbf{Architecture and risk resolution: }\textit{RESL} - Reducing risk resolution will allow more resources to be allocated for product development, reducing the development time and cost. This will cause a need for additional risk management overhead however.
\item\textbf{Improve process maturity level: }\textit{PMAT} - Increasing this will help with reducing the time and cost of resolving product bugs and hence improves quality. Overhead is introduced with this however due to the need to implement the Software Engineering Institute's Capability Maturity Model.
\item\textbf{Improve precedentedness and development flexibility: }\textit{PREC, FLEX} - Having increased familiarity with the product type and more flexible development would reduce costs. Such factors are uncontrollable sometimes and depend on the development environment and history.
\item\textbf{Increase budget: }\textit{Revised win condition} - If Funds are available, this could allow the product to be more competitive and may increase ROI.
\end{itemize}

\section{Drastic vs. Conservative Control (Hoh In strategies)}
Earlier we presented a paper by Boehm that suggested using strategies  in order to impose control over a project and resolve conflicts in project requirements. These strategies were presented earlier, and are meant to override internal project parameters and policies. For this reason we have placed these strategies under the guise of drastic change. In the software world, these drastic solutions to conflicts within projects are suggested that would theoretically modify a project in the intended  manner. However these drastic solutions can have unintended effects , where a strategy like reduce functionality might deliver the effect of reduce cost and time of development, but also put in the risk of under delivering. This would not be helpful for the project as that might cause it to be poorly received. 

Conservative project changes are changes with in the project that abide by present project parameters, which is the way that star operates by default. We wish to present the following argument: Before performing {\em drastic changes} to a project,  it is  worthwhile to
thoroughly explore the available options within the current structure of a
project.  Through applying policies that avoid drastic change, we wish to see whether we are able to achieve the same or better effects compared to drastic changes, while at the same time attempting to avoid the negative side effects that drastic changes inherently have.

\input{figures/misc/how}

The \fig{how} presents the various strategies presented by Boehm et al., and there implementation within STAR. Note that the setting on the right hand side overrides any project settings that conflict with them. All the numbers indicate ratings, with KSLOC being the only exception, where the number is a ratio that is multiplied by the range that the project has in for the KSLOC attribute.

\input{figures/hohin/winloss-hohin}

As we did in the previous section, this section will also only concentrate on analysing the results for three of the four software engineering models used within STAR. The experiments for each scenario were run ten times, after which the data generated at the policy points was collected and passed through the Mann-Whitney unit test~\cite{mann47}, where each strategy is ranked. The total number of runs of STAR in this case study is 
\begin{center}
$strategies*projects*10$
\end{center}
 This calculates to a total of 400 runs, since we used the NASA projects. Note that the above figures are quartile charts that indicate the variations in the runs. Only the second and third quartile are shown in order to reduce the clutter of the graphs that would've been caused by outliers. ``\textbf{STAR}'' indicates conservative change, with none of the strategies being used. Also, the number on the left of the quartile indicate the rank according to Mann-Whitney. Threats weren't included in this study due to results that had it zeroed out across the board, with occasional outliers which produced messy, inconclusive results, a pattern seen several times throughout this thesis.
 
In terms of the results for effort, clearly avoiding any drastic change within the project  is the best choice, ranking first in all the tests. And while it did tie with other strategies for the different projects, conservative change maintained its rank across the multiple projects, irrespective of how constrained a project is. Another clear result is that improving programmer capability (pcap) is definitely not the way to go to maintain costs, ranking last for every project. Other notable observations include the reducing functionality does well until you hit the most constrained projects and that improving the tools used and the platform does best in the most constrained project. Note here however that, despite of the ranking, most of the alternative strategies are within ballpark figures of each other, except for the lowest ranking strategies, making those the most definitive result.

Moving on to development time, there seems to be a similar picture compared to the results under effort. Improving \textit{pcap} is still the worst thing you can do, and avoiding drastic change is still a favorable policy to go by. At worst, conservative change manages to be second for the most constrained project. On the other hand reducing functionality and relaxing the schedule both do very well with the lightly constrained projects (flight and ground), and improving the tools and platform used does best in the most constrained project. One very interesting definitive result comes from reduce quality in OSP2, where this strategy wins out by a large margin, while it scored mid-pack in all the other projects. This could be interpreted as saying the following: earlier in the project, reducing the quality of the product doesn't help with development time; however, as the development of the product nears the end stages, if you need to rush the project out, reducing the quality (which happens to reduce reliability and documentation) will help in getting the product out the door.  A word of caution here however: this short term payoff only comes at a cost in the medium term. As can be seen in the OSP2 results for effort in \fig{hohineffort} and defects in \fig{hohindefect}, the side effect of rushing a product out is larger effort and much larger defect numbers.

Finally, when it comes to defects, we see a consistent overall result that reducing quality will in fact increase defects. This is demonstrated by having \textit{reduce quality} rank last in all the projects, with an especially large margin in the more constrained project (OSP, OSP2). Here as well though, conservative change does well. It scores lowest with ground; however, looking at the quartile charts for ground, the difference between STAR and the higher ranked drastic change strategies isn't significant enough to declare a clear loss.

To conclude this section, we have and demonstrated that, overall, conservative change and policies that abide by project limits are a better, more consistent choice for project managers. Even though drastic change does seem to do better in some cases, the difference is either not significant enough or the strategy itself has serious side effects on other aspects of the project. 
