Repaso Parcial Ing de Software

========================================= Modelo del proceso

========================================
Un modelo general del proceso incluye un conjunto de actividades estructurales y
sombrilla, acciones y tareas de trabajo.

Cada uno de los modelos de proceso puede describirse por un flujo distinto del
proceso: descripcin decmo se organizan secuencial y cronolgicamente las
actividades estructurales, acciones y tareas.

*Los modelos prescriptivos llevan a cabo el mismo conjunto de actividades

estructurales generales: comunicacin, planeacin, modelado, construccin y
desarrollo.

*Los modelos de proceso secuencial, como el de la cascada y en V, tienen aplicacin

en situaciones en las que los requerimientos estn bien definidos y son estables.

*Los modelos de proceso incremental son de naturaleza iterativa y producen con

mucha rapidez versiones funcionales del software.

*Los modelos de proceso evolutivo reconocen la naturaleza iterativa e incremental

de la mayora de proyectos de ingeniera de software y estn diseados para aceptar
los cambios.

*El modelo de proceso concurrente permite que un equipo de software represente los
elementos iterativos y concurrentes de cualquier modelo de proceso.

*Los modelos especializados incluyen el basado en componentes, que pone el nfasis

en la reutilizacin y ensamble de los componentes.

*El modelo de mtodos formales consiste en un enfoque basado en matemticaspara

desarrollar y verificar el software.

*El modelo orientado a aspectos implica preocupaciones

globales que afectan toda la arquitectura del sistema.

============================================ Proceso Unificado

=========================================

El proceso unificado es un proceso del software diseado como estructura para los
mtodos y herramientas del UML, y est impulsado por el caso de uso, centrado en
la arquitectura, y es iterativo e incremental.

============================================ Factores humanos

==================================

Si los miembros del equipo de software son los que van a generar las
caractersticas del proceso que van a aplicarse a la elaboracin de software, entre
ellos debe existir cierto nmero de
caractersticas clave:

Competencia: La capacidad que tenga cada miembro en aportar al desarrollo.

Incluye el talento innato, las habilidades especficas relacionadas con el software
y el conocimiento general del proceso que el equipo haya elegido aplicar.

*Enfoque comn: Todos deben centrarse en una meta: entregar al cliente en la fecha
prometida un producto de software que funcione.
*Colaboracin. Es la capacidad que tiene el equipo de trabajar en equipo ayudandose
mutuamentelos miembros del equipo deben colaborar, entre s y con todos los
participantes.

*Habilidad para tomar decisiones: Es la autonoma de cada miembro del equipo para
tomar decisiones sobre asuntos tanto tcnicos como del proyecto.

*Capacidad para resolver problemas difusos: Es la capacidad para adaptarse al

cambio, las lecciones aprendidas de cualquier actividad relacionada con la solucin
de problemas sern benficas para el equipo en una etapa posterior del proyecto.

*Confianza y respeto mutuos: Un buen equipo basa su trabajo en la confianza y

respeto que son necesarios para llevarse bien y trabajar de la mejor manera.

*Organizacin propia: la organizacin propia implica tres cosas:

1) el equipo se organiza a s mismo para hacer el trabajo

2) el equipo organiza el proceso que se adapte mejor a su ambiente de trabajo
3) el equipo organiza la programacin del trabajo a fin de que se logre del mejor
modo posible la entrega del producto.

Un equipo con organizacin propia tiene el control del trabajo que realiza.
Establece sus propios compromisos y define los planes para lograrlo.

La organizacin propia sirve para mejorar la colaboracin y elevar la moral del

equipo.

=================================== Desarrollo de casos de uso

=========================================

Se identifican primero los actores antes de hacer un caso de uso.

*Caso de uso: Un caso de uso es una descripcind del comportamiento del sistema en
distintas condiciones en las que el sistema responde a una peticin de alguno de
sus participantes.

*Actores: Los actores son las distintas personas (o dispositivos) que usan el
sistema o producto en el contexto de la funcin y comportamiento que va a
describirse.

Los actores representan los papeles que desempean las personas (o dispositivos o
sensores) cuando opera el sistema.

Un actor es cualquier cosa que se comunique con el sistema o producto y que sea
externo a ste. Todo actor tiene uno o ms objetivos cuando utiliza el sistema.

---- Diferencias: Un usuario normal puede tener varios papeles diferentes cuando
usa el sistema, mientras
que un actor representa una clase de entidades externas que slo tiene un papel en
el contexto del caso de uso.

========================================= MODELO DE LOS REQUERIMIENTOS

================================

El objetivo del modelo del anlisis es describir los dominios de informacin,

funcin y comportamiento que se requieren para el sistema.
El modelo de anlisis y la especificacin de requerimientos proporcionan un medio
para evaluar la calidad una vez construido el software.

El modelo de anlisis debe describir lo que quiere el cliente, establecer una base
para el diseo y un objetivo para la validacin.

======================================= Desarollo de los diagramas

===================================

*Desarrollo de un diagrama de actividades

Un diagrama de actividades UML representa grficamente las acciones y decisiones

que ocurren cuando se realiza cierta funcin.

Un diagrama de actividades es similar a uno de flujo porque utiliza:

*Rectngulos redondeados para denotar una funcin especfica del sistema.

*Flechas para representar flujo a travs de ste.
*Rombos de decisin para ilustrar un ramificacin de las decisiones (cada flecha
que salga del rombo se etiqueta)
y lneas continuas para indicar que estn ocurriendo actividades en paralelo.

*Diagramas de canal (swimlane)

Un diagrama de canal (swimlane) representa el flujo de acciones y decisiones e

indica qu actores efectan cada una de ellas.

*Atributos: Los atributos nombran a un objeto de datos, describen sus

caractersticas y, en ciertos casos,
hacen referencia a otro objeto.

Los atributos son el conjunto de objetos de datos que definen por completo la clase
en el contexto del
problema.

*Relaciones: Las relaciones indican la manera en la que los objetos de datos se

conectan entre s.

*Diagrama de Clases:

El diagrama de clases representa de forma grafica y textual los objetos que

manipular el sistema, las operaciones (tambin llamadas mtodos o servicios) que
se aplicarn a los objetos para efectuar la manipulacin, las relaciones entre los
objetos y las colaboraciones que tienen lugar entre las clases definidas.

Los elementos de un modelo basado en clases incluyen:

las clases y los objetos.

Atributos.
Operaciones.
Modelos clase-responsabilidad-colaborador (CRC).
diagramas de colaboracin y paquetes.

Operaciones(metodos)
Las operaciones definen el comportamiento de un objeto dentro del sistema.

Modelado clase-responsabilidad-colaborador (CRC)

Proporciona una manera sencilla de identificacin y organizacin de las clases que
son relevantes para los requerimientos de un sistema o producto.

Un modelo CRC en realidad es un conjunto de tarjetas que representan clases.

Las tarjetas se dividen en tres secciones. En la parte superior de la tarjeta se

escribe el nombre de la clase, en la parte izquierda del cuerpo se enlistan las
responsabilidades de la clase y en la derecha, los colaboradores.

Las responsabilidades son los atributos y operaciones (son las tareas que debe
realizar esa clase).

Los colaboradores son clases diferentes que se requieren para a fin de completar
una responsabilidad.

*Diagrama de Flujos de datos (DFD)

El propsito de los diagramas de flujo de datos es proveer un puente semntico

entre los usuarios y los desarrolladores de sistemas.

Permite desarrollar modelos del dominio de la informacin y del dominio funcional.

*Modelo de comportamientos

El modelo de comportamiento indica la forma en la que responder el software a

eventos o estmulos externos.

*Diagrama de Estados

Un diagrama de estados es una forma grafica de representar los estados

(comportamiento
especficos) del sistema.

Lo estados son las posibles situaciones en las que puede estar un proceso.

Un diagrama de estado representa el comportamiento sin fijarse en las clases

involucradas.

*Diagrama de secuencia

Un diagrama de secuencia representa el comportamiento, describiendo la forma en la

que las clases pasan de
un estado a otro.

*Diagrama de Comunicacin o Colaboracin

Representa graficamente el grado en el que los objetos se conectan unos con otros
en el sistema, es decir como se comunican para llevar a cabo procesos.

Los objetos son rectangulo y las feclas de coneccion tiene un mensaje diciendo que
mensaje se envia de un objeto a otro.nb

======================================= Fases de desarrollo

======================================

Fase de diseo

El diseo se aplica sin importar el modelo del proceso que se utilice, comienza una
vez que se
han analizado y modelado los requerimientos.

El diseo del software siempre debe comenzar con el anlisis de los datos.

El proceso de diseo es iterativos aqui se pasan los requerimientos en un plano a

la vida real.

======================== Lineamientos y atributos de la calidad del software

============================
*Atributos de Calidad:

Se basan en la funcionalidad, usabilidad, confiabilidad, rendimiento y

mantenibilidad. Los atributos de calidad representan el objetivo de todo diseo de
software,

*ARQUITECTURA DEL SOFTWARE

la arquitectura de un sistema es un marco general que describe su forma y

estructura: sus componentes y la manera en las que ajustan entre s.

*Componente: Un componente es un bloque de construccin de software de cmputo.

Un componente es un elemento funcional (parte modular, desplegable y sustituible)

de un programa que incorpora la lgica del procesamiento, la implantacin de datos
y expone un conjunto de interfaces para el paso de datos.

*Cohesin: la cohesin implica que un componente o clase slo contiene atributos y

operaciones que se relacionan uno con el otro y con la clase o componente en s.