ISI DIAPO 01

download ISI DIAPO 01

of 44

description

Intro a los Sistemas de Informacion

Transcript of ISI DIAPO 01

  • INGENIERA DELSOFTWARE

    ING. OLMER VILLENA LENCUSCO 2015

  • Temas

    INTRODUCCIN ESPECIFICACIN DEL SOFTWARE FUNDAMENTOS DEL DISEO SOFTAWARE TCNICAS GENERALES DE DISEO SOFTWARE

    2

  • Concepto de Ingeniera deSistemas

    Concepto de sistema, conjunto de cosas que ordenadamente relacionadasentre s contribuyen a un determinado objeto. De forma recursiva, las partesde un sistema pueden ser consideradas como nuevos sistemas (subsistemas).

    Los sistemas informticos estn compuestos por ordenadores y sus perifricos.Entre ellos podemos distinguir dos tipos de subsistemas: Sistemas Hardware, son los elementos materiales, los que se pueden

    tocar. Sistemas Software, los programas que gobiernan el funcionamiento del

    computador. El objetivo de los sistemas informticos es el tratamiento de la informacin:

    almacenamiento, elaboracin y presentacin de datos. De esta forma seautomatizan determinadas acciones.

    En la concepcin del sistema informtico no solo se decide el trabajo arealizar, sino tambin cmo ha de ser utilizado por los usuarios.

    3

  • Concepto de Ingeniera del Software

    Caractersticas del software (lo contrario para el hardware): No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales Su duplicacin es poco costosa, lo caro es el desarrollo Puede ser modificado fcilmente, tanto que es necesario un control de versiones

    La Ingeniera del Software comprende las tcnicas y procedimientos ingenieriles para eldesarrollo del software.

    La IS no se plantea solo una actividad de programacin, previamente son necesarias lasfases de anlisis y diseo y posteriormente la integracin y la verificacin, incluso elmanteniendo cuando el producto ya est en explotacin. (CICLO DE VIDA).

    Inicialmente la tarea de desarrollo era realizada individualmente por hbiles creativos, deforma poco disciplinada. El trabajo en equipo supone la divisin y organizacin del trabajoutilizandometodologas de desarrollo.

    En los 70 y los 80 empiezan a usarse herramientas CASE (Computer Aided SoftwareEngineering). En los 90 IPSE e ICASE.

    4

  • La crisis del Software

    Se produce cuando surge la necesidad de desarrollar aplicacionessoftware demasiado complejas, a mediados de los 60.

    Para superar la crisis: Aparicin de metodologas concretas de desarrollo Concepcin de la Ingeniera del Software como disciplina Trabajo en equipo y especializacin (analistas, programadores, ...)

    No se ha llegado a una situacin estable, sino a una evolucinpermanente con avances continuos en la IS, forzados por el rpidoabaratamiento y aumento de capacidad del hardware.

    5

  • Mitos del Software

    El hardware es mucho ms importante que el software El software es fcil de desarrollar El software consiste exclusivamente en programas ejecutables El desarrollo del software es slo una labor de programacin Es natural que el software contenga errores

    6

  • Formalizacin del proceso dedesarrollo La ingeniera supone la existencia de procesos bien

    establecidos para la realizacin de actividades dedesarrollo, construccin, fabricacin, etc.

    El ciclo de vida es el proceso de desarrollo y mantenimientodel software. Segn el modelo elegido se describen unconjunto de actividades para llevar a cabo el ciclo de vida,

    Los modelos clsicos y O.O. Prcticamente identifican actividades similares y slo se

    diferencian en la forma de presentacin.

    7

  • EL DESARROLLO DESISTEMAS DE INFORMACION

    Ciclo de Vida = Ciclo de Desarrollo + Mantenimiento

    MetodologasMetodologas1. ESTRUCTURADA.

    2. ORIENTADO A OBJETO

  • EL CICLO TRADICIONAL DE LOS S.I.

    FASE 1

    FASE 2

    FASE 3

    FASE N

    FASE N + 1

    FASESQUE VARIAN DEAUTOR EN AUTOR

  • CASCADA ESTRUCTURADO ESPIRAL PROPTOTIPO

    MODELOS

    Anlisis derequerimientosEspecificaciones.Diseo.Implementacin.PruebaMantenimiento.

    EncuestaAnlisis.Diseo.Implantacin..PruebasControl de calidad.Procedimientos.Conversin B.D.Instalacin.

    Requerimientos.Anlisis de riesgo.Prototipo 1, 2.Req. softwareValidacin de Req.Anlisis de riesgo.Prototipo 3.Diseo software.Validacin diseo. Integracin y prueba.

    Requerim. BsicosDesarr. Prot. oper.Uso prot.Usuario satisfecho?.Si. Aceptar.No. Revisar ymejorar.

    MODELOS PARA EL CICLO DE VIDA DEDESARROLLO DE SOFTWARE

  • Definicindel

    ProyectoEstudio

    deSistemas

    Diseo

    Programacin

    InstalacinPosimplantacin

    Laudon y Laudon. 1996Auditora.

    Pruebas

    Cdigo.

    Especificaciones.

    Propuesta sistema.

    Propuesta.

    PRODUCTOS.

    CICLO DE VIDA TRADICIONALLos Sistemas de Informacin

  • FABREGAS:1- Requerimientos2- Anlisis/Diseo3- Construccin4- Pruebas5- Produccin/Mantenimiento

    SENN:1- Investigacin Preliminar2- Determ. de Requerimientos.3- Diseo del Sistema4- Desarrollo del Software5- Prueba del Sistema6- Implantacin y Evaluacin

    PRESSMAN:1- Anlisis2- Diseo3- Codificacin4- Prueba5- Mantenimiento

    EN GENERAL USAREMOS:1- Anlisis2- Diseo3- Implementacin4- Mantenimiento

    EL CICLO DE VIDA SEGN BIBLIOGRAFA

  • Implantacin Ascendente Las fases deben sucederse de manera Secuencial El usuario no ve resultados, sino hasta el final El usuario o el ambiente pueden cambiar lasespecificaciones originales del sistema.

    Presenta numerosos problemas Analista-UsuarioManejable como proyecto

    CARACTERISTICAS DEL CICLO DE VIDACLASICO

  • CICLO DE VIDA TRADICIONAL

    ANALISIS

    IMPLEMENTACION

    DISEO

    MANTENIMIENTO

  • Sistemas II.

    CICLO DE VIDA

    1. ANALISIS:1.1. Estudio Preliminar1.2. Levantamiento de Informacin1.3. Definicin del Problema1.4. Elaboracin del Modelo Funcional del Sistema actual1.5. Determinacin de Requerimientos1.6. Descripcin y Evaluacin de Alternativas1.7. Aprobacin de alternativas

  • 2.DISEO2.1. Elaborar Modelo Funcional del Sistema

    Propuesto2.2. Diseo Lgico2.3. Elaboracin y Presentacin del

    prototipo del Sistema2.4. Aprobacin del Sistema Propuesto

    CICLO DE VIDA

  • Sistemas II.

    3. IMPLEMENTACION3.1. Desarrollo del Software3.2. Prueba del Sistema3.3. Puesta en Marcha

    Qu significa poner enMarcha un Sistema ?

    Qu significa poner enMarcha un Sistema ?

    CICLO DE VIDA

  • PUESTA EN MARCHA:Actividad de traslado de una aplicacin probada a un ambiente deproduccin

    PUESTA EN MARCHA:Actividad de traslado de una aplicacin probada a un ambiente deproduccin

    - Acondicionamiento de locales- Organizacin del Cliente- Entregar aplicacin probada- Elaborar datos en Vivo- Adiestramiento- Carga de datos en vivo- Entrega de documentacin- Asignar Responsabilidades- Determinar FIN de la instalacin

    CICLO DE VIDA

  • Es la ltima fase del Ciclo de Vida de Desarrollo deSistemas, en donde los SI son sistemticamentereparados y mejorados. Por definicin, el proceso de mantenimiento de un SI esun proceso de devolucin al principio del Ciclo de Vida yde repeticin de los pasos de desarrollo para laimplementacin de cambios. Las 4 actividades ms importantes que ocurren dentrodel mantenimiento son:Obtencin de los requerimientos de mantenimiento. Transformacin de los requerimientos en cambios.Diseo de los cambios. Implementacin de los cambios.

    MANTENIMIENTO DE SISTEMAS

  • Sistemas II.

    CORRECTIVO. Para reparar fallas en el diseo, codificacin oimplementacin, del sistema. ADAPTATIVO. Para que las funcionalidades del sistemaevolucionen a la par de los cambios del negocio o de lastecnologas. PERFECTIVO. Para agregar nuevas funciones al sistema opara mejorar su desempeo. PREVENTIVO. Para evitar posibles problemas del sistema aFuturo.

    TIPOS DE MANTENIMIENTO

  • Mtodos Orientados a Objetos Los mtodos orientados a objeto describen eimplementan los sistemas de informacin desde unpunto de vista ontolgico.

  • Sistemas II.

    QUE HACER PARAIMPLEMENTARUN EXITOSOSISTEMA DE INFORMACION?

  • MODELO EN CASCADA23

  • MODELO EN CASCADA

    ANLISIS, determinar qu debe hacer el software -> especificacin DISEO, descomponer y organizar el sistema para que los mdulospuedan ser desarrollados por separado CODIFICACIN, escribir el cdigo fuente de cada mdulo y realizarsobre ellos las pruebas necesarias INTEGRACIN, combinar todos los mdulos y probar el sistemacompleto antes de pasar a su explotacin MANTENIMIENTO, durante la explotacin es necesario realizar cambiosocasionales bien para corregir errores o para introducir mejoras, Se trata de aislar cada fase de las otras, lo que facilita la especializacinde los desarrolladores. Al final de cada fase se requiere un proceso derevisin para evitar que los errores se propaguen a fases posterioresprovocando la vuelta atrs.

    24

  • MODELO EN CASCADAAMPLIADO

    25

  • MODELO EN CASCADA

    Cada fase debe generar una informacin de salida precisa ysuficiente: DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es una especificacinprecisa y completa a partir de los requisitos establecidos por el cliente. DOCUMENTO DE DISEO DEL SOFTWARE (SDD),descripcin de laestructura global del sistema, especificacin de qu debe hacer cadauno de los mdulos y de cmo se combinan. CDIGO FUENTE, el programa debidamente comentado(documentacin interna). SISTEMA SOFTWARE, el ejecutable producto dela fase de integracin y ladocumentacin de las pruebas realizadas. DOCUMENTOS DE CAMBIOS, despus de cada modificacin realizada enla fase de mantenimiento: problema detectado y solucin adoptada

    26

  • MODELO EN V27

  • MODELO EN V AMPLIADO28

  • MODELO EN V Incluye fases similares a las del modelo en cascada

    pero de forma jerrquica. En horizontal serepresenta el avance en el desarrollo y en verticalel nivel de detalle.

    VERIFICACIN, comprobacin de que una partedel sistema cumple con sus especificaciones.

    VALIDACIN, comprobacin de que un elmentosatisface las necesidades del usuario identificadasdurante el anlisis.

    29

  • PROTOTIPOS En los modelos clsicos se insiste en las actividades de revisin deresultados al final de cada fase para evitar la vuelta atrs, que nose contempla de una forma organizada y resulta muy costosa.Estn orientados a una forma de desarrollo lineal. PROTOTIPO, es un sistema auxiliar que permite probarexperimentalmente soluciones parciales a los requisitos del sistema Para que el coste de desarrollo del prototipo sea bajo en relacinal del sistema final podemos:

    Limitar las funciones Limitar su capacidad Limitar su eficiencia Evitar limitaciones de diseo, utilizando un hardware ms potenteque el que ejecutar el sistema final Reducir la parte a desarrollar

    30

  • PROTOTIPOS RPIDOS

    Su finalidad es solo adquirir experiencia, no se aprovechan comoproducto (usar y tirar). Se denominan maquetas cuando su funcionalidado capacidad es muy limitada.

    El sistema final se codifica totalmente partiendo de cero, no seaprovecha el cdigo del prototipo

    Lo importante de estos prototipos es que se desarrollen en poco tiempo.

    31

  • PROTOTIPOS RPIDOS32

  • PROTOTIPOS EVOLUTIVOS

    En este caso se intenta aprovechar al mximo el cdigo del prototipo, ypara ello se emplea el mismo hardware/software del sistema final.

    Se realizan fases de anlisis y diseo parcial, que se van ampliando hastaconstruir el sistema final mediante adiciones sucesivas.

    Se puede considerar un modelo en cascada en bucle, de manera que encada iteracin se va avanzando en el desarrollo.

    HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se empleanlenguajes de 4 generacin, que son de alto nivel y de tipo declarativo.Tambin se emplean lenguajes de especificacin, como VDM y Z. Sidisponemos del compilador correspondiente podemos obtenerautomticamente el cdigo del prototipo.

    En el desarrollo de prototipos es clave la reutilizacin de software.

    33

  • PROTOTIPOS EVOLUTIVOS34

  • MODELO EN ESPIRAL

    Puede considerarse como un refinamiento del modelo evolutivo general queintroduce el anlisis de riesgo como elemento fundamental para guiar laevolucin del proceso de desarrollo. En la dimensin radial se representa el esfuerzo realizado en el desarrollo(siempre creciente) En cada iteracin 4 fases:

    PLANIFICACIN, determina que parte del desarrollo se abordar en ese ciclo. ANALISIS DE RIESGO, evaluar diferentes alternativas para esa parte del desarrolloseleccionando la ms ventajosa y tomando precauciones para evitar los posiblesinconvenientes. INGENIERA, las actividades de los modelos clsicos EVALUACIN, se analizan los resultados de la fase de ingeniera.

    35

  • MODELO EN ESPIRAL36

  • MANTENIMIENTO DEL SOFTWARE

    El mantenimiento no representa una actividad especfica, sinoque consiste en rehacer parte de las actividadescorrespondientes a las otras fases del desarrollo para introducircambios sobre una aplicacin ya en fase de explotacin.

    MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores queno fueron detectados en el desarrollo del producto.

    MANTENIMIENTO ADAPTATIVO, modificar una aplicacin paraadaptarla a las nuevas necesidades del entorno.

    MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versionesmejoradas del producto

    37

  • GESTIN DE CAMBIOS El mantenimiento supone la realizacin de una serie de cambios sucesivos Si afectan a la mayor parte del sistema se puede plantear como un nuevodesarrollo. Cada cambio debe ser documentado con:

    INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser propuesto por elcliente. INFORME DE CAMBIO, describe la solucin dada al problema y el cambiorealizado

    REINGENIERA, es necesaria cuando el desarrollo de una aplicacin no estdocumentado y se dispone solamente del cdigo. Se llama tambiningeniera inversa porque supone reconstruir y documentar las fases deanlisis y diseo llegando a la estructura modular de la aplicacin y lasdependencias entre mdulos y funciones. Estas actividades organizan ydocumentan un sistema deficiente.

    38

  • GARANTA DE CALIDAD Para evaluar la calidad son necesarias tcnicas de aplicacin de mtricas precisas tanto sobre los productos software como a sus procesos dedesarrollo. McCall propone un esquema basado en valoraciones a 3 niveles:

    FACTORES, valoracin significativa de la calidad en base a los criterios establecidos CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad MTRICAS, mediciones puntuales de determinadas caractersticas del producto.

    Entre los factores de calidad tenemos: CORRECCIN, grado en que cumple con las especificaciones FIABILIDAD, grado de ausencia de fallos EFICIENCIA, reilacin entre la cantidad de resultados y los recursos requeridos SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicacin MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario. FLEXIBILIDAD, facilidad para modificar el producto FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su correccin o fiabilidad TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos INTEROPERATIVIDAD, facilidad del producto para trabajar con otros

    39

  • PLAN DE GARANTA DE CALIDAD (SQAP)

    Es un documento formal para organizar el proceso de desarrollosoftware de manera que se asegure la calidad del producto final.Debe contemplar: Organizacin, direccin y seguimiento de los equipos de desarrollo Modelo de ciclo de vida a seguir, detallando fases y actividades Documentacin requerida, determinando contenido y guin de cadadocumento Revisiones y auditorias, para garantizar que las actividades y losdocumentos son correctos Organizacin de las pruebas, a distintos niveles Organizacin de la etapa de mantenimiento, determinando cmogestionar la realizacin de cambios

    40

  • REVISIONES

    Consiste en inspeccionar el resultado de una actividad para determinar si esaceptable o contiene defectos que han de ser subsanados. Las revisiones deben ser formalizadas y contempladas en el modelo de ciclode vida:

    Deben ser realizadas por un grupo de personas y no individualmente El grupo de be ser reducido Debe ser imparcial, nada que ver con los desarrolladores Se debe revisar el producto, pero no el productor ni el proceso de produccin Se debe establecer de antemano una lista formal de comprobaciones Se debe levantar acta de la reunin de revisin, recogiendo las decisiones tomadas

    41

  • PRUEBAS

    Consiste en hacer funcionar el producto o una parte de l y comprobar silos resultados son correctos.

    No permite garantizar la calidad del producto. En general no es posibleprobar un producto de forma exhaustiva, debido a su complejidad.

    42

  • GESTIN DE CONFIGURACIN CONFIGURACIN, disposicin de las partes que componen una cosa y le dan su peculiar figura. La CONFIGURACN SOFTWARE se refiere a la manera en que diversos elementos se combinan para construir un producto software. Se han de combinar todos los elementos que intervienen en el desarrollo:

    Documentos del desarrollo Cdigo fuente Programas, datos y resultado de las pruebas Manuales de usuario Documentos de mantenimiento, informes de problemas y cambios Prototipos intermedios Normas particulares del proyecto

    Dado que los elementos software van evolucionando a lo largo del desarrollo se requiere: Control de versiones, almacenar de forma organizada las sucesivas versiones de cada elemento de la configuracin. Control de cambios, garantizar que las diferentes configuraciones del software se componen de elementos compatibles entre s

    (lnea base).

    43

  • NORMAS Y ESTNDARES

    IEEE, Institute of Electrical and Electronics Engineer de USA [IEEE93] DoD, Departament od Defense de USA [DoD88] ESA, Agencia Europea del Espacio [ESA91] ISO, organismo internacional de normalizacin (International Standars

    Organization). En Espaa AENOR. METRICA-2, desarrollada por el Consejo Superior de Informtica del MAP.

    Se basa en la metodologa de anlisis y diseo de Yourdon/DeMarco.

    44