Tarea

1. Psicología 101- B- Sampedro Garcia David

2.  Software
 Programas
 Archivos de configuración
 Documentación de la estructura del sistema
 Manuales de instalación y uso
 Sitios web con información y actualizaciones
 TIPOS DE SOFTWARE
 Productos genéricos
 sistemas producidos por una organización y que se venden en el mercado abierto. Ejemplos: sistemas gestores de bases de datos,
procesadores de texto, paquetes gráficos,...
 Productos personalizados
 desarrollados específicamente para un cliente
 aplicaciones de negocio, sistemas de control de tráfico aéreo, control de procesos de fabricación,...
 el cliente controla la especificación de la aplicación

3.  El software desde una perspectiva industrial
 El valor del software: de “elemento añadido” a principal elemento de coste
 El desarrollo del software:
 Algunas preguntas:
 ¿Por qué se tarda tanto? (y casi siempre más de lo previsto)
 ¿Por qué la productividad es tan baja?
 ¿Por qué cuesta tanto?
 ¿Por qué siempre quedan errores sin localizar?

4.  El software como elemento lógico.
 Se desarrolla, no se fabrica:
 Se “deteriora” con el mantenimiento
 Desarrollo a medida.
 La “crisis” del software: problemas que aparecen en el desarrollo del software al desarrollar, mantener y atender
la demanda de nuevas aplicaciones.
Insatisfacción del cliente
Planificación y estimaciones
imprecisas
Calidad
Sin tiempo para recoger
datos históricos
Baja productividad
Dificultad de mantener
el software existente

5.  Causas de la crisis del software
 Naturaleza lógica del software
 Mala gestión de los proyectos ( ausencia de datos, deficiente comunicación, ...)
 Ausencia de entrenamiento formal en nuevas técnicas (programadores vs. ingenieros de
software)
 Resistencia al cambio
 Mitos del software:
MITOS DEL CLIENTE
- Requisitos establecidos como
una declaración general de
objetivos
- Flexibilidad del software ante
los cambios
MITOS DE GESTIÓN
- Uso de estándares
- Uso de herramientas
- Mala planificación: aumento
de programadores
MITOS DE LOS DESARROLLADORES
- Programa funcionando = fin del trabajo
- Calidad = el programa se ejecuta
sin errores
- Entrega al cliente: programa
funcionando

6.  La Ingeniería de Software es una disciplina de la Ingeniería que
concierne a todos los aspectos de la producción de software
 Los Ingenieros de Software adoptan un enfoque sistemático para
llevar a cabo su trabajo y utilizan las herramientas y técnicas
necesarias para resolver el problema planteado, de acuerdo a las
restricciones de desarrollo y recursos disponibles.

7. La computación concierne a la teoría y fundamentos de
cualquier sistema de computo, sea de hardware o de
software.
La Ingeniería de software concierne solo al desarrollo de
sistemas o productos de software.
La Ingeniería de Software todavía esta lejos de ser una
ciencia como los son la Química, la Ingeniería Civil o la
Electrónica.

8. Mantenibles.
 Debe ser posible que el software evolucione y que siga cumpliendo con sus
especificaciones.
Confiabilidad.
 El software no debe causar danos tangibles o económicos en el caso de fallos.
Eficiencia.
 El software no debe desperdiciar los recursos del sistema.
Utilización adecuada.
 El software debe contar con una interfaz de usuario adecuada y su documentación.

9. El software contiene:
Líneas de código de algún lenguaje ?
Instrucciones de computadora.
Descripción de las estructuras de datos.
Algoritmos.
Procedimientos y funciones.
Componentes de software.

10. Por su estructura:
Funcionales.
Orientados a objetos.
Orientados a listas.
Orientados a componentes.
Por su función:
Programas o Sistemas de Usuario
Interfaces Hombre-Maquina.
Herramientas de Software.
Librerías.
Sistemas de uso genérico: Compiladores, S.O’s, Procesadores de Texto, etc.
Bases de Datos.
Sistemas basados en Web.

11. INGENIERÍA DEL SOFTWARE
ORIENTADA A OBJETOS
La Programación Orientada a Objetos (OOP por sus siglas en inglés de Object Oriented
Programming) como paradigma, "es una forma de pensar, una filosofía, de la cual surge una
cultura nueva que incorpora técnicas y metodologías diferentes
La Programación Orientada a Objetos desde el punto de vista computacional "es un método
de implementación en el cuál los programas son organizados como grupos cooperativos de
objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases,
todas son miembros de una jerarquía de clases unidas vía relaciones de herencia"
Programación Orientada a Objetos

12. Análisis Orientado a Objetos
(OOA por sus siglas en inglés de Object Oriented Analysis) "es un método de análisis
que examina los requerimientos desde la perspectiva de las clases y objetos
encontrados en el vocabulario de del dominio del problema" .
Diseño Orientado a Objetos
es un método de diseño abarcando el proceso de descomposición orientado a objetos y
una notación para representar ambos modelos lógico y físico tal como los modelos
estáticos y dinámicos del sistema bajo diseño

13. EL MODELADO
Por un lado el Análisis y Diseño (OOAD) y por otro Programación (POO).Se recalcaba la
necesidad de usar lenguajes de modelado para desarrollar proyectos:
OOSE, OMT-2, Booch’93 o UML. Este último, fruto de la fusión y de mejoras de los
anteriores, aún estaba en proceso de desarrollo en Rational (compañía integrada en
IBM hoy en día).
Aun con la cotidianeidad del paradigma orientado a objetos, muchos informáticos
sumergidos en un mar de siglas se realizan la siguiente pregunta:
“Pues muy bien, ya sé UML... ¿y ahora qué?”
El Modelado es una técnica de ingeniería probada y bien aceptada.
Un modelo es una abstracción del sistema, especificando el sistema desde un cierto punto de vista y en un determinado nivel de abstracción
Un modelo es una simplificación de la realidad.

14. UNIFIED MODELING LANGUAJE (UML)
UML es un lenguaje de especificación, visualización, construcción y documentación de
propósito general, aunque especializado en sistemas software.
UML combina lo mejor de:
•Modelamiento conceptual de datos
•Modelamiento del flujo de actividades
•Modelamiento de Objetos
•Modelamiento de Componentes

15.  UML es el lenguaje de modelado orientado a objetos estándar
predominante ahora y en los próximos años.
 Razones:
 Participación de metódologos influyentes
 Participación de importantes empresas
 Estándar del OMG
 Evidencias:
 Herramientas que proveen la notación UML.

16. Modelos y Diagramas
 Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho
sistema, considerando un cierto propósito. Así, el modelo describe completa-mente
aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un
apropiado nivel de detalle.
 Diagrama: una representación gráfica de una colección de elementos de modelado, a
menudo dibujada como un grafo con vértices conectados por arcos

17. Modelos Diagramas Un proceso de desarrollo de software debe ofrecer un conjunto de
modelos que permitan expresar el producto desde cada una de las
perspectivas de interés
 El código fuente del sistema es el modelo más detallado del
sistema (y además es ejecutable). Sin embargo, se requieren otros
modelos ...

18. ... Diagramas de UML
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboración
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
DiagramsComponent
DiagramsDiagramas de
Distribución
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
Diagramas de
Actividad
Modelos
Los diagramas expresan gráficamente partes de un modelo

19. Propuesta de Rational Unified Process (RUP)
El Proceso Unificado de Desarrollo de Software
 M. de Casos de Uso del Negocio (Business Use-Case Model)
 M. de Objetos del Negocio (Business Object Model)
 M. de Casos de Uso (Use-Case Model)
 M. de Análisis (Analysis Model)
 M. de Diseño (Design Model)
 M. de Despliegue (Deployment Model)
 M. de Datos (Data Model)
 M. de Implementación (Implementation Model)
 M. de Pruebas (Test Model)

20. ¿Qué es un Proceso de Desarrollo de SW? RUP
 Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo
No existe un proceso de software universal. Las características de cada proyecto (equipo
de desarrollo, recursos, etc.) exigen que el proceso sea configurable
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software

21. Dos Dimensiones

22. El Proceso Unificado tiene dos dimensiones: (Figura 1):
Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del
proceso a lo largo de su desenvolvimiento
Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el aspecto dinámico del proceso conforme se va
desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).
La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en
términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos
y roles.
Dos Dimensiones

23.  Modelado del Negocio
 Comprender procesos del negocio
 Modelado de Requisitos
 Obtener y describir requisitos del sistema
 Análisis y Diseño del Sistema
 Identificar clases y colaboraciones para objetos del dominio
 Resolver problemas de diseño (nuevas clases y colaboraciones,
patrones..)
 Diseño de Bases de Datos
 Implementación
 Pruebas
Modelo del
Negocio
Modelo de
Requisitos
Modelo del
Análisis Modelo del
Diseño