mi proyecto
TRANSCRIPT
UNIVERSIDAD DE OCCIDENTE
UNIDAD LOS MOCHIS
SEMINARIO DE INVESTIGACION
LIC. SISTEMAS COMPUTACIONALES
METODOLOGÍA UTILIZADA EN LA ELABORACIÓN DE SOFTWARE EN LA REGIÓN DE LOS MOCHIS
PRESENTAN:
LÓPEZ MARTINEZ NEIBA KARELY
RUIZ PACHECO LUIS ENRIQUE
ASESOR: M.C. GENARO EFRAÍN GÁMEZ BUSTILLOS
PROF: M.C. FRANCISCO RODIMIRO GUZMÁN DICOCHEA
Los Mochis, Sinaloa a 13 de Julio de 2010
Í N D I C E
Dedicatoria .............................................................................................................. I Agradecimiento ......................................................................................................... II Resumen .................................................................................................................. III Summary .................................................................................................................. IV Capítulo I Metodología
1.1 Planteamiento ...................................................................................... 01 1.2 Justificación .......................................................................................... 03 1.3 Objetivos .............................................................................................. 04 1.4 Metodología ......................................................................................... 05
Capítulo II Marco teórico 2.1 Antecedentes históricos ...................................................................... 06 2.2 Metodologías de la programación ....................................................... 08
2.2.1 Metodología, análisis y diseño estructurado .............................. 08 2.2.2 Metodología, análisis y diseño orientado a objetos ................... 09
2.3 Ingeniería del software ......................................................................... 10 2.3.1 Procesos de desarrollo de software .......................................... 14
2.3.1.1 Modelo en cascada ................................................... 15 2.3.1.2 Modelo de desarrollo evolutivo.................................. 15 2.3.1.3 Modelo incremental ................................................... 16 2.3.1.4 Modelo en espiral ...................................................... 17 2.3.1.5 Modelo espiral win-win .............................................. 18 2.3.1.6 Modelo de desarrollo concurrente ............................. 19 2.3.1.7 Desarrollo basado en componentes.......................... 20
2.3.2 Métodos de desarrollo de software ............................................ 21 2.3.3 Herramientas para la creación de software ............................... 22
2.4 Un enfoque de calidad ......................................................................... 26 2.4.1 Calidad ...................................................................................... 26
2.4.1.1 Control de calidad ..................................................... 28 2.4.1.2 Garantía de calidad ................................................... 28 2.4.1.3 Coste de calidad ....................................................... 29
2.4.2 Aseguramiento de la calidad del software ................................. 30 2.4.3 Gestión de la calidad del software ............................................. 30 2.4.4 Sistema de calidad .................................................................... 31 2.4.5 Certificación de la calidad .......................................................... 32
2.4.5.1 Capability Maturity Model Integration ........................ 32 2.4.5.2 Modelo de procesos para la industria
del software ............................................................... 33 2.4.6 Factores que determinan la calidad del software ...................... 35
Capítulo III Desarrollo de la investigación 3.1 Metodología de desarrollo ..................................................................... 37 3.2 Presentación, análisis e interpretación de resultados .......................... 39
Capítulo IV Conclusiones y recomendaciones ........................................................ 44 Bibliografía ................................................................................................................ 47
I
DEDICATORIA
A MIS PADRES:
A ustedes les dedico estas palabras como un reconocimiento al esfuerzo y
apoyo incondicional que han brindado en el transcurso de mi vida. Gracias
por enseñarme lo que han recogido a su paso por la vida y por darme la
libertad de elegir mi futuro; por brindarme con las manos abiertas su apoyo
y confianza en mi preparación, porque hoy recibo su más valiosa herencia:
Mi Profesión.
II
AGRADECIMIENTO
A DIOS:
A ti agradezco que hayas dado la vida y salud, así como la oportunidad de disfrutar y compartir con mi familia y amigos una de las etapas más felices
de mi vida, y porque nunca me dejaste flaquear ni perder la fe en los momentos más difíciles.
Profesor:
A ti querido maestro que llevas en el pensamiento, la enseñanza como escudo tu comprensión y talento. Bendito sea tu trabajo una bella y noble misión, predicando con tu ejemplo a generación tras generación. Tienes esa gran virtud de entregarte en cuerpo y alma, yéndose tu juventud en favor de la enseñanza. Nos enseñas muchas cosas grandes conocimientos, experiencias propias o ajenas sin escatimar sufrimientos. Eres un gran confidente un entrañable amigo, algunas veces madre o padre que nos enseña el camino. Tienes grandes satisfacciones cuando aquilatan tu servicio, también algunas decepciones que son gajes de tu oficio. Hoy te digo gracias por todo lo que me has dado, es un trozo de tu vida que a todos nos has convidado. Espero seguir tus pasos quizá no sea en un salón, pero cualquiera que sea mi empleo vivirás en mi corazón.
. M.C. Genaro Efraín Gámez Bustillos
M.C. Francisco Rodimiro Guzmán Dicochea
III
RESUMEN
La ingeniería de software es el proceso de construir aplicaciones de tamaño o alcance
prácticos, en las que predominan el esfuerzo del software y que satisface los
requerimientos de funcionalidad, desempeño y calidad.
El software se ha convertido en una tecnología indispensable en los negocios, la ciencia
y la ingeniería; permitiendo la creación de nuevas tecnologías.
Un elemento clave de cualquier proceso de ingeniería es la medición. Empleamos
medidas para entender mejor los atributos de los modelos que creamos. Pero,
fundamentalmente, empleamos las medidas para valorar la calidad de los productos de
ingeniería o de los sistemas que construimos. Intentando obtener un conjunto de
medidas indirectas que dan lugar a estándares que proporcionan una identificación de
la calidad de algún tipo de representación del software.
Existen organismos reguladores de software que proporcionan las herramientas para
producir software de calidad permitiendo detectar los flancos débiles de los procesos y
fortaleciéndolos en forma homogénea e íntegra, mediante la aplicación de mejoras, en
aquellas áreas consideradas poco eficientes. Proporcionando una guía para mejorar los
procesos de una organización y la habilidad para gestionar el desarrollo, adquisición y
mantenimiento de productos o servicios.
Esta investigación pretende mostrar la situación actual de desarrollo de software en la
ciudad de Los Mochis ya que como estudiantes teníamos la inquietud de conocer y
exponer el proceso de desarrollo y los requerimientos de calidad utilizados en la
elaboración de software.
IV
SUMMARY
The engineering of software is the process of constructing applications of size or scope
practical, in that they predominate over the effort of the software and that satisfies the
requests of functionality, performance and quality.
The software has turned into an indispensable technology into the business, the
science and the engineering; allowing the creation of new technologies.
A key element of any process of engineering is the measurement. We use
measurements to understand better the attributes of the models that we create. But,
fundamentally, we use the measurements to value the quality of the products of
engineering or of the systems that we construct. Trying to obtain a set of indirect
measurements that lead to standards that provide an identification of the quality of some
type of representation of the software.
There exist regulatory organisms of software that provide the hardware to produce
quality software allowing to detect the weak flanks of the processes and strengthening
them in homogeneous and complete form, by means of the application of progress, in
those slightly efficient considered areas. Providing a handlebar to improve the processes
of an organization and the skill to manage the development, acquisition and
maintenance of products or services.
This investigation tries to show the current situation of development of software in the
city of Los Mochis since as students we had the worry of knowing and exhibiting the
process of development and the quality requests used in the making of software.
CAPÍTULO I
METODOLOGÍA
1
1.1 Planteamiento
Hoy en día, el termino tecnología informática se ha ampliado para abarcar
muchos aspectos que se refieren a la computadora, las cuales se componen por
hardware que es la parte física de la misma y el software que es un conjunto de
programas y procedimientos que se necesitan para hacer posible la realización
de una tarea específica.
En la actualidad, el software de computadoras es la tecnología individual más
importante en el ámbito mundial. Nadie en la década de 1950 podría haber
predicho que el software se convertiría en una tecnología indispensable en los
negocios, la ciencia y la ingeniería; tampoco que el software permitiría la
creación de tecnologías nuevas (Ing. Genética), la extensión de tecnologías
existentes (Telecomunicaciones), el fin de tecnologías antiguas; que el software
sería la fuerza conductora detrás de la revolución de las computadoras
personales.
El software de las computadoras se divide en software de base e ingeniería de
software. El software de base controla y respalda en cierto modo las categorías
del sistema operativo y la interfaz grafica de usuario, además el software de base
ahorra al usuario el tener que preocuparse por las partes de la memoria del
computador que contiene el documento y otros procesos más.
La ingeniería de software es el proceso de construir aplicaciones de tamaño o
alcance prácticos, en las que predominan el esfuerzo del software y que
satisface los requerimientos de funcionalidad y desempeño1.
Por lo que este proyecto pretende mostrar un panorama de los aspectos
considerados más importantes en la elaboración de software, así como también
1 Braude Ingeniería de software una perspectiva orientada a objetos
2
los estándares y métricas utilizados para la creación del mismo en la región de
Los Mochis, Sinaloa.
Anteriormente las compañías locales productoras de software no implementaban
estándares ya que programaban de acuerdo a las necesidades de los clientes, y
dadas las condiciones actuales donde el software se ha convertido en un ente
predominante en la toma de decisiones y dado que existe software para
cualquier campo del conocimiento.
Con el cambio de la sociedad del conocimiento y originado por la globalización
de la información nace un área de especialidad a nivel mundial denominada
ingeniería de software.
Esta nueva área del conocimiento en el desarrollo de software se creó con el fin
de estandarizar y normar el software a nivel mundial.
Por lo expuesto anteriormente consideramos relevante para efectos de esta
investigación dar respuesta a las siguientes interrogantes, planteándose como
pregunta principal: ¿Cuál es el panorama actual que existe en la creación de
software en Los Mochis? y como complementarias: ¿Cuáles son las
metodologías utilizadas para la elaboración de software?, ¿Cuáles son los
factores a considerar en la calidad del software?
3
1.2 Justificación
El impacto que han tenido las computadoras en el mundo, es tan profundo que
vale la pena conocer la manera que ha evolucionado esta tecnología, esta
relación estrecha entre persona, software y empresa, no se pueden concebir el
uno sin el otro, por esta razón se trata de dar todas las referencias posibles del
software y su ingeniería así como sus estándares y métricas utilizados para su
creación en Los Mochis.
Este proyecto se realiza con el propósito de describir y mostrar el panorama
actual del software en la región de los Mochis y hacer una comparativa de los
métodos, estándares y métricas utilizadas en las diferentes casas productoras de
software en Los Mochis.
4
1.3 Objetivos
Generales:
Mostrar y analizar el panorama actual en la elaboración y construcción de
software en la región de Los Mochis, Sinaloa.
Específicos:
Describir las metodologías para elaboración de software.
Analizar las consideraciones de la calidad de la ingeniería del software.
5
1.4 Metodología
Para llevar a cabo el desarrollo de esta investigación el método a seguir será el
siguiente:
Primeramente se realizara una amplia búsqueda de información sobre ingeniería
de software así como sus diferentes metodologías y estándares utilizados
actualmente, esta se realizara en las bibliotecas de Universidad de Occidente
campus Los Mochis e Instituto Tecnológico de Los Mochis.
Además de visitar y entrevistar a personas expertas en el área de ingeniería de
software en la ciudad de Los Mochis, con el fin de recabar información y reforzar
la investigación.
CAPÍTULO II
MARCO TEÓRICO
6
2.1 Antecedentes Históricos
Se denomina software (palabra de origen anglosajón, pronunciada "sóft-uer"),
programa, equipamiento lógico o soporte lógico a todos los componentes intangibles de
una computadora, es decir, al conjunto de programas y procedimientos necesarios para
hacer posible la realización de una tarea específica, en contraposición a los
componentes físicos del sistema (hardware).
La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la
primera conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia
de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse
según Alan Davis como “la aplicación inteligente de principios probados, técnicas,
lenguajes y herramientas para la creación y mantenimiento, dentro de un coste
razonable, de software que satisfaga las necesidades de los usuarios”.2
El término ingeniería del software empezó a usarse a finales de la década de los
sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a
las problemáticas que ofrecía el software en ese momento. En esa época, el
crecimiento de la demanda de sistemas de computación cada vez más y más
complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al
electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la “crisis del
software” (en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los
presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de
control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban
más allá de las pérdidas millonarias que causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino
en parte porque no es razonable estar en crisis más de veinte años, y en parte porque
se estaban haciendo progresos en los procesos de diseño y metodologías.
2 Sommerville, Ingeniria del Sofware, 7° edición, Pearson Addison Wesley, 2006.
7
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas,
metodologías y tecnologías que se presentaban como la solución definitiva al problema
de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de
software. Entre las que se encuentran la programación estructurada, la programación
orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de
programación ADA, la documentación, los estándares, CORBA, los servicios web y el
lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a
los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet).
Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo
de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero
no cómo hacerlo.
La metodología indica cómo hay que obtener los distintos productos parciales y finales,
en otras palabras la metodología es el conjunto de procedimientos, técnicas,
herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo
software.
A lo largo de los años han existido diferentes métodos que han sido desarrollados
diferenciándose por su fortaleza y debilidad para el desarrollo de software,
encontrándose dos generaciones de metodologías de mayor preeminencia como son:
Estructurado.
Orientada a Objetos.
8
2.2 METODOLOGÍAS DE LA PROGRAMACIÓN
2.2.1 Metodología, análisis y diseño estructurado
Al igual que muchas de las contribuciones importantes de la ingeniería del software, el
análisis estructurado no fue introducido en un solo artículo o libro clave que incluyera un
tratamiento completo del tema. Pressman menciona que los primero trabajos sobre
modelos de análisis aparecieron a finales de los 60’s y principios de los 70’s nace lo que
se le conoce como análisis estructurado término acuñado originalmente por Douglas
Ross lo que le permite al analista conocer un sistema o proceso (actividad) en una
forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que
no se omite ningún detalle pertinente.
A mediados de los 80´s, las ampliaciones para tiempo real fueron introducidas por Ward
y Mellor y, más tarde, por Hatley y Pirbhai. Con esas ampliaciones, se consiguió un
método de análisis más robusto que podía ser aplicado de forma más efectiva a
problemas de ingeniería.
El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con
la determinación de requerimientos para obtener la comprensión completa y exacta de
una situación dada. A partir de aquí determina los requerimientos que serán la base de
un sistema nuevo o modificado.
En el análisis estructurado la palabra estructura significa qué: 1) el método intenta
estructurar el proceso de determinación de los requerimientos comenzando con la
documentación del sistema existente; 2) el proceso está organizado de tal forma que
intenta incluir todos los detalles relevante que describe al sistema en uso; 3) es fácil
verificar cuando se han omitido detalles relevantes; 4) la identificación de los
requerimientos será similar entre varios analistas e incluirá las mejora soluciones y
estrategias para las oportunidades para de desarrollo de sistemas; y 5) los documentos
de trabajo generados para documentar los sistemas existente o propuesto son
dispositivos de comunicación eficientes.
9
El análisis estructurado hace uso de los siguientes componentes.
Símbolos gráficos. Iconos y connotaciones para identificar y describir los
componentes de un sistema junto con las relaciones entre estos componentes.
Diccionario de datos. Descripciones de todos los datos utilizados en el sistema.
Descripciones de procesos y procedimientos. Declaraciones formales que
emplean técnicas y lenguajes que permiten a los analistas describir actividades
importantes que forman parte del sistema.
Reglas. Estándares para describir y documentar el sistema en forma completa y
correcta.
2.2.2 Metodología, análisis y diseño Orientado a Objetos
En los 90’s se establece el análisis orientado a objetos basándose en un conjunto de
principios básicos: (1) se modelo el dominio de la información; (2) se describe la
función;(3) se representa el comportamiento del modelo; (4) los modelos de datos
funcional y de comportamiento se dividen para mostrar más detalles; y (5) los modelos
iniciales representan la esencia del problema mientras que los últimos aportan detalles
para la implementación. Estos principios forman la base para el enfoque del análisis
orientado a objetos. Partiendo de esta época a la fecha como el nuevo auge en la
manera de diseñar y programar software.
El propósito del análisis orientado a objetos es definir todas las clases que son
relevantes al problema que se van a resolver, las operaciones y atributos asociados, las
relaciones y comportamientos asociadas con ellas. Para cumplir se deben ejecutar las
siguientes tareas:
1. Los requisitos básicos del usuario deben comunicarse entre el cliente y el
ingeniero del software.
2. Identificar las clases (es decir definir atributos y métodos).
3. Se debe especificar una jerarquía de clases.
4. Representan las relaciones objeto a objeto (conexiones de objetos).
10
5. Modelar el comportamiento del objeto.
6. Repetir interactivamente las tareas de la 1 a la 5 hasta completar el modelo.
El análisis orientado a objetos comienza con una descripción de casos de uso, que es
una descripción de escenarios sobre cómo interactúan los actores (gente, maquina u
otros sistemas) con el sistema a construir. El modelo de clases-responsabilidad-
colaboración (CRC) traslada la información de los casos de uso a una representación
de las clases y sus colaboraciones con las otras clases. Las características estáticas y
dinámicas de las clases se modelan entonces utilizando un lenguaje de modelado
unificado o cualquier otro método.
Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a
objetos. También se necesitará realizar un análisis y diseño orientado a objetos.
El moldeamiento visual es la clave para realizar el análisis orientado a objetos. Desde
los inicios del desarrollo de software orientado a objetos han existido diferentes
metodologías para hacer esto del modelamiento, pero sin lugar a duda, el Lenguaje de
Modelamiento Unificado (UML) puso fin a la guerra de metodologías.
Los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier tipo
de sistemas (no solamente de software) usando los conceptos de la orientación a
objetos. Y además, este lenguaje debe ser entendible para los humanos y máquinas.
Actualmente en la industria del desarrollo de software se tiene a UML como un estándar
para el modelamiento de sistemas orientado a objetos. Fue la empresa Racional que
creó estas definiciones y especificaciones del estándar UML, y lo abrió al mercado. La
misma empresa creó uno de los programas más conocidos hoy en día para este fin; el
Racional Rose, pero también existen otros programas como el Poseidon que trae
licencias del tipo community edition que permiten su uso libremente.
El UML consta de todos los elementos y diagramas que permiten modelar los sistemas
en base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se
11
construyen en forma correcta, son fáciles de comunicar, cambiar, expandir, validar y
verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes
plenamente reutilizables.
2.3 Ingeniería del software
La Ingeniería de Software es una disciplina o área de la Informática o Ciencias de la
Computación, que ofrece métodos y técnicas para desarrollar y mantener software de
calidad que resuelven problemas de todo tipo. Hoy día es cada vez más frecuente la
consideración de la Ingeniería de Software como una nueva área de la ingeniería, y el
ingeniero de software comienza a ser una profesión implantada en el mundo laboral
internacional, respetada, con derechos, deberes y responsabilidades que cumplir, junto
a una ya reconocida consideración social en el mundo empresarial y, por suerte, con
brillante futuro3.
La Ingeniería de Software trata con áreas muy diversas de la informática y de las
ciencias de la computación, tales como construcción de compiladores, sistemas
operativos o desarrollos en Intranet/Internet, abordando todas las fases del ciclo de vida
del desarrollo de cualquier tipo de sistemas de información y aplicables a una infinidad
de áreas tales como: negocios, investigación científica, medicina, producción, logística,
banca, control de tráfico, meteorología, el mundo del derecho, la red de redes Internet,
redes Intranet y Extranet, etc3.
El termino Ingeniería se define en DRAE4 como: «1. Conjunto de conocimientos y
técnicas que permiten aplicar el saber científico a la utilización de la materia y de las
fuentes de energía. 2. Profesión y ejercicio de ingeniero» y el termino ingeniero se
define como: «Persona que profesa o ejerce la ingeniería». De igual modo la Real
Academia de Ciencias Exactas, Físicas y Naturales de España define el término
3 Pressman, Ingenieria del software un enfoque practico. 5ta. Edicion
4 DRAE, Diccionario de la Real Academia Española de la Lengua.
12
Ingeniera como: «Conjunto de conocimientos y técnicas cuya aplicación permite la
utilización racional de los materiales y de los recursos naturales, mediante invenciones,
construcciones u otras realizaciones provechosas para el hombre»5.
Evidentemente, si la Ingeniería del Software es una nueva Ingeniería, parece lógico que
reúna las propiedades citadas en las definiciones anteriores. Sin embargo ni el
DRAE(Diccionario de la Real Academia Española de la Lengua), ni la Real Academia
Española de Ciencias han incluido todavía el termino en sus últimas ediciones; en
consecuencia vamos a recurrir para su definición más precisa a algunos de los autores
más acreditados que comenzaron en su momento a utilizar el término o bien en las
definiciones dadas por organismos internacionales profesionales de prestigio tales
como IEEE o ACM, de los cuales se han seleccionado las siguientes definiciones de
Ingeniería del Software:
Definición 1:
Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y
mantenimiento de sistemas de software6.
Definición 2:
Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño
y construcción de programas de computadora y la documentación necesaria requerida
para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo
de software o producción de software(Bohem)7.
5 Vocabulario Científico y Técnico, edición de 1996.
6 Zelkovitz, M. V., Shaw, A. C. y Gannon, J. D.: Principles of Software Engineering and Desing. Prentice-
Hall, Englewoods Clig, 1979. 7 Boehm, B. W.: «Software Engineering», IEEE Transactions on Computers, C-25, núm. 12, diciembre,
pp. 1226-1241.
13
Definición 3:
Ingeniería del Software trata del establecimiento de los principios y métodos de la
Ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en
máquinas reales(Bauer)8.
Jacobson define al proceso de ingeniería de software como "un conjunto de etapas
parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la
obtención de un producto de software de calidad" y Pressman lo define como "un marco
de trabajo de las tareas que se requieren para construir software de alta calidad".
(Pressman 1992).El proceso de desarrollo de software "es aquel en que las
necesidades del usuario son traducidas en requerimientos de software, estos
requerimientos transformados en diseño y el diseño implementado en código, el código
es probado, documentado y certificado para su uso operativo". Concretamente "define
quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo".
El proceso de desarrollo de software requiere por un lado un conjunto de conceptos,
una metodología y un lenguaje propio. Pressman define que los proyectos de software
están divididos en fases. Al conjunto de fases y su secuencia se le denomina ciclo de
vida del software. El cual comprende cuatro grandes fases: concepción, elaboración,
construcción y transición. La concepción define el alcance del proyecto y desarrolla un
caso de negocio. La elaboración define un plan del proyecto, especifica las
características y fundamenta la arquitectura. La construcción crea el producto y la
transición transfiere el producto a los usuarios. Scacchi(1987) menciona que el ciclo de
vida del Software describe todo el proceso de software de un sistema dado, desde su
concepción hasta su retiro (concepción, introducción, aceptación o crecimiento,
madurez, saturación, obsolescencia y retiro) y Pressman define al ciclo de vida del
software como un tiempo determinado en el cual un producto de software se desarrolla
y usa, hasta que es retirado.
El desarrollo del software se realiza mediante un método basado en conceptos y
técnicas que conforman el enfoque o paradigma de la forma de construir un sistema de
8 Bauer, F.L: «Software Engineering», Information Processing, 71, North Holland Publishing Co.,
Amsterdam, 1972.
14
software. Dicho método permite establecer el proceso de software, es decir, las
actividades de desarrollo, cuya definición determinará el tipo de soporte requerido para
llevarlas a efecto.
La Ingeniería del software es una tecnología multicapa. Como muestra la Figura 1,
cualquier enfoque de ingeniería (incluida ingeniería del software) debe apoyarse sobre
un compromiso de organización de calidad.
Figura 1. Capas de la ingeniería del Software.
2.3.1 Procesos de desarrollo de software
El fundamento de la ingeniería del software es la capa de proceso. El proceso de la
ingeniería del software es la unión que mantiene juntas las capas de tecnología y que
permite un desarrollo racional y oportuno de la ingeniería del software. El proceso
define un marco de trabajo para un conjunto de aéreas clave de proceso (ACPs) que
se deben establecer para la entrega efectiva de la tecnología de la ingeniería del
software. Las áreas claves del proceso forman la base del control de gestión de
proyectos del software y establecen el contexto en el que se aplican los métodos
técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes,
formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona
adecuadamente.
Se establece un marco común del proceso definiendo un pequeño número de
actividades del marco de trabajo que son aplicables a todos los proyectos del software,
con independencia de su tamaño o complejidad. Un número de conjuntos de tareas –
cada uno es una colección de tareas de trabajo de ingeniería del software, hitos de
15
proyectos, productos de trabajo, y puntos de garantía de calidad- que permiten que las
actividades del marco de trabajo se adapten a las características del proyecto del
software y a los requisitos del equipo del proyecto. Finalmente, las actividades de
protección -tales como garantía de calidad del software, gestión de configuración del
software y medición*-abarcan el modelo de procesos. Las actividades de protección son
independientes de cualquier actividad del marco de trabajo y aparecen durante todo el
proceso (Pressman 1992).
Estos modelos generales no son descripciones definitivas de los procesos de software.
Más bien, son abstracciones de los procesos que se pueden utilizar para explicar
diferentes enfoques para el desarrollo de software. Puede pensarse en ellos como
marcos de trabajo del proceso que pueden ser extendidos y adaptados para crear
procesos más específicos de ingeniería del software.
2.3.1.1 Modelo en cascada
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos
hacia abajo (como en una cascada de agua) considera las actividades fundamentales
del proceso de especificación, desarrollo, validación y evolución, y los representa como
fases separadas del proceso, tales como la especificación de requerimientos, el diseño
del software, la implementación, las pruebas y mantenimiento (Sommerville 2002).
Las ventajas del modelo en cascada son que la documentación se produce en cada
fase y que este cuadra con otros modelos del proceso de ingeniería de. Su principal
problema es su inflexibilidad al dividir el proyecto en distintas etapas.
2.3.1.2 Modelo de Desarrollo Evolutivo
Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Este
16
se refina basándose en las peticiones del cliente para producir un sistema que satisfaga
sus necesidades (Sommerville 2002).
La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la
especificación se puede desarrollar de forma creciente. Tan pronto como los usuarios
desarrollen un mejor entendimiento de su problema, éste de se puede reflejar en el
sistema software. Sin embargo, desde una perspectiva de ingeniería y de gestión, el
enfoque evolutivo tiene dos problemas:
El proceso no es visible: Los administradores tienen que hacer entregas
regulares para medir el progreso. So los sistemas se desarrollan rápidamente, no
es rentable producir documentos que reflejen cada versión del sistema.
A menudo los sistemas tienen una estructura deficiente: los cambios continuos
tienden a corromper la estructura del software. Incorporar cambios en el se
convierte cada vez más en una tarea difícil y costosa.
2.3.1.3 Modelo incremental
Combina elementos del modelo lineal secuencial (aplicados repetidamente) con la
filosofía interactiva de construcción de prototipos, el modelo incremental aplica
secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario.
Cada secuencia lineal produce un incremento del software.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un
producto esencial. Es decir se afrontan requisitos básicos, pero muchas funciones
suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el
producto central (o sufre la revisión detallada). Como un resultado de utilización y/o de
evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la
modificación del producto central a fin de cumplir mejor las necesidades del cliente y la
entrega de funciones, y características adicionales. Este proceso se repite siguiendo la
entrega de cada incremento, hasta q se elabore el producto completo (Pressman 1992).
17
Figura 2. El modelo Incremental
2.3.1.4 Modelo en espiral
Es un modelo de software es un proceso de software evolutivo que conjuga la
naturaleza interativa de la construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo
rápido de versiones incrementales del software. En el modelo espiral, el software se
desarrolla en una serie de versiones incrementales. Durante las primeras interacciones,
la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas
interacciones se producen versiones cada vez más completas del sistema diseñado
(Pressman 1992).
Figura 3. Un modelo espiral típico.
18
El modelo en espiral se divide en un número de actividades de marco de trabajo,
también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones
de tareas:
Comunicación con el cliente.
Planificación.
Análisis de riesgo.
Ingeniería
Construcción y acción
Evaluación del cliente.
2.3.1.5 Modelo espiral WIN-WIN (Victoria&Victoria)
El objetivo de este modelo es mostrar los requisitos del cliente. En un contexto ideal, el
desarrollador simplemente pregunta al cliente lo que necesita y el cliente proporciona
detalles suficientes para continuar. Desgraciadamente esto raramente ocurre. En
realidad el cliente y el desarrollador entran en un proceso de negociación, donde el
cliente puede ser preguntado para sopesar la funcionalidad, en rendimiento, y otros
productos o características del sistema frente al coste y al tiempo de comercialización
(Pressman 1992).
Figura 4. El modelo en espiral WinWin
19
Más que una simple actividad de comunicación con el cliente, se definen las siguientes
actividades:
Identificación del sistema o subsistemas clave de los “directivos”.
Determinación de las condiciones de “victoria” de los directivos.
Negociación de las condiciones de “victoria” de los directivos para reunirlas en un
conjunto de condiciones “Victoria&Victoria” para todos los afectados (incluyendo
el equipo del proyecto de software).
Las mejores negociaciones se esfuerzan en obtener “Victoria&Victoria”. Esto es,
el cliente gana obteniendo el producto o sistema q satisface la mayor parte de
sus necesidades y el desarrollador gana trabajando para conseguir presupuestos
y lograr una fecha de entrega realista.
2.3.1.6 Modelo de desarrollo concurrente
El modelo de proceso concurrente se puede representar en forma de esquema como
una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
Este modelo define una serie de acontecimientos que disiparan transacciones de
estado a estado para cada una de las actividades de la ingeniería del software. Por
ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia
del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos,
que disparará la actividad de análisis del estado hecho al estado cambios en espera.
La dimensión de componentes se afronta con dos actividades: diseño y realización. Lac
concurrencia se logra de dos formas: (1) las actividades del sistema y de componentes
ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos; (2)
una aplicación cliente-servidor típico se implementa con muchos componentes, cada
una de los cuales se pueden diseñar y realizar concurrentemente. En realidad, el
modelado de proceso concurrente es aplicable a todo tipo de desarrollo de software y
proporciona una imagen exacta del estado actual de un proyecto (Pressman 1992).
20
Figura 5. Un elemento del modelo de proceso concurrente.
2.3.1.7 Desarrollo basado en componentes
El desarrollo basado en componentes como lo menciona Pressman, incorpora muchas
de las características del modelo en espiral. Es evolutivo por naturaleza, y exige un
enfoque interativo para la creación del software. Sin embargo, el modelo de desarrollo
basado en componentes configura apliaciones desde componentes preparados de
software (llamadas “clases”).
Esta actividad se lleva a cabo examinando los datos que se van a manejar por parte de
la aplicación y el algoritmo que se va a aplicar para conseguir el tratamiento. Los datos
y los algoritmos correspondientes se empaquetan en una clase.
Las clases creadas en los proyectos de ingeniería del software anterior, se almacenan
en una biblioteca de clases o diccionario de datos (repository). Una vez identificadas las
clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya
existen. En caso de que así fuera, se extraen de la biblioteca y se vuelven a utilizar. Si
una clase candidata no reside en la biblioteca, se aplican los métodos orientados
objetos. Se compone así la primera iteración de la aplicación a construirse, mediante las
clases extraídas de la biblioteca y las clases nuevas construidas para cumplir las
necesidades Únicas de la aplicación. El flujo del proceso vuelve a la espiral y volverá a
introducir por último la iteración ensambladora de componentes a través de la actividad
21
de ingeniería. Pressman dice que el modelo de desarrollo basado en componentes
conduce a la reutilización del software, y la reutilización proporciona beneficios a los
ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. Informa
que el ensamblaje de componentes lleva a una reducción del 70 por 100 de tiempo de
ciclo de desarrollo, un 84 por 100 del coste del proyecto y un índice de productividad del
26.2, comparado con la norma de industria del 16.9. Aunque estos resultados están en
función de la robustez de la biblioteca de componentes, no hay duda de que el
ensamblaje de componentes proporciona ventajas significativas para los ingenieros de
software.
Figura 5. Desarrollo basado en componentes
2.3.2 Métodos de desarrollo de software
Los métodos de la ingeniería del software indican “cómo” construir técnicamente el
software. Los métodos abarcan una gran gama de tareas que incluyen análisis de
requisitos, diseño, construcción de programas, pruebas y mantenimiento. Los métodos
de la ingeniería del software dependen de un conjunto de principios básicos que
gobiernan cada área de la tecnología e incluyen actividades de modelado y otras
técnicas descriptivas (Pressman, 1992).
22
Sommerville menciona que un método de ingeniería de software es un enfoque
estructurado para el desarrollo de software cuyo propósito es facilitar la producción de
software de alta calidad de una forma costeable.
Todos los métodos se basan en la idea de modelos gráficos de desarrollo de un
sistema y en el uso de estos modelos como un sistema de especificación o diseño.
2.3.3 Herramientas para la creación de software
Las herramientas de la Ingeniería del software proporcionan un enfoque automático o
semi-automático para el proceso y para los métodos. Cuando se integran herramientas
para que la información creada por una herramienta la pueda utilizar otra, se establece
un sistema de soporte para el desarrollo del software llamado ingeniería del software
asistida por computadora (CASE).
CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de
mejorar su visión general de la ingeniería, estas herramientas CASE ayudan a
garantizar que la calidad se diseñe antes de llegar a construir el producto (Pressman
1992).
Herramientas de ingeniería de procesos de negocio: El objetivo primordial de
las herramientas de esta categoría consiste en representar objetos de datos de
negocios, sus relaciones, y la forma en que fluyen estos objetos de datos entre
distintas zonas de negocio en el seno de la compañía.
Modelado de procesos y herramientas de gestión: Las herramientas de
modelado de procesos (llamadas también herramientas de tecnología de
procesos) se utilizan para representar los elementos clave del proceso de
manera que sea posible entenderlo mejor. Estas herramientas también pueden
proporcionar vínculos con descripciones de procesos que ayuden a quienes
estén implicados en el proceso de comprender las tareas que se requieren para
llevar a cabo ese proceso.
23
Herramientas de planificación de proyectos: Las herramientas de esta
categoría se concentran en dos áreas primordiales: Estimación de esfuerzos de
proyecto y de costes de software y planificación de proyectos. Las herramientas
de estimación calculan el esfuerzo estimado, la duración del proyecto y el
número recomendado de personas.
Herramientas de análisis de riesgos: La identificación de posibles riesgos y el
desarrollo de un plan para mitigar, monitorizar y gestionar esos riesgos tienen
una importancia fundamental en los proyectos grandes. Las herramientas de
análisis de riesgos hacen posible que el gestor del proyecto construya una tabla
de riesgos proporcionando una guía detallada en la identificación y análisis de
riesgos.
Herramientas de gestión de proyectos: La planificación del proyecto y el plan
del proyecto deberán ser rastreados y monitorizados de forma continua.
Herramientas de seguimiento de requisitos: Las herramientas típicas de
seguimiento de requisitos combinan una evaluación de textos por interacción
humana, con un seguimiento de gestión de bases de datos que almacena y
categoriza todos y cada uno de los requisitos del sistema que se <<analizan>> a
partir de la RFP o especificación original.
Herramientas de métricas y de gestión: Las herramientas con orientación
técnica determinan las métricas técnicas que proporcionan una mejor visión de la
calidad del diseño o del código.
Herramientas de documentación: las herramientas de documentación suponen
una oportunidad importante para mejorar la productividad.
Herramientas de software de sistema: CASE es una tecnología de estaciones
de trabajo. Por tanto, el entorno CASE debe adaptase a un software de sistema
en redes de alta calidad, al correo electrónico, a los boletines electrónicos y a
otras capacidades de comunicaciones.
Herramientas de control de calidad: Las herramientas de control de calidad
son en realidad herramientas métricas que hace una auditoria del código fuente
para determinar si es justa o no a ciertos estándares del lenguaje.
24
Herramientas de gestión de base de datos: El software de gestión de bases
de datos sirve como fundamentos para establecer una base de datos CASE
(repositorio), que también se denominará base de datos del proyecto.
Herramientas de configuración de software: La gestión de configuración de
software (GCS) se encuentra en el núcleo de todos los entornos CASE. Las
herramientas pueden ofrecer su asistencia en las cinco tareas principales de
GCS: (identificación, control de versiones control de cambios, auditorias y
contabilidad de estados).
Herramientas de análisis y diseño: Las herramientas de análisis y diseño
capacitan al ingeniero del software para crear modelos del sistema que haya que
construir. Los modelos contienen una representación de los datos, de la función y
del comportamiento (en el nivel de análisis), así como caracterizaciones del
diseño de datos, arquitectura, procedimientos e interfaz.
Herramientas PRO/SIM: Las herramientas PRO/SIM (de prototipos y
simulación) proporcionan al ingeniero del software la capacidad de predecir el
comportamiento de un sistema en tiempo real antes de llegar a construirlo.
Herramientas de desarrollo y diseño de interfaz: Las herramientas de
desarrollo y diseño de interfaz son en realidad un conjunto de primitivas de
componente de programas tales como menús, botones, estructuras de ventanas,
iconos, mecanismos de desplazamiento, controladores de dispositivos, etc.
Herramientas de construcción de prototipos: Se puede utilizar toda una gama
de herramientas de generación de prototipos. Los generadores de pantallas
permiten al ingeniero de software definir rápidamente la disposición de pantalla
para aplicaciones interactivas.
Herramientas de programación: La categoría de herramientas de
programación abarca los compiladores, editores y depuradores que están
disponibles para apoyar a la mayoría los lenguajes de programación, los
lenguajes de cuarta generación, los entornos de programación gráfica, los
generadores de aplicaciones y los lenguajes de consulta de bases de datos.
Herramientas de desarrollo de Web: Las actividades asociadas a la ingeniería
Web están apoyadas por una variedad de herramientas de desarrollo de Web.
Entre estas herramientas se incluyen las que prestan ayuda a la generación de
25
texto, gráficos, formularios, guiones, applets, y otros elementos de una página
Web.
Herramientas de integración y pruebas: Adquisición de datos: herramientas
que adquieren datos que se utilizaran durante la prueba; Medida estática:
herramientas que analizan el código fuente sin ejecutar casos de prueba;
Medida dinámica: herramientas que analizan el código fuente durante la
ejecución; Simulación: herramientas que simulan las funciones del hardware o de
otros elementos externos; Gestión de pruebas: herramientas que prestan su
asistencia en la planificación, desarrollo y control de las pruebas; Herramientas
de funcionalidad cruzada: se trata de herramientas que cruzan los limites de las
categorías anteriores.
Herramientas de análisis estático: Las herramientas de análisis estático
prestan su asistencia al ingeniero del software a efectos de derivar casos
prácticos. Se utilizan tres tipos distintos de herramientas estáticas de
comprobación en la industria: herramientas de comprobación basadas en código,
lenguajes de comprobación especializados, y herramientas de comprobación
basadas en requisitos.
Herramientas de análisis dinámico: Las herramientas de análisis dinámico
interactúan con un programa que se esté ejecutando, comprueban la cobertura
de rutas, comprueban las afirmaciones acerca del valor de variables específicas
e instrumentan por otro lado el flujo de ejecución del programa.
Herramientas de gestión de pruebas: Se utilizan para controlar y coordinar las
pruebas del software por todos y cada uno de los pasos principales de las
pruebas. Las herramientas de esta categoría gestionan y coordinan las pruebas
de regresiones, efectúan comparaciones que determinan las diferencias entre la
salida real y esperada y realizan pruebas por lotes de programas con interfaces
hombre-máquina interactivas.
Herramientas de pruebas cliente/servidor: El entorno C/S existe unas
herramientas de comprobación especializadas que ejerciten la interfaz gráfica de
usuario y los requisitos de comunicaciones en red para el cliente y el servidor.
Herramientas de reingeniería: La categoría de herramientas de reingeniería se
pueden subdividir en las funciones siguientes: Herramientas de ingeniería
26
inversa para producir especificaciones: se toma el código fuente como entrada y
se generan modelos gráficos de análisis y diseño estructurados, listas de
utilización y otras informaciones de diseño; Herramientas de reestructuración y
análisis de código: se analiza la sintaxis del programa, se genera una gráfica de
control de flujo y se genera automáticamente un programa estructurado;
Herramientas de reingeniería para sistemas en línea: se utilizan para modificar
sistemas de bases de datos en línea (por ejemplo: para convertir archivos IDMS
o DB2 traduciéndolos a un formato de entidades y relaciones).
2.4 Un Enfoque de Calidad
Algunos desarrolladores de software continúan creyendo que la calidad del software es
algo en lo que empiezan a preocuparse una vez que se ha generado el código. ¡Nada
más lejos de la realidad! La garantía de calidad del software (SQA, Software Quality
Assurance GCS, Gestión de calidad del software) es una actividad de protección que se
aplica a lo largo de todo el proceso del software. La SQA engloba: (1) un enfoque de
gestión de calidad; (2) tecnología de ingeniería del software efectiva (métodos y
herramientas); (3) revisiones técnicas formales que se aplican durante el proceso del
software; (4) una estrategia de prueba multiescalada; (5) el control de la documentación
del software y de los cambios realizados; (6) un procedimiento que asegure un ajuste a
los estándares de desarrollo del software (cuando sea posible), y (7) mecanismos de
medición y de generación de informes.
2.4.1 Calidad
Todas las metodologías y herramientas tienen un único fin producir software de gran
calidad
Definiciones de calidad del software:
“Concordancia con los requisitos funcionales y de rendimiento explícitamente
establecidos con los estándares de desarrollo explícitamente documentados y
27
con las características implícitas que se espera de todo software desarrollado
profesionalmente” Pressman (1992).
“El conjunto de características de una entidad que le confieren su aptitud para
satisfacer las necesidades expresadas y las implícitas” ISO 8402 (UNE 66-001-
92).
El American Heritage Dictionary, define la calidad como «una característica o
atributo de algo». Como un atributo de un elemento, la calidad se refiere a las
características mensurables -cosas que se pueden comparar con estándares
conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin
embargo, el software en su gran extensión, como entidad intelectual, es más
difícil de caracterizar que los objetos físicos.
No obstante, si existen las medidas de características de un programa. Entre estas
propiedades se incluyen complejidad ciclomática, cohesión, número de puntos de
fusión, líneas de código, etc.
La obtención de un software con calidad implica la utilización de metodologías o
procedimientos estándares para el análisis, diseño, programación y prueba del software
que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la
labor de desarrollo como para el control de la calidad del software.
Cuando se examina un elemento según sus características mesurables, se pueden
encontrar dos tipos d calidad: calidad del diseño y calidad de concordancia.
La calidad del diseño se refiere a las características que especifican los ingenieros para
un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento
contribuyen a la calidad del diseño. Cuando se utilizan materiales de alto grado y
especifican tolerancias más estrictas y niveles más altos de rendimiento, la calidad de
diseño de un producto aumenta, si el producto se fabrica de acuerdo con las
especificaciones. La calidad de concordancia es el grado de cumplimiento del las
especificaciones de diseño durante su realización. Una vez más, cuanto mayor sea el
28
grado de cumplimiento, mas alto será el nivel de calidad de concordancia. En el
desarrollo del software, la calidad de diseño comprende los requisitos, especificaciones
el diseño del sistema. La calidad de concordancia es un aspecto centrado
principalmente en la implementación. Si la implementación sigue el diseño, y el sistema
resultante cumple los objetivos de requisitos y rendimiento, la calidad de concordancia
es alta (Pressman, 1992).
2.4.1.1 Control de calidad
El control de cambios puede equipararse al control de calidad. Pero, ¿cómo se logra el
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
cumple con los requisitos que le han sido asignados. El control de calidad incluye un
bucle de realimentación (feedback) del proceso que creó el producto. La combinación
de medición y realimentación permite afinar el proceso cuando los productos de trabajo
creados fallan al cumplir sus especificaciones. Este enfoque ve el control de calidad
como parte del proceso de fabricación (Pressman 1992).
Las actividades de control de calidad pueden ser manuales, completamente
automáticas o una combinación de herramientas automáticas e interacción humana. Un
concepto clave del control de calidad es que se hayan definido todos los productos y las
especificaciones mensurables en las que se puedan comparar los resultados de cada
proceso. El bucle de realimentación es esencial para reducir los defectos producidos.
2.4.1.2 Garantía de calidad
La garantía de calidad consiste en la auditoría y las funciones de información de la
gestión. El objetivo de la garantía de calidad es proporcionar la gestión para informar de
los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una
visión más profunda y segura de que la calidad del producto está cumpliendo sus
objetivos. Por supuesto, si los datos proporcionados mediante la garantía de calidad
29
identifican problemas, es responsabilidad de la gestión afrontar los problemas y aplicar
los recursos necesarios para resolver aspectos de calidad (Pressman, 1992).
2.4.1.3 Coste de calidad
El coste de calidad incluye todos los costes acarreados en la búsqueda de la calidad o
en las actividades relacionadas en la obtención de la calidad. Se realizan estudios
sobre el coste de calidad para proporcionar una línea base del coste actual de calidad,
para identificar oportunidades de reducir este coste, y para proporcionar una base
normalizada de comparación. La base de normalización siempre tiene un precio. Una
vez que se han normalizado los costes de calidad sobre un precio base, tenemos los
datos necesarios para evaluar el lugar en donde hay oportunidades de mejorar nuestros
procesos. Es más, podemos evaluar cómo afectan los cambios en términos de dinero.
(Pressman, 1992)
Los costes de calidad se pueden dividir en costes asociados con la prevención, la
evaluación y los fallos.
Entre los costes de prevención se incluyen:
planificación de la calidad,
revisiones técnicas formales,
equipo de pruebas,
formación.
Entre los costes de evaluación se incluyen actividades para tener una visión más
profunda de-la condición del producto «la primera vez a través de» cada proceso.
A continuación se incluyen algunos ejemplos de costes de evaluación:
inspección en el proceso y entre procesos,
calibrado y mantenimiento del equipo,
pruebas.
30
2.4.2 Aseguramiento de la calidad del software
El aseguramiento de calidad del software es el conjunto de actividades
planificadas y sistemáticas necesarias+ para aportar la confianza en que el
producto (software) satisfará los requisitos dados de calidad.
El aseguramiento de calidad del software se diseña para cada aplicación antes
de comenzar a desarrollarla y no después.
Algunos autores prefieren decir garantía de calidad en vez de aseguramiento.
o Garantía, puede confundir con garantía de productos.
o Aseguramiento pretende dar confianza en que el producto tiene calidad.
El aseguramiento de calidad del software está presente en:
o Métodos y herramientas de análisis, diseño, programación y prueba.
o Inspecciones técnicas formales en todos los pasos del proceso de
desarrollo del software.
o Estrategias de prueba multiescala
o Control de la documentación del software y de los cambios realizados
o Procedimientos para ajustarse a los estándares (y dejar claro cuando se
está fuera de ellos).
o Mecanismos de medida (métricas).
o Registro de auditorías y realización de informes.
Actividades para el aseguramiento de calidad del software
o Métricas de software para el control del proyecto.
o Verificación y validación del software a lo largo del ciclo de vida.
Incluye las pruebas y los procesos de revisión e inspección
o La gestión de la configuración del software
2.4.3 Gestión de la calidad del software
El estándar ISO 9000, que ha sido adoptado por más de 130 países para su uso, se ha
convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia
de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está
31
en que no es específico de la industria: está expresado en términos generales, y puede
ser interpretado por los desarrolladores de diversos productos como automóviles,
equipamientos deportivos y televisiones, así como por desarrolladores de software. Se
han realizado muchos documentos que relacionan el estándar con la industria del
software, pero no entran en una gran cantidad de detalles. El objetivo de esta sección
es describir lo que significa el ISO 9001 en términos de elementos de calidad y técnicas
de desarrollo (Pressman, 1992).
Para la industria del software los estándares relevantes son:
ISO 9001. Quality Systems- Model for Quality Assurance in Design,
Development, Production, Installation and Servicing. Este es un estándar que
describe el sistema de, calidad utilizado para mantener el desarrollo de un
producto que implique diseño.
ISO 9000-3. Guidelines for Application of ISO 9001 to the Development, Supply
and Maintainance of ISO 9004-2. Quality Management and Quality System
Elements -Part 2-. Este documento proporciona las directrices para el servicio de
facilidades del software como soporte de usuarios.
2.4.4 Sistema de calidad
• Sistema de calidad
– Estructura organizativa, procedimientos, procesos y recursos necesarios
para implantar la gestión de calidad.
• El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa
• La dirección de la empresa es la responsable de fijar la política de calidad y las
decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de
calidad.
• Un sistema de calidad consta de varias partes
– Documentación
32
• Manual de calidad. Es el documento principal para establecer e
implantar un sistema de calidad. Puede haber manuales a nivel de
empresa, departamento, producto, específicos (compras,
proyectos,…)
– Parte física: locales, herramientas ordenadores, etc.
– Aspectos humanos:
• Formación de personal
• Creación y coordinación de equipos de trabajo
2.4.5 Certificación de la calidad
Un sistema de certificación de calidad permite una valoración independiente que debe
demostrar que la organización es capaz de desarrollar productos y servicios de calidad
Los pilares básicos de la certificación de calidad son tres:
Una metodología adecuada
Un medio de valoración de la metodología
La metodología utilizada y el medio de valoración de la metodología deben estar
reconocidos ampliamente por la industria.
2.4.5.1 Capability Maturity Model Integration
Integración de Modelos de Madurez de Capacidades o Capability Maturity Model
Integration (CMMI) es un modelo para la mejora y evaluación de procesos para el
desarrollo, mantenimiento y operación de sistemas de software.
Mediante la aplicación de CMMI se obtiene un Nivel de Madurez de los procesos de
construcción de software, integrados en las disciplinas base Ingeniería de Sistemas,
Ingeniería de Software e Integración de componentes.
33
CMMI incluye cinco niveles de madurez, siendo el más básico el Nivel 2 (Gestión de
Proyectos) y el esfuerzo de alcanzarlo, dependerá fuertemente de la cultura de trabajo
de cada empresa.
Estos análisis permiten detectar los flancos débiles de los procesos fortaleciéndolos en
forma homogénea e integra, mediante la aplicación de mejoras, en aquellas áreas
consideradas poco eficientes.
El objetivo de CMMI es proveer una guía para mejorar los procesos de una
organización y la habilidad para gestionar el desarrollo, adquisición y mantenimiento de
productos o servicios.
CMMI provee un acercamiento a la estructura de su organización, ayudándolo a evaluar
el grado de maduración organizacional y estableciendo prioridades para mejorar e
implementar esas mejoras.9
Categorías de mejoras, beneficios:
Mejoras en la predictibilidad de plazos y presupuestos.
Mejoras en los ciclos de vida de construcción de software.
Mejoras en la productividad.
Mejoras en la Calidad (medida por defectos).
Incrementa la satisfacción del Cliente.
Mejora la moral de los empleados.
Mejora el retorno de la inversión.
Decremento el costo de Calidad.
2.4.5.2 Modelo de Procesos para la Industria del Software
Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de
sistemas y productos de software. Desarrollado por la Asociación Mexicana para la
9 http://www.asnnetwork.com.ar/detalle.php?IDSECCION=354
34
Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad
Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para
obtener una norma mexicana que resulte apropiada a las características de tamaño de
la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software.
Moprosoft es el nombre del modelo en la comunidad universitaria y profesional, y la
norma técnica a la que da contenido es la NMX-059/01-NYCE-2005 que fue declarada
Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el
Diario de la Federación.
Moprosoft, tiene por objetivo proporcionar a la industria mexicana, y a las áreas internas
dedicadas al desarrollo y mantenimiento de software, un conjunto integrado de las
mejores prácticas basadas en los modelos y estándares reconocidos
internacionalmente, tales como ISO 9000:2000, CMM-SW, ISO/
IEC 15504, PMBOK, SWEBOK entre otros.
Moprosoft contiene tres categorías de procesos que corresponden a las capas de Alta
Dirección, Gestión y Operación. La categoría de Alta Dirección contiene el proceso de
Gestión de Negocio; la categoría de Gestión se compone de Gestión de Procesos,
Gestión de Proyectos y Gestión de Recursos, a su vez, este último se divide en tres
subprocesos: el de Recursos Humanos, el de Bienes, Servicios e Infraestructura y el de
Conocimiento de la Organización. Finalmente, la categoría de Operación contiene los
procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento
de Software.
Moprosoft, a diferencia de CMM-SW y CMMI, está dirigido a la micro y pequeña
industria. Sintetiza las mejores prácticas en un conjunto pequeño de procesos que
abarcan las responsabilidades de la alta dirección, gestión y operación. Se trata de un
modelo integrado, en el cual: las salidas de un proceso están claramente dirigidas como
entradas a otros procesos; las prácticas de planeación, seguimiento y evaluación se
incluyeron en todos los procesos de gestión y administración; los objetivos, los
indicadores, las mediciones y las metas cuantitativas fueron incorporadas de manera
congruente y práctica en todos los procesos; las verificaciones, validaciones y pruebas
35
están incluidas de manera explícita dentro de las actividades de los procesos; y existe
una base de conocimiento que resguarda todos los documentos y productos generados
por los procesos.
En otras palabras, es un modelo que –de manera más pragmática que otros– presenta
las mejores prácticas para la industria de software.
En la actualidad, es indudable que el software es la herramienta que establece las
dinámicas laborales, de producción y hasta de convivencia en todo el mundo.
Los múltiples desarrollos que en este ámbito se dan –casi cotidianamente–generan
como consecuencia la necesidad de establecer cánones de calidad para cada producto,
para así garantizar que su desempeño y sus funciones cubran las expectativas de sus
consumidores y que, en la praxis, cumplan con su cometido satisfactoriamente.
2.4.6 Factores que determinan la calidad del software
Se clasifican en tres grupos:
• Operaciones del producto: características operativas
– Corrección (¿Hace lo que se le pide?)
• El grado en que una aplicación satisface sus especificaciones y
consigue los objetivos encomendados por el cliente.
– Fiabilidad (¿Lo hace de forma fiable todo el tiempo?)
• El grado que se puede esperar de una aplicación lleve a cabo las
operaciones especificadas y con la precisión requerida
– Eficiencia (¿Qué recursos hardware y software necesito?)
• La cantidad de recursos hardware y software que necesita una
aplicación para realizar las operaciones con los tiempos de
respuesta adecuados.
– Integridad (¿Puedo controlar su uso?)
36
• El grado con que puede controlarse el acceso al software o a los
datos a personal no autorizado.
– Facilidad de uso (¿Es fácil y cómodo de manejar?)
• El esfuerzo requerido para aprender el manejo de una aplicación,
trabajar con ella, introducir datos y conseguir resultados
• Revisión del producto: capacidad para soportar cambios
– Facilidad de mantenimiento (¿Puedo localizar los fallos?)
• El esfuerzo requerido para localizar y reparar errores
– Flexibilidad (¿Puedo añadir nuevas opciones?)
• El esfuerzo requerido para modificar una aplicación en
funcionamiento
– Facilidad de prueba (¿Puedo probar todas las opciones?)
• El esfuerzo requerido para probar una aplicación de forma que
cumpla con lo especificado en los requisitos
• Transición del producto: adaptabilidad a nuevos entornos
– Portabilidad (¿Podré usarlo en otra máquina?)
• El esfuerzo requerido para transferir la aplicación a otro hardware
o sistema operativo.
– Reusabilidad (¿Podré utilizar alguna parte del software en otra
aplicación?)
• Grado en que partes de una aplicación pueden utilizarse en otras
aplicaciones
– Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o
sistemas informáticos?
• El esfuerzo necesario para comunicar la aplicación con otras
aplicaciones o sistemas informáticos.
CAPÍTULO III
DESARROLLO DE LA
INVESTIGACION
37
3.1 Metodología de desarrollo
Para obtener respuesta a nuestros objetivos planteados en esta investigación se realizo
la recolección sistemática de datos de poblaciones o de muestras de población que
deben obtenerse mediante el uso de entrevistas personales.
Esta encuesta tiene como finalidad conocer el panorama real y la situación actual que
se vive en las casas productoras de desarrollo de software en la región de Los Mochis,
Sinaloa, muestra los retos a los que se enfrentan como: las acreditaciones y/o
certificaciones que como empresa es necesario para obtener acceso a proyectos de
desarrollo importantes, debemos mencionar que las empresas encuestadas se
encuentran en constante crecimiento y a la vanguardia tecnológica adecuada a las
necesidades que demandan los sectores públicos y privados de la región de Los
Mochis.
La presente encuesta fue diseñada con la finalidad de dar respuesta a los objetivos que
fueron planteados al inicio de esta investigación.
Ejemplo de encuesta aplicada a las principales casas productoras y desarrolladoras de
software en Los Mochis, Sinaloa:
1. ¿Conoce alguna metodología en el desarrollo de software?
2. ¿Conoce organizaciones que certifiquen las metodologías de software, cuáles?
3. ¿Qué metodología utilizan en el desarrollo de software?
4. ¿La empresa cuenta con alguna certificación, cuáles?
5. ¿Cuáles son las áreas de certificación con las que cuenta la empresa?
6. ¿Sus analistas y/o programadores cuentan con alguna certificación, cuáles?
7. ¿Cuáles son los principales problemas para tener acceso a proyectos de
desarrollos importantes?
8. ¿Cuáles son las recomendaciones para que las empresas produzcan software de
calidad?
38
Entre las empresas que fueron consideradas para esta investigación, se selecciono una
muestra representativa para esta investigación de campo.
Empresas entrevistadas:
SHYA
IMAGENSOFT
ÉXITO
MACROPRO
DASI DESARROLLO
A continuación se presentan los resultados obtenidos de esta investigación llevada a
cabo en los días de 24 de mayo al 07 de junio de 2010.
39
3.2 Presentación, análisis e interpretación de resultados
1. ¿Conoce alguna metodología en el desarrollo de software?
2. ¿Qué metodología utilizan en el desarrollo de software?
3. ¿Conoce Organizaciones que Certifiquen las metodologías de software, cuáles?
100%
0%
Si
No
50%
33%
17% Programacion Orientada a Objetos
RUP
CMMI-DEV
100%
0%
si
no
40
4. ¿La Empresa cuenta con alguna certificación, cuáles?
43%
14%
29%
14%
Innevo
Cega Software
Sei
Nyce
100%
0%
Si
No
22%
34%
22%
11%
11%Moprosoft
CMMI
Syscom
Panasonic
siemens
41
5. ¿Cuáles son las áreas de certificación con las que cuenta la empresa?
6. ¿Sus analistas y/o programadores cuentan con alguna certificación, cuáles?
29%
14%
14%
29%
14%Desarrollo
CCTV
Soporte
Procesos
Calidad
100%
0%
Si
No
14%
43%14%
29%ASP.net
ADO.net
UML
SQL
42
En las siguientes preguntas no se cuantificaron los resultados debido a que no fueron
enfocadas para ser consideradas y tomadas en cuenta como tal, sino para conocer la
situación por la cual atraviesan las empresas al momento de hacer desarrollo de
software.
7. ¿Cuáles son los principales problemas para tener acceso a proyectos de
desarrollo importantes?
Las empresas desarrolladoras de software en la región de Los Mochis nos
mencionan que el principal problema es la falta de cultura de software en la
entidad por parte de las empresas clientes que están establecidas en la región,
así como el factor económico por parte de las ellas para invertir en software para
sus organizaciones, ya que piensan que es un riesgo invertir en este tipo de
tecnología.
8. ¿Cuáles son las recomendaciones para que las empresas produzcan software de
calidad?
Las empresas recomiendan el trabajar bajo procesos y estándares de calidad
que avalen su trabajo de desarrollo y productos de software, así como la mejora
continua de sus procesos.
Además de tener al personal y empresa capacitados bajo normas y estándares
de calidad para llevar a cabo sus procesos y actividades de desarrollo y ver que
se apliquen constantemente para llevar a la mejora continua de los procesos de
calidad en cada una de las actividades realizadas
Como se esperaba se logro obtener información acerca de la situación actual que se
vive en las empresas de desarrollo de software en la región de Los Mochis, Sinaloa,
además de conocer los retos a los que se enfrentan ( acreditaciones y/o certificaciones)
como empresa es necesario para obtener acceso a proyectos de desarrollo
importantes, debemos mencionar que las empresas encuestadas se encuentran
certificadas y acreditadas lo que les permite tener en constante crecimiento y estar a la
43
vanguardia tecnológica adecuada a las necesidades que demandan los sectores
públicos y privados de la región de Los Mochis.
Con los resultados obtenidos de las encuestas se logro responder a los objetivos
planteados en nuestra investigación.
Objetivos
Generales:
Mostrar y analizar el panorama actual en la elaboración y construcción de
software en la región de Los Mochis, Sinaloa.
Específicos:
Describir las metodologías para elaboración de software.
Analizar las consideraciones de la calidad de la ingeniería del software.
Para responder al objetivo general podemos mencionar que las casas desarrolladoras
de software se han preocupado por ser empresas de tipo mundial es decir producir
software de alta calidad basados en estándares propios de la ingeniería del software
esto permite poner a la ciudad de Los Mochis a la vanguardia en calidad y metodologías
de desarrollo de software, entre las metodologías utilizadas para el desarrollo se
encuentran la programación orientada a objetos, metodología RUP y estándares de
CMMI solo por mencionar algunos.
En cuanto a los objetivos específicos se observo que existe una cultura de calidad y
certificación por parte de las empresas desarrolladoras de software para acreditar sus
actividades y lograr software de calidad, entre las certificaciones con las que cuentan
las empresas son CMMI, Panasonic, Siemens y MOPROSOFT certificándose en áreas
de desarrollo, procesos, calidad y soporte de software, lo cual avala la seriedad y
formalidad de su trabajo.
CAPÍTULO IV
CONCLUSIONES Y
RECOMENDACIONES
44
Conclusiones
En la actualidad, el software de computadoras es la tecnología individual más
importante en el ámbito mundial. El software se ha convertido en una tecnología
indispensable en los negocios, la ciencia y la ingeniería; permitiendo la creación de
tecnologías nuevas (Ing. Genética), la extensión de tecnologías existentes
(Telecomunicaciones).
La ingeniería de software ha llegado a convertirse en el proceso de construir
aplicaciones de tamaño o alcance prácticos, en las que predominan el esfuerzo del
software y que satisface los requerimientos de funcionalidad, desempeño y calidad.
Un elemento clave de cualquier proceso de ingeniería es la medición. Empleamos
medidas para entender mejor los atributos de los modelos que creamos. Pero,
fundamentalmente, empleamos las medidas para valorar la calidad de los productos de
ingeniería o de los sistemas que construimos. A diferencia de otras disciplinas, la
ingeniería del software no está basada en leyes cuantitativas básicas de la física. Las
medidas absolutas, tales como el voltaje, la masa, la velocidad o la temperatura no son
comunes en el mundo del software. En su lugar, intentamos obtener un conjunto de
medidas indirectas que dan lugar a estándares que proporcionan una identificación de
la calidad de algún tipo de representación del software. Sin embargo las medidas y
estándares de software no son absolutas.
Existen organismos reguladores de software que proporcionan las herramientas para
producir software de calidad permitiendo detectar los flancos débiles de los procesos y
fortaleciéndolos en forma homogénea e íntegra, mediante la aplicación de mejoras, en
aquellas áreas consideradas poco eficientes. Proporcionando una guía para mejorar los
procesos de una organización y la habilidad para gestionar el desarrollo, adquisición y
mantenimiento de productos o servicios.
45
Esta investigación se logro mostrar la situación actual de desarrollo de software en la
ciudad de Los Mochis ya que como estudiantes teníamos la inquietud de conocer y
exponer el proceso de desarrollo y los requerimientos de calidad utilizados en la
elaboración de software. Para dar solución a esta inquietud nos planteamos los
siguientes objetivos específicos:
Describir las metodologías para elaboración de software.
Analizar las consideraciones de la calidad de la ingeniería del software.
Dimos respuesta a estos objetivos mediante una investigación documental e
investigación de campo en algunas empresas desarrolladoras de software en la ciudad
de Los Mochis.
El objetivo número uno se respondió con la investigación plasmada en el capítulo II del
tema 2.2 Metodologías de la programación de este proyecto en el cual, se mencionan
aspectos como los procesos, métodos y herramientas de desarrollo de software.
Respecto al objetivo número dos, iniciamos dándole solución mediante la aplicación de
encuestas a las empresas desarrolladoras de software para conocer de primera mano
lo que se vive actualmente en las empresas, haciendo hincapié en los aspectos y
consideraciones de calidad. Complementándolo con información recabada en el tema
2.4 Un enfoque de calidad.
De manera general se observo que existe una cultura de calidad y certificación por
parte de las empresas desarrolladoras de software para acreditar sus actividades y
lograr software de calidad, entre las certificaciones con las que cuentan las empresas
son CMMI, Panasonic, Siemens y MOPROSOFT certificándose en áreas de desarrollo,
procesos, calidad y soporte de software, lo cual avala la seriedad y formalidad de su
trabajo. Permitiendo poner a la ciudad de Los Mochis a la vanguardia en calidad y
metodologías de desarrollo de software.
46
Para finalizar este proyecto se recomienda continuar con esta investigación ya que se
mencionaron aspectos de suma importancia como los son los retos a los que se
enfrentan las empresas para obtener las acreditaciones y/o certificaciones, obtener
acceso a proyectos importantes de desarrollo, la obtención de recursos mediante
certificaciones que avalan la calidad y seriedad de la empresa y por consecuente el
producto (software)
47
BIBLIOGRAFÍA
1. Braude, Ingeniería de software una perspectiva orientada a objetos. Pearson
educación, mexico, 2002.
2. Sommerville, Ingeniria del Sofware, 7° edición, Pearson Addison Wesley,
2006.
3. SENN, James. "Análisis y Diseño de Sistemas de Información"
4. DRAE, Diccionario de la Real Academia Española de la Lengua.
5. Vocabulario Científico y Técnico, edición de 1996.
6. Zelkovitz, M. V., Shaw, A. C. y Gannon, J. D.: Principles of Software
Engineering and Desing. Prentice-Hall, Englewoods Clig, 1979.
7. Boehm, B. W.: «Software Engineering», IEEE Transactions on Computers, C-
25, núm. 12, diciembre, pp. 1226-1241.
8. Bauer, F.L: «Software Engineering», Information Processing, 71, North
Holland Publishing Co., Amsterdam, 1972.
9. Pressman, Ingenieria del software un enfoque practico. 5ta. Edicion
10. Walt Scacchi: "Models of Software Evolution: Life Cycle and Process", SEI
Curriculum Module SEI-CM-10-1.0, Oct. 1987.
11. http://www.asnnetwork.com.ar/detalle.php?IDSECCION=35