Desarrollo de Software

Unidad 1.- Introducción a la Ingeniería de Software

Ing. José Alberto Rojas AragónModelado de Procesos de Desarrollo de SoftwareTecnologías de la Información y Comunicación

Co

nte

nid

o

• Definición de Ingeniería de Software y su importancia

• Ciclo de vida de un sistema de software

Modelado de Procesos de Desarrollo de Software

Ingeniería de software y su importancia


¿Qu

é es

ser

inge

nie

ro?

• Ingeniero: Persona que aplica los conocimientos de una o varias ramas de la ciencia para resolver cierto tipo de necesidades de la gente– Mediante el diseño, construcción u

operación de algún tipo de artefacto o sistema


Car

acte

ríst

icas

de

un

a in

gen

ierí

a

• Se necesitan conocimientos avanzados para diseñar y construir el tipo de sistemas que le caracteriza. Diferencia entre técnico e ingeniero.

• Existen dos “momentos”:– Primero, conocer el problema, y– Sólo después, podemos diseñar y construir

la solución.

• Para conseguir buenos resultados (en calidad, tiempo y costo) es necesario trabajar de forma organizada y sistemática.

• La creatividad es necesaria (diseño), pero no es suficiente, Diferencia entre artista e ingeniero.


Co

nsi

der

acio

nes

• El sentido común es muy importante

– Ley del mínimo esfuerzo

• Entre las opciones correctas elegir la más sencilla

• Reutilización (código, artefactos y conocimiento)

– No inventar la rueda

• Emplear estándares y metodologías

– Aprender de la experiencia

• Utilizar “buenas prácticas” y “lecciones aprendidas”


¿Qu

é es

el S

oft

war

e?

• Software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo


• A que se parece el software:


Tip

os

de

Soft

war

e• Un producto de software es un

producto diseñado para un usuario

– Genéricos

– Hechos a la medida

• Tipos de Software

– Interfaces Hombre Maquina

– Compiladores

– Bases de Datos

– Sistemas basados en Web

– Sistemas Operativos

– Etc….


Car

acte

ríst

icas

de

un

bu

en

soft

war

e

• Mantenibles– Debe ser posible que el software evolucione

y que siga cumpliendo con sus especificaciones.

• Confiabilidad– El software no debe causar daños físicos 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.


¿Qu

é es

Inge

nie

ría

de

Soft

war

e?

• Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software.


Def

inic

ión

IEEE

• Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de los principios y hábitos de la ingeniería al software.

• Instituto de Ingenieros en Electricidad y Electrónica (IEEE), 1993


Pro

ceso

s d

e D

esar

rollo

de

Soft

war

e

• Proceso de desarrollo de software

– Conjuntos sistemático de actividades cuya meta es el desarrollo o la evolución del software

• No existe un proceso universal efectivo para todos los contextos de proyectos de desarrollo


Def

inic

ion

es B

ásic

as• ¿Cuál es proceso de desarrollo del

software?

– Especificación: lo que el sistema debería hacer y sus restricciones de desarrollo

– Desarrollo: producción del sistema

– Validación: comprobar que el software es lo que el cliente quiere

– Evolución: cambios y mantenimiento al software con relación a los cambios de requerimientos y demandas


Otr

a p

ersp

ecti

va• Esta perspectiva establece relaciones

entre elementos que permiten responder ¿Quién debe hacer? ¿Qué debe hacer? ¿Cómo debe hacerlo?


Mo

del

os

de

Pro

ceso

G

enér

ico

s

• Modelo de Cascada– Separar en distintas fases de especificación y

desarrollo.

• Desarrollo Evolutivo– La especificación y el desarrollo están

intercalados.

• Prototipado– Un modelo sirve de prototipo para la

construcción del sistema final.

• Transformación Formal– Un modelo matemático del sistema se

transforma formalmente en la implementación.

• Desarrollo basado en Reutilización– El sistema es ensamblado a partir de

componentes existentes.


¿Cu

ánto

cu

esta

hac

er

Sofw

tare

?

• 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.

• Cuesta mas mantener el software que desarrollarlo. Para sistemas con una larga vida, este costo se multiplica.

• La distribución de los costos dependedel modelo empleado para el desarrollo del software


Co

sto

de

Efic

ien

cia


Costos

Eficiencia

Met

od

olo

gías

de

Des

arro

llo d

e So

ftw

are

• Proceso de desarrollo de software detallado y completo• Definen con precisión los artefactos, roles y actividades

involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc.

• Metodologías tradicionales (no ágiles)– Fuerte planificación durante todo el proceso de desarrollo

– Intensa etapa de análisis y diseño antes de la construcción del sistema.

• Metodologías ágiles– incremental (entregas pequeñas de software, con ciclos

rápidos)

– cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación)

– sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado)

– adaptable (permite realizar cambios de último momento)


Met

od

olo

gías

Tradicional

RUP

Agil

SCRUM

Extreme Programming

AUP

Crystal


Her

ram

ien

tas

CA

SE• Sistemas de software cuya finalidad es la

de proveer soporte automatizado para actividades de proceso o desarrollo de software.

• Los sistemas CASE son usados con frecuencia como soporte dentro de la metodología de desarrollo.– Herramientas CASE tempranas o Superiores

• Herramientas para soportar las actividades tempranas de requerimientos y diseño dentro del proceso de software;

– Herramientas CASE tardías o Inferiores• Herramientas para soportar actividades

posteriores como ser la programación, depuración y prueba o testeo.


Des

afío

s d

e la

Inge

nie

ría

de

Soft

war

e

• Heterogeneidad, entrega y confianza.

• Heterogeneidad– Técnicas de desarrollo para la construcción

de software que puedan encararse con plataformas heterogéneas y ambientes de ejecución apropiados;

• Entrega– Técnicas de desarrollo que lleven a una

entrega de software más rápida;

• Confianza– Técnicas de desarrollo que demuestren que

el software es de confianza para con sus usuarios.


Res

po

nsa

bili

dad

étic

ay

pro

fesi

on

al

• La Ingeniería de Software implica responsabilidades mayores que el simple uso de habilidades técnicas

• Los ingenieros de software deben comportarse de manera honesta y éticamente responsable si van a ser respetados como profesionales

• Comportamiento éticamente responsable es mucho más que simplemente actuar dentro de la ley


Asp

ecto

s d

e re

spo

nsa

bili

dad

p

rofe

sio

nal

• Confidencialidad – Los ingenieros deberían normalmente

respetar la confidencialidad de sus clientes independientemente de que se haya firmado o no un previo acuerdo de confidencialidad.

• Capacidad – Los ingenieros no deberían pretender

tener mayor capacidad (intelectual y laboral) de la que tienen, deben aceptar conscientemente trabajo que esté acorde a su capacidad.


Asp

ecto

s d

e re

spo

nsa

bili

dad

p

rofe

sio

nal

• Derechos de propiedad intelectual

– Los ingenieros deberían estar conscientes de las leyes que gobiernan el uso de propiedad intelectual, como ser patentes y derechos reservados. Deben ser cuidadosos al garantizar que la propiedad intelectual de sus clientes está protegida.

• Mal uso de la computadora

– Los ingenieros de software no deberían usar sus habilidades técnicas para un mal uso de las computadoras de otras personas. El mal uso de una computadora comprende desde lo relativamente simple (jugar en la computadora del cliente) hasta lo extremamente serio (diseminar virus).


Có

dig

od

e Et

ica

-P

rin

cip

ios

• Juicio

– Los ingenieros de software mantendrán su integridad e independencia de juicio como profesional.

• Gerencia

– Gerentes y líderes de Ingeniería de Software suscribirán y promoverán un acercamiento ético hacia el manejo de desarrollo de software y evolución.

• Profesión

– Los ingenieros de Software incrementarán la integridad y reputación de la profesión en constancia con el interés público.


Có

dig

o d

e Et

ica

-P

rin

cip

ios

• Colegas

– Los ingenieros de software serán condescendientes y brindarán apoyo a sus colegas.

• Uno Mismo

– Los ingenieros de software participarán en la formación continua con respecto a la práctica de su profesión y promoverán un acercamiento ético a la práctica de la profesión.


Dile

mas

Eti

cos

• Desacuerdo en principio con las políticas de administración superior.

• El empleador actúa de un modo no ético y lanza un sistema de seguridad crítico sin terminar la prueba del sistema.

• Participación en el desarrollo de armamento militar o sistemas nucleares.


Ciclos de Vida del Software


Mod

elo

s d

e D

esar

roll

o d

e

So

ftw

are

• Representación formal o simplificada del procesode software.

• Modelos Genéricos:

– Modelo de Cascada: Separar en distintas fases de especificación y desarrollo

– Desarrollo Evolutivo: La especificación y el desarrollo están intercalados

– Prototipado: Un modelo sirve de prototipo para la construcción del sistema final

– Transformación Formal: Un modelo matemático del sistema se transforma formalmente en la implementación

– Desarrollo basado en Reutilización: El sistema es ensamblado a partir de componentes existentes


Model

o d

e C

asca

da

(grá

fica

)

Diseño del Softwarey del Sistema

Implementación yPrueba de unidades

Integración y Prueba del Sistema

Operación yMantenimiento

Definición de Requerimientos


Fas

es d

el M

od

elo

de

Cas

cad

a

• Análisis de requerimientos y

definición.

• Diseño del sistema y del software.

• Implementación y prueba de unidades

• Integración y prueba del sistema.

• Operación y mantenimiento.

• La dificultad en esta modelo reside, en

la dificultad de hacer cambios entre

etapas.


Des

arro

llo

Ev

olu

tiv

o

Descripcióndel sistema

VersiónInicial

VersiónFinal

VersionesIntermedias

Especificación

Desarrollo

Validación

ActividadesConcurrentes


Des

arro

llo

Ev

olu

tiv

o• Problemas

– Poca visibilidad en el proceso

– Los sistemas están pobremente

especificados

– Se requieren habilidades especiales.

• Aplicabilidad

– Para sistemas interactivos pequeños o

medianos.

– Para partes de sistemas grandes (p.ej. la

interfaz de usuario).

– Para sistemas de corta vida.


Pro

toti

pad

o• Prototipado exploratorio

– 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.

• Prototipado de “throw-away”.

– El objetivo es entender los requerimientos

del sistema. Se puede comenzar con

especificaciones poco entendidas.


Pro

ble

mas

y R

iesg

os

con

los

Model

os.

• Cascada.

– Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.

– Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.

• Prototipado.

– Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseño se llevan a cabo paso a paso.

– Alto riesgo debido a falta de visibilidad

• Evolutivo.

– Alto riesgo debido a la necesidad de tecnología avanzada y habilidades del grupo desarrollador.


Man

ejo d

e R

iesg

os

• La tarea principal del administrador

consiste en minimizar riesgos.

• El “riesgo” inherente en una actividad es

se mide en base a la incertidumbre que

presenta el resultado de esa actividad.

• Las actividades con alto riesgo causan

sobre-costes en cuanto a planeación y

costos

• El riesgo es proporcional al monto de la

calidad de la información disponible.

Cuanto menos información, mayor el

riesgo.


Model

os

de

Pro

ceso

s

Híb

rido

s

• Los sistemas grandes están hechos

usualmente de varios subsistemas.

• No es necesario utilizar el mismo

modelo de proceso para todos los

subsistemas.

• El prototipado es recomendado cuando

existen especificaciones de alto riesgo.

• El modelo de cascada es utilizado en

desarrollos bien comprendidos.


Model

o d

e P

roce

so d

e

Esp

iral


Fas

es d

el M

od

elo

de

Esp

iral

• Planteamiento de Objetivos

– Se identifican los objetivos específicos para cada

fase del proyecto

• Identificación y reducción de riesgos.

– Los riesgos clave se identifican y analizan, y la

información sirve para minimizar los riesgos

• Desarrollo y Validación.

– Se elige un modelo apropiado para la

siguiente fase del desarrollo

• Planeación.

– Se revisa el proyecto y se trazan planes para la

siguiente ronda del espiral


Pla

nti

lla

par

a u

na

ron

da

del

esp

iral

• Objetivos.

• Restricciones.

• Alternativas.

• Riesgos.

• Resolución de riesgos.

• Resultados.

• Planes.

• Garantías (commitments).


Ven

taja

s del

Mo

del

o d

e

Esp

iral

• Centra su atención en la reutilización

de componentes y eliminación de

errores en información descubierta en

fases iniciales.

• Los objetivos de calidad son el primer

objetivo.

• Integra desarrollo con mantenimiento.

• Provee un marco de desarrollo de

hardware/software.


Pro

ble

mas

co

n e

l M

od

elo

de

Esp

iral

• El desarrollo contractual especifica el

modelo del proceso y los resultados a

entregar por adelantado.

• Requiere de experiencia en la

identificación de riesgos.

• Requiere refinamiento para uso

generalizado.


Que

model

o u

tili

zar

?• Para sistemas bien comprendidos

utiliza el Modelo de Cascada. La fase

de análisis de riesgos es relativamente

fácil.

• Con requerimientos estables y

sistemas de seguridad críticos, utiliza

modelos formales.

• Con especificaciones incompletas,

utiliza el modelo de prototipado.

• Pueden utilizarse modelos híbridos en

distintas partes del desarrollo.


Vis

ibil

idad

de

Pro

ceso

s• Los sistemas de software son intangibles

por lo que los administradores necesitan

documentación para identificar el

progreso en el desarrollo.

• Esto puede causar problemas..•El tiempo planeado para entrega de resultados puede no

coincidir con el tiempo necesario para completar una

actividad.

•La necesidad de producir documentos restringe la iteración

entre procesos.

•.El tiempo para revisar y aprobar documentos es

significativo.

• El modelo de cascada es aún el modelo

basado en resultados mas utilizado.


Docu

men

tos

del

Mo

del

o

de

Cas

cada

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.Modelado de Procesos de Desarrollo

de Software

Vis

ibil

idad

del

Mo

del

o

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.


Actividadesde Evaluación

• Construye un mapa conceptual sobre los conceptos tratados en esta presentaciónModo de entrega: correo electrónico

• Realiza un investigación sobre los ciclos de vida y las metodologías de Desarrollo que se mencionan en la presentación. Recuerda agregar tu cuestionario. Min. 5 Max. 10 PreguntasModo de entrega: impreso


Date post:	25-Mar-2016
Category:	Documents
Upload:	carola-romero-bonilla
View:	213 times
Download:	0 times

Desarrollo de Software

Documents