Tema8 mantenimientoSistemasSoftware PDF

IngenieradelSo1wareII
Tema08.MantenimientodeSistemasSo1ware
PabloSnchezBarreiro
DPTO.DEMATEMTICAS,ESTADSTICAY COMPUTACIN
p.sanchez@unican.es
EstetemasepublicabajoLicencia: CreaOveCommonsBYNCSA3.0
Introducci on
Mantenimiento de Sistemas Software
Mantenimiento Software
Anlisis y Especificacin de Requisitos
Despliegue Mantenimiento Pruebas
Diseo Arquitectnico
Diseo Detallado
Implementacin
Pablo S anchez (MATESCO)
2 / 62
Introducci on
Importancia Mantenimiento software
Importancia del Mantenimiento Software

Identicado como una de las causas de la crisis del software [7].
3 / 62
Introducci on
Mantenimento software vs sistemas cl asicos
Permiten peque nas adaptaciones, pero su modicaci on es muy costosa. Suele implicar la construcci on de un nuevo sistema.
4 / 62
Introducci on
Mantenimento software vs sistemas cl asicos
El coste material de un producto software es despreciable. Un producto software es altamente modicable. Hasta el punto de poder llegar a ser un producto completamente nuevo (ej. Linux).
5 / 62
Introducci on
Costes hist oricos mantenimiento software
Listas de bugs y foros de soporte en productos comerciales . Actualizaciones de productos comerciales (ej. Windows Update, Acrobat Update)
Pablo S anchez (MATESCO) Mantenimiento Software 6 / 62
Introducci on
Importancia mantenimiento software
Adaptaci on al euro - Efecto 2000. Pantallas t actiles m oviles. Sistemas de taricaci on telefon a m ovil. Negocios de software libre basados en consultor a y mantenimiento (ej. openArchitecureWare http://www.openarchitectureware.org/). Actualmente, facilidad de mantenimiento, adaptabilidad y evoluci on son las caracter sticas m as importantes de la mayor a de los sistemas software.
7 / 62
Introducci on
En Ingenier a del Software no hay verdades universales
8 / 62
Introducci on
Objetivos del tema
Este no es el objetivo del tema
9 / 62
Introducci on
Objetivos del tema
Esto tampoco es el objetivo del tema
10 / 62
Introducci on
Objetivos del tema
Objetivos del tema
Objetivos
Aprender a analizar, planicar, ejecutar y gestionar acciones de mantenimiento software.
11 / 62
Deniciones
Deniciones mantenimiento software

Est andar IEEE 1219
La modicaci on de un producto software despu es de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno [9].
Est andar ISO/IEC 14764

Conjunto de actividades destinadas a proporcionar soporte econ omicamente rentable para un determinado producto software. Estas actividades se realizan tanto antes de la entrega del producto como despu es de la entrega del mismo. Las actividades previas a la entrega incluyen las actividades destinadas a planicar, anticipar y preparar actividades de mantenimiento posteriores. Las actividades posteriores a la entrega incluyen modicaciones del producto software, formaci on y asistencia al usuario [8].
Deniciones

Mantenibilidad (Maintainability)
Capacidad de un producto software de ser modicado. Estas modicaciones incluyen correcciones, mejoras, o adaptaciones a cambios en el entorno, los requisitos o las especicaciones funcionales [8].
Efecto domin o (ripple eect)

Un determinado cambio en un producto software se dice que genera un efecto domin o cuando a consecuencia del cambio debemos realizar cambios adicionales en el sistema.
Estabilidad de un dise no software

Capacidad de resistencia al efecto domin o que tendr a un sistema software derivado de dicho dise no cuando es modicado [13].
13 / 62
Deniciones

Sistema Heredado (Legacy Systems)
Un sistema heredado es un m etodo, tecnolog a, computador o aplicaci on antiguo que contin ua en uso porque a un satisface las necesidades de los usuarios, a un existiendo nuevas tecnolog as o m etodos m as ecientes disponibles (ej. aplicaciones COBOL en banca, Amadeus).
14 / 62
Tipos de mantenimiento software
Tipos de acciones de mantenimiento software

1
Correctivo: localiza y corrige defectos en un programa tras su entrega (ej. IVA al 15 %, agujeros de seguridad). Puede ser urgente o no urgente. Adaptativo: Modicaci on para adaptarse a un cambio en el entorno (ej. Euro, pantallas t actiles). Perfectivo: Modicaci on para detectar y corregir fallos latentes antes de que se conviertan en carencias [8]. Modicaci on para modicar o a nadir nuevas funcionalidades [11]. (Ej. rma digital en banca online). Preventivo: Modicaci on para detectar y corregir fallos latentes antes de que se conviertan en fallos operacionales [8]. Mejorar las propiedades del software [11]. (Ej. recodicar para aplicar patrones de dise no).
15 / 62
Tipos de mantenimiento software
Tipos de cambios en productos software
Anticipado: Un cambio se dice que es anticipado cuando ha sido previsto durante el desarrollo del sistema software y se han adoptado decisiones de dise no que permiten acomodar la variaci on (ej. uso de constantes, patr on estrategia, sistema de plugins de Eclipse). No anticipado: Todo aquel que no es anticipado. There is not silver bullet [4].
16 / 62
Principales Retos Mantenimiento Software

1 2
El efecto iceberg (o el efecto usillos/reforma). No es lo mismo producir que mantener:
Diferentes medidas de productividad entre desarrollo y mantenimiento:40 LDC desarrollado por 1 LDC mantenido [11].
17 / 62
C odigo heredado (legacy code)
Desarrollado con tecnolog as y t ecnicas anticuadas. No hay documentaci on. Si la hay, est a en notaci on Benito & Manolo, que ya no trabajan en la empresa. Reescribirlo entero no es factible (ej. Amadeus). El sistema no tiene porque estar bien dise nado, programado, ni haber sido desarrollado siguiendo un proceso de ingenier a.
Cambios en sistemas heredados/indebidamente documentados
19 / 62
Degradaci on calidad producto software

class Bill { float amountToBill; float calculateTotalCharge() { return amountToBill + (amountToBill * (16.0/100.0); } // calculateTotalCharge() } //Bill
20 / 62

class Bill { float amountToBill; float calculateTotalCharge(int clientType) { if (clientType == 0) { return amountToBill + (amountToBill * (16.0/100.0); } else { return amountToBill + (amountToBill * (6.0/100.0); } } // calculateTotalCharge() } //Bill
21 / 62

class Bill { float amountToBill; float calculateTotalCharge(int clientType, int productType) { if ((clientType == 0) && (productType == 0)) { return amountToBill + (amountToBill * (16.0/100.0); } else if ((clientType == 0) && (productType == 1)) { return amountToBill + (amountToBill * (4.5/100.0); } else if ((clientType == 1) && (productType == 0)) { return amountToBill + (amountToBill * (12.0/100.0); } else if ((clientType == 1) && (productType == 1)) { return amountToBill + (amountToBill * (4.5/100.0); } } // calculateTotalCharge() } //Bill
22 / 62
A nadiendo iva al total mensual

class Bill { float amountToBill; float calculateTotalCharge(int clientType, int productType) { float total, iva; if ((clientType == 0) && (productType == 0)) iva = amountToBill * (16.0/100.0); } else if ((clientType == 0) && (productType iva = amountToBill * (4.5/100.0); } else if ((clientType == 1) && (productType iva = amountToBill * (12.0/100.0); } else if ((clientType == 1) && (productType iva = amountToBill * (4.5/100.0); } total = amountToBill + iva; IvaLogger.addIva(iva); return total; } // calculateTotalCharge() } //Bill
Pablo S anchez (MATESCO) Mantenimiento Software
{ == 1)) { == 0)) { == 1)) {
23 / 62
Principales Problemas Mantenimiento Sw (Resumen)
1 2 3 4
Efectos domin o y efecto iceberg. Cambios ad-hoc, ausencia metodol ogica del cambio. Ausencia de documentaci on adecuada (decisiones de dise no). Degradaci on calidad del producto.
24 / 62
Soluci on para el mantenimiento software
Establecer procedimientos claramente denidos y estandarizados para el mantenimiento software, que se basen en t ecnicas y herramientas para el mantenimiento claramente denidas y validadas. Asignarle los recursos adecuados, tanto f sicos y econ omicos como humanos, Usar t ecnicas para control de calidad, tanto sobre el producto como sobre el proceso. Ejemplo: S3M (http://www.s3m.ca/).
25 / 62
Metodolog as para el mantenimiento software
Organizaci on del equipo humano
Organigrama del equipo humano
Atencin al usuario Gestor de peticiones
Equipo de diseo y desarrollo Equipo de Mantenimiento Gestor de Mantenimiento
Cliente
Planificador
26 / 62
Procesos de mantenimiento software
MANTEMA [12]
act [ Mantema ] Peticin de Mantenimiento error Severidad? Alta Atender directamente Baja Adaptacin tipo? otro
Mejora Evaluar y clasificar Si proceder? No Elaborar Informe
Evaluar, clasificar, encolar Encolar
Seleccionar primera tarea cola
Planificar
Analizar
Disear
Implementar
Probar
27 / 62
Lowel Jay Arthur [1]

Proceso de evoluci on de un sistema
Peticin de Cambio
Analisis de Impacto
Planificacin de Versiones
Implementacin de Cambios
Entrega del Sistema
Reparacin de defectos
Adaptacin de Plataforma
Perfeccionamiento del Sistema
Proceso de cambios de urgencia

Peticin de Cambio Analizar cdigo fuente Parchear cdigo fuente Entregar sistema parcheado
28 / 62
Gesti on de petici on de cambio en Bugzilla

New bug from a user with canconfirm or a product without UNCONFIRMED state
UNCONFIRMED
Bug confirmed or receives enough votes Developer takes possession Bug is reopened, was never confirmed
NEW
Ownership is changed
Developer takes possession
Development is finished with bug
Possible resolutions: FIXED DUPLICATE WONTFIX WORKSFORME INVALID
ASSIGNED
Development is finished with bug
Developer takes possession Issue is resolved QA not satisfied with solution
RESOLVED
Bug is closed
QA verifies solution worked
REOPEN
Bug is reopened
VERIFIED
Bug is reopened Bug is closed
CLOSED
29 / 62
Documentaci on de cambios software
Plantillas para documentaci on cambios software

Tomada de Basili et al [2]
1
Descripci on del cambio.

1 2 3 4 5 6 7 8 Localizaci on. Subsistemas afectados. M odulos afectados. Entradas/salidas afectadas. Tama no. L neas de c odigo a nadidas, modicadas y eliminadas. M odulos examinados, a nadidos, modicados y eliminados. Tipo del cambio (Correctivo Perfectivo Preventivo Adaptativo)
Descripci on del problema.

1 Descripci on del error. Causa y origen del error. Momento del proceso en que se produjo el error. 2 Dicultad. Causas que dicultaron la modicaci on. Actividad m as dif cil relacionada con la modicaci on. 3 4 Cantidad de esfuerzo desperdiciado. Decisiones que se podr an haber tomado para disminuir la dicultad de los errores.
Descripci on del proceso de cambio.

1 2 3 4 5 Esfuerzo dedicado. Experiencia del personal de mantenimiento Tiempo del personal de mantenimiento trabajando en el sistema. Tiempo del personal trabajando en el dominio. Artefactos relacionados con el cambio. Mantenimiento Software
30 / 62
Documentaci on de cambios software
Plantillas para documentaci on cambios software

Plantilla aleatoria encontrada en internet (moodle). Plantilla modelo de bugzilla:
https://landfill.bugzilla.org/bugzilla-3.6-branch/show_bug.cgi?id=1
31 / 62
T ecnicas de mantenimiento
Introducci on
Soluciones t ecnicas para el problema de mantenimiento

1
Ingenier a Inversa: Reconstruir el proceso de ingenier a de un producto a partir de ciertos artefactos de dicho producto. Reingenier a: Examen y modicaci on de un sistema para reconstruirlo en una nueva forma. Puede precisar de un proceso de ingenier a inversa para reconstruir el proceso de ingenier a del producto. Reestructuraci on: Modicaci on del software para hacerlo m as f acil de entender y cambiar o menos susceptible de incluir errores en cambios posteriores. Transformaciones: Manipulaci on, por medio de transformaciones autom aticas ejecutadas por un computador, del c odigo o modelo de un sistema para a nadirle/modicarle/eliminarle elementos. (ej. pasar un sistema a distribuido).
32 / 62
Introducci on
Soluciones t ecnicas para el problema de mantenimiento
33 / 62
Ingenier a Inversa
Qu e es Ingenier a Inversa?
34 / 62
Ingenier a Inversa
Qu e es Ingenier a Inversa?
35 / 62
Ingenier a Inversa
Ingenier a Inversa de c odigo Java a UML

class Persona { String nombre; int edad; Set<Telefono> telefonos; String getName() { ... } ... } class Profesor extends Persona { String centro; } class Telefono { int numero; String operador; int codigoInternacional; }
36 / 62
Ingenier a Inversa
Ingenier a Inversa de c odigo Java a UML
class [
ReverseEngineering ]
Persona +nombre : String +edad : Integer +telefonos 0..*
Telefono +numero : int +operador : String +codigoInternacional : int
Profesor +centro : String
37 / 62
Ingenier a Inversa
Ingenier a Inversa de bases de datos relacionales
Region rname salesman_name id
Customer cid cname address phone rname id ref
Sales pnum cid volume
Product pnum pname id
38 / 62
Ingenier a Inversa

1 2
Por cada tabla sin referencias a otras tablas, creamos una entidad. Para las entidades creadas, copiamos atributos y marcamos claves primarias. Marcamos las tablas como procesadas. Por cada tabla con referencias externas, creamos una entidad. Para las entidades creadas, copiamos atributos y marcamos claves primarias. Por cada clave externa, creamos una relaci on entre la entidad creada y la referenciada. Para dicha relaci on, el extremo de tabla referenciada, tendr a cardinalidad 1, salvo restricci on expresa. Para dicha relaci on, el extremo de la entidad creada, tendr a cardinalidad 0.., salvo restricci on expresa. Si una entidad tiene: (1) su clave primaria formada por la uni on de las claves primarias de tablas con las cuales se relaciona; y (2) los extremos de las relaciones con las otras entidades tiene como cardinalidad superior 1, convertir dicha entidad en una relaci on n a m entre entidades. Copiar los atributos de la entidad a atributos de la relaci on.
Mantenimiento Software 39 / 62
3 4 5
Ingenier a Inversa
rname
id
cid cname phone
pnum
pname
Region
Customer
Product id
salesman_name
rname address
volume
40 / 62
Reestructuraci on
Reestructuraci on: Refactorings

Refactorizaci on
Proceso de cambio de un sistema software de forma que su comprtamiento externo no se vea afectado pero que mejora su estructura interna (ej. atributos relacionados a clase).
Malos olores (bad smells)

Indicios sobre potenciales problemas en el c odigo (ej. c odigo replicado, mismo m etodo en varias subclases).
41 / 62
Reestructuraci on
Esquema de una refactorizaci on
1 2 3 4 5 6
Nombre S ntomas Causas Refactorizaciones propuestas Benecios esperados Efectos colaterales y contraindicaciones
42 / 62
Reestructuraci on
Refactorizaciones m as Populares [6]
1 2 3 4 5 6
Pull Up Method. Move Method. Add Parameter. Move Field. Rename Method. Rename Field.
43 / 62
Reestructuraci on
Pull Up Method
Descripci on
Existen m etodos cuasi-id enticos en las subclases
class [
Refactorings ] UniversityMember
class [
Refactorings ] UniversityMember
Student +setCourse( course : Course )
Teacher +setCourse( course : Course )
+setCourse( course : Course )
Student
Teacher
44 / 62
Reestructuraci on
Move Method
Descripci on
Un m etodo de una clase A es m as usado en una clase B que en la clase donde est a denido.
class [ Course
MoveMethod ] +students 0..* Student +isInCourse( course : Course )
class [
MoveMethod ] Course +students Student 0..*
+isInCourse( student : Student )
45 / 62
Reestructuraci on
Add Parameter
Descripci on
A method needs more information from its caller.
class AP(left) [
AP(left) ] Student
class AP(right) [
AP(right) ]
+getContactData()
Student +getContactData( faculty : Faculty )
OJO ! puede crear listas interminables de argumentos
46 / 62
Reestructuraci on
Introduce Parameter Object

Descripci on
Existen grupos de par ametros que est an naturalmente relacionados
class [
IPO(left) ] Student
class [
IPO(right) ] Student Date +day : int +month : int +year : int
+bookSession( day : int, month : int, year : int ) +notifyExam( day : int, month : int, year : int )
+bookSession( date : Date ) +notifyExam( date : Date )
47 / 62
Reestructuraci on
Move Field
Descripci on
Un atributo de una clase A es m as usado en una clase B que en la clase donde est a denido.
class [
MoveField(left) ] ProductType
class [
MoveField(right) ] ProductType +vat : int
Product +vat : int
+kind 1
Product
+kind 1
48 / 62
Reestructuraci on
Rename Field/Method
Descripci on
El nombre de un atributo o m etodo no es signicativo
class [
MoveField(right) ] Prd PrdT +c : int
class [
MoveField(right) ] ProductType +vat : int
+t 1
Product
+kind 1
49 / 62
Reestructuraci on
Replace Magic Number with Symbolic Constant

Descripci on
Tenemos una constante num erica con un signicado bien denido
double calculateTotalCharge() { return this.totalAmount + (this.totalAmount*16.0/100.0); }
refactors to
static final double NORMAL_VAT = 16.0; double calculateTotalCharge() { return this.totalAmount + (this.totalAmount*NORMAL_VAT/100.0); }
50 / 62
Reestructuraci on
Replace Type Code with State/Strategy

Descripci on
Una clase tiene un atributo que indica tipo y que afecta al comportamiento de la clase
class [
TypeBased ] Product ProductType +vat : float
class [
Strategy ] Product +vat : float +calculateTotalCharge()
+kind 1
+calculateTotalCharge()
NormalProduct +calculateTotalCharge()
ReduceVATProduct +calculateTotalCharge()
BasicProduct +calculateTotalCharge()
51 / 62
Detecci on de clones
Detecci on de c odigo replicado

Problema del c odigo replicado
@#& Happiness
Base Functionality Access Control Fault Tolerance v 2 . 0 Encryption

Sadness
M o dul eA
M o dul eB
M o dul eC
Module D
M o dul eE
52 / 62
Detecci on de c odigo replicado (Baxter et al [3])

Fragmento 1 en mdulo A Fragmento 2 en mdulo B void Insertar(lista l, int info) { int cont; boolean enc; void Anadir(int e, lista l) { Elemento e; int i:=1; boolean enc:=false; cont:=1; while (not enc) { enc:=false; if l[i].ocupado then while (enc==false) { i++; e:=l[cont]; else enc=true; if (not e.ocupado) then { } e.ocupado:=true; l.info:=e; e.info:=info; l.ocupado:=true; l[cont]:=e; } enc:=true; } else cont:=cont+1; } }
53 / 62
... if a=b then for i=1 to f(n) aux = aux + f(i, i-1) end for a=0 end if ....
54 / 62

Clones= Para cada s Subrboles Si s PesoMnimo entonces TablaHash = TablaHash {s} Para cada (s1, s2) que estn en la misma entrada de TablaHash Si Similitud(s1,s2)UmbralDeSimilitud entonces Para cada s Subrboles(s1) Si s Clones entonces Clones=Clones - {s} Para cada s Subrboles(s2) Si s Clones entonces Clones=Clones - {s} Clones=Clones {s1} {s2}
55 / 62
M etricas para mantenimiento software
M etricas para dise nos software orientados a objetos [5]

Weigthed Method per Class (WMC) Depth of Inheritance Tree (DIT) Number of Children (NOC) Coupling Between Objects (CBO) Response For a Class (RFC) Lack of Cohesion in Methods (LCOM) WMC = n i =1 ci maximum lenght to the root of the tree number of inmediate subclasses of a class number of tother classes used by a class RFC = M + n i =1 Ri LCOM = P Q
Regla informal
Un sistema ser a m as mantenible cuanto mayor cohesi on tenga y menor sea su acoplamiento [10].
56 / 62
M etricas para mantenimiento software
M etricas para dise nos software orientados a objetos [5]
class [ OBSComponentClassesLarge ] System +register() +unregister() 1..* +clerks +packOrder() ShoppingCart Customer 0..* +name : String +customers +creditCard : String +customer +addItem( book : Book, quantity : Integer ) +removeItem( book : Book ) +checkOut() +creditNotification( ok : Boolean ) +deliveryNotification( ok : Boolean ) Book 1..* +books +author : String +title : String Clerk SelectedBook +quantity : Integer
0..* +books
57 / 62
Conclusiones
Conclusiones
Importancia del mantenimiento software y diferencia con sistemas cl asicos. Denci on de mantenimiento software. Tipos de mantenimiento y cambio. Importancia y problemas de los sistemas heredados. Organizaci on y gesti on del mantenimiento. Concepto y t ecnicas de Ingenier a Inversa. Concepto y t ecnicas de Refactorizaci on. M etricas para mantenimiento.
3 4 5 6 7
58 / 62
Bibliograf a
Referencias I
Lowell Jay Arthur. Software Evolution: A Software Maintenance Challenge. John Wiley & Sons, February 1988. Victor Basili, Lionel Briand, Steven Condon, Yong-Mi Kim, Walc elio L. Melo, and Jon D. Valett. Understanding and Predicting the Process of Software Maintenance Release. In Proc. of the 18th Int. Conference on Software Engineering (ICSE), pages 464474, Berlin, Germany, March 1996. Ira D. Baxter, Andrew Yahin, Leonardo Moura, Marcelo SantAnna, and Lorraine Bier. Clone Detection Using Abstract Syntax Trees. In Proc. of the Int. Conference on Software Maintenance (ICSM), pages 368377, Bethesda (Maryland, USA), November 1998.
Bibliograf a
Referencias II
Frederick P. Brooks. No Silver Bullet - Essence and Accidents of Software Engineering. IEEE Computer, 20(4):1019, April 1987. Shyam R. Chidamber and Chris F. Kemerer. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, 20(6):476493, June 1994. Steve Counsell, Youssef Hassoun, George Loizou, and Rajaa Najjar. Common Refactorings, a Dependency Graph and Some Code Smells: an Empirical Study of Java OSS. In Guilherme Horta Travassos, Jos e Carlos Maldonado, and Claes Wohlin, editors, Proc. of the Int. Symposium on Empirical Software Engineering (ISESE), pages 288296, Rio de Janeiro (Brazil), September 2006.
Bibliograf a
Referencias III
Edsger W. Dijkstra. The humble programmer. Communications of the ACM, 15(10):859866, October 1972. ISO/IEC/IEEE. Software engineering software life cycle processes maintenance. Technical Report International Standard ISO/IEC 14764:2006, IEEE Std 14764-2006, September 2006. IEEE (The Institute of Electrical and Electronics Engineers). Standard for software maintenance. Technical Report IEEE Std 1219-1993, December 1992. David L. Parnas. On the Criteria to be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12):10531058, 1972.
61 / 62
Bibliograf a
Referencias IV
Mario Piattini, Jos e Villalba, Francisco Ruiz, Teresa Bastanchury, Macario Polo, Miguel Angel Mart nez, and C esar Nistal. Mantenimiento del Software. Modelos, T ecnicas y M etodos para la Gesti on del Cambio. Macario Polo, Mario Piattini, Francisco Ruiz, and Coral Calero. MANTEMA: A Complete Rigorous Methodology for Supporting Maintenance Based On The ISO/IEC 12207 Standard. In Proc. of the 3rd European Conference on Software Maintenance and Reengineering (CSMR), pages 178181, Amsterdam (The Netherlands), March 1999. Stephen S. Yau and James S. Collofello. Design Stability Measures for Software Maintenance. IEEE Transactions on Software Engineering, 11(9):849856, October 1985.

Tema8 mantenimientoSistemasSoftware PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tema8 mantenimientoSistemasSoftware PDF

Caricato da

Copyright:

Formati disponibili

IngenieradelSo1wareII

Mantenimiento de Sistemas Software

Anlisis y Especificacin de Requisitos

Despliegue Mantenimiento Pruebas

Pablo S anchez (MATESCO)

Importancia Mantenimiento software

Importancia del Mantenimiento Software

Pablo S anchez (MATESCO)

Importancia Mantenimiento software

Mantenimento software vs sistemas cl asicos

Pablo S anchez (MATESCO)

Importancia Mantenimiento software

Mantenimento software vs sistemas cl asicos

Pablo S anchez (MATESCO)

Importancia Mantenimiento software

Costes hist oricos mantenimiento software

Importancia Mantenimiento software

Importancia mantenimiento software

Pablo S anchez (MATESCO)

Importancia Mantenimiento software

En Ingenier a del Software no hay verdades universales

Pablo S anchez (MATESCO)

Objetivos del tema

Este no es el objetivo del tema

Pablo S anchez (MATESCO)

Objetivos del tema

Esto tampoco es el objetivo del tema

Pablo S anchez (MATESCO)

Objetivos del tema

Objetivos del tema

Pablo S anchez (MATESCO)

Deniciones mantenimiento software

Est andar ISO/IEC 14764

Deniciones mantenimiento software

Efecto domin o (ripple eect)

Estabilidad de un dise no software

Pablo S anchez (MATESCO)

Deniciones mantenimiento software

Pablo S anchez (MATESCO)

Tipos de mantenimiento software

Tipos de acciones de mantenimiento software

Pablo S anchez (MATESCO)

Tipos de mantenimiento software

Tipos de cambios en productos software

Pablo S anchez (MATESCO)

Principales Retos Mantenimiento Software

Principales Retos Mantenimiento Software

El efecto iceberg (o el efecto usillos/reforma). No es lo mismo producir que mantener:

Pablo S anchez (MATESCO)

Principales Retos Mantenimiento Software

C odigo heredado (legacy code)

Principales Retos Mantenimiento Software

Cambios en sistemas heredados/indebidamente documentados

Pablo S anchez (MATESCO)

Principales Retos Mantenimiento Software

Degradaci on calidad producto software

Pablo S anchez (MATESCO)

Principales Retos Mantenimiento Software

Degradaci on calidad producto software

Pablo S anchez (MATESCO)

Principales Retos Mantenimiento Software

Degradaci on calidad producto software

Pablo S anchez (MATESCO)