instituto de educación superior “san ignacio de ...€¦ · o el soporte a seguimiento de...

Instituto de Educación Superior“San Ignacio de Monterrico”

SOFTWARE COMO PRODUCTO

EL PRODUCTO SOFTWARE.

Temas a tratar

• Definiremos el producto final de la ingeniería del software: EL

SOFTWARE.

• Importancia que tiene en la sociedad.

• Complejidad del desarrollo del mismo.

• Áreas en las que se aplica.

• Áreas temáticas de la informática.

El Software como una Obra Humana.

• Algunos autores comparan el software a la escritura de libros.

o Fruto del intelecto,

o Descripción de realidades y ficciones.

• Cuando el software es grande es como una novela de varios tomos.

Definición de software.

• Para nosotros será el conjunto de información:

o capaz de producir en las maquinas el comportamiento deseado,

de forma eficaz y eficiente,

o que los usuarios puedan utilizar el sistema de forma eficiente.

o Al que los desarrolladores puedan dar mantenimiento de forma

eficaz y eficiente.

La importancia del Software.

• Nuestra sociedad depende en gran medida de la informática.

Formando Emprendedores De Calidad Para Un Mundo Empresarial 1


o Parece impensable que los sistemas informáticos dejasen de

trabajar, ya que son soporte de muchos sistemas.

o Ejemplos de sistemas básicos son:

el sistema para el control de semáforos de la ciudad,

medios de transporte aéreo, los bancos,

los sistemas de producción (fabricas), hospitales, etc.

Desde la perspectiva histórica, ...

• Todo esto a pesar de que la informática es una ciencia muy joven (50

años)

o Los primeros años se centraron en la construcción de maquinas

capaces de dar soporte a estos sistemas.

o En la actualidad la el Software ha superado a la del Hardware

como clave del éxito de muchos sistemas informáticos.

Además aun queda mucho por hacer.

• Empresas, de todo tipo, plantean nuevos problemas a ser resueltos.

o Problemas inabordables hace unos años por el coste de los

ordenadores,

o Por otra parte la ciencia sigue evolucionando, con lo que

problemas mas sofisticados pueden ser abordados con las

técnicas de la Inteligencia Artificial, comunicaciones, multimedia,

etc.

¿Porque es difícil desarrollar Software?

• Es complicado explicar los motivos que hacen tan difícil desarrollar

Software.

• Lo cierto es que muchos proyectos de desarrollo de software fracasan.

• Centraremos el tema mediante:



o Una estadística realizada sobre 8 proyectos de Software

Estadounidenses.

o Características del Software.

o Aplicaciones del Software.

Estadística realizada sobre 8 proyectos de Software Estadounidenses

Características del Software

• Es inmaterial e invisible.

• El comprador lo puede evaluar cuando ya ha sido construido.

• El Software se desarrolla, no se fabrica.

• Es complejo. Los sistemas actuales están formados por miles de

funciones con interfaces complejas entre ellas.

• Es excesivamente maleable.

El Software se desarrolla, no se fabrica


Área: Sistemas de Defensa en Tiempo Real

0 0.5 1 1.5 2 2.5 3 3.5Millones de dolares

Pagado pero no entregado

Entregado pero no utilizado

abandonado o rechazado

Utilizado después de cambios

Utilizado como se entrego


• En cualquier sistema de producción podemos observar dos fases la de

desarrollo y la de fabricación.

o El desarrollo es lento y costoso.

o La fabricación en serie y con costes estables.

• Con el Software ocurre lo mismo pero...

o Muchas aplicaciones se desarrollan a medida, sin usar

componentes existentes.

o La fabricación no se considera tal.

El software es excesivamente maleable

• Todo el mundo exige que se realicen cambios sobre el Software como

respuesta a pequeños cambios del entorno.

• Además no es fácil comprender su comportamiento, según Pressman:

o La curva de fallos del Hardware.

o La curva ideal de fallos del Software.

o La curva real de fallos del Software.

Curva de fallos del Hardware



Curva ideal de fallos del Software

Curva real de fallos del Software



Clasificaciones del software desde diversos puntos de vista:

• La utilización que se hace de el.

• El tratamiento comercial que tiene.

• En relación con la funcionalidad que aporta a la maquina.

• Exigencia en eficiencia y los factores críticos que se le exigen.

Según la utilización del software:

• De Gestión.

• Producción y control de procesos.

• Robótica.

• De ingeniería y Científico.

• Ofimático.

• Dde Formación y divulgación.

• Domótico.

• Ocio y Juegos.

De Gestión

Se trata del software que da soporte a los procesos comerciales y manejo de

información que tienen por objetivo permitir a las gestiones una mejor gestión.

Producción y control de procesos

Es el software que da soporte a los procesos productivos y conducentes a

desarrollar las actividades propias de cada negocio.



Robótica

Software que se centra en controlar y automatizar el comportamiento de

engendros mecánicos que colaboran con los seres humanos en diversos

campos, desde la ortopedia hasta la exploración de otros planetas.

De ingeniería y Científico

Da soporte a los procesos creativos y de diseño de las personas, se caracteriza

por cálculos matemáticos complejos. Ejemplo de ello son las herramientas CAD

o el soporte a seguimiento de acontecimientos en el espacio (Telescopios, etc.)

Ofimático

Software que permite a las personas utilizar los ordenadores en las tareas que

habitualmente se realizan en oficinas.

De Formación y divulgación

Software que tiene por objetivo el transferir conocimientos al ser humano, en

esta categoría entran toda la creación de cursos, simuladores, etc.

Domótico

Software que se utiliza para controlar el hábitat del ser humano, a pequeña

escala. Va desde las alarmas hasta el control de temperaturas de un hogar.

Ocio y Juegos

En esta categoría entran un gran conjunto de aplicaciones que tienen por

objetivo el que el ser humano pase algo de tiempo disfrutando con los

ordenadores. Están muy difundidos los videojuegos, pero también deberíamos

incluir los foros y conferencias que se puedan plantear en Internet, etc.

Según el tratamiento comercial que tiene

• Software de estantería: COTS (Commercial off the shelf),



• Paquetes parametrizables,

• Software a medida,

• Software personal.

En relación con la funcionalidad que aporta a la maquina:

• Software de sistemas,

• Comunicaciones,

• Empotrado,

• De usuario.

Software empotrado

Exigencia en eficiencia y los factores críticos que se le exigen

• Software de tiempo real,

• Transaccional,

• Monousuario y PC.

El software visto desde el punto de vista de los constructores

• Paradigmas o formas de razonar:



o Teoría

o Abstracción

o Diseño

• El Contexto Social

• Las áreas temáticas del desarrollo del software

Teoría

• Pensamiento matemático.

o Definiciones formales,

o axiomas,

o teoremas,

o demostraciones

• Organizar las ideas, pensamientos y formas de realizar el trabajo.

Abstracción

• Dadas diversas realidades, se analizan y se extrae el conocimiento

o Se aventuran hipótesis,

o Se construyen modelos,

o Se realizan predicciones,

o Se llevan a cabo experimentos,

o Se obtienen resultados,

o Se demuestra que la hipótesis era correcta.

Diseño

• Es la forma de trabajar en la ingeniería.

o Se obtienen los requisitos,

o Se obtienen las especificaciones,



o se prepara e implementa el diseño,

o se prueba y evalúa el diseño realizado.

El contexto social

• La sociedad reclama unas pautas de comportamiento para los

informáticos, los productos que crean y el uso que se hace de la

información que manejan.

• Consideraciones:

o Éticas

o Legales

Nueve Áreas Temáticas de la Informática

Tucker, A et all. : “Fundamentos de Informática”. McGraw Hill 1994

Resumen



• Hemos visto como el software es básico en nuestra sociedad y su

funcionamiento.

• Es complicado desarrollar software.

• Por software se entienden muchos productos distintos.

• La propia perspectiva del desarrollador del software habla de áreas muy

diversas.



PROCESO DE LA INGENIERÍA DE SOFTWARE

Objetivos

• Reconocer el marco de trabajo de la ingeniería de software.

• Conocer el papel que cumple el análisis dentro de la ingeniería de

software.

• Reconocer a RUP como uno de los mejores procesos de ingeniería de

software.

INGENIERÍA DE SOFTWARE

¿Qué es Ingeniería?

Conjunto de conocimientos y técnicas científicas.

¿Qué es Software?

Elemento lógico del sistema.

¿Qué es Ingeniería de Software?

Es una disciplina o área de la informática o ciencia de la computación, que

ofrece conocimientos, técnicas y métodos para desarrollar y mantener software

de calidad que resuelva problemas de todo tipo.

¿Qué es Software de Calidad?

Software concordante con:

• Los requisitos funcionales del cliente.

• Los estándares de desarrollo reconocidos en la industria de software

mundial.



Ingeniería de Software como Tecnología Multicapa

• Cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de

organización de calidad.

• El fundamento de la ingeniería del software es la capa de proceso.

• Los métodos de la ingeniería del software indican cómo construir

técnicamente el 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.

PROCESO DE SOFTWARE

¿Qué es un Proceso de Software?

Conjunto de etapas con la intención de lograr un objetivo: OBTENER UN

SOFTWARE DE CALIDAD.

Otra denominación del Proceso de Software

Al proceso de software también se le conoce como : “Ciclo de Vida del

Software”



Fases Genéricas

• La Fase de Definición ¿Qué?

• La Fase de Desarrollo ¿Cómo?

• La Fase de Mantenimiento – Cambio

MODELO DE PROCESO DE SOFTWARE

¿Qué es un Modelo de Proceso de Software?

Es una estrategia de desarrollo que los ingenieros de software deben emplear

para resolver problemas de la industria de software.

Básicamente, el problema es seleccionar el modelo de proceso de software

apropiado para la ingeniería de software que debe aplicar el equipo de

proyecto.

Modelos de Procesos de Software

• Lineal Secuencial

• DRA

• Desarrollo Concurrente

• Ensamblaje de Componentes

• Construcción de Prototipos

• Incremental

• Espiral



El RATIONAL UNIFIED PROCESS (RUP)

Proceso OO

Requerimientos de Usuarios Software

Fases de RUP

Inicio

Define el alcance y objetivos del proyecto.

Elaboración

Plan del proyecto, Especificación de características y Arquitectura base.

Construcción

Construye y opera el producto.

Transición

Transición del producto a la comunidad del usuario.


Inicio Elaboración Construcción Transición<-------------------------------------Tiempo------------------------------------->

MetasPrincipales

Inicio Elaboración Construcción Transición<-------------------------------------Tiempo------------------------------------->

MetasPrincipales


Definición de RUP

• Es un proceso de ingeniería de software orientado a objetos.

• Consiste en un conjunto de actividades necesarias para transformar los

requerimientos del usuario en el sistema de software.

• Está especializado para diversos tipos de software de sistemas,

diversas áreas de aplicación, diferentes tipos de organizaciones y

diferentes tamaños de proyectos.

• Captura varias de las mejores prácticas en el desarrollo moderno de

software que es aplicable para un amplio rango de proyectos y

organizaciones.

• RUP es una guía de cómo usar UML de la forma más efectiva.

----------o----------



GESTIÓN DEL PROYECTO DE SOFTWARE

PANORAMA GENERAL

Construcción de una casa para “Boby”

Construcción de una casa

Construcción de un rascacielos


Puede hacerlo una sola persona.

Requiere:

Modelado mínimo

Proceso simple

Herramientas simples

Construida eficientemente y en un

tiempo razonable por un

equipo

Requiere:

Modelado

Proceso bien definido

Herramientas más sofisticadas

No cualquier persona o grupo de

persona lo realiza.

Imposible sin técnicas de

Ingeniería.


GENERALIDADES TÉCNICAS

• La Ingeniería de Software (ISw) es un término difícil de definir de cual

hay muchas interpretaciones.

• El desarrollo de software es un proceso artesanal dado que a la

programación de computadoras se le denomina arte.

• La ISw permite sistematizar y estructurar el desarrollo de software.

• ¿Cuál es la diferencia entre un albañil y un ingeniero en construcción?

• La aplicación de conocimiento y la disciplina de desarrollo.

• La ISw es un área tan extensa que prácticamente abarca todas las áreas

de la computación.

• El objetivo fundamental de la ISw es lograr la calidad del software.

• Por calidad se entienden muchas cosas. Para nuestro curso lo

entenderemos como realizar 100% bien las cosas en el menor tiempo

posible.

• La calidad hace referencia intrínseca a eficacia y eficiencia.

• Eficacia hacer las cosas bien.

• Eficiencia hacer las cosas bien con la menor cantidad de recursos.

• ¿Qué tiene más calidad un “Tico” o un BMV?

• Los dos tienen igual calidad si cumplen con los requerimientos

(checklist).

• En general la ISw tiene los objetivos de que el software sea correcto,

utilizable y costo-efectivo.

• Sinónimos de calidad es que esté libre de errores. Muchas de las

metodologías de software actuales se basan en esta premisa.

• ¿Por qué la necesidad de la ISw?



• El software es cada vez más complejo. A través de la Génesis de la

evolución del software, los proyectos informáticos se hicieron tan complejos y

costosos como construir edificios.

• En 1968 se da un hito importante al ocurrir la “crisis del software” y

definirse la ISw como tal.

• El software se define como un conjunto de instrucciones y estructuras de

datos que permiten resolver problemas a través de una computadora.

• La principal característica de proyectos informáticos es que el software

es un producto intangible y es difícil manejarlo. El desarrollo de software es una

actividad mental consumidora de tiempo.

• El software cuenta con las siguientes características:

o El software se desarrolla, no se fabrica.

o El software no se estropea.

o La mayoría del software es “Tailoring” (a la medida), casi no

existe rehúso.

• Se debe tomar en cuenta que existen diversos tipos de software con

características específicas:

o Software empotrado

o Software para PCs

o Software de Inteligencia Artificial

o Software de Gestión

o Software de Tiempo Real

o Software Científico

o Software de Sistemas

• La ISw es un conjunto de “mejores prácticas” que si no se llevan a la

práctica no sirven de nada.



• El factor humano es el recurso más importante de cualquier proyecto de

software. Por ejemplo, la Ley de Brooks: Si se aumenta un programador más

se retrasa el proyecto mientras se explica que hay que hacer.

• El proceso de desarrollo de software implica cuatro etapas:

o Especificación

o Desarrollo

o Evaluación

o Evolución

• El desarrollo de software se basa en modelos, siendo los más

representativos:

o Cascada (clásico)

o Construcción de prototipos

o Espiral

o RAD (Desarrollo rápido de aplicaciones)

• Cada uno de estos modelos tiene sus respectivas fases que pueden ser

muy similares entre sí.

GESTIÓN DEL PROYECTO

• La planeación de un proyecto es la parte más importante de la

Administración de cualquier proyecto por que es donde se define el

problema.

• Imaginemos que somos carpinteros y un cliente nos pide realizar una

silla de manera ¿Cómo es que le hacemos al cliente su producto?

• La gestión de un proyecto se centra en las 4P’s: Personal, Producto,

Proceso y Proyecto en respectivo y riguroso orden.

• El personal que está involucrado en un proyecto de software son:

Directivos, Administradores de Proyecto, Profesionales, Clientes y

Usuarios Finales, todos juegan roles y subroles muy importantes.



• De las tareas más difíciles de la gestión de proyectos se encuentran la

motivación del personal y del liderazgo.

• El desarrollo de software se debe realizar en equipos de trabajo y no

solamente en grupos. ¿Cuál es la diferencia entre grupos de trabajo y

equipos de trabajo?

o Un grupo es sólo una asociación de miembros que comparten

algo en común.

o Un equipo es un conjunto de personas que trabajan de manera

conjunta (colaborativamente) para lograr un fin común. Si uno no

realiza bien el trabajo repercute en los demás.

• Los equipos de software pueden ser de tres tipos: Descentralizado

Democrático, Descentralizado Controlado y Centralizado Controlado.

• Las metodologías ágiles de desarrollo de personas hacen hincapié en

equipos de dos personas.

• Muchas metodologías de software han cambiando el nombre de

Producto al de solución para hacer referencia al “entregable” de un

proyecto.

• Toda gestión de Proyecto debe cumplir con cuatro fases: planeación,

organización, dirección y control.

Establecer las prioridades de un proyecto.

Hacer la valoración inicial de las actividades del proyecto.

Definir los hitos del proyecto y productos a entregar.

Mientras el proyecto no se haya terminado o cancelado repetir.

Bosquejar la programación en el tiempo del proyecto.

Iniciar actividades conforme a la programación.

Esperar (por un momento).

Revisar el progreso del proyecto.

Revisar los estimados de los parámetros del proyecto.



Actualizar la programación del proyecto.

Renegociar las restricciones del proyecto y los productos a entregar

Si surgen problemas entonces

Iniciar la revisión técnica

Fin si

Fin mientras

• La parte más difícil de la Gestión de Proyectos consiste en el proceso de

Estimación.

• El proceso de estimación tiene su primera aproximación en el proceso

de Presentación de la Propuesta, seguida de la determinación de

recursos, planeación y calendarización, costos, gestión de riesgos,

supervisión y concluye con la presentación de informes.

• Estimar los costos de un proyecto es sumamente complicado. Las

métricas que se tienen están enfocadas al tamaño del código (LOC) o

bien a la funcionalidad del mismo (puntos de función).

• Los puntos de función toman en cuenta parámetros como las interfaces

de E/S, el número de archivos, las interacciones con los usuarios, entre

otros.

• Las técnicas de estimación pueden ser modelos empíricos como

consultar a un experto, estimación por analogía o bien lo que el cliente

esté dispuesto a dar; la otra alternativas son los métodos formales de

estimación que utilizan algoritmos genéricos como el modelo COCOMO

II.

• Se puede hacer uso de la subcontratación (outsourcing).

• El análisis de riesgos es una de las actividades que con frecuencia es

omitida en el desarrollo de cualquier proyecto.

• Los riesgos nos definen todos aquellos factores que pueden hacer que

fracase un proyecto. Se mide en % y puede ser de tres tipos: Riesgo de

Proyecto, de Producto y del Negocio.



• El análisis de riesgos es uno de los primeros pasos para realizar los

estudios de factibilidad, los cuales pueden ser de cuatro tipos: Operativa,

Técnica, Cronograma y Económica.



USO DE MÉTRICAS EN UN PRODUCTO O SERVICIO

PROBLEMÁTICA DE LA ESTIMACIÓN

• Averiguar lo que costara desarrollar una aplicación:

o Esfuerzo (hombre-mes),

o Duración,

o Dinero, etc.

• M

omento en que se desea conocer el coste.

¿Qué se entiende normalmente por “ESTIMACIÓN”?

La definición más común de estimación es “Una estimación es la predicción

más optimista con una probabilidad distinta de cero de ser cierta”.

Tom DeMarcoTom DeMarco

Aceptar esta definición lleva irrevocablemente hacia un método denominado

cuál es el primer momento en el que no se puede demostrar que no va a ser

posible terminar.

Proceso de Estimación de Software


Medir lo quequiere elusuario

Estimar loque Costara(esfuerzo)

Descomponerpor fases y

tareas

HistorialEmpresa

Especificación derequerimientos

Requisitos aCumplir

Medida de lo quequiere el usuario

Estimacióndel Esfuerzo

Tareas arealizar


Medir lo que quiere el usuario

Estimar lo que costara

• Experiencia Individual

• Experiencia de Empresa

Métodos utilizados para la estimación de proyectos

• Basados en la experiencia.

• Basado exclusivamente en los recursos.

• Método basado exclusivamente en el mercado.

• Basado en los componentes del producto o en el proceso de desarrollo.

• Métodos algorítmicos.

Métodos basados exclusivamente en la experiencia:

• Juicio experto:

o Puro

Un experto estudia las especificaciones y hace su

estimación.



Se basa fundamentalmente en los conocimientos del

experto.

Ahora... si desaparece el experto, la organización

simplemente deja de estimar...

o Delphi

Un grupo de personas son informadas y tratan de adivinar

lo que costara el desarrollo tanto en esfuerzo, como su

duración.

Las estimaciones en grupo suelen ser mejores que las

individuales.

Se dan las especificaciones a un grupo de expertos.

Se les reúne para que discutan tanto el producto como la

estimación.

Remiten sus estimaciones individuales al coordinador.

Cada estimador recibe información sobre su estimación, y

las ajenas pero de forma anónima.

Se reúnen de nuevo para discutir las estimaciones.

Cada uno revisa su propia estimación y la envía al

coordinador.

Se repite el proceso hasta que la estimación converge de

forma razonable.

o Analogía

Consiste en comparar las especificaciones de un proyecto,

con las de otros proyectos.

Pueden varias los siguientes factores:

• Tamaño: ¿mayor o menor?

• Complejidad: ¿Más complejo de lo usual?

• Usuarios: Si hay más usuarios habrán más

complicaciones.



• Otros factores:

o Sistema Operativo, entornos, ¿es la primera

vez que se va a utilizar?

o Hardware, ¿es la primera vez que se va a

utilizar?

o Personal del proyecto, ¿nuevos en la

organización?

o Distribución de la utilización de recursos en el ciclo de vida

Usualmente las organizaciones tienen una estructura de

costes similar entre proyectos.

Si en un proyecto ya hemos realizado algunas fases, es de

esperar que los costes se distribuyan de manera

proporcional.

Método basado exclusivamente en los recursos: Parkinson

• En la estimación consiste en ver de cuanto personal y durante cuanto

tiempo se dispone de el, haciendo esa estimación.

• En la realización: “El trabajo se expande hasta consumir todos los

recursos disponibles”. (Ley de Parkinson)

Método basado exclusivamente en el mercado: precio para vender

• Lo importante es conseguir el contrato.

• El precio se fija en función de lo que creemos que esta dispuesto a

pagar el cliente.

• Si se usa en conjunción con otros métodos puede ser aceptable, para

ajustar la oferta.



• Peligro si es el único método utilizado.

Basado en los componentes del producto o proceso de desarrollo:

• Bottom-up

o Se descompone el proyecto en las unidades lo menores posibles.

o Se estima cada unidad y se calcula el coste total.

• Top-Down

o Se ve todo el proyecto, se descompone en grandes bloques o

fases.

o Se estima el coste de cada componente.

Métodos algorítmicos

Se basan en la utilización de fórmulas que aplicadas sobre modelos top-down o

bottom-up producen una estimación de coste del proyecto:

• Modelo de estimación de coste y esfuerzo COCOMO (Boehm).

• Métrica de atributos internos del producto PUNTOS DE FUNCIÓN

(Albrecht).



FASE DE PARTIDA DE UN PROYECTO

TEMAS

• Situación actual e identificación de la necesidad.

• Estudio de viabilidad.

• Técnicas de recogida de información.

SITUACIÓN ACTUAL E IDENTIFICACIÓN DE LA NECESIDAD

Puntos de partida para cada proyecto de desarrollo de software:

• A nivel de empresa

• A nivel del propio proyecto

Inicio a nivel de empresa

Los principales elementos que marcan el inicio del proyecto son:

• La decisión de realizar el proyecto.

• La selección del jefe de proyecto.

La decisión de realizar el proyecto

Hay que determinar quién va a desarrollar el software:

• Departamento de desarrollo de la empresa.

• Empresa de servicios informáticos.

Departamento de desarrollo de la empresa

El origen de la necesidad inicial puede venir de:

• El cambio de los requisitos del software existente (legislación,

estándares, etc.).

• La petición específica de un cliente o usuario.

• La propuesta realizada desde la organización de desarrollo.

• La necesidad detectada por el departamento de marketing.



• El personal de mantenimiento de las aplicaciones hace una

recomendación específica.

• Se detecta a partir de los usuarios.

Hay que saber lo que hay que hacer.

Hay que evaluar la viabilidad del proyecto, evaluando beneficios y gastos.

Empresa de servicios informáticos

• Surge como respuesta a la demanda de un cliente.

• La empresa debe de tener:

o idea clara de las necesidades.

o valorar la viabilidad del proyecto.

o Los beneficios dependen de las condiciones contractuales que se

establezcan.

o El cliente necesita conocer las ventajas de la nueva aplicación.

o Los gastos incluyen la preparación del presupuesto. Se trata de:

Alcance del proyecto.

Complejidad de su desarrollo.

Será necesario definir y analizar los requisitos del sistema que se debe

construir.

Se crea un documento llamado informe de necesidades que recoge los

resultados de los estudios previos.

La decisión de emprender un proyecto implica estudiar su viabilidad.

El Estudio de Viabilidad debe analizar:

• Las diferentes alternativas que se pueden plantear:

o Comprar un producto software comercial que cumpla los

requisitos definidos.

o Desarrollar el producto internamente.



o Automatización parcial del sistema, para tener menor gasto.

o Desarrollarlo de forma externa mediante un contrato. Para ello se

necesita:

Solicitud de propuestas.

Selección de una oferta.

Supervisar los resultados a través de un control de

aceptación del producto.

o La evaluación de cada alternativa, incluyendo su viabilidad

económica, técnica, legal, operativa, etc.

o La especificación detallada de la alternativa seleccionada.

o El establecimiento de fechas y de compromisos de trabajo por

parte de las personas y departamentos implicados (Plan tentativo

para el proyecto).

La selección del Jefe de Proyecto

• Suele realizarse de forma posterior a la decisión de realizar un proyecto.

• Es el elemento más crítico para el éxito del proyecto.

• Características más deseables para dirigir un proyecto son: (Bruce &

Pederson, 1982)

o Liderazgo: habilidad para motivar a los componentes del equipo

de proyecto.

o Comprensión técnica: conocimientos para tomar las decisiones

técnicas correctas.

o Competencia en la gestión: capacidad para controlar las

actividades, los costes y los presupuestos del proyecto.

o Presteza y decisión: para observar, evaluar y decidir.

o Versatilidad y flexibilidad: para encauzar acontecimientos

imprevistos.



o Integridad: para reclutar al personal más capacitado y ganarse la

confianza del cliente.

o Previsión: para anticiparse a los problemas y aportar soluciones.

Inicio a nivel de proyecto

El director de proyecto debe establecer el entorno inicial de trabajo del

proyecto:

• Identificación de las áreas de gran riesgo del proyecto.

• Establecimiento de presupuestos, calendarios, planes de trabajo

personal y asignaciones de tareas.

• Las técnicas de comunicación entre los miembros del equipo.

• Los requisitos que deben cumplir los posibles subcontratistas.

• La manera de abordar la interacción con el cliente.

• Los resultados de estas actividades se incluyen en la primera versión del

Plan del Proyecto:

o Qué hay que hacer.

o Cómo se hará.

o Quién lo hará.

o Cuándo se hará

o Con qué herramientas y técnicas se hará.



ESTUDIO DE VIABILIDAD

“TODOS LOS PROYECTOS SON REALIZABLES

¡CON RECURSOS ILIMITADOS Y UN TIEMPO INFINITO!”

Pressman, 1993

Definición

Análisis técnico, operacional y económico previo a un proyecto para determinar

si éste es rentable.

Objetivos:

• Investigar el problema planteado.

• Discutir aspectos esenciales que sirvan de base para decidir si el

problema es abordable o no.

• Decidir acerca de la continuidad o no del proyecto, así como los riesgos

que conlleva la ejecución del mismo.

¿Qué aspectos deben incluir?

• Económico: determinar si el beneficio obtenido compensa los costes.

• Técnico: estudiar la funcionalidad, el rendimiento o las restricciones para

determinar si son realizables.

• Legal: dilucidar si los requisitos atentan contra alguna ley o reglamento o

a disposiciones legales de contratos, responsabilidad civil, etc.

• Operativa: determinar si se puede implantar de manera efectiva en la

empresa.

Consideraciones Técnicas:

• Riesgo de desarrollo

o ¿Se puede desarrollar el sistema de tal forma que las

funcionalidades y el rendimiento esperado se consigan dentro de

las restricciones impuestas?.

• Disponibilidad de recursos humanos.



o ¿Tenemos el suficiente número de personas, con la cualificación

adecuada?.

• Disponibilidad de recursos informático.

o ¿Tenemos los recursos hardware y software necesarios?.

• Tecnología actual.

o ¿Estamos usando tecnología lo suficientemente probada?.

o ¿Qué tecnologías se requieren para conseguir los requisitos?

o ¿Qué nuevos métodos/algoritmos/técnicas son necesarios?

o ¿Cuál es el riesgo?

Análisis Económico de Coste-Beneficio

• Sus conclusiones son determinantes para que la dirección de la

empresa tome una decisión sobre continuar o cancelar el proyecto.

• Permite:

o Seleccionar la alternativa más beneficiosa.

o Prever las necesidades financieras.

o Valora:

los elementos tangibles: gastos de equipo, tiempo de

desarrollo, salarios, etc.

los elementos intangibles: ventajas económicas de una

mejor información para decidir, beneficios competitivos de

un mejor entorno de trabajo, etc.

Análisis Económico de Coste-Beneficio

Representación en forma de tabla:

• Columnas: años de vida del proyecto.

• Filas: los conceptos de gasto y beneficio del

proyecto.

Conceptos de Costes:



• Coste del personal informático implicado durante

todo el proyecto.

• Coste de software adicional (S.O., Compiladores,

Herramientas CASE, SGBD, etc.).

• Análisis Económico de Coste-Beneficio

• Coste de consultoría.

• Coste de hardware.

• Coste de la infraestructura (mobiliario, obras, etc.).

• Costes debidos al usuario (formación,

documentación, etc.).

• Además de los costes continuos:

o Mantenimiento del sistema.

o Alquileres.

• Inflación y

• Los “costes de oportunidad”:

o Recursos (económicos y/o humanos)

utilizados en este proyecto no podrán

invertirse en otros que pueden resultar más

rentables.

Conceptos de Beneficios (valoración subjetiva):

• Nuevas funcionalidades.

• Eliminación de errores.

• Reducción de errores.

• Aumento de velocidad.

• Aumento de fiabilidad.

Aspectos importantes para un análisis eficaz:



• La mayoría de las estimaciones de costes y de

beneficios suelen consistir en rangos de valores

probables.

• Es recomendable hacer estimaciones pesimistas o

conservadoras (ley de Murphy “si algo puede fallar,

fallará).

• Considerar diversos factores económicos: inflación,

tipos de interés, volúmenes de crecimiento, etc.

(recomendable utilizar los mismos valores recogidos

en los planes financieros de la empresa.).

• Tratar de valorar y prever todos los riesgos.



TÉCNICAS DE RECOGIDA DE INFORMACIÓN

El proceso de análisis debería seguir los siguientes pasos: (Raghavan, 1994)

• Identificar las fuentes de información (usuarios) relevantes para el

proyecto.

• Realizar las preguntas apropiadas para comprender sus necesidades.

• Analizar la información recogida para detectar los aspectos que quedan

poco claros.

• Confirmar con los usuarios lo que parece haberse comprendido de los

requisitos.

• Sintetizar los requisitos en un documento de especificación apropiado.

¿Por qué se necesitan técnicas de recogida de información?

• Diferentes vocabularios o jergas.

• Choque de personalidades y caracteres.

• Desconocimiento de lo que la tecnología puede ofrecer, etc.

Principales Técnicas: (Flaaten et al. 1989)

• Entrevistas.

o Técnica más utilizada.

o Requiere mayor preparación y experiencia por parte del analista.

o Definición (Flaaten et. Al, 1989): “intento sistemático de recoger

información de otra persona” a través de una comunicación

interpersonal que se lleva a cabo por medio de una conversación

estructurada.

o Siempre hay un entrevistador y un entrevistado.

o Entrevistador (Daniels y Yeats, 1991):

Imparcial.

Ponderado.



Escuchar activamente.

Cordial y accesible.

Paciente.

Además, el entrevistador debe:

• Mostrar interés y entusiasmo por el trabajo que

realiza y ser capaz de transmitirlo a los

entrevistados.

Fases de la entrevista:

• Preparación.

o El entrevistador debe documentarse:

Investigar la situación de la empresa

(documentos disponibles).

Información externa (folletos, informes

del sector, publicaciones, etc.).

Objetivos:

• Mayor eficacia.

• Obtener información no

accesible por otros medios.

o Identificar las personas a entrevistar:

Enfoque top-down:

• Desde los directivos (visión

global)

• Hasta los empleados (detalles)

Entrevistas de “cortesía”:

• Visión estratégica.



• Influencia sobre personal

dependiente.

Objetivos:

• Minimizar el número de

entrevistados.

• Apoyo al proyecto.

o Objetivo y logística de la entrevista:

Lugar (Confortable y minimizando las

interrupciones).

Fijar fecha y hora (adaptarse al

entrevistado).

Envío previo de cuestionario (conocer

los temas a tratar).

Autorización firmada (interés de la

dirección).

Objetivos:

• Mayor eficacia.

• Apoyo al proyecto.

• Realización.

o Apertura:

Informar sobre la razón de la

entrevista, uso de la información,

mecánica de las preguntas, etc.

Objetivo: crear el ambiente

confortable.

o Desarrollo:

No debe superar las 2 horas.



Técnicas:

• Preguntas abiertas: no

escuetas, no interrogatorio.

• Utilizar las palabras y frases

apropiadas.

• Asentir y muestras de escucha

(tono de voz, movimientos,

expresión facial, etc.).

• Repetir las respuestas dadas,

con precaución.

• Pausas, con precaución.

• Distribución de tiempos:

o Entrevistador un 20%

o Entrevistado un 80%

• No interrumpir al entrevistado.

• Hacer ver que nos está

ayudando.

• Tomar notas (grabar, puntos

esenciales, colaboradores).

o Terminación:

Agradecimientos.

Citación para nueva entrevista.

Posibilidad de aclarar dudas

posteriores.

• Análisis.

o Lectura de las notas de la entrevista.



o Pasar a limpio esas notas

o Reorganizar la información.

o Contrastar la información con:

o Otras entrevistas.

o Otras fuentes.

o Evaluar la entrevista para mejorar las

siguientes.

• Desarrollo conjunto de aplicaciones (JAD)

o Cooperación y trabajo en equipos entre usuarios y analistas.

o Varias reuniones entre usuarios cualificados y analistas, de 2 a 4

días.

o Las entrevistas requieren mucho tiempo frente a JAD.

o Detectar errores en la especificación de requisitos.

o Participación importante de los usuarios.

o Fases:

Adaptación o preparación:

• Selección de los participantes.

• Obtener cierta información.

• Organizar la reunión.

Sesión JAD: finalmente se obtiene el documento de

especificación.

Documentación: documento de especificación de requisitos

final (detallado, gráficos, dibujos, etc.).



• Prototipado.

o El prototipo se debe construir más rápidamente que la aplicación.

o Utilizado cuando:

Área de la aplicación mal definida.

Coste muy alto si los usuarios rechazan la aplicación por

no cumplir sus expectativas.

Necesidad de evaluar el impacto del sistema en los

usuarios y en la organización.

o Tipos:

o Prototipado de la interfaz de usuario:

Comprobar que está bien diseñada y satisface las

necesidades de los usuarios.

Coste bajo.

Evita modificaciones posteriores.

Consiste en modelos de pantallas (papel, programas de

dibujo o presentaciones) o simulaciones más elaboradas.

o Modelos de rendimiento:

Evaluar el posible rendimiento de un diseño técnico (en

aplicaciones críticas).

No son aplicables al trabajo de análisis de requisitos.

o Prototipado funcional:

El prototipo supone una primera versión del sistema con

funcionalidad limitada.

Relacionado con un ciclo de vida iterativo: cada función

implementada se comprueba si es adecuada, se corrige y

refina para añadirla al sistema.

o Prototipado – Herramientas utilizadas



Nivel bajo:

• Herramientas comunes y fáciles de utilizar:

programas de dibujo o de presentaciones, hojas de

cálculo o generadores de informes.

• Permite la incorporación rápida de los cambios

solicitados por el usuario.

Nivel medio:

• Gestores de bases de datos (se ha usado mucho

Dbase III).

• Sistemas de cuarta generación (con manejo de

datos).

Nivel alto: permiten reutilizar el prototipo realizado para

continuar el desarrollo.

• Herramientas CASE.

• Gestores de aplicaciones.

• Observación

o Análisis “in situ” del departamento a informatizar.

o Ventajas:

Analizar mejor los detalles.

Captar el funcionamiento y el ambiente real de la empresa.

• Estudio de documentación

o El analista debe estudiar la documentación existente en las

organizaciones y también los impresos (con datos).

• Cuestionarios.

o Permiten recoger información de un gran número de personas, en

poco tiempo y dispersas geográficamente.



• Tormenta de ideas (Brainstorming).

o Reunión de 4 a 10 usuarios

o Fase 1º: permite capturar un primer conjunto de requisitos.

o Fase 2º: análisis detallado de cada propuesta.

o Útil cuando las necesidades no están muy claras.

• ETHICS (Effective Technical and Human Implementation of Computer-

based Systems, Implementación Efectiva de Sistemas Informáticos

desde los puntos de vista Humano y Técnico).

o Fomenta la participación de los usuarios en los proyectos.

o Se busca la satisfacción de los empleados en el trabajo

o Los requisitos técnicos del sistema son los necesarios para

mejorar la situación de los empleados en función de los análisis

realizados.



PLANEACIÓN DE SISTEMAS DE INFORMACIÓN

¿QUÉ ES LA PLANEACIÓN DE SISTEMAS?

• Pretende identificar y establecer prioridades sobre los sistemas de

información y trabajo de la empresa. En donde se puedan identificar las

necesidades y diseñar soluciones para dichas necesidades.

• A diferencia del análisis el estudio se hace en un ámbito mayor.

FASES QUE COMPONEN LA PLANEACIÓN DE SISTEMAS

1. Fase de Estudio: Estudiar la misión de la organización.

2. Fase de Definición: Definir una arquitectura de información.

3. Análisis de Áreas de Empresa: Analizar un área de empresa.

FASES DE LA PLANEACIÓN

FASE DE ESTUDIO



OBJETIVOS DE LA FASE DE ESTUDIO

• Establecer los criterios de la planeación de sistemas.

• Cimentar una cooperación de trabajo entre el área de sistemas de

información (interna o externa) y los directivos de la empresa.

• Analizar las estrategias de la empresa que pudieran influir sobre los

sistemas de información.

INSTRUMENTOS

Análisis de Factores Críticos de Éxito

Es la identificación de una jerarquía de medidas de rendimiento que lleva a la

identificación de los factores y los puntos críticos que determinarán el éxito de

una empresa.

Jerarquía de Factores Críticos



Análisis de Competencia

Las 5 fuerzas competitivas de Porter:

Michael Porter desarrolló este método de análisis con el fin de descubrir qué

factores determinan la rentabilidad de un sector industrial y de sus empresas.

Para Porter, existen 5 diferentes tipos de fuerzas que marcan el éxito o el

fracaso de un sector o de una empresa:

1. Amenaza de entrada de nuevos competidores. El mercado o el

segmento no son atractivos dependiendo de si las barreras de entrada

son fáciles o no de franquear por nuevos participantes, que puedan

llegar con nuevos recursos y capacidades para apoderarse de una

porción del mercado.

2. La rivalidad entre los competidores. Para una corporación será más

difícil competir en un mercado o en uno de sus segmentos donde los

competidores estén muy bien posicionados, sean muy numerosos y los

costos fijos sean altos, pues constantemente estará enfrentada a

guerras de precios, campañas publicitarias agresivas, promociones y

entrada de nuevos productos.

3. Poder de negociación de los proveedores. Un mercado o segmento del

mercado no será atractivo cuando los proveedores estén muy bien

organizados gremialmente, tengan fuertes recursos y puedan imponer

sus condiciones de precio y tamaño del pedido. La situación será aún

más complicada si los insumos que suministran son claves para

nosotros, no tienen sustitutos o son pocos y de alto costo. La situación

será aun más crítica si al proveedor le conviene estratégicamente

integrarse hacia delante.

4. Poder de negociación de los compradores. Un mercado o segmento no

será atractivo cuando los clientes están muy bien organizados, el

producto tiene varios o muchos sustitutos, el producto no es muy

diferenciado o es de bajo costo para el cliente, lo que permite que pueda

hacer sustituciones por igual o a muy bajo costo. A mayor organización

de los compradores, mayores serán sus exigencias en materia de



reducción de precios, de mayor calidad y servicios y por consiguiente la

corporación tendrá una disminución en los márgenes de utilidad. La

situación se hace más crítica si a las organizaciones de compradores les

conviene estratégicamente sindicalizarse.

5. Amenaza de ingreso de productos sustitutos. Un mercado o segmento

no es atractivo si existen productos sustitutos reales o potenciales. La

situación se complica si los sustitutos están más avanzados

tecnológicamente o pueden entrar a precios más bajos reduciendo los

márgenes de utilidad de la corporación y de la industria.

Análisis de la Cadena de Valor

Cadena de valor de Porter

La cadena de valor fue descrita y popularizada por Michael E. Porter en su

best-seller de 1985: Competitive Advantage: Creating and Sustaining Superior

Performance. New York, NY The Free Press.

La cadena de valor categoriza las actividades que producen valor añadido en

una organización. Se dividen en dos tipos de actividades:



1. Las actividades primarias que conforman la creación física del producto,

las actividades relacionadas con su venta y la asistencia post-venta. Se

dividen en:

a. Logística interna: recepción, almacenamiento y distribución de las

materias primas.

b. Operaciones (producción): recepción de las materias primas para

transformarlas en el producto final.

c. Logística externa: almacenamiento de los productos terminados y

distribución del producto al consumidor.

d. Ventas y Marketing: actividades con las cuales se da a conocer el

producto.

e. Servicios post-venta (mantenimiento): actividades destinadas a

mantener o realizar el valor del producto. Ej: garantías.

2. Estas actividades son apoyadas por las también denominadas

actividades secundarias:

a. Infraestructura de la organización: actividades que prestan apoyo

a toda la empresa, como la planificación, contabilidad, finanzas...

b. Dirección de recursos humanos: búsqueda, contratación y

motivación del personal.

c. Desarrollo de tecnología (investigación y desarrollo): obtención,

mejora y gestión de la tecnología.

d. Abastecimiento (compras): proceso de compra de los materiales.

Para cada actividad de valor añadido han de ser identificados los generadores

de costes y valor.



ACTIVIDADES

1. Formar el equipo de planeación.

2. Definir el ámbito y la expectativas de la planeación.

3. Identificar las medidas de rendimiento de la empresa.

4. Desarrollar el plan de proyecto de planeación.

5. Ejecutar.

6. Revisar y Retroalimentar.

FASE DE DEFINICIÓN



OBJETIVOS DE LA FASE DE DEFINICIÓN

• La segunda fase consiste en definir una arquitectura de información.

• Una arquitectura de información es una visión y un plan para el uso de

tecnología de información y desarrollo de sistemas de información

necesarios para apoyar la misión de empresa.

• Definir datos, aplicaciones, redes, servicios de información e

infraestructuras para los sistemas de información.

• Identificar área lógicas de empresa y establecer prioridades, para la

estructuración de los sistemas tanto a corto plazo, mediano y largo.

INSTRUMENTOS

Análisis de Asociaciones

• Es una técnica que examina las asociaciones o relaciones naturales

entre dos objetos o ideas cualesquiera, la cual utiliza matrices de

asociaciones.

• La matriz de asociación documenta las relaciones entre dos medidas de

rendimiento o dos objetos de la empresa.

Matriz de Asociaciones

P = Responsabilidad Primaria

S = Responsabilidad Secundaria



Matrices que den respuesta a diferentes preguntas:

• ¿Qué unidades de la empresa utilizan cada dato?

• ¿Qué unidades de la empresa realizan cada función de la empresa?

• ¿Qué unidades de la empresa se encuentran en X lugar?

• ¿Qué objetivos de empresa son pertinentes para cada función de la

empresa?

• ¿Qué unidades de la empresa son responsables de cada objetivo y

como es su relación?

• ¿Qué factores críticos de éxito se aplican a cada función de empresa?

Análisis de afinidades y agrupaciones

• La afinidad es una medida de lo que tienen en común “cosas” diferentes.

Los valores de afinidad siempre están comprendidos entre 0 y 1.

• De la matriz de asociaciones se identifica:

o Afinidad (entidad1 con entidad 2)

o Número de veces que suceden juntas 1 y 2

o Número de veces que sucede 1

• La agrupación forma grupos lógicos de cosas sobre la base de las

afinidades.



ACTIVIDADES

1. Definir un modelo de la empresa.

2. Evaluar las estrategias actuales de la empresa.

3. Evaluar las estrategias y los servicios actuales de información.

4. Identificar áreas de la empresa y establecer prioridades.

5. Completar la nueva arquitectura de información.

6. Identificar y planear proyectos posteriores.

7. Revisar las Conclusiones y aprobar el plan

a. Revisión de Calidad.

b. Revisión de Factibilidad.

ANÁLISIS DE ÁREA DE EMPRESA

OBJETIVOS

El propósito del AAE es idear un plan que lleve a obtener aplicaciones de

sistemas de información altamente integradas para un área de empresa. Como

contraste al análisis clásico de sistemas, el análisis de áreas de empresa

requieren un ámbito más amplio y un menor nivel de detalle que el análisis.

Desarrollar una base única e integrada para la empresa. Desarrollar una

infraestructura común de redes para la empresa. Desarrollar proyectos



planeados de desarrollo de aplicaciones, prioridades y calendarios para cada

área de la empresa.

• Identificar las necesidades en la empresa de una base de datos

compartida.

• Identificar la necesidad de una red compartida.

• Identificar el nivel de integración entre las áreas de la empresa.

INSTRUMENTOS

Reingeniería de Procesos

Es una técnica obligatoria para estudiar los procesos de empresa básicos,

independiente de las unidades de la empresa y del soporte de sistemas de

información, con el fin de determinar si los procesos pueden ser simplificados y

mejorados de forma significativa.

ACTIVIDADES

1. Formar el equipo de análisis.

2. Identificar medidas de rendimiento de la empresa.

3. Elaborar el modelo de área de empresa.

4. Evaluar el rendimiento actual del área de empresa y de los sistemas de

información.

5. Identificar proyectos de desarrollo y establecer prioridades.

6. Planear una estrategia y proyectos de desarrollo de aplicaciones.

7. Revisar las conclusiones y aprobar el plan.



INGENIERÍA DE LOS SISTEMAS

“...Diseño, implementación e instalación de sistemas que incluyen hardware,

software y gente...”

OBJETIVOS

• Introducir conceptos de Ingeniería de Sistemas a Ingenieros de

Software.

• Discutir las dificultades de la Ingeniería de Sistemas.

• Describir el concepto de procuración de sistema y el proceso de

Ingeniería del Sistema.

• Discutir el concepto de confiabilidad en un contexto de sistema.

TÓPICOS

• Sistemas y su ambiente.

• Procuración del sistema.

• El proceso de Ingeniería de Sistema.

• Modelado de la Arquitectura del Sistema.

• Factores Humanos.

• Ingeniería de la confiabilidad en el sistema

¿QUE ES UN SISTEMA?

• Un conjunto de componentes inter-relacionados trabajando

conjuntamente para un fin común. El sistema puede incluir software,

dispositivos mecánicos y eléctricos, hardware, y ser operado por gente.

• Los componentes del sistema son dependientes de otros componentes.

• Las propiedades y el comportamiento de los componentes del sistema

están inter-relacionados de forma compleja.



PROBLEMAS CON LA INGENIERÍA DE SISTEMAS

• Los sistemas grandes están usualmente diseñados para resolver

problemas complejos.

• La Ingeniería de Sistemas requiere un gran esfuerzo de coordinación

entre varias disciplinas.

o Existen combinaciones infinitas para el diseño de software entre

componentes.

o Existe desconfianza mutua y poco entendimiento entre distintas

disciplinas.

• Los sistemas deben diseñarse para que duren varios años en un

ambiente con cambios continuos.

INGENIERÍA DE SOFTWARE Y SISTEMAS

• La proporción del software en los sistemas esta creciendo. La

electrónica esta siendo controlada por software, con lo que se están

remplazando los sistemas de propósito específico.

• Los problemas de la Ingeniería de Sistemas son similares a los de la

Ingeniería de Software.

• El software ha sido visto siempre como un problema dentro de la

Ingeniería de Sistemas. Muchos proyectos grandes se han visto

retrasados por el software.

LOS SISTEMAS Y SU AMBIENTE

• Los sistemas no son independientes, sino que existen dentro de un

ambiente.

• La función del sistema puede ser la de cambiar su ambiente.

• Los efectos del ambiente pueden alterar el funcionamiento del sistema.

p.ej. la fuente de poder puede afectar al sistema.



• El ambiente físico y organizacional puede ser importante.

JERARQUÍAS DEL SISTEMA

PROCURACIÓN DEL SISTEMA

• Es la adquisición de un sistema en una organización, para satisfacer una

necesidad.

• Es necesario especificar el sistema y desarrollar la arquitectura antes de

cualquier adquisición.

o Es necesaria una especificación que permita al contratista

desarrollar el sistema.

o La especificación puede permitir comprar sistemas comerciales

existentes, que resulten mas baratos que desarrollar el sistema.

CONTRATISTAS Y SUB-CONTRATISTAS

• La adquisición de sistemas de hardware-software muy grandes se hace

usualmente a través de un contratista principal.

• Los sub-contratos se hacen para que sean llevados a cabo por otros

proveedores de partes del sistema.



• El cliente contrata el sistema con el contratista principal y no con los sub-

contratistas.

MODELO CONTRATISTA/SUB-CONTRATISTA

PROCESO DE PROCURACIÓN DEL SISTEMA

EL PROCESO DE INGENIERÍA DE SISTEMA

• Involucra a Ingenieros de diferentes áreas.



o Existe mucho espacio para malentendidos aquí. Distintas

disciplinas utilizan diferente vocabulario y se requiere mucha

negociación.

• Usualmente se sigue el modelo de cascada dada la necesidad de

desarrollo en paralelo de distintas partes del sistema.

o Poco margen para iteración entre fases debido a que los cambios

de hardware pueden ser muy costosos. El software tendrá que

compensar los problemas de hardware.

PROCESO DE INGENIERÍA DE SISTEMAS

DESARROLLO INTERDISCIPLINARIO

DEFINICIÓN DE REQUERIMIENTOS DEL SISTEMA

• En esta etapa se definen tres tipos de requerimientos.

o Requerimientos funcionales finos. Las funciones del sistema son

definidas en forma abstracta.

o Propiedades del sistema. Los requerimientos no-funcionales para

el sistema en general son definidos.

o Características indeseables. Comportamiento inaceptable del

sistema es especificado.



• Se deben definir también los objetivos organizacionales para el sistema.

OBJETIVOS DEL SISTEMA

• Objetivos Funcionales.

o Proveer un sistema de alarmas e intrusos para un edificio que

proveerá alerta interna y externa contra incendios o entradas no-

autorizadas.

• Objetivos Organizacionales.

o Asegurar el funcionamiento normal del trabajo que se lleva a cabo

en el edificio, y que no sea interrumpido por eventos tales como

incendios o entradas no-autorizadas.

PROBLEMAS CON LOS REQUERIMIENTOS DEL SISTEMA

• A medida que el sistema está siendo especificado, ocurren cambios.

• Se deben anticipar los desarrollos de hardware o comunicaciones en el

ciclo de vida del sistema.

• Difícil definir requerimientos no-funcionales del sistema, sin tener una

idea clara de un componente específico.

PROCESO DE DISEÑO DEL SISTEMA



EL PROCESO DE DISEÑO DEL SISTEMA

• Partición de Requerimientos.

o Organización de requerimientos en grupos relacionados.

• Identificación de subsistemas.

o Identificar un conjunto de subsistemas que cumplen con los

requerimientos del sistema.

• Asignación de requerimientos a subsistemas.

• Especificación de funcionalidad de cada subsistema.

• Definición de interfaces entre subsistemas.

o Actividad crítica cuando se desarrolla el sistema el forma paralela.

PROBLEMAS DEL PROCESO DE DISEÑO DEL SISTEMA

• La partición de requerimientos de hardware, software y componentes

humanos puede involucrar mucha negociación.

• Con frecuencia se asume que los problemas difíciles de diseño son

fácilmente resueltos por software.

• Las plataformas de software pueden ser inapropiadas para los

requerimientos de software, por lo que deben de compensar esto.

DESARROLLO DE SUB-SISTEMAS

• Típicamente se desarrollan en paralelo con distintos grupos de

desarrolladores.

• Falta de comunicación entre grupos de trabajo.

• Si existen mecanismos burocráticos lentos para proponer cambios en el

sistema, provocarán que la planificación se extienda.



INTEGRACIÓN DEL SISTEMA

• Es el proceso de conjuntar hardware, software y gente, para llevar a

cabo un sistema.

• Debe de ser llevado a cabo de forma incremental, de forma que los sub-

sistemas sean integrados uno a la vez.

• En esta etapa, usualmente se encuentran los problemas de interfaces.

• Puede haber problemas si no se coordina bien la entrega de

componentes del sistema.

INSTALACIÓN DEL SISTEMA

• Puede haber suposiciones incorrectas en el ambiente del sistema.

• Puede haber resistencia humana a la introducción de un nuevo sistema.

• El sistema puede tener que co-existir con algún sistema alternativo por

algún tiempo.

• Puede haber problemas físicos en la instalación (p.ej. cableado, etc.)

• Tiene que identificarse el entrenamiento del operador.

OPERACIÓN DEL SISTEMA

• Traerá problemas no contemplados en los requerimientos.

• Los usuarios podrían usar el sistema de forma no contemplada por los

Ingenieros del Sistema.

• Puede revelar problemas con la interacción con otros sistemas.

o Problemas físicos por incompatibilidad.

o Problemas de conversión de datos.

o Errores frecuentes del operador derivados de interfaces

inconsistentes.



EVOLUCIÓN DEL SISTEMA

• Los sistemas grandes tienen una larga vida. Pero deben evolucionar

para adaptarse a requerimientos cambiantes.

• La evolución es inherentemente costosa.

o Los cambios pueden ser vistos desde una perspectiva técnica y

de negocio.

o Los sub-sistemas interactúan de forma que en el futuro problemas

no contemplados pueden aparecer.

o No existe una racionalidad para justificar el proceso de diseño.

o La estructura del sistema se corrompe a medida que se le hacen

cambios.

• La mayoría de los sistemas requieren mantenimiento.

MODELADO DE LA ARQUITECTURA DEL SISTEMA

• El modelo de la arquitectura presenta una visión abstracta de los sub-

sistemas que configuran el sistema.

• Incluye flujos de información entre sub-sistemas.

• Identifica distintos tipos de componentes funcionales del modelo.

Arquitectura de un Sistema de Control de Tráfico Aéreo



COMPONENTES FUNCIONALES DEL SISTEMA

• Componentes de censores.

o Obtiene información del ambiente del sistema, p.e.j. radares del

sistema de control de tráfico aéreo.

• Componentes de actuadores.

o Componentes que causan algún cambio en el ambiente del

sistema. P.ej. las válvulas en el proceso de control del sistema

que incrementa o decrementa el flujo de control de un ducto.

• Componentes de cómputo.

o Lleva a cabo cómputo de algunas entradas recibidas para

producir salidas. P.ej. el procesador de punto flotante del sistema.

• Componentes de comunicaciones

o Permite comunicar distintos componentes del sistema entre sí.

P.ej. los enlaces entre un sistema de cómputo distribuido.

• Componentes de control

o Coordina la interacción de los componentes del sistema. P.ej. el

planificador en un sistema en tiempo real.

• Componentes de interfaces.

o Facilita la interacción entre los componentes del sistema. P.ej.

interfaz del operador.



Todos los componentes son usualmente controlados por software.

FACTORES HUMANOS

• Todos los sistemas tienen usuarios y son utilizados en un contexto social

y organizacional.

• Es necesaria una interfaz de usuario apropiada para un control de

operación efectivo.

• Los factores humanos son con frecuencia un factor que determina el

éxito o el fracaso de un sistema.

• Cambios en el proceso de trabajo causa problemas.

• Habilidades de los usuarios.

• Cambios introducidos en la organización.

RESUMEN

• La Ingeniería de Sistemas es difícil. Nunca habrá una respuesta fácil en

la solución de problemas de desarrollo de sistemas complejos.

• Los Ingenieros de Software no tienen respuesta a todas las preguntas,

pero entienden el funcionamiento del sistema.

• Se debe de reconocer el papel que juega cada disciplina y cooperar

entre todas en el proceso de Ingeniería de Sistemas.

• La Ingeniería de Sistema involucra a múltiples disciplinas.

• El Proceso de I.S sigue a menudo el modelo de cascada.



PROPUESTA TECNOLÓGICA

Por lo general se hace referencia a las soluciones integrales a partir de un

análisis global de las necesidades de los clientes.

A continuación presentaremos algunos Casos Prácticos:

PLAN DE ACTUALIZACIÓN TECNOLÓGICA

Cliente

Por lo general el sector Universidades.

Necesidades

El cliente por lo general plantea la necesidad de modernizar las infraestructuras

informáticas, de acuerdo con su planificación estratégica, alrededor de un Plan

de Actualización Tecnológica donde se identifiquen, estructuren y prioricen

diversos proyectos. Dichos proyectos no deben contemplarse de forma aislada

sino dentro de un marco operativo global.

Descripción del proyecto

Realizar sesiones de consultoría, en las que se evalúan las necesidades de la

Universidad y se estudian las distintas soluciones alternativas, se diseña dicho

Plan, englobando un conjunto de proyectos de implantación de nuevas

soluciones e infraestructuras de sistemas.

1. Implantación de Directorio Activo y autenticación en plataforma

heterogénea Linux-Microsoft a través de LDAP.

2. Implantación de nueva infraestructura de correo electrónico para

Alumnos, Personal Administrativo y Personal Docente basada en

Exchange 2000.

3. Implantación del servicio de servidores de ficheros y servidores FTP en

Linux.

4. Implantación y puesta en marcha de Sistema Antivirus TrendMicro.

5. Implantación de servicios de Proxy ISA server.

6. Actualización de plataforma hardware de servidores.



7. Solución SAN y Backup con ArcServe.

8. Gestión de Contenidos ContentManager - SharePointPortal Server.

Probables beneficios:

• Reducción del tiempo necesario para la incorporación de nuevos

servicios destinados a alumnos, personal docente y personal

administrativo.

• Mejora del nivel de servicio, la calidad, las prestaciones y

capacidades de los servicios ya existentes.

En definitiva, se produciría una mejora de los servicios del alumnado y de la

calidad de la docencia.

CONSULTORIA EN TECNOLOGIAS DE LA INFORMACIÓN Y LA

COMUNICACIÓN

Cliente

Sector - Distribución Comercial

Necesidades

La empresa objeto de estudio se plantea la actualización de sus sistemas

informáticos para modernizar sus infraestructuras y mejorar sustancialmente

las prestaciones que ahora se ofrecen a los usuarios en cuanto a fiabilidad,

integración entre aplicaciones y seguridad.


Teniendo en cuenta el propio Plan Estratégico del cliente, se enfoca dicha

actualización tecnológica según la misión y visión corporativa y en la dirección

de los ejes de actuación establecidos a corto y medio plazo.

Se plantean los objetivos preliminares en cuanto a:

• Conocer y evaluar la situación actual de las infraestructuras y los

servicios que brinda el Departamento de Informática, así como los

procesos y los recursos asociados, para identificar y establecer



una valoración de requisitos y necesidades a las que dar

respuesta con la posterior elaboración de soluciones alternativas

de actualización tecnológica.

• Diseñar un Plan de Actualización Tecnológica, que como

solución, incorpore la identificación de proyectos viables que den

respuesta a las necesidades de modernización y actualización de

infraestructuras, así como la integración y prestación de nuevos

servicios ofrecidos a los integrantes de la empresa.

Dichos objetivos se elaboran y materializan mediante estándares de auditoría y

técnicas de consultoría que permitirán al mismo cliente establecer según sus

necesidades el entorno óptimo para su caso empresarial, siendo ayudado por

el equipo consultor, el cual guiará objetivamente todas las partes del proceso.

CONSULTORÍA DE INFRAESTRUCTURAS INFORMÁTICAS

Cliente

Sector - Ingeniería y Construcción

Necesidades

En este caso empresarial, existe una clara intención por parte del cliente en

cuanto a actualizar el entorno de sus infraestructuras informáticas, tanto a nivel

de sistemas como en comunicaciones y seguridad. Se requiere de soporte

experto externo para la propuesta de soluciones tecnológicas.


El planteamiento de la consultoría es relativo al estudio de las infraestructuras

informáticas para la posterior prescripción de los proyectos tecnológicos

adecuados.

Se establecen los siguientes ámbitos de actuación:

• Infraestructura de Sistemas

• Infraestructura de Comunicaciones

• Infraestructura de Seguridad



• Infraestructura de Mensajería

• Procesos de Negocio

Analizando las amenazas, debilidades, fortalezas y oportunidades detectadas

en el escenario, así como los distintos procesos empresariales considerados

como relevantes, se prescriben las soluciones y proyectos adecuados a las

necesidades preestablecidas.

CONSULTORÍA DE TECNOLOGÍAS DE LA INFORMACIÓN Y LA

COMUNICACIÓN

Cliente

Sector - Consultoria Inmobiliaria

Necesidades

Se pretende optimizar la plataforma de sistemas de información y

comunicación, siendo el propio cliente el impulsor de una auditoria que permita

conocer su estado de la forma más completa y precisa posible.


La propuesta de soluciones parte del estudio de la infraestructura, en donde se

auditan los siguientes ámbitos:

• Seguridad

• Infraestructuras de TI

• Sistemas de Información

Después de la captación de datos y de su posterior análisis se procede a la

evaluación de los entornos objeto de estudio y a la elaboración de propuestas

que garanticen un óptimo funcionamiento de los sistemas informáticos,

basándose las mismas en los puntos siguientes:

• Plan de seguridad

• Consolidación de infraestructuras

• Integración de aplicaciones



ESTÁNDARES DE LA CALIDAD

¿QUE ES UN SISTEMA DE GESTION DE LA CALIDAD?

• Es el sistema de gestión para dirigir y controlar una organización con

respecto a la calidad (ISO 9000:2000).

• Es el conjunto de elementos interrelacionados de la organización que

trabajan coordinados para establecer y lograr el cumplimiento de la

política de calidad y los objetivos de calidad, generando

consistentemente productos y servicios que satisfagan las necesidades

y expectativas de sus clientes.

REQUISITOS DEL CLIENTE

• De los productos o servicios que le suministremos, esa satisfacción la va

a buscar en la Calidad, o lo que es lo mismo en:

o Las características y los requisitos (Satisfacción de su función).

o La entrega a tiempo (Satisfacción de tenerlo cuando lo necesita).

o El precio (Satisfacción de poderlo adquirir).

PROCESO DE GESTIÓN DE LA CALIDAD

SISTEMAS DE GESTIÓN DE LA CALIDAD

Evidenciar

“Proveer confianza, como resultado de demostrar, en el producto y/o servicio la

conformidad con los requisitos establecidos”



ISO 9004: 2000

PRINCIPIOS DE GESTIÓN DE LA CALIDAD

1. Organización enfocada a los clientes.

2. Liderazgo.

3. Compromiso del personal.

4. Enfoque de procesos.

5. Enfoque de Sistemas para la Gestión.

6. Mejora Continua.

7. Decisiones basadas en hechos.

8. Relaciones de mutuo beneficio con proveedores

1.- ORGANIZACIÓN ENFOCADA A LOS CLIENTES

• Las Organizaciones dependen de los clientes, estas deberían

comprender sus necesidades actuales y futuras.

• El éxito es superar las expectativas del cliente.

2.- LIDERAZGO

• Los líderes establecen la unidad de propósito y la orientación de la

Organización.

• Los líderes deberían crear y mantener un ambiente interno, donde el

personal logre involucrarse en el logro de los objetivos de la

Organización.

3.- COMPROMISO DEL PERSONAL

• El personal en todos los niveles es la esencia de la Organización.

• Un Personal comprometido posibilita que sus habilidades y competencia

sean utilizadas en beneficio de la Organización.



4.- ENFOQUE DE PROCESOS

• Los resultados deseados son alcanzados más eficientemente si las

actividades y recursos se gestionan como procesos.

5.- ENFOQUE DE SISTEMAS PARA LA GESTIÓN

• Identificar las actividades, procesos y su interrelación dentro de la

Organización.

• Cumplir con el concepto de Sinergia.

6.- MEJORA CONTINUA

• Las Mejora Continua del desempeño de la Organización debe ser un

objetivo permanente de ésta.

7.- DECISIONES BASADAS EN HECHOS

• Las decisiones eficaces se basan en el análisis de los datos y la

información.

8.- RELACIONES DE MUTUO BENEFICIO CON LOS PROVEEDORES

• Los Proveedores y las Organizaciones son interdependientes, se puede

crear una red de mayor valor agregado.

ISO 9001: 2000 - CAMBIOS EN LA ESTRUCTURA DE LA NORMA

ESTRUCTURA BASADA EN PROCESOS

• Sistema de Gestión de Calidad

o Manual de Calidad, Documentación, Registros

• Responsabilidad directiva

o Política, objetivos, planeación, sistema, revisión

• Recursos

o Recursos Humanos, infraestructura, instalaciones



• Realización de Producto y/o servicios

o Cliente, diseño, compras, producción, ajustes

• Medición, análisis y mejora

o Auditorias, control de procesos y productos, mejora.

MODELO BÁSICO DE PROCESOS

MODELO DEL PROCESO DE UNA ORGANIZACIÓN

REQUISITOS PARA EL PRODUCTO

REQUISITOS PARA EL SISTEMA DE CALIDAD


Propios de cada producto

• Cliente• Organización• Normas obligatorias

• Especificaciones de producto.• Especificaciones de proceso.• Otras especificaciones técnicas.• Acuerdos contractuales.• Requisitos reglamentarios.

Determinados por: Están contenidos en:

Genéricos y aplicables a cualquier organización

• Elementos del sistema• Procesos Necesarios• Características operativas

Normas para Sistemas de Calidad

Especifican: Están contenidos en:


GESTIÓN DE LA CALIDAD MODELO DE PROCESOS - ISO 9001:2000

REQUISITOS GENERALES

• Manual de Calidad.

• Procedimientos Requeridos.

• Procedimientos de la API.

• Planes de Calidad.

• Formatos.

• Registros.

RESPONSABILIDAD DE LA DIRECCIÓN

Compromiso de la Dirección

La Alta Dirección debe tener compromiso con el Sistema de Gestión de la

Calidad y su mejora continua:

• Comunicando a la organización la importancia del cumplimiento de los

requisitos .



• Estableciendo su Política de Calidad.

• Estableciendo sus objetivos de Calidad.

• Revisar el Sistema de Calidad.

• Proporcionado los recursos Adecuados.

ENFOQUE AL CLIENTE

• La Alta Dirección debe asegurarse que se cuenta con un enfoque al

cliente.

• Importante como nos aseguramos que entendemos las necesidades de

los Clientes. P.ej. (Se audita en el Departamento Comercial cuando se

revisa el Requisito 7.2).

POLÍTICA DE LA CALIDAD

La Alta Dirección debe asegurar que la política de la Calidad: P.ej:

“...Las administraciones portuarias integrales, se comprometen a gestionar y

lograr el desarrollo del puerto:

• Promoviendo el uso, aprovechamiento y explotación de los instalaciones

del gobierno federal ubicadas en el recinto.

• Construyendo obras, terminales, marinas, instalaciones y servicios

portuarios, así como proporcionando los recursos necesarios,

infraestructura efectiva y segura.

• Satisfaciendo las necesidades de nuestros clientes, a través de la

supervisión de los servicios cesionados y brindando un eficaz servicio

administrativo, a través de la mejora continua de nuestros procesos y de

la implementación del sistema de gestión de calidad NMX-CC-9001-

IMNC-2000 / ISO-9001:2000...”



PLANIFICACIÓN

Objetivos de la Calidad

La Alta Dirección debe establecer sus objetivos de Calidad que sean medibles,

cuantificables y consistentes con la política de Calidad.

Planificación del Sistema de Gestión de la Calidad

La Alta Dirección debe asegurar que:

• Se planea la implantación del Sistema de Gestión de Calidad.

• Se planean los cambios al sistema de Gestión de Calidad.

Debemos asegurar que el proceso de planeación y transición del Sistema se

lleve de Acuerdo a lo planeado.

Responsabilidad, autoridad y comunicación

Responsabilidad y autoridad

La Alta Dirección debe asegurar que las responsabilidades, autoridades sean

definidas y comunicadas dentro de la organización.

Representante de la dirección

La Alta Dirección debe definir a un representante con responsabilidad y

autoridad para:

• Asegurar que se implementa el Sistema de Gestión de la Calidad.

• Mantener informada a la Dirección.

• Asegurar que se tiene el enfoque al cliente en todos los niveles de la

Organización.

Comunicación interna

La Alta Dirección debe asegurarse de una comunicación efectiva dentro de la

Organización.



Nos van a Auditar que los proceso de comunicación se encuentren bien

definidos, por ejemplo que se envié la información, que se confirme la

recepción y si existe la respuesta, como se dio esta.

Revisión por la dirección

Generalidades

Deben llevarse a cabo Revisiones por la Alta Dirección en intervalos

planificados para:

• Asegurar la continua consistencia adecuación y efectividad del SGC.

• Visualizar oportunidades para mejora.

• Determinar la necesidad de cambios.

• Revisar la política de Calidad.

• Monitorear los objetivos.

• Generar y mantener registros de las revisiones.

Entradas para la revisión

La información a ser usada en la revisión de la Alta Dirección es:

• Los resultados de auditorias;

• Retroalimentación de los clientes;

• Desempeño de los procesos y conformidad del producto;

• Situación de las acciones correctivas y preventivas;

• Seguimientos de las acciones derivadas de las revisiones anteriores de

la dirección;

• Cambios planeados que podrían afectar al Sistema de Gestión de la

Calidad;

• Recomendaciones de mejora;



Salidas de la revisión

Los resultados de la revisión por la Alta Dirección deben incluir decisiones y

acciones asociadas a:

• Mejora de la efectividad del Sistema de Gestión de la Calidad y sus

procesos;

• Mejora del producto en relación con los requisitos del cliente; y

• Necesidades de recursos.

Gestión de los recursos

ISO nos solicita que determinemos los recursos necesarios para operar con

calidad y de esa manera será más probable lograr la satisfacción del cliente.

• Provisión de recursos.

• Recursos Humanos.

• Infraestructura.

• Ambiente de trabajo.

Realización del producto

• Planificación de la Realización del producto.

• Procesos Relacionados con los Clientes.

• Diseño y Desarrollo.

• Compras.

• Prestación del Servicio.

• Control de Equipos.



Mediciones, análisis y mejora

Nos pide que establezcamos procesos de inspección y supervisión para

demostrar en todo momento la conformidad del servicio, del sistema de gestión

y de la mejora continua.

Supervisión y Medición

• Satisfacción del cliente.

• Auditoria Interna.

• Supervisión de procesos.

• Inspección de Servicio.

Control de Servicio no Conforme

Análisis de Datos

Mejora

• Mejora Continua.

• Acciones Correctivas.

• Acciones Preventivas.



SISTEMAS DE INFORMACIÓN

GLOSARIO

DATO.- Representación de un hecho.

INFORMACIÓN.- Conjunto de datos organizados.

INFORMATICA.- Ciencia encargada del tratamiento racional y automático de la

información.

SISTEMA.- Conjunto integrado y ordenado de partes que propenden por un fin

común.

SISTEMA DE INFORMACION

Ente que recibe datos y los transforma en información.

SISTEMA DE INFORMACION: Visión de implementación


ProcesosDatos

Desorden, entropía Neguentropía Orden

Información

ProcesosDatos

Estructuras de datos Estructuras de datos

Información

Estructuras de control, algoritmos


El doctor Niklaus Wirth (1970) creador del lenguaje Pascal, plantea la siguiente

ecuación:

Programas = Estructuras de datos + Estructuras de control

MODELO CONTEMPORÁNEO

“Un sistema de información definido técnicamente es un conjunto de

componentes interrelacionados que recopilan, procesan, almacena y distribuye

información para soportar la toma de decisiones y el control en la

organización”. Laudon & Laudon

SISTEMA DE INFORMACIÓN

ELEMENTOS DE ESTE MODELO

Dato Información Entrada

Procesamiento Salida Retroalimentación

DEFINICIÓN DE NEGOCIOS

“Los sistemas de información son una solución organizacional y administrativa,

basada en TI que cambiará conforme cambie el ambiente”.



MODELO

ORGANIZACIÓN

El elemento clave en una organización es su gente, para poder integrar a la

gente a los sistemas de información es necesario el también entender:

• Como esa gente trabaja y como trabaja la organización.

• Estructura organizacional.

• Las relaciones jerárquicas y de control.

• Los procedimientos de operación

PIRÁMIDE DE HABILIDADES Y GENTE



ADMINISTRACIÓN

• Las estrategias que nos ayudan a lograr el propósito de la organización.

• La administración incluye el como manejar los recursos con los que se

cuenta.

• No solo se plantea la estrategia se debe establecer el como llegar a ella.

TECNOLOGÍA

• Hardware

• Software

• Tecnología de almacenamiento

• Tecnología de comunicaciones

ENFOQUE SOCIOTÉCNICO DE LOS SI

ENFOQUE DE NEGOCIOS

• Entender a los Negocios como un sistema.

• Debemos entender a un sistema como un conjunto de componentes que

interactúan entre si para lograr un propósito.



• Debemos entender a un subsistema como un componente de un

sistema.

COMO UNA EMPRESA ES UN SISTEMA

OTROS COMPONENTES

Además de los componentes tradicionales de sistemas encontramos:

• Los sistemas tienen propósitos.

• Los sistemas tienen fronteras.

• Los sistemas trabajan en un ambiente.

• Los sistemas se basan en sus entradas para generar salidas

SISTEMAS DE INFORMACIÓN Y LOS SISTEMAS DE TRABAJO

• Es muy común el utilizar el mismo termino dar el mismo significado a los

términos.

• Tecnología de Información, Sistemas de Información y Sistemas de

trabajo.

• Debemos definir cada termino.

TI, SI y WS


CLIENTES

PROVEEDORES

DISEÑO DEPRODUCTO PRODUCCIÓN VENTAS ENTREGAS SERVICIO

PREFERENCIAS

ORDENES

BIENSERVICIO

SOLICITUDDE SERVICIO

ORDEN

COMPRAS

BIEN SERVICIOTERMINADO

DISEÑO ORDENPROD

EMPRESA

AMBIENTE DE NEGOCIOS

FIRMA

SI

WS

TI


TECNOLOGÍA DE INFORMACIÓN

Es el hardware y el software usado por los sistemas de información.

SISTEMA DE INFORMACIÓN

Es un tipo particular de sistema de trabajo que usa tecnología de información

para capturar, transmitir , almacenar, manipular y desplegar información que

soportan uno o más sistemas de trabajo.

SISTEMA DE TRABAJO

• Es un sistema en el que las personas participantes desempeñan el

proceso de negocios usando la información, la tecnología y otros

recursos para producir productos para clientes internes o externos.

• La base de un sistema de trabajo es el proceso de negocios el cual

consiste el una serie de pasos ubicados en un lugar en el tiempo y

espacio, que tienen un principio y un fin, que tiene entradas y genera

salidas.

TRABAJO

Por trabajo no se refiere a lo que la gente hace en el día, se refiere a la

aplicación de los recursos humanos y físicos como gente, equipo, tiempo,

esfuerzo y dinero en generar salidas que serán usadas por clientes externos o

internos.

FIRMA

La firma o empresa consiste en la interrelación de sistemas de trabajo los

cuales operan para generar los productos o servicios para los clientes externos

que se encuentran en el ambiente de negocios.



AMBIENTE DE NEGOCIOS

Incluye a la misma empresa o firma y todo lo que afecta su éxito como:

competidores, proveedores, clientes, Instituciones reguladoras, condiciones

sociales, demográficas y económicas.

ROLES DE LOS SI Y WS

WORK-CENTERED ANALYSIS WCA

• Es un esquema que nos permite identificar como un sistema de trabajo

es soportado por un sistema de información.

• Este esquema combina recursos como Administración de la calidad,

reingeniería de procesos y teoría general de sistemas.

• Consiste en 6 elementos interrelacionados.

ELEMENTOS DE WCA

• Clientes internos o externos al sistema de trabajo.

• Productos o Servicios Generados por el sistema de trabajo que el cliente

recibirá.

• Los pasos del proceso de negocios.

• Los participantes en el sistema de trabajo.

• La información que el sistema de trabajo utiliza o genera.

• La tecnología que el sistema de trabajo usa.


• Scanner de código de barras captura los productos y calcula la cuenta.

• Sistema de identificación de empleados que analiza voz.

• Ejecuta la transacción con el cliente.

• Prevé que una persona no autorizada acceda un área.


SISTEMA DE INFORMACION ORIENTADA A OBJETOS

GENERALIDADES

Por qué Modelamos?

El modelado es una técnica de hacer modelos, que ofrece una visión global del

sistema.

Importancia de Modelar

• Permite visualizar y especificar la estructura.

• Proporcionan plantillas y

• Documentan decisiones.

Principios del Modelado

• La elección de qué modelos crear, y dar forma a una solución.

• Todo modelo puede ser expresado a diferentes niveles de precisión.

• Los mejores modelos están ligados a la Realidad.

• Un único modelo no es suficiente.



Modelado orientado a objetos

UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la

cual permite:

• Especificar

• Construir

• Visualizar

• Documentar... Los objetos de un sistema.

DISEÑO DE SOFTWARE

CONTENIDO

• Conceptos básicos de Ingeniería de Software

o Proceso de desarrollo. Actividades

• Conceptos básicos de orientación a objetos

o Abstracciones. Orientación a objetos

• Metodologías de diseño

o Diseño basado en abstracciones. Diseño orientado a objetos.

o Metodología: Booch (Booch), Rumbaugh (OMT),

Jacobson (OOSE), Coad-Yourdon (OOA/OOD)

• Casos de estudio

PROCESO DE DESARROLLO DE SOFTWARE

Actividades (ciclo) de desarrollo


Análisis

Diseño

Codificación

Integración

Mantenimiento


DESARROLLO EVOLUTIVO DE SOFTWARE

• Inconvenientes del modelo en cascada

o Rígido, es muy costoso rectificar

o La documentación inicial suele quedar obsoleta

• Modelos de desarrollo evolutivo

o Ciclo de vida espiral

o Uso de prototipos

o Programación extrema (Extreme Programming)

o Desarrollo ágil

• Cambia el proceso, pero no las actividades

ANÁLISIS

• Entrada

o Conocimiento del dominio de la aplicación, actividades de los

usuarios, mercado, etc.

• Actividades

o Identificar las necesidades del usuario

o Análisis de viabilidad

o Determinar los requisitos de la aplicación

• Salida

o Documento de requisitos del software



DISEÑO

• Entrada

o Documento de requisitos del software

• Actividades

o Establecer una(s) estrategia(s) de solución

o Análisis de alternativas. Formalizar la solución

o Descomponer y organizar la aplicación

o Fijar descripciones de cada módulo

• Salida

o Documento de diseño del software

CODIFICACIÓN

• Entrada

o Documento de diseño del software

• Actividades

o Creación del código fuente

o Pruebas de unidades

• Salida

o Código de módulos, probado

INTEGRACIÓN. VALIDACIÓN

• Entrada

o Código de módulos, probado

o Documento de requisitos del software (validación)

• Actividades

o Pruebas de integración

o Pruebas de validación

• Salida



o Aplicación completa, lista para usar

PROYECTO

Actividades a desarrollar

ABSTRACCIONES

• Abstracciones

o Implementan determinados servicios, ocultando los detalles. Se

usan conociendo su interfaz

• Abstracciones funcionales

o Funciones y acciones

o Realizan una operación

• Tipos abstractos de datos

o Agrupan un tipo de datos con sus operaciones

o Ocultan la representación de los datos

CLASES Y OBJETOS

• Clases

o Definen un tipo de objetos y sus operaciones


Análisis

Diseño

Codificación

Integración

Mantenimiento

Pruebas de integración

Diseño modular

Codificación y pruebas de unidades


o Coinciden en esencia con tipos abstractos de datos

o La clase oculta los detalles de implementación

o Atributos: contenido de información de los objetos

o Métodos: operaciones sobre los objetos

o Mensajes: invocación de las operaciones

• Objetos

o Datos de una determinada clase

HERENCIA

• Concepto: especialización

o Define una clase particular (subclase o clase hija) a partir de otra

clase general (superclase o clase padre)

o La subclase hereda los atributos y métodos de la superclase, y

puede tener otros nuevos

o También se pueden redefinir métodos

o Ejemplo: fecha => fecha_y_hora

• Subclases como subtipos: sustitución

o Imprimir_Calendario( fecha )

o Imprimir_Calendario( fecha_y_hora )

DISEÑO ORIENTADO A OBJETOS

• Descomposición y organización en partes

o Partes = clases o abstracciones

o Organización: estructura del conjunto

• Relaciones entre clases

o Agregación: objetos que contienen otros objetos



o Uso: clases que utilizan otras clases

o Herencia: clases especializadas

o Otras relaciones: modelo de datos.

Ejemplo: paciente padece enfermedad

DIAGRAMAS DE CLASES

DESCOMPOSICIÓN MODULAR

• Módulo: agrupación de elementos

o Clases, tipos, constantes, objetos, etc.

• Acoplamiento

o Ligaduras o interferencias entre módulos

o Deseable bajo acoplamiento (independencia)

o Ejemplo: No usar variables globales por su nombre

• Cohesión

o Relación entre los elementos de un módulo

o Deseable alta cohesión

o Ejemplo: Módulos que sean clases o TADs


Clase

Atributos

MétodosHerencia

Uso

Agregación


DIAGRAMAS MODULARES

METODOLOGÍA DE DISEÑO

• Evaluar y comprender la especificación

• Idear una estrategia de solución, informal

• Formalizar la estrategia

• Validar el modelo: escenarios, etc.

• ¿Hay elementos complejos? Iterar

• Diseño detallado

• Formalizar la estrategia

o Identificación de entidades (clases, métodos, ...)

o Agrupar métodos en clases

o Identificar y asignar responsabilidades

o Identificar relaciones entre clases

o Refinar las clases

• Diseño detallado

o Definir atributos, argumentos de las operaciones, ...


Dibujar

Curva_C

Pluma

Papel

Uso

Papel

- Crear- PonerEnBlanco- MarcarHorizontal- MarcarVertical- Imprimir

Papel

- Crear- PonerEnBlanco- MarcarHorizontal- MarcarVertical- Imprimir

Pluma

- Crear- Poner- Avanzar- GirarDerecha- GirarIzquierda

Pluma

- Crear- Poner- Avanzar- GirarDerecha- GirarIzquierda

Dibujar


o Codificar interfaces (código Ada, C++, Java, ...)

REUTILIZACIÓN

• Componentes

o Librerías, genéricos, etc.

• Esquemas de arquitectura (Frameworks)

o Módulos fijos, ya definidos

o Módulos específicos, a crear en cada caso

• Patrones de diseño

o Esquemas conocidos (no reinventar la rueda)

o E.Gamma, R.Helm, R.Johnson, J.Vlissides: Design Patterns: ... -

(“la banda de los cuatro”)

• Ejemplo: Modelo-Vista-Controlador (MVC)

LENGUAJES DE PROGRAMACIÓN

AGENDA

• Computadoras

• Programas

• Lenguajes de Programación

COMPUTADOR

Máquina electrónica, analógica o digital, dotada de una memoria de gran

capacidad y de métodos de tratamiento de la información, capaz de resolver

problemas matemáticos y lógicos mediante la utilización automática de

programas informáticos. (Real Academia Española).



Elementos de un Computador

• Hardware: dispositivos y circuitos electrónicos

o CPU, Memorias (RAM, Discos Duros),Tarjeta Madre, etc.

• Software: programas computacionales capaces de realizar alguna tarea

a través de instrucciones que el hardware es capaz de procesar.

o Sistemas Operativos (linux, windows, MAC, OS/2), Driver’s,

aplicaciones usuarias (word, excel, outlook, msn, flash).

o Internet: navegadores (Explorer, Opera, Mozilla, Netscape).

Hardware


NºPCI’s, Bus, AGP, Integraciones, Capacde ampliación, Marca,Chipset, USB’s

Dispositivo electrónico encargado de integrar todos los periféricos (procesador, memorias, tarjetas adicionales, etc). Funciones: Conexión física. Administración, control y distribución de energía eléctrica. Comunicación de datos. Temporización. Sincronismo. Control y monitoreo.

Tarjeta o Placa Madre

Velocidad (RPM)Capacidad de almacenamiento

Memoria de lectura y escritura encargada de almacenar archivos de datos. “Almacenamiento Eterno” (siempre y cuando no le ocurra algún deterioro o falla física).

Disco Duro

Velocidad (Ciclos/s)Capacidad de almacenamiento

Memoria de lectura y escritura que se utiliza normalmente como memoria temporal para almacenar resultados intermedios y datos no permanentes. Almacenamiento Volátil.

RAM

Ancho de Banda

Conectan la CPU a los dispositivos de almacenamiento (por ejemplo, un disco duro), los dispositivos de entrada (por ejemplo, un teclado o un mouse) y los dispositivos de salida (por ejemplo, un monitor o una impresora).

Buses de Datos

Velocidad (Ciclos/s)Circuito microscópico que interpreta y ejecuta instrucciones. Encargado de procesar los datos.CPU

Características Importantes

DefiniciónDispositivo

NºPCI’s, Bus, AGP, Integraciones, Capacde ampliación, Marca,Chipset, USB’s

Dispositivo electrónico encargado de integrar todos los periféricos (procesador, memorias, tarjetas adicionales, etc). Funciones: Conexión física. Administración, control y distribución de energía eléctrica. Comunicación de datos. Temporización. Sincronismo. Control y monitoreo.

Tarjeta o Placa Madre

Velocidad (RPM)Capacidad de almacenamiento

Memoria de lectura y escritura encargada de almacenar archivos de datos. “Almacenamiento Eterno” (siempre y cuando no le ocurra algún deterioro o falla física).

Disco Duro

Velocidad (Ciclos/s)Capacidad de almacenamiento

Memoria de lectura y escritura que se utiliza normalmente como memoria temporal para almacenar resultados intermedios y datos no permanentes. Almacenamiento Volátil.

RAM

Ancho de Banda

Conectan la CPU a los dispositivos de almacenamiento (por ejemplo, un disco duro), los dispositivos de entrada (por ejemplo, un teclado o un mouse) y los dispositivos de salida (por ejemplo, un monitor o una impresora).

Buses de Datos

Velocidad (Ciclos/s)Circuito microscópico que interpreta y ejecuta instrucciones. Encargado de procesar los datos.CPU

Características Importantes

DefiniciónDispositivo


Unidades

Software

Programas computacionales capaces de trabajar con datos.

• Sistemas Operativos (linux, windows, MAC, OS2), Driver’s, aplicaciones

usuarias (word, excel, outlook, msn, flash).

• Internet: navegadores (Explorer, Opera, Mozilla, Netscape).

Elementos de un Computador


1024 GBTB1 TeraByte

1024 MBGB1 GigaByte

1024 KBMB1 MegaByte

1024 B = 210 B KB1 KiloByte

B

b

Abreviación

8 bit’s = 1 Byte

0 ó 11 Bit

EquivalenciaUnidad

1024 GBTB1 TeraByte

1024 MBGB1 GigaByte

1024 KBMB1 MegaByte

1024 B = 210 B KB1 KiloByte

B

b

Abreviación

8 bit’s = 1 Byte

0 ó 11 Bit

EquivalenciaUnidad

Procesador

Memoria Corto Plazo

Entradas Salidas

Memoria Largo Plazo

TecladoMouseSensores

PantallaImpresoraAudio

Disco DuroDisketeraCD

RAMTipo VonNeumann


PROGRAMAS


Hardware

S.O.

AplicacionesUsuarias

Soporte

BIOS

Nuestro quehacerNuestro

quehacer

Software


Aplicaciones Usuarias

• Programas computacionales utilizados por usuarios en general.

Generalmente se ejecutan bajo interfaces gráficas (ventanas).

• Productos Office, Explorer, Autocad, Encarta, Nero, Emacs, Gedit.

Soporte

• Programas que conectan los periféricos con el SO y las aplicaciones

usuarias.

• Drivers, Codecs, Servicios Internet.

S.O.

• Es el administrador de recursos.

• Linux, Windows, Mac, OS/2

BIOS

• Programa que administra la Placa Madre.

• Cada Placa Madre tiene el suyo propio.

LENGUAJES DE PROGRAMACIÓN


S.O.

AplicacionesUsuarias

Soporte

BIOS

Se crean con lenguajes de programación



Yo entiendo este lenguaje

Yo entiendo este lenguaje

if(x=5) then

Begin

……

end


TIPOS DE LENGUAJES

• Lenguaje de Máquina: es el lenguaje propio del computador, basado en

el sistema binario (0 y 1). El programador debe introducir todos y cada

uno de los comandos y datos en forma binaria.

• Lenguaje de Bajo Nivel: mínima abstracción de instrucciones en 0 y 1 a

palabras claves como ADD, STORE, JUMP. Permite crear programas

muy rápidos, pero no son portables.

• Lenguaje de Alto Nivel: representan una mayor abstracción, en donde

los signos que utiliza son más cercanos al lenguaje natural.

BREVE HISTORIA DE LOS LENGUAJES DE ALTO NIVEL

• …años 50’: el estadounidense Grace Hopper crea UNIVAC I y UNIVAC

II, FLOW- MATIC.



• 1954: FORTRAN (Formula Translator), by IBM.

• 1958: ALGOL (Algorithmic Language), LISP.

• 1959: COBOL (Common Business Oriented Language)

• 1962: SNOBOL

• 1964: SIMULA, BASIC

• 1969: SMALLLTALK

• 1970: PASCAL, PROLOG

• 1971: C

• 1980: C con clases

• 1983: C++

• 1986: Eiffel

• 1987: Perl

• 1991: Python, Oak, Visual Basic

• 1995: JAVA, PHP, DELPHI, VBScript, Jscript

• 2000: VB.NET

COMPILADOR

Programa que convierte el lenguaje informático creado por el usuario en

lenguaje propio del computador.

• Revisión Sintáctica

• Revisión Semántica

• Creación del ejecutable



ANEXOS

NIVELES DE PROGRAMACIÓN



PROGRAMAS DE PROCESO

Esquema general del proceso de traducción



PROCESO DE COMPILACIÓN

Compilación y montaje de un programa



Estructura general de un compilador



----------o----------



TECNOLOGÍA DE CALIDAD DEL SOFTWARE

EXPERIENCIAS PRÁCTICAS

AGENDA

• Introducción. Contexto Inicial.

• Plan de Mejora de Procesos. Necesidad.

• Modelo de desarrollo adoptado. Estrategia.

• Experiencias de Mejora de Procesos. Aplicación práctica de CMM.

• Proceso de Certificación de Software.

• Conclusiones.

INTRODUCCIÓN. Contexto Inicial

Casa de Software SIGTA

Empresa: Empresa de Telecomunicaciones de Cuba, S.A. ETECSA.

Misión: Comercializar productos de software de alto valor para la Gestión de los

Operadores de Telecomunicaciones y Servicios de excelencia en Ingeniería de

Software basados en estándares internacionales.

Líneas de Trabajo

• Plataforma de Gestión para Operadores de Telecom.



• Servicios de Ingeniería de Software.

PLAN DE MEJORA DE PROCESOS. Necesidad

Primer Paso Desarrollo de Software

Para conseguir un proceso de producción de software sin fallos, adecuado a

las necesidades estipuladas en un principio y entregado a tiempo, esta claro

que la producción de software debe convertirse en un proceso disciplinado y

aceptado por todos.

Los procesos definidos ayudan a la Planificación y desarrollo de un trabajo. El

proceso que establezcamos debe ser flexible y debe facilitar el cambio y la

innovación.

Modelos de Calidad

Por qué se usan los modelos de Calidad?


Tie

mpo

Costo

Calidad

Tie

mpo

Costo

Calidad

Tie

mpo

Costo

Calidad


MODELO DE DESARROLLO ADOPTADO. Estrategia


CMM (Capab i l i t y Mat ur i t y Mode l )

Modelo de Desar ro l lo

Modelo para medir la madurez de los procesos de software en una organización.

Nive l-2 (Repe t ib le)

N ive l de Madurez ac t ua l

Gestión de Requerimientos Planeamiento de Proyectos Seguimiento continuo de Proyectos Gestión de Subcontratos Aseguramiento de la Calidad de Software Gestión de Configuración

RUP (Rat iona l U n i f ied Proc ess)

Met odo logía de Desar ro l lo

UML (Uni f ied Mode l ing Lenguage)

Lenguaje de Modelac ión

Metodología basada en componentes que permite transformar los requerimientos de usuario en un sistema de software

Basada en Casos de Uso Arquitectura Centralizada Iterativa e Incremental

Permite preparar el material documental de un producto de software.

CMM (Capab i l i t y Mat ur i t y Mode l )

Modelo de Desar ro l lo

Modelo para medir la madurez de los procesos de software en una organización.

Nive l-2 (Repe t ib le)

N ive l de Madurez ac t ua l

Gestión de Requerimientos Planeamiento de Proyectos Seguimiento continuo de Proyectos Gestión de Subcontratos Aseguramiento de la Calidad de Software Gestión de Configuración

RUP (Rat iona l U n i f ied Proc ess)

Met odo logía de Desar ro l lo

UML (Uni f ied Mode l ing Lenguage)

Lenguaje de Modelac ión

Metodología basada en componentes que permite transformar los requerimientos de usuario en un sistema de software

Basada en Casos de Uso Arquitectura Centralizada Iterativa e Incremental

Permite preparar el material documental de un producto de software.


Estrategia de Implantación

• Auspicio de la máxima dirección de la Empresa.

• Entrenamiento (Universidad + Externo).

• Procesos definidos, documentados y usados (Políticas).

• Institucionalización del Proceso.



EXPERIENCIAS DE MEJORA DE PROCESOS. Aplicación práctica de CMM.

Etapas de un Proyecto de Software


Proceso puede repetir tareas exitosas previasGestión del proceso con el seguimiento de

costos, planificación y funcionalidad

KPAGestión de

Requerimientos

KPAPlanificación de

Proyectos

KPASeguimiento de

Proyectos

KPAAseguramientode la Calidad

KPAGestión de

Configuración

KPAGestión de

Subcontratos

~Nivel-2 Repetible

Proceso puede repetir tareas exitosas previasGestión del proceso con el seguimiento de

costos, planificación y funcionalidad

KPAGestión de

Requerimientos

KPAPlanificación de

Proyectos

KPASeguimiento de

Proyectos

KPAAseguramientode la Calidad

KPAGestión de

Configuración

KPAGestión de

Subcontratos

~Nivel-2 Repetible

~~Nivel-2 Repetible


Principales Tareas

• Especificar Requerimientos. Casos de Uso del Sistema.

• Definir Arquitectura del Sistema.

• Ejecución adecuada de las pruebas de calidad.



Roles implementados

• Jefe de Proyecto

• Arquitecto de Software

• Aseguramiento de la Calidad de Software

• Gestión de Configuración

• Implementación y Soporte

• Ingenieros de Software

• Ingenieros en Testing

Métricas Nivel-2 CMM


GerenciaCasa SIGTA

SubgerenciaDesarrollo

Subgerencia Implementación

Grupo Negociación y Marketing

Grupo-1 de

Proyectos

Grupo-2 de

Proyectos

Grupo-3 de

Proyectos

Grupo Control de

Calidad

Grupo Testing y

Empaquetado

Grupo Soporte e

Implement.

Estado de cada requerimiento aprobado.Actividad de cambio de cada requerimiento especificado.Cantidad de cambios acumulados (cambios propuestos, abiertos, probados, incorporados a la línea base del proyecto)

Término y cumplimiento de Hitos respecto al plan.Trabajo realizado, esfuerzo consumido, fondos gastados respecto al plan

Esfuerzos y recursos gastados en estas actividades.Actividades de cambio para el plan de desarrollo de software.

Costo de las actividades respecto al plan.Fechas reales de entrega respecto al plan.Fechas reales de envío al subcontratista respecto al plan.

Término y cumplimiento de Hitos respecto al plan.Trabajo realizado, esfuerzo consumido, fondos gastados respecto al planCantidad de auditorias y actividades revisadas respecto al plan

Número de requerimientos de cambio por unidad de tiempo.Término y cumplimiento de Hitos respecto al plan.Trabajo realizado, esfuerzo consumido, fondos gastados respecto al plan

Gestión deRequerimientos

Planificación deProyectos

Seguimiento y Control de Proyectos

Gestión deSubcontratos

Aseguramientode Calidad

Gestión dela Configuración

Estado de cada requerimiento aprobado.Actividad de cambio de cada requerimiento especificado.Cantidad de cambios acumulados (cambios propuestos, abiertos, probados, incorporados a la línea base del proyecto)

Término y cumplimiento de Hitos respecto al plan.Trabajo realizado, esfuerzo consumido, fondos gastados respecto al plan

Esfuerzos y recursos gastados en estas actividades.Actividades de cambio para el plan de desarrollo de software.

Costo de las actividades respecto al plan.Fechas reales de entrega respecto al plan.Fechas reales de envío al subcontratista respecto al plan.

Término y cumplimiento de Hitos respecto al plan.Trabajo realizado, esfuerzo consumido, fondos gastados respecto al planCantidad de auditorias y actividades revisadas respecto al plan

Número de requerimientos de cambio por unidad de tiempo.Término y cumplimiento de Hitos respecto al plan.Trabajo realizado, esfuerzo consumido, fondos gastados respecto al plan

Gestión deRequerimientos

Planificación deProyectos

Seguimiento y Control de Proyectos

Gestión deSubcontratos

Aseguramientode Calidad

Gestión dela Configuración


Gestión de Requerimientos

• Requerimientos del Negocio.

• Requerimientos del Usuario.

o Requerimientos Funcionales.

o Requerimientos No Funcionales.

• Experiencia práctica: Independizar Levantamiento de Requerimientos.

Gestión de Configuración


Porcentaje de fuentes de errores en las etapas de desarrollo de software.

Requisitos 56 %

Otros 10 %

Construcción7 %

Diseño 27%

Bibliotecade

Programación

Bibliotecade

Calidad

PROMOCION

INSTALACIONBibliotecade

Producción

LIBERACION

IC NC LCAó

Desarrollo Aseguramiento de la Calidad / Control de la Configuración Operación

REMOCION

Se detecta un defecto

RCAnálisis y evaluación del cambio

RCApr.

REMOCION

Se autoriza un cambio

Solicitud de cambio

Interno Externo

Bibliotecade

Programación

Bibliotecade

Programación

Bibliotecade

Calidad

PROMOCIONBiblioteca

de Calidad

PROMOCION

INSTALACIONINSTALACIONBibliotecade

Producción

LIBERACION

IC NC LCAó

Bibliotecade

Producción

LIBERACION

IC NC LCAó

Desarrollo Aseguramiento de la Calidad / Control de la Configuración Operación

REMOCION


REMOCION


RCRCAnálisis y evaluación del cambio

Análisis y evaluación del cambio

RCApr.RCApr.

REMOCION


REMOCION


Solicitud de cambio

Interno Externo

Solicitud de cambio

Interno Externo


Aseguramiento de la Calidad

Experiencia práctica:

• SQA en todo el Proceso.

• Especialista de Testing incorporados en las etapas iniciales del

Proyecto.

PROCESO DE CERTIFICACIÓN DE SOFTWARE

La certificación de Software aporta una colaboración invalorable a las

empresas participantes de una licitación internacional.


Administración de la Calidad del Software (Dirigir y controlar )

SQA (Incluye CC en todas las etapas)

R: Requerimientos

A: Análisis

D: Diseño

C: Codificación

P: PruebasCC

R A D C P

CC CC CC CC

Administración de la Calidad del Software (Dirigir y controlar )

SQA (Incluye CC en todas las etapas)

R: Requerimientos

A: Análisis

D: Diseño

C: Codificación

P: PruebasCCCCCC

R A D C PRR AA DD CC PP

CCCCCC CCCCCC CCCCCC CCCCCC

Ayuda enLínea

Instalación IntegradaNiveles de

Seguridad

Procedimientos de Trabajo

Documentaciónen Línea

AgentesServidores

Clientes RegularesClientes AdministradoresControl de Copias

Control de AccesosHLP

CNT

Manual de Usuario

Plegable Comercial

Derechos Ejecución

Soporte enLínea

Curso deCapacitación

WebPaging

Celulares

Instalación

Mtto.

SIGTA

Documentación De Proyecto


CONCLUSIONES

• El proceso de cambio hacia una organización madura requiere de

tiempo, deseos y cambios en la cultura de las Personas.

• Disponer de las buenas prácticas de CMM asegura procesos acertados,

controlados y de constante satisfacción.

“Somos lo que hacemos de forma repetitiva. La excelencia, entonces, no es un

acto, sino un hábito”. Aristóteles

----------o----------

SISTEMAS DE PRUEBAS DEL SISTEMA



PRUEBAS DE SOFTWARE

• La prueba es un conjunto de actividades que se planean con

anticipación y se realizan de manera sistemática.

• Por tanto, se debe definir una plantilla para las pruebas del software, o

sea, un conjunto de pasos en que se puedan incluir técnicas y métodos

específicos del diseño de casos de prueba.

VERIFICACIÓN Y VALIDACIÓN

Verificación es el conjunto de actividades que aseguran que el software

implemente correctamente una función específica.

Validación es un conjunto diferente de actividades que aseguran que el

software construido corresponde con los requisitos del cliente.

ESTRATEGIA DE PRUEBA PARA ARQUITECTURAS CONVENCIONALES

Organización para las pruebas del software



ESTRATEGIA DE PRUEBA DEL SOFTWARE PARA ARQUITECTURAS

ORIENTADAS A OBJETOS

El grado al que se han completado y la consistencia de las representaciones

orientadas a objetos deben evaluarse a medida que se construyen.

ASPECTOS ESTRATÉGICOS

• Especificar los requisitos del producto de manera cuantificable antes de

que empiecen las pruebas.

• Establecer explícitamente los objetivos de la prueba.

• Comprender cuáles son los usuarios del software y desarrollar un perfil

para cada categoría de usuario.

• Desarrollar un plan de prueba que destaque la "prueba de ciclo rápido".

• Construir un software "robusto" diseñado para probarse a sí mismo.

• Usar revisiones técnicas formales y efectivas como filtro previo a la

prueba.



ESTRATEGIAS DE PRUEBA PARA EL SOFTWARE CONVENCIONAL

• Prueba de unidad

• Pruebas de validación

• Prueba de integración

• Pruebas de sistema:

o Recuperación

o Seguridad

o Resistencia

o Desempeño.

----------o----------



PRODUCTO SOFTWARE

FUNCIONALIDAD

La capacidad del producto software para proporcionar las funciones que

satisfacen las necesidades establecidas e implícitas cuando el software se

utiliza bajo condiciones especificadas.

Esta característica se refiere a lo que hace el software para satisfacer

necesidades, mientras que las otras características se refieren principalmente a

cuándo y a cómo las satisface.

Para un sistema el cual es operado por un usuario, la combinación de

funcionalidad, confiabilidad, facilidad de uso, y eficiencia, puede ser medido

externamente por la calidad en uso.

Apropiabilidad

La capacidad del producto software para proporcionar un apropiado conjunto

de funciones para las tareas especificadas y los objetivos de los usuarios.

Exactitud

La capacidad del producto de software para proporcionar resultados correctos

o efectos convenidos con el grado necesario de precisión. (Esto incluye el

grado necesario de precisión de los valores calculados).



Interoperabilidad

La capacidad del producto de software para interactuar con uno o más

sistemas específicos. (Se usa la interoperabilidad en lugar de compatibilidad

para evitar posibles ambigüedades con reemplazabilidad).

Seguridad

La capacidad del producto software para proteger la información y los datos de

modo que las personas o los sistemas no autorizados no puedan leerlos o

modificarlos, y a las personas o los sistemas autorizados no se les niegue el

acceso a ellos.

Conformidad con la funcionalidad

La capacidad del producto software para adherirse a estándares, normas,

convenciones o regulaciones en legislaciones y prescripciones similares

relacionadas con la funcionalidad.



CONFIABILIDAD

La capacidad del producto software para mantener su nivel de desempeño

cuando es utilizado bajo condiciones especificadas (durante un determinado

período de tiempo).

El desgaste o envejecimiento no se dan en el software. Las limitaciones en

confiabilidad resultan de fallas en requisitos, diseño e implementación. Las

fallas debidas a estos defectos dependen de la manera en que se use el

producto de software y de las opciones escogidas del programa, mas que en el

tiempo transcurrido.

La definición de confiabilidad es “La capacidad de la unidad funcional para

realizar una función requerida…”. En este documento, la funcionalidad es sólo

una de las características de la calidad del software. Por lo tanto, la definición

de confiabilidad ha sido ampliada a “mantener su nivel de desempeño…” en

lugar de “ … realizar una función requerida”.

Madurez

La capacidad del producto software para evitar fallas como resultado de fallas

en el software.

Tolerancia a fallas

La capacidad del producto software para mantener un nivel de desempeño

especificado en casos de fallas (en el software) o de que se infrinjan sus

enlaces especificados. (El nivel de desempeño especificado puede incluir la

capacidad de falla segura).



Recuperabilidad

La capacidad del producto software para restablecer su nivel de desempeño y

recuperar los datos directamente afectados en caso de falla (así como con el

tiempo y el esfuerzo necesario para ello).

Después de una falla, un producto de software algunas veces será dado de

baja por cierto período de tiempo, esta longitud de tiempo es evaluada para su

recuperabilidad.

La disponibilidad es la capacidad del producto de software de permanecer en

un estado para realizar una función requerida en un punto dado en el tiempo,

bajo condiciones establecidas de uso. Externamente, la disponibilidad se puede

evaluar por la proporción del tiempo total durante el cual el producto de

software está en un estado de alta. La ressponibilidad es por lo tanto una

combinación de la madurez (que gobierna la frecuencia de la falla), de la

tolerancia de la falla y de la recuperabilidad (que gobierna la longitud de tiempo

dado de baja que sigue a cada falla). Por esta razón no ha sido incluida como

una subcaracterística separada.

Conformidad con la confiabilidad

La capacidad del producto software para adherirse a estándares, convenciones

o regulaciones relacionadas con la confiabilidad.

FACILIDAD DE USO

La capacidad del producto software para ser comprendido, aprendido, utilizado

y que sea atractivo para el usuario, cuando es utilizado bajo condiciones

especificadas.



Algunos aspectos de funcionalidad, de confiabilidad y de eficiencia también

afectarán la facilidad de uso, pero para los propósitos de la ISO/IEC - 9126

ellos no son clasificados como facilidad de uso.

Los usuarios pueden incluir operadores, usuarios finales y usuarios indirectos

quienes están bajo la influencia o dependencia del uso del software. La

facilidad de uso debe dirigirse a todos los diferentes ambientes de usuario que

puede afectar el software, el cual puede incluir preparación para el uso y

evaluación de resultados.

Comprensibilidad

La capacidad del producto software para permitirle al usuario entender si el

software es conveniente, cómo puede ser utilizado para las tareas

determinadas y las condiciones de uso.

Facilidad de aprendizaje

La capacidad del producto software para permitirle al usuario aprender su

aplicación (como por ejemplo, control de operación, entradas, salidas).

Operabilidad

La capacidad del producto software para permitirle al usuario su operación y

control.

Aspectos tales como conveniencia, facilidad de cambios, adaptabilidad e

instalabilidad, pueden afectar la operabilidad.



La operabilidad corresponde a la controlabilidad, a la tolerancia del error y a la

conformidad con expectativas del usuario.


funcionalidad, confiabilidad, facilidad de uso y eficiencia, puede ser medida


Atractivo

La capacidad del producto software para que sea agradable al usuario.

Esto se refiere a los atributos del software previstos para hacer el software más

atractivo al usuario, tal como el uso del color y de la naturaleza del diseño

gráfico.

Conformidad del uso

La capacidad del producto software para adherirse a estándares,

convenciones, guías de estilo o regulaciones relacionadas con la facilidad de

uso.

EFICIENCIA

La capacidad del producto software para proporcionar un desempeño

apropiado, en relación con la cantidad de recurso utilizado, bajo condiciones

establecidas.

Los recursos pueden incluir otros productos de software, la configuración del

software y del hardware del sistema, materiales (por ejemplo, papel para

impresión, disquetes) y servicios para el personal de operación, mantenimiento

o soporte.




funcionalidad, confiabilidad, facilidad de uso y eficiencia, puede ser medida


Comportamiento en el tiempo

La capacidad del producto software para proporcionar adecuados tiempos de

respuesta, de procesamiento y de tasas de eficiencia en el desempeño de su

función, bajo condiciones establecidas.

Utilización de los recursos

La capacidad del producto software para utilizar una apropiada cantidad y tipos

de recursos cuando el software desempeña su función bajo condiciones

establecidas.

Los recursos humanos están incluidos como parte de la productividad.

Conformidad con la eficiencia

La capacidad del producto software para adherirse a estándares o

convenciones relacionadas con la eficiencia.



MANTENIBILIDAD

La capacidad del producto software para ser modificado. Las modificaciones

pueden incluir correcciones, mejoras o adaptaciones del software a cambios de

ambiente y en requisitos y especificaciones funcionales.

Analizabilidad

La capacidad del producto software para ser diagnosticado por deficiencias o

causas de fallas en el software, o para identificar las partes que se deben

modificar.

Facilidad de cambio

La capacidad del producto software para permitir una modificación especificada

que debe ser implementada.

La implementación arriba citada incluye los cambios en la codificación, el

diseño y la documentación.

Si el software va a ser modificado por el usuario final, la facilidad de cambio

puede afectar la operabilidad.

Estabilidad

La capacidad del producto software para evitar efectos no esperados debido a

modificaciones en el software.

Facilidad de prueba

La capacidad del producto software para permitir validar las modificaciones.



Conformidad con la mantenibilidad


convenciones relacionadas con la facilidad de mantenimiento.



PORTABILIDAD

La capacidad del producto software para ser transferido de un ambiente a otro.

El ambiente puede ser organizacional, de hardware o de software.

Adaptabilidad

La capacidad del producto software para adaptarse a diferentes ambientes

especificados sin aplicar acciones o medios distintos a los ofrecidos para este

propósito por el software considerado.

La adaptabilidad incluye la escalabilidad de la capacidad interna (por ejemplo:

campos de pantalla, tablas, volumen de transacciones, formatos de reportes,

entre otros).

Si el software va a ser adaptado por el usuario final, la adaptabilidad

corresponde con la apropiabilidad y puede afectar la operabilidad.

Instalabilidad

La capacidad del producto software para ser instalado en un ambiente

especificado.

Si el software va a ser instalado por el usuario final, la instalabilidad puede

afectar la adaptabilidad resultante y la operabilidad.

Co-existencia

La capacidad del producto software para coexistir con otros software

independientes en un ambiente común en el cual comparten recursos



comunes.

Reemplazabilidad

La capacidad del producto software para ser utilizado en lugar de otro producto

de software especificado para el mismo propósito en el mismo ambiente. Por

ejemplo, la reemplazabilidad de una nueva versión de un producto de software

es importante para el usuario cuando éste pasa a una versión superior.

El término reemplazabilidad se usa en lugar de compatibilidad para evitar

posibles ambigüedades con la interoperabilidad. La reemplazabilidad puede

incluir atributos tanto de instalabilidad como de adaptabilidad. El concepto ha

sido introducido como una subcaracterística de ella debido a su importancia.

Conformidad con la portabilidad


convenciones relativas a la portabilidad.

----------o----------


instituto de educación superior “san ignacio de ...€¦ · o el soporte a seguimiento de...

Documents