=Paper=
{{Paper
|id=Vol-1138/re4p22
|storemode=property
|title=Towards a toolbox for cost-calculation in the pre-requirements phase
|pdfUrl=https://ceur-ws.org/Vol-1138/re4p22.pdf
|volume=Vol-1138
|dblpUrl=https://dblp.org/rec/conf/refsq/MullerB14
}}
==Towards a toolbox for cost-calculation in the pre-requirements phase
==
https://ceur-ws.org/Vol-1138/re4p22.pdf
Towards a toolbox for cost-calculation in the pre-
requirements phase
Christian Müller and Kai Breiner
Fraunhofer Institute for Experimental Software Engineering (IESE),
Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany,
{christian.mueller,kai.breiner}@iese.fraunhofer.de
Abstract. Efficient and precise estimation of project costs even before a project
has started is a challenging task. Unfortunately, this is common practice for
small and medium sized enterprises (SME) when applying for projects. Without
budget (effort) and based on a minimal set of facts SME have to calculate a
proposed project’s effort without having the confidence that the proposal will
be granted. Therefore, in this paper the idea of a methodology is presented that
consists out of a toolbox, leveraging on the one hand to make an efficient esti-
mation and to present the facts on which decisions will be made as well. Using
the principle of reuse, SME can use this toolbox to create mockups/prototypes
out of the shelf along with an estimation of the project costs that are derived
from the according experience factory. Efficiency, understandability of the fea-
ture scope, and understandability of the estimated costs will characterize the
generated view on the project proposal.
Keywords: pre-contract cost estimation, tool supported bidding phase, re-
quirements engineering, requirements toolbox
1 Motivation
Estimating costs during the requirements phase is a common and necessary step while
producing software. In general there exist different established techniques that are
either algorithmic or non-algorithmic [1]. All of these techniques have three aspects in
common. First, there is (more or less) expert experience necessary in order to imple-
ment the technique. Second, the input to these techniques has to cover a significant
level of detail (e.g., complexity of features, feature descriptions, composition of dia-
logs). Third, decision makers lack of understanding the scope of the provided features
as well as the lack of understanding the relationship between provided features and
estimated costs.
When deciding whether to apply for a request for proposal, there is too less infor-
mation available to perform sound cost estimation. However, this is necessary in or-
der to produce a realistic proposal. If bidding for a request small and medium size
enterprises (SME) are often competing against each other. Thus, the estimated cost
needs to be as realistic as possible.
REFSQ, 2014.
Nowadays SME possess an increasing portfolio, which needs to be considered dur-
ing the creation of a proposal. Nevertheless, they do not use nor have a standard pro-
cedure to create such a proposal for a new request. For each proposal they have to
investigate in their archives of previous proposals to find relevant fragments that fit
on the current request and are tailored using individual fragments. In some cases the
proposal will be refined by adding prototype visualizations [2].
To tackle this problem Section 2 contains a description of the idea of a toolbox
leveraging the out of the box composition of proposals, which is able to produce
stakeholder-oriented views (e.g., costs, visualizations, or fact-sheets). Section 3 will
elaborate the benefits that arise if using the proposed toolbox. In Section 4, a roadmap
including the single steps to develop this toolbox will be presented.
Dialog DB Dialog Selection
manual e.g., storyboard
selection
generation
based on
Mockup Costs Features Plan
• Feature 1
$ • Feature 2
• Feature 3
Experience Factory
Information System at a Glance
Fig. 1. Draft of the solution idea.
2 Solution idea: Proposed Toolbox
In general the challenges mentioned above in the pre-project phase can be clustered as
follows:
• Efficient elicitation of customer-specific requirements.
• Understandable preparation of the facts for decision makers.
The solution idea to approach these challenges can be clustered as follows:
• Tool-supported methodology for effective and efficient support during the pre-
project phase.
• Semi-automatic generation of a project plan based on a mockup/prototype.
• Individual preparation of project facts for decision makers.
As depicted in Figure 1 the solution idea strongly relies on a dialogs or fragments
of dialogs out of the shelf (Dialog DB). Major contribution is that these artefacts are
used to create the proposal by selecting the desired subset of artefacts. This selection
can be combined into a concrete mockup, rough prototype, or some storyboard with-
out investing much effort. Based on previous experience, software development facts
about the single artefacts are known and can be evaluated fully automatically. Know-
ing the entire mockup, the tool can calculate the costs of the designated project based
on the data that is stored in the experience factory for each of the artefacts.
As a result, the toolbox cannot only determine the entire project cost, but can also
provide an overview about additional project facts. These facts include a description
about the features to be implemented (as a rationale for the calculated effort) as well
as a plan to conduct the implementation phase. For example, this can even be refined
in a way that the tool can propose some kind of Gantt chart reflecting intra-artefact
relationships that need to be considered during the development. Basically all views
can be provided in a way to support decision makers’ understandability of the feature
scope as well as the total costs.
Prior to the selection of the artefacts, a lightweight RE process, e.g., involving spe-
cific creativity techniques, can be executed in order to have an input for the manual
selection phase.
3 Assessment: Strengths and Weaknesses
Advantage of the proposed toolbox is that it reduces the effort that is needed to create
a project proposal. This means that the overall project costs can be calculated based
on previous experience. Further, all the necessary proposal facts can be summarized
and displayed in different views. This is of great importance to the decision makers,
who have to judge whether a project proposal reflects realistic costs and is feasible in
the end.
Major disadvantage is that the initial experience factory needs to be created and al-
so needs to be maintained over time. Another disadvantage is that by implementing
the toolbox, assumable a smaller set of products (portfolio) can be offered, because
the proposed project is build based on the known artefacts. Any additional tailoring
will result in the same activities as without using the toolbox. Nevertheless, the
amount of these traditional activities will be reduced anyway.
4 Related Work
Most of the traditional requirements engineering methodologies neglect the pre-
project phase. Staring point of these methodologies is the circumstance that the pro-
ject was granted and budget is available.
Despite that fact two process models exist that consider the pre-project phase: V-
Model XT and CMMI. V-Model XT concentrates on the view of the client side (who
is formulating the request for proposal) and neglects all aspects from the view of the
contractor [3] [4]. The description of the CMMI standard is similar. There is space for
acquisition activities, but there is also a lack of the contractor’s point of view [5]. A
first idea how a pre-project phase can be handled is described in [6]. The major focus
of this work is on the handling of risks.
For eliciting requirements exist many techniques that can be considered for the
scope of this work. These techniques can be clustered to:
• Interviews (e.g., conversation, structured interviews, workshops, focus groups,
questionnaires)
• Creativity techniques (e.g., brainstorming, Walt Disney method, Osborn
checklists)
• Observation techniques
• Analysis of existing documents and systems
Also, there exist a variety of different tools to create prototypes. Examples are Just-
inmind [7], ProtoShare [8], Axure [9], or MockFlow [10], to name a few. All of these
tools are able to create wireframes of the software to be developed as well as the nav-
igation and relation between the single screens. Disadvantage of these tools is the
inability to express the costs of finally implementing the wireframes within a software
development project as well as the capability to explicitly benefit of reusing artefacts.
5 Conclusion and Future Work
To develop a sound methodology, the information need for these pre-contract and
early project phases needs to be determined. To gather this information and in order to
gain a deep understanding of the particular information needed in each phase on both
business and client-side, workshops and interviews will be conducted with four SME
located in Germany. Another outcome of this information gathering phase will be an
understanding of the involved roles and used reference values. The collected infor-
mation will be consolidated afterwards in order to identify commonalities and differ-
ences in the SME’s individual processes. A first outcome of this information gather-
ing will be a generic process description including the relevant process steps, involved
roles and reference values underlying the calculation.
In a second step, different types of visualization will be researched in order to find
a suitable representation on which decision makers can rely on and use for their
judgment (e.g., correct scope of features, calculated costs for these features).
Using the defined reference process from the first step and the visualization con-
cept of the second step, a toolbox will be developed, which combines both and will
address the overall project goal.
Acknowledgements. The work presented has been developed in the research project
SmartOffer, which is funded by the German Federal Ministry of Education and Re-
search (BMBF) under the project number: 01IS13024.
6 References
1. Khatibi, V., and Jawawi, D. N. (2011). Software cost estimation methods: A re-
view. Journal of emerging trends in computing and information sciences, 2(1), 21-
29.
2. Flinders, K. (2010). Using pictures to explain software requirements could save
billions, http://www.computerweekly.com/Articles/2010/10/25/243517/Using-
pictures-to-explain-software-requirements-could-save-billions-says.htm, last visit-
ed on 05.08.2013.
3. Andrea, J. (2003). An Agile Request For Proposal (RFP) Process. In Proceedings
of the Conference on Agile Development (ADC '03). IEEE Computer Society,
Washington, DC, USA, pp 152.
4. Renault, S., Mendez-Bonilla, O., Franch, X., and Quer, C. (2009). A pattern-based
method for building requirements documents in call-for-tender processes. ;In Pro-
ceedings of IJCSA. 2009, 175-202.
5. Gallagher, B.P., Phillips, M., Richter, K., and Shrum, S. (2010). CMMI for Acqui-
sition: Guidelines for Improving the Acquisition of Products and Services, New-
York 2010.
6. Paech, B., Heinrich, R., Zorn-Pauli, G., Jung, A., and Tadijky, S. (2012). Answer-
ing a Request for Proposal - Challenges and Proposed Solutions. REFSQ 2012: 16-
29.
7. Justinmind – The best platform to define mobile and web apps with rich interactive
wireframes. http://www.justinmind.com , last visited on 23.12.13.
8. ProtoShare – Design Interactive Website, App and Mobile Prototypes and
Wireframes with ProtoShare. http://www.protoshare.com, last visited on 23.12.13.
9. Axure – Dangerously Interactive Prototypes. http://www.axure.com, last visited on
23.12.13.
10. MockFlow – Super-easy Wireframing. http://www.mockflow.com, last visited on
23.12.13.