isi diapo 01
Post on 08-Jan-2016
244 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
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
top related