Tm01 el modelado en el desarrollo de software

IT Architect um IBM
24. Jan 2013
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
1 von 29

Más contenido relacionado

Was ist angesagt?

Introduccion a la Ingeniería de SoftwareIntroduccion a la Ingeniería de Software
Introduccion a la Ingeniería de SoftwareLia IS
Modelamiento softwareModelamiento software
Modelamiento softwareCristhian J. Oscco Huangal
Iso 12207Iso 12207
Iso 12207Yabizyta
Metodología RUPMetodología RUP
Metodología RUPJorge Cortés Alvarez
Pruebas de softwarePruebas de software
Pruebas de softwareMiluska Azabache Gonzales
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de SoftwareAndrés Felipe Montoya Ríos

Destacado

DiseñO Del Software E IngenieríA Del SoftwareDiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del Softwarelcastillo110
Modelamiento de softwareModelamiento de software
Modelamiento de softwaresairarcf
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREadark
Diseño de SoftwareDiseño de Software
Diseño de SoftwareAndrés Felipe Montoya Ríos
UML: CASOS DE USOUML: CASOS DE USO
UML: CASOS DE USOKatty Landacay
Calidad del softwareCalidad del software
Calidad del softwareReivaj Sagarv

Similar a Tm01 el modelado en el desarrollo de software

Trabajo de desarrollo desoftwareTrabajo de desarrollo desoftware
Trabajo de desarrollo desoftwarefrancisco alexander sanchez
Ingenieria de softwareIngenieria de software
Ingenieria de softwareFernando Alfonso Casas De la Torre
Omar,luis,danielOmar,luis,daniel
Omar,luis,danielGonzalo Daniel Romero Coreas
SELECCIÓN DE TECNICAS DE INGENIERIA DE SOFTWARE. SELECCIÓN DE TECNICAS DE INGENIERIA DE SOFTWARE.
SELECCIÓN DE TECNICAS DE INGENIERIA DE SOFTWARE. Cristhian Martinez
Paula guiaPaula guia
Paula guiatodosesplaya
Kevin guiaKevin guia
Kevin guiakeninmnk

Más de Julio Pari

Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Julio Pari
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesLinks kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesComandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
Indice General Tesis Sistemas UPCIndice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPCJulio Pari
Arquitectura Web FISI UNMSMArquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSMJulio Pari
Jelastic EnterpriseJelastic Enterprise
Jelastic EnterpriseJulio Pari

Tm01 el modelado en el desarrollo de software

Hinweis der Redaktion

  1. Veamos ahora cuales son las características genéricas del proceso de desarrollo de software, es decir aquellas características que se encontrarán presentes en cualquiera sea el proceso de desarrollo particular que adoptemos. Más adelante veremos en detalle distintos modelos específicos de procesos de desarrollo. La fase de Definición se ocupa del qué . Es decir, durante la Definición se intenta identificar qué información debe ser procesada, qué funcionalidad se desea, qué interfaces van a ser usadas, qué restricciones de diseño existen. Por lo tanto, se deberán identificar los requerimientos tanto de hardware como de software. Básicamente, durante la fase de Definición tendrán lugar tres actividades: la Ingeniería del Sistema, la captura y análisis de los requerimientos y la planificación del proyecto de software. La fase de Desarrollo se ocupa del cómo . Es decir, acá se debe definir cómo serán las estructuras de datos, cómo será la arquitectura del software, cómo se implementarán los detalles procedimentales, cómo serán las interfaces, cómo traducimos el diseño en código, cómo llevamos a cabo la prueba. Básicamente, tres tareas deberán ocurrir en esta fase: el diseño del software, la generación de código y la prueba del software. La fase de Mantenimiento o Soporte se ocupa de los cambios en el software. En esta fase se podrán llevar a cabo cuatro tipos de mantenimientos diferentes dependiendo del tipo de cambio: Mantenimiento Correctivo: cambiar el software para corregir errores. Mantenimiento Adaptativo: cambiar el software para adaptarlo a su entorno, por ejemplo cambios en la CPU, en el sistema operativo, en las políticas de la empresa, en las características externas del producto, etc.). Mantenimiento Perfectivo: cambiar el software para mejorarlo y obtener nuevos beneficios. Mantenimiento Preventivo: debido al deterioro producido en el software por los sucesivos cambios, se suele llevar a cabo un procesos de Reingeniería para producir un nuevo software con la misma funcionalidad pero de mejor calidad.
  2. Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
  3. Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
  4. Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."
  5. Un model o captur a una vista de un sistema del mundo real . Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle . Diagram a : una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos