Investigación sobre las prácticas de ingeniería de software en México

Transcripción

1 Invstigación sobr las prácticas d ingniría d softwar n México RESUMEN El objtivo d la prsnt invstigación s idntificar los principals lmntos qu conforman la gstión dl softwar y con llo diagnosticar l stado actual d la producción d softwar n las organizacions. Para su laboración s llvó a cabo un procso d consulta con la comunidad d softwar n colaboración con la Asociación Mxicana d Calidad para la Ingniría d Softwar (AMCIS) y l Laboratorio d Sistmas d Información dl CIC-IPN durant l ms d agosto dl S idntificó l contxto n l cual s ncuntra la organización y la administración d los proyctos. La part d administración d proyctos, s nfocó n las áras d control tals como: tcnología, los costos, los plans, y l dsarrollo dl producto, rquir mdicions comprnsivas para la toma d dcisions dntro d los proyctos, y finalmnt la prspctiva d la calidad d softwar(modlos d calidad, factors qu influyn n la toma d dcisions, atributos qu indican calidad d los productos). Finalmnt s prsntan las conclusions dl análisis d las actividads d ingniría d softwar n la ciudad d México. Prsntada por: María d la Luz Villalobos Hrnándz. ESCA-IPN -mail:luzv@rocktmail.com Agustín Francisco Gutiérrz Tornés CIC-IPN. Palabras clav : Calidad, ingniría d softwar, control, administración d proyctos. 1

2 1.Introducción La industria dl softwar pos una gran tolrancia por part d sus consumidors. Mantin una visión d los sfurzos actuals y d la forma n qu facilitan las bass para trabajar n lína con los usuarios cuyos proyctos son afctados por los cambios n la práctica d la ingniría d softwar, proporciona una amplia prspctiva d los sfurzos por mjorar y ayudar n sus xpctativas. Un important indicador d la crcint participación d la informática n la conomía mxicana, s l Producto Intrno Bruto Informático (PIB), l cual crció 27.2% n términos rals n l año 2000 rspcto a 1999, sto s 4 vcs más qu la conomía n su conjunto. Con llo l sctor informático participa con 3.5% dl total d la conomía. A su intrior l sctor srvicios profsionals n informática crció 4.9% n términos rals [1]. Las organizacions ddicadas al srvicio d "análisis d sistmas y procsaminto informático", s ncuntran n su mayoría n l Distrito Fdral n dond s ubican casi 5 d cada 10 mprsas dl ramo. El cambio aclrado y d comptitividad global qu viv l mundo, dond la libralización d las conomías y la libr comptncia caractrizan l ntorno d convivncia para l sctor mprsarial, ha originado qu las mprsas s procupn por sr más ficints, brindando productos y srvicios d calidad. Dsd la década d los años stnta, l tma d la calidad ha sido motivo d procupación para spcialistas, ingniros, invstigadors y comrcializadors d softwar, ralizando invstigacions con dos objtivos fundamntals: la obtnción d softwar con calidad y la valuación d la calidad dl softwar. El ára d gstión y control d la calidad n proyctos d softwar n México s rlativamnt nuva y las mprsas si bin rconocn la importancia d la calidad, no s ncuntran suficintmnt prparadas para acptar los nuvos rtos qu tra consigo y ponr n práctica sus principios y técnicas. Con l objto d diagnosticar y orintar las accions d las prácticas d ingniría d softwar, s ralizó una invstigación acrca d la prspctiva d la administración d proyctos informáticos, y l impacto dl tma d calidad dl softwar como vntaja comptitiva. Est rport, sinttiza los rsultados d una consulta con ciudadanos vinculados con la actividad. 2.Asguraminto d la calidad d softwar El asguraminto d la calidad s una actividad inmrsa n todo l procso d ingniría d softwar, cubrindo aspctos tals como: métodos y hrramintas d análisis, disño, codificación y pruba; rvisions técnicas formals; l control d la documntación dl softwar y d los cambios ralizados; un procdiminto qu asgur un ajust a los stándars d dsarrollo d softwar(cuando sa posibl); y mcanismos d mdida y d información[2]. La obtnción d un softwar con calidad implica la utilización d mtodologías o procdimintos stándars para l análisis, disño, programación y pruba dl softwar qu prmitan uniformar la filosofía d trabajo, para lograr una mayor confiabilidad, mantnibilidad y facilidad d pruba, y lvar la productividad. Para controlar la calidad dl softwar s ncsario, dfinir los parámtros, indicadors o critrios d mdición, Tom D Marco[3] planta: "ustd no pud controlar lo qu no s pud mdir". Las cualidads para mdir la calidad dl softwar son dfinidas por innumrabls autors, los cuals las dnominan y agrupan d formas difrnts. 2

3 3.Mtodología Al buscar stadísticas acrca d las mprsas qu dsarrollan softwar n la ciudad d México, los datos ncontrados n l SIEM[A1], dl cnso d 1993 bajo l rubro d unidads conómicas por sctor sgún clas d actividad contmpla 224 mprsas prstadoras d srvicios d análisis d sistmas y procsaminto informático. Sin mbargo, éstas mprsas no rvlan l total actual d las mprsas qu dsarrollan softwar, pus no contmpla institucions gubrnamntals, institucions ducativas, d invstigación, tc. Al no ncontrar stadísticas acrca d la forma como s producido l softwar, s disñó un instrumnto piloto qu s aplicó a 25 lídrs d proycto como mustra. Esta primra fas, rvló qu las prsonas ncustadas dsconocían la forma n como la calidad total podría influir n la gstión d los proyctos. Por tanto, l instrumnto fu ajustado para aplicarlo no sólo a los lídrs d proycto, sino a consultors, programadors, administradors d bass d datos, tc., para obtnr una visión más amplia. Para su laboración s llvó a cabo un procso d consulta con la comunidad. Enfocándos n dos parts sncials: los antcdnts para ubicar l contxto n l cual s ncuntra la organización y la gstión d los proyctos. La sgunda part, s nfocó n las áras d control d los proyctos tals como: tcnología, los costos, los plans, y l dsarrollo dl producto, rquir mdicions comprnsivas para la toma d dcisions dntro d los proyctos, y finalmnt la prspctiva d la calidad d softwar(modlos d calidad, factors qu influyn n la toma d dcisions, atributos qu indican calidad d los productos). El custionario d 20 prguntas[a2], s xtndió a las organizacions qu producn softwar n la ciudad d México, invitando a una población d 100 prsonas n colaboración con la Asociación Mxicana d Calidad para la Ingniría d Softwar (AMCIS) y l Laboratorio d Sistmas d Información dl CIC-IPN y n trs smanas proporcionó una rspusta favorabl por part d los ncustados, s dscartaron 28 custionarios por no star compltamnt contstados, qudando solo 72, cuyos rsultados son prsntados a continuación. 4.Prsntación d rsultados Para comprndr las prspctivas d los ncustados, s clasificó a la población sgún su posición actual n la organización tal y como s mustra n la tabla y gráfica1. Tabla 1. Posición qu ocupa l participant dntro d la organización. Posición actual Porcntaj (%) 1. Lídr d proycto Consultor Programador/analista Administrador d bass d datos(dba) Administración d rds Soport técnico Otro Funt: Elaboración propia, agosto

4 Gráfica 1. Posición actual. Posición actual d los ncustados n ú m d p a r t i c i p a n t s Lídr d proycto o d quipo Consultor Programador/analista DBA participants administración d rds soport técnico otro Los ncustados podían marcar varias opcions, dpndindo d las funcions qu dsmpñan dntro d su proycto actual. El mayor porcntaj lo ocuparon los programadors/analistas, sguidos d los lídrs d proycto y consultors, los ncargados d brindar soport técnico y n solo un 4.9% los administradors d rd y d las bass d datos, también participaron con un 11.76% n auditors d sistmas, grnts, ncargados dl ára d sistmas, invstigadors, tc., agrupado n otros. También fu ncsario idntificar las actividads dond s dsmpñaban, considrando qu podrían dsmpñars n actividads simultánas, s propusiron 7 actividads gnrals y s dio un margn para qu los ncustados mncionarán alguna otra actividad no contmplada. Vr tabla y gráfica 2. Tabla 2. Actividads qu dsmpña l participant. Actividads Porcntaj (%) 1.Rqurimintos d softwar Disño d softwar Código y prubas d unidads Prubas intgración Asguraminto d la calidad Administración d la configuración Mjoras d los procsos Otro

5 Gráfica 2. Actividads n las qu s dsmpña Actividads dsmpñadas 40 n ú m d p a r t i c i p a n t s tipo d actividad Rqurimintos d softwar disño d softwar Código y pruba d unidads Prubas intgración Asguraminto d calidad Admón d la configuración Mjoras d procsos otros S dividiron n dos rubros las actividads: básicas y d asguraminto d la calidad. En las actividads básicas la fas d análisis, disño, codificación y prubas intgraban un 55.69%, n cambio las actividads d asguraminto d la calidad, administración d la configuración, mjoras d los procsos intgraban solo un 32.86%. El 11.42% rstant abarca las funcions d auditorías invstigación. La mayoría d las organizacions posn difrnts proyctos o contratos qu son tratados d manra simultána. Para podr hacr corrlacions ntr la prspctiva d las rspustas proporcionadas y las xpctativas d métodos d control, ra ncsario idntificar l giro d la mprsa, s dcir, conocr l tipo d softwar qu s dsarrolla, por llo s dfinió 10 giros principals. Vr gráfica y tabla 3. Tabla 3. Giro d la mprsa Giro Porcntaj (%) 1.Multimdia y wb Sistmas d información Sistmas distribuidos 0 4.Sistmas d timpo ral Sistmas d ingniría y cintíficos 0 6.Sistmas d control Sistmas d intligncia artificial Sistmas d goprocsaminto Assoría y consultoría Capacitación 0 11.Docncia invstigación Otro

6 Gráfica 3. Giro d las mprsas Prgunta n ú m d p a r t i c i p a n t s tipo d softwar D los lídrs d proycto y las áras dond s dsmpñan l 28.57% s n l ára d sistmas d información, y l 23.8% n las áras d assoría y otras actividads, n cambio los consultors l 27.7% s ddican al ára d docncia y l 18.18% al dsarrollo d proyctos multimdia y wb. 4.1.Exprincia laboral Sistmas multimdia y wb. Sistmas d información Sistmas distribuidos. Sistmas d timpo ral. Sistmas d ingniría y cintíficos. Sistmas d control Sistmas d Intligncia Artificial Sistmas d goprocsaminto Assoría y consultoría. Capacitación. Docncia invstigación. otro S pidió a las participants rvlaran l númro d años qu llvan laborando n la prsnt mprsa, así como l númro d años d xprincia qu posn n l ára d softwar. El timpo promdio d años laborando n la mprsa actual s d 5, con un rango d 1 a 24 años, n l caso d los años d xprincia n l ára d softwar fu d 7.84, con un rango d 1 a 30 años. Sgún datos d la ANUIES[4] n 1999, la población scolar d posgrado por ára d studio n Computación Sistmas manjaba 2857 prsonas cursando spcializacions, mastrías y doctorados lo cual indica una crcint dmanda d profsionals altamnt calificados. Varios d los ncustados posían mnos años d xprincia n l ára d softwar a psar d star laborando por mas años n la misma mprsa. Vr gráfica 4. 6

7 Gráfica 4. Exprincia laboral Prgunta núm. d participants a 5 6 a a a a a 30 antigüdad mplo actual ára d softwar 4.2.Construcción d quipos d trabajo El método d organización n quipos d producción d softwar tin sus orígns n l concpto d quipo: jf-programadors,propusto inicialmnt por Harlan Mils y dscrito por Bakr [5]. El núclo dl quipo stá compusto por un ingniro snior (programador jf), l cual planifica, dirig l análisis y las actividads d dsarrollo, coordina y rvisa todas las actividads técnicas dl quipo; un prsonal técnico (normalmnt d dos a cinco prsonas), y por un ingniro d apoyo, qu ayuda al ingniro snior n sus actividads y pud rmplazarl con una pérdida mínima d continuidad dl proycto. El nfoqu d la calidad total radica n dcrmntar l timpo n l ciclo d vida, incrmntar la productividad, crar mayor satisfacción n los clints y éxito n los ngocios. El cambio consistirá n dfinir lo qu ralmnt significa l nfoqu d la calidad para dirigirla[6]. Partindo d las stadísticas d la SECOFI[7], dond s postula qu la mayor part d las mprsas d srvicios n México s componn d micro y pquñas mprsas, s trató d dmostrar qu las mprsas ddicadas al ára d producción d softwar n México son micros y pquñas mprsas. Yourdon [8], propon la siguint squmatización d las organizacions d softwar: Pquños. Utilizan 1 programador d 1 a 6 mss. Los programas pquños no tinn intracción con otros programas; los stándars técnicos d documntación y notacions, así como las rvisions sistmáticas d los proyctos dbn usars, aunqu l grado d formalidad srá mnor al mplado n proyctos grands. Mdianos. Emplan d 2 a 5 programadors con duración d mnos d un año, xign la intracción ntr programadors y la comunicación con los usuarios; d ahí qu s ncsit cirta formalidad n la planación, documntación y rvisión dl proycto. 7

8 Grands. En los proyctos grands son d 5 a 20 programadors, n llos surgn los problmas d comunicación, admás xist la gran posibilidad d alta rotación d prsonal asignado al proycto durant su dsarrollo; lo antrior rquir dl ntrnaminto y la adoctrinación dl prsonal nuvo o d la distribución d rsponsabilidad ntr los intgrants dl grupo. Admás, son sncials los procsos sistmatizados, documntación stándar y rvisions formals. Como rfrncia, también s utilizó l critrio d pquños proyctos softwar mplado n CMM. Vr tabla 4. Tabla 4 Propusta d grupos d trabajo para dsarrollar softwar n micro y pquñas mprsas. Variant d pquño Númro d prsonas Timpo stimado Pquño mss Muy pquño mss Diminuto smanas Indidivual 1 1 smana Ridículo 1 1 hora Funt CMM d SEI vrsion 1.1 [5] En 1998 n l panl d la confrncia d SEPG n l CMM para pquños proyctos [9], proycto pquño s dfinió como una duración d 3 a 4 mss con 5 prsonas o mnos. Brodman y Johnson[10] dfinn una pquña organización como aqulla qu pos mnos d 50 dsarrolladors d softwar y un pquño proycto como aqul mnor d 20 dsarrolladors. El quipo dsarrollo d softwar pud star assorado por uno o más spcialistas (por jmplo: xprtos n tlcomunicacions, disñadors d bass d datos,tc.), por una plantilla d soport(por jmplo, documntadors, técnicos, jcutivos,tc.,) y por un administrador d bas d datos. El timpo stimado para ralizar los proyctos d softwar s catgorizó n 5 rangos. Vr tabla y gráfica 5. Tabla 5. Timpo promdio d duración d los proyctos Timpo stimado Porcntaj (%) 1 ms 20.83% 2 a 4 mss 13.88% 5 a 7 mss 26.38% 8 a 12 mss 25% más d 12 mss 12.5% Los programadors, analistas y dmás mimbros dl grupo d sistmas d una mprsa adoptan las dirctrics dl lídr d grupo, o d los mimbros dl quipo con mayor xprincia qu hayan trabajado n bunos quipos y posn alguna ida d cómo actuar. Sin mbargo, n la mayoría d los casos los quipos tinn qu atravsar por una varidad d sucsos por jmplo: las mtas, los rols d cada uno d los mimbros dl quipo, sus rsponsabilidads, como s tomaran las dcisions, los stándars y procdimintos qu ocuparán y n qu forma lo harán, los objtivos d calidad, l sguiminto d la calidad y qu s hará para alcanzarla, los procsos qu s utilizarán para dsarrollar l producto, la stratgia d dsarrollo y como s db producir l disño, la intgración y las prubas d producto, tc. 8

9 Gráfica 5. Timpo stimado para ralizar sus proyctos. 5.Duración d proyctos )más d 12 14% a)1 ms 21% d) % b)2-4 14% c)5-7 26% El númro d prsonas qu componn l ára d sistmas dntro d la mprsa s catgorizó por intrvalos. Vr tabla y gráfica 6. Tabla 6. Númro d prsonas qu componn l ára d dsarrollo d softwar Prsonal mplado para dsarrollar Porcntaj (%) softwar 1 a a a a más d Existn tantas structuras d organización d prsonal d sistmas como organizacions. Esto ayuda a comprobar qu la mayoría d las mprsas son micro y pquñas. En un pquño proycto d softwar, una sola prsona pud analizar los rqurimintos, ralizar l disño, gnrar l código y llvar a cabo las prubas. Cuando s manjan aplicacions para multimdios y hrramintas para dsarrollos wb, l prsonal rqurido oscila ntr 1 y 5, n cambio para la construcción o actualización d módulos d sistmas d mayor compljidad s pudn ocupar más d 21 prsonas, como n los casos d las mprsas d consultoría d sistmas d gstión, dond atindn varios clints a la vz. Vr gráfica 6. En proyctos grands, l númro d programadors s tan amplio qu las difrncias individuals n la productividad tindn a quilibrar l promdio, aunqu los módulos dsarrollados por un programador débil pudn xhibir pobr calidad y rtrasars n su ntrga. Los proyctos pquños y mdianos, d mnos d 5 prsonas, son muy snsibls a la capacidad individual d los programadors. A mdida qu l tamaño aumnta, db involucrars más prsonal. 9

10 Dsafortunadamnt, l añadir gnt a un proycto tin a mnudo un fcto dstructivo n l mismo, hacindo incluso qu la agnda s alargu más, pus mintras s nsña no s trabaja, y l proycto s rtrasa. Dbido al incrmnto d la ofrta d srvicios informáticos, las organizacions no pudn tardars más d 3 a 4 mss n laborar las aplicacions Gráfica 6. Prsonal qu compon l ára d softwar Prsonal d dsarrollo d softwar )21 o más 29% a)1-5 39% d) % c) % b) % 4.3. Administración d los procsos d softwar Los procsos d softwar dfinn las principals actividads qu contribuyn a su dsarrollo, la slcción o l mantniminto d un producto d softwar ajustado para darl un srvicio. También dfin las rlacions y las intraccions qu pudn xistir ntr las actividads, y los documntos qu son rsultado d dichas actividads. Para ésta scción, s dlimitaron 4 posibls rspustas para qu los ncustados mitiran su opinión n bas a los siguints critrios: 1. Si. Cuando la práctica stá bin stablcida y s jcuta consistntmnt como un procdiminto stándar d opración. 2. No. La práctica no stá bin stablcida o s ralizada inconsistntmnt. 3. No aplica. Pos l conociminto rqurido acrca dl proycto u organización pro la prgunta no s aplicabl al proycto actual dl ncustado. 4. Dsconoc. Pos incrtidumbr d cómo rspondr a la prgunta. 10

11 4.3.1.Plan documntado Para tnr una buna administración por proyctos s rquir qu l analista o l programador y su jf inmdiato laborn un plan d trabajo n l cual s spcifiqun actividads, mtas, prsonal participant y timpos. Est plan db sr rvisado priódicamnt (smanal, mnsual, tc.) para valuar l avanc rspcto a lo programado. Vr gráfica y tabla 7. Tabla 7. Sguiminto d algún plan documntado qu guí l dsarrollo para laborar un proycto. Opcions Porcntaj (%) Sí No No aplica 5.63 Dsconoc 0 Gráfica 7. Aplicación d plans documntados para construir softwar. Plan documntado f r c u n c i a si no no aplica dsconoc opcions Sólo n un 66.19% s sigu un plan documntado para dsarrollar un proycto. Aunqu n las organizacions cunt con los datos ncsarios para ralizar los plans d dsarrollo, sus programas stán basados n amplias suposicions las cuals a mnudo son irrals Análisis d rqurimintos El análisis d los rqurimintos rquir d gran comunicación y pudn surgir problmas tanto para l analista como para l clint. Es un procso d dscubriminto y rfinaminto. Tanto l qu dsarrolla l softwar como l clint, tinn un papl activo n la spcificación d rqurimintos. El clint intnta rformular su concpto, algo nbuloso, d la función y comportaminto d los programas n dtalls concrtos, l qu dsarrolla l softwar actúa como intrrogador, consultor y l 11

12 qu rsulv los problmas. El analista db stablcr contacto con l quipo técnico y d gstión dl usuario/clint y con la mprsa qu vaya a dsarrollar l softwar. El gstor dl programa pud srvir como coordinador para facilitar l stablciminto d los caminos d comunicación. El objtivo dl analista s rconocr los lmntos básicos dl programa tal como lo prcib l usuario/clint[11]. El softwar por su naturalza s muy cambiabl. Vr tabla y gráfica 8. Tabla 8. Prsonal ncargado d dfinir los rqurimintos junto con l clint Opcions: Porcntaj (%) Lídr d proycto Lídr comrcial 4.22 Ambos otro Funt:Elaboración propia, agosto Gráfica 8. Prsonal qu raliza l stablciminto d los rqurimintos con los clints. Prsonal para stablcr rqurimintos con los clints f r c u n c i a proyctos comrcial ambos otro rsponsabls Funt:Elaboración propia, agosto En la gráfica partindo d la hipótsis d qu l análisis d los rqurimintos lo ralizaban los lídrs comrcials y no los lídrs d proycto, al invstigar, s dmostró qu l 65.27% d las ntrvistas con los clints las ralizan los lídrs d proycto, mintras l 4.16% ra ralizado por los lídrs comrcials, y solo l 18.05% lo ralizaban n conjunto los lídrs comrcial y d proycto con l clint Evaluación d tcnologías Existn varias técnicas para hacr la valuación d las tcnologías, las cuals pudn sr útils n los sguimintos d los procsos y así compararlos con procsos similars utilizados por otros individuos, grupos u organizacions. Primro s busca ralizar procsos d mdición d tcnologías qu san indpndints d los procsos y qu rflj su capacidad y robustz. (vr tabla y gráfica 9.) 12

13 Tals comparacions dbn sr válidas para los difrnts tipos d procsos n los siguints términos: Mdir la habilidad d la tcnología para laborar productos d alta calidad. Organizar la información dl mjor al por. Indicar la habilidad d las tcnologías para liminar problmas. Estimar los costos. Tabla 9. Rvisión d las tcnologías xistnts n l mrcado ants d comnzar un proycto. Opcions: Porcntaj (%) Sí No No aplica 4.22 Dsconoc 4.22 Gráfica 9. Aplicación d una rvisión d tcnologías xistnts n l mrcado para ofrcr una buna solución al clint Bnchmarking d tcnologías si no no aplica dsconoc El nivl tcnológico utlizado n un proycto d programación incluy aspctos como slcción dl ambint computacional, prácticas d programación y hrramintas d programación disponibls. Al inicio dl proycto s rvisan las nuvas tcnologías xistnts n l mrcado para dtrminar la más adcuada a las ncsidads dl clint dond l 61.9% d los lídrs d proycto si valúa las tcnologías, mintras qu solo l 59% d los consultors lo fctúan. 13

14 4.3.4.Prácticas d softwar Si nadi obsrva los métodos qu los ingniros d softwar utilizan, nadi más sabrá como trabajan. Entoncs los ingniros no tinn qu cambiar sus métodos d trabajo si no lo dsan. Las prácticas d softwar son largas por sí mismas informals. Rogr Prssman[2] ilustra una distribución rcomndada d sfurzos ntr las distintas fass d dfinición y dsarrollo. Pon un mayor énfasis n las taras inicials d análisis y disño y n la tara trminal d pruba. Gráfica 10. Porcntajs d timpo invrtidos para las fass dl ciclo d vida Distribución d sfurzos frcuncia Análisis y disño codificación pruba y dpuración rangos En términos gnrals l porcntaj d timpo invrtido n las actividads d análisis y disño s d 37.18%, para la tapa d codificación un 35.67%, y finalmnt para la tapa d prubas un 23.33% Dpndindo d lo crítico qu sa l softwar, así srá la cantidad d pruba qu s rquira(vr gráfica 10). Dichos rgistros mustran l timpo sprado para dsarrollar l softwar. Los lídrs y consultors invirtn más timpo n disñar, n cambio los programadors invirtn mas timpo n compilar y corrgir rrors qu n cualquir otra actividad Capacitación Uno podría prguntars porqu la comunidad d softwar ha sido tan lnta para adoptar los principios d calidad. La rspusta aparc n qu stos métodos son difícils d introducir y no obvios por sí mismos. Por jmplo, pocos ingniros crn qu s más ficint l ncontrar los dfctos por las rvisions d código, qu por las prubas y la dpuración. Las organizacions dbn proporcionar la capacitación adcuada a su prsonal. 14

15 Los lídrs d proycto rcibn capacitación solo un 61.9%, n contrast con los invstigadors qu no rcibn apoyos para programas d capacitación n las institucions n dond laboran[12], n cambio los consultors si rcibn capacitación n un 63%. Los administradors d bass d datos y los ncargados dl soport técnico rcibn capacitación n un 90%. Vr gráfica 11 y tabla 10. Tabla 10. La capacitación proporcionada s la ncsaria para dsarrollar las bass y l conociminto rqurido para dsmpñar sus actividads Opcions: Porcntaj (%) Sí No No aplica 1.40 Dsconoc 7.04 Gráfica 11. Capacitación proporcionada. Capacitación f r c u n c i a si no no aplica dsconoc opcions Cambios n los proyctos La gstión d calidad s más bnficiosa n la mdida n qu sa posibl incorporar lmntos d lla n tapas más tmpranas dl ciclo d dsarrollo d softwar. Es claro qu un rror d dsarrollo ntr más crca d su funt d orign s dtct srá fácil d corrgir y por lo mismo l costo d aqulla corrcción srá mucho mnor. Vr tabla 11. Tabla 11. Comunicación ntr los mimbros dl proycto Opcions: Porcntaj (%) Sí No No aplica 4.22 Dsconoc

16 Gráfica 12. Comunicación ntr los mimbros dl proycto para ralizar los cambios y ajustar los plans. Información d cambios f r c u n c i a si no no aplica dsconoc opcions Por tradición, s considra qu la tara d programación s una actividad individual y privada, d modo qu muchos programadors tinn poco contacto social y prfirn trabajar n forma aislada[13]. El incrmnto dl tamaño dl producto d softwar, disminuy la productividad al aumnto d la compljidad d las intraccions ntr los divrsos componnts dl sistma, y a causa dl incrmnto d comunicación ncsario ntr programadors, grnts y clints. El dsarrollo d softwar s dmasiado compljo si no s mpla un control d calidad adcuado. Db habr un timpo prudnt para invstigar la mjora d los procsos d softwar. Al mdir la notificación d los cambios n los proyctos sólo l 70.83% comunica a los dmás mimbros qu l proycto va a sr modificado sobr todo n las áras d soport técnico, administración d bass d datos y d rds, y l 20.83% confirman la falta d comunicación ntr los mimbros. Vr gráfica

17 4.3.7.Control d proyctos La técnica más común para stimar un proycto s basar la stimación n l procso qu s va a utilizar, s dcir, l procso s dscompon n un conjunto rlativamnt pquño d actividads o taras, y n l sfurzo rqurido para cada tara. Un gran rror n la stimación dl costo pud sr lo qu marqu la difrncia ntr bnficios y pérdidas. La stimación dl costo y dl sfurzo dl softwar nunca srá una cincia xacta, son dmasiadas las variabls( humanas, técnicas, d ntorno, políticas, tc.) qu pudn afctar l costo final dl softwar y l sfurzo aplicado para dsarrollarlo. Vr tabla 12. Tabla 12. Factors qu compara para obtnr stimacions Opcions: Porcntaj (%) 1. Tamaño Costos Duración Rcursos humanos Tcnología Al analizar las actividads qu componn st procso dsd la prspctiva d la calidad organizacional, para llo s comparan las stimacions inicials con los rsultados n términos d: tamaño dl proycto aparc como l factor dtrminant con un 29.8%, sguido por l costo total dl proycto con un 27.6%, postriormnt a nivls similars qudan la duración cronológica con un 14.92% y los aspctos tcnológicos con un 14.17%, y finalmnt la stimación d los rcursos humanos con un 13.43%. Vr gráfica 13. Al pnsar n los mdios d control d las tapas d dsarrollo l 34.78% fctúa runions priódicas para conocr l stado dl proycto, situación qu s muy aconsjabl pus rduc significativamnt la tasa d rrors acumulados y con llo, los costos. Gráfica 13.Estimacions para l control d proyctos Rsultados vs stimacions inicials tcnología 14% tamaño 30% r.humanos 13% duración 15% costos 28% Funt: Elaboración propia, agosto

18 La valuación final d los rsultados d todas las rvisions ralizadas solo s prsntó n un 32.17%, n cambio l idntificar si las taras s han cumplido n las fchas programadas rfljó un Las runions informals con los mimbros para conocr sus valoracions subjtivas obtuvo un 15.65%. Tanto los invstigadors como l prsonal ddicado a las áras d control y sistmas d timpo ral dmostraron ponr mayor énfasis n stos cuatro factors, aunado claro stá a su nivl d xprincia n la coordinación d proyctos.vr gráfica 14. Gráfica 14. Actividads para mantnr un control dl proycto Mdidas para l control d los proyctos runions 16% runions 35% fchas 17% rsultados 32% Prubas El plan d pruba dscrib la forma n la cual s mostrará a los clints qu l softwar funciona corrctamnt, xplicando quién ralizó las prubas, las razons y cómo s condujron las prubas[14]. En cuanto a los plans d pruba solo l 15.27% raliza l plan complto d prubas, n promdio 13.63% d los lidrs d proycto utilizan un plan d prubas, los dmás solo jcutan prubas y las valúan. Vr gráfica 15. Cuando los componnts posn gran nivl d dfctos n las prubas, gnralmnt posn grands dfctos n sus usos subscunts [15]. Las prubas d los dfctos son ntoncs un bun indicador d la calidad n l trabajo. S dcidió agrupar los tipos d pruba n sólo dos grupos: prubas d caja blanca y ngra. 18

19 Gráfica 15. Fass dl plan d pruba aplicadas Fass d pruba valuación 30% objtivos 14% disño 36% pruba 20% Funt: Elaboración propia, agosto 2001 La pruba d la caja blanca prmit obtnr casos d pruba qu garanticn qu al mnos una vz s jrcitn todos los caminos indpndints d cada módulo, s jrcitan todas las dcisions lógicas n sus vrtints vrdadra y falsa; s jcutan todos los bucls n sus límits y con sus límits opracionals, jrcitn las structuras intrnas d datos para asgurar su validz, l 31% aplica sta pruba. Vr gráfica 16. La pruba d la caja ngra prmit obtnr conjuntos d condicions d ntrada qu jrcitn compltamnt todos los rquisitos funcionals d un programa. Intnta ncontrar rrors n funcions incorrctas o ausnts, rrors d intrfaz, rrors n structuras d datos o n accsos a bass d datos xtrnas, rrors d rndiminto y rrors d inicialización y d trminación. Esta pruba s mpla n un 21%. Gráfica 16. Tipos d prubas mpladas comúnmnt. Prubas qu utilizan comunmnt dsconoc 27% caja blanca 31% otra 21% caja ngra 21% Funt: Elaboración propia, agosto

20 En total, sólo l 38.04% utiliza ambas. Tanto n l caso d los lídrs d proycto como n l d los consultors y programadors la mayoría rfljó aplicar las prubas d la caja ngra n mayor mdida (8%) a difrncia d las d la caja blanca. El 21% utilizan otro tipo d prubas, ntr las qu s ubicaron las siguints hrramintas d automatización d prubas: 1. Vrificadors d pruba. Midn l alcanc intrno n rlación a la structura d control informa dl valor d cobrtura al xprto d garantía d calidad. 2. Gnradors d archivos d pruba dond los procsadors gnran y rllnan con valors prdtrminados, archivos d ntrada típicos para postriors prubas d programas. 3. Simuladors d ntorno dond modlizan l ntorno xtrno dl softwar d timpo ral para simular dinámicamnt las condicions rals d opración. 4. Prubas d rsistncia dond s nfrntan los programas a situacions anormals. Si la pruba s llva a cabo con éxito mostrará hasta qu punto las funcions dl softwar s adcuan a las spcificacions y s cubrn los rquisitos d rndiminto. El prsonal d prubas, valua los documntos y rgistros usados n la laboración dl sistma, así como todas las salidas y rports, la dscripción d las actividads d flujo d la información y d procdimintos, los archivos almacnados, su uso y su rlación con otros archivos y sistmas, su frcuncia d accso, su consrvación, su sguridad y control, la documntación propusta, las ntradas y salidas dl sistma y los documntos funts a utilizar. Vr gráfica 17 Gráfica 17. Contratación d prsonal xclusivo para ralizar prubas. Contrata prsonal xclusivo para prubas f r c u n c i a si no no aplica dsconoc opcions Funt: Elaboración propia, agosto 2001 El 6.94% d los ncustados rspondió qu contrata prsonal xtrno xclusivamnt para ralizar las prubas. 20

21 4.3.9.Modlos d calidad Uno d los campos n los qu más s ha trabajado s n la utilización d modlos d valuación d calidad d softwar qu tratan d aportar un mdio para dfinir y dscomponr l concpto d calidad d softwar n caractrísticas más sncillas d valuar y mdir. Entr los modlos d asguraminto y gstión d la calidad dl softwar s propusiron cuatro: ISO 9001 ISO , ISO SPICE, ISO Tick-IT, Capability Maturity Modl (CMM), contmplando la opción d qu los usuarios pudisn utilizar algún otro modlo, o n su dfcto qu no aplicasn ninguno. Vr gráfica 18. Gráfica 18. Aplicación d los modlos más comuns d asguraminto d la calidad d softwar Modlos d calidad utilizados n las mprsas 9001 Y 9000_3 28% Tick-IT 0% Spic 0% CMM 8% otro 5% ninguno 59% Funt:Elaboración propia, agosto El 28% utilizan l ISO 9001 ISO , l 8% utilizan l CMM, l 5.33% utilizan otros modlos, modlos propios qu llos van ajustando para satisfacr las ncsidads d los clints, l 58.67% contstó qu aun no aplican ningún modlo Calidad d softwar Dbido a qu son muchos los factors para mdir la calidad, s optó por obtnr información acrca d trs tmas spcíficos: los factors d calidad d un producto, los problmas a los qu s nfrntan al laborar un softwar y los factors qu incidn n la productividad dl softwar. Nuvamnt s dlimitaron los rangos d rspustas dsd los nivls bajo, mdio, alto y muy alto. Si s ncuntra a nivls alto para un dtrminado proycto, la productividad dl dsarrollo d softwar srá significativamnt más alta qu si l mismo factor stuvira por dbajo d la mdia (dsfavorabl). Los factors d calidad qu dscribn a un softwar sgún McCall [16] cntrándos n caractrísticas oprativas, su capacidad d soportar cambios y su adaptabilidad a nuvos ntornos. El Estándar ISO/IEC 9126[17] proporciona dfinicions d caractrísticas y subcaractrísticas qu sugirn algunos aspctos a analizar para buscar objtivos d calidad para un producto d softwar. El nfoqu gnral db studiar l risgo rlacionado con cada uno d éstos aspctos, y n caso d prsntars un lvado nivl d risgo s db spcificar un conjunto d objtivos d calidad para l producto d manra qu 21

22 puda limitars l risgo. A continuación mncionarmos los rqurimintos para las caractrísticas d Calidad. Funcionalidad. "Conjunto d atributos qu mantinn la xistncia d un conjunto d funcions así como sus propidads spcificas. Las funcions son aqullas qu satisfacn un stado o las ncsidads implícitas." Confiabilidad. "Conjunto d atributos qu rspaldan la capacidad dl softwar para mantnr su dsmpño bajo cirtas condicions n un priodo dl timpo". Eficincia. "Conjunto d atributos qu rspaldan la rlación ntr l nivl d jcución dl softwar y l monto d los rcursos utilizados bajo las condicions stablcidas." La ficincia dl softwar stá influnciada por su implmntación. La arquitctura d softwar, la structura d los algoritmos y los lnguajs d programación tinn un gran impacto. Es rcomndabl qu la fas d disño d la arquitctura dl softwar s tom n cunta, rvisándola y justificándola para alcanzar la ficincia d los objtivos. Usabilidad. "Conjunto d atributos qu rspaldan l sfurzo rqurido para su uso, así como n l asguraminto individual a través d un stado o un conjunto implicado d un conjunto d usuarios". Mantniminto. "Conjunto d atributos qu rspaldan l sfurzo rqurido para spcificar las modificacions". El mantniminto s sncialmnt important cuando l objtivo s adquirir l producto complto incluyndo la trazabilidad d los procsos d dsarrollo dl softwar. Portabilidad. "Un conjunto d atributos qu rspaldan la habilidad d softwar para sr transfrido d un ambint a otro". Rusabilidad. Conjunto d atributos qu rspaldan la posibilidad d qu l producto d softwar s us n otro dominio [18]. La ficincia dmostró sr l factor más important con un 57.14% junto con la confiabilidad con un 54.93%, sguidas por la funcionalidad con un 50.7%, la mantnibilidad con un 47.89%, la usabilidad con un 42.85%, la portabilidad con un 39.44% y d mnor importancia fu la rusabilidad con un 38.02%. Los primros cuatro factors los ubicaron n nivls más altos, la usabilidad, la portabilidad y la rusabilidad s ubicaron n nivl mdio. Podría infrirs qu la productividad s significativamnt alta. A psar d contar con hrramintas d cuarta gnración y d técnicas d orintación a objtos, s obsrvó qu s sacrifica la rusabilidad d sus componnts, por llo sta caractrística fu la d mnor importancia. Tracz obsrvó qu los programadors d softwar primro dbn ncontrar la utilidad d la rusabilidad[19]. La utilidad dpndrá dl marco d rfrncia d la aplicación ralizada así como d sus caractrísticas intrnas. Admás, los lídrs d proycto no obsrvan qu los sistmas d softwar frcuntmnt sigun patrons similars. Sría posibl capturar sus patrons como lmntos d softwar rusabl qu podrían sr aplicados a muchos dsarrollos difrnts. Garvin dfin la calidad prcibida por l usuario como la combinación d los atributos dl producto qu proporcionan la mayor satisfacción a un usuario spcificado[20]. Los productos pudn tnr calidad n rlación al propósito para l qu furon disñadas, podría dcirs qu s auto-vidnt. 22

23 Mdición d softwar La razón fundamntal para mdir l softwar y los procsos d softwar s para obtnr datos qu nos ayudn a manjar l control para la planificación, los costos y la calidad d los productos d softwar. Es important l sr consistnt n cuanto a las mdidas tals como l tamaño, los dfctos, los sfurzos y los timpos planados. Gráfica 19. Motivos por los cuals d db mdir l softwar Mdición d softwar 41 v a l o r s m á x i m o s opcions Funt: Elaboración propia, agosto 2001 Los motivos qu s sñalaron como d mayor intrés furon: con un 68% l stablciminto d una lína bas para stimacions futuras, con un 59%, l uso d los nuvos métodos y hrramintas d ingniría d softwar para su postrior incorporación al procso d producción, n trcr lugar con un 54.5% l indicar l grado d calidad d los productos. Ahora bin, dbido a qu la prspctiva d st studio s nfoco a prsonal dl ára d sistmas, l factor d mdición d productividad no tuvo la importancia sprada a difrncia d lo qu hubira sucdido si la ncusta hubis sido contstada por prsonal dl ára d rcursos humanos. S rconoc como un problma important la insuficincia d stímulos. Vr gráfica Calidad dl producto Productividad dl prsonal Métodos y hrramintas d ingniría d softwar Lína bas para stimacions futuras Factors d productividad Dbido a las caractrísticas propias dl análisis y la programación, s muy frcunt qu la implantación d los sistmas s rtras y s llga a sucdr qu una prsona llv trabajando varios años dntro d un sistma o bin qu s prsntn irrgularidads n las qu los programadors s ponn a ralizar actividads ajnas a la dircción d informática. Para la ncusta s solicitó su calificación sobr algunos d los problmas considrados como principals para la productividad dl softwar. Vr gráfica

24 Gráfica 20.Factors qu incidn n la productividad Factors d productividad dl softwar v a l o r s m á x i m o s factors humanos factors dl problma factors dl procso factors dl producto factors d los rcursos Funt: Elaboración propia, agosto 2001 Dntro d sta prgunta influyó los años d xprincia n l ára d softwar. En la introducción d las stratgias, los involucrados n l ára d sistmas posn dificultads para adoptar nuvos métodos. Pus han aprndido a dsarrollar softwar durant su ducación formal siguindo sus prácticas con pocos ajusts y rfinamintos. El factor d los rcursos utilizados rfiriéndos a las hrramintas CASE y a los rcursos d hardwar y softwar mostró l mayor intrés por part d los ncustados con un 59%. Para los invstigadors, ncargados dl ára y grnts con más d 10 años d xprincia, l factor humano con 54.5% fu l dtrminant n la productividad dl softwar argumntando qu si no s logra transmitir a los dmás mimbros dl quipo las spcificacions dl sistma aunado a una motivación continua, los mimbros dl proycto no ralizarán su trabajo con mayor intrés. Los factors dl problma tals como la compljidad dl proycto y los cambios n las rstriccions o rquisitos d disño solo mostraron un 45% d importancia mdia alta, sindo qu rfljaban los intrss d las prsonas d sistmas multimdia y wb. Sin mbargo, tanto los factors dl procso y dl producto dmostraron tnr una importancia mdia d un 40.5%. 24

25 5.Conclusions La calidad dl producto y d los procsos van d la mano. Cuando la calidad no s incluy n un sistma, l procso d dsarrollo s ncarga solo d ncontrar y componr los dfctos. Como rsultado, los proyctos s nfocan a rparar los dfctos conform a su grado d importancia para los usuarios. Las prsonas qu no tin una cultura d calidad, causan rtrasos n las ntrgas d los proyctos, porqu si los incluyn, l costo dl proycto s lvará, sguramnt stos individuos saln más baratos, pro los rrors comtidos, lo son mucho más. Para stablcr un ambint d mdición dl softwar, la organización dl softwar db dfinir una colcción d procsos d datos y rgistro d mdios. Los problmas d softwar s rportan típicamnt como los vhículos usados para colccionar datos acrca d los problmas y dfctos. Los datos son nsamblados como part d un problma d análisis y procsos d corrcción son prcisamnt los datos qu caractrizan o proporcionan valors a los atributos d los problmas y los dfctos a mdir. Sin mbargo, stas facilidads dl procso n los aspctos d colcción d datos d problmas d softwar y mdición d dfctos, la varidad d las actividads ncontradas y rports d problmas rlatados hac difícil para comunicar claramnt cuando s dfin o s spcifica los problmas y mdición d dfctos. En ralidad, no dbn buscars supr-programadors brillants o gnios para sr part d un quipo, tan solo, aqullos dispustos a aprndr y a compartir su conociminto. Por jmplo, si l programador ha practicado o sta dispusto a programar n parja, so dic mucho d su prfil y d su capacidad d aprndizaj. Al construir un producto d baja calidad y s pusto a pruba, ést rvla l costo sobrstimado y qu admás los procsos no pudiron compltars n l plan stimado. El trabajo d softwar pud sr stimado, planado y controlado para ajustars a los plans. El producir softwar libr d dfctos no s un trabajo sncillo, aunqu no xista vidncia alguna qu no puda ralizars. En l caso d los modlos d gstión y asguraminto d la calidad, aun s poca la difusión d los mismos n la comunidad ddicada a sta ára, y s ncsita no sólo conocr las prspctivas intrnacionals d la calidad, sino también informar d las conscuncias qu podría ocasionar al implmntar alguno d los modlos. Las organizacions qu dsarrollan softwar n México son n su mayoría pquños y micromprsarios qu no s intrsan por utilizar métodos d control d sus proyctos, su prspctiva radica n cumplir sólo con los rqurimintos n las fchas stipuladas, sin ofrcr a los clints srvicios d valor agrgado. Los lídrs d proycto dbrían probar controls fctivos suficintmnt flxibls para ajustars a los cambios o tomar vntajas d nuvas oportunidads. La ncsidad d crar implmntar un procso continuo para la administración fctiva incluy a todos los mimbros (provdors, clints, dsarrolladors). Balancando los costos, programas y las considracions técnicas, pnsando n futuro idntificando incrtidumbrs, anticipando las ntradas potncials, administrando los rcursos d los proyctos y actividads. Por lo mismo s important cntrars n la calidad dl producto como un mdio para obtnr mjors productos y a partir d ahí, influir n la calidad dl procso. Como s ha podido obsrvar, l adoptar una crtificación bajo alguno d los modlos d calidad, nos da una oportunidad d prmancr n l mrcado, pro dsd una prspctiva d un lídr d proycto, qu dsconoc las mtodologías d asguraminto y gstión d la calidad, un modlo d calidad no prmit la adopción d un método ágil d dsarrollo, dbido a qu s tarda dmasiado timpo n stablcr políticas y n rorganizar procsos, y con llo, los métodos tradicionals ncarcn vidntmnt los productos d softwar. 25

26 Rfrncias: [1] Jimno Solis, Marco A. Comportaminto dl PIB n México. [2] Prssman, Rogr. Ingniría d softwar. Edit. McGraw-Hill, 3ª dición, Madrid España [3] D Marco, Tom. Why dos softwar cost so much?. Dorst hous, Nw York, NY, USA, [4] ANUIES. Anuario stadístico d la ANUIES [5] Bakr, F.T. "Chif Programmr Tam Managmnt of Production Programming", IBM systms Journal, vol. 11 no , pp [6] Paulk, Mark C. y otros, "Capability Maturity Modl for Softwar, vrsión 1.1", Softwar Enginring Institut, CMU/SEI-93-TR-24, Fbrro d [7]SECOFI [8] Yourdon, E. Tchniqus of Program structur and dsign; Prntic Hall, Englwood Cliffs, NJ, USA, [9]Haddn, Rita. How scalabl ar CMM ky practics?, Crosstalk: th journal of Dfns Softwar Enginring, Vol II, No. 4, april [10] Johnson, Donna L., and Broadman, Judith G. Applying th CMM to small organizations and small projcts. Procdings of th 1998 softwar nginring procss group confrnc, Chicago IL, USA, 9-12, March [11]Balzr, R. And Goodman, N. Principls of good softwar spcification, Proc. On spcifications of Rliabl Softwar, IEEE, 1979, [12]Guzmán Arnas, Adolfo. Ralidads y prspctivas d la computación n México. Julio 1999 ISBN Sri Vrd, No. 22. [13] Cougar, D., and R. Zawacki "What motivats DP Profssionals?" Datamation, Sptmbr [14]Shari Lawrnc, Pflgr. Softwar nginring thory and practic. Edit. Prncit Hall, 2 nd dition. [15] Winbrg, Grald M. Quality softwar managmnt vol. 1, systms thinking. Edit. McGrawHill, México, [16] McCall J A, Richards PK y Waltrs GF; Factors in softwar quality, Vols I,II,III; US Rom Air Dvlopmnt Cntr Rports NTIS AD/A , 015, 055, [17] ISO, Softwar product valuation. Quality charactristics and guidlins for thir us, ISO, [18] Santa Olalla Salgado, Rn, Santa Olalla Salgado, Javir & Gutiérrz Tornés, Agustín F. Monografía d la rusabilidad dl softwar. Rport técnico. Sri vrd No. 43. Novimbr 2000, México. [19]Tracz, Will. Softwar Rus Maxims, ACM SIGSOFT Softwar Enginring Nots, Vol. 13, No.4, Octobr [20] Bvan, Nigl & Azuma, Motoi. Quality in us: Incorporating human factors into softwar nginring lif cycl, Uk-Japan. 26

27 Anxo A1 Estadísticas dl SIEM Emprsas, Padrón, Estadísticas por CMAP d Srvicios Srvicios d análisis d sistmas y procsaminto informático 224 Estadísticas dl INEGI. Aspctos informáticos Unidads conómicas por sctor sgún clas d actividad (datos rfrnts a 1993). Funt: Cnsos conómicos INEGI. *principio d confidncialidad stadística. Srvicios: Comprnd las class cnsals :Srvicios d alquilr d quipo lctrónico para l procsaminto informático y Srvicios d análisis d sistmas y procsaminto informático. Estado Srvicios Clas Clas Distrito Fdral Nacional

28 Anxo A2 El prsnt custionario s d caráctr académico y anónimo, tin por objtivo rcabar información sobr los factors qu incidn n la producción d softwar, por lo cual s agradc su participación y s l informa qu los datos qu ustd proporcion srán d caráctr strictamnt confidncial. Scción I. Antcdnts Instrucción: Marqu con una X la opción slccionada. 1. Cuál d las siguints opcions dscrib su posición actual (pud marcar varias) ( )Lídr d proycto o d quipo ( )Consultor ( )Programador/analista ( )Admón rds ( )Soport técnico ( )Otro 2. En cuál d las siguints actividads s dsmpña (pud marcar varias)? ( ) Rqurimintos d softwar ( ) Asguraminto d calidad d softwar ( ) Disño d softwar ( ) Administración d la configuración ( ) Código y prubas d unidads ( ) Mjoras dl procso d softwar ( ) Prubas intgración ( ) otro 3. Cuál s l giro d su mprsa? ( ) Sistmas multimdia y wb. ( ) Sistmas d información (sistmas d gstión, SMBD, SMBDOO, tc.). ( ) Sistmas distribuidos. ( ) Sistmas d timpo ral. ( ) Sistmas d ingniría(cad/cam) y cintíficos. ( ) Sistmas d control (Sistmas d adquisición d datos). ( ) Sistmas d Intligncia Artificial(sistmas xprtos, tc.). ( ) Sistmas d goprocsaminto ( ) Assoría y consultoría. ( ) Capacitación. ( ) Docncia invstigación. ( ) otro 4.Exprincia laboral: Cuánto timpo llva n la prsnt mprsa? Cuánto timpo tin n l ára d softwar? años años 5. D cuántas prsonas s compon l ára d dsarrollo d softwar n su mprsa? ( ) a)1-5 b)6-10 c)11-15 d)16-21 )21 o más 6.- El timpo promdio d duración d sus proyctos s d...? ( ) a)1 ms b)2-4 mss c)5-7 mss d)8-12 mss )más d 12 mss 28

29 Scción 2 Gstión d proyctos d Softwar Instrucción: Elija la opción d acurdo a los critrios siguints: Si- La práctica stá bin stablcida y s jcuta consistntmnt como un procdiminto stándar d opración. No- La práctica no stá bin stablcida o s ralizada inconsistntmnt. No aplica Pos l conociminto rqurido acrca dl proycto u organización pro ustd sint qu la prgunta no aplica para l proycto. Dsconoc Ud. pos incrtidumbr d cómo rspondr a la prgunta. Utilic los spacios para comntarios para cualquir aclaración acrca d sus rspustas a las prguntas. 1. Para laborar un proycto s sigu algún plan documntado qu guí l dsarrollo? ( ) Si ( ) No ( ) No aplica ( ) Dsconoc 2. Dntro d los proyctos, quins son las prsonas ncargadas d colaborar con l clint para stablcr l sistma d rqurimintos? ( )lídr d proycto ( )lídr comrcial ( )lídr d proycto y comrcial ( )otro 3. Al inicio dl proycto s rvisan las nuvas tcnologías xistnts n l mrcado para dtrminar la más adcuada a las ncsidads dl clint? ( ) Si ( ) No ( ) No aplica ( ) Dsconoc Comntarios: 4. En cuanto a la distribución d sfurzos, qu porcntaj l asigna a cada fas (l total db sr 100%)? ( )Análisis y disño ( )Codificación ( )Pruba y dpuración 5. La capacitación proporcionada s la ncsaria para dsarrollar las bass y l conociminto rqurido para dsmpñar sus actividads? ( ) Si ( ) No ( ) No aplica ( ) Dsconoc 6. Mantin informados a todos los mimbros dl quipo acrca d los cambios dl proycto(j.: aqullos qu ralizaron l trabajo y aqullos qu son los rsponsabls dl trabajo)? ( ) Si ( ) No ( ) No aplica ( ) Dsconoc 7. Los rsultados d los proyctos actuals s comparan con las stimacions inicials d los plans d softwar n términos d...? (pud marcar varias) ( )Tamaño dl proycto ( )Costos ( )Duración cronológica dl proycto ( )Rcursos humanos ( )Tcnología 8. Cuáls d las siguints actividads raliza para mantnr un control dl proycto? (pud marcar varias) ( )runions priódicas sobr l stado dl proycto ( )valuar los rsultados d todas las rvisions ralizadas n todo l procso ( )idntificar si las taras s han alcanzado n las fchas programadas ( )runions informals con los mimbros para conocr sus valoracions subjtivas 29

30 9. Para ralizar las prubas dl sistma, cuáls d los siguints pasos raliza? ( ) Establc objtivos d las prubas ( ) Disña los casos d pruba ( ) Pruba los casos ( ) Evalúa los rsultados d las prubas 10. Qué tipo d prubas aplica a un proycto? ( )prubas qu dmustrn la función s compltamnt oprativa ( )prubas qu asgurn qu las opracions intrnas s ajustan a las spcificacions ( ) otra 11. La mprsa contrata prsonal xclusivo para las prubas dl sistma? ( ) Si ( ) No ( ) No aplica ( ) Dsconoc 12. Cuál d los siguints modlos d gstión y asguraminto aplica? ( )ISO 9001 ISO ( )ISO SPICE ( )ISO Tick-IT ( )Capability Maturity Modl (CMM) ( )otro ( )ninguno Instrucción. En las siguints trs custions slccion d la lista d valors anotando l númro qu cra convnint para cada opción. (1-Bajo 2- Mdio 3-Alto, 4- Muy Alto) 13.D acurdo a su nivl d importancia los siguints factors d calidad qu dscribn a un softwar son: ( ) Confiabilidad (Qu no fall, qu no tnga rrors) ( ) Eficincia (El grado n qu s aprovchan los rcursos a disposición dl producto d softwar) ( ) Funcionalidad (S rfir al grado n qu l softwar satisfac los rqurimintos, hac lo sprado ) ( ) Mantnibilidad ( Pudo actualizarlo?) ( ) Portabilidad ( Podré usarlo n otro ambint computacional?) ( ) Rusabilidad ( Pud una part o todo utilizars n otro softwar?) ( ) Usabilidad (S rfir a la facilidad d uso.) 14.D las siguints razons, anot l númro qu a su critrio l corrsponda a cada opción qu sñal los motivos por los cuals s db mdir l softwar. ( ) Indicar la calidad dl producto ( ) Evaluar la productividad d la gnt qu dsarrolla l producto ( ) Evaluar l uso d nuvos métodos y hrramintas d ingniría d softwar ( ) Establcr una lína bas para futuras stimacions 15.D acurdo a su xprincia anot l númro qu corrsponda a los factors qu incidn n la productividad dl softwar ( ) Factors humanos. La cantidad y la xprincia dl prsonal d dsarrollo. ( ) Factors dl problma. La compljidad dl problma a rsolvr y l númro d cambios n las rstriccions o los rquisitos dl disño. ( ) Factors dl procso. Técnicas d análisis y disño utilizadas. ( ) Factors dl producto. Fiabilidad y rndiminto dl sistma basado n computadora. ( ) Factors d los rcursos. Disponibilidad d hrramintas CASE, d rcursos d hardwar y d softwar. 30