UNIVERSIDAD PÚBLICA DE EL ALTO

CH
NOMBRE: ROSLIN MIENKA CHOQUE COARITE
PARALELO: 5to “B”
MATERIA: GABINETE DE AUDITORIA DE SISTEMAS INFORMATICOS
DOCENTE: LIC. SUGAR CARLOS FLORES CONDORI
GESTION: 2022

METODOLOGIA CRYSTAL CLEAR

1. CARACTERÍSTICAS
Las características principales de las metodologías orientadas a objetos

 Ofrecen una forma de pensar más que una forma de programar.

 Reducen la complejidad en el diseño de software.
 Permiten atacar los errores en el transcurso del diseño y
no durante la implementación, donde el costo de reparación es
bastante mayor.

2. MARCO DE TRABAJO
La metodología OMT emplea tres clases de modelos para describir el
sistema:

 Modelo de objetos. Describe la estructura estática de los objetos del

sistema. El modelo de objetos proporciona el entorno esencial en el
cual se pueden situar el modelo dinámico y el modelo funcional. El
objetivo es capturar aquellos conceptos del mundo real que sean
importantes para la aplicación. Se representa mediante
diagramas de objetos.
 Modelo dinámico. Describe los aspectos de un sistema que
tratan de la temporización y secuencia de operaciones y la
organización de sucesos y estados. Captura el control, aquel aspecto
de un sistema que describe las secuencias de operaciones que se
producen sin tener en cuenta lo que hagan las operaciones, aquello a
lo que afecten o la forma en que están implementadas. Se representa
gráficamente mediante diagramas de estado
 Modelo funcional. Describe las transformaciones de valores de datos
(funciones, correspondencias, restricciones y dependencias
funcionales) que ocurren dentro del sistema. Captura lo que hace el
sistema, independientemente de cuando se haga o de la forma en que
se haga. Se representa mediante diagramas de flujo de datos.

3. ACCIONES Y TAREAS POR ACTIVIDAD

Las fases que conforman a la metodología OMT son:
 Análisis. El analista construye un modelo del dominio del problema,
mostrando
sus propiedades más importantes. El modelo de análisis es una
abstracción
resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma
en que se hará. Los elementos del modelo deben ser conceptos del dominio de
aplicación y no conceptos informáticos tales como estructuras de datos. Un buen
modelo debe poder ser entendido y criticado por expertos en el dominio
del
problema que no tengan conocimientos informáticos.
 Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel
sobre
la arquitectura del mismo. Durante esta fase el sistema se organiza en
subsistemas basándose tanto en la estructura del análisis como en la arquitectura
propuesta. Se selecciona una estrategia para afrontar el problema.
 Diseño de objetos. El diseñador de objetos construye un modelo
de diseño
basándose en el modelo de análisis, pero incorporando detalles de
implementación. El diseño de objetos se centra en las estructuras de
datos
y algoritmos que son necesarios para implementar cada clase. OMT describe la
forma en que el diseño puede ser implementado en distintos lenguajes.
 Implementación. Las clases de objetos y relaciones desarrolladas
durante el
análisis de objetos se traducen finalmente a una implementación
concreta.
Durante la fase de implementación es importante tener en cuenta los principios de
la ingeniería del software de forma que la correspondencia con el diseño
sea
directa y el sistema implementado sea flexible y extensib
Las fases que conforman a la metodología OMT son:

 Análisis. El analista construye un modelo del dominio del problema,

mostrando sus propiedades más importantes. El modelo de
análisis es una abstracción resumida y precisa de lo que debe de
hacer el sistema deseado y no de la forma en que se hará. Los
elementos del modelo deben ser conceptos del dominio de aplicación y
no conceptos informáticos tales como estructuras de datos. Un buen
modelo debe poder ser entendido y criticado por expertos en
el dominio del problema que no tengan conocimientos informáticos.
 Diseño del sistema. El diseñador del sistema toma decisiones de alto
nivel sobre la arquitectura del mismo. Durante esta fase el
sistema se organiza en subsistemas basándose tanto en la
estructura del análisis como en la arquitectura propuesta. Se
selecciona una estrategia para afrontar el problema.
 Diseño de objetos. El diseñador de objetos construye un
modelo de diseño basándose en el modelo de análisis, pero
 incorporando detalles de implementación. El diseño de objetos
se centra en las estructuras de datos y algoritmos que son
necesarios para implementar cada clase. OMT describe la forma en
que el diseño puede ser implementado en distintos lenguajes.
 Implementación. Las clases de objetos y relaciones
desarrolladas durante el análisis de objetos se traducen
finalmente a una implementación concreta. Durante la fase de
implementación es importante tener en cuenta los principios de la
ingeniería del software de forma que la correspondencia con el
diseño sea directa y el sistema implementado sea flexible y extensible.

4. VENTAJAS Y DESVENTAJAS

4.1. Ventajas
 Proporciona una serie de pasos perfectamente definidos al
desarrollador.
 Tratamiento especial de la herencia.
 Facilita el mantenimiento dada la gran cantidad de información que
se genera en el análisis
 Es fuerte en el análisis
4.2. Desventajas
 Hay pocos métodos para encontrar inconsistencias en los modelos.
 Interacción de objetos no soportada explícitamente en
ninguna herramienta gráfica.
 Al ser un análisis iterativo es difícil de saber cuándo comenzar con
el diseño.
 Es débil en el diseño

Metodología Desarrollo Conducido por Características (DCC)

1. CARACTERISTICAS
 Las características se pueden organizar en un agrupamiento
jerárquico relacionado con el negocio.
 Como las características son bloques pequeños de funcionalidad
entregable, los usuarios las describen con mayor facilidad,
pueden entender cómo éstas se relacionan con otras con mayor
rapidez, y pueden revisarlas de mejor manera en búsqueda de
ambigüedades, errores u omisiones.
 Una característica es el incremento de software entregable, el equipo
desarrolla características operativas cada dos semanas.
 Debido a que las características son pequeñas, sus diseños y
representaciones de código son más fáciles de inspeccionar de
manera efectiva.
2. MARCO DE TRABAJO
El desarrollo conducido por características es un modelo de proceso
práctico para la ingeniería de software orientada a objetos debido a que las
características se pueden organizar en un grupos relacionado con el
negocio, y este busca que el equipo de proyecto desarrolle las
características o funciones que son evaluadas por el cliente, las cuales
pueden ser implementadas en un corto tiempo de dos semanas o menos, es
un modelo que se enfoca más hacia la parte de la dirección y gestión de
proyectos

3. ACCIONES Y TAREAS POR ACTIVIDAD

El DCC concede una mayor importancia a las directrices y técnicas de
la gestión del proyecto que muchos otros métodos ágiles, ya que enfatiza
cuestiones de calidad y define claramente entregas tangibles y formas de
evaluación del progreso. Se encuentra definido por cinco fases o actividades
que se muestran a continuación:
 El desarrollo de un modelo general: En una fase ya se tiene el
dominio, el contexto, y los requerimientos del sistema a construir. En
este momento se posee información básica de las especificaciones
funcionales.
 La construcción de la lista de características los ensayos,
modelos de objetos y documentación de requerimientos
proporcionan la base para construir una amplia lista de características
Las funciones se agrupan conforme a diversas actividades en áreas de
dominio específicas y la lista de características es revisada por los
usuarios para asegurar su validez y exhaustividad.
 El diseño y la construcción por características, se selecciona las
características a desarrollar y los equipos dispuestos por cada
una de ellas. Luego se procede iterativamente hasta que se
producen las características seleccionadas.
 Diseño por características.
 Construcción por características.

4. VENTAJAS Y DESVENTAJAS
4.1. Ventajas:
 El tipo de cambio está bloqueado. DCC fija el tipo de cambio en
el CSO. Cuando realiza una transacción y acepta un DCC, la tasa
de cambio utilizada es la tasa de mercado actual (más la marca
para el vendedor y / o proveedor de servicios). Los tipos de cambio
de las tarjetas de crédito no se bloquean hasta que se procesa la
transacción, generalmente días después. Si el tipo de cambio DCC
 (incluido el margen de beneficio) es mejor que el tipo de cambio
cuando se procesa la transacción, podría ahorrar dinero.
 Tienes transparencia en tiempo real. Si elige DCC, la conversión
de moneda se realiza justo delante de sus ojos y sabe el tipo de
cambio que está pagando de inmediato. Las compañías de tarjetas
de crédito no están obligadas a revelar el tipo de cambio.
 Facilita la comparación de precios. Dado que la mayoría de las
personas comprenden mejor su propia moneda, es probable que la
comparación de precios sea más fácil con DCC.
4.2. Desventaja:
 Marcado desconocido. Si bien los vendedores de DCC están
obligados a revelar el tipo de cambio, no están obligados a revelar
la marca por encima del tipo de cambio actual del mercado. Si no
tiene una aplicación de cambio de moneda, es posible que no sepa
cuánto está pagando por encima de la tasa de mercado.
 Las tarifas de transacción permanecerán vigentes. Las
personas a menudo creen que al elegir un DCC en el CSO, no
tendrán que pagar la tarifa de transacción extranjera cobrada con
su tarjeta de crédito. Esto no es verdad. La mayoría de las tarjetas
de crédito cobran una tarifa por todas las transacciones que no
tienen nada que ver con la conversión de la moneda.
 La tarifa por transacciones extranjeras puede ser más alta. Si
la tasa de conversión de DCC es más alta que la tasa disponible a
través de su tarjeta de crédito, su tarifa de transacción extranjera
también será más alta.

METODOLOGÍA SCRUM

1. CARACTERÍSTICAS:
Aquí vamos a encontrar una serie de características, de las que se destacan
algunas, como, por ejemplo:
 La colaboración, ya que es una de las mejores cosas que tiene Scrum
es que se fomenta mucho la colaboración entre los miembros del
equipo de desarrollo, entre el cliente y el equipo.
 El auto organización, porque Scrum está muy enfocado a que los
equipos sean capaces de organizarse, de auto gestionarse, de saber
llevar la carga de trabajo en todo momento, de que se tenga el control
del tiempo, etc. Por todo eso, los equipos son los que se marcan sus
ritmos y el desarrollo es progresivo, ya que se va avanzando a medida
que va pasando el tiempo y el equipo va adquiriendo madurez y se
procede a un valor incremental.
  La priorización, debido a que existen prioridades y se establecen
criterios para saber qué trabajos son los que lo más importante y son
los primeros que hay que desarrollar. Scrum es una metodología muy
abierta, flexible y que se adapta a las necesidades de los clientes en
cada momento. Si aparece algo urgente, se le puede asignar una
prioridad y el equipo puede ponerse a trabajar de forma
inmediata.

2. MARCO DE TRABAJO:

Entre las diferentes metodologías de un proyecto, Scrum es un método para trabajar

en
equipo a partir de iteraciones o Sprints. Así pues, Scrum es una metodología ágil,
por lo
que su objetivo será controlar y planificar proyectos con un gran volumen de
cambios de
última hora, en donde la incertidumbre sea elevada.
Se suele planificar por semanas. Al final de cada Sprint o iteración, se va revisando
el
trabajo validado de la anterior semana. En función de esto, se priorizan y planifican
las
actividades en las que invertiremos nuestros recursos en el siguiente Sprint.
La metodología Scrum se centra en ajustar sus resultados y responder a las
exigencias
reales y exactas del cliente. De ahí, que se vaya revisando cada entregable, ya que
los
requerimientos van variando a corto plazo. El tiempo mínimo para un Sprint es de
una
semana y el máximo es de cuatro semanas
Entre las diferentes metodologías de un proyecto, Scrum es un método para
trabajar en equipo a partir de iteraciones o Sprints. Así pues, Scrum es una
metodología ágil, por lo que su objetivo será controlar y planificar proyectos
con un gran volumen de cambios de última hora, en donde la incertidumbre
sea elevada.

Se suele planificar por semanas. Al final de cada Sprint o iteración, se va

revisando el trabajo validado de la anterior semana. En función de esto, se
priorizan y planifican las actividades en las que invertiremos nuestros
recursos en el siguiente Sprint.

La metodología Scrum se centra en ajustar sus resultados y responder a las

exigencias reales y exactas del cliente. De ahí, que se vaya revisando cada
entregable, ya que los requerimientos van variando a corto plazo. El tiempo
mínimo para un Sprint es de una semana y el máximo es de cuatro semanas

3. ACCIONES Y TAREAS POR ACTIVIDAD

El desarrollo de producto tiene un ciclo de vida en la metodología Scrum.
Estas son fases en las que se divide un proceso Scrum:
 a. ¿Qué y quién? El producto que queremos conseguir una vez
terminemos el Sprint, y los roles de equipo con sus tareas asignadas.
b. ¿Dónde y cuándo? El plazo y el contenido del Sprint.
c. ¿Por qué y cómo? Las distintas herramientas para aplicar esta
metodología ágil.

Cada Sprint puede tener una serie de eventos o etapas. Los más comunes
son:

a. Reunión para la planificación del Sprint. En ella, se divide el tiempo de

duración del Sprint, así como el objetivo y entregable del mismo.
Además, el equipo de desarrollo deberá saber cómo realizarlo. Muy
parecido a lo que llamamos reunión de Kick off.
b. Scrum diario. Se basa en poner en común y sincronizar actividades
para elaborar el plan del día

4. VENTAJAS Y DESVENTAJAS

4.1. Ventajas:
Scrum es muy fácil de aprender: los roles, hitos y herramientas son
claros y tienen un objetivo por lo que es un método muy relacionado con
nuestra manera diaria de trabajar.
 El cliente puede comenzar a usar el producto rápidamente.
 Se agiliza el proceso, ya que la entrega de valor es muy frecuente.
 Menor probabilidad de sorpresas o imprevistos, porque el
cliente está viendo frecuentemente el proyecto.

4.2. Desventajas:

Aunque Scrum sea fácil de aprender, es muy difícil implementarlo. Esto supone
una predisposición y un cambio de cultura de la organización que debe ir desde
los altos mandos hasta los clientes.
 La necesidad de tener equipos multidisciplinares puede ser un
problema, ya
que es difícil encontrar personas que sean capaces de hacer todo el trabajo de un
equipo.
 El equipo puede tender a realizar el camino más corto para conseguir el
objetivo
de un sprint, el cual no siempre ofrece resultados de calidad.
 Aunque Scrum sea fácil de aprender, es muy difícil implementarlo. Esto
supone una predisposición y un cambio de cultura de la organización que
debe ir desde los altos mandos hasta los clientes.
  La necesidad de tener equipos multidisciplinares puede ser un
problema, ya que es difícil encontrar personas que sean capaces de
hacer todo el trabajo de un equipo.
 El equipo puede tender a realizar el camino más corto para conseguir el
objetivo de un sprint, el cual no siempre ofrece resultados de calidad.

METODOLOGÍA FEATURE DRIVEN DEVELOPMENT (FDD)

1. CARACTERISTICAS
 Se preocupa por la calidad, por lo que incluye un
monitoreo constante del proyecto.
 Ayuda a contrarrestar situaciones como el exceso en el presupuesto,
fallas en el programa o el hecho de entregar menos de lo deseado.
 Propone tener etapas de cierre cada dos semanas. Se
obtienen resultados periódicos y tangibles.
 Se basa en un proceso iterativo con iteraciones cortas que producen
un software funcional que el cliente y la dirección de la empresa
pueden ver y monitorear.
 Define claramente entregas tangibles y formas de evaluación del
progreso del proyecto.
 No hace énfasis en la obtención de los requerimientos sino en cómo se
realizan las fases de diseño y construcción.

2. MARCO DE TRABAJO
 El FDD tiene cinco procesos. Los primeros tres se hacen al principio
del proyecto
 Desarrollar un modelo global: Al inicio del desarrollo se construye un
modelo teniendo en cuenta la visión, el contesto y los requisitos que
debe tener el sistema a construir. Este modelo se divide en áreas que
se analizan detalladamente. Se construye un diagrama de clases por
cada área.
 Construir una lista de los rasgos: Se elabora una lista que
resuma las funcionalidades que debe tener el sistema, cuya lista es
evaluada por el cliente.
 Cada funcionalidad de la lista se divide en funcionalidades más
pequeñas para un mejor entendimiento del sistema.
  Planear por rasgo: Se procede a ordenar los conjuntos de
funcionalidades conforme a su prioridad y dependencia, y se asigna a
los programadores jefes.
 Diseñar por rasgo: Se selecciona un conjunto de funcionalidades de la
lista. Se procede a diseñar y construir la funcionalidad
mediante un proceso iterativo, decidiendo que funcionalidad se van
a realizar en cada iteración. Este proceso iterativo incluye inspección
de diseño, codificación, pruebas unitarias, integración e inspección de
código

3. ACCIONES Y TAREAS POR ACTIVIDAD

El equipo de trabajo está estructurado en jerarquías, siempre debe
haber un jefe de proyecto, y aunque es un proceso considerado ligero
también incluye documentación (la mínima necesaria para que algún
nuevo integrante pueda entender el desarrollo de inmediato).
 Director del Proyecto: Líder administrativo y financiero del proyecto.
Protege al equipo de situaciones externas.
 Arquitecto jefe: Realiza el diseño global del sistema.
Ejecución de todas las etapas.
 Director de desarrollo: Lleva diariamente las actividades de
desarrollo. Resuelve conflictos en el equipo. Resuelve problemas
referentes a recursos.
 Programador Jefe: Analiza los requerimientos. Diseña el proyecto.
Selecciona las funcionalidades a desarrollar de la última fase del FDD.
 Propietario de clases: Responsable del desarrollo de las
clases que se le asignaron como propias. Participa en la decisión
de que clase será incluida en la lista de funcionalidades de la próxima
iteración.
 Expertos de dominio: Puede ser un usuario, un cliente, analista o una
mezcla de estos. Poseen el conocimiento de los requerimientos
del sistema. Pasa el conocimiento a los desarrolladores para que
se asegure la entrega de un sistema completo.

4. VENTAJAS Y DESVENTAJAS
4.1. Ventajas:
 El equipo de desarrollo no malgasta el tiempo y dinero del cliente
desarrollando soluciones innecesariamente generales y complejas
que en realidad no son un requisito del cliente.
 Cada componente del producto final ha sido probado y
satisface los requerimientos.
 Rápida respuesta a cambios de requisitos a lo largo del desarrollo.
 Entrega continua y en plazos cortos de software funcional.
 Trabajo conjunto entre el cliente y el equipo de desarrollo.
  Minimiza los costos frente a cambios.
 Importancia de la simplicidad, al eliminar el trabajo innecesario.
 Atención continua a la excelencia técnica y al buen diseño.
 Mejora continua de los procesos y el equipo de desarrollo.
 Evita malentendidos de requerimientos entre el cliente y el equipo.
4.2. Desventajas:
 Falta de documentación del diseño. El código no puede
tomarse como una documentación. En sistemas de tamaño
grande se necesitar leer los cientos o miles de páginas del
listado de código fuente.
 Problemas derivados de la comunicación oral. Este tipo de
comunicación resulta difícil de preservar cuando pasa el tiempo y
está sujeta a muchas ambigüedades.
 Fuerte dependencia de las personas. Como se evita en
lo posible la documentación y los diseños convencionales,
los proyectos ágiles dependen críticamente de las personas.
 Falta de reusabilidad. La falta de documentación hacen
difícil que pueda reutilizarse el código ágil
 METODOLOGIA OBJECT MODELING TECHNIQUE (OMT)

1. CARACTERISTICAS
Las características principales de las metodologías orientadas a objetos:
 Ofrecen una forma de pensar más que una forma de programar.
 Reducen la complejidad en el diseño de software.
 Permiten atacar los errores en el transcurso del diseño y
no durante la implementación, donde el costo de reparación es
bastante mayor.

2. MARCO DE TRABAJO
La metodología OMT emplea tres clases de modelos para describir el
sistema:
 Modelo de objetos. Describe la estructura estática de los objetos del
sistema. El modelo de objetos proporciona el entorno esencial en el
cual se pueden situar el modelo dinámico y el modelo funcional. El
objetivo es capturar aquellos conceptos del mundo real que sean
importantes para la aplicación. Se representa mediante
diagramas de objetos.
 Modelo dinámico. Describe los aspectos de un sistema que
tratan de la temporización y secuencia de operaciones y la
organización de sucesos y estados. Captura el control, aquel aspecto
de un sistema que describe las secuencias de operaciones que se
producen sin tener en cuenta lo que hagan las operaciones, aquello a
lo que afecten o la forma en que están implementadas. Se representa
gráficamente mediante diagramas de estado.
 Modelo funcional. Describe las transformaciones de valores de datos
(funciones, correspondencias, restricciones y dependencias
funcionales) que ocurren dentro del sistema. Captura lo que hace el
sistema, independientemente de cuando se haga o de la forma en que
se haga. Se representa mediante diagramas de flujo de datos.

3. ACCIONES Y TAREAS POR ACTIVIDAD

 Análisis. El analista construye un modelo del dominio del problema,
mostrando sus propiedades más importantes. El modelo de
análisis es una abstracción resumida y precisa de lo que debe de
hacer el sistema deseado y no de la forma en que se hará. Los
elementos del modelo deben ser conceptos del dominio de aplicación
y no conceptos informáticos tales como estructuras de datos. Un buen
modelo debe poder ser entendido y criticado por expertos en
el dominio del problema que no tengan conocimientos informáticos.
 Diseño del sistema. El diseñador del sistema toma decisiones de alto
nivel sobre la arquitectura del mismo. Durante esta fase el
sistema se organiza en subsistemas basándose tanto en la
 estructura del análisis como en la arquitectura propuesta. Se
selecciona una estrategia para afrontar el problema.
 Diseño de objetos. El diseñador de objetos construye un
modelo de diseño basándose en el modelo de análisis, pero
incorporando detalles de implementación. El diseño de objetos
se centra en las estructuras de datos y algoritmos que son
necesarios para Implementar cada clase. OMT describe la forma en
que el diseño puede ser implementado en distintos lenguajes.
 Implementación. Las clases de objetos y relaciones
desarrolladas durante el análisis de objetos se traducen
finalmente a una implementación concreta. Durante la fase de
implementación es importante tener en cuenta los principios de la
ingeniería del software de forma que la correspondencia con el
diseño sea directa y el sistema implementado sea flexible y extensible.

4. VENTAJAS Y DESVENTAJAS
4.1. Ventajas:
 Proporciona una serie de pasos perfectamente definidos al
desarrollador.
 Tratamiento especial de la herencia.
 Facilita el mantenimiento dada la gran cantidad de información que
se genera en el análisis.
 Es fuerte en el análisis
4.2. Desventajas:
 Hay pocos métodos para encontrar inconsistencias en los modelos.
 Interacción de objetos no soportada explícitamente en
ninguna herramienta gráfica.
 Al ser un análisis iterativo es difícil de saber cuándo comenzar con
el diseño.
 Es débil en el diseño