1

Ingeniera de software UNI-I Luis Enrique R

2010
5
Se llama ciclo de ida del software a las fases !or las que !asa un !ro"ecto de software
desde que es conce#ido$ %asta que est& listo !ara usarse' (!icamente$ inclu"e las
siguientes actiidades) toma de requisitos$ an&lisis$ dise*o$ desarrollo$ !rue#as
+alidaci,n$ aseguramiento de la calidad-$ instalaci,n +im!lantaci,n-$ uso$ mantenimiento
" o#solescencia' El !ro"ecto tiende a !asar iteratiamente !or estas fases$ en lugar de
%acerlo de forma lineal' .s !ues$ se %an !ro!uesto arios modelos +en cascada$
incremental$ eolutio$ en es!iral$ o concurrente$ !or citar algunos- !ara descri#ir el
!rogreso real del !ro"ecto'
MODELO EN CASCADA
El modelo en cascada es el m&s sim!le
de todos ellos " sire de #ase !ara el
resto' Sim!lemente asigna unas
actiidades a cada fase$ que serir&n
!ara com!letarla " !ara !ro!orcionar los
requisitos de la siguiente' .s$ el
!ro"ecto no se dise*a %asta que %a sido
anali/ado$ o se desarrolla %asta que %a
sido dise*ado$ o se !rue#a %asta que %a
sido desarrollado$ etc'
5
MODELO EN ESPIRAL
El modelo en es!iral se #asa en la
creaci,n de !rototi!os del !ro"ecto$ que
!asan !or las fases anteriores$ " que an
acerc&ndose sucesiamente a los
o#0etios finales' .s !ues$ nos !ermite
e1aminar " alidar re!etidamente los
requisitos " dise*os del !ro"ecto antes de
acometer nueas fases de desarrollo'
MODELO ITERATIVO O
INCREMENTAL
2inalmente$ el modelo iteratio
o incremental es el que !ermite
que las fases de an&lisis$
dise*o$ desarrollo " !rue#as se
retroalimenten continuamente$
" que em!iecen lo antes
!osi#le' 3ermitir& atender a
!osi#les cam#ios en las
necesidades del usuario o a
nueas %erramientas o
com!onentes que los
desarrolladores descu#ran "
que faciliten el dise*o o
!ro!orcionen nueas
funcionalidades'
Se trata de o#tener lo m&s
r&!idamente una ersi,n
funcional del software$ "
a*adirle !restaciones a !artir
de lo que se %a a!rendido en la ersi,n anterior' El a!rendi/a0e !roiene tanto del
5
desarrollo anterior$ como del uso del software$ si es !osi#le' En este ti!o de desarrollo es
im!rescindi#le esta#lecer una lista de control del !ro"ecto$ donde iremos registrando las
funcionalidades que faltan !or im!lementar$ las reacciones de los usuarios$ etc' " que
nos !ro!orcionar& las #ases !ara cada nuea iteraci,n'
Este 4ltimo m5todo es el m&s usado +aunque sea inoluntariamente- en !ro"ectos de
software li#re$ !or la !ro!ia naturale/a cam#iante de los requisitos

(odo sistema tiene un !eriodo de definici,n en el cual se %an de !lanificar todas las
eta!as del mismo$ tanto de creaci,n como de correcci,n' 3ara llearlo a ca#o tenemos
diferentes o!ortunidades$ la elecci,n ser& m&s ,!tima si anali/amos #ien los
requerimientos " !ro!iedades que se desean !ara el sistema'
La determinaci,n de los requerimientos se %alla en #ase a la e1!eriencia de %a#lar con
el usuario final so#re sus necesidades " anali/ando un sistema de software e1istente'
!odemos modeli/ar los requerimientos del usuario mediante lengua0es como U6L$ que
dis!onen de modelos llamados casos de uso !ensados !ara descri#ir las
funcionalidades necesarias !ara los usuarios'
7a" diferentes ti!os de requerimientos) de entorno +Sistema 8!eratio$ sistema gestor
de #ase de datos$ sistema de arc%ios etc'9- ergon,micos +interfa/ grafica$ etc'9-
funcionales +que de#e %acer el sistema-$ de rendimiento$ de tiem!o$ formato de entrega$
etc'
Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siuientes ob!etivos en
mente"
Identifique las necesidades del :liente'
Eal4e que conce!tos tiene el cliente del sistema !ara esta#lecer su ia#ilidad'
Realice un .n&lisis (5cnico " econ,mico'
.signe funciones al 7ardware$ Software$ !ersonal$ #ase de datos$ " otros
elementos del Sistema'
Esta#le/ca las restricciones de !resu!uestos " !lanificaci,n tem!oral'
:ree una definici,n del sistema que forme el fundamento de todo el tra#a0o de
Ingeniera'

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio

del Hardware y el Software, as como de la Ingeniera humana (Manejo y
dministraci!n de "ersonal#, y administraci!n de base de datos$
5
Ob!etivos del Anlisis#
Identi$icaci%n de Necesidades#
Es el !rimer !aso del an&lisis del sistema$ en este !roceso en .nalista se re4ne con el
cliente ";o usuario +un re!resentante institucional$ de!artamental o cliente !articular-$ e
identifican las metas glo#ales$ se anali/an las !ers!ectias del cliente$ sus necesidades
" requerimientos$ so#re la !lanificaci,n tem!oral " !resu!uestal$ lneas de mercadeo "
otros !untos que !uedan a"udar a la identificaci,n " desarrollo del !ro"ecto'
.lgunos suelen llamar a esta !arte &Anlisis de Re'uisitos % " lo diiden en cinco
!artes)
Reconocimiento del problema.
Evaluacin y Sntesis.
Modelado.
Especificacin.
Revisin.
.ntes de su reuni,n con el analista$ el cliente !re!ara un documento conce!tual del
!ro"ecto$ aunque es recomenda#le que este se ela#ore durante la comunicaci,n :liente
< analista$ "a que de %acerlo el cliente solo de todas maneras tendra que ser
modificado$ durante la identificaci,n de las necesidades'
Estudio de Viabilidad#
6uc%as eces cuando se em!rende el desarrollo de un !ro"ecto de Sistemas los
recursos " el tiem!o no son realistas !ara su materiali/aci,n sin tener !5rdidas
econ,micas " frustraci,n !rofesional' La ia#ilidad " el an&lisis de riesgos est&n
relacionados de muc%as maneras$ si el riesgo del !ro"ecto es alto$ la ia#ilidad de
!roducir software de calidad se reduce$ sin em#argo se de#en tomar en cuenta cuatro
&reas !rinci!ales de inter5s)
(# Viabilidad econ%mica#
Una ealuaci,n de los costos de desarrollo$ com!arados con los ingresos netos o
#eneficios o#tenidos del !roducto o Sistema desarrollado'
)# Viabilidad T*cnica#
Un estudio de funciones$ rendimiento " restricciones que !uedan afectar la
reali/aci,n de un sistema ace!ta#le'
+# Viabilidad Leal#
5
Es determinar cualquier !osi#ilidad de infracci,n$ iolaci,n o res!onsa#ilidad legal en
que se !odra incurrir al desarrollar el Sistema'
Es!ecificaciones del Sistema) Es un =ocumento que sire como fundamento
!ara la Ingeniera 7ardware$ software$ >ase de datos$ e ingeniera 7umana'
=escri#e la funci,n " rendimiento de un Sistema #asado en com!utadoras " las
dificultades que estar&n !resentes durante su desarrollo' Las Es!ecificaciones de
los requisitos del software se !roducen en la terminaci,n de la tarea del an&lisis'
El conce!to 8rientado a 8#0eto es m&s sim!le " est& menos relacionado con la
inform&tica que el conce!to de flu0o de datos' Esto !ermite una me0or comunicaci,n
entre el analista " el e1!erto en el dominio del !ro#lema +es decir$ el cliente-'
2' El !aradigma 8rientado a 8#0eto utili/a la %erencia !ara e1!resar e1!lcitamente
las caractersticas comunes de una serie de o#0etos' Estas caractersticas comunes
quedan escondidas en el an&lisis " dise*o estructurado " llean a du!licar entidades
en el an&lisis " c,digo en los !rogramas' Sin em#argo$ el !aradigma 8rientado a
8#0eto !one es!ecial 5nfasis en la reutili/aci,n$ " !ro!orciona mecanismos efectios
que !ermiten reutili/ar aquello que es com4n$ sin im!edir !or ello descri#ir las
diferencias'
?' La !rogramaci,n orientada a o#0etos es muc%o m&s fia#le !or diersas ra/ones'
En !rimer lugar !or el desarrollo incremental " la !rogramaci,n !or diferencia$ al
!oder ir a*adiendo funcionalidad a %erencia' El tama*o medio de una rutina en
entornos orientados a o#0etos es de @ o 5 lneasA " se %a de tener en cuenta que s,lo
se tienen rutinas$ "a que no e1iste el conce!to de !rograma !rinci!al' La utili/aci,n
masia de li#reras de clases garanti/a la fia#ilidad$ "a que los com!onentes s,lo se
a*aden a la li#rera cuando se %a erificado la correcci,n de su funcionamiento'
El an&lisis estructurado se #asa fundamentalmente en la descom!osici,n funcional
del sistema que queremos construir' Esta descom!osici,n funcional requiere traducir
el dominio del !ro#lema en una serie de funciones " su#funciones' El analista de#e
com!render !rimero el dominio del !ro#lema " a continuaci,n documentar las
5
funciones " su#funciones que de#e !ro!orcionar el sistema' El !ro#lema es que no
e1iste un mecanismo !ara com!ro#ar si la es!ecificaci,n del sistema e1!resa con
e1actitud los requisitos del sistema'

@' El !aradigma orientado a o#0etos es una forma de !ensar acerca de un !ro#lema
en t5rminos del mundo real en e/ de en t5rminos de un ordenador' El .n&lisis
8rientado a 8#0etos !ermite anali/ar me0or el dominio del !ro#lema$ sin !ensar en
t5rminos de im!lementar el sistema en un ordenador como el an&lisis " dise*o
estructural' El .n&lisis 8rientado a 8#0etos !ermite !asar directamente el dominio del
!ro#lema al modelo del sistema'
5' Los cam#ios en los requisitos afectan nota#lemente a la funcionalidad de un
sistema$ !or lo que afectan muc%o al software desarrollado con m5todos
estructurados' Sin em#argo$ los cam#ios afectan en muc%a menor medida a los
o#0etos que com!onen o mane0a el sistema$ que son muc%o m&s esta#les' Las
modificaciones necesarias !ara ada!tar una a!licaci,n #asada en o#0etos a un
cam#io de requisitos suelen estar muc%o m&s locali/adas'
B' La transici,n entre las fases de an&lisis " dise*o en la orientaci,n al o#0eto es
muc%o m&s suae que en las metodologas estructuradas$ no %a#iendo tanta
diferencia entre las eta!a'
Enca,sulaci%n - ocultaci%n de datos" El t5rmino enca!sulaci,n indica l ca!acidad
que tienen los o#0etos de construir una c&!sula a su alrededor$ ocultando la
informaci,n que contienen +aqu5lla que es necesaria !ara su funcionamiento interno$
!ero innecesaria !ara los dem&s o#0etos- a las otras clases que com!onen la
a!licaci,n'
La ca!acidad de !resentaci,n de informaci,n dentro de un o#0eto se diide en dos
!artes #ien diferenciadas)
Inte.na" La informaci,n que necesita el o#0eto !ara o!erar " que es innecesaria !ara
los dem&s o#0etos de la a!licaci,n' Estos atri#utos se denominada !riados " tienen
como marco de a!licaci,n 4nicamente a las o!eraciones asociadas al o#0eto'
E/te.na" La que necesitan el resto de los o#0etos !ara interactuar con el o#0eto que
definimos' Estas !ro!iedades se denominan !4#licas " corres!onde a la informaci,n
que necesitan conocer los restantes o#0etos de la a!licaci,n res!ecto del o#0eto
definido !ara !oder o!erar'
Las caractersticas de =ise*o estructurado de o#0etos +=88-)
Mantenibilidad" :ualidad que indica que un !rograma o sistema de#e ser
f&cilmente modifica#le' Es decir que los cam#ios en las condiciones e1ternas
+como la definici,n de una nuea aria#le- im!licar&n modificaciones
5
!eque*as en el !rograma ; sistema' El conce!to de manteni#ilidad im!lica
que un !rograma$ al igual que un ser io de#e ser ca!a/ de ada!tarse a un
medio am#iente siem!re cam#iante'
Reusabilidad" a noci,n de o#0eto !ermite que !rogramas que traten las
mismas estructuras de informaci,n reutilicen las definiciones de o#0etos
em!leadas en otros !rogramas e incluso los !rocedimientos que los
mani!ulan' =e esta forma$ el desarrollo de un !rograma !uede llegar a ser
una sim!le com#inaci,n de o#0etos "a definidos donde estos est&n
relacionados de una manera !articular'
La eoluci,n del dise*o de software$ como !arte del !roceso de desarrollo de software$
es un !roceso continuo que se %a ido !roduciendo durante las 4ltimas tres d5cadas' Los
!rimeros tra#a0os so#re dise*o se centraron so#re los criterios !ara el desarrollo de
!rogramas modulares " los m5todos !ara me0orar la arquitectura del software de una
manera descendente' Los as!ectos !rocedimentales de la definici,n del dise*o
eolucionaron %acia una filosofa denominada !rogramaci,n estructurada' 3osteriores
tra#a0os !ro!usieron m5todos !ara la traducci,n del flu0o de datos o de la estructura de
los datos$ en una definici,n de dise*o' Nueos enfoques !ara el dise*o !ro!onen un
m5todo orientado a o#0etos !ara la o#tenci,n del dise*o'
:ada metodologa de dise*o de software introduce %eursticas " notaciones !ro!ias$ as
como una isi,n algo !articular de lo que caracteri/a a la calidad del dise*o' Sin
em#argo$ todas las metodologas tienen arias caractersticas comunes)
Un mecanismo !ara la traducci,n de la re!resentaci,n del cam!o de informaci,n
en una re!resentaci,n de dise*o A
5
Una notaci,n !ara re!resentar los com!onentes funcionales " sus interfaces A
7eursticas !ara el refinamiento " la !artici,n$ "
:riterios !ara la aloraci,n de la calidad'
El o#0etio m&s im!ortante es )
Entregar las funciones requeridas !or el usuario +Satisfaga una es!ecificaci,n funcional
dada-'
3ero adem&s !ara lograr esto de#en considerarse los as!ectos de)
Rendimiento" cu&n r&!ido !ermitir& el dise*o reali/ar el tra#a0o dado un recurso
!articular de %ardware' Es decir que contem!le las limitaciones del medio donde ser&
im!lementado el sistema$ " alcance los requerimientos de !erformance " uso de
recursos'
Cont.ol" !rotecci,n contra errores %umanos$ m&quinas defectuosas$ o da*os
intencionales'
Con$iabilidad" facilidad con la cual el dise*o !ermite modificar el sistema'
El 4nico instrumento adecuado !ara determinar el status de la calidad de un !roducto
software es el !roceso de !rue#as' En este !roceso se e0ecutan !rue#as dirigidas a
com!onentes del software o al sistema de software en su totalidad$ con el o#0etio de
medir el grado en que el software cum!le con los requerimientos' En las !rue#as se
usan casos de !rue#a$ es!ecificados de forma estructurada mediante (5cnicas de
!rue#a' El !roceso de !rue#as$ sus o#0etios " los m5todos " t5cnicas usados se
descri#en en el !lan de !rue#a'
(i!os de !rue#a)
P.uebas unita.ias" E0ecutado ma"ormente !or los desarrolladores
P.uebas de Ca!a 0lanca" Esta #asada en la l,gica interna de la a!licaci,n " el
c,digo' 7ace una co#ertura de declaraciones del c,digo$ ramas$ caminos "
condiciones'
5
P.uebas de Ca!a Ne.a" No est& #asada en el conocimiento del c,digo o dise*o
interno$ determina la funcionalidad del sistema'
P.uebas al$a1 - ,.uebas beta" Es la !rue#a cuando la a!licaci,n esta cerca de la
entrega al usuario' Se %acen !eque*os cam#ios generalmente en el dise*o de
interfaces' Esta !rue#a es %ec%a !or usuarios' Es la #4squeda de #ugs en el
!rograma com!leto' Ceneralmente es %ec%a !or usuarios'
3rue#as de Integridad
P.uebas del Sistemas" Es una !rue#a de ca0a negra inclu"endo todos los
com!onentes del sistema desde el %ardware a la documentaci,n'
Pasos ,a.a el desa..ollo de ,.uebas"
- Obtener los requerimientos en forma clara.
- Obtener planificacin de diseo.
- Determinar funcionalidad.
- dentificar aplicaciones de alto ries!o o con prioridad de prueba.
- Determinar m"todos de prueba.
- Determinar conte#to de la prueba.
- Obtener datos de prueba.
- Estimar tiempo de prueba.
- $lasificar errores del pro!rama.
- Documentar errores del pro!rama.
- Redactar los casos de prueba que encontraron fallas.
- %probar una revisin en la prueba.
- Evaluar resultados en reportes.
- &uscar bu!s.
- 'olver a probar si es necesario.
- %ctuali(ar el plan de prueba.
5
5
=efinici,n " significado de :onfigurar)
.da!tar una a!licaci,n software o un elemento %ardware al resto de los elementos del
entorno " a las necesidades es!ecficas del usuario' Es una tarea esencial antes de
tra#a0ar con cualquier nueo elemento' La tendencia actual es a reducir las necesidades
de configuraci,n mediante sistemas que !ermiten al nueo elemento detectar en qu5
entorno se instala$ configur&ndose autom&ticamente sin requerir la !artici!aci,n del
usuario' :uando 5sta es necesaria$ se intenta facilitar al m&1imo el !roceso de
configuraci,n'
-:ursor) Elemento gr&fico que indica en qu5 !unto de la !antalla se situar& el car&cter
que se introdu/ca en ese momento' Suele re!resentarse mediante un rect&ngulo o lnea
!ar!adeante$ aunque su forma " color de!enden del !rograma que se utilice$
!ermiti5ndose$ generalmente$ ada!tar sus caractersticas a los gustos " !referencias del
usuario'
-CE6) +Cra!%ics Enironment 6anager- .dministrador de entorno de gr&ficos' Interfa/
de usuario gr&fica de =igital Researc%$ similar al entorno 6ac;Dindows' CE6 se
incor!ora en R86 en arias com!utadoras'
->eta-tester) .ntes de lan/arse un !rograma de software$ un determinado n4mero de
usuarios$ t5cnicos " e1!ertos lo !rue#an con el fin de detectar errores en su
funcionamiento' Son los #eta-tester Su !rinci!al caracterstica es que no !ertenecen a la
em!resa desarrolladora del software en cuesti,n$ " que reali/an las !rue#as del
!rograma en un entorno real$ esto es$ como si realmente tra#a0aran con 5l'
-3aquete) El t5rmino se refiere a cierto software de a!licaci,n dise*ado !ara atender
necesidades sectoriales$ de un ti!o de negocio$ etc' Un !aquete integrado contiene un
con0unto de !rogramas !ara atender diersas necesidades$ !or e0em!lo) conta#ilidad$
entas$ etiquetas$ etc5tera' :on frecuencia$ un !aquete integra a!licaciones
desarrolladas !or distintas firmas'
-.n&lisis) En an&lisis de sistemas es el !rimer !aso$ en este !roceso en .nalista se
re4ne con el cliente ";o usuario +un re!resentante institucional$ de!artamental o cliente
!articular-$ que identifican'
La fase de mantenimiento de un !ro"ecto contiene las fases de im!lantaci,n$ testeo$
de!uraci,n " control de rendimiento$ eta!as que nos !ermiten a0ustar nuestro sistema de
forma que sus funcionalidades corres!ondan con los o#0etios iniciales'
La !rimera fase del mantenimiento de un sistema software consiste en la im!lantaci,n
de nuestra a!licaci,n en el entorno donde se a a desarrollar' 3osteriormente$ es
necesario reali/ar una serie de !rue#as !ara com!ro#ar que no %an surgido !ro#lemas$
en tal caso ser& recomenda#le reali/ar una de!uraci,n' 2inalmente$ se de#e mantener
5
un control del Rendimiento' 3ara com!letar todas estas fases con 51ito$ dis!onemos de
diersas utilidades que facilitan el !roceso de mantenimiento'
:.SE) :om!uter < .ided Software Engineering , Ingeniera de Software a!licada en
com!utadoras
(ecnologa :ase'
Sus :om!onentes de la 7erramienta :ase'
Su Estructura'
Estado .ctual'
:ase en el 2uturo
:lasificaciones