Nico, Exacto, por ese tipo de razonamiento creo que puede ayudar a que uno diga no pera pero eso no debería ser así. Pero estamos asumiendo que al menos uno de los developers tiene idea de seguridad. Que por experiencia propia, y sin ofender a nadie, en general los developers no tienen mucha idea de seguridad. Basados en que ambos developers no tienen un buen entendimiento de "buenas practicas" de programación, puede que la mescolanza de código constante entre dos personas cause que algo no este 100% correcto, o que uno asuma algo que el otro no hizo. Hay muchos factores que puede perjudicar, así como muchos que pueden ayudar. La realidad es que depende mucho de la situación y de que tan bien preparados estén los developers. Y si te pones a pensar, esto es algo que también afecta al desarrollo "común", asi que talves la respuesta es que no cambia en nada. :)
Bue, por eso preguntaba si alguien tenia data sobre el tema, porque sin datos reales solo puede tener "teorías" subjetivas sobre el tema. Slds 2009/9/24 Nicolás Sanguinetti <[email protected]> > 2009/9/24 Matias Pablo Brutti <[email protected]>: > > Interesantes los papers, pero ninguno se refiere a lo que yo mencione en > el > > email. Estoy hablando de estudios sobre si pair programming introduce mas > o > > menos vulnerabilidades en el código desde el punto de vista de la > seguridad. > > Estos papers son interesantes pero apuntan a otra cosa :D Gracias de > todos > > modos ! > > Slds. > > Va de nuevo la pregunta: cuáles son tus teorías en por qué ayuda (o > no) en el área de seguridad? > > Para mi ayuda (sin una demostración factual, pero ta, tenés dos > personas hablando del tema, si a una se le pasa por algo un detalle, a > la otra capaz que no) > > > > > 2009/9/24 Maximiliano Guzman <[email protected]> > >> > >> Ahí van algunos estudios: > >> > >> The costs and benefits of pair programming: > >> collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF > >> > >> Strenthening the case for pair programming: > >> www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF > >> > >> 2009/9/23 Matias Pablo Brutti <[email protected]> > >>> > >>> Me interesaria saber si hay algun estudio que indique si pair > programming > >>> introduce mas o menos bugs ( vulnerabilidades ) en el codigo. Tengo > teorias > >>> a favor y en contra. Pero seria interesante saber si alguna compania > hizo > >>> algun estudio serio del tema. :D Alguien sabe de algun estudio de este > tipo > >>> ? > >>> Slds > >>> > >>> 2009/9/23 Joaquín Vicente <[email protected]> > >>>> > >>>> > >>>> 2009/9/23 Agustin Nicolas Viñao Laseras <[email protected]> > >>>>> > >>>>> Carlos, es correcto lo que decis, veo la diferencia en PP que el > costo > >>>>> de hora de desarrollo es mas elevaldo (por poner 2 recursos en lugar > de 1) > >>>>> pero al mismo tiempo son menos las horas de desarrollo y menos los > problemas > >>>>> (errores, bugs, etc) que se podra presentar a posterior. > >>>>> > >>>>> Por lo tanto, y desde mi perspectiva, un mismo desarrollo lleva mas > >>>>> horas con 2 programadores separados que con 2 programadores haciendo > PP. Lo > >>>>> cual eleva el costo de hora en PP para cualquier proyecto. > >>>>> > >>>>> Corrijanme si no es correcta esta relacion de menor cantidad de horas > >>>>> para un mismo desarrollo haciendo PP. > >>>> > >>>> Se puede pensar el pair programming como la relación entre 1 senior > >>>> (equipo de pair programming) y 2 juniors (dos desarrolladores > separados). El > >>>> valor de la hora de trabajo de un senior es más cara que un junior, > pero es > >>>> mucho más eficiente trabajando que cada junior por separado. Incluso > puede > >>>> ser más eficiente que los dos juniors juntos. > >>>> > >>>> En el caso de dos personas haciendo pair programming, si bien parece > más > >>>> cara la hora de desarrollo, trabajan mucho más eficientemente. El > costo se > >>>> compensa y hasta puede ser más efectivo. > >>>> > >>>> > >>>> Joaquín Vicente > >>>> > >>>> _______________________________________________ > >>>> Ruby mailing list > >>>> [email protected] > >>>> > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > >>>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> --<自由編碼人>-- > >>> Ing. Matias Pablo Brutti > >>> Security Consultant > >>> Email : [email protected] > >>> Site: http://www.freedomcoder.com.ar > >>> > >>> _______________________________________________ > >>> Ruby mailing list > >>> [email protected] > >>> > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > >>> > >> > >> > >> _______________________________________________ > >> Ruby mailing list > >> [email protected] > >> > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > >> > > > > > > > > -- > > -- > > --<自由編碼人>-- > > Ing. Matias Pablo Brutti > > Security Consultant > > Email : [email protected] > > Site: http://www.freedomcoder.com.ar > > > > _______________________________________________ > > Ruby mailing list > > [email protected] > > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > > > > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > -- -- --<自由編碼人>-- Ing. Matias Pablo Brutti Security Consultant Email : [email protected] Site: http://www.freedomcoder.com.ar
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
