Sei sulla pagina 1di 15

Ingieniería de software (1968)

- Desarrollar software de calidad a tiempo y dentro del presupuesto


+ Surge por desarrolladores sin objetivos concretos e incapaces de determinar los
recursos necesarios.
+ Sirve para definir la construcción de productos de alta calidad usando
componentes elaborados e integrandolos bajo restricciones de tiempo y presupuesto.
- Complejidad y Cambio
+ Los sistemas de software útiles son complejos.
* Necesitan evolucionar con las necesidades de los usuarios finales y su
ambiente de destino.
$ Ej. Facebook; Continúamente actualiza sus herramientas, además que se ha
motado su funcionamiento en dispositivcs móviles.

Fallas en la ingieniería de software


- Error del año 1900
+ Existió una persona que nació en 1898; fué invitada a inscribirse en un jardin de
niños en 1902 cuando tenía ciento cuatro años de edad.
- Error del año bisiesto
+ Hace un par de años multarón mil dólares a un supermercado por tener carne con
caducidad expirada; los programadores no considerarón los años bisiestos.
- Mal uso de la interfaz
+ El 10 de Abril de 1900 Londres, un tren partió sin chofer debido a que el sistema
permitia que el tren partiera a tiempo siempre y cuando estuvierán las puertas
cerradas; una puerta de habia atascado, el chofer se bajó a resolver el problema y
antes que se percatará el tren partió.
- Seguridad
+ 2 de Noviembre de 1988, se dio a conocer el gusano de internet que afectó gran
decenas de equipos y requirió de varios dias para eliminar la infección. Se propagó
por medios del sistema de correo de Unix.
- Retrasos y exedido de presupuesto
+ En 1995, el aereopuerto internacional de Denver experimento de 16 meses de
retraso y 3.2 mil millones de dólares extras para la construcción del sistema de
manejo de equipaje automatizado.
- Entrega a tiempo
+ En 1984 la compañia de seguros Wisconsin recibe un sistema de software
desarrollado en 18 meses. El sistema no funcionó se expidierón 60 millones de pagos
extras para hacer ajustes y 3 años más de desarrollo.
- Complejidad innecesaria
+ El avión de carga C-17 de McDonmell se exedió 500 millones de dólares por
problemas en el software. Se instalarón 19 computadoras, 80 microprocesadores y 6
lenguajes de programación diferentes.

¿Qué es la ingieniería de software?


- Cumple con objetivos diferentes
- Tiene muchos componentes
- Se usa para solucionar problemas
+ Via experimentación
- Acotada a presupuestos y tiempos de entrega
+ Comúnmente apoyados en métodos empiricos
- Necesaria para la adquisición de conocimiento
+ Vía modelado de los dominios de aplicación
* Datos
* Soluciones
+ No es lineal; un solo dato puede invalidar modelos completos.
- Es dirigida por fundamentación
+ Considera el contexto( condiciones iniciales, singulares y generales) sobre
desiciones y razones tras las mismas.
+ Es representada por modelos de problemas
* Estos modelos permiten predecir impactos de un cambio

Modelado
- Necesario para describir y comprender sistemas complejos
+ Sistemas de átomos
+ Sociedades de seres humanos
+ Sistema solar
- También se puede usar para describir sistemas artificiales
+ Sistemas de reservación de boletos
+ Comercialización de acciones
- Es uno de los métodos básicos de la ciencia
- Se usa para representación abstracta de la ciencia
+ Para análizar carácteristicas o comportamiento relevantes
+ Permite responder preguntas
- Es usado para visualizar y comprender
+ Sistemas que ya no existen
+ Sistemas que se supone que existen
- Manejan dos tipos de entidades
+ Sistemas del mundo real observado
* Como función de un conjunto de fenomenos
+ Dominio del problema
* Conjunto de conceptos interdependientes
$ Describe aspectos relevantes en el problema
- Se tiene que identificar el ambiente
- Se tiene que comprender los sistemas
+ Para evaluar soluciones y compromisos
- Combina métodos orientados a objetos
+ Dominio del problema
* Como conjunto de objetos y relaciones
+ Rango de solución
* Se modelan como objetos los conceptos de solución
$ El conjunto de líneas para representar un tren o una transacción son objetos
que son parte del dominio de solución
* Es una extensión del dominio del problema
- Utilizado para abordar el problema de usuario final

Solución de problemas
- Comúnmente mediante ensayo y error
+ Con recursos limitados y conocimiento incompleto
- El método de la ingieniería
+ 1.- Formular el problema
+ 2.- Análizar el problema
+ 3.- Búscar soluciones
+ 4.- Decidir cual es la solución
+ 5.- Especificar la solución
- En el desarrollo de software
+ Obtención de requerimientos
+ Análisis
+ Diseño del sistema
+ Diseño de objetos
+ Implementación
* Se compara modelo contra el proceso de desarrollo
$ Calendarización y desarrollo
% Se obtiene productos entregables y recursos gastados

Adquisición de conocimiento
- El desarrollo no es lineal
+ Un dato puede invalidar el conocimiento adquirido
* Es necesario implementar un desarrollo básado en riesgo
$ Es importante anticipar sorpresas tardias en un proyecto
% Identificando componentes de alto riesgo
$ Todas las actividades se desarrollan en paralelo
% Son dificiles de manejar

Administración de la fundamentación
- Los requerimientos de un sistema cambian constantemente
+ Los modelos de dominio de aplicación se estabilizan una vez los desarrolladores
adquieren comprensión adecuada del problema
- Su objetivo es comprender el contexto de cada decisión de deseño
- 1.- Contiene mayor información que los modelos de solución
- 2.- La información sobre fundamentación no es explicita

Conceptos de ingieniería de software


- Proyecto; sistema de software
+ Actividades
* Tareas
% Consume recursos; participantes, tiempo ó equipo
% Genera productos de trabajo; sistema, modelo ó documento
+ Se usa UML (Unified Modeling Language)
Participantes y Papeles
- Diciplinas
+ Personas
* Construyen sistema
- Gerente
+ Planea
+ Calcula presupuesto de proyecto
+ Coordina desarrolladores y clientes
- Papeles
+ Usuario final
+ Cliente
+ Desarrollador
- Participantes
+ Alicia
+ Juan
+ Marcos
+ Zoe
+ Compañia de trenes
+ Viajeros

Sistemas y Modelos
- Sistema
+ Término usado para referirnos a la realidad subyacente
- Modelo
+ Término usado para referirnos a cualquier nivel de abstracción de la realidad
- La calendarización del proyecto, su presupuesto y su tiempo de entrega
planeado son modelos del proyecto de desarrollo.

Productos de trabajo
- Artefacto producido
+ Documento ó fragmento de software
* Involucra a cliente ó desarrollador de software
$ Generan producto de trabajo interno
% Que establecen Entrega
# Definidas antes de inicio del proyecto
# Especificadas en un contrato

Actividades, tareas y recursos


- Actividad
+ Tareas
* Genera productos de trabajo
$ Consume recursos; tiempo, equipo y mano de obra
* Ej. Definir requerimientos con el cliente
* Entregar
$ Instalar sistema en ubicación operacional (en sentido más práctico)
+ Puede tener otras actividades
* También se les llama fases
* Entregar; instalación, entrenamiento ( en sentido más teórico)

Objetivos, requerimientos y restricciones


- Objetivo
+ Principio de alto nivel para guiar al proyecto
+ Define atributos importantes del sistema
+ Difícil conseguirlo de forma simultanea
* Ej. cumplir con tiempo, calidad y presupuesto
- Requerimiento funcional
+ Tiene que cumplir con funcionalidad
+ Ej. generar informes sobre la venta de boletos
- Requerimiento no funcional
+ Restricción para operar el sistema
+ Ej. generar informes sobre la venta de boletos en menos de un segundo

Notaciones, métodos y metodologías


- Notación
+ Reglas para representar un modelo
* Pueden ser diagramas UML ó alfabeto romano
- Método
+ Conjunto de reglas para la solución de un problema que se puede repetir
- Metodología
+ Colección de métodos para la solución de un tipo de problema

Desarrollo de actividades con la ingieniería de


software
- Manejar la complejidad mediante modelos del dominio del problema
+ 1.- Obtención de requerimientos; propósito del sistema
+ 2.- Análisis
+ 3.- Diseño del sistema
+ 4.- Diseño de objetos
+ 5.- Implementación
- I.- Produce descripción del sistema en términos de actores y casos de uso
+ Usuarios finales
+ Otras computadoras
+ Secuencia de cuentas entre un actor y el sistema
- 2.- Traduce casos de uso en un modelo de objeto que describe el sistema
+ Correcto
+ Completo
+ Consistente
+ Claro
+ Realista
+ Verificable
- 3.- Define objetivos de desarrollo del proyecto, estructura el sistema en
subsistemas que pueden realizar equipos individuales. Se define el hardware,
software, persistencia de datos, flujo de control global, politica de control de
acceso y manejo de condiciones de frontera( alcances).
- 4.- Diseño de objetos; objeto personalizado para cubrir el hueco entre modelo de
análisis, hardware y software definidos en el diseño del sistema.
- 5.- Traducir el modelo en código fuente.

Administración del desarrollo de software


- Para cumplir con tiempo, calidad y presupuesto
+ Planeación del proyecto
+ Supervisión del estado
+ Seguimiento de cambios
+ Coordinación de recursos
- Actividades
+ Comunicación
+ Administración de la fundamentación
+ Pruebas
+ Administración de la configuración del software
+ Administración del proyecto
+ Actividades del modelado del ciclo de vida que tiene el software

UML (Lenguaje unificado de modelado)


- Notaciones
+ Sirven para resaltar ideas con forma resumida y precisa
+ Contienen una semantica(significado) definida
* Adecuada
$ Comprendida
% Se alínea con estandares y convenciones
% Elimina malas interpretaciones y ambiguedad
+ Para el curso se consideran 5 notaciones (hay aproximadamente 14)
* Diagramas de casos de uso
* Diagramas de clase
* Diagramas de secuencia
* Diagramas de gráfica de estado
* Diagramas de actividad
+ Modelo funcional (las que describen su comportamiento)
* Diagramas de casos de uso
$ Describe funcionalidad desde el punto de vista de usuario(hay varios
actores)
+ Modelo de objetos (las que describen la estructura)
* Diagramas de clase
$ Describe la estructura del sistema
% Objetos, atributos, asociaciones y operaciones
+ Modelo de operación o dinámico
* Diagramas de secuencia, diagramas de gráfica de estado y diagramas de
actividad
* Describen comportamiento como secuencia de mensajes, comportamiento con
base a estados y transacciones entre ellos.

Diagramas de casos de uso


- Se usan durante la obtención de requerimientos
- Siven para el análisis de funcionalidad del sistema
- Describen desde el punto de vista de un tercero
- Actor describe la entidad que interactúa con el sistema
- Identifica actores y casos de uso (entidades y funciones)
+ Sirve para definir las fronteras del sistema
* Identificar las tareas realizadas por el sistema
$ Definir casos de uso dentro de la frontera del sistema
* Identificar las tareas realizadas por el ambiente del sistema
* Identificar a los actores, están fuera de la frontera del sistema
- Entidades
+ Tangibles
+ Intagibles
+ Tienen atributos y relaciones entre entidades

Diagramas de clase
- Describen la estructura del sistema
+ Son abstracciones de sistemas informáticos
* Tienen un comportamiento común de un conjunto de objetos
$ Se crean, modifican ó destruyen durante la ejecución
% Tienen estados con base a sus atributos y relaciones entre objetos
+ Con base, clases, atributos, operaciones, y sus asociaciones
Diagramas de secuencia
- Formalizar el comportamiento del sistema
+ Visualizar el comportamiento entre objetos
* Los objetos que participan en cada uno de los casos de uso

Diagramas de gráfica de estado


- Describe el comportamiento de un estado con otros estados y transacciones entre
ellos
+ Un estado representa al conjunto particular de valores de variables para un objeto

Diagramas de actividad
- Describe el sistema desde el punto de vista de actividades
+ Presentadas a modo de estado que concentra un conjunto de actividades
* La terminación dispara transición hacia otra actividad
* Representan el flujo datos
$ Objetos que intercambian entre operaciones
- Los rectangulos redondeados representan actividades
- Las flechas son transiciones entre actividades
- Las barras gruesas son sincronización del flujo de control

Obtención de requerimientos
- Nadie esta exento de cometer errores. Lo importante es aprender de ellos. Karl
Popper.
- Requerimiento
+ Carácteristica del sistema
+ Restricción de funcionalidad del sistema
- Da como resultado especificación del sistema
- Da como resultado un modelo de análisis que los desarrolladores interpretan sin
ambigüedad
- Requiere de varios grupos de participantes con varios niveles de conocimientos
- Sirve para definir convenciones de notación
+ Metros o kilometros
+ Punto décimal o coma para separar números
+ Preguntas de confirmación que hará el sistema al usuario
+ Método abreviado para operar el sistema
* Combinación de teclas
- Constituye "especificación del sistema"
+ Sirve como contrato entre clientes y desarrolladores
- La obtención de requierimientos y el análisis sucedes con forma concurrente
+ Se enfocan en la visión del usuario
* Funcionalidad
* Casos de uso
* Manejo de errores
* Condiciones "ambientales" de funcionamiento
- Actividades
+ Identificación de actores
+ Identificación de escenarios
+ Identificación de casos de uso
+ Identificación de relaciones entre casos de uso
+ Identificación de requerimientos no funcionales
- Implementa metodologias para obtención de información y toma de desiciones
+ Diseño conjunto de aplicaciones (JAD); desarrolladores, usuarios y clientes
+ Conocimiento de análisis de tareas (KAT); Obtención de requerimientos
mediante observación
+ Pruebas de utilidad; Validación del modelo de obtención de requerimientos con el
usuario mediante métodos diversos

Modelo formal del sistema


- Pretende ser correcto, completo, consistente y verificable
- Es orientado a objetos
+ Diagramas de clases, diagramas de gráfica de estados y diagramas de secuencia
- Identifica ambiguedades causadas por impresiciones inherentes al lenguaje natural y
por suposiciones de los autores acerca de las especificaciones.
+ Mediante la formalización
* Es una actividad iterativa
- Se enfoca en la estructuración y formalización de los requerimientos obtenidos de
los usuarios
+ Puede no ser comprensible por usuarios o clientes

Conceptos de análisis
- Objetos de entidad, frontera y control
+ 1.- Las entidades persistentes rastreadas por el sistema
+ 2.- Los objetos que tienen interacción entre usuarios y sistema
+ 3.- Las tareas realizadas por el usuario y soportadas por el sistema
- Multiplicidad de asociación
+ Diagramas de clase; el extremo de una asociación puede etiquetarse con un
conjunto de enteros llamados multiplicidad.
* Indica la cantidad de vinculos que pueden originarse desde la instancia de la
clase conectada al extremo de la asociación
+ Tipos de asociación
* Asociación de uno a uno; 1 en cada extremo
* Asociación de uno a muchos; 1 en cada extremo y 0..n (ó *)
* Asociación de muchos a muchos

Asociaciones calificadas
- Calificación
+ Técnica para la reducción de multiplicidad usando claves
+ Las asociaciones de 0..1 ó 1 son más fáciles de comprender que las
asociaciones con multiplicidad de 0..n ó 1..n
+ Se reduce la multiplicidad usando algún atributo de la entidad como clave,
también llamada calificador y se le llama "asociación calificada"

Generalización
- Permite organizar conceptos con forma jerarquica
+ En la parte superior se encuentra el concepto más general y en la parte inferior el
concepto más especifico
+ Se le llama herencia a un concepto similar en lenguajes de programación
* Se usa para la reutilización de código
- Actividades de análisis
+ Identificación de objetos de entidad
+ Identificación de objetos frontera
+ Identificación de objetos control
+ Diagramas de secuencia; para describir las relaciones entre objetos a lo largo del
tiempo
+ Identificación de asociaciones
* Diagramas de clase
$ Identificación de atributos
% Propiedades de objetos individuales
# Involucra; Nombre, Descripción y un tipo de dato

1. Describe la computadora gráficamente primero con base su estructura


y después con base su organización.

Estructura: Hardware, kenel, aplicaciones, usuarios.


Organización: CPU, teclado, impresora, memoria,pantalla.

2. Menciona la justificación para usar teoría de ingeniería de software


con el desarrollo de sistemas de información.

Sirve para definir la construcción de productos de alta calidad usando


componentes elaborados e integrándolos bajo restricciones de tiempo y
presupuesto.
- Complejidad y Cambio
Los sistemas de software útiles son complejos.
Necesitan evolucionar con las necesidades de los usuarios finales y su
ambiente de destino.

3. ¿Qué es un sistema de software?

 Cumple con objetivos diferentes


 Tiene muchos componentes
 Se usa para solucionar problemas
 tiene un ciclo de vida de muchos años.

4.- Menciona las etapas de desarrollo de software donde se puede usar


modelado.

 Obtención de requerimientos
 Análisis
 Diseño del sistema
 Diseño de objetos
 Implementación
 Se compara modelo contra el proceso de desarrollo

5. Menciona el modelo de datos usado para representar sistemas de


información.

UML
Modelo Dinámico: Diagrama de secuencia, diagramas de grafica de estado,
diagramas de actividad.

6. ¿Para qué sirve la administración de la fundamentación en el


modelado de sistemas de información?

Para adquirir conocimiento, solucionar problemas.


Para comprender el contexto en cada decisión:
1.- Contiene mayor información que los modelos de solución
2.- La información sobre fundamentación no es explicita

7. Menciona los conceptos usados de ingeniería de software para


describir la estructura de un problema.

Proyecto, sistema de software


-Tareas:
- Consume recursos; participantes, tiempo ó equipo
-Genera productos de trabajo; sistema, modelo ó documento
- Se usa UML (Unified Modeling Language)

8. Menciona los conceptos: objetivos, requerimientos y restricciones.

 Objetivos: Principio de alto nivel para guiar al proyecto, define atributos


importantes del sistema
 Requerimientos: Tiene que cumplir con funcionalidad
 Restricciones: Restricción para operar el sistema

9. Menciona con forma general las actividades realizadas por la


ingeniería de software.

1. Obtención de requerimientos; propósito del sistema


2. Análisis
3. Diseño del sistema
4. Diseño de objetos
5. Implementación

10. Menciona las características relevantes que describen puntualmente al


modelado UML.

Sirven para resaltar ideas con forma resumida y precisa.


contiene una semántica resumida adecuada.
Se alinea con estándares y convenciones
11. Menciona las características relevantes que describen la etapa de
obtención de requerimientos.

 características del sistema, restricción de funcionalidad del sistema


 Da como resultado especificación del sistema
 Requiere varios grupos de participantes con varios niveles de conocimiento
 sirve para definir convenciones de anotación:

 Punto decimal o coma para separar números


 Preguntas de confirmación que hará el sistema del usuario
 Método abreviado para operar el sistema

Potrebbero piacerti anche