32989394
Beschreibung
Mindmap von Marlon Stiven Rojas, aktualisiert more than 1 year ago
|
Erstellt von Marlon Stiven Rojas
vor etwa 3 Jahre
|
|
PROCESO PARA EL DESARROLLO DE SOFTWARE
- Modelo de desarrollo de software
- 1. Software: El objetivo principal que busca la ingeniería de software es
convertir el desarrollo de software en un proceso formal, con
resultados predecibles, que permitan obtener un producto final de alta
calidad y satisfaga las necesidades y expectativas del cliente.
- 2. Modelo de Desarrollo de Softwares: Modelo de Cascada, Modelo de Desarrollo Evolutivo,
Modelo de Desarrollo basado en Componente. Cada uno de estos modelo explica de una manera
coherente, el desarrollo o creación de un proyecto, como el desarrollo de softwares, en la cual
todo se basa de una forma diferente pero tiene un mismo fin en común.
- Existen tres paradigmas de
los modelos de desarrollo
de software
- Paradigma de Desarrollo Ágil
- Paradigma Orientado a Objetos
- Paradigma Tradicional
- Paradigma de Desarrollo Ágil
- Modelo de
cascada
- El modelo de cascada define las
siguientes etapas que deben
cumplirse de forma sucesiva:
- Especificación de requisitos
- Diseño del software
- Construcción o Implementación del software
- Integración
- Pruebas (o validación)
- Despliegue (o instalación)
- Mantenimiento
- Especificación de requisitos
- El modelo de cascada define las
siguientes etapas que deben
cumplirse de forma sucesiva:
- Modelo de espiral
- La principal característica del modelo en espiral es la
gestión de riesgos de forma periódica en el ciclo de
desarrollo. Este modelo fue creado en 1988 por Barry
Boehm, combinando algunos aspectos clave de las
metodologías del modelo de cascada y del desarrollo
rápido de aplicaciones, pero dando énfasis en un área que
para muchos no jugó el papel que requiere en otros
modelos: un análisis iterativo y concienzudo de los riesgos,
especialmente en el caso de sistema complejos de gran
escala.
- La principal característica del modelo en espiral es la
gestión de riesgos de forma periódica en el ciclo de
desarrollo. Este modelo fue creado en 1988 por Barry
Boehm, combinando algunos aspectos clave de las
metodologías del modelo de cascada y del desarrollo
rápido de aplicaciones, pero dando énfasis en un área que
para muchos no jugó el papel que requiere en otros
modelos: un análisis iterativo y concienzudo de los riesgos,
especialmente en el caso de sistema complejos de gran
escala.
- 1. Software: El objetivo principal que busca la ingeniería de software es
convertir el desarrollo de software en un proceso formal, con
resultados predecibles, que permitan obtener un producto final de alta
calidad y satisfaga las necesidades y expectativas del cliente.
- Actividades del desarrollo
de software
- Planificación
- La importante tarea a la hora de crear
un producto de software es obtener los
requisitos o el análisis de los requisitos.
Los clientes suelen tener una idea más
bien abstracta del resultado final, pero
no sobre las funciones que debería
cumplir el software
- La importante tarea a la hora de crear
un producto de software es obtener los
requisitos o el análisis de los requisitos.
Los clientes suelen tener una idea más
bien abstracta del resultado final, pero
no sobre las funciones que debería
cumplir el software
- implementación
- es parte del proceso en el que los
ingenieros de software programan el
código para el proyecto de trabajo que
está en relación de las demanda del
software, en esta etapa se realizan las
pruebas de caja blanca y caja negra. Las
pruebas de software son parte esencial
del proceso de desarrollo del software.
- es parte del proceso en el que los
ingenieros de software programan el
código para el proyecto de trabajo que
está en relación de las demanda del
software, en esta etapa se realizan las
pruebas de caja blanca y caja negra. Las
pruebas de software son parte esencial
del proceso de desarrollo del software.
- Despliegue y mantenimiento
- El despliegue comienza cuando el
código ha sido suficientemente
probado, ha sido aprobado para su
liberación y ha sido distribuido en
el entorno de producción.
- El despliegue comienza cuando el
código ha sido suficientemente
probado, ha sido aprobado para su
liberación y ha sido distribuido en
el entorno de producción.
- Planificación
- Principales Roles en el proceso
de Desarrollo de Software
- Gerente de proyecto: Tiene por función presentar informes sobre las litigaciones de riesgos,
hacer cumplir los plazos y llevar el control de los costos. También organiza el equipo, realiza la
planificación y estima el tiempo de las actividades. En conclusión, resuelve problemas.
- Analista de requerimientos: Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del
Software, la documentación de los requerimientos para así el resto del equipo lo que pueda consultar en
cualquier momento. Debe ser una persona con capacidad de abstracción y análisis.
- Desarrollador de software o programador: Encargado de la concepción y el diseño, escribe el código, prueba lo
que construye y se encarga de hacer el mantenimiento del código.
- Testeador: Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar claro esta, estudiar
funcionalidad del producto y desarrollar las pruebas que revelen incidentes críticos. Reporta los incidentes y
provee información sobre la calidad del sistema.
- Arquitecto de software: Está encargado del aseguramiento de la calidad, mejorar continuamente la arquitectura.
Gestiona los requerimientos no funcionales, asume la dirección técnica para asegurar que todos los aspectos de la
arquitectura se estén desarrollando de manera correcta.
- Gerente de proyecto: Tiene por función presentar informes sobre las litigaciones de riesgos,
hacer cumplir los plazos y llevar el control de los costos. También organiza el equipo, realiza la
planificación y estima el tiempo de las actividades. En conclusión, resuelve problemas.
- También denominado ciclo de vida del desarrollo de
software es una estructura aplicada al desarrollo de un
producto de software. Hay varios modelos a seguir para el
establecimiento de un proceso para el desarrollo de
software, cada uno de los cuales describe un enfoque
diferente para diferentes actividades que tienen lugar
durante el proceso.
- PLANEACION , DESARROLLO Y EJECUCION DE 5
MODERLOS
- 1. MODELO REQUISITOS
- El desarrollo de software comienza con una fase inicial de planificación
incluyendo un análisis de requisitos. Nos fijamos en los requisitos que
piden los clientes para estudiar cuales están poco claros, incompletos,
ambiguos o contradictorios. Se indaga en profundidad y se hacen
demostraciones prácticas incluyendo a los usuarios clave.
- ESTE SE DIVIDE EN 3 MODELOS O SUP
PUNTOS
- DESCRICION DEL PROBLEMA
- se describirán las necesidades del cliente,
textuales informales o reseñas
- se describirán las necesidades del cliente,
textuales informales o reseñas
- MODELO DE INTERFACES
- Describe la presentación de
información entre los actores
y el sistema. Se especifica en
detalle cómo se verán las
interfaces de usuario al
ejecutar cada uno de los casos
de uso.
- Describe la presentación de
información entre los actores
y el sistema. Se especifica en
detalle cómo se verán las
interfaces de usuario al
ejecutar cada uno de los casos
de uso.
- MODELO DE CASO DE USO
- Este modelo describe las diferentes formas
en que se va a utilizar, donde cada una de
estas posibilidades serán llamadas "Caso
de uso", siendo estas muy variadas y
dependientes de los tipos de usuarios que
tendrá
- ESTO SE DIVIDE EN DOS MODELOS
- ACTORES
- Son todos aquellos que intercambian informacion con el sistema
creado, donde puede ser una persona, un hardware extermo u otro
sistema. Dentro de este modelo es de importancia vital identificar los
diferentes actores, pues esto ayudara a delimitar el sistema y evitara
un libre albedrio. es por ello que para evitar este tipo de acciones, hay
dos tipos de actores, primarios y secuandarios
- Actores primarios: los cuales rigen la secuencia lógica de
ejecución del sistema
- Actores Secundarios: Los cuales supervisarán y mantendrán
el sistema. Estos son complementos de los primarios
- Actores primarios: los cuales rigen la secuencia lógica de
ejecución del sistema
- Son todos aquellos que intercambian informacion con el sistema
creado, donde puede ser una persona, un hardware extermo u otro
sistema. Dentro de este modelo es de importancia vital identificar los
diferentes actores, pues esto ayudara a delimitar el sistema y evitara
un libre albedrio. es por ello que para evitar este tipo de acciones, hay
dos tipos de actores, primarios y secuandarios
- CASO USO
- Al usarse terminología orientada a objetos, cada caso de
uso define una clase o forma particular de usar el
sistema, mientras que cada ejecución del caso de uso se
puede ver como una instancia del mismo, o sea, un
objeto, con estado y comportamiento.
- inclusión
- Es una sección de un caso de uso que es parte obligatoria
del caso de uso básico, donde se insertará la
funcionalidad depende del caso de uso a ser insertado.
- Es una sección de un caso de uso que es parte obligatoria
del caso de uso básico, donde se insertará la
funcionalidad depende del caso de uso a ser insertado.
- extensión
- Es cuando un caso de uso
puede insertarse en otro
para extender la
funcionalidad del anterior.
- Es cuando un caso de uso
puede insertarse en otro
para extender la
funcionalidad del anterior.
- generalización
- Apoya la reutilización de los casos de uso. Mediante la relación
de generalización es necesario describir las partes similares una
sola vez, en lugar de repetirlas para todos los casos de uso con
comportamiento común.
- Apoya la reutilización de los casos de uso. Mediante la relación
de generalización es necesario describir las partes similares una
sola vez, en lugar de repetirlas para todos los casos de uso con
comportamiento común.
- documentación
- Es la descripción textual detallada
de cada uno de los actores y casos de
uso identificados. todo esto se
registrara en una tabla
- Es la descripción textual detallada
de cada uno de los actores y casos de
uso identificados. todo esto se
registrara en una tabla
- inclusión
- Al usarse terminología orientada a objetos, cada caso de
uso define una clase o forma particular de usar el
sistema, mientras que cada ejecución del caso de uso se
puede ver como una instancia del mismo, o sea, un
objeto, con estado y comportamiento.
- ACTORES
- ESTO SE DIVIDE EN DOS MODELOS
- Este modelo describe las diferentes formas
en que se va a utilizar, donde cada una de
estas posibilidades serán llamadas "Caso
de uso", siendo estas muy variadas y
dependientes de los tipos de usuarios que
tendrá
- DESCRICION DEL PROBLEMA
- ESTE SE DIVIDE EN 3 MODELOS O SUP
PUNTOS
- El desarrollo de software comienza con una fase inicial de planificación
incluyendo un análisis de requisitos. Nos fijamos en los requisitos que
piden los clientes para estudiar cuales están poco claros, incompletos,
ambiguos o contradictorios. Se indaga en profundidad y se hacen
demostraciones prácticas incluyendo a los usuarios clave.
- 2.MODELO DE ANALISIS
- Cuando ya se ha desarrollado y aceptado el modelo de
requisitos, se inicia el desarrollo del modelo de análisis
siguiendo el modelo de casos. El cual su objetivo es comprender
y generar una arquitectura de objetos para el sistema con base
en lo especificado en el modelo de requisitos.
- ARQUITECTURA DE CLASES
- tiene como objetivo generar una
arquitectura de objetos que sirva
como base para el diseño del
sistema.
- ESTA ARQUITECTURA SE COMPONE
DE 2 FACTORES
- estereotipos
- El tipo de funcionalidad o “la razón de ser” de un
objeto dentro de una arquitectura se conoce como
su estereotipo
- El tipo de funcionalidad o “la razón de ser” de un
objeto dentro de una arquitectura se conoce como
su estereotipo
- casos de usos
- En cada caso de uso se identifican los objetos necesarios
para su implementación. Los objetos se identifican según
sus estereotipos de manera que correspondan con la
funcionalidad ofrecida en cada uno
- En cada caso de uso se identifican los objetos necesarios
para su implementación. Los objetos se identifican según
sus estereotipos de manera que correspondan con la
funcionalidad ofrecida en cada uno
- estereotipos
- ESTA ARQUITECTURA SE COMPONE
DE 2 FACTORES
- tiene como objetivo generar una
arquitectura de objetos que sirva
como base para el diseño del
sistema.
- INDENTIFICACION DE CLASES SEGUN
ESTEREOTIPOS
- Para hacer la transicion del modelo anterior, se debe
hacer primero la identificación de los objetos
necesarios para todos los casos de uso, para que asi
se le pueda asignar la funcional de forma general al
caso del uso, afectando asi sus objetos,
- borde
- todos los casos de uso que dependen
de los aspectos externos del sistema se
ubican en los objetos borde, pues con
ellos se comunican los actores con el
sistema. Donde su tarea es traducir los
eventos generados por un actor en
eventos del sistema, y así mismo
traducir los eventos del sistema en
una presentación comprensible por el
actor, esta clase describe el sistema
comunicación-actor
- todos los casos de uso que dependen
de los aspectos externos del sistema se
ubican en los objetos borde, pues con
ellos se comunican los actores con el
sistema. Donde su tarea es traducir los
eventos generados por un actor en
eventos del sistema, y así mismo
traducir los eventos del sistema en
una presentación comprensible por el
actor, esta clase describe el sistema
comunicación-actor
- entidad
- son objetos de
entidad aquellos
que pueden
modificar la
informacion que el
sistema maneja a
corto y largo plazo.
- son objetos de
entidad aquellos
que pueden
modificar la
informacion que el
sistema maneja a
corto y largo plazo.
- control
- son objetos de
control
aquellos que
evitarán que
otros objetos
tengan
diferentes
comportamientos
- son objetos de
control
aquellos que
evitarán que
otros objetos
tengan
diferentes
comportamientos
- borde
- Para hacer la transicion del modelo anterior, se debe
hacer primero la identificación de los objetos
necesarios para todos los casos de uso, para que asi
se le pueda asignar la funcional de forma general al
caso del uso, afectando asi sus objetos,
- ARQUITECTURA DE CLASES
- Cuando ya se ha desarrollado y aceptado el modelo de
requisitos, se inicia el desarrollo del modelo de análisis
siguiendo el modelo de casos. El cual su objetivo es comprender
y generar una arquitectura de objetos para el sistema con base
en lo especificado en el modelo de requisitos.
- 3.MODELO DE DISEÑO
- En esta fase ya se comienza a visualizar la
solución con la ayuda de las anteriores fases.
Se hace un diseño lógico y otro físico. Se
crean metadatos, diagramas o
pseudocódigos. La duración de esta fase
varía de un proyecto a otro.
- El resultado del modelo de diseño son
especificaciones muy detalladas de todos los
objetos, incluyendo sus operaciones y atributos.
- para evitar múltiples errores,
por la complejidad del sistema
se tienen en cuenta 2 puntos
- Diseño de sistema.
- El modelo se adapta al ambiente de implementación.
Este paso incluye identificar e investigar las
consecuencias del ambiente de implementación
sobre el diseño. Aquí deben tomarse las decisiones
de implementación estratégicas: i) cómo se
incorporará una base de datos en el sistema, ii) qué y
có.mo se usarán las bibliotecas de componentes, iii)
qué lenguajes de programación se utilizarán, iv)
cómo se manejarán los procesos, incluyendo
comunicación y requisitos de rendimiento, v) cómo
se diseñará el manejo de excepciones y recolección
de basura, etc
- El modelo se adapta al ambiente de implementación.
Este paso incluye identificar e investigar las
consecuencias del ambiente de implementación
sobre el diseño. Aquí deben tomarse las decisiones
de implementación estratégicas: i) cómo se
incorporará una base de datos en el sistema, ii) qué y
có.mo se usarán las bibliotecas de componentes, iii)
qué lenguajes de programación se utilizarán, iv)
cómo se manejarán los procesos, incluyendo
comunicación y requisitos de rendimiento, v) cómo
se diseñará el manejo de excepciones y recolección
de basura, etc
- Diseño de objetos
- Se refina y formaliza el modelo para generar especificaciones
muy detalladas de todos los objetos, incluyendo sus operaciones
y atributos. Se describe cómo interactúan los objetos en cada
caso de uso específico, especificando qué debe hacer cada
operación en cada objeto.
- Se refina y formaliza el modelo para generar especificaciones
muy detalladas de todos los objetos, incluyendo sus operaciones
y atributos. Se describe cómo interactúan los objetos en cada
caso de uso específico, especificando qué debe hacer cada
operación en cada objeto.
- Diseño de sistema.
- para evitar múltiples errores,
por la complejidad del sistema
se tienen en cuenta 2 puntos
- El resultado del modelo de diseño son
especificaciones muy detalladas de todos los
objetos, incluyendo sus operaciones y atributos.
- para iniciar el proceso de diseño
se desea planificar las
estrategias de diseño, el diseño
de los objetos, del sistema y la
revision de diseños y diagramas
- estrategias de diseño
- Es necesario tomar decisiones generales sobre las
estrategias de diseño a seguir. Algunas de las decisiones a
tomar se presentan a continuación y se relacionan con
aspectos que incluyen la arquitectura, robustez, reuso y
extensibilidad del sistema
- Es necesario tomar decisiones generales sobre las
estrategias de diseño a seguir. Algunas de las decisiones a
tomar se presentan a continuación y se relacionan con
aspectos que incluyen la arquitectura, robustez, reuso y
extensibilidad del sistema
- diseño de objetos
- Se añade detalles al análisis y tomar decisiones junto con el diseño del
sistema, o sea, al ambiente de implementación, de manera que se logre
una especificación detallada antes de comenzar la imple-mentación final.
Algunos de los aspectos a resolver por el diseño de objetos es determinar
cómo las clases, atributos y asociaciones del modelo de análisis deben
implementarse en estructuras de datos específicas. También es necesario
determinar si se requiere introducir nuevas clases en el modelo de diseño,
para las cuales no se tiene ninguna representación en el modelo de
análisis, o si se requiere modificar o eliminar clases identificadas durante
el modelo de análisis. Se debe agregar herencia para incrementar el reuso
del sistema. También es necesario determinar los algoritmos para
implementar las operaciones, así como todos los aspectos de optimización.
- Se añade detalles al análisis y tomar decisiones junto con el diseño del
sistema, o sea, al ambiente de implementación, de manera que se logre
una especificación detallada antes de comenzar la imple-mentación final.
Algunos de los aspectos a resolver por el diseño de objetos es determinar
cómo las clases, atributos y asociaciones del modelo de análisis deben
implementarse en estructuras de datos específicas. También es necesario
determinar si se requiere introducir nuevas clases en el modelo de diseño,
para las cuales no se tiene ninguna representación en el modelo de
análisis, o si se requiere modificar o eliminar clases identificadas durante
el modelo de análisis. Se debe agregar herencia para incrementar el reuso
del sistema. También es necesario determinar los algoritmos para
implementar las operaciones, así como todos los aspectos de optimización.
- diseño del sistema
- En estos aspectos pueden variar radicalmente entre uno y otro
sistema, y también pueden afectar de manera importante la
arquitectura final del sistema. En general, existen diversos
enfoques para la incorporación del ambiente de
implementación a la arquitectura del sistema
- para el diseño se dividen en 3 factores
- lenguajes de programación
- existe un apoyo directo a los conceptos y mecanismos
fundamentales del análisis orientado a objetos:
encapsulamiento, clasificación, generalización y
polimorfismo. Sin embargo, generalmente se puede
traducir cualquier concepto o mecanismo orientado a
objetos a otros existentes en los lenguajes no
orientados a objetos.
- existe un apoyo directo a los conceptos y mecanismos
fundamentales del análisis orientado a objetos:
encapsulamiento, clasificación, generalización y
polimorfismo. Sin embargo, generalmente se puede
traducir cualquier concepto o mecanismo orientado a
objetos a otros existentes en los lenguajes no
orientados a objetos.
- bases de datos
- Las bases de datos son fundamentales en los sistemas de información.
Una decisión estratégica importante en tal contexto es si debe utilizar
bases de datos relacionales u orientadas a objetos.
- Las bases de datos son fundamentales en los sistemas de información.
Una decisión estratégica importante en tal contexto es si debe utilizar
bases de datos relacionales u orientadas a objetos.
- interfaces grafias
- se encarga de administrar la interacción
con el usuario mediante elementos
gráficos, como lo son los botones, menús
y textos.
- se encarga de administrar la interacción
con el usuario mediante elementos
gráficos, como lo son los botones, menús
y textos.
- lenguajes de programación
- para el diseño se dividen en 3 factores
- En estos aspectos pueden variar radicalmente entre uno y otro
sistema, y también pueden afectar de manera importante la
arquitectura final del sistema. En general, existen diversos
enfoques para la incorporación del ambiente de
implementación a la arquitectura del sistema
- revisión de diseño
- el sistema se optimiza de la mejor
manera
- el sistema se optimiza de la mejor
manera
- diagrama de
secuencias de diseño
- Una vez completado tanto el diseño de objetos como el
del sistema, es posible describir los casos de uso del
análisis con base en los protocolos de clases definidos
antes. Esto es muy importante, ya que permite revisar
que el diseño esté lógicamente completo.
- Una vez completado tanto el diseño de objetos como el
del sistema, es posible describir los casos de uso del
análisis con base en los protocolos de clases definidos
antes. Esto es muy importante, ya que permite revisar
que el diseño esté lógicamente completo.
- estrategias de diseño
- En esta fase ya se comienza a visualizar la
solución con la ayuda de las anteriores fases.
Se hace un diseño lógico y otro físico. Se
crean metadatos, diagramas o
pseudocódigos. La duración de esta fase
varía de un proyecto a otro.
- 5.MODELO DE PRUEBAS
- LLegado a este punto el sistema ya se encuentra desarrollado en su mayor porcentaje, por la que ahora solo
hace falta realizar una gran cantidad de pruebas las cuales van a definir posibles errores a corregir, es de aclarar
que la manera de probar los sistemas llega a ser muy variado, por lo que puede elevar aun mas el costo de
desarrollo es por ello que estas pruebas deben elegir de manera integral
- para desarrollar y ejecutar las pruebas se
requiere 2 tipos de procesos
- tipos de prueba
- se dividen de manera
general en pruebas de
verificación y validación.
- Las técnicas utilizadas para
realizar las pruebas son
muy variadas
- Prueba de regresión. Tiene como propósito
verificar el sistema luego, de haberle
introducido cambios,
- Prueba de operación. Su objetivo es verificar el
sistema en operación por un largo periodo bajo
condiciones normales de uso. Este tipo de prueba
mide la confiabilidad (reliability) del sistema.
- Prueba de escala completa. Trata de verificar el sistema en su
carga máxima mediante la asignación de los parámetros a su
valor límite y la interconexión del sistema con un máximo de
equipos y usuarios simultáneos. Su máxima expresión es la
prueba de estrés (stressing), que significa que se prueba el
sistema en los límites extremos para determinar su nivel de
tolerancia y si ocurre algún tipo de falla.
- Prueba de documentación de usuario. Tiene como propósito
probar la documentación de usuario, incluyendo el manual de
éste y la documentación de mantenimiento y servicio. Se
prueba que los manuales y el comportamiento del sistema
sean congruentes entre sí, que sean legibles, con una buena
redacción y, en general, que sean comprensibles.
- Prueba de aceptación o de validación. Pretende lograr
una revisión final por parte de la organización que
solicitó el sistema, lo cual, a menudo, significa validación
del sistema. El sistema se prueba en su ambiente real
por un periodo extenso. Cuando se termina la prueba, se
toma la decisión de aceptar o no el producto. Este tipo
de prueba es a veces conocida como prueba alfa.
- Prueba de rendimiento
(performance) o de capacidad.
Tiene como propósito medir la
capacidad de procesamiento del
sistema bajo diferentes cargas,
incluyendo espacio de
almacenamiento y utilización de la
unidad de procesamiento. Los
valores medidos se comparan con
los valores requeridos.
- Prueba de sobrecarga. Pretende observar cómo se comporta el sistema cuando
se le aplica una sobrecarga, más allá de las pruebas de escala completa y
rendimiento. Aunque no se puede esperar que el sistema tolere estas pruebas,
debería funcionar correctamente, es decir, sobrevivir a picos de carga y evitar
que ocurra una catástrofe. Es siempre importante saber en qué momento y de
qué manera cae el rendimiento del sistema.
- Prueba basada en requisitos o prueba de casos de uso. Intenta
llevar a cabo pruebas basadas directamente en la especificación
de requisitos. Pueden utilizarse los mismos casos de uso
originales como casos de prueba. También pueden ser
utilizadas para verificar las especificaciones de rendimiento o
de escala completa. Se trata de verificar que el sistema final
cumple con las especificaciones funcionales descritas por los
casos de uso originales
- Prueba negativa. Tiene como propósito medir el estrés del
sistema en situaciones inesperadas, como casos de uso que
normalmente no serían utilizados de manera simultánea. El
sistema se usa intencional y sistemáticamente de forma
incorrecta. Este maltrato debe ser planeado de forma
cuidadosa para probar aspectos especialmente críticos
- niveles de prueba
- Prueba de unidad. Mediante esta prueba
sólo una unidad es probada como tal,
como una clase, un paquete de servicio o
un subsistema.
- Prueba de integración. En ella se verifica que las unidades
trabajen juntas correctamente. Ambas pueden ser realizadas
mediante casos de uso de pruebas, los cuales pueden ser
aplicados a clases, paquetes de servicio, subsistemas y el sistema
completo
- Prueba de sistema. Verifica el sistema completo o su aplicación
como tal. Se toma el punto de vista del usuario final y los casos
de uso de pruebas ejecutan acciones típicas del usuario.
- Prueba de unidad. Mediante esta prueba
sólo una unidad es probada como tal,
como una clase, un paquete de servicio o
un subsistema.
- Prueba de regresión. Tiene como propósito
verificar el sistema luego, de haberle
introducido cambios,
- Las técnicas utilizadas para
realizar las pruebas son
muy variadas
- se dividen de manera
general en pruebas de
verificación y validación.
- procesos de prueba
- en este punto se tiene en cuenta consideraciones similares al
proceso de desarrollo de software que incluyen estrategias,
actividades y métodos los cuales deben ser aplicados.
- planeación de la prueba
- tiene como proposito establecer las
estrategias de prueba, definiendo si
estas se de manera automática o
manual, y además si existen programas
y datos de prueba que pueden ser
usados, sean modificados o de nueva
cuenta
- tiene como proposito establecer las
estrategias de prueba, definiendo si
estas se de manera automática o
manual, y además si existen programas
y datos de prueba que pueden ser
usados, sean modificados o de nueva
cuenta
- estrategias de prueba
- Existen una gran variedad de estrategias para el proceso de
pruebas, en donde se destaca el orden que va a llevar a cabo, la
partición de equivalencias de pruebas que van a aplicar y la
posibilidad. Para crear las estrategias de pruebas se tiene en cuenta
3 conceptos mas.
- Orden de Pruebas: tiene como propósito
definir en que momento y en que orden se
va a aplicar las pruebas
- Alcance de pruebas: Tiene como propósito identificar
el tipo, numero y casos de prueba que se van a aplicar
para revisar los diferentes aspectos del sistema
- Automatización de pruebas: tiene como
propósito reducir el esfuerzo y costo de las
pruebas mediante la automatización del
proceso o los aspectos
- Orden de Pruebas: tiene como propósito
definir en que momento y en que orden se
va a aplicar las pruebas
- Existen una gran variedad de estrategias para el proceso de
pruebas, en donde se destaca el orden que va a llevar a cabo, la
partición de equivalencias de pruebas que van a aplicar y la
posibilidad. Para crear las estrategias de pruebas se tiene en cuenta
3 conceptos mas.
- planeación de la prueba
- en este punto se tiene en cuenta consideraciones similares al
proceso de desarrollo de software que incluyen estrategias,
actividades y métodos los cuales deben ser aplicados.
- tipos de prueba
- para desarrollar y ejecutar las pruebas se
requiere 2 tipos de procesos
- LLegado a este punto el sistema ya se encuentra desarrollado en su mayor porcentaje, por la que ahora solo
hace falta realizar una gran cantidad de pruebas las cuales van a definir posibles errores a corregir, es de aclarar
que la manera de probar los sistemas llega a ser muy variado, por lo que puede elevar aun mas el costo de
desarrollo es por ello que estas pruebas deben elegir de manera integral
- 4. MODELO DE IMPLEMENTACIÓN
- Aquí se instala el software, se evalúa la integración, la adaptabilidad,
la portabilidad y se instalan las configuraciones posteriores
necesarias.
- Se toma lo anterior para realizar al
código final , ya que pues todos los
elementos deben estar simples y
sencillos
- una vez especificado se
generan los diagrama de clases
para completar el sistema
- una vez especificado se
generan los diagrama de clases
para completar el sistema
- Aquí se instala el software, se evalúa la integración, la adaptabilidad,
la portabilidad y se instalan las configuraciones posteriores
necesarias.
- 1. MODELO REQUISITOS
- MARLON STIVEN ROJAS MORENO
Medienanhänge
Möchten Sie kostenlos Ihre eigenen Mindmaps mit GoConqr erstellen? Mehr erfahren.