Detalle De Un Proceso De Desarrollo De Software
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Detalle De Un Proceso De Desarrollo De Software as PDF for free.
More details
- Words: 757
- Pages: 6
DETALLE DE UN PROCESO DE DESARROLLO DE SOFTWARE ANALISIS •
Características
•
Documentos
•
Especificaciones
•
Diagrama de caso de uso
•
Escenarios-subescenarios
•
Prototipos
DISEÑO (PRELIMINAR Y DETALLADO) •
•
•
Modelo de clases y objetos o
diagramas de secuencia
o
diagramas de colaboración
Diagramas de clases y consultas de patrones de diseño o
modelo de comportamiento de clases y objetos
o
diagramas de actividades
o
diagramas de estado
construcción de modelo o
diagramas de componentes
o
diagramas de despliegue
IMPLEMENTACION •
Decisiones que se toman a partir de los diagramas de componentes y de despliegue
•
Implementa las clases de componentes a partir de los diagramas de objetos
•
Prueba o
Prueba unitaria de cada clase
•
o
Prueba de módulos
o
Prueba de integración
Mantenimiento o
Informes de errores
o
Nueva especificación de requisitos
ANALISIS ORIENTADO A OBJETOS (AOO) [BOSCH 94] “ es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema “ •
Documentos básicos o
Documentos de análisis
o
Especificaciones de requisitos o requerimientos
o
Diagramas de caso de uso
o
Escenarios y sub escenarios
o
Prototipos y su evolución (todos deberán estar identificados y codificados)
•
Documentos de análisis o
Contiene el documento en que aporta el cliente
o
Las actas de reuniones de trabajo
o
Secretaria
o
Aprobar el acta de cada uno
ESPECIFICACIONES DE REQUISITOS O REQUERIMIENTOS [JACOBSON CAP 6] “ la captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles lo que se debe construir “ •
La especificación de requisitos es un documento mas técnico y elaborado de los documentos de análisis.
•
Codificar requisitos
•
Utilizar una especificación jerárquica o
Nivel 1: casos de uso
o
Nivel 2: escenarios
o
Nivel 3: sub-escenarios
DIAGRAMAS DE CASO DE USO (I) •
Es uno de los cinco tipos de diagrama UML, que se utiliza para el modelado
•
Se corresponde inicialmente con requisitos del primer nivel
•
Se suelen codificar con el mismo código que el requisito
•
Los casos de uso representan una vista externa del sistema
•
Se sacan durante reuniones entre el desarrollador y el cliente para que al final todos coincidan
•
El modelado con casos de uso fue desarrollado por Jacobson en 1992
DIAGRAMAS DE CASO DE USO (II) • Sistema que se desea modelar •
Un actor es una clase
• Caso de uso • Interacción •
Limites del sistema
DESCRIPCION DEL CASO DE USO
Hay: 1. Pedidos 2. Informes 3. Averías 4. Reservas 5. Subgerencia 6. Información para el usuario 7. Actividad
SISTEMAS •
Sistema Servidor: está formado por una maquina Windows NT que es atacado por un sistema cliente constituido por maquinas.
•
Sistema Cliente: los programas de aplicación residen en la maquina “cliente” que atacan a servidor donde se encuentra instalado en gestor de la base de datos junto con la base de datos correspondiente.
INTERFASES •
Interfaz de administrador: le permite acceder a todas las acciones que presenta la aplicación.
•
Interfaz dependiente: solo tiene acceso a algunas de las funciones de la aplicación.
•
Interfaz mecánico: tendrá acceso solamente a las reparaciones de la aplicación.
CASOS DE USO RATIONAL ROSE
•
Tiene una acción para ir introduciendo los casos de uso
•
Permite el manejo de autores que se traducirán al sistema como clase
•
Cada sistema recibe un nombre y está ligado a una ventana
ESCENARIOS U SUBESCENARIOS
•
Cada caso de uso da lugar a múltiples escenarios
•
Se codifican
•
Los escenarios también se pueden utilizar para probar el sistema en la fase de pruebas
•
No es necesario hacer todos los escenarios y subescenarios
DIAGRAMA DE CASOS DE USO (III) •
La relación “EXTEND” se utiliza cuando un caso de uso es similar a otro caso se uso pero le añade una característica nueva
•
La relación “USE” se utiliza cuando se tiene una parte del comportamiento común o más de un caso de uso
PROTOTIPOS •
Consiste en crear un modelo o maqueta del sistema que se construye para evaluar mejor los requisitos.
•
Estos modelos son o prototipos, suelen consistir en versiones reducidas, demos o conjuntos de pantallas
Existen tres razones principales para emplear Prototipado, ordenadas por frecuencias de uso. •
Prototipos de interfaz de usuario: sirve para asegurarse de que esta bien diseñado y satisface las necesidades de quien debe usarlo.
•
Modelo de rendimiento: sirve para evaluar el posible rendimiento de un diseño técnico
•
Prototipado funcional
Características
•
Documentos
•
Especificaciones
•
Diagrama de caso de uso
•
Escenarios-subescenarios
•
Prototipos
DISEÑO (PRELIMINAR Y DETALLADO) •
•
•
Modelo de clases y objetos o
diagramas de secuencia
o
diagramas de colaboración
Diagramas de clases y consultas de patrones de diseño o
modelo de comportamiento de clases y objetos
o
diagramas de actividades
o
diagramas de estado
construcción de modelo o
diagramas de componentes
o
diagramas de despliegue
IMPLEMENTACION •
Decisiones que se toman a partir de los diagramas de componentes y de despliegue
•
Implementa las clases de componentes a partir de los diagramas de objetos
•
Prueba o
Prueba unitaria de cada clase
•
o
Prueba de módulos
o
Prueba de integración
Mantenimiento o
Informes de errores
o
Nueva especificación de requisitos
ANALISIS ORIENTADO A OBJETOS (AOO) [BOSCH 94] “ es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema “ •
Documentos básicos o
Documentos de análisis
o
Especificaciones de requisitos o requerimientos
o
Diagramas de caso de uso
o
Escenarios y sub escenarios
o
Prototipos y su evolución (todos deberán estar identificados y codificados)
•
Documentos de análisis o
Contiene el documento en que aporta el cliente
o
Las actas de reuniones de trabajo
o
Secretaria
o
Aprobar el acta de cada uno
ESPECIFICACIONES DE REQUISITOS O REQUERIMIENTOS [JACOBSON CAP 6] “ la captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles lo que se debe construir “ •
La especificación de requisitos es un documento mas técnico y elaborado de los documentos de análisis.
•
Codificar requisitos
•
Utilizar una especificación jerárquica o
Nivel 1: casos de uso
o
Nivel 2: escenarios
o
Nivel 3: sub-escenarios
DIAGRAMAS DE CASO DE USO (I) •
Es uno de los cinco tipos de diagrama UML, que se utiliza para el modelado
•
Se corresponde inicialmente con requisitos del primer nivel
•
Se suelen codificar con el mismo código que el requisito
•
Los casos de uso representan una vista externa del sistema
•
Se sacan durante reuniones entre el desarrollador y el cliente para que al final todos coincidan
•
El modelado con casos de uso fue desarrollado por Jacobson en 1992
DIAGRAMAS DE CASO DE USO (II) • Sistema que se desea modelar •
Un actor es una clase
• Caso de uso • Interacción •
Limites del sistema
DESCRIPCION DEL CASO DE USO
Hay: 1. Pedidos 2. Informes 3. Averías 4. Reservas 5. Subgerencia 6. Información para el usuario 7. Actividad
SISTEMAS •
Sistema Servidor: está formado por una maquina Windows NT que es atacado por un sistema cliente constituido por maquinas.
•
Sistema Cliente: los programas de aplicación residen en la maquina “cliente” que atacan a servidor donde se encuentra instalado en gestor de la base de datos junto con la base de datos correspondiente.
INTERFASES •
Interfaz de administrador: le permite acceder a todas las acciones que presenta la aplicación.
•
Interfaz dependiente: solo tiene acceso a algunas de las funciones de la aplicación.
•
Interfaz mecánico: tendrá acceso solamente a las reparaciones de la aplicación.
CASOS DE USO RATIONAL ROSE
•
Tiene una acción para ir introduciendo los casos de uso
•
Permite el manejo de autores que se traducirán al sistema como clase
•
Cada sistema recibe un nombre y está ligado a una ventana
ESCENARIOS U SUBESCENARIOS
•
Cada caso de uso da lugar a múltiples escenarios
•
Se codifican
•
Los escenarios también se pueden utilizar para probar el sistema en la fase de pruebas
•
No es necesario hacer todos los escenarios y subescenarios
DIAGRAMA DE CASOS DE USO (III) •
La relación “EXTEND” se utiliza cuando un caso de uso es similar a otro caso se uso pero le añade una característica nueva
•
La relación “USE” se utiliza cuando se tiene una parte del comportamiento común o más de un caso de uso
PROTOTIPOS •
Consiste en crear un modelo o maqueta del sistema que se construye para evaluar mejor los requisitos.
•
Estos modelos son o prototipos, suelen consistir en versiones reducidas, demos o conjuntos de pantallas
Existen tres razones principales para emplear Prototipado, ordenadas por frecuencias de uso. •
Prototipos de interfaz de usuario: sirve para asegurarse de que esta bien diseñado y satisface las necesidades de quien debe usarlo.
•
Modelo de rendimiento: sirve para evaluar el posible rendimiento de un diseño técnico
•
Prototipado funcional
Related Documents
Detalle De Un Proceso De Desarrollo De Software
December 2019 9
Modelos De Proceso De Desarrollo Del Software
May 2020 12
Proceso De Desarollo De Software
November 2019 11
Proceso De Desarrollo Y Proceso De Mantenimiento
July 2020 23
Plan De Desarrollo De Software
December 2019 47