unidad ii ing-software

8/19/2019 Unidad II Ing-Software

1/26


2/26


3/26

0 continuación descri"iremos mas en fondo cada uno de estos componentes.

PERSONAL

L&s $)%ti(i$)!tes

El proceso del Software (y todos los proyectos de Software) lo componenparticipantes que pueden clasificarse en una de cinco categor%as

1. Gestiones Superiores, que definen los aspectos de negocios que amenudo tienen una significativa influencia en el proyecto.

2. Gestores (técnicos)del proyecto que deben planificar, motivar, organizar, y controlar a los profesionales que realizan el traba o de Soft!are.

". #rofesionales ' que proporcionan las capacidades técnicas necesarias parala ingenier%a de un producto o aplicación.

$. %lientes, que especifiquen los requisitos para la ingenier%a del software.&. 'suarios finales, que interaccionan con el Software una vez que se $a

entregado para la producción.

3odos los proyectos de Software est! compuestos por los participantes apuntadosanteriormente. &ara ser eficaz' el equipo del proyecto de"e organizarse de maneraque maximice las $a"ilidades y capacidades de cada persona. 4se es el tra"a#odel #efe de equipo.

L&s e es "e e3#i$&

,a gestión de un proyecto es una actividad intensamente $umana' y por estarazón' los componentes profesionales del Software a menudo no son "uenos #efesde equipo.

*ué es lo que "uscamos cuando seleccionamos a alguien para dirigir unproyecto de Software+

M&ti4)(i !.- ,as $a"ilidades para motivar (con un 5tira y arro#a6) al personaltécnico para que produzca conforme a sus me#ores capacidades.O% )!i/)(i !.- ,as $a"ilidades para moldear procesos existentes ( o inventar unos nuevos) que permita al concepto inicial transformarse en un proyecto final.I"e)s & i!!&4)(i !.- ,a $a"ilidad para motivar al personal para crear y sentirsecreativos incluso cuando de"an de tra"a#ar dentro de los l%mites.

El éxito de los gestores de proyectos se "asa en aplicar un estilo de gestión en laresolución de pro"lemas. Es decir' un gestor de proyectos de Software de"er%a deconcentrarse en entender el pro"lema que $ay que resolver' gestionando el flu#ode ideas y' al mismo tiempo' $aciendo sa"er a todos los miem"ros del equipo

3


4/26

(mediante pala"ras y muc$o m!s importante' con $ec$os) que la calidad esimportante y que no de"e verse comprometida.

E+ e3#i$& "e S& t5)%e

Existen casi tantas estructuras de organización de personal para el desarrollo deSoftware como organizaciones que se dedican a ello. &ara "ien o para mal' elorganigrama no puede cam"iarse f!cilmente. ,as consecuencias pr!cticas ypol%ticas de un cam"io de organización no est!n dentro del alcance de lasresponsa"ilidades del gestor de un proyecto de Software. Sin em"argo' laorganización del personal directamente involucrado en un nuevo proyecto deSoftware est! dentro del !m"ito del gestor del proyecto.

,a 7me#or/ estructura de equipo depende del estilo de gestión de una organización'el n-mero de personas que compondr! el equipo' sus niveles de preparación y ladificultad general del pro"lema. 8antei 980N:;< sugiere tres organigramas deequipo genéricos

Des(e!t%)+i/)"& "e &(%6ti(& 7DD . Este equipo de ingenier%a de Software notiene un #efe permanente. 8!s "ien' 6 se nom"ran coordinadores de tareas a cortoplazo y se sustituyen por otros para diferentes tareas6 . ,as decisiones so"repro"lemas y los enfoques se $acen por consenso del grupo. ,a comunicaciónentre los miem"ros del equipo es $orizontal.

Des(e!t%)+i/)"& (&!t%&+)"& 7DC .Este equipo de ingenier%a de Software tieneun #efe definido que coordina tareas espec%ficas y #efes secundarios que tienenresponsa"ilidades so"re su"tareas. ,a resolución de pro"lemas sigue siendo unaactividad del grupo' pero la implementación de soluciones se reparte entresu"grupos por el #efe del equipo. ,a comunicación entre su"grupos e individuos es$orizontal. 3am"ién $ay comunicación vertical a lo largo de la #erarqu%a de control.

Ce!t%)+i/)"& C&!t%&+)"& 7CC .El #efe del equipo se encarga de la resolución depro"lemas a alto nivel y la coordinación interna del equipo. ,a comunicación entreel #efe y los miem"ros del equipo es vertical.

8ante% descri"e siete factores de un proyecto que de"er%an considerarse cuandose planifica el organigrama de equipos de ingenier%a del Software

• ,a dificultad del pro"lema que $ay que resolver.• El tama2o del programa resultante en l%neas de código o puntos de función• El tiempo en que el equipo estar! #unto (tiempo de vida del equipo)• El grado en que el pro"lema puede ser modularizado.• ,a calidad requerida y fia"ilidad del sistema que se va a construir• ,a rigidez de la fec$a de entrega• El grado de comunicación requerido para el proyecto.

4


5/26

EL PRO8LEMA

El gestor de un proyecto de Software se enfrenta a un dilema al inicio de un

proyecto de ingenier%a de Software. Se requieren estimaciones cuantitativas y unplan organizado' pero no se dispone de información sólida. 1n an!lisis detalladode los requisitos del Software proporcionara la información necesaria para lasestimaciones' pero el an!lisis a menudo lleva semanas o meses. 0-n peor' losrequisitos pueden ser fluidos' cam"iando regularmente a medida que progresa elproyecto.

9 0it& "e S& t5)%e

,a primera actividad de gestión de un proyecto de= Software es determinar el!m"ito del Software. El !m"ito se define respondiendo a las siguientescuestiones

C&!te t&. >ómo enca#a el software a construir en un sistema' producto ocontexto de negocios mayor y qué limitaciones se imponen como resultado delcontexto+O0 eti4&s "e i! &% )(i !. *ué o"#etos de datos visi"les al cliente (>apitulo ;;)se o"tienen del software+ *ué o"#etos de datos son requeridos de entrada+F#!(i ! ' %e!"i ie!t&. *ue función realiza el software para y transformar lainformación de entrada en una salida+ ?ay caracter%sticas de rendimientoespeciales que a"ordar+

El !m"ito de un proyecto de Software de"e ser univoca y entendi"le a niveles degestión y técnico. ,os enunciados del !m"ito del Software de"en estar delimitados.

Des(& $&si(i ! "e+ $%&0+e )

,a descomposición del pro"lema' denominado a veces particionado, es unaactividad que se asienta en el corazón del an!lisis de requisitos del Software.

urante la actividad de exposición del !m"ito no se intenta descomponer elpro"lema totalmente. 8!s "ien' la descomposición se aplica en dos !reasprincipales (;) la funcionalidad que de"e entregarse y (@) el proceso que seemplear! para entregarlo.

E+ PROCESO

,as fases genéricas que caracterizan el proceso de Software 5 definición'desarrollo' y mantenimiento6 son aplica"les a todo Software. El pro"lema es

5


6/26

seleccionar el modelo de proceso apropiado para la ingenier%a del Software quede"e aplicar el equipo del proyecto.

M)"#%)(i ! "e+ $%&0+e ) ' e+ $%&(es&

,a planificación de un proyecto empieza con la maduración del pro"lema y delproceso' "as!ndose en unos criterios de adaptación. 3odas las funciones que sede"en tratar de tratar dentro de un proceso de ingenier%a por el equipo deSoftware de"en pasar por el con#unto de actividades estructurales que se $andefinido para una organización de Software.

Des(& $&si(i ! "e+ $%&(es&

1n equipo de Software de"er%a tener un grado significativo de flexi"ilidad en laelección del paradigma de ingenier%a del Software que resulte me#or para elproyecto y de las tareas de ingenier%a del Software que conforman el modelo deproceso una vez elegido.

,a descomposición del proceso comienza cuando el gestor del proyecto pregunta>ómo vamos a realizar esta actividad E>&+. &or e#emplo' un peque2o proyecto'

relativamente simple' requiere las siguientes tareas para la actividad decomunicación con el cliente

;. esarrollar una lista de aspectos que se $an de clarificar @. Aeunirse con el cliente para resolver los aspectos que se $an de

clarificar.B. esarrollar con#untamente una exposición del !m"ito del proyecto=. Aevisar el alcance del proyecto cuando se requiera

EL PROYECTO

,os veteranos profesionales de la industria a menudo se refieren a la regla * cuando estudian proyectos de Software particularmente dif%ciles +l primer noventa por ciento de un sistema absorbe el noventa por ciento del esfuerzo y tiempo invertido. +l ltimo diez por ciento se lleva el otro noventa por ciento del esfuerzo y del tiempo asignado 9C0?D=


7/26

ista desde el punto de vista de un diccionario' una estimación es un con#untoaproximado de valores para algo que $a de ser $ec$o. En el mundo de desarrollode Software' ,arry &utnam $a apuntado que la gestión de desarrollo de Softwareconsidera la estimación como una actividad que permite o"tener' principalmente'

respuestas aproximadas a las siguientes preguntas>u!nto costar!+>u!nto tiempo llevar! $acerlo+

,a respuesta a estas dos preguntas constituye el n-cleo del tema que aqu% secontempla' sin em"argo' y como se puede prever ésta no es tan sencilla. *ué$ace que la estimación no sea tan dif%cil de realizar.

,as razones para esta comple#idad son las siguientes

;. N& e iste #! &"e+& "e esti )(i ! #!i4e%s)+ o una formula que puedaser usada para todas las organizaciones. El $ec$o en que se puedandefinir unos principios generales' pero cada interpretación es particular ydiferente al resto. >ada organización tiene sus propios recursos'procedimientos e $istoria y es necesario a#ustar los procesos deestimación a esos par!metros -nicos. 0dem!s' a medida que estospar!metros cam"ien' de"en cam"iar los procesos de estimación.

@. ?ay #(?)s $e%s&!)s i $+i()")s e! +&s $%&'e(t&s 3#e $%e(is)! "eesti )(i&!es. ,a alta dirección de la empresa necesita las estimacionespara tomar decisiones de negocio so"re la via"ilidad del proyecto y sucontinuidad a lo largo del desarrollo. ,a dirección del proyecto necesita lasestimaciones para ser sugerencias a la alta dirección' para o"tener losresultados necesarios para el desarrollo del proyecto y' para $acer unaplanificación detallada y controlar el proyecto.

B. L) #ti+i")" "e #!) esti )(i ! t) 0i=! "e$e!"e%6 "e +) et)$) "e"es)%%&++& e! )+) 3#e !&s e!(&!t%e &s. 0l comienzo de un proyecto'normalmente sólo se necesita estimaciones de costo y duraciónaproximadas. 0 medida que el proyecto madura las estimaciones que senecesitan ser!n m!s exactas. >on lo que una estimación -til al comienzodel proyecto puede no serlo m!s tarde.

=. L) esti )(i ! ) e!#"& se ?)(e s#$e% i(i)+ e!te, sin apreciar elesfuerzo requerido para $acer un tra"a#o. 0dem!s tam"ién se suele dar elcaso de que la estimación sea necesaria antes de o"tener lasespecificaciones de requisitos del sistema. &or esta razón' una situaciónt%pica en que se presiona a los estimadores para que se apresuren enescri"ir una estimación anticipada del sistema que no comprenden a-n.

F. L)s esti )(i&!es (+)%)s, (& $+et)s ' $%e(is)s s&! "i *(i+es "e&% #+)%. Especialmente al inicio del proyecto. ,os cam"ios' adaptaciones

y ampliaciones son m!s la regla que la excepción como consecuencia deello' de"en adaptarse tam"ién las planificaciones y los o"#etivos.

7


8/26

G. L)s ()%)(te%*sti()s "e S& t5)%e ' "e #! "es)%%&++& ?)(e! "i *(i+ +)esti )(i !, por e#emplo' el nivel de a"stracción' la comple#idad' el gradode medición del producto y del proceso' los aspectos innovadores....

H. ,a rapidez con la que cam"ia la tecnolog%a de la información y lasmetodolog%as de desarrollo de Software son pro"lema para +)

est)0i+i/)(i ! "e+ $%&(es& "e esti )(i !. &or e#emplo' son dif%ciles depredecir la influencia de nuevos "ancos de prue"as' lengua#es de cuarta yquinta generación' estrategias de prototipado' y de técnicas y $erramientasnovedosas en general.

:. 1n estimador no puede tener muc$a e $e%ie!(i) "e esti )% desarrollos'especialmente de proyectos largos. >u!ntos proyectos largos puedealguien dirigir en' por e#emplo' ;I a2os+

D. Existe #!) te!"e!(i) aparentemente de los desarrolladores $acia las#0esti )(i !. 1n estimador suele elegir una porción de Softwarede"er%a tomar para luego extrapolarlo al resto del sistema' normalmente seignoran los aspectos no lineales del desarrollo de Software' por e#emplo' lacoordinación y la gestión.

;I.El estimador estima el tiempo que le llevar%a e#ecutar personalmente unatarea' ignorando el $ec$o de que' a menudo' una parte del tra"a#o la%e)+i/) $e%s&!)+ e!&s e $e%i e!t)"&, con un %ndice de productividadmenor.

;;. Existen )+)s i!te%$%et)(i&!es en las relaciones lineales entre lacapacidad requerida por unidad de tiempo y el tiempo disponi"le. Estosignifica que el Software desarrollado por @F personas en dos a2os podr!ser llevado aca"o por FI personas en un a2o. Esta interpretación eserrónea.

;@.El estimador tiende a %e"#(i% en alg-n grado +)s esti )(i&!es para$acer m!s acepta"le la oferta.

;B.Jnfluyen un gran n-mero de factores en el esfuerzo y duración de undesarrollo de Software. Estos factores se llaman 7 "%i4e%s "e (&st&@ odisparadores de costo. E#emplos de estos disparadores son el tama2o ycomple#idad del Software' el compromiso y participación del usuario' laexperiencia del equipo de desarrollo. En general estos disparadores decosto son dif%ciles de determinar.

0l desarrollar sistemas se estiman con "ase a las siguientes consideraciones.

• El producto Software que se tiene que desarrollar.


9/26


10/26

>uando se $a"lo de la definición de estimación' se vieron dos preguntas a las queeste proceso de"%a dar respuesta. Estas preguntas eran

>u!nto costar!+

>u!nto tiempo llevar! $acerlo+Esta información constituye información "!sica de todo proceso de estimación.,os distintos métodos existentes para realizar este proceso proporcionaninformación adicional para dar respuestas' en función del método' a algunas de lassiguientes preguntas

>u!nta gente se necesita y que perfil de"e de tener+>u!les son los riesgos+>ómo afectan las restricciones impuestas a las estimaciones+>u!nto tiempo se necesita para realizar cada fase del ciclo de vida+>ómo impacta este proceso en el resto de los proyectos de la empresa+>u!l ser! el esfuerzo para mantener este proyecto+>u!l ser! el tama2o del sistema+ (l%neas de código)>u!ntos defectos tendr! el producto+>u!nta documentación ser! generada+>u!l ser! el esfuerzo para confeccionar dic$a documentación+

2. M=t%i()s "e S& t5)%e

,a medición es fundamental para cualquier disciplina de ingenier%a' y la ingenier%adel Software no es una excepción.

-as métricas del Soft!are se refieren a un amplio elenco de medidas para elSoftware de computadora. ,a medición se puede aplicar al proceso de Softwarecon el intento de me#orarlo so"re una "ase continua.

&odemos definir las 8étricas de Software o 8edidas de Software como

,a aplicación continua de técnicas "asadas en las medidas de los procesos dedesarrollo de Software y sus productos' para producir una información de gestiónsignificativa y a tiempo. Esta información se utilizar! para me#orar esos procesos ylos productos que se o"tienen de ellos.

,as 8étricas de Software implican medir medir involucra n-meros el uso den-meros para $acer cosas me#or. ,as 8étricas de Software pretenden me#orar losprocesos de desarrollo de Software y me#orar' por tanto' todos los aspectos de lagestión de aquellos procesos.

Estas medidas son aplica"les a todo el ciclo de vida del desarrollo' desde lainiciación' cuando de"emos estimar los costos' al seguimiento y control de la

10


11/26

fia"ilidad de los productos finales' y a la forma en que los productos cam"ian através del tiempo de"ido a la aplicación de me#oras.

,as medidas del Software y los modelos de medida son entonces -tiles paraestimar y predecir costos y para medir la productividad y la calidad del producto.

1n ingeniero del Software recopila medidas y desarrolla métricas para o"tener indicadores.

9%e)s "e A$+i()(i !

0lgunas de las !reas donde se aplican las métricas de Software son

E+ (&!t%&+ "e $%&'e(t&s "e "es)%%&++& "e S& t5)%e a través de medidas en un!rea que esta generando un gran interés. Este es un tema que $a alcanzado uninterés relevante con el incremento de contratos a precio fi#o para desarrollar unproducto Software y la utilización de cl!usulas de penalización en los mismos encaso de retrasos' so"recostos' etc.

L) $%e"i((i ! "e +&s !i4e+es "e ()+i")" del Software' a menudo en términos defia"ilidad' es otra !rea en que las 8étricas de Software tiene un importante papelque #ugar.

El uso de las 8étricas de Software es proporcionar #!) 4e%i i()(i ! (#)!tit)ti4)"e+ "ise & "e s& t5)%ees otra !rea "ien definida. Estas 8étricas no se van aestudiar en esta 1nidad si no en la 1nidad de ise2o.

Aecientemente se $a estudiado e+ e e(t& "e +&s )(t&%es "e+ e!t&%!& en laeficacia de los procesos de desarrollo. Esta opción no esta a"ierta para todas lasorganizaciones' pero existe una gran preocupación so"re como incrementar laproductividad de los procesos de desarrollo introduciendo cam"ios en el entornoen el cual aquellos tienen lugar. ,as medidas pueden ser utilizadas para identificar donde de"er%an concentrarse los cam"ios.

,a utilización de las 8étricas para (& $%)% #!)s &% )!i/)(i&!es (&! &t%)s esun !rea de aplicación muy importante. >S>6 Jndex en Europa y el SoftwareEngineering Jnstitute en E.E.1.1. ofrecen este tipo de servicios a la industria ymuc$as organizaciones los utilizan. 1n resultado de esta aplicación es que sepuede identificar que se esta $aciendo mal y quién lo esta $aciendo "ien yaprender de esas empresas.

Linalmente' el uso m!s com-n de las medidas de Software es la $%&4isi ! "ei! &% )(i ! "e esti !, que incluye datos acerca de la productividad' calidad yeficacia de los procesos.El valor de esta información est! en analizar los datos de las tendencias' d%a ad%a. Est! me#orando o empeorando la calidad de un equipo de desarrollo+. Si esas%' por qué ocurre+ qué puede $acer la dirección para me#orar la situación+

11


12/26


13/26

amos a analizar' de todos los tipos de medidas utilizadas en la medición delproducto Software' -nicamente aquellas que nos interesen para realizar el procesode estimación del Software' que ser!n las métricas del tama2o' y en cierto gradolas de calidad.

M=t%i()s "e+ t) ) &

,as 8étricas del Software orientadas al tama2o provienen de la normalización delas medidas de calidad yKo productividad considerando 6el tama2o 6 del Softwareque se $aya producido.

Existen un cierto numero de 8étricas que intentan cuantificar el tama2o delSoftware. ,a 8étrica m!s utilizada' l%neas de código' tiene el inconveniente o"viode que sus valores no pueden ser medidos $asta que el proceso de codificación$a finalizado. ,os puntos de función' y los Oang de e 8arco tienen las venta#asde ser medi"les durante los primeros pasos de desarrollo.

El estado actual en el estudio de las medidas del tama2o es

• Existe un cierto consenso en cuanto a las e"i")s "e +&! it#", pero noen cuanto a las medidas de las especificaciones o dise2o.

• Existen algunos tra"a#os de e"i(i ! "e +)s #!(i&!)+i")"es de lasespecificaciones ( que se aplican igualmente al dise2o y a los programas)

• Existen muy pocos tra"a#os en cuanto a la e"i") "e +) (& $+e i")" delpro"lema a resolver . Nótese que este concepto es distinto que el decomple#idad computacional' por tanto el tra"a#o $ec$o en esa !rea no sirve.

0 continuación' vamos a analizar las medidas mas utilizadas en ladeterminación del tama2o del Software.

0) L*!e)s "e C "i &: ,a medida mas utilizada de la longitud delcódigo fuente de un programa es el Numero de ,%neas de >ódigo( ,ines of >ode en Jnglés' a"reviado ,M>).

Sin em"argo esta métrica puede calcularse de muc$as maneras. Estasdiferencias afectan ala tratamiento de la l%neas en "lanco y las l%neas decomentarios' las sentencias no e#ecuta"les' las instrucciones m-ltiples

por l%nea y las m-ltiples l%neas por instrucción. 0dem!s' de"er%an contarse las l%neas reusa"les del código

>uando se intenta utilizar esta medida (l%neas de código) en términosde productividad surgen dos pro"lemas.

0) No se tiene en cuenta el concepto de reutilización.

13


14/26

O) No se tiene en cuenta el concepto de costos fi#os ni tareas que sedesarrolla que no produce instrucciones

0 Es$e(i i()(i ! "e+ Dise & ,a definición de medidas an!logas a la longitudpara las especificaciones y los documentos de dise2o no es f!cil. 0l comienzo del

ciclo de vida' tales documentos consisten en una infinidad de texto' grafos'diagramas matem!ticos' y s%m"olos. ,a naturaleza de aquellos depender! enparticular del estilo el método o la notación utilizada. 1nas especificaciones o undise2o' est!n compuestos por textos o diagramas' los cuales parecen inmedi"lescon relación a la longitud.

1na medida que se $a utilizado para permitir las comparaciones es la del Numerode &aginas. Sin em"argo' la unidad p!gina no puede ser formalmente definida sise desea incluir textos y diagramas.

( P%e"i((i ! "e +) +&! it#": Existen una serie de modelos que veremosmas adelante para la predicción del costo que dependen de la $a"ilidadpara predecir la longitud ( N,M>) con exactitud con la fase de definición deespecificaciones del sistema a implantar.

1n modo intuitivo de predecir la longitud es o"teniendo una relación entre lalongitud de diferentes productos o"tenidos durante el ciclo de vida. En particular'una predicción de longitud' se puede o"tener considerando la relación ratio deexpansión entre la longitud de las especificaciones o del dise2o y la longitud del>ódigo en proyectos similares en los que se mantienen datos.

?a $a"ido algunos intentos para esta"lecer relaciones emp%ricas entre la longituddel código de programas y la longitud de la documentación.

" F#!(i&!)+i")": El concepto de funcionalidad de un producto se origina apartir de una noción intuitiva de cantidad de funciones que proporciona.

?a $a"ido dos intentos serios para medir la funcionalidad de un producto deSoftware. 1no de ellos se de"e a 0l"rec$t y corresponde a los &untos de Lunción(FPA, del inglés Lunction &oint 0n!lisis) y otro de"ido a de e 8arco' los Oang'que no $a tenido una gran difusión.

El o"#etivo m!s importante es identificar una medida del tama2o de Software quepueda ser la varia"le predominante en los sistemas de predicción de costos yesfuerzo' as% como en la evaluación de la productividad. Este es un o"#etivoencomia"le' ya que una medida de la funcionalidad ser%a claramente preferi"le ala medida del tama2o exclusivamente de la longitud. En am"os casos' losproductos cuya funcionalidad est! siendo medida con documentos deespecificación' pero que podr%an aplicarse posteriormente a otros productos delciclo de vida. ,a funcionalidad' a pesar de los pro"lemas existentes' es un atri"utomuy importante del producto y es la me#or aproximación existente $asta la fec$a.

14


15/26

M=t%i()s "e C)+i")"

El o"#eto primordial de la ingenier%a del Software es producir un sistema'aplicación o producto de alta calidad. &ara lograr este o"#etivo' los ingenieros delsoftware de"en aplicar métodos efectivos con $erramientas modernas dentro del

contexto de un proceso maduro de desarrollo del Software.Se puede generar una larga lista de caracter%sticas de la calidad de Softwarecorrección' eficacia' porta"ilidad' manteni"ilidad' fia"ilidad' etc.

esafortunadamente' las caracter%sticas a veces se solapan y entran en conflictounas con otras. &or e#emplo' incrementar la porta"ilidad' que es muy desea"le'puede dar lugar a una eficacia menor.

0unque se $an realizado una gran cantidad de tra"a#os en est! !rea' presenta unagran variedad en los caminos seguidos frente a otras !reas de investigación de lasmétricas' tales como el tama2o del Software o la comple#idad' cuyo estudio $asido m!s uniforme.

?an tenido considera"le atención tres !reas

• C&%%e((i ! "e +&s $%& %) )s,medida como el n-mero de efectos. 1nprograma de"e operar correctamente o proporcionar! poco valor a sususuarios. ,a corrección es el grado en el que el Software lleva a ca"o sufunción requerida.

• Fi)0i+i")" "e+ S& t5)%e, calculada partir del dato anterior. En est! épocade intrusos inform!ticos y de virus' la integridad del software $a llegado $atener muc$a importancia. Este atri"uto mide la $a"ilidad de un sistema pararesistir ataques ( tanto accidentales como intencionales ) contra su

seguridad. El ataque se puede realizar en cualquiera de los trescomponentes del Software' programas' datos' y documentos.• M)!te!i0i+i")" "e+ S& t5)%e, que se mide a partir de otro con#unto de

métricas' incluidas las de comple#idad ,a facilidad de mantenimiento es lafacilidad con la que se puede corregir un programa si se encuentra un error'se puede adaptar si su entorno cam"ia' o me#orar si su cliente desea uncam"io de requisitos.

,a calidad del software es una caracter%stica que' teóricamente al menos' puedeser medida en cada fase del ciclo de desarrollo del Software.

M=t%i()s "e P%&(es&s

Estas métricas eval-an el proceso en s% de fa"ricación del productocorrespondiente. E#emplos de este tipo de métricas son el tiempo de desarrollo delproducto' el esfuerzo que conlleva dic$o desarrollo' el n-mero y tipo de recursosempleados (personas' m!quinas' etc) el costo del proceso. ,a o"tención de este

15


16/26

tipo de métricas esta asociada generalmente a alguna técnica de estimación. Enel siguiente tema descri"iremos las técnicas "!sicas de estimación' y los métodosque se pueden aplicar.

I!te %)(i ! "e +)s M=t%i()s "e!t%& "e+ P%&(es& "e S& t5)%e

,a mayor%a de los desarrolladores de Software todav%a no miden' y por desgracia'la mayor%a no desean ni comenzar.

&or qué es tan importante medir el proceso de ingenier%a de Software y elproducto (Software) que produce+. ,a respuesta es relativamente o"via. Si no semide' no $ay una forma real de determinar s% se est! me#orando. P si no se est!me#orando' se est! perdido.8ediante el uso de la medición para esta"lecer una l%nea "ase del proyecto' cadauno de estos asuntos se $ace m!s f!cil de mane#ar. Pa $emos apuntado que lal%nea "ase sirve como "ase de la estimación. 0dem!s' la recopilación de métricasde calidad permite a una organización 5sintonizar6 su proceso de ingenier%a delSoftware para eliminar las causas 5 poco vitales6 de los defectos que tienen elmayor impacto en el desarrollo del Software.

2. T=(!i()s "e Esti )(i !

1na vez definidas las métricas de Software podemos entender las diferentestécnicas existentes para la estimación' existen principalmente cuatro técnicas deestimación.

;. ,a opinión de los expertos. Esta técnica se "asa en la experienciaprofesional de los participantes en el proyecto de estimación.

@. ,a analog%a. Es una aproximación m!s formal que la experiencia de losexpertos y se "asa en la comparación directa de uno o m!s proyectospasados. ,a estimación inicial se a#usta dependiendo de las diferenciasentre el proyecto pasado y el nuevo.

B. ,a descomposición. >onsiste en la descomposición de un producto encomponentes m!s peque2os' o descomponer un proyecto en tareas denivel inferior. ,a estimación se $ace partir del esfuerzo requerido paraproducir los componentes m!s peque2os o para realizar las tareas de nivelinferior. ,a estimación glo"al de un proyecto resultar! de sumar lasestimaciones de los componentes.

=. ,as ecuaciones de estimación. Son fórmulas matem!ticas que esta"lecenla relación de algunas medidas de entrada (que normalmente es la medidadel tama2o del producto) y determinan el esfuerzo que se requerir!.

Re3#isit&s "e #! 8#e! M=t&"& "e Esti )(i !

1n método de estimación tendr! éxito s%

16


17/26

• ,a estimación inicial est! dentro de un BI Q de desviación del costo finalreal.

• El método permite el refinamiento de la estimación durante el ciclo de vidadel producto Software.

• El método es f!cil de usar por el estimador. Esto permite una r!pida re6

estimación cuando sea necesario por e#emplo para evaluar distintasalternativas.• ,as reglas de la estimación son entendidas por todas las personas a las

que afectan los resultados de la misma. ,os directivos se sienten m!sseguros cuando el proceso de estimación es f!cilmente comprensi"le.

• El método es soportado por $erramientas y est! documentado. ,adisponi"ilidad de $erramientas aumenta la eficacia de cualquier método.Esto es de"ido' principalmente' a que los resultados pueden ser o"tenidosm!s r!pidamente y de una forma est!ndar.

M=t&"&s "e Esti )(i !

1n método de estimación eficaz permitir! ignorar aspectos sin interés yconcentrase en los aspectos esenciales. 1n "uen modelo de"er%a poseer capacidades predicitivas' me#or que ser meramente descriptivo o explicativo.

,a validez de las métricas de Software y de los modelos de estimación de"e ser esta"lecida mostrando la coincidencia entre los datos emp%ricos y experimentales.Esto requiere una cuidadosa atención en la toma de medidas y en el an!lisis delos datos.

,os modelos de estimación existentes se pueden clasificar como 8odelos deEstad%sticos' 8odelos "asados en 3eor%as y 8odelos >ompuestos. 0 continuacióndescri"iremos cada uno de ellos.

M&"e+&s Est)"*sti(&s

>.E Ralson y &.>. Lelix' de JO8 utilizaron datos de GI proyectos terminadoscompletamente para desarrollar un modelo simple de calculo del esfuerzo dedesarrollo de Software.

El principal determinante del esfuerzo de desarrollo fue la métrica ,M>.

Se asumió una relación de la forma E a,"' donde , es el n-mero de l%neas decódigo' en miles y E es el esfuerzo total requerido en mesesK personas.

8ediante una an!lisis de regresión se encontraron los valores apropiados para a y". ,a ecuación resultante fue

17

E = 5,2 L 0,91


18/26

,a productividad nominal de programación en ,M> por persona K mes' puede ser calculada como ,KE. Ralston y Lelix tam"ién intentaron desarrollar un %ndice deproductividad' J' que podr%a $acer incrementar o disminuir la productividaddependiendo de la naturaleza del proyecto.

M&"e+&s 0)s)"&s e! Te&%*)s: M&"e+& "e P#t!) .

El modelo m!s importante es el de &utnam. Este modelo asume una distri"uciónespec%fica del esfuerzo a lo largo de la vida de un proyecto de desarrollo deSoftware. El modelo se $a o"tenido partir de distri"uciones de mano de o"ra degrandes proyectos. Sin em"argo' se puede extrapolar a proyectos m!s peque2os.

&utnam desarrolló la siguiente relación entre el tama2o del producto Software y eltiempo de desarrollo.

onde, el n-mero de instrucciones fuente producidasE el esfuerzo durante todo el ciclo de vida en a2os K personas.> una constante dependiente de la tecnolog%a3 el tiempo de desarrollo en a2os.

,os varios tipos > pueden ser > @.III para un entorno po"re de desarrollo desoftware ( sin metodolog%a' con una documentación y unas revisiones po"res) > :.III para un "uen entorno de desarrollo de Software ( con una "uena tecnolog%aadecuada' documentación y revisiones) > ;.;II para un entorno excelente( con $erramientas y técnicas autom!ticas). Se puede o"tener la constante >correspondiente al entorno propio a partir de datos $istóricos recopilados so"re losanteriores esfuerzos de desarrollo.

M=t&"&s C& $#est&s

Son modelos que utilizan una com"inación de intuición an!lisis estad%stico y #uiciode expertos. 0 continuación se descri"en los m!s importantes.

) M&"e+&s COCOMO "e 8&e? . Es pro"a"lemente el m!s conocido ysólidamente documentado de todos los modelos de estimación de costos.8as adelante se estudiara en profundidad este modelo' con aplicacionespr!cticas.

0 SOFTCOST. T)#s5&%t?e: 3rauswort$e' de Tet &ropulsión ,a"oratory'intentó desarrollar una estimación de costo del Software utilizandoelementos de los modelos con m!s éxito disponi"les. Este modelo requiere

18

E = L 3 / (C 3T4)


19/26

G: par!metros de entrada' cuyos valores se deducen a partir de lasrespuestas del usuario a =H preguntas acerca del proyecto.

( SPapers Tones $a desarrollado un modelo deestimación de costos llamado Software &roductivity' *uality and Aelia"ility(S&*A).

El enfoque del pro"lema es similar al de Ooe$m en su modelo >M>M8M. Est!"asado en @I factores que influyen razona"lemente en el costo y productividad deldesarrollo del software y que est!n "ien definidos y otros @F factores que no est!ntan "ien definidos.

S&*A es un producto comercial' pero no esta tan "ien documentados como otrosmodelos. Aequiere responder a m!s de ;II preguntas relacionadas con elproyecto para formular los par!metros de entrada necesarios en el calculo de loscostos y los planes. Tones se2ala que con este modelo es posi"le proporcionar estimaciones de costo que estar!n el DIQ de las veces dentro del valor real conuna desviación del ;FQ.

" COPMO- T?e0)#t: 3$e"aut propone un modelo de desarrollo de Softwareque intenta conta"ilizar el esfuerzo requerido cuando los equipos deprogramación est!n involucrados en grandes proyectos. ,a ecuacióngeneral de calculo de esfuerzo es

onde 0'"'c'd' son constantes para ser determinadas a partir de datos emp%ricosmediante an!lisis de regresiónS es el tama2o del programa en miles de ,M>& es el medio de personal durante el ciclo de vida del proyecto

esafortunadamente' este modelo no requiere uno si no dos par!metros cuyosvalores no son conocidos $asta la terminación del proyecto. 0dem!s' lasconstantes " y c dependientes de la comple#idad del Software no sonf!cilmente determina"les.

Este modelo presenta una fórmula interesante' pero necesita un mayor desarrollo y a#uste par que sea de interés general.

e%%) ie!t)s A#t& 6ti()s "e Esti )(i !

,as técnicas de descomposición y los modelos emp%ricos de estimacióndescritos en las secciones anteriores se pueden implementar con Software.,as $erramientas autom!ticas de estimación permiten al planificador estimar

19

E a U "S U c&"


20/26

costos y esfuerzos' as% como llevar a ca"o an!lisis del tipo Vqué pasa s%W conimportantes varia"les del proyecto' tales como la fec$a de entrega o laselección de personal. 0unque existen muc$as $erramientas autom!ticas deestimación' todas ex$i"en las mismas caracter%sticas generales y todasrequieren una o m!s clases de datos como los mostrados a continuación

;. 1na estimación cuantitativa del tama2o del proyecto ( por e#emplo' en, >) o de la funcionalidad ( datos so"re los puntos de función)

@. >aracter%sticas cualitativas del proyecto' tales como la comple#idad'fia"ilidad requerida o el grado de criticidad del negocio.

B. 0lguna descripción del personal de desarrollo yKo del entorno dedesarrollo.

0 partir de estos datos' el modelo implementado por la $erramienta autom!tica deestimación proporciona estimaciones del esfuerzo requerido para llevar aca"o elproyecto' los costos' la carga del personal' la duración y en algunos casos' laplanificación temporal del desarrollo y el riesgo asociado.

2.H P+)!i i()(i ! "e P%&'e(t&s.

El o"#etivo de planificación del proyecto de Software es proporcionar un marco detra"a#o que permita al gestor $acer estimaciones razona"les de recursos' costo yplanificación temporal. Estas estimaciones se $acen dentro de un marco de tiempolimitado al comienzo de un proyecto de Software' y de"er%an actualizarse amedida que progresa el proyecto. 0dem!s' las estimaciones de"er%an definir losescenarios del V me#or caso W y V peor caso W de forma que los resultados delproyecto puedan limitarse .El o"#etivo de la planificación se logra mediante un proceso de descu"rimiento dela información que lleve a estimaciones razona"les.

9 0it& "e+ S& t5)%e.

,a primera actividad de la planificación del proyecto de Software es determinar elmbito del Soft!are . Se de"en evaluar la función y el rendimiento que se

asignaron al Software durante la ingenier%a del sistema. El !m"ito del Softwaredescri"e la función' el rendimiento' las restricciones' las interfases y la fia"ilidad.Se eval-an las funciones descritas en el enunciado del !m"ito' y en algunoscasos se refinan para dar m!s detalles antes del comienzo de la estimación.,a técnica m!s utilizada con frecuencia para acercar al cliente y al desarrollador' ypara $acer que comienza el proceso de comunicación es esta"lecer unaentrevista preliminar.,a comunicación con el cliente lleva a una definición de datos ' funciones' ycomportamientos a implementarse' y de información so"re el rendimiento yimitaciones que delimitan el sistema.

Re(#%s&s

20


21/26

,a segunda tarea de la planificación del desarrollo de Software es la estimación delos recursos requeridos para acometer el esfuerzo de desarrollo de Software.

En "ase a la pir!mide de recursos se encuentra el entorno de desarrollo*?ardware y Software6 que proporciona la infraestructura de soporte al esfuerzo dedesarrollo. En un nivel m!s alto se encuentra los componentes del Soft!are/eutilizables, los "loques de Software que pueden reducir dr!sticamente loscostos de desarrollo y acelerar la entrega. En la parte m!s alta esta el recursoprimario6las personas.

Re(#%s&s # )!&s

El encargado de la planificación comienza elevando el !m"ito y seleccionando las$a"ilidades técnicas que se requieren para llevar aca"o el desarrollo. El n-merode personas requeridas para un proyecto de Software sólo puede ser determinadodespués de $acer una estimación del esfuerzo de desarrollo ( por e#emplo'personas 5 mes o personas 5 a2os.)

Re(#%s&s "e S& t5)%e Re#ti+i/)0+es.

>ualquier estudio so"re recurso de Software estar%a incompleto sin estudiar lareutilización' esto es' la creación y la reutilización de "loques de construcción desoftware 9?IID;


22/26

C& $&!e!tes ') "es)%%&++)"&s. El Software existente se puede adquirir de unatercera parte o provenir de uno desarrollado internamente para un proyectoanterior. Estos componentes est!n listos para utilizarse en el proyecto actual y se$an validado totalmente.

C& $&!e!tes ') e $e%i e!t)"&s. ,as especificaciones' dise2os' códigos' odatos de prue"as ya existentes y desarrollados para proyectos anteriores que sonsimilares al Software que se va a construir para el proyecto actual. ,os miem"rosdel equipo del Software actual ya $an tenido la experiencia completa en el !rea dela aplicación representada para estos componentes' ,as modificaciones' por tanto'requeridas para componentes de total experiencia' tendr! un riesgo relativamente"a#o.

C& $&!e!tes (&! e $e%ie!(i) $)%(i)+. ,as especificaciones' los dise2os'códigos o los datos de prue"a existentes ya desarrollados para proyectosanteriores que se relacionan con el Software que se va a construir para elproyecto actual' pero que requerir!n una modificación sustancial. ,os miem"rosdel equipo del Software actual $an limitado su experiencia sólo al !rea deaplicación representada por estos componentes. ,as modificaciones' por tanto'requeridas para componentes de experiencia parcial tendr!n "astante grado deriesgo.

C& $&!e!tes !#e4&s. ,os componentes de Software que el equipo de Softwarede"e construir son espec%ficamente para las necesidades del proyecto actual.

Re(#%s&s "e e!t&%!&

El entorno es donde se apoya el proyecto de Software' llamado a menudoentorno de 0ngenier a de Soft!are (+0S) incorpora ?ardware y Software. El?ardware proporciona una plataforma con las $erramientas (Software) requeridaspara producir los productos que son el resultado de una "uena pr!ctica de laingenier%a de Software.

1NJ 0 JJJ

C&!(e$t&s 86si(&s "e+ "es)%%&++& "e #! Siste ) "e I! &% )(i !

3l finalizar el siglo, 4emos descubierto que somos parte de un inmenso sistema *o conjunto de sistemas- que va de las plantas y los animales a las células, las

22


23/26

moléculas, los tomos y las estrellas. Somos un eslab5n de la cadena del ser6 como llamaban los antiguos fil5sofos al universo6

7%83907 #3:. iscurso al reci"ir el premio Nó"el de ,iteratura.

&ara Newton' dentro de su concepción mecanicista' un siste ) era unmecanismo que opera seg-n leyes inmuta"les. No as% dentro de una visiónsistémica. >onforme lo expone Oertalanffy' un sistema puede definirse como uncon#unto de elementos f;' f@' ... fn en interacción' definición a la cual' seg-nAodr%guez elgado convendr%a a2adirle la caracter%stica de poseer una frontera ol%mite6 m!s o menos "orroso6 que separa al sistema de su entorno.

Sistema es un todo que tiene una función en un todo m!s grande de lo cual es unaparte... todo sistema es parte de un sistema m!s grande.

Siste ) "e I! &% )(i !: Es un con#unto de procesos formales integrados a laempresa' que almacena datos en "ase de datos para su posterior an!lisis y tienecomo función posterior a la toma de decisiones Xerenciales.,os sistemas de información son desarrollados con propósitos diferentesdependiendo de las necesidades del negocio.

L) !e(esi")" "e+ )!6+isis ' "ise & "e siste )s

El an!lisis y dise2o de sistemas' tanto como es e#ecutado por los analistas desistemas' "usca analizar sistem!ticamente la entrada de datos o el flu#o de datos'el proceso o transformación de datos' el almacenamiento de datos y la salida deinformación dentro del contexto de un negocio particular. 0dem!s' el dise2o yan!lisis de sistemas es usado para analizar' dise2ar e implementar me#oras en elfuncionamiento de los negocios que pueden ser logradas por medio del uso desistemas de información computarizados.,a instalación de un sistema sin planeación adecuada lleva a grandesfrustraciones' y frecuentemente causa que el sistema de#e ser usado.El an!lisis y dise2o de sistemas lleva estructura al an!lisis y dise2o de sistemasde información' un costoso esfuerzo que de otra forma podr%a $a"er sido $ec$o demodo casual. &uede ser visto como una serie de procesos llevados aca"osistem!ticamente para me#orar un negocio por medio del uso de sistemas deinformación computarizados. Xran parte del an!lisis y dise2o de sistemasinvolucró el tra"a#o con los usuarios actuales y eventuales de los sistemas deinformación.

A!)+ist)s "e Siste )s: ,os analistas de sistemas generalmente valoran lamanera en que funcionan los negocios examinando la entrada' el procesamientode datos y la salida de información con el propósito de me#orar los procesosorganizacionales.

8uc$as me#oras involucran me#or apoyo para las funciones de los negocios por medio del uso de sistemas de información computarizados. Esta definición

23


24/26

enfatiza un enfoque sistem!tico y metódico para analizar' y posi"lemente me#orar'lo que esta sucediendo en el contexto espec%fico creado por un negocio.

Nuestra definición de un analista de sistemas es necesariamente amplia. Elanalista de"e ser capaz de tra"a#ar con gente de todas las descripciones y de"e

tener experiencia en el tra"a#o con computadoras. El analista desempe2a muc$ospapeles' "alanceando varios al mismo tiempo. ,os tres papeles principales delanalista de sistemas son consultor' experto de soporte y agente de cam"io.

E+ )!)+ist)s "e Siste )s (& & C&!s#+t&%

El analista de sistemas frecuentemente act-a como consultor y' por lo tanto'puede ser contratado espec%ficamente para que se encargue de los asuntos de lossistemas de información dentro de un negocio. Esto puede ser una venta#a' de"idoa que los consultores externos pueden llevar con ellos una perspectiva fresca queno poseen otros miem"ros de la organización. &ero tam"ién puede decirse que losanalistas externos est!n en desventa#a' de"ido a que la verdadera culturaorganizacional nunca puede ser conocida por un extra2o.

E+ )!)+ist) "e siste )s (& & E $e%t& "e S&$&%te

Mtro papel que tal vez requiera desarrollar es el de experto de soporte en unnegocio donde se esta empleado regularmente en alguna actividad de sistemas.En este papel el analista se apoya en su experiencia profesional relacionada conel ?ardware y Software de computadora y sus uso en el negocio. Este tra"a#ofrecuentemente no es un proyecto de sistema completo' si no solamentepeque2as modificaciones o decisiones que afectan un solo departamento.

>omo experto de soporte no est! administrando el proyecto' o simplemente est!nsirviendo como un recurso para aquellos que lo mane#an. Si se es una analista desistemas empleado por una organización de fa"ricación o servicios' muc$as de lasactividades diarias pueden ser desarrolladas en este papel.

E+ )!)+ist) "e siste )s (& & A e!te "e C) 0i&

El papel m!s compresivo y responsa"le que toma un analista de sistemas es elde agente de cam"io' ya sea externo o interno al negocio. >omo analista se es unagente de cam"io cada vez que se e#ecuta cualquiera de las actividades del ciclode vida del desarrollo de sistemas ( tratado en la siguiente sección ) y se est!presente en el negocio por un periodo extendido ( de dos semanas $asta m!s deun a2o ). 1n agente de cam"io puede ser definido como una persona que sirve decatalizador para el cam"io' desarrolla un plan para el cam"io y tra"a#a #unto conotras para facilitar ese cam"io.

C#)+i")"es "e+ )!)+ist) "e siste )s

24


25/26

0 partir de la descripción anterior de los papeles que desempe2a el analista desistemas' es f!cil ver que el analista de sistemas exitoso de"e poseer una altogrado de cualidades. 8uc$os tipos de agentes diferentes son analistas desistemas' por lo que cualquier descripción quedar! corta en alguna forma. Sinem"rago' $ay algunas cualidades que parecen mostrar la mayor%a de los analistas

de sistemas. 0ntes que nada' el analista es un solucionador de pro"lemas. Es una persona queve el an!lisis de los pro"lemas como un reto y que disfruta al encontrar solucionesfuncionales. >uando es necesario' el analista de"e ser capaz de atacar sistem!ticamente la situación al mano por medio de la aplicación $!"il de$erramientas' técnicas y experiencia. El analista tam"ién de"e ser un comunicador capaz de relacionarse en forma significativa con la dem!s gente a través deperiodos extensos. ,os analistas de sistemas necesitan la suficiente experienciaen computación para programar' comprender las capacidades de lascomputadoras' para recoger los requerimientos de información de los usuarios ypara comunicar lo que se necesita a los programadores.El analista de sistemas de"e ser un individuo auto disciplinado y auto motivado'capaz de mane#ar y coordinar innumera"les recursos del proyecto incluyendo aotras gentes. El an!lisis de sistemas es una carrera que demanda muc$o' pero encompensación es cam"iante y siempre retadora.

EL CICLO DE IDA DEL DESARROLLO DE SITEMAS

?emos $ec$o referencia al enfoque sistem!tico que toma el analista para elan!lisis y dise2o de sistemas de información. 8uc$o de esto esta comprendido enlo que es llamado el ciclo de vida del desarrollo de sistemas ( S ,> por sus siglasen inglés). El S ,> es un enfoque por fases del an!lisis y dise2o que sostieneque los sistemas son desarrollados de me#or manera mediante el uso de un cicloespec%fico de actividades del analista y del usuario.,os analistas no est!n de acuerdo con qué tantas fases exactas $ay en el ciclo devida del desarrollo de sistemas' pero' por lo general' ala"an su enfoqueorganizado. 0qu% $emos dividido el ciclo en siete fases.

0unque cada fase es presentada en forma discreta' nunca se lleva aca"o como unpaso aparte. En vez de ello' varias actividades pueden suceder simult!neamente'y las actividades pueden ser repetidas. Esta es la razón por lo cual es m!s -tilpensar que el S ,> se logra en fases ( >on actividades traslap!ndose y luegodisminuyendo) y no en pasos separados.

25


26/26

unidad ii ing-software

Documents