Inge.de.software clase 2

Ingeniería de Software

MODULOS DEL CURSO

x CONCEPTOS FUNDAMENTALES DE LA INGENIERIA DE
SISTEMAS Y DE LA INGENEIRIA DE SOFTWARE

x EL LENGUAJE UNIFICADO DE MODELAMIENTO UML

x EL MODELO ORIENTADO A OBJETOS

x UNIDADES DE CONSTRUCCION

Ingeniería de Software Diapositiva1

Ingeniería de Sistemas

CONCEPTOS FUNDAMENTALES
DE LA INGENIERIA DE SISTEMAS

“Diseño, implementación e instalación de sistemas que
incluyen hardware, software y gente.”


Objetivos

x Introducir conceptos de Ingeniería de Sistemas a los
Ingenieros de Software.
x Discutir las dificultades de la Ingeniería de Sistemas.
x Describir el concepto de realización de sistema y el
proceso de Ingeniería del Sistema.
x Discutir el concepto de confiabilidad en un contexto de
sistema.


Tópicos

x Sistemas y su ambiente.
x Realización del sistema.
x El proceso de Ingeniería de Sistemas.
x Modelado de la Arquitectura del Sistema.
x Factores Humanos.
x Ingeniería de la confiabilidad en el sistema


Que es un Sistema ?

x Un conjunto de componentes inter-relacionados trabajando
conjuntamente para un fin común. El sistema puede incluir
software, dispositivos mecánicos y eléctricos, hardware, y
ser operado por gente.
x Los componentes del sistema son dependientes de otros
componentes.
x Las propiedades y el comportamiento de los componentes
del sistema están inter-relacionados de forma compleja.


Problemas con la Ingeniería de Sistemas

x Los sistemas grandes están usualmente diseñados para
resolver problemas complejos
x La Ingeniería de Sistemas requiere un gran esfuerzo de
coordinación entre varias disciplinas.
q Existen combinaciones infinitas para el diseño de software entre
componentes.
q Existe desconfianza mutua y poco entendimiento entre distintas
disciplinas.
x Los sistemas deben diseñarse para que duren varios años
en un ambiente con cambios continuos.


Ingeniería de Software y Sistemas

x La proporción del software en los sistemas esta creciendo.
La electrónica esta siendo controlada por software, con lo
que se están remplazando los sistemas de propósito
específico.
x Los problemas de la Ingeniería de Sistemas son similares a
los de la Ingeniería de Software.
x El software ha sido visto siempre como un problema
dentro de la Ingeniería de Sistemas. Muchos proyectos
grandes se han visto retrasados por el software.


Los Sistemas y su Ambiente

x Los sistemas no son independientes, sino que existen
dentro de un ambiente.
x La función del sistema puede ser la de cambiar su
ambiente.
x Los efectos del ambiente pueden alterar el funcionamiento
del sistema. p.ej. la fuente de poder puede afectar al
sistema
x El ambiente físico y organizacional puede ser importante.


Jerarquías del Sistema

Ciudad

Barrio

Casa

Sistema de Sistema de Sistema de
Calefacción Potencia Agua

Sistema de Sistema de Sistema de
Seguridad Alumbrado Desperdicios


Procuración del Sistema

x Es la adquisición de un sistema en una organización, para
satisfacer una necesidad.
x Es necesario especificar el sistema y desarrollar la
arquitectura antes de cualquier adquisición.
q Es necesaria una especificación que permita al contratista desarrollar el
sistema.
q La especificación puede permitir comprar sistemas comerciales existentes,
que resulten mas baratos que desarrollar el sistema.


Contratistas y Sub-contratistas

x La adquisición de sistemas de hardware-software muy
grandes se hace usualmente a través de un contratista
principal.
x Los sub-contratos se hacen para que sean llevados a cabo
por otros proveedores de partes del sistema.
x El cliente contrata el sistema con el contratista principal y
no con los sub-contratistas.


Modelo Contratista/Sub-Contratista

Cliente
del Sistema

Contratista
Principal

Sub-Contratista 1 Sub-Contratista 2 Sub-Contratista 3


Proceso de Realización del Sistema

Sistema
Comercial
Adapta Elige Detalla Elige
Requerimientos Sistema Requerimientos Proveedores

Estudio de
Sistemas existentes

Envía petición Selecciona Negocia Contrato de
a desarrollador Desarrollador Contrato Desarrollo

Sistema
a Desarrollar


El Proceso de Ingeniería de Sistemas

x Involucra a Ingenieros de diferentes áreas.
q Existe mucho espacio para malentendidos aquí. Distintas disciplinas
utilizan diferente vocabulario y se requiere mucha negociación.
x Usualmente se sigue el modelo de cascada dada la
necesidad de desarrollo en paralelo de distintas partes del
sistema.
q Poco margen para iteración entre fases debido a que los cambios de
hardware pueden ser muy costosos. El software tendrá que compensar los
problemas de hardware.


Proceso de Ingeniería de Sistemas

Definición de Entrega
Requerimientos del Sistema

diseño del Evolución
Sistema del Sistema

Desarrollo de Instalación
Sub-sistemas del Sistema

Integración
del Sistema


Desarrollo Interdisciplinario

Ingeniería Ingeniería Ingeniería
de Software Electrónica Mecánica

Ingeniería Ingeniería diseño de
de Estructuras de Sistemas Interfaces

Ingeniería Ingeniería Arquitectura
Web Eléctrica


Definición de Requerimientos del Sistema

x En esta etapa se definen tres tipos de requerimientos.
q Requerimientos funcionales finos. Las funciones del sistema son definidas
en forma abstracta.
q Propiedades del sistema. Los requerimientos no-funcionales para el
sistema en general son definidos.
q Características indeseables. Comportamiento inaceptable del sistema es
especificado.
x Se deben definir también los objetivos organizacionales
para el sistema.


Objetivos del Sistema

x Objetivos Funcionales.
q Proveer un sistema de alarmas e intrusos para un edificio que proveerá
alerta interna y externa contra incendios o entradas no-autorizadas.

x Objetivos Organizacionales.
q Asegurar el funcionamiento normal del trabajo que se lleva a cabo en el
edificio, y que no sea interrumpido por eventos tales como incendios o
entradas no-autorizadas.


Problemas con los Requerimientos del Sistema

x A medida que el sistema está siendo especificado, ocurren
cambios.
x Se deben anticipar los desarrollos de hardware o
comunicaciones en el ciclo de vida del sistema.
x Difícil definir requerimientos no-funcionales del sistema,
sin tener una idea clara de un componente específico.


Proceso de Diseño del Sistema

Definición de
Descomposición de Interfaces de los
Requerimientos Sub-Sistema

Identificación Especificación
de Sub-sistemas Funcional de
Sub-Sistemas

Asignación de
Requerimientos a
los Sub-Sistema


El Proceso de Diseño del Sistema

x Partición de Requerimientos.
q Organización de requerimientos en grupos relacionados.
x Identificación de subsistemas.
q Identificar un conjunto de subsistemas que cumplen con los
requerimientos del sistema.
x Asignación de requerimientos a subsistemas.
x Especificación de funcionalidad de cada subsistema.
x Definición de interfaces entre subsistemas.
q Actividad crítica cuando se desarrolla el sistema el forma paralela.


Problemas del Proceso de Diseño del Sistema

x La partición de requerimientos de hardware, software y
componentes humanos puede involucrar mucha
negociación.
x Con frecuencia se asume que los problemas difíciles de
diseño son fácilmente resueltos por software.
x Las plataformas de software pueden ser inapropiadas para
los requerimientos de software, por lo que deben de
compensar esto.


Desarrollo de Sub-Sistemas

x Típicamente se desarrollan en paralelo con distintos
grupos de desarrolladores.
x Falta de comunicación entre grupos de trabajo.
x Si existen mecanismos burocráticos lentos para proponer
cambios en el sistema, provocarán que la planificación se
extienda.


Integración del Sistema

x Es el proceso de reunir hardware, software y gente, para
llevar a cabo un sistema.
x Debe de ser llevado a cabo de forma incremental, de forma
que los sub-sistemas sean integrados uno a la vez.
x En esta etapa, usualmente se encuentran los problemas de
interfaces.
x Puede haber problemas si no se coordina bien la entrega de
componentes del sistema.


Instalación del Sistema

x Puede haber suposiciones incorrectas en el ambiente del
sistema.
x Puede haber resistencia humana a la introducción de un
nuevo sistema.
x El sistema puede tener que co-existir con algún sistema
alternativo por algún tiempo.
x Puede haber problemas físicos en la instalación (p.ej.
cableado, etc)
x Tiene que identificarse el entrenamiento del operador.


Operación del Sistema

x Traerá problemas no contemplados en los requerimientos.
x Los usuarios podrían usar el sistema de forma no
contemplada por los Ingenieros del Sistema.
x Puede revelar problemas con la interacción con otros
sistemas.
q Problemas físicos por incompatibilidad.
q Problemas de conversión de datos.
q Errores frecuentes del operador derivados de interfaces inconsistentes.


Evolución del Sistema

x Los sistemas grandes tienen una larga vida. Pero deben
evolucionar para adaptarse a requerimientos cambiantes.
x La evolución es inherentemente costosa.
q Los cambios pueden ser vistos desde una perspectiva técnica y de
negocio.
q Los sub-sistemas interactúan de forma que en el futuro problemas no
contemplados pueden aparecer..
q No existe una racionalidad para justificar el proceso de diseño.
q La estructura del sistema se corrompe a medida que se le hacen cambios.
x La mayoría de los sistemas requieren mantenimiento.


Modelado de la Arquitectura del Sistema

x El modelo de la arquitectura presenta una visión abstracta
de los sub-sistemas que configuran el sistema.
x Incluye flujos de información entre sub-sistemas.
x Identifica distintos tipos de componentes funcionales del
modelo.


Sistema de Sistema de Sistema de Comunicaciones Sistema de
Radar Transponder Comunicaciones con el avión Telefonía

Procesador de Procesador de Procesador de .
Posicionamiento Procesador de Respaldo Comunicaciones
Respaldo

Arquitectura
de un Sistema
Base de Datos
Sistema de de Control de
Simulación del de Plan de vuelo
Tráfico Aéreo
Avión

Sistema de
mapeo de
clima
Controlador de la Consolas de
Caja Negra del Inf. del Sistema Control
Sistema

Sistema de reporte de
Actividades del Sistema


Componentes Funcionales del Sistema

x Componentes sensores.
q Obtiene información del ambiente del sistema, pe.j. radares del sistema de
control de tráfico aéreo.
x Componentes actuadores.
q Componentes que causan algún cambio en el ambiente del sistema. p.ej.
las válvulas en el proceso de control del sistema que incrementa o
decrementa el flujo de control de un ducto.
x Componentes de cómputo.
q Lleva a cabo cómputo de algunas entradas recibidas para producir
salidas. pej. el procesador de punto flotante del sistema.


Componentes Funcionales del Sistema

x Componentes de comunicaciones
q Permite comunicar distintos componentes del sistema entre sí. p.ej. los
enlaces entre un sistema de cómputo distribuido.
x Componentes de control
q Coordina la interacción de los componentes del sistema. pej. el
planificador en un sistema en tiempo real.
x Componentes de interfaces.
q Facilita la interacción entre los componentes del sistema. pej. interfaz del
operador.
x Todos los componentes son usualmente controlados
por software.


Factores Humanos

x Todos los sistemas tienen usuarios y son utilizados en un
contexto social y organizacional.
x Es necesaria una interfaz de usuario apropiada para un
control de operación efectivo.
x Los factores humanos son con frecuencia un factor que
determina el éxito o el fracaso de un sistema.
x Cambios en el proceso de trabajo causa problemas.
x Habilidades de los usuarios.
x Cambios introducidos en la organización.


Resumen

x La Ingeniería de Sistemas es difícil. Nunca habrá una
respuesta fácil en la solución de problemas de desarrollo
de sistemas complejos.
x Los Ingenieros de Software no tienen respuesta a todas las
preguntas, pero entienden el funcionamiento del sistema.
x Se debe de reconocer el papel que juega cada disciplina y
cooperar entre todas en el proceso de Ingeniería de
Sistemas.
x La Ingeniería de Sistema involucra a múltiples disciplinas.
x El Proceso de I.S sigue a menudo el modelo de cascada.



CONCEPTOS FUNDAMENTALES
DE
LA INGENIERIA DE SOFTWARE


Objetivos

x Definir la Ingeniería de Software y explicar su
importancia.
x Discutir los conceptos de producto de software y proceso
de software.
x Explicar la importancia de la visibilidad de los procesos.
x Introducir la noción de responsabilidad profesional.


Tópicos

x Productos de Software.
x El proceso de Software.
x El modelo de Espiral de Boehm.
x La visibilidad de los procesos.
x Responsabilidad profesional.



x Las economías de los países desarrollados dependen en
gran parte del software.
x Mas y más sistemas son actualmente controlados por
software.
x La Ingeniería de Software concierne a teorías, métodos y
herramientas para el desarrollo profesional de software.
x El gasto en La Ingeniería de Software, representa un alto
porcentaje del PIB de los países desarrollados.


Costos del Software

x Los costos del software a menudo dominan al costo del
sistema. El costo del software en un PC es a menudo mas
caro que la PC.
x Cuesta mas mantener el software que desarrollarlo. Para
sistemas con una larga vida, este costo se multiplica.
x La Ingeniería de Software concierne a un desarrollo
efectivo en cuanto a costos del software.


Productos de Software

x Productos genéricos.
q Productos que son producidos por una organización para ser vendidos al
mercado.
x Productos hechos a medida.
q Sistemas que son desarrollados bajo pedido a un desarrollador específico.
x La mayor parte del gasto del software es en productos
genéricos, pero hay más esfuerzo en el desarrollo de los
sistemas hechos a medida.


Características de los Productos de
Software

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


Importancia de las características del producto

x La importancia relativa de las características depende en el
tipo de producto y en el ambiente en el que será utilizado.

x En algunos casos, algunos atributos pueden dominar.
q En sistemas de seguridad críticos de tiempo real, los atributos clave
pueden ser la confiabilidad y la eficiencia.
x Los costos tienden a crecer exponencialmente si son
requeridos altos niveles de alguna característica.


Costes de Eficiencia.

Costos

Eficiencia


El Proceso de Software

x Conjunto estructurado de actividades requeridas para
desarrollar un sistema de software.
q Especificación.
q Diseño.
q Validación.
q Evolución.
x Las actividades varían dependiendo de la organización y
del tipo de sistema a desarrollarse.
x Debe estar explícitamente modelado si va a ser bien
administrado.


Características del proceso

x Entendible
q Se encuentra el proceso bien definido y es entendible ?.
x Visible
q El proceso es visible al exterior ?.
x Soportable
q Puede el proceso ser soportado por herramientas CASE ?.
x Aceptable
q El proceso es aceptado por aquellos involucrados en el ?.


Características del proceso

x Confiable
q Los errores del proceso son descubiertos antes de que se conviertan en
errores del producto ?.
x Robusto
q Puede continuar el proceso a pesar de problemas inesperados ?.
x Mantenible
q Puede el proceso evolucionar para cumplir con los objetivos
organizacionales ?.
x Rapidez
q Que tan rápido puede producirse el sistema ?.


Modelo de Ingeniería del Proceso

x Especificación - establecer los requerimientos y
restricciones del sistema
x Diseño - Producir un modelo en papel del sistema
x Manufactura - construir el sistema
x Prueba - verificar que el sistema cumpla con las
especificaciones requeridas
x Instalación - entregar el sistema al usuario y asegurar su
operacionalidad
x Mantenimiento - reparar fallos en el sistema cundo sea
descubiertos


Problemas en el Modelo del Proceso

x Normalmente, las especificaciones son incompletas o
anómalas
x No existe una distinción precisa entre la especificación, el
diseño y la manufactura
x Solo hasta que el sistema se ha producido se puede probar
x El software no se puede remplazar siempre durante el
mantenimiento


Modelos Genéricos de Desarrollo de Software

x Modelo de Cascada
x Separar en distintas fases de especificación y desarrollo.
x Desarrollo Evolutivo
x La especificación y el desarrollo están intercalados.
x Basado en Prototipos
x Un modelo sirve de prototipo para la construcción del sistema final.
x Transformación Formal
x Un modelo matemático del sistema se transforma formalmente en la
implementación.
x Desarrollo basado en Reutilización
x El sistema es ensamblado a partir de componentes existentes.


Modelo de Cascada (gráfica)

Definición de
Requerimientos

Diseño del Software
y del Sistema

Implementación y
Prueba de unidades

Integración y Prueba
del Sistema

Operación y
Mantenimiento


Fases del Modelo de Cascada

x Análisis de requerimientos y definición.
x Diseño del sistema y del software.
x Implementación y prueba de unidades
x Integración y prueba del sistema.
x Operación y mantenimiento.
x La dificultad en esta modelo reside, en la dificultad de
hacer cambios entre etapas.


Desarrollo Evolutivo
Actividades
Concurrentes

Versión
Especificación Inicial

Descripción Versiones
Desarrollo
del sistema Intermedias

Versión
Validación Final


Desarrollo Evolutivo

x Problemas
q Poca visibilidad en el proceso
q Los sistemas están pobremente especificados
q Se requieren habilidades especiales.
x Aplicabilidad
q Para sistemas interactivos pequeños o medianos.
q Para partes de sistemas grandes (p.ej. la interfaz de usuario).
q Para sistemas de corta vida.


Prototipado

x Prototipos exploratorios
q El objetivo es trabajar con clientes hasta evolucionar a un sistema final, a
partir de una especificación inicial. Se debe comenzar con unas
especificaciones bien entendidas.
x Prototipos de “throw-away”.
q El objetivo es entender los requerimientos del sistema. Se puede
comenzar con especificaciones poco entendidas.


Problemas y Riesgos con los Modelos.

x Cascada.
q Alto riesgo en sistemas nuevos debido a problemas en las especificaciones
y en el diseño.
q Bajo riesgo para desarrollos bien comprendidos utilizando tecnología
conocida.
x Prototipos.
q Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y
el diseño se llevan a cabo paso a paso.
q Alto riesgo debido a falta de visibilidad
x Evolutivo.
q Alto riesgo debido a la necesidad de tecnología avanzada y habilidades
del grupo desarrollador.


Manejo de Riesgos

x La tarea principal del administrador consiste en minimizar
riesgos.
x El “riesgo” inherente en una actividad es se mide en base a
la incertidumbre que presenta el resultado de esa actividad.
x Las actividades con alto riesgo causan sobre-costos en
cuanto a planeación y costos
x El riesgo es proporcional al monto de la calidad de la
información disponible. Cuanto menos información,
mayor el riesgo.


Modelos de Procesos Híbridos

x Los sistemas grandes están hechos usualmente de varios
subsistemas.
x No es necesario utilizar el mismo modelo de proceso para
todos los subsistemas.
x El desarrollo por prototipos es recomendado cuando
existen especificaciones de alto riesgo.
x El modelo de cascada es utilizado en desarrollos bien
comprendidos.


Modelo de Proceso de Espiral
Evalúe alternativas,
Determine objetivos identifique y resuelva
alternativas y riesgos
restricciones Análisis de
Riesgos
Análisis de
Riesgos
Análisis de
Riesgos Prototipo
Prototipo Operacional
Análisis Prototipo 3
de Proto 2
REVISIÓN Riesgos tipo 1

Plan de requerimientos Concepto de Simulaciones, modelos y benchmarks
Plan del ciclo de vida Operación Requeri
mientos de Diseño Diseño
SW del Detallado
Plan de Validación de Producto Codificación
Desarrollo Requerimientos
Prueba de
Plan de Integración Diseño Unidades
Prueba de
y Prueba V &V
Prueba de Integración
Planea la
Aceptación Desarrolla y verifica
siguiente fase
Servicio el siguiente nivel
del producto

Fases del Modelo de Espiral

x Planteamiento de Objetivos
q Se identifican los objetivos específicos para cada fase del proyecto.
x Identificación y reducción de riesgos.
q Los riesgos clave se identifican y analizan, y la información sirve para
minimizar los riesgos.
x Desarrollo y Validación.
q Se elige un modelo apropiado para la siguiente fase del desarrollo.
x Planeación.
q Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.


Plantilla para una ronda del espiral

x Objetivos.
x Restricciones.
x Alternativas.
x Riesgos.
x Resolución de riesgos.
x Resultados.
x Planes.
x Garantías (commitments).


Mejoramiento de la Calidad en el Modelo de Espiral.

x Objetivos
q Mejorar significativamente la calidad del software.
x Restricciones.
q Dentro de los 3 primeros anos.
q Sin que se produzcan grandes inversiones de capital.
q Sin que se lleven a cabo grandes cambios organizacionales.
x Alternativas.
q Reutilizar software certificado existente.
q Introducir especificaciones formales y verificación.
q Invertir en herramientas de prueba y validación.


Mejoramiento de la Calidad

x Riesgos.
q No existen mejoras en el software baratas.
q Las mejoras en la calidad pueden incrementar costes excesivamente
q Los nuevos métodos pueden causar bajas en el personal.
x Solución de riesgos.
q Estudio de la literatura existente.
q Proyecto piloto.
q Búsqueda de todos los componentes reutilizables potenciales.
q Identificación del soporte disponible de herramientas
q Entrenamiento al personal y seminarios motivacionales.



x Resultados.
q La experiencia en métodos formales es limitada - es muy difícil
cuantificar las mejoras.
q Limitado el soporte en herramientas para sistemas de desarrollo de la
compañía.
q Existencia de componentes reutilizables, pero poco soporte de
herramientas de reuso.
x Planes.
q Explorar la opción de la reutilización a mas detalle.
q Desarrollar herramientas prototipo para reutilización.
q Explorar el esquema de certificación de componentes.
x Garantías.
q Explorar los siguientes 18 meses.

Modelo de Espiral para la elaboración de un
catálogo.

x Objetivos
q Desarrollar un catálogo de componentes de software
x Restricciones.
q A un ano.
q Debe soportar los tipos de componentes existentes.
q Costo total menor de $100,000.
x Alternativas.
q Comprar software de captura de información.
q Comprar bases de datos y desarrollar el catálogo utilizando la BD.
q Desarrollar catálogo de propósito especial.



x Riesgos.
q Puede ser imposible satisfacer las restricciones.
q La funcionalidad del catálogo puede ser inapropiada.
x Solución de riesgos.
q Desarrolla un prototipo del catálogo (utilizando lenguajes de cuarta
generación 4GL y una BD existente) para clarificar los requerimientos.
q Relaja restricciones de tiempo.



x Resultados.
q Los sistemas de captura de información son inflexibles. Los
requerimientos no pueden cumplirse.
q El prototipo que utiliza la BD puede mejorarse para completar el sistema.
q El desarrollo de un catálogo de propósito específico no es costeable.
x Planes.
q Desarrolla el catálogo utilizando una BD existente mejorando el prototipo
y la interfaz de usuario.
x Garantías.
q Explorar los siguientes 12 meses.


Flexibilidad en el modelo de Espiral

x Para sistemas bien comprendidos utiliza el Modelo de
Cascada. La fase de análisis de riesgos es relativamente
fácil.
x Con requerimientos estables y sistemas de seguridad
críticos, utiliza modelos formales.
x Con especificaciones incompletas, utiliza el modelo de
prototipos.
x Pueden utilizarse modelos híbridos en distintas partes del
desarrollo.


Ventajas del Modelo de Espiral

x Centra su atención en la reutilización de componentes y
eliminación de errores en información descubierta en fases
iniciales.
x Los objetivos de calidad son el primer objetivo.
x Integra desarrollo con mantenimiento.
x Provee un marco de desarrollo de hardware/software.


Problemas con el Modelo de Espiral

x El desarrollo contractual especifica el modelo del proceso
y los resultados a entregar por adelantado.
x Requiere de experiencia en la identificación de riesgos.
x Requiere refinamiento para uso generalizado.


Visibilidad de Procesos

x Los sistemas de software son intangibles por lo que los
administradores necesitan documentación para identificar
el progreso en el desarrollo.
x Esto puede causar problemas..
q El tiempo planeado para entrega de resultados puede no coincidir con el
tiempo necesario para completar una actividad.
q La necesidad de producir documentos restringe la iteración entre
procesos.
q El tiempo para revisar y aprobar documentos es significativo.
x El modelo de cascada es aún el modelo basado en
resultados mas utilizado.


Documentos del Modelo de Cascada

Actividad Documentos Producidos
Análisis de Requerimientos Documento de Requerimientos
Definición de Requerimientos Documento de Requerimientos.
Especificación del Sistema. Especificación Funcional, Plan de Pruebas
de Aceptación.
Diseño Arquitectural Especificación de la Arquitectura, y Plan de
Pruebas del Sistema
Diseño de Interfaces Especificación de la Interfaces y Plan de
pruebas de Integración.
Diseño Detallado Especificación del diseño y Plan de prueba
de Unidades.
Codificación Código de Programa
Prueba de Unidades Reporte de prueba de unidades
Prueba de Módulos Reporte de prueba de módulos
Prueba de Integración Reporte de prueba de integración y Manual
de usuario final
Prueba del Sistema Reporte de prueba del sistema
Prueba de Aceptación Sistema final mas la documentación.


Visibilidad del Modelo

Modelo de Proceso Visibilidad del Proceso
Modelo de Cascada Buena visibilidad, cada actividad produce un
documento o resultado
Desarrollo Evolutivo Visibilidad pobre, muy caro al producir
docuementos en cada iteración.
Modelos Formales Buena visibilidad, en cada fase deben
producirse documentos.
Desarrollo orientado a la reutilización Visibilidad moderada. Importante contar con
documentación de componentes reutilizables.
Modelo de Espiral Buena visibilidad, cada segmento y cada
anillo del espiral debe producir un
documento.


Responsabilidad profesional

x Los Ingenieros de software no solo deben considerar
aspectos técnicos. Deben tener una visión mas amplia, en
lo ético, social y profesional.
x No existe estatutos para ninguno de estos aspectos.
q Desarrollo de sistemas militares.
q Piratería.
q Que es mejor para la profesión de Ingeniero de Software.


Aspectos Éticos

x Confidencialidad.
x Competencia.
x Derechos de propiedad intelectual.
x Mal uso de la computadora.


Resumen

x La Ingeniería de software concierne a las teorías, métodos
y herramientas para el desarrollo, administración y
evolución de productos de software.
x Los productos de software consisten de programas y
documentación. Los atributos de los productos son,
mantenibilidad, robustez, eficiencia y usabilidad.
x El proceso de software consiste en aquellas actividades
involucradas en el desarrollo de software.


Resumen

x El modelo de cascada considera cada actividad del proceso
como una actividad discreta.
x El modelo de desarrollo evolutivo considera actividades
del proceso en forma concurrente.
x El modelo de espiral se basa en análisis de riesgos.
x La visibilidad del proceso involucra la creación de
documentos o resultados de las actividades.
x Los Ingenieros de software deben tener responsabilidades
éticas, sociales y profesionales.


Inge.de.software clase 2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Inge.de.software clase 2

Similar to Inge.de.software clase 2 (20)

Inge.de.software clase 2