ingeniería de software - unamprofesores.fi-b.unam.mx/adanzg/sweng/presentaciones/01... ·...

Ingeniería de Software. Proceso de Desarrollo de Software Página 0

Ingeniería de Software.

El Proceso de Desarrollo de Software.

(Con tecnología OO).


• En el proceso de desarrollo de software, metodología se refiere al

nivel más alto de organización de un proyecto de desarrollo.

• Esta metodología se descompone en fases.

• Las fases se descomponen en disciplinas (workflows).

• Las disciplinas se descomponen en actividades.

• Las actividades transforman los artefactos de una disciplina a otra.

• La salida de una disciplina se convierte en la entrada de la siguiente.

• El artefacto final es un sistema de software operable que satisface el

artefacto inicial: los requerimientos del sistema.

Proceso General del Desarrollo de Software.


Jerarquía del Proceso de Desarrollo de Software

Orientado a Objetos.


Las 4 fases principales.

• Iniciación o concepción (Inception).

• Elaboración (Elaboration).

• Construcción (Construction).

• Transición (Transition).


Las 7 principales disciplinas.

1. Determinación de requerimientos.

2. Análisis de requerimientos (o simplemente Análisis).

3. Definición de la Arquitectura.

4. Diseño.

5. Construcción (Implementación).

6. Pruebas.

7. Implantación (Deployment).

Nota. En ocasiones se considera el Mantenimiento como una octava disciplina.


La disciplina de Determinación de Requerimientos.

Disciplina Propósito Descripción.

Determinación de

Requerimientos.

Determinar o entender que

debe hacer el sistema en

términos generales.

Determinar:

• Con quiénes debe

interactuar el sistema

(actores).

• Cuáles son los casos de

uso (use cases) qué debe

soportar el sistema.

• El detalle de los

requerimientos

funcionales de cada caso

de uso (use case).


Actividades y artefactos de la disciplina de Determinación

de Requerimientos.

FR: Functional req's. NFR: Non-functional req's. SRS: System Requirements Specification.


La disciplina de Análisis de Requerimientos.


Análisis de

Requerimientos.

Entender a detalle que

debe hacer el sistema

elaborando modelos de los

procesos existentes.

Determinar:

• Casos de Uso (use

cases) detallados y

elaborados.

• Las abstracciones clave u

objetos principales que

existen en el ámbito del

sistema.


Actividades y artefactos de la disciplina de Análisis de

Requerimientos.

CRC: Class Responsibility Collaboration: UC: Use Cases.


La disciplina de Arquitectura.


Arquitectura. Modelar la estructura de

alto nivel del sistema para

satisfacer los NFRs:

requerimientos no

funcionales.

• Desarrollar la estructura

de más alto nivel de la

solución de hardware y

software.

• Identificar las tecnologías

que soportan el modelo

arquitectónico.

• Identificar los riesgos del

proyecto y elaborar

planes de mitigación.


Actividades y artefactos de la disciplina de Arquitectura.


La disciplina de Diseño.


Diseño. Modelar cómo soportará el

sistema todos los casos de

uso

• Crear un modelo de

diseño para cada caso de

uso.

• Crear un modelo de

solución.

• Refinar el modelo de

diseño del sistema.

• Aplicar patrones de

diseño a los modelos.

• Modelar los estados de

objetos complejos.


Actividades y artefactos de la disciplina de Diseño


Las disciplinas de Construcción, Pruebas y Deployment.

Disciplinas Propósito Descripción.

Construcción.

Pruebas.

Deployment.

Construir (codificar),

probar e instalar todos los

componentes del sistema

en sus correspondientes

clientes y/o servidores.

• Implementar (codificar)

cada uno de los

componentes del

sistema.

• Llevar a cabo las pruebas

unitarias, de sistema y de

stress.

• Hacer el deployment del

sistema.


Actividades y artefactos de las disciplinas de

Construcción, Pruebas y Deployment.


Roles de los Involucrados.

Equipo del Cliente

Propietario o accionista.

Gerente.

Usuario.

Equipo de desarrollo

Gerente del Proyecto.

Analista.

Arquitectos.

Diseñador.

Programador.

Probador.

Deployer.


Modelado de Software.

• La concepción o idea original de un proyecto de

software empieza como una idea en la mente de

alguien.

• Para construir algo concreto a partir de esa idea, el

equipo de desarrollo debe crear una serie de

modelos conceptuales, que transformen la idea en

un sistema de producción.


Modelado de Software (2).

• ¿Qué es un modelo?

• Una conceptualización abstracta simplificada

de una entidad (e.g. un edificio) o un sistema

(e.g. software).

• Diferentes vistas muestran el modelo en

diferentes perspectivas.


Específicamente, el modelado nos permite:

• Visualizar sistemas nuevos o existentes.

• Comunicar decisiones a los involucrados en el proyecto.

• Documentar las decisiones tomadas en cada disciplina del

proceso.

• Especificar la estructura (modelo estático) y el comportamiento

(modelo dinámico) de los elementos del sistema.

• Utilizar patrones conocidos para construir la solución del software.

¿Por qué modelar el Software?


Transformaciones del modelo.

El proceso de desarrollo de Software se puede concebir

como una serie de transformaciones del modelo mental

del patrocinador (stakeholder) al código real.

FR: Functional requirements. NFR: Non-functional requirements.


Ejercicio 1: Disciplinas.

Término Definición

1 Determinación de

requerimientos.

A Modelar la estructura de más alto nivel del sistema e identificar y mitigar

riesgos

2 Análisis. B Instalar la implementación del sistema en un ambiente producción.

3 Arquitectura. C Codificar los componentes de software definidos en el modelo de diseño.

4 Diseño. D Identificar los requerimientos del sistema mediante entrevistas con los

propietarios, patrocinadores y usuarios del sistema propuesto.

5 Construcción. E Asegurarse de que la implementación cumple las expectativas definidas en

los requerimientos.

6 Pruebas. F Crear un modelo de la solución del sistema que satisfaga los requerimientos

funcionales.

7 Deployment. G Estudiar a detalle, entender, refinar y modelar los requerimientos del sistema.

¿A qué definición corresponden los términos mencionados?


Ejercicio 2: Beneficios del modelaje.

√ Descripción.

Los modelos proporcionan el punto de partida para un nuevo sistema.

Los modelos ayudan a entender lo que se ha desarrollado.

Los modelos ayudan a visualizar sistemas nuevos o existentes.

Los modelos son realizaciones concretas de un sistema.

Los modelos ayudan a comunicar decisiones a los involucrados (stakeholders)

del proyecto.

Marque las descripciones que representan beneficios del modelaje.


Ejercicio 3: Características de la disciplina de

Determinación de Requerimientos.

√ Descripción.

Esta disciplina empieza con entrevistas con el dueño o accionista del negocio.

Esta disciplina requiere modelar la estructura de alto nivel del sistema para

satisfacer los requerimientos no funcionales.

El propósito de esta disciplina es determinar qué debe hacer el sistema en

términos generales.

Se debe crear el modelo de diseño durante esta disciplina.

Se deben crear los diagramas de Casos de Uso iniciales durante esta

disciplina.

Marque las descripciones que representan características de esta

disciplina.


Ejercicio 4: Características de la disciplina de Análisis de

Requerimientos.

√ Descripción.

El propósito de esta disciplina es determinar qué debe hacer el sistema en

forma comprehensiva.

Esta disciplina incluye el registro de los detalles de los Casos de Uso.

El propósito de esta disciplina es modelar cómo soportará el sistema los Casos

de Uso.

Durante esta disciplina se crea el modelo de Diseño.

Durante esta disciplina se crea el diagrama de Deployment.


disciplina.



Arquitectura.

√ Descripción.

Durante esta disciplina se usa el diagrama de Actividades para verificar los

Casos de Uso.

Durante esta disciplina se analizan los Casos de Uso para determinar detalles

adicionales.

Durante esta disciplina se determina la estructura de alto nivel del sistema

(hardware y software), que satisface los requerimientos no funcionales.

Durante esta disciplina se podrían crear diagramas de estado.

El propósito de esta disciplina es modelar como soportará el sistema los Casos

de Uso.


disciplina.



Diseño.

√ Descripción.

Durante esta disciplina se crea el diagrama de Deployment.

El propósito de esta disciplina es modelar la estructura de alto nivel del Sistema

para satisfacer los requerimientos no funcionales.

Durante esta disciplina se crea el diagrama de capas y estratos.

El propósito de esta disciplina es modelar la estructura del Sistema para satisfacer

los requerimientos funcionales.

Durante esta disciplina se refina el modelo de Diseño.


disciplina.


Ejercicio 7: Características de las disciplinas de

Construcción, Pruebas y Deployment.

√ Descripción.

Durante esta disciplina se crea un plan de Deployment.

Durante esta disciplina se crean diagramas de paquetes.

Durante esta disciplina se crea el modelo de Solución.

El propósito de estas disciplinas es implementar, probar e implantar el sistema.

El foco de esta disciplina es descubrir los requerimientos funcionales y no

funcionales.

Marque las descripciones que representan características de estas

disciplinas.

ingeniería de software - unamprofesores.fi-b.unam.mx/adanzg/sweng/presentaciones/01... ·...

Documents