ingeneria de sofware

7/18/2019 ingeneria de sofware

http://slidepdf.com/reader/full/ingeneria-de-sofware 1/40

software

Conceptos

DOCENTE: Richard Ugarte GarcíaPunata - Cochaa!a - "o#i$ia



Conceptos

Ingeniería de siste!as:Es un modo de enfoque interdisciplinario que permite estudiar ycomprender a los sistemas, con el propósito de implementar uoptimizar sistemas complejos.

Ingeniería de re%ueri!ientos:

Enfoca un área fundamental: la denición de lo que sedesea producir. Su principal tarea consiste en la generación deespecicaciones correctas que describan con claridad, sinambigüedades, en forma consistente y compacta, elcomportamiento del sistema.

Ingeniería de producto:Es el softare acabado, esta orientado a !acer sistemas para

mercados grandes, se concentra en las caracter"sticas que tiene quetener el producto para ser #endido, comercializado.

Ingeniería de procesos negocios:Se !ace softare para una empresa, se obser#a como trabaja o

funciona una empresa, modica la estructura organizacional de unainstitución$tareas que ocupaban funcionarios a!ora los procesa el&



Conceptos

Ingeniería de software:Es el proceso de desarrollo de softare, mediante m'todos yt'cnicas para resol#er problemas reales de la sociedad.

Ingeniería de re%uisitos:(acilita el mecanismo apropiado, para comprender lo que

quiere el cliente. Es parte de la ingenier"a de requerimientos. Ingeniería de prueas:

)n producto no probado no sale al mercado, constantementebuscan errores e identican, ellos #an probando y se aseguran deque el producto sea de calidad.

&iste!as de infor!aci'n:

Es un conjunto de partes que interact*an entre si para lograrun objeti#o.

El sistema de información es considerado como un conjunto decomponentes interrelacionados que recuperan, procesan,almacenan y distribuyen información para soportar la toma dedecisiones, la coordinación y el control de una organización.

+



elaciones-ajo el concepto de ingeniería de siste!as se entiende

una ciencia que estudia como mejorar los sistemasorganizacionales, de producción, #entas, comercialización yotros. ara ello normalmente se apoya en sistemascomputacionales

/uando la ingenier"a de softare se orienta a unaorganización se denomina ingeniería de proceso denegocios.

/uando se orienta a un producto se denomina ingenieríade producto.

ara que ingeniería de software nos ayude a construirsistemas complejos o simples debemos !acer uso de laingeniería de re%ueri!ientos o requisitos, ingenieríade prueas y otros procedimientos.

0



elaciones 1ng. Sistemas

1ng. producto

1ng.Softare

1ng. roceso

negocios

&iste!as de infor!aci'nauto!ati(ados

1ng. de requerimientos 21ng. de requisitos

1ng. de pruebas

3



epaso 4area 5:

/ontrastar6relacionar6denir: 7ejor si muestranmediante un diagrama las relaciones6diferenciasentre los siguientes conceptos:

1ng. Sistemas 1ng. roducto1ng. Softare 1ng. equisitos1ng. equerimientos 1ng. roceso 8egociosSistemas de información 1ng. ruebas

9



)ase deDe*nici'n

cti#idades de:•nálisis•lanicación

;



+n,#isis de&iste!as



nálisis de sistemas

Oeti$oProductoEl Docu!ento de Especi*caci'n de

re%ueri!ientossir#e para realizar el contrato entre el cliente y

el desarrollador

E<isten dos paradigmas a tra#'s de los cualesse enfrenta la acti#idad análisis de sistemas: Paradig!a Estructurado Paradig!a Orientado a Oetos

=



+cti$idades de#+n,#isis

5. Estudio de (actibilidad&. >btención y análisis de

requerimientos/omprensión del dominiorototipado $opcional%ecolección de requerimientos/lasicación de informaciónesolución de con?ictos

riorización@ericación de requerimientos

+. Especicación derequerimientos

0. @alidar requerimientos

5. econocimiento delproblema

&. E#olución y s"ntesis:

$7odelamiento6prototipeo%

+. Especicación0. e#isión (inal

5A



epaso 4area 5:

+n,#isis de &iste!as&. 1denticar los paradigmas que se utilizan

para el análisis de sistemas. E<plicar los &más usados y por cada uno de ellosseBalar las !erramientas y notaciones ausar.

+. Cescribir el proceso de análisis: pasos aseguir y sus entregables6productos.

55



requerimientosDos requisitos establecidos e<pl"citamente se

re?ejan en el documento de especicación derequisitos del sistema:

Re%ueri!iento: )n requerimiento puede ser

especicado desde una sentencia en lenguaje natural,!asta en un lenguaje matemático muy formal. Da l"neaentre requerimientos y especicaciones de diseBo esdelgada.

Das especicaciones de requerimientos deber"anproducirse a diferentes niveles de abstraccióntomando en cuenta que una Especicación del Sistemadebe ser entendida por los potenciales usuarios, deforma que sir#a de base para realizar el contrato entreel ingeniero y los usuarios, quienes preeren una 5&



Fu' es unrequerimientoG

CE(181/1H8:)n ser#icio que el sistema debe pro#eer

)na caracter"stica o restricción que debecumplir.

Ejemplos..• No es una necesidad• No es un problema

5+



4ipos de requerimientos)unciona#es: funciones a realizar por el

softare. Son declaraciones de los servicios que pro#eeráel sistema. Estos requerimientos son el corazón del sistema,puesto que su e<istencia e<plican la necesidad del mismo.

lgunas #eces los requerimientos funcionales tambi'ndeclaran e<pl"citamente lo que el sistema no debe !acer.

Dos requerimientos funcionales denen las funciones que

el sistema será capaz de realizar. Cescriben lastransformaciones que el sistema realiza sobre las entradaspara producir salidas.

Este es el corazón del sistema, si no fuera por los requerimientosfuncionales, el sistema no tendr"a razón de ser.

/arrera de SistemasI1nformática)7SS: /oc!abambaJ-oli#ia

507gr. 1ndira /amac!o del /astillo 7ateria: 1ngenier"a de Softare



funciona#es

&iste!a de caero auto!,tico. (5: 1denticar usuario.

(&: Emitir estado de cuenta. (+: ealizar transacción de retiro de

dinero (3: Emitir recibo impreso.

53



4ipos de requerimientosNo funciona#es: Son restricciones bajo

las cuales el sistema debe operar.quellos requerimientos que no se reeren directamente a

las funciones espec"cas que entrega el sistema, sino a laspropiedades emergentes de este como la abilidad, larespuesta en el tiempo, la capacidad de almacenamiento,

interfaz, documentación, consideraciones de !ardare,caracter"sticas de desempeBo, manejo de errores,condiciones e<tremas, asuntos de calidad, modicaciones alsistema, ambiente f"sico, cuestiones de seguridad,cuestiones de recursos, pol"ticas de la organización encuanto al softare o !ardare

Dos requerimientos no funcionales tienen que #er concaracter"sticas que de una u otra forma puedan limitar elsistema

Estos deben ser cumplidos, acompaBan al sistemaen s" para que sea usado.

Por ee!p#o: Si pedimos que un sistema sea !ec!o en unadministrador de -C determinado y no lo !acemos elusuario no !ará uso de 'l porque la -C de la empresa esta59



requerimientosRe%ueri!iento de usuario:

Cescriben los requerimientos funcionales y nofuncionales de tal forma que sean comprensiblespor los usuarios del sistema.

Kay que tomar en cuenta que el usuario no posee

un conocimiento t'cnico detalladoEspecican el comportamiento e<terno del sistema.Dos requerimientos del usuario no se deben denir

utilizando un modelo de implementación. Cebenredactarse utilizando el lenguaje natural,representaciones y diagramas intuiti#os sencillos

Cebido al lenguaje no formal para la especicaciónpueden surgir problemas como: falta de claridad odetalle, ambigüedades y otros relacionados con el

lenguaje natural. 5;



7ás sobre

requerimientosRe%ueri!ientos de# siste!aSon descripciones más detalladas y formales que

los requerimientos del usuario.gregan detallan y e<plican como el sistema debe

proporcionar los requerimientos del usuario Sir#en como base para denir el contrato de la

implementación del sistema y por lo tanto, debe ser

una especicación completa y consistente delsistema. Son utilizados por los ingenieros desoftare como el punto de partida para el diseBo delsistema.

Simplemente deben describir el comportamiento

e<terno del sistema y sus restricciones operati#as5L



Ciagrama de elacionesde los /onceptos dados

Se detallan

5=



Re%ueri!ientos

Cel docu!ento de Esp. de equerimientos/ompleto/onsistente: Dos requerimientos no tienen con?ictos entre si

Cocumentado7odicable: Su estructura facilita los cambios.

Ce un re%ueri!iento/orrecto

@ericable: debe poder denirse si se cumplió o no. sistema.@álido: lo que el usuario realmente quiere

8o ambiguo: una sola interpretación

Cocumentado

&A



equerimientosG)n /lásicoN..

La solicitud de usuario Lo que entendió ellíder del proyecto

El diseño del analistade sistemas

El enfoque delprogramador

La recomendación delconsultor externo

La documentación del

proyecto

La implantación en

producciónEl soporte operativo

El presupuesto del

proyectoLo que el usuario

realmente necesitaba

¿ Necesario acer gestión de requerimientos !

• Los requerimientos son los cimientos de un sistema• Los requerimientos son el "cuello de botella# de la $ng% de Soft&are

á



nálisis J Subacti#idad:

7odelado del sistema

'ubo de (gua

Nido de p)*aros

La construcción del +atercube inició

en diciembre de ,--. y se planea que

est/ completamente terminado a

principios de ,--0% 'inco piscinas1 lu2

natural1 acopio de agua de lluvia1

reciclado del agua% 'osto mas de 3--millones de dólares

&&



7odelado del sistema

/uándo se realiza esta acti#idad dentro delproceso de desarrollo de softare que se denió enla parte 5.Gcti#idades de nálisis y CiseBo.

Fue modelos e<isten y cómo serepresentanG7odelos de conte<to: Estructurado $C(C de ni#el

>%, >> $/aso de uso general%,

7odelos comportamiento: >> $ diagrama decasos de uso, diagrama de secuencia, diagramade acti#idad%, Estructurado: C(COs

7odelos de datos: >>: Ciagrama de clases.

Estructurado: EJ &+



7odelado del sistema 7odelos: para qu' sir#en G

ara describir el sistema formalmente

/uándo usar GDos modelos se utilizan en la acti#idad de

análisis y diseBo. Dos modelos ayudan acomprender el sistema6requerimientos 6diseBoy se deben usar cuando sea difícil la

compresión sin ellos o la especicación puedadar lugar a ambigüedades.Dos modelos ayudan a manejar la

complejidad del sistema

&0



4'cnicas de rele#amiento

$recolección% de informaciónEntre#ista.J Se selecciona a un conjunto de personas querepresente a todos los sectores cr"ticos de la organización, con el'nfasis puesto en los sectores más afectados o que !arán un usomás frecuente del nue#o sistema.

/uestionarios.J /onsiste en el llenado formularios o contratosindicando los requerimientos. En sistemas muy complejos 'stospueden tener centenares de páginas. P se usan cuando !aymuc!os usuarios, y es dif"cil entre#istarlos a todos.

4alleres.J euniones con #arios usuarios para concertar

requerimientos. Dos requisitos tienen a menudo implicacionescruzadas desconocidas para las personas implicadas indi#iduales yque a menudo no se descubren en las entre#istas o quedanincompletamente denidas durante la misma.

>bser#ación

e#isión documental &3&3



4'cnicas6Kerramientasrototipos.J )n prototipo es una pequeBa muestra, de

funcionalidad limitada, de cómo ser"a el producto nal una #ezterminado. yudan a conocer la opinión de los usuarios yrecticar algunos aspectos antes de llegar al producto

terminado./asos de )so.J )n caso de uso es una t'cnica para

documentar posibles requerimientos, gracando la relación delsistema con los usuarios u otros sistemas.

C(COs

&9



(uentes de informaciónersonas:

)suarios directos e indirectos del sistema /olegas con e<periencia

>tros sistemas1nternetCocumentos de la empresaDibros relacionados con el softare a construir

Ce todas estas fuentes las personas son lafuente más rele#ante .

&;



epaso &: nálisis $tarea &%

5. /ontrastar6relacionar6denir: 7ejor si muestranmediante un diagrama las relaciones6diferencias entrelos siguientes conceptos

&. equerimientos funcionales Jequerimientos nofuncionalesJequerimientos )suarioJ equerimientosdel Sistema

+. Ce ejemplos por cada concepto de arriba 0 ejemplosaplicados a un sistema que le gustar"a desarrollar

0. 7odelado del sistema :/uando se realiza esta acti#idad dentro del proceso de

desarrollo de softare que se denió en la parte 5.GFue modelos e<isten Gara qu' sir#en G

/uándo usar G/omo se representanG &L



Docu!ento deEspeci*caci'n deRe%ueri!ientos

4area +



especicaciónde requerimientos

5.J1ntroducción ropósito del documento de

requerimientos lcance del producto

&.JCescripción general erspecti#a del producto (unciones del producto estricciones generales /aracter"sticas del usuario

+.Jequerimientos espec"cos

equerimientos funcionales equerimientos no funcionales

0.J lcance3.J p'ndice e "ndice

5. 1ntroducción6/onte<to

&. equerimientosfuncionalesI8o funcionales

+. )suarios6roles:1ndirectos6directos

0.lcance

3.ne<os: Cocumentación,procedimientos, información sobre#alores usados, #alidación.

+A



1ntroducciónDa introducción debe introducir al tema que

en este caso es el sistema.Se debe !ablar de la institución, sus objeti#os

planes y como el sistema ayudará a lograrlos.Se debe establecer los objeti#os de la

institución a largo, mediano y corto plazo ydentro de ese conte<to establecer el lugar que

tendrá el sistema.Es importante ubicar al sistema en el ámbito

de la organización.

+5



p'ndices $ane<os% e 1ndices+p/ndice pro#ee información detallada y precisa

relacionada con la aplicación que se desarrolla 4odo lo que no se especicó en la parte principal de forma

detallada y da lugar a doble interpretación debe ser aclarado y

especicado en los ane<os. Es aqu" que se debe C>/)7E84el análisis, es decir: se deben poner copias u originales dedocumentos como ser formularios de registro de datos,reportes, res*menes que actualmente utilizan en la empresa$sean estos de origen manual o de del antiguo sistemaautomatizado que se desea cambiar%, denir las caracter"sticasde los datos de los mismos, especicar procedimientos y6ocambios en los mismos.

0ndice se debe incluir #arios "ndices en el documento unoalfab'tico, de contenido, diagramas, funciones y otros.

+&



epaso Coc.eq. $tarea +%

5. Especique el contenido m"nimo. E<pliquemediante un ejemplo en que consiste cadauna de sus partes $ a tra#'s de un caso de

aplicación%.&. 1ndique que fuentes de información son

recomendables para su elaboración y en queconsiste cada una de ellas.

+. /ondiciones que tiene que cumplir ocaracter"sticas que debe tener el documentopara ser considerado de calidad.

0. 7encione el contenido de los ane<os que

deber"a tener este documento. ++



+ntes de hacer un p#an 1despu/s de un an,#isispre$ionálisis de (actibilidadnálisis de opciones



nálisis de factibilidadOeti$o Resu#tados

Es asegurarnos que

el proyecto #a traerbenecios y esposible realizarlo con

los recursosmateriales,

tecnológicos y!umanos

•Seguir adelante con el

proyecto•ecomendar retrasar por untiempo•8o continuar con el proyecto•/ontinuar con el proyecto

modicado

+3



nálisis de factibilidad/onsideraciones:

(actibilidad económica $administrador de laempresa%: -enecios Q @s. /ostos Q

(actibilidad t'cnica$desarrollador6administrador%

(actibilidad operati#a $desarrollador%

(actibilidad legal $desarrollador%

(actibilidad pol"tica

+9



nálisis de opcionesOeti$o

Es escoger el proyecto que más #entajas tiene .Producto

1nforme indicando la mejor opción y por qu'

&e necesita esta#ecer:5.>bjeti#os I rioridades&.Establecer parámetros de comparación+./uanticar los parámetros elegidos para cada una de

las opciones0.plicar alg*n m'todo para elegir objeti#amente una

opción.

2/todos7atriz payJoR

Mrácos de polaridad +;



nálisis de opciones:

7atriz ayJoR

1. Opción conservativa: objeti#o minimizar lasp'rdidas, elegirá la opción con payoR más bajo: 53.AAA.

2. Opción optimista: el objeti#o de ma<imizar lasganancias, elegirá la opción con payoR más grande: opción.

Sin embargo ni la opción conser#ati#a, ni la optimista toma lasen cuenta las magnitudes relati#as de las ganancias o las

p'rdidas, por lo que se planteó la siguiente:

Opci'n Costo2,3i!o 456

Costo2íni!o

456

Pa1o7 456

- 5AA.AAA;A.AAA 0A.AAA33.AAA 9A.AAAA53.AAA

+L



nálisis de opciones:

7atriz ayJoR Opción minimización de riesgos: considera la mismaprobabilidad para el má<imo #alor como para elm"nimo, por ejemplo:>pción : /osto probable 2 $A,3 < 5AA.AAA% $A,3 < 0A.AAA% 2

;A.AAA>pción -: /osto probable 2 $A,3 < ;A.AAA% $A,3 < 33.AAA% 2

9&.3AA

or lo que de acuerdo a esta tercera opción escoger"amos la demenor riesgo la opción B con 9&.3AA.

Si se conociese la probabilidad para que se de elm"nimo, por ejm. 93U. P para - la probabilidad dem"nimo, por ejm. 03U>pción : /osto probable 2 $A,+3 < 5AA.AAA% $A,93 < 0A.AAA% 2

95.AAA

>pción -: /osto probable 2 $A,33 < ;A.AAA% $A,03 < 33.AAA% 29+.&3A +=

nálisis de opciones: Mráco de



nálisis de opciones: Mráco depolaridadOpci'

nCosto2i#es"s.

Ca#endario4!eses6

Con*ai#idad

Reuso486

Portai#idad

E*ciencia

-/

5&.AL.A5;.3

+++A+9

3=5+

0A0A3A

=A;3+A

A.+3A.;3

5

Documents

ingeneria de sofware