Ingeniería de Software PRG 151 CEC 1

Inf. Franz Ramos

INGENIERIA DE SOFTWARE

Introduccion

La Ingenieria del Software es una disciplina o area de la informatica o ciencias de la

computacion, que ofrece metodo y tecnicas para desarrollar y mantener software de calidad
que resuelven problemas de todo tipo. Hoy dia es cada vez mas frecuente la consideracion de la
Ingenieria del Software como un nueva area de la ingenieria, y el Ingeniero del Software
comienza a ser una profesion implantada en el mundo laboral internacional, con derechos,
deberes y responsabilidades que cumplir, junto a una, y reconocida consideracion social en el
mundo empresarial y, por suerte, para esas personas con brillante futuro.

Definicion: Ingenieria

La ingeniería es el estudio y la aplicación de las distintas ramas de la tecnología. El profesional

en este ámbito recibe el nombre de ingeniero.

La actividad del ingeniero supone la concreción de una idea en la realidad. Esto quiere decir
que, a través de técnicas, diseños y modelos, y con el conocimiento proveniente de las ciencias,
la ingeniería puede resolver problemas y satisfacer necesidades humanas.

La ingeniería también supone la aplicación de la inventiva y del ingenio para desarrollar una
cierta actividad. Esto, por supuesto, no implica que no se utilice el método científico para llevar
a cabo los planes.

Definicion: Software

Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos

asociados que forman parte de las operaciones de un sistema de computación. [Std. 729, IEEE]

El software no son solo programas, sino todos los documentos asociados y la configuracion
de datos que se necesitan para hacer que estos programas operen de manera correcta. Un
sistema de software consiste en diversos programas independientes, archivos de configuracion
que se utilizan para ejecutar estos programas, un sistema de documentacion que describe
la estructura del sistema, la documentacion para el usuario que explica como utilizar
el sistema y sitios web que permitan a los usuarios descargar la informacion de productos
recientes. [Sommerville, 2004]

El software de computadora es el producto que los ingenieros de software construyen y

despues mantienen en el largo plazo. El software se forma con (1) las instrucciones (programas
de computadora) que al ejecutar se proporcionan las caracteristicas, funciones y el grado de
Ingeniería de Software PRG 151 CEC 2
Inf. Franz Ramos

desempeño deseados; (2) las estructuras de datos que permiten que los programas manipulen
informacion de manera adecuada; y (3) los documentos que describen la operacion y uso
de los programas. [Pressman, 2005]

Definiciones: Ingenieria del Software

• Ingenieria del Software es el estudio de los principios y metodologias para desarrollo y

mantenimiento de sistemas de software. [Zelkovitz, 1978]
• Ingenieria del Software es la aplicacion practica del conocimiento cientifico en el diseño
y construccion de programas de computadora y la documentacion asociada requerida
para desarrollar y operar (funcionar) y mantenerlos. Asi como tambien desarrollo de
software o produccion de software. [Bohem, 1976]
• La Ingenieria del Software es el establecimiento y uso de principios solidos de la
ingenieria para obtener economicamente un software confiable y que funcione de modo
eficiente en maquinas reales. [Bauer, 1972]
• Ingenieria de Software es la aplicacion de un enfoque sistematico, disciplinado y
cuantificable al desarrollo operacion (funcionamiento) y mantenimiento del software: es
decir, la aplicacion de ingenieria al software. [IEEE, 1993]
• La Ingenieria de Software es una disciplina de la ingenieria que comprende todos los
aspectos de la produccion de software desde las etapas iniciales de la especificacion del
sistema hasta el mantenimiento de este despues que se utiliza. [Sommerville, 2004]
• La Ingenieria de Software es una disciplina que integra el proceso, los metodos, y las
herramientas para el desarrollo de software de computadora. [Pressman, 2005]

Principales areas de estudio y/o investigacion

• Metodos y Metodologias de Desarrollo de Software

• Procesos de Desarrollo de Software
• Gestion de Proyectos de Software
• Medicion y Estimacion de Software
• Ingenieria de Requisitos / Requerimientos
• Ingenieria de Software Empirica
• Gestion de Riesgos
• Usabilidad de Software
• Evaluacion de Software
• Metricas de Software
• Calidad de Software
• Metodos Formales
• Ingenieria Web
Ingeniería de Software PRG 151 CEC 3
Inf. Franz Ramos

Referencias:

• Roger Pressman. Ingenieria del Software: Un Enfoque Practico. McGraw-Hill. 2006

• Ian Sommerville. Ingenieria de Software. Pearson. 2005
• Alfredo Weitzenfeld. Ingenieria de Software Orientada a Objetos: Teoría y
Práctica con UML y Java. Thomson Paraninfo. 2005
• Mario G. Piattini y Otros. Analisis y Diseño de Aplicaciones Informáticas de
Gestión: Una perspectiva de Ingenieria del Software. Editorial Ra-Ma. 2003
• Eric J. Braude. Ingeniería de Software: Una perspectiva orientada a objetos.
Editorial Ra-Ma. 2003
• Stephen R. Schach. Ingeniería de Software Clasica y Orientada a Objetos.
McGraw-Hill. 2006

Proceso de Desarrollo de Software

Un proceso define quien esta haciendo que, cuando, y como alcanzar un

determinado objetivo. En la Ingenieria del Software el objetivo es construir un producto
software o mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo
eficiente de software de calidad. Captua y presenta las mejores practicas que el estado actual
de la tecnologia permite. En consecuencia, reduce el riesgo y hace el proyecto mas predecible.
El efecto global es el fomento de una vision y una cultura comunes.

Es necesario un proceso que sirva como guia para todos los participantes clientes, usuarios,
desarrolladores y directivos ejecutivos. No nos sirve ningun proceso antiguo; necesitamos uno
que sea el mejor proceso que la industria pueda reunir en este punto de su historia. Por ultimo
necesitamos un proceso que este ampliamente disponible de forma que todos los interesados
puedan comprender su papel en el desarrollo en el que se encuentran implicados.

Un proceso de desarrollo de software deberia tambien ser capaz de evolucionar durante muchos
años. Durante esta evolucion deberia limitar su alcance, en un momentodel tiempo dado, a las
realidades que permitan las tecnologias, herramientas, personas y patrones de organizacion.

1. Tecnologias: El proceso debe contruirse sobre las tecnologias lenguajes de

programacion, sistemas operativos computadores, estructuras de red, entornos de
desarrollo, etc disponibles en el momento en que se va a emplear el proceso. Por
ejemplo hace varios años el modealado visual no era realmente de uso general. Era
demasiado caro. En aquellos tiempos, un creador de un proceso practicamente tenia que
asumir que se usarian diagramas hechos a mano. Esa suposicion limitaba mucho el gado
en el cual el creador del proceso podia establecer el modelado dentro del proceso.
Ingeniería de Software PRG 151 CEC 4
Inf. Franz Ramos

2. Herramientas: Los procesos y las herramientas deben desarrollarse en paralelo. Las

herramientas son esenciales en el proceso. Dicho de otra forma, un proceso
ampliamente utilizado para soportar la inversion necesaria para crear las herramientas
que lo soporten.
3. Personas: Un creador del proceso debe limitar el conjunto de habilidades necesarias
para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen, o
apuntar aquellas que los desarrolladores puedan obtener rapidamente. Hoy es posible
empotrar las herramientas software tecnicas que antes requieran amplios
conocimientos, como la comprobacion de la consistencia en los diagramas del modelo.
4. Patrones de Organizacion: Aunque los desarralladores de software no pueden ser
expertos tan independientes como los musicos de una orquestas, estan muy lejos de los
trabajadores automatas en los cuales Frederick W. Taylor baso su “Direccion Cientifica”
hace cien años. El creador del proceso debe adoptar el proceso a las realidades del
momento hechos como mezcla(en empresas pequeñas recien montadas) de socios de la
empresa, empleados asalariados, trabajadores de obra y subcontratas de outsourcing y
la prolongada escacez de desarrolladores de software.

Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias. Ademas el
equilibrio debe estar presente no solo ahora, sino tambien en el futuro. El creador del proceso
debe diseñar el proceso de forma que pueda evolucionar, de igual forma que el desarrollador de
software intenta desarrollar un sistema que no solo funciona este año, sino que evoluciona con
exito en los años venideros. Un proceso debe madurar durante varios años antes de productos
comerciales manteniendo a la vez un nivel razonable de riesgo de utilizacion. El desarrollo de
un producto nuevo es bastante arriesgado en el mismo como para añadirle el riesgo de un
proceso puede ser estable. Sin este equilibrio de tecnologias, herramientas, personas y
organizacion, el uso del proceso seria bastante arriesgado.

Modelos de Procesos de Software:

Al día de hoy, ha aumentado la complejidad con la que se desarrollan sistemas de información

para la industria, por lo que resulta difícil generar productos que cumplan cabalmente con las
expectativas del cliente.

Para responder a esta situación, han surgido una serie de herramientas, técnicas y modelos que
facilitan a las organizaciones, encargadas de las tecnologías de la información, generar
productos que cumplan las expectativas del cliente e incluso las rebasen, herramientas que
prometen ser la solución a los problemas de calidad, costo y tiempos de desarrollo; de éstas
podemos mencionar a los “modelos de calidad” como la norma ISO 9000-2000, la ISO/IEC TR
15504 y el modelo CMM (Capability Maturity Model del Software Engineerig Institute SEI).
Ingeniería de Software PRG 151 CEC 5
Inf. Franz Ramos

Aunque en el pasado se reconocía la necesidad de crear software de calidad, no se había hecho

un esfuerzo serio para que nuestra industria generara productos que nos dieran la oportunidad
de competir en el mercado internacional, con calidad equiparable o superior a la de países como
la India o Irlanda. Afortunadamente, dicha situación ha cambiado; nuestro gobierno en
conjunto con la industria, ha iniciado un esfuerzo serio para impulsar la industria del software a
través del Programa para el Desarrollo de la Industria del Software (PROSOFT).

PROSOFT reconoce el estado incipiente de la industria mexicana de software, así como la

necesidad de invertir cantidades crecientes de recursos en capital de tecnologías de información
con objeto de contribuir de manera sostenible al crecimiento de la economía y la generación de
empleos bien remunerados.

Con el programa, se pretende establecer una industria de software competitiva

internacionalmente y asegurar su crecimiento a largo plazo, lo que situaría a México como líder
de esta industria en Latinoamérica en 2012, además de convertirlo en líder desarrollador de
soluciones de tecnologías de información de alta calidad y uso de software en Latinoamérica.

1. Este programa tiene siete estrategias de donde emergen varios proyectos que ayudarán
a que se alcancen las metas previstas en éste:
2. Promover las exportaciones y la atracción de inversiones.
3. Educar y formar personal competente en el desarrollo de software, en cantidad y calidad
convenientes.
4. Contar con un marco legal promotor de la industria.
5. Desarrollar el mercado interno.
6. Fortalecer a la industria local.
7. Alcanzar niveles internacionales en capacidad de procesos.
8. Promover acciones conjuntas con los gobiernos estatales y construir infraestructura.

Para el caso de la estrategia 6, la Asociación Mexicana para la Calidad en Ingeniería de

Software (AMCIS), con el auspicio de la Secretaría de Economía propone un modelo concebido,
diseñado y desarrollado por mentes mexicanas, adecuado para las necesidades específicas de
México y con ventajas respecto de otros. El nuevo modelo, denominado MoProSoft, ofrece
características que los otros no tienen de manera independiente; para su concepción, se
tomaron las mejores prácticas de los otros modelos y se integraron y mejoraron otras; a
continuación, mencionamos a qué se refiere cada modelo y algunas de sus ventajas y
desventajas.

Norma ISO 9000-2000

Ingeniería de Software PRG 151 CEC 6
Inf. Franz Ramos

Es una norma internacional destinada a evaluar la capacidad de la organización para cumplir los
requisitos del cliente, los reglamentarios y los propios de la organización.

Ventajas

• Tiene un mecanismo de certificación bien establecido.

• Está disponible y es conocida.

Desventajas

• No es específica para la industria de software.

• No es fácil de entender.
• No está definida como un conjunto de procesos.
• No es fácil de aplicar.

Capability Maturity Model (CMM)

Es un marco evolutivo organizado en cinco niveles para lograr la mejora continua de procesos.

Ventajas

• Específico para el desarrollo y mantenimiento de software.

• Definido como un conjunto de áreas clave de procesos.
• Tiene un modelo de evaluación.
• Desde 1998 empezó a popularizarse en México.
• Existen organizaciones evaluadas.

Desventajas

• Es un modelo extranjero, no internacional.

• No es fácil de entender (inglés, 18 KPAs, 220 páginas).
• No es fácil de aplicar (pensado para organizaciones grandes).
• La mejora no está enfocada directamente a los objetivos de negocio.
• La evaluación es costosa y no tiene periodo de vigencia.
• Se está abandonando a favor de CMM-I (el SEI dejará de dar soporte a partir del 2005).

ISO/IEC TR 15504

Define el modelo de referencia de procesos de software y de capacidades de procesos que

constituyen la base para la evaluación de procesos de software. Se compone de 9 partes de las
cuales la 2, 3 y 9 son normativas y las demás informativas.
Ingeniería de Software PRG 151 CEC 7
Inf. Franz Ramos

Ventajas

• Específico para el desarrollo y mantenimiento de software.

• Fácil de entender (24 procesos, 16 páginas).
• Definido como un conjunto de procesos.
• Orientado a mejorar los procesos para contribuir a los objetivos del negocio.

Desventajas

• No es práctico ni fácil de aplicar.

• Tiene solamente lineamientos para un mecanismo de evaluación.
• Todavía no es norma internacional.

MoProSoft

Es un Modelo de Procesos para la Industria de Software que fomenta la estandarización de su

operación, a través de la incorporación de las mejores prácticas en gestión e ingeniería de
software. La adopción del modelo permite elevar la capacidad de las organizaciones para
ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad.

Ventajas

• Fácil de entender.
• Fácil de aplicar.
• No es costoso en su adopción.
• Sirve de base para alcanzar evaluaciones exitosas con otros modelos o normas, tales
como ISO 9000:2000 [1] o CMM.1 V1.1[2].

A decir de sus creadores, el modelo está orientado a pequeñas y medianas empresas, hecho
favorable si se considera que aproximadamente el 80% de las empresas desarrolladoras de
software del país caen en esta categoría. Su principal fortaleza es que integra varias de las
prácticas propuestas por los otros modelos y corrige algunas de sus desventajas, como son el
hecho de que no ha sido liberado por completo o al menos falta el modelo de evaluación;
además, está en proceso de convertirse en norma compitiendo con el proyecto de norma
ISO/IEC TR 15504 y aunque no ha sido probado, se planea realizar pilotos en algunas
organizaciones para evaluar qué tan fácil resulta su implantación determinando los recursos
necesarios.

Lo interesante para nosotros como academia, es que tenemos la oportunidad de proponer

productos concebidos y desarrollados en México, adecuados a nuestros requerimientos y
Ingeniería de Software PRG 151 CEC 8
Inf. Franz Ramos

realidad, lo que repercute de manera directa en la gama de soluciones que tiene una
organización para resolver sus necesidades.

Modelo de Cascada:

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada,

es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software,
de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente
anterior.

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos
2. Diseño
3. Codificación
4. Pruebas
5. Implantación
6. Mantenimiento

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce

necesariamente al rediseño y nueva programación del código afectado, aumentando los costes
del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el
esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el
paradigma más seguido al día de hoy.

Fases del modelo

Análisis de requisitos

Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos
debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de
Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar
en detalles internos.

Diseño

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado,

aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento
de Diseño del Software), que contiene la descripción de la estructura global del sistema y la
Ingeniería de Software PRG 151 CEC 9
Inf. Franz Ramos

especificación de lo que debe hacer cada una de sus partes, así como la manera en que se
combinan unas con otras.

Codificación

Es la fase de programación propiamente dicha. Aquí se desarrolla el código fuente, haciendo

uso de prototipos así como pruebas y ensayos para corregir errores.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que

funciona correctamente antes de ser puesto en explotación.

Implantación

El software obtenido se pone en producción.

Mantenimiento

Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o
bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.

Variantes

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y
en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el
sistema final este libre de fallos
Ingeniería de Software PRG 151 CEC 10
Inf. Franz Ramos

Modelo de Prototipo:

Modelo de Riesgo y Espiral:

Qué es el Modelo Espiral?

Desarrollado por B. Boehm, básicamente, la idea es Desarrollo Evolutivo, usando el Modelo de

Cascada para cada etapa; esta orientado a evitar riesgos de trabajo. No define en detalle el
sistema completo a la primera. Los desarrollares deberían solamente definir las mas altas
prioridades. Definir e implementarlas y entonces obtener un feedback de los usuarios (tal y
como feedback distingue desarrollo "evolutivo" de "incremental"). Con este conocimiento,
Ingeniería de Software PRG 151 CEC 11
Inf. Franz Ramos

deberían entonces retroceder o volver al punto de partida para definir e implementar más y
mejores partes.

El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso
de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas
expresiones que son obtenidas transformando otras dadas son examinadas para ver si
representan progresos hacia el objetivo.

Este método esta basado en dos importantes principios:

1. la practica de diseñó profesional es caracterizar en términos de conocer, actuar en

situaciones, conversación con la situación y reflexión en acción. Hay un distinto medio
de proceso - orientación en esta aproximación al diseño. Es raro que el diseñador tenga
el diseño en su cabeza por adelantado y que después meramente lo transcriba. Gran
parte del tiempo del diseñador esta inmiscuido en una progresiva relación con su
entorno. Una buena metáfora para describirlo es "la conversación con el material", como
un escultor, quien esta ocupado en una conversación con el medio. El escultor modela
arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser.
2. la necesidad para diseñadores de tomar la practica de trabajo seriamente, de supervisar
las formas en las que el trabajo se esta haciendo, en el sentido de una solución abierta y
desplegada para aumentar la complejidad de una situación que el diseñador solo
entiende parcialmente. El hecho por el cual se esta tratando con "actores humanos". Los
sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es,
definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo
cooperación y comunicación.

Una visión general del Modelo de Cascada puede ser la siguiente:

Ingeniería de Software PRG 151 CEC 12
Inf. Franz Ramos