DEFINICIN DE IS

La ingeniera de software es una aplicacin prctica del conocimiento cientfico para proveer metodologas y tcnicas que ayuden a
desarrollar sistemas de software a tiempo, y a su vez que aseguren que el desarrollador cumpla con las expectativas de calidad y
permanezca dentro del presupuesto.
2.2. HISTORIA DE LA ING DE SW
El termino de ingeniera de software empez a usarse a finales de los 60, en octubre de 1968, segn Alan Davis como "la aplicacin
inteligente de principios probados, tcnicas, lenguajes y herramientas para la creacin y mantenimiento, dentro de un coste razonable,
de software que satisfaga las necesidades de los usuarios".
Su origen se debi a que el entorno de desarrollo de sistemas software adoleca de:
Retrasos considerables en la planificacin, Poca productividad, Elevadas cargas de mantenimiento, Demandas cada vez ms desfasadas frente a las
ofertas, Baja calidad y fiabilidad del producto, Dependencia de los realizadores
Cmo se define crisis?
La palabra crisis "un punto decisivo en el curso de algo; momento, etapa, o evento decisivo o crucial". Para el software no ha habido
ningn punto crucial, slo una lenta evolucin.
La crisis en la industria del software permanece durante muchos aos, Lo que si se podra decir es que hay un problema crnico en el
desarrollo de software.
debido a la falta de: Formalismo y metodologa, Herramientas de soporte
Actualmente la evolucin de la Ingeniera del Software, tiene nuevos mtodos y herramientas formales que van a permitir en el futuro
un planteamiento de ingeniera en el proceso de elaboracin de software.
Dicho planteamiento permitir dar respuesta a los problemas de:
- Administracin
- Calidad
- Productividad
- Fcil mantenimiento
Este ltimo es uno de los grandes problemas, pues puede llegar a suponer un importe superior al 60% del total del coste del software.
Porque se crea la Ingeniera de Software??
La ingeniera de software se crea debido a las siguientes caractersticas:
Confiable y realizar slo las tareas especificadas en los requerimientos.
El producto debe ser robusto. Esto quiere decir que el software se comporta de manera razonable, incluso en circunstancias no
anticipadas desde el principio.
Reutilizable, de manera tal que pueda ser incorporado en otro producto de software si se requiere.
Eficiente en el uso de los recursos del sistema.
Evolutivo, de forma tal que se pueda agregar funcionalidad adicional sin efectos perjudiciales.
Cumplir con los requerimientos de rendimiento especificados, es decir, debe cumplir algunas de las restricciones relacionadas al
rendimiento.
Portable, es decir que puede trabajar bajo diferentes plataformas de software y ambientes.
El producto de software debe ser utilizable, su uso debe ser los suficientemente sencillo por parte de personas no especialistas.
2.3. CARACTERSTICAS DEL SOFTWARE
El software se desarrolla o construye no se fabrica.
El desarrollo del software y la construccin del hardware son actividades fundamentalmente diferentes.
En ambas actividades la buena calidad se adquiere mediante un buen diseo, pero la fase de construccin del hardware
puede introducir problemas de calidad que no existen (o son fcilmente corregibles) en el software.
Ambas actividades dependen de las personas, pero la relacin entre las personas dedicadas y el trabajo realizado es
completamente diferente para el software.
Ambas actividades requieren la construccin de un producto pero los enfoques son diferentes.
Los costos del software se concentran en la ingeniera. Esto significa que los proyectos de sw no se pueden manejar como si
fueran proyectos de fabricacin.

2.3. CARACTERSTICAS DEL SOFTWARE

Aunque la industria tiene una tendencia hacia la construccin por componentes, la mayora del software an se construye a la
medida.
En el mundo del hardware, la reutilizacin de componentes es una parte natural del proceso de ingeniera. En el mundo del
software es el inicio.
2.4. MITOS DEL SOFTWARE
En la actualidad, la mayora de los profesionales reconocidos en la ingeniera del software identifican los mitos en su real dimensin: actitudes
equivocadas que han causado problemas serios a los administradores y al personal tcnico por igual. Sin embargo, las antiguas actitudes y viejos
hbitos son difciles de modificar, por lo que an subsisten creencias falsas sobre el software.
Mitos de los administradores
Mitos de los Clientes
Mitos de los administradores
Mito 1. Ya se tiene un libro lleno de estndares y procedimientos para la construccin de software. Esto proporcionar a mi gente todo el
conocimiento necesario?
Mito 2. Si se est atrasado en el itinerario es posible contratar ms programadores para as terminar a tiempo.
Mito 3. Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compaa lo construya.
Mitos de los Clientes
Mito 1. Un enunciado general de los objetivos es suficiente para comenzar a escribir programas; los detalles se pueden afinar despus.
Mito 2. Los requerimientos del proyecto cambian de manera continua, pero el cambio puede ajustarse con facilidad porque el software es flexible.
Mitos de los Desarrolladores
Mito 1. Una vez que el programa ha sido escrito y puesto a funcionar, el trabajo est terminado.
Mito 2. Mientras el programa no se est ejecutando, no existe forma de evaluar su calidad.
Mito 3. El nico producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa en funcionamiento.
Mito 4. La Ing de Sw obligar a emprender la creacin de una documentacin voluminosa e innecesaria y de manera invariable tornar ms lento el
proceso.
2.5. CAPAS DEL SOFTWARE
Capa de Herramientas
Las herramientas de la Ingeniera de Software proporcionan un enfoque automtico o semi-automtico para el proceso y para los mtodos.
Capa de los Mtodos
Indican como construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo,
construccin de programas, pruebas y mantenimiento.
Capa del Proceso
Forman la base del control de gestin de proyectos del software y establecen contexto en el que se aplican los mtodos tcnicos.
2.6. EL PROCESO DEL SOFTWARE
2.6. EL PROCESO DEL SOFTWARE
Establece un marco comn del proceso definiendo un pequeo numero de actividades del marco de trabajo que son aplicables a todos
los proyectos del software, con independencia de su tamao o complejidad.

Marco comn del Proceso de Software

Formalizacin del proceso de desarrollo

Procesos bien establecidos para la realizacin de actividades de desarrollo, construccin, fabricacin, etc.
El ciclo de vida es el proceso de desarrollo y mantenimiento del software. Segn el modelo elegido se describen un conjunto de
actividades para llevar a cabo el ciclo de vida,
Los modelos clsicos:
MODELO EN CASCADA
MODELO EN V
Prcticamente identifican actividades similares y slo se diferencian en la forma de presentacin
MODELO EN CASCADA
ANLISIS, determinar qu debe hacer el software -> especificacin
DISEO, descomponer y organizar el sistema para que los mdulos puedan ser desarrollados por separado
CODIFICACIN, escribir el cdigo fuente de cada mdulo y realizar sobre ellos las pruebas necesarias
INTEGRACIN, combinar todos los mdulos y probar el sistema completo antes de pasar a su explotacin
MANTENIMIENTO, durante la explotacin es necesario realizar cambios ocasionales bien para corregir errores o para introducir mejoras,
Se trata de aislar cada fase de las otras, lo que facilita la especializacin de los desarrolladores. Al final de cada fase se requiere un
proceso de revisin`para evitar que los errores se propaguen a fases posteriores provocando la vuelta atrs.
MODELO EN CASCADA AMPLIADO
MODELO EN CASCADA
Cada fase debe generar una informacin de salida precisa y suficiente:
DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es una especificacin precisa y completa a partir de los requisitos
establecidos por el cliente.
DOCUMENTO DE DISEO DEL SOFTWARE (SDD),descripcin de la estructura global del sistema, especificacin de qu debe
hacer cada uno de los mdulos y de cmo se combinan.
CDIGO FUENTE, el programa debidamente comentado (documentacin interna).
SISTEMA SOFTWARE, el ejecutable producto dela fase de integracin y la documentacin de las pruebas realizadas.
DOCUMENTOS DE CAMBIOS, despus de cada modificacin realizada en la fase de mantenimiento: problema detectado y
solucin adoptada
MODELO EN V
MODELO EN V AMPLIADO

MODELO EN V
Incluye fases similares a las del modelo en cascada pero de forma jerrquica. En horizontal se representa el avance en el desarrollo y en
vertical el nivel de detalle.
VERIFICACIN, comprobacin de que una parte del sistema cumple con sus especificaciones.
VALIDACIN, comprobacin de que un elemento satisface las necesidades del usuario identificadas durante el anlisis.
PROTOTIPOS
En los modelos clsicos revisin de resultados al final de cada fase para evitar la vuelta atrs, orientados a una forma de desarrollo lineal.
PROTOTIPO, es un sistema auxiliar que permite probar experimentalmente soluciones parciales a los requisitos del sistema
Para que el coste de desarrollo del prototipo sea bajo en relacin al del sistema final podemos:
Limitar las funciones
Limitar su capacidad
Limitar su eficiencia
Evitar limitaciones de diseo, utilizando un hardware ms potente que el que ejecutar el sistema finaL
Reducir la parte a desarrollar
PROTOTIPOS RPIDOS
Su finalidad es solo adquirir experiencia, no se aprovechan como producto (usar y tirar). Se denominan maquetas cuando su
funcionalidad o capacidad es muy limitada.
El sistema final se codifica totalmente partiendo de cero, no se aprovecha el cdigo del prototipo
Lo importante de estos prototipos es que se desarrollen en poco tiempo.
PROTOTIPOS RPIDOS

PROTOTIPOS EVOLUTIVOS
En este caso se intenta aprovechar al mximo el cdigo del prototipo, y para ello se emplea el mismo hardware/software del sistema
final.
Se realizan fases de anlisis y diseo parcial, que se van ampliando hasta construir el sistema final mediante adiciones sucesivas.
Se puede considerar un modelo en cascada en bucle, de manera que en cada iteracin se va avanzando en el desarrollo.
HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se emplean lenguajes de 4 generacin, que son de alto nivel y de tipo
declarativo. Tambin se emplean lenguajes de especificacin, como VDM y Z. Si disponemos del compilador correspondiente podemos
obtener automticamente el cdigo del prototipo.
En el desarrollo de prototipos es clave la reutilizacin de software
PROTOTIPOS EVOLUTIVOS

MODELO EN ESPIRAL
Puede considerarse como un refinamiento del modelo evolutivo general que introduce el anlisis de riesgo como elemento fundamental
para guiar la evolucin del proceso de desarrollo.
En la dimensin radial se representa el esfuerzo realizado en el desarrollo (siempre creciente)
En cada iteracin 4 fases:
PLANIFICACIN, determina que parte del desarrollo se abordar en ese ciclo.
ANALISIS DE RIESGO, evaluar diferentes alternativas para esa parte del desarrollo seleccionando la ms ventajosa y
tomando precauciones para evitar los posibles inconvenientes.
INGENIERA, las actividades de los modelos clsicos
 EVALUACIN, se analizan los resultados de la fase de ingeniera.

MODELO EN ESPIRAL

2.7. SOFTWARE DE ALTA CALIDAD

Qu es calidad?
El grado en que un sistema, componente, o proceso cumple con los requerimientos especificados, y las necesidades y/o expectativas del
cliente o usuario.
Pressman (2002) se refiere a la calidad del
software como
La concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados, y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.
Las definiciones anteriores resaltan tres puntos importantes:
Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.
Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del
software. Si no se siguen esos criterios, casi siempre habr falta de calidad.
Existe un conjunto de requisitos implcitos que a menudo no se mencionan. Si el software se ajusta a sus requisitos explcitos pero falla
en alcanzar los requisitos implcitos, la calidad del software queda en entredicho.
Control de Calidad
El control de calidad es una serie de inspecciones, revisiones y pruebas utilizadas a lo largo del proceso del software para asegurar que cada producto
cumpla con los requisitos que le han sido asignados.
Garanta de Calidad
La garanta de calidad consiste en la auditoria y las funciones de informacin de la gestin. El objetivo de la garanta de calidad es proporcionar la
gestin para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms profunda y segura de que la
calidad del producto esta cumpliendo sus objetivos.
GARANTA DE CALIDAD
Para evaluar la calidad son necesarias tcnicas de aplicacin de mtricas precisas tanto sobre los productos software como a sus
procesos de desarrollo.
McCall propone un esquema basado en valoraciones a 3 niveles:
FACTORES, valoracin significativa de la calidad en base a los criterios establecidos
CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad
MTRICAS, mediciones puntuales de determinadas caractersticas del producto.
Entre los factores de calidad tenemos:
CORRECCIN, grado en que cumple con las especificaciones
FIABILIDAD, grado de ausencia de fallos
EFICIENCIA, relacin entre la cantidad de resultados y los recursos requeridos
GARANTA DE CALIDAD
SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas
FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicacin
MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario.
FLEXIBILIDAD, facilidad para modificar el producto
FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su correccin o fiabilidad
TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma
REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos
INTEROPERATIVIDAD, facilidad del producto para trabajar con otros
PLAN DE GARANTA DE CALIDAD (SQAP)
Es un documento formal para organizar el proceso de desarrollo software de manera que se asegure la calidad del producto final. Debe
contemplar:
Organizacin, direccin y seguimiento de los equipos de desarrollo
Modelo de ciclo de vida a seguir, detallando fases y actividades
Documentacin requerida, determinando contenido y guin de cada documento
Revisiones y auditorias, para garantizar que las actividades y los documentos son correctos
Organizacin de las pruebas, a distintos niveles
Organizacin de la etapa de mantenimiento, determinando cmo gestionar la realizacin de cambios
Costos de Calidad
El costo de la calidad incluye todos los costos acarreados en la bsqueda de la calidad o en bsqueda de las actividades relacionadas en
la obtencin de la calidad.
El costo de calidad se puede dividir en:
Costos de prevencin
Costos de evaluacin
Costos de fallos.

Costos de Prevencin
En el costo de prevencin se incluye:
Planificacin de calidad,
Revisiones de tcnicas formales,
Equipo de pruebas,
Formacin.
Costos de Evaluacin
En el costo de evaluacin se incluyen actividades para tener una visin mas profunda de la condicin del producto la primera vez a travs
de cada proceso.
Algunos ejemplos de costos de evaluacin:
Inspeccin en el proceso y entre procesos,
Calibrado y mantenimiento del equipo,
Pruebas.
Costos de Fallo
Los costos de fallo son los costos que desapareceran si no surgieran defectos antes del envi de un producto a los clientes.
Estos costos se pueden subdividir en costos de fallo interno y costos de fallo externo.
Los internos se producen cuando se detecta un error en el producto antes de su envi. Entre estos se incluyen:
 Revisin,
Reparacin,
Anlisis de las modalidades de fallos.
Los costos de fallo externo son los que se asocian a los defectos encontrados una vez enviado el producto al cliente.
Algunos ejemplos de costos de fallo externo:
Resolucin de quejas,
Devolucin y sustitucin de productos,
Soporte de lnea de ayuda,
Trabajo de garanta.

2.8. FACTORES DE CALIDAD Y PRODUCTIVIDAD (McCall)

Los factores que afectan la calidad del software se pueden categorizar en dos amplios grupos:
Factores que se pueden medir directamente (por ejemplo, defectos por punto de funcin) y
Factores que se pueden medir solo indirectamente (por ejemplo, facilidad de uso o de mantenimiento).
2.8. FACTORES DE CALIDAD Y PRODUCTIVIDAD (McCall)

Correccin. es la capacidad de los productos de software para realizar con exactitud sus tareas, tal y como se definen en las
especificaciones.
Fiabilidad que un programa lleve a cabo su funcin con la exactitud requerida.
Eficiencia. Es la capacidad de un sistema de software para exigir la menor cantidad posible de recursos hardware.
Integridad. capacidad de los sistemas software de proteger sus diversos componentes contra modificaciones y accesos no autorizados.
Usabilidad Es la facilidad con la cual cualquier personas pueden aprender a usar los productos de software y aplicarlos a la resolucin de
problemas. Tambin cubre la facilidad de instalacin, de operacin y de supervisin.
Facilidad de mantenimiento. El esfuerzo necesario para localizar y arreglar un error en un programa. Flexibilidad. Que se pueda
modificar un programa que ya est en funcionamiento.
Facilidad de prueba. El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su funcin.
Portabilidad. Es la facilidad de transferir los productos software a diferentes entornos hardware y software.
Reusabilidad (capacidad de reutilizacin). los elementos de software de servir para la construccin de muchas aplicaciones diferentes.
Interoperatividad. es la facilidad de combinar unos elementos de software con otros.