URJC 2009: Matching the Staged Model and Orphaning

8/8/2019 URJC 2009: Matching the Staged Model and Orphaning

http://slidepdf.com/reader/full/urjc-2009-matching-the-staged-model-and-orphaning 1/23

Introduction to Stage ModelStage Characteristics

Introduction to OrphaningMatching Stage Model and Orphaning

Conclusions

Stage Model and Orphaned Lines: How to applyhuman resources metrics to guess things

Daniel Izquierdo Cortazar

[email protected]/Libresoft, Universidad Rey Juan Carlos

GSyC/Libresoft SeminarFebruary, 3th 2009

Daniel Izquierdo Cortazar Stage Model and Orphaned Lines: How to apply human resource

http://find/

http://goback/





Conclusions

(cc) 2009 Daniel Izquierdo Cortazar.Some rights reserved. This document is distributed under the Creative

Commons Attribution-ShareAlike 2.5 licence, available inhttp://creativecommons.org/licenses/by-sa/2.5/

Daniel Izquierdo Cortazar Stage Model and Orphaned Lines

http://goforward/

http://find/

http://goback/





Conclusions

Table of contents

1 Introduction to Stage Model

2 Stage Characteristics

3 Introduction to Orphaning

4

Matching Stage Model and Orphaning

5 Conclusions


http://find/

http://goback/





Conclusions

Index




4

Matching Stage Model and Orphaning

5 Conclusions


I d i S M d l

http://find/

http://goback/





Conclusions

Stage Model: Phases

Initial Development

Evolution

Servicing

Phaseout

Closedown


I t d ti t St M d l

http://find/

http://goback/





Conclusions

Initial Development

Software team expertise: The team adds to its knowledge,the domain and the problem (critical for future evolution)


Introduction to Stage Model

http://find/

http://goback/





Conclusions

Evolution

Iterative changes, modifications and deletions carry on

Customers ask for new functionality

There are some early releases



http://find/

http://goback/





Conclusions

Servicing

Software must have an appropriate architecture and a skilled

development team

”When these are lacking, the software enters the servicing orsaturation stage when it is considered aging, decayed orlegacy.

Modifications are expensive and difficult, so they are avoid

and the old software is not changed at all.Each change degrades the architecture.



http://find/

http://goback/





Conclusions

Phaseout

The company does not carry on more services, and tries togenerate as much benefits as possible from the unchangedsoftware.

It becomes out of date



http://find/

http://goback/





Conclusions

Closedown

The company shuts down the software.

Users are asked to use another replacement system.



http://find/

http://goback/



gStage Characteristics


Conclusions

Index




4 Matching Stage Model and Orphaning

5 Conclusions



http://find/

http://goback/





Conclusions

Staff Expertise

It is critical during the first two phases (Initial developmentand Evolution).

In next phases the software is considered as a black box, bigchanges are not allowed and staff expertise is less important.



http://find/

http://goback/





Conclusions

Software Architecture

Initial architecture loses its original integrity.After first steps, it is required a redesign.

New code damages the architecture making it cryptic andhard to understand


Introduction to Stage ModelS C

http://find/

http://goback/



Stage CharacteristicsIntroduction to Orphaning

Matching Stage Model and OrphaningConclusions

Software Decay

This is a mix of loss of staff experience and loss of architecture coherence.

As architecture degrades, there is a need for expertise torecognize and improve the architecture.

However, as a project ages, experienced people tend to leave,and they are replaced by people with less tacit knowledge

and less expertise.This is totally the opposite needed by a decayed project.


Introduction to Stage ModelS Ch i i

http://find/

http://goback/





Index





5 Conclusions


Introduction to Stage ModelSt Ch t isti s

http://find/

http://goback/





Approach to measure knowledge loss due to developerturnover

There is a natural regeneration of developers

We can measure knowledge in terms of lines of source code

How do the companies deal with it?



http://find/

http://goback/





Orphaned Lines vs Size

1998-02-28 2000-02-28 2002-03-28 2004-03-28 2006-03-28

Time

0

200000

400000

600000

800000

1000000

1200000

N u m b e r o f L i n e s

Ev. Total Lines

Ev. Orph. Lines

GIMP Total Lines

GIMP Orph. Lines

S ze an Orp ane L nes Evo ut on



http://find/

http://goback/





Index





5 Conclusions



http://find/

http://goback/





Common Ideas

Regeneration of developersKnowledge loss

Aging of the source code

Code decay



http://find/

http://goback/





Common Ideas

We could detect changes in the state of the software in anautomated way

Big amounts of orphaned lines may mean: ”take care, youshould deal with your knowledge loss” or ”your team expertiseis low in some modules”

We are able to notify about high levels of developers

regeneration. (going to Servicing phase?)Useful to make decisions



http://find/

http://goback/



gIntroduction to Orphaning


Index





5 Conclusions



http://find/

http://goback/




Conclusions

Stage model provides a theoretical framework.

We could give a practical approach and provide data tovalidate it.

Evolution and GIMP are two interesting examples to be takeninto account in this study.

Customers could also know about the stage of their software,from an empirical point of view and they can compare with

others.



http://find/

http://goback/




Conclusions

Questions?

Thanks for your attendance!Questions?


http://find/

http://goback/

URJC 2009: Matching the Staged Model and Orphaning

Documents

Transcript of URJC 2009: Matching the Staged Model and Orphaning