an architecture for effort estimation of solutions donatien koulla moulla
TRANSCRIPT
An Architecture for Effort Estimation of Solutions Based on Open Source
IWSM Mensura 2015 (Cracow, Poland)
Moulla Donatien Koulla
University of Ngaoundere (Cameroon)
Overview § Introduction
§ Effort Estimation for Open Source Software
§ Proposed Architecture for Solutions Based on
Open Source (Exploratory Research)
§ Discussion & Future Works
2
3
Introduction to Open Source § Much so*ware development is now done using other so*ware products with open licenses & using a coopera9ve & distributed model.
§ Many so*ware companies rely on Open Source So*ware to develop their customer solu9ons & products.
§ For an increasing number of organiza9ons & governmental agencies, Open Source so*ware is included in their business strategy.
4
Introduction to Open Source Research on effort es-ma-on of so*ware projects
§ focuses on conven9onal (tradi9onal) projects with commercial licenses
§ Does not take into account so*ware built using Open Source. Objec-ve Propose an architecture for effort es9ma9on for so*ware projects based
on Open Source
5
Effort Estimation in Open Source
§ Scarcity of research work on effort es9ma9on
in OSS
§ The development effort invested in a project
is usually not known, even a9er the OSS
so9ware has been released.
6
Effort Estimation in the Field of Open Source Software
Open Source es9ma9on is different from
conven9onal for several reasons:
§ Management
§ Development model
§ Requirements.
7
Es-ma-on context of a classical so9ware project
Es-ma-on context of a typical open source project
There is a customer who:
-‐ Pays for the so*ware (therefore, he has some control on the resources available, on the planning and on penal9es if deliverables not produced, or of poor quality (i.e. he can refuse to pay!).
-‐ States-‐documents his needs-‐requirements. -‐ Will use the func9onality. -‐ Wants the so*ware for a specific date.
The customer : -‐ Not known in advance. The customer is some future random users. He
can par9cipate to the development of so*ware or not. -‐ Does not specify in advance the func9onality he wants and at which
level of details. -‐ Does not pay: so he does not have some controls on the so*ware. -‐ Coordina9on ac9vity done by core-‐developers.
There is a so9ware development team:
-‐ With a project manager to plan & control (for budget & delivery date)
-‐ Paid people (therefore, they are ‘accountable’ to their boss and customer)
-‐ Paid people record their effort & a 9me recording system -‐ To collect historical data for management purposes.
Classical effort es9ma9on models are designed in this context .
The Open Source So9ware developer’s context:
-‐ OSS is supported by people all over the world. The developers are users of the so*ware. They are not known in advance. Generally, there is no formal project management regime, budget or schedule.
-‐ The mo9va9ons to contribute to OOS development are: improve programming skills, code for project is intellectually s9mula9ng to write, enhance professional status, enhance reputa9on in OSS community, etc.
-‐ The frequency of par9cipa9on when all work is volunteered is influenced usually by work-‐related need.
-‐ There is no formal project manager, so customer or manager does not had any control on the volunteers.
-‐ There is no formal document for requirements. -‐ Volunteers make some commitments and these commitments are
usually monitored-‐recorded by versioning system, mailing lists, bug-‐tracking system, etc.
8
8
The present work will be case-‐based research.
This architecture intended for similar cases
(projects) & is intended both for prac99oners &
industry.
A Proposed Architecture
9
A Proposed Architecture The characteris9c of OSS development that is not captured
by classical es9ma9on models is the effect of scheduling and the voluntariness of people’s par9cipa9on.
Compared to tradi9onal es9ma9on models, our proposal
includes in addi9on: § Effort of integra9ng the pieces of so*ware and new
func9onali9es; § Effort related to number of changes to source code
(commits); § Effort related to complexity of code.
10
§ The basic OSS system contains pieces of so*ware (components) that need to be adapted.
§ The Func9onal Requirements is as a sub-‐set of the user requirements.
§ NFR concerns: quality requirements, So*ware system environment requirements & technical requirements.
§ Based on these requirements, a target solu9on is designed.
§ Total effort invested is the sum of effort involved in each ac9vity.
§ Proposed architecture takes in account the specific characteris9cs to OSS (see page 8) as NFR.
A Proposed Architecture
11
In the context of solu9ons based on OSS, we have:
§ Effort of integra9ng
§ Effort related to quality agributes
§ Number of changes to source code (commits)
§ Effort related to the complexity of code
§ Capacity for hardware
§ Func9onal size for so*ware.
A Proposed Architecture
12
A Proposed Architecture (Exploratory)
13
A Proposed Estimation Architecture (Exploratory)
14
The present paper addresses the issue of an architecture of effort es9ma9on for solu9ons based on Open Source.
Next steps:
§ Refine the architecture.
§ Take in account other agributes in rela9on with
effort which have yet men9oned.
Discussion & Future Works
15
§ A more detailed discussion of what effort/cost drivers are missing from tradi9onal es9ma9on models that are needed to successfully es9mate Open Source development effort.
§ Include how to evaluate the proposal in real-‐life context & how to make generaliza9ons more robust analy9cal induc9on.
Discussion & Future Works
16
Adapt what is useful, reject what is useless, and add what is specifically your own.
Bruce Lee, arts instructor, filmmaker,
and the founder of Jeet Kune Do
I will receive the comments of audience from Professor Alain Abran by email to [email protected].
17