Ingeniería de Software: Introducción, Mitos, Paradigmas y Calidad

INGENIERIA DE SOFTWARE
SISTEMAS Y COMPUTACION
INSTITUTO TECNOLÓGICO DE
TLALNEPANTLA
DEPARTAMENTO DE SISTEMAS Y COMPUTACION
INGENIERIA EN TECNOLOGIAS DE INFORMACION Y

COMUNICACIONES
UNIDAD I
INTRODUCCION A LA INGENIERIA DE SOFTWARE

Y SISTEMAS DE INFORMACION
PROFESOR:
DR. ANTONIO NAVARRETE PRIETO
CURSO: 2017
1
DR. ANTONIO NAVARRETE
1.1 CONCEPTO DE INGENIERÍA DE SOFTWARE Y SISTEMA DE INFORMACIÓN
1.1.1 Mitos
Muchas de las causas de la crisis del software se pueden encontrar en una mitología que
surge durante los primeros años del desarrollo del software. A diferencia de los mitos
antiguos, que ofrecían a los hombres lecciones dignas de tener en cuenta, los mitos del
software propagaron información errónea y confusión. Los mitos del software tienen
varios atributos que los hacen insidiosos, por ejemplo, aparecieron como declaraciones
razonables de hechos; tuvieron un sentido intuitivo y frecuentemente fueron
promulgados por expertos que estaban al día.
Hoy, la mayoría de los profesionales competentes consideran a los mitos por lo que son
actitudes erróneas que han causado serios problemas, tanto a los gestores como a los
técnicos. Sin embargo, las viejas actitudes y hábitos son difíciles de modificar y cuando
vamos hacia la década del software, todavía se cree en algunos restos de los mitos del
software.
A) Mitos de gestión. Los gestores con responsabilidad sobre el software, como los
gestores en la mayoría de las disciplinas están normalmente bajo la presión de cumplir los
presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.
 Mito. Si fallamos en planificación, podemos añadir mas programadores y adelantar

el tiempo perdido.
 Realidad. El desarrollo del software no es un proceso mecánico como la

fabricación. Puede añadirse gente pero solo de manera planificada y bien
coordinada.
B) Mitos del cliente. Un cliente que solicita una ampliación del software puede ser una
persona del despacho de a lado, un grupo técnico de la sala de abajo, el departamento de
ventas o una compañía exterior que solicita un software bajo contrato. En muchos casos el
cliente cree en los mitos que existen sobre el software, debido a que los gestores y
trabajadores responsables hacen muy poco para corregir la mala información. Los mitos
conducen a que el cliente se cree una falsa expectativa y finalmente, queda insatisfecho
con el que desarrolla el software.
 Mito. Los requisitos del proyecto cambian continuamente, pero los cambios
pueden acomodarse fácilmente, ya que el software es flexible.
2
 Realidad. Es verdad que los requisitos del software cambian, pero el impacto del
cambio varia según el momento en que se introduzca.
C) Mitos de los desarrolladores. Los mitos en los que aún creen muchos desarrolladores
se han ido fomentando durante cuatro décadas de cultura informática. Durante los
primeros días de desarrollo de software, la programación se veía como un arte. Las viejas
formas u actitudes tardan en morir.
 Mito. Hasta que no tengo el programa "ejecutándose", realmente no tengo forma

de comprobar su calidad.
 Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos
más efectivos para garantizar la calidad del software- la revisión técnica formal.
1.1.2 Paradigmas
Un paradigma es un ejemplo o un modelo que utiliza la ingeniería para el desarrollo de un

software o proyecto.
Reconocer los problemas, causas y demoler los mitos del software son los primeros pasos
a solucionar. Pero las propias soluciones tienen que proporcionar asistencia práctica a la
persona que desarrolla un software, mejorar la calidad del software, por ultimo permitir al
mundo del software mantenerse en paz con le mundo del hardware.
No existe un único enfoque para solucionar el mal del software. Sin embargo, para
solucionar este problema se tendrán que utilizar:
 Combinación de métodos completos para todas las fases del desarrollo

del software.
 Mejores herramientas para automatizar estos métodos.
 Bloques de construcción más potentes para la implementación de
software.
 Técnicas para la garantía de calidad del software y Una filosofía
predominante para la coordinación, control y gestión para conseguir una
disciplina para el desarrollo del software.
Con esto se puede conseguir una disciplina para el desarrollo del software.
Tipos de paradigmas:
1. Modelo cascada
2. Modelo prototipo
3
3. Modelo incremental
4. Modelo espiral
5. Técnicas de 4a. generación
1.1.3 Ingeniería de Software
Definiciones:
 “La ISW es el establecimiento y uso de principios sólidos de ingeniería, orientados

a obtener software económico que sea fiable y trabaje de manera eficiente en
máquinas reales” (Fritz Bauer).
 “ISW: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para
el desarrollo, la operación y el mantenimiento del software; es decir, la aplicación
de la ingeniería al software; (2) El estudio de enfoques como en (1)” (Glosario
Estándar de Términos de Ingeniería del Software de IEEE, 1998).
 “Una disciplina que comprende todos los aspectos de la producción de software
desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento
de éste después de que se utiliza” (Sommerville 2002).
1.1.4 Calidad del Software
La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan

su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección,
confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa a otro.

Un software elaborado para el control de naves espaciales debe ser confiable al nivel de
"cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel
de calidad; mientras que un producto de software para ser explotado durante un largo
período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los
costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.
La calidad del software puede medirse después de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el
diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad
como su control durante todas las etapas del ciclo de vida del software.
¿COMO OBTENER UN SOFTWARE DE CALIDAD?
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
4
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.
La política establecida debe estar sustentada sobre tres principios básicos: tecnológico,
administrativo y ergonómico.
1. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo

del software.
2. El principio administrativo contempla las funciones de planificación y control del
desarrollo del software, así como la organización del ambiente o centro de
ingeniería de software.
3. El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad

del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su
control o evaluación.
¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?
Para controlar la calidad del software es necesario, ante todo, definir los parámetros,
indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no
puede controlar lo que no se puede medir".
Las cualidades para medir la calidad del software son definidas por innumerables autores,
los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define
métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones
de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios
de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro
niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel
inferior contiene los indicadores que conforman el nivel precedente. Otros autores
identifican la calidad con el nivel de complejidad del software y definen dos categorías de
métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles que
son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que
requiere los siguientes pasos:
 Definir el software que va a ser controlado: clasificación por tipo, esfera de

aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el
desarrollo del software.
5
 Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada
clase de software es necesario definir los indicadores y sus magnitudes.
 Crear o determinar los métodos de valoración de los indicadores: métodos
manuales como cuestionarios o encuestas estándares para la medición de criterios
periciales y herramientas automatizadas para medir los criterios de cálculo.
 Definir las regulaciones organizativas para realizar el control: quiénes participan
en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados
y elaborados, etc.
A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un

proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier
entidad que se dedique a la investigación, producción y comercialización del software, el
cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la
confección de una Metodología para el Aseguramiento de la Calidad del Software y el
desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las
técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de
Aseguramiento de la Calidad del Software.
1.2 IMPORTANCIA DE LA INGENIERÍA DE SOFTWARE
Actualmente casi todos los países dependen de sistemas complejos basados en

computadora. Más y más productos incorporan computadoras y Software en estos
sistemas representan una proposición grande y creciente del costo total del sistema. Por
lo tanto, producir software costeable es esencial para el funcionamiento de la economía
nacional e internacional.
La ingeniería de software es una disciplina de la ingeniería cuya meta es el desarrollo

costeable de sistemas de software. Este es abstracto e intangible. No está restringido por
materiales, o gobernado por leyes físicas o por procesos de manufactura. De alguna
forma, esto simplifica la ingeniería de software ya que no existen limitaciones físicas del
potencial del software. Sin embargo, esta falta de restricciones naturales significa que el
software puede llegar a ser extremadamente complejo y, por lo tanto, muy difícil de
entender.
La ingeniería de software es una disciplina relativamente joven. La noción de esta

ingeniería fue propuesta inicialmente en 1968, en una conferencia para discutir lo que en
ese entonces se llamó la “crisis del software”. Esta crisis fue el resultado de la introducción
de las poderosas (en ese momento) computadoras de tercera generación. Su poder hizo
que las aplicaciones hasta ese entonces irrealizables fueran una propuesta factible.
6
El software resultante fue de órdenes de magnitud más grande y más complejo que los
sistemas de software previos.
La experiencia previa en la construcción de estos sistemas mostró que un enfoque

informal para el desarrollo del software no era muy bueno. Los grandes proyectos a
menudo tenían años de retraso. Costaban mucho más de lo presupuestado, era
irrealizable, difíciles de mantener y con un desempeño pobre. El desarrollo de software
estaba en crisis. Los costos de hardware se temblaban mientras que los del software se
incrementaban con rapidez. Nuevas técnicas y métodos eran necesarios para controlar la
complejidad inerte en los sistemas de software grandes.
Estas técnicas han llegado a ser parte de la ingeniería de software y se utilizan

ampliamente, aunque no universalmente. Sin embargo, aun existen problemas en la
producción de software complejo, que cumpla con las expectativas del usuario, que se
libere a tiempo y que este dentro del presupuesto. Muchos proyectos de software aún
tienen problemas y esto ha conducido a que algunos autores (Presuman, 1997) sugieran
que la ingeniería de software se encuentra en un estado de enfermedad crónica.
Entre más crezca nuestra habilidad para producir software, también lo hará la complejidad
de los sistemas de software solicitados. Las nuevas tecnologías resultantes de la
convergencia de las computadoras y de los sistemas de comunicación impusieron nuevas
demandas a los ingenieros de software. Por esta razón, y debido a que muchas compañías
no aplican de forma efectiva las técnicas de la ingeniería de software, aún tenemos
problemas. Las cosas no están tan mal como los fatalistas sugieren. Sin embargo, existe
mucho por mejorar.
Hemos tenido un gran proceso desde 1968 y que el desarrollo de esta ingeniería ha
mejorado considerablemente nuestro software. Hemos desarrollado métodos efectivos
de especificación, diseño e implementación del software. Las nuevas notaciones y
herramientas reducen el esfuerzo requerido para producir sistemas grandes y complejos.
Los ingenieros de software pueden estar orgullosos de sus logros. Sin software complejo
no habríamos explorado el espacio, no tendríamos Internet y Telecomunicaciones
modernas, y todas las formas de viajar serian más peligrosas y caras. Dicha ingeniería ha
hecho enormes contribuciones en su corto periodo de vida.
1.2.1 Concepto de Ingeniería de Software.
Es una disciplina que comprende todos los aspectos de la producción de software desde
las etapas iniciales de la especificación del sistema, hasta el momento de éste, después de
que se utiliza.
7
En esta definición existen dos frases claves:
1.- “Disciplina de la Ingeniería” Los ingenieros hacen que las cosas funcionen. Aplican
teorías, métodos y herramientas donde sean convenientes, pero las utilizan de forma
selectiva y siempre tratando de describir soluciones a los problemas, aun cuando no
existan teorías y métodos aplicables para resolverlos.
Los ingenieros, también saben que deben trabajar con restricciones financieras Y
organizacionales, por lo que buscan soluciones tomando en cuenta estas restricciones.
2. “Todos los aspectos de producción de software” La ingeniería de software no sólo

comprende los procesos técnico del desarrollo de software, sino también, las actividades,
como la administración de proyectos de software y el desarrollo de herramientas,
métodos y teorías de apoyo a la producción del software.
En general, los ingenieros de software adoptan un enfoque sistemático y organizado en su

trabajo, ya que es la forma más efectiva de producir software de alta calidad. Sin
embargo, aunque la ingeniería consiste en seleccionar el método más apropiado para un
conjunto de circunstancias, un enfoque más informal y creativo de desarrollo podría ser
efectivo en algunas circunstancias. El desarrollo informal es apropiado para el desarrollo
de sistemas de comercio electrónico basado en Web que requieren una mezcla de
capacidades de software y de diseño gráfico.
1.2.2 Método, técnica y herramienta.
a) METODO
Un método de ingeniería del 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. Métodos como Análisis Estructurado (DeMarco, 1978) y JSD (Jack- son,
1983) fueron los primeros desarrolladores en los años 70. Estos métodos intentaron
identificar los componentes funcionales básicos de un sistema de tal forma que los
métodos orientados a funciones aún se utilizan ampliamente. En los años 80 y 90, estos
métodos orientados a funciones fueron complementados por métodos orientados a
objetos, como los propuestos por Booh (994) y Rumbaugh et al., 1991). Estos diferentes
enfoques se han integrado a un solo enfoque unificado basado en UML (Lenguaje de
Modelado Unificado).
Todos los métodos basados 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 de diseño. Los métodos
incluyen una variedad de componentes diferentes que son:
8
COMPONENTE DESCRIPCIÓN EJEMPLO
Descripciones del Descripción de los modelos del Sistema Modelos de objetos, de
modelo del sistema que se desarrollará y la notación flujo de datos, de maquinas
utilizada para definir los modelos. de estado, etc.
Reglas Restricciones que siempre aplican a los Cada entidad de un modelo
modelos de sistemas. de sistema debe tener
nombre único.
Recomendaciones Heurística que caracteriza una buena Ningún objeto debe tener
práctica de diseño en este método. más de 7 subobjetos
Seguir estas recomendaciones debe dar asociados a el.
como resultado un modelo del sistema
bien organizado.
Guías en el proceso Descripciones de las actividades que Loa atributos de los objetos
deben seguirse para desarrollar los deben documentarse antes
modelos del sistema y la organización de definir las operaciones
de estas actividades. asociadas a un objeto.
b) TÉCNICA
Técnicas de caja Negra de AQ maneja aplicaciones, o partes de ellas, que ya están

construidas. Estas técnicas verifican si el software cumplo o no con sus requerimientos.
Técnicas de caja blanca (o caja de vidrio) de QA se aplica a los componentes que forman la
unidad que se esta probando. Encender el televisor, cambiar los canales y luego observar
su calidad equivaldría a la técnica de la caja negra. Probar el aparato de manera que
funcione cada circuito es una técnica de caja blanca, por que involucra los componentes
que conforman el televisor. Los procesos AQ que no son uno de estos dos extremos
suelen llamarse técnicas de caja gris. Verificar la mayor parte de los componentes de su
televisor es una técnica de caja gris. En el sentido estricto, la diferencia entre las técnicas
de caja blanca y caja gris no siempre esta bien definida.
Aunque muchas veces se piensa en las cajas negras y blancas en el contexto de las
pruebas, estos conceptos se aplican a varias actividades de aseguramiento de la calidad.
Las técnicas de caja blanca requieren que el ingeniero piense en la estructura, forma y
propósito del artefacto que examina. Esto incluye usar métodos formales e inspección.
9
INTERVENCIÓN DE QA
c) HERRAMIENTA
La ingeniería e software es un mercado sustancial. Un gran número de proveedores

venden herramientas y entornos para ayudar a los ingenieros a desarrollar aplicaciones de
software. Estas con frecuencia recibe el nombre de herramienta de ingeniería de software
asistida por computadora (CASE, Computer- arded Software Engineering). En ocasiones,
quienes respaldan las herramientas CASE prometen mucho y entregan menos.
A continuación se muestra un cuadro enumerando los componentes posibles de una

herramienta CASE.
Los grandes proyectos, sencillamente se pueden manejar sin al menos una de estas
componentes CASE. Por ejemplo en un proyecto grande, las herramientas de
administración de configuración son indispensables.
10
Componentes potenciales de las herramientas CASE (Graficas reproducidas con permiso

de Corel).
1.2.3 Herramientas CASE
La definición de (CASE): Conjunto de herramientas y métodos asociados que proporcionan

asistencia automatizada en el proceso de desarrollo del software a lo largo de su ciclo de
vida.
• Gestión del proyecto (Planificación, estimación y control )

• Desarrollo del software (Análisis, diseño , implementación , validación )
• Mantenimiento del software.
11
Figura. Componentes de herramientas CASE
CLASIFICACIÓN DE LAS HERRAMIENTAS CASE
Se suele suponer que para crear un entorno CASE efectivo, debe incluir todas las
categorías de herramientas, pero esto es sencillamente falso. Se puede dar lugar a
confusión (o antagonismos) al situar una herramienta determinada dentro de una
categoría cuando otros podrían pensar que se ha omitido una categoría, eliminando, d
esta forma, un conjunto completo de herramientas de entornos CASE.
Además la categorización simple tiende hacer llena, esto es, no aparece una interacción
jerárquica de las herramientas o de las relaciones entre ellas. Pero aun asumiendo todos
estos riesgos, es necesario crear una taxónoma para comprender mejor el alcance del
CASE y para apreciar mejor donde se pueden aplicar estas herramientas en el proceso de
ingeniería del software.
Las herramientas CASE se pueden clasificar por su función, por su papel como
instrumentos para el personal técnico a los directivos, por la arquitectura del entorno
(Hardware y Software) que los soportan e incluso por su origen y coste.
12
Figura. Taxonomía de herramientas CASE
1.3 HISTORIA DE LA INGENIERÍA DEL SOFTWARE

Definiciones:
 “La ISW es el establecimiento y uso de principios sólidos de ingeniería, orientados

a obtener software económico que sea fiable y trabaje de manera eficiente en
máquinas reales” (Fritz Bauer).
 “ISW: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para

el desarrollo, la operación y el mantenimiento del software; es decir, la aplicación
de la ingeniería al software; (2) El estudio de enfoques como en (1)” (Glosario
Estándar de Términos de Ingeniería del Software de IEEE, 1998).
13
 “Una disciplina que comprende todos los aspectos de la producción de software
desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento
de éste después de que se utiliza” (Sommerville 2002).
El software es quizá uno de los productos de la ingeniería que más ha evolucionado en

muy poco tiempo, pasando del software empírico o artesanal hasta llegar al software
desarrollado bajo los principios y herramientas de la ingeniería del software.
Sin embargo, dentro de estos cambios, las personas encargadas de la elaboración del
software se han enfrentado a problemas muy comunes: unos debido a la exigencia cada
vez mayor en la capacidad de resultados del software, debido al permanente cambio de
condiciones lo que aumenta su complejidad y obsolescencia; y otros, debido a la carencia
de herramientas adecuadas y estándares de tipo organizacional encaminados al
mejoramiento de los procesos en el desarrollo del software.
Una necesidad sentida en nuestro medio es el hecho de que los productos de software
deben ser desarrollados con base en la implantación de estándares mundiales, modelos ,
sistemas métricos, capacitación del recurso humano y otros principios y técnicas de la
ingeniería software que garanticen la producción de software de calidad y competitividad
a nivel local e internacional.
ANTECEDENTES: GÉNESIS Y EVOLUCIÓN.
Con el acelerado avance tecnológico de la información, la cantidad y la complejidad de los

productos de software se están incrementando considerablemente, así como también la
exigencia en su funcionalidad y confiabilidad; es por esto que la calidad y la productividad
se están constituyendo en las grandes preocupaciones tanto de gestores como para
desarrolladores de software.
En los primeros años del software, las actividades de elaboración de programas eran
realizadas por una sola persona utilizando lenguajes de bajo nivel y ajustándose a un
computador en especial, que generaban programas difíciles de entender, aun hasta para
su creador, después de algún tiempo de haberlo producido. Esto implicaba tener que
repetir el mismo proceso para desarrollar el mismo programa para otras máquinas. Por
consiguiente, la confiabilidad, facilidad de mantenimiento y cumplimiento no se
garantizaban y la productividad era muy baja.
Posteriormente, con la aparición de técnicas estructuradas y con base en las experiencias

de los programadores se mejoró la productividad del software. Sin embargo, este
software seguía teniendo fallas, como por ejemplo: documentación inadecuada, dificultad
para su correcto funcionamiento, y por supuesto, insatisfacción de cliente.
14
Conforme se incrementaba la tecnología de los computadores, también crecía la demanda
de los productos de software, pero mucho más lentamente, tanto que hacia 1990 se decía
que las posibilidades de software estaban retrasadas respecto a las del hardware en un
mínimo de dos generaciones de procesadores y que la distancia continuaba aumentando.
En la actualidad muchos de estos problemas subsisten en el desarrollo de software, con

una dificultad adicional relacionada con la incapacidad para satisfacer totalmente la gran
demanda y exigencias por parte de los clientes.
Problemas del Software
Durante décadas se ha hablado de una crisis del software. Sin embargo, por crisis
entendemos normalmente un estado pasajero de inestabilidad, que tiene como resultado
un cambio de estado del sistema o una vuelta al estado inicial, en caso de que se tomen
las medidas para superarla. Teniendo en cuenta esto, el software, más que padecer una
crisis podríamos decir que padece una enfermedad crónica. Los problemas que surgieron
cuando se empezó a desarrollar software de una cierta complejidad siguen existiendo
actualmente, sin que se haya avanzado mucho en los intentos de solucionarlos.
Estos problemas son causados por las propias características del software y por los errores
cometidos por quienes intervienen en su producción. Entre ellos podemos citar:
a) La planificación y la estimación de costes son muy imprecisas.
A la hora de abordar un proyecto de una cierta complejidad, sea en el ámbito que sea, es
frecuente que surjan imprevistos que no estaban recogidos en la planificación inicial, y
como consecuencia de estos imprevistos se producirá una desviación en los costes del
proyecto. Sin embargo, en el desarrollo de software lo más frecuente es que la
planificación sea prácticamente inexistente, y que nunca se revise durante el desarrollo
del proyecto. Sin una planificación detallada es totalmente imposible hacer una
estimación de costes que tenga alguna posibilidad de cumplirse, y tampoco se pueden
identificar las tareas conflictivas que pueden desviarnos de los costes previstos.
Entre las causas de este problema podemos citar:
• No se recogen datos sobre el desarrollo de proyectos anteriores, con lo que no se

acumula experiencia que pueda ser utilizada en la planificación de nuevos proyectos.
• Los gestores de los proyectos no están especializados en la producción de

software. Tradicionalmente, los responsables del desarrollo del software han sido
ejecutivos de nivel medio y alto sin conocimientos de informática, siguiendo el
principio de ‘Un buen gestor puede gestionar cualquier proyecto’. Esto es cierto, pero
no cabe duda de que también es necesario conocer las características específicas del
software, aprender las técnicas que se aplican en su desarrollo y conocer una
tecnología que evoluciona continuamente.
15
b) La productividad es baja.
Los proyectos software tienen, por lo general, una duración mucho mayor a la esperada.
Como consecuencia de esto los costes se disparan y la productividad y los beneficios
disminuyen. Uno de los factores que influyen en esto, es la falta de unos propósitos claros
o realistas a la hora de comenzar el proyecto. La mayoría del software se desarrolla a
partir de unas especificaciones ambiguas o incorrectas, y no existe apenas comunicación
con el cliente hasta la entrega del producto. Debido a esto son muy frecuentes las
modificaciones de las especificaciones sobre la marcha o los cambios de última hora,
después de la entrega al cliente. No se realiza un estudio detallado del impacto de estos
cambios y la complejidad interna de las aplicaciones crece hasta que se hacen
virtualmente imposibles de mantener y cada nueva modificación, por pequeña que sea, es
más costosa, y puede provocar el fallo de todo el sistema.
Debido a la falta de documentación sobre cómo se ha desarrollado el producto o a que las

sucesivas modificaciones - también indocumentadas - han desvirtuado totalmente el
diseño inicial, el mantenimiento de software puede llegar a ser una tarea imposible de
realizar, pudiendo llevar más tiempo el realizar una modificación sobre el programa ya
escrito que analizarlo y desarrollarlo entero de nuevo.
c) La calidad es mala.
Como consecuencia de que las especificaciones son ambiguas o incluso incorrectas, y de

que no se realizan pruebas exhaustivas, el software contiene numerosos errores cuando
se entrega al cliente. Estos errores producen un fuerte incremento de costes durante el
mantenimiento del producto, cuando ya se esperaba que el proyecto estuviese acabado.
Sólo recientemente se ha empezado a tener en cuenta la importancia de la prueba
sistemática y completa, y han empezado a surgir conceptos como la fiabilidad y la garantía
de calidad.
d) El cliente queda insatisfecho.
Debido al poco tiempo e interés que se dedican al análisis de requisitos y a la

especificación del proyecto, a la falta de comunicación durante el desarrollo y a la
existencia de numerosos errores en el producto que se entrega, los clientes suelen quedar
muy poco satisfechos de los resultados. Consecuencia de esto es que las aplicaciones
tengan que ser diseñadas y desarrolladas de nuevo, que nunca lleguen a utilizarse o que
se produzca con frecuencia un cambio de proveedor a la hora de abordar un nuevo
proyecto.
16
1.4 LOS SISTEMAS DE INFORMACIÓN: CONCEPTO, CARACTERÍSTICAS,

ESTRUCTURAS, PROCESOS, CLASIFICACIÓN, ERP´S, CRM, SCM.
Como sistema se define a un conjunto de elementos interrelacionados con un fin común.

La parte más importante de un sistema es la información y las relaciones entre cada uno
de sus elementos. La información es un conjunto de datos organizados coherente y
congruentemente; la información que no cumple con estos elementos se convierte en
ruido. Todo sistema requiere información y ésta va a servir para ser procesada y evaluada
para tomar una o más decisiones sobre el sistema.
El término Sistema de Información tiene dos definiciones importantes:
a) Es una disposición de componentes integrados entre sí cuyo objetivo es

satisfacer las necesidades de información en una organización.
b) Es una disposición de personas, actividades, datos, redes y tecnología

integrados entre sí con el propósito de apoyar y mejorar las operaciones y la
toma de decisiones.
Una definición básica de sistema es la siguiente: Grupo de elementos interdependientes o

que interactúan regularmente formando un todo, a continuación se enumeran diversos
ejemplos.
Un sistema gravitacional, un sistema termodinámico, un sistema de ríos, un sistema

telefónico, un sistema de autopistas, el sistema newtoniano de la mecánica, el sistema de
mecanografía al tacto, un sistema taxonómico, el sistema decimal, etcétera.
1.4.1 Elementos de los Sistemas de Información
a) El recurso computacional.
Equipo de soporte: son todas las herramientas que se utilizan para desarrollar y
darle mantenimiento al sistema.
b) El recurso humano.
Personas: son las encargadas de introducir la información al sistema, por lo que

de ellas depende que la información sea adecuada. Dentro de las personas se
incluye a los analistas del sistema y programadores y a los usuarios del sistema.
17
Los usuarios.- Los trabajadores de la información son aquellos que se ganan la

vida al crear, utilizar, procesar, administrar o intercambiar información, reciben el
nombre de trabajadores de cuello blanco para distinguirlos de los llamados
trabajadores de cuello azul que prestan sus servicios en la industria y el campo. El
nombre más común para este tipo de trabajadores de la información es usuario.
Los usuarios son aquellos empleados que interactúan con el sistema como pueden ser los
gerentes y empleados de una organización. El tipo de usuarios depende del grado de
participación que tengan en el sistema.
Los usuarios se clasifican en cuatro categorías:
A. Usuarios primarios: son los que interactúan con el sistema. Ellos alimentan al
sistema con los datos de entrada o reciben salidas por algún medio de salida.
B. Usuarios indirectos: son aquellos que se benefician de los resultados o reportes
generados por los sistemas pero que no interactúan de manera directa con el
hardware o software.
C. Usuarios gerente: son los usuarios que tienen responsabilidades administrativas
dentro de los sistemas de aplicación. Esto usuarios son los que utilizan el sistema
con mayor frecuencia. Si este usuario no utiliza de forma directa o indirecta el
sistema, no tendrán la autoridad para aprobar la creación de un sistema de
información, además de no contar con la responsabilidad ante la organización de la
efectividad de los sistemas, debido a que estos usuarios deben de participar en el
desarrollo de sistema.
D. Usuarios directivos: estos usuarios toman ciertas responsabilidades en el
desarrollo de los sistemas de información. El que este tipo de usuario tome
decisiones sobre la existencia o no de un sistema de información en la organización
es una función de riesgos, ya que en ocasiones los sitemas de información
desarrollados en una forma inadecuada pueden entorpecer e incluso dañar a las
actividades de la organización.
Cabe hacer la consideración de que no todos los usuarios finales tienen la misma
experiencia, algunos nunca han usado una computadora, mientras otros interactúan
cotidianamente con un sistema a de información. Cada grupo debe ser capaz de utilizar el
sistema con facilidad y de manera oportuna cuando sea necesario, aunque su empleo no
forme parte de la rutina cotidiana. Por lo que las características que deberá tener un
sistema de información deberán contemplar la satisfacción de las necesidades de los
usuarios ocasionales. Los cuatro tipos de usuarios son importantes; cada uno de ellos
paseé información esencial sobre las funciones de la organización y hacia dónde se dirige
ésta. Los analistas proporcionan las ideas con respecto a las mejores formas de usar
eficientemente las computadoras.
18
c) Datos ó Información
Para este concepto la Información está estrechamente relacionado con el analista de

sistemas ya que debe adaptar la información para ser entregada, por lo que debe saber a
quién se le va a entregar y de qué forma la requiere.
La información en las organizaciones tiene dos tipos de flujo:
1. Horizontal: es la información que se da al mismo nivel y es directa.
2. Vertical: esta información se puede dar de dos formas:
a) Ascendente: esta información se da de abajo hacia arriba en cuanto

al organigrama se refiere y puede presentarse en forma de reporte
o solicitud.
b) Descendente: son órdenes o peticiones de acciones a realizar.
d) Los programas
Dentro de este aspecto el analista deben considerar si el software a utilizar será comprado
a terceros o bien diseñar software de acuerdo a las necesidades del sistema. La elección
en cada caso dependerá del costo de cada una de las alternativas, el tiempo disponible
para el desarrollo y de la disponibilidad de programadores (acción que puede ejercer el
analista como analista programador).
En caso de seleccionar el desarrollo del software se tendrán que realizar todas y cada una
de la técnicas que para el desarrollo de software se conocen y sean adecuadas
dependiendo de la pericia del programador. Y de ahí se debe de seleccionar el lenguaje de
programación.
Por ello el analista junto con el grupo de trabajo deberá elegir y aplicar el lenguaje de
programación más adecuado para la realización del software para desarrollar el sistema.
La elección del software dependerá en gran parte del conocimiento y experiencia del
analista al usar determinados lenguajes; otro tipo de elemento que determinará la
aplicación de un lenguaje será el tipo de sistema a realizar, ya que dependiendo de lo que
se desee en cuestión del sistema, se seleccionará el lenguaje que facilite su creación.
e) La documentación
Un sistema debe contemplar una documentación adecuada y completa para mantenerlo y

actualizarlo de manera satisfactoria; sin embargo muchos analistas hacen caso omiso de
este aspecto.
19
Al documentar un sistema se debe buscar cubrir los siguientes objetivos:
 Estandarizar la documentación.
 Facilitar el desarrollo de la misma.
 Ahorrar tiempo.
Una vez contemplados los puntos anteriores, es necesario aplicar estas ventajas para
realizar la documentación del sistema, debido a que si se logra una documentación
eficiente del sistema se tendrán las siguientes ventajas:
1. Será una herramienta didáctica para nuevos miembros de la organización y por lo

tanto nuevos usuarios.
2. Es requisito básico para quien tenga la responsabilidad del mantenimiento del
sistema o modificación del mismo.
3. Ayuda a los analistas a trabajar en áreas relativas, evitando redundancias y
facilitando la integración de todos los sistemas. o Asegura que el sistema opere
correctamente con el mínimo de errores.
4. Los recursos se usan de forma más eficiente.
SISTEMAS ERP, CRM Y SCM:
1) Sistemas ERP. Entreprise Resource Planning - Planificación de Recursos

Empresariales.
Es un sistema de información integral que incorpora los procesos operativos y de negocio

de una empresa, por ejemplo: producción, ventas, compras, logística, contabilidad (de
varios tipos), gestión de proyectos, inventarios y control de almacenes, pedidos, nóminas,
etc.
Características principales:
a) Integrales: Porque permiten controlar los diferentes procesos de la compañía

entendiendo que todos los departamentos de una empresa se relacionan entre sí.
b) Modulares: Es un conjunto de departamentos que se encuentran interrelacionados
por la información que comparten y que se genera a partir de sus procesos.
c) Adaptables: Los ERP están creados para adaptarse a la idiosincrasia de cada
empresa. Esto se logra por medio de la configuración o parametrización de los
procesos de acuerdo con las salidas que se necesiten de cada uno.
Ventajas:
20
A. La funcionalidad se encuentra dividida en módulos, los cuales
pueden instalarse de acuerdo con los requerimientos del cliente.
Ejemplo: Ventas, Materiales, Finanzas, Control de Almacén, etc.
B. Optimización de procesos empresariales.
C. Acceso a información de forma confiable, verás y a tiempo.
D. La posibilidad de compartir información con las demás área de la
organización buscando integridad y buen desarrollo de los procesos.
E. Eliminación procesos incensarios dentro de la compañía.
Desventajas:
A. Aunque el ERP pueda tener menús modulares configurables según

los roles de cada usuario, es un todo. Esto significa: es un único
programa.
B. los datos se ingresan sólo una vez y deben ser consistentes,
completos y comunes.
2) Sistemas CRM. Customer Relationship Management - Gestión de Relaciones

Personales
Significa de manera literal, la administración de la relación comercial con los clientes de

una empresa.
Características principales. Permite almacenar información de todos y cada uno de los

contactos con nuestros Clientes y con su entorno. . Es un gran repositorio que nos
abastece con los detalles de nuestros clientes, así como también con consejos o pautas
sobre futuros contactos con los mismos.
Ventajas:
A. Recopilar la mayor cantidad de información posible sobre los

clientes, para poder dar valor a la oferta y distanciarse de sus
competidores.
B. Permiten mantener todas las herramientas comerciales a
disposición del operador.
Desventajas
A. El alto costo de estos productos comerciales, licencias adicionales

como un sistema operativo y más aún el alto costo de la su
implantación y puesta en marcha, afortunadamente existen también
diversos proyectos de sistemas CRM con licencia.
B. No siempre están relacionados con el tele marketing.
21
3) Sistemas SCM. Supply Chain Management- Gestión de la Cadena de Suministro.
Son los procesos empresariales en torno a la logística y servicio al cliente: compras,

aprovisionamiento, producción, almacenamiento, preparación, distribución y postventa.
Características principales. Contribuye a la coordinación y optimización de procesos

empresariales y transacciones comerciales tanto en el seno de una misma compañía como
entre distintas empresas.
Ventajas:
A- Al tener una visión más amplia del funcionamiento de su negocio,

podrá mejorar la asignación de recursos y mejorar el servicio al
cliente.
B.- La globalización de mercados y producción y la evolución

tecnológica.
Desventajas:
A.- Dura la competencia. Esto ha generado un ciclo de vida cada vez

más corto para los productos.
B.- Costos podrían ser elevadísimos si un producto fuera realizado en

un solo lugar y todos los insumos tuvieran que traerse y por otro
lado, se contara sólo con la mano de obra local.
Indicaciones de la Unidad 1:
 Elaborar cuestionario individual de 10 preguntas y enviar

al profesor el último día de clases de la unidad (utilizar
formato de investigaciones y tareas).
 Realizar una presentación en Power-Point de la unidad
(se evaluara diseño y contenido de la misma)
22

Ingeniería de Software: Introducción, Mitos, Paradigmas y Calidad

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Software: Introducción, Mitos, Paradigmas y Calidad

Cargado por

Copyright:

Formatos disponibles

INGENIERIA DE SOFTWARE

DEPARTAMENTO DE SISTEMAS Y COMPUTACION

INGENIERIA EN TECNOLOGIAS DE INFORMACION Y

INTRODUCCION A LA INGENIERIA DE SOFTWARE

1.1 CONCEPTO DE INGENIERÍA DE SOFTWARE Y SISTEMA DE INFORMACIÓN

 Mito. Si fallamos en planificación, podemos añadir mas programadores y adelantar

 Realidad. El desarrollo del software no es un proceso mecánico como la

 Mito. Hasta que no tengo el programa "ejecutándose", realmente no tengo forma

Un paradigma es un ejemplo o un modelo que utiliza la ingeniería para el desarrollo de un

 Combinación de métodos completos para todas las fases del desarrollo

1.1.3 Ingeniería de Software

 “La ISW es el establecimiento y uso de principios sólidos de ingeniería, orientados

1.1.4 Calidad del Software

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan

La calidad del software es medible y varía de un sistema a otro o de un programa a otro.

¿COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtención de un software con calidad implica la utilización de metodologías o

1. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo

La adopción de una buena política contribuye en gran medida a lograr la calidad

¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?

 Definir el software que va a ser controlado: clasificación por tipo, esfera de

A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un

1.2 IMPORTANCIA DE LA INGENIERÍA DE SOFTWARE

Actualmente casi todos los países dependen de sistemas complejos basados en

La ingeniería de software es una disciplina de la ingeniería cuya meta es el desarrollo

La ingeniería de software es una disciplina relativamente joven. La noción de esta

La experiencia previa en la construcción de estos sistemas mostró que un enfoque

Estas técnicas han llegado a ser parte de la ingeniería de software y se utilizan

1.2.1 Concepto de Ingeniería de Software.

En esta definición existen dos frases claves:

2. “Todos los aspectos de producción de software” La ingeniería de software no sólo

En general, los ingenieros de software adoptan un enfoque sistemático y organizado en su

1.2.2 Método, técnica y herramienta.

Un método de ingeniería del software es un enfoque estructurado para el desarrollo de

Todos los métodos basados en la idea de modelos gráficos de desarrollo de un sistema y

Técnicas de caja Negra de AQ maneja aplicaciones, o partes de ellas, que ya están

La ingeniería e software es un mercado sustancial. Un gran número de proveedores

A continuación se muestra un cuadro enumerando los componentes posibles de una

Componentes potenciales de las herramientas CASE (Graficas reproducidas con permiso

1.2.3 Herramientas CASE

La definición de (CASE): Conjunto de herramientas y métodos asociados que proporcionan

• Gestión del proyecto (Planificación, estimación y control )

Figura. Componentes de herramientas CASE

CLASIFICACIÓN DE LAS HERRAMIENTAS CASE

Figura. Taxonomía de herramientas CASE

1.3 HISTORIA DE LA INGENIERÍA DEL SOFTWARE

 “La ISW es el establecimiento y uso de principios sólidos de ingeniería, orientados

 “ISW: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para

El software es quizá uno de los productos de la ingeniería que más ha evolucionado en

ANTECEDENTES: GÉNESIS Y EVOLUCIÓN.

Con el acelerado avance tecnológico de la información, la cantidad y la complejidad de los

Posteriormente, con la aparición de técnicas estructuradas y con base en las experiencias

En la actualidad muchos de estos problemas subsisten en el desarrollo de software, con

Problemas del Software

a) La planificación y la estimación de costes son muy imprecisas.

Entre las causas de este problema podemos citar:

• No se recogen datos sobre el desarrollo de proyectos anteriores, con lo que no se

• Los gestores de los proyectos no están especializados en la producción de

Debido a la falta de documentación sobre cómo se ha desarrollado el producto o a que las

Como consecuencia de que las especificaciones son ambiguas o incluso incorrectas, y de

d) El cliente queda insatisfecho.

Debido al poco tiempo e interés que se dedican al análisis de requisitos y a la