UNIVERSIDAD LA SALLE A.C.

Facultad de Ingeniera

Ingeniera de Software

Alfonso Rios Herrera

Contenido
I. Introduccin

II. Gestin de Proyectos

III. Evaluacin de Proyectos

IV. Control de Calidad V. Herramientas para el desarrollo VI. Metodos de Certificacin

Introduccin a la Ingeniera de Software

1.1 1.2 1.3 1.4 1.5 Conceptos Crisis del desarrollo Mitos y realidades Evolucin La Curva del Software

1.1 Conceptos de Ingeniera de Software

Es una disciplina que permite sistematizar el proceso de desarrollo de software de cualquier tipo, mediante el estudio de diferentes principios y metodologas aplicables a cada caso especfico.
1. 2. 3. 4. 5. 6. 7. 8. Es una disciplina de la Ingeniera Se especialzia en el Software Es una disciplina con normas y disposiciones Permite sistematizar el entorno Sistematiza el proceso de desarrollo Estudia cualquier tipo de Software Estudia diferentes principios y metodologas Es aplicable a cada caso especfico.

1.1 Conceptos de Ingeniera de Software El software debe:

1) Ser Confiable 2) Ser Rentable

3) Ser Bien Documentado

4) Aprovechar de manera ptima sus recursos 5) Prolongar su vida til al mximo 6) Ser Amigable con el usuario 7) Autoprotegerse de eventos dainos 8) Realizar realmente los procesos necesarios

1.1 Conceptos de Ingeniera de Software Campos de accin del Software

1. Sistemas de Informacin 2. Software de Tiempo Real 3. Software de Gestin 4. Software Tcnico 5. Software Residente 6. Software Comercial 7. Software de Investigacin

1.2 Crisis del desarrollo

La palabra crisis significa necesidad de cambio. Es un estado serio o decisivo de las cosas o del punto en el tiempo en que pronto debe terminar un asunto o sufrir un cambio material, un punto de inflexin, una interseccin crtica. (Diccionario Universal Websters, 1936). La rpida evolucin de las computadoras y su ingerencia en la sociedad, ha desatado una carrera en el desarrollo del software, donde los procedimientos y metodologas han sido rebasados por la urgencia de presentar resultados a tiempo, pero que en la mayora de los casos sacrific su eficiencia. Durante los ltimos aos, se han presentado diferentes problemticas respecto al desarrollo del software, esto principalmente debido a las siguientes razones:

1.2 Crisis del desarrollo

1. 2. 3. 4. 5. 6. 7. 8. Evolucin del Hardware Preparacin Profesional Mala asignacin de recursos Falsas expectativas creadas Rotacin de Personal Falta de Cultura Informtica Corto Ciclo de Vida Poca Flexibildad

1.3 Mitos y realidades

Un Mito es la supuesta creencia sobre una cosa a las que se atribuyen cualidades o excelencias que no tienen, o bien una realidad de la que carecen. Esto en el caso del Software se traduce en la falsa creencia de que algo o alguien va a solucionar un problema generado a partir del uso del Software. La realidad es que el estudiar los mitos mas frecuentes respecto a la generacin de Software, permitir analizar el origen del problema y proponer alguna solucin para evitar la difusin de dicho mito.

1.3 Mitos y realidades Mitos de Gestin:Estos mitos se relacionan con

aquellas personas que se encargan de mantener vivo el Software, estn a cargo del presupuesto y normalmente deben buscar la optimizacin de los recursos materiales y humanos asignados.
1. Teorizacin excesiva 2. Sobretecnificacin 3. Exceso de participantes

1.3 Mitos y realidades Mitos de Usuario:El usuario en general, es aquella

persona que como ya se dijo anteriormente, debe operar o solicita la construccin del software para que su personal lo opere. En ambos casos, el usuario siempre juega el papel de cliente a quien bien cierto hay que satisfacer, y concienciar por otro lado del lmite real de la plataforma de cmputo a usar.
1. Generalidad de objetivos
2. Sobreflexibilidad 3. Tecnologa mal estimada

1.3 Mitos y realidades Mitos del desarrollador:El desarrollador del

Software es la persona capacitada para programar a una computadora con el Software que se estime necesario para producir el resultado estimado. En general, el desarrollador tiene capacidad de anlisis, abstraccin y sntesis de los problemas por resolver, pero a menudo su papel es subestimado.
1. Falta de Participacin
2. Software sin pruebas 3. Sobreexplotacin de recursos

1.4 Evolucin del Software

N 1 2 3 4 5 6 7 8 Caracterstica Aos Tipo de Hardware Conectividad Arquitectura Programacin interfase MIS Tecnologa 1. Era 1950-1966 Mainframes Especial Central Lotes Unica Especiales Bulbo 2. Era 1965-1973 Mainframes Privada Distribuida Abreviada Simblica A la medida Transistor 3. Era 1971-1988 C. Personal Redes Cliente/Serv Procedural Texto Comerciales Microchip 4. Era 1988-2002
D. Mviles

Internet Hbridos Objetos Grfica Expertos Multiproc.

1.5 La curva del Software

CURVA DE FALLA DEL HARDWARE
100

Indice de fallo

80 60 40 20 0 1 2 3 4 5 6 7 8 9 10 11 12 Tiempo

1.5 La curva del Software

CURVA DE FALLA DEL SOFTWARE (IDEALIZADO)
100

Indice de fallo

80 60 40 20 0 1 2 3 4 5 6 7 8 9 10 11 12 Tiempo

1.5 La curva del Software

Unidad II: Gestin de Proyectos

2.1 2.2 2.3 2.4 Introduccin Medicin y mtricas Control del Proyecto Proceso de Adquisicin

2.1 Introduccin
La administracin eficaz de un proyecto de software se centra en las cuatro Ps: 1. Personal 2. Producto 3. Proceso 4. Proyecto

2.1 Introduccin

Personal

La necesidad de contar con personal para el desarrollo del software altamente calificado y motivado se viene discutiendo desde los aos 60s, de hecho el factor humano o capital intelectual (Modernamente nombrado), es tan importante que el Instituto de Ingeniera del Software (SEI), desarroll un modelo de madurez de la capacidad de administracin de personal para aumentar la preparacin de las organizaciones para llevar a cabo las aplicaciones para atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo.

2.1 Introduccin

Personal
Superiores.- Definen los aspectos de negocio que a menudo tienen una significativa influencia en el proyecto. Tcnicos del Proyecto.- Se encargan de Planificar, Motivar, Organizar y Controlar a los profesionales que realizan el trabajo de software. Profesionales.- Proporcionan las capacidades tcnicas necesarias para la ingeniera del producto o aplicacin. Clientes.- Especifican los requisitos para la ingeniera del software y otros elementos que tienen menor influencia en el resultado. Usuarios Finales.- Interaccionan con el software una vez que se ha entregado para la produccin.

2.1 Introduccin

Producto

Se considerar Producto para reconocer cualquier software que ser construido a peticin de otros. Esto incluye, no slo productos de software, sino tambin, sistemas basados en computadora, software inmerso en otra aplicacin (Embbeded) y software de resolucin de problemas. Antes de poder planificar un proyecto, se deberan establecer los objetivos y el mbito del producto, se deberan contemplar soluciones alternativas e identificar las dificultades tcnicas y de administracin. Sin esta informacin es imposible definir unas estimaciones razonables de costo, una valoracin efectiva del riesgo y una planificacin de proyecto realista.

2.1 Introduccin

Proceso

Proporciona la estructura desde la que se puede establecer un plan detallado para el desarrollo de software. Un nmero de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener que tomar en cuenta su tamao o complejidad. El problema en este punto es seleccionar el modelo de proceso apropiado para la ingeniera de software que debe aplicar el equipo de proyecto, siendo los ms comunes:

Secuencial Lineal (Estructurado) Prototipos RAD Espiral Mtodos Formales Tcnicas de Cuarta Generacin

2.1 Introduccin

Proyecto

Dirigimos los proyectos de software planificados y controlados por una razn principal, es la nica manera conocida para Administrar la Complejidad. En 1998, los datos de la industria del software indicaron que el 26% de los proyectos de software fallaron completamente y que el 46% experimentaron un desbordamiento en la planificacin (Tiempo) y en el costo. Para evitar el fracaso del proyecto, se deben eludir un conjunto de seales de peligro comunes; comprender los factores de xito crticos que conducen a una administracin correcta del proyecto y desarrollar un enfoque de sentido comn para planificar, supervisar y controlar un proyecto.

2.1 Introduccin

Proyecto Positivo
Relacin de equipo Comunicacin c/usuario

Negativo
Rotacin de personal Mala planeacin

Interno

Externo

Tecnologa de Punta Necesidades de Mercado

Competencia Crisis Econmica

2.2 Medicin y Mtricas

La medicin es fundamental para cualquier disciplina de la ingeniera y la ingeniera de software no es la excepcin. La medicin nos permite tener una visin ms profunda proporcionando un mecanismo para la evaluacin objetiva.

Porqu medir?
1. 2. 3. 4. Caracterizar Evaluar Predecir Mejorar

2.2 Medicin y Mtricas

Dentro de un contexto de ingeniera de software, una medida proporciona una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. La medicin es el acto de determinar una medida y la mtrica es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. 1a. Vez ?

Medida

Medicin

Mtrica

Indicador

Homeostasis

2.2 Medicin y Mtricas

Ejemplo 1: Se sabe que un atleta profesional debe saltar al menos
2.10 mts. (medida), se determina hacer tres intentos por persona (medicin), y cada resultado se anota en una tabla (mtrica), lo cual determina si un deportista califica o no para competir (indicador).

Ejemplo 2: Un adolescente toma 10 bebidas alcohlicas en promedio

(medida), se hace un conteo de botellas cada hora de las 21 a las 24 horas (medicin), y de cada inventario se hace un reporte (mtrica), y as estimar la compra de licor en la prxima ocasin (indicador).

Ejemplo 3: La impresora BJ consume 1 cartucho cada 200 paginas

(medida), se solicita al administrador de sistemas imprimir un reporte cada cambio (medicin), para hacer una tabla de consumo (mtrica), y decididir la poltica de compra por mayoreo o menudeo (indicador).

2.2 Medicin y Mtricas

Mtricas orientadas al Tamao.- Provienen de la normalizacin de las medidas de calidad y/o productividad considerando el tamao del software que se haya producido. (Construccin del Software) Cdigo

Tamao en Kilobytes
Algoritmos usados Nmero de mdulos, pantallas, reportes, etc. Mantenimiento Tiempo para Respaldos Tiempo de Recuperacin Tiempo para ejecucin de procesos especiales

2.2 Medicin y Mtricas

Mtricas orientadas a Pruebas: Se derivan de las anteriores para poder establecer los valores esperados de los resultados que se obtienen de hacer pruebas al Software. (Validacin del Software) Piloto: Errores de cdigo Tiempo de proceso (Nulo, Saturacin,promedio) Paralelo:

Dudas del usuario acerca del Software

Paro de operacin

2.2 Medicin y Mtricas

Mtricas orientadas a la Funcin.- Utilizan la medida de la funcionalidad entregada por la aplicacin como un valor de normalizacin, Ya que esta no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. (Produccin del Software)

Cuantitativas
Tiempo de respuesta Reportes y consultas disponibles Cualitativas Confiabilidad Operacin

2.3 Control del Proyecto

La administracin de proyectos comienza con un conjunto de actividades que globalmente se denominan planificacin del proyecto. Antes de que el proyecto comience se deben realizar estimaciones del trabajo a realizar, de los recursos necesarios y del tiempo que transcurrir desde el comienzo hasta el final de su realizacin. Este plan es el que permitir el control del administrador sobre sus recursos materiales y tcnicos y sus actividades. El objetivo del administrador es definir todas las tareas del proyecto, construir una red que describa todas sus interdependencias, identificar las tareas que son crticas dentro de la red y despus hacerles un seguimiento para asegurarse que el retraso se reconoce de inmediato.

2.3 Control del Proyecto

Porqu puede fallar?
1. 2. 3. 4. 5. 6. Fechas poco reales Cambios del usuario Subestimacin de recursos Riesgos predecibles y no predecibles Dificultades tcnicas imprevistas Dificultades humanas imprevistas

Qu se puede hacer?
1. 2. 3. 4. 5. 6. Agenda compartida Documentacin integral Estimacin detallada de recursos Estrategia de desarrollo para resultados rpidos Revisiones peridicas con especialistas Reuniones frecuentes con el cliente

2.3 Control del Proyecto

El plan de proyecto es una actividad que distribuye el esfuerzo estimado a lo largo de la duracin prevista del proyecto, asignando el esfuerzo a las tareas especficas, es importante observar que el plan evoluciona con el tiempo. Este tipo de plan identifica las principales actividades de ingeniera y las funciones del producto a las que se aplican.
El plan se puede ver desde dos perspectivas, la primera se ha establecido una fecha final de la entrega de un sistema basado en computadora y la organizacin est obligada a distribuir el esfuerzo dentro del marco de tiempo previsto. El segundo punto, asume que se han estudiado unos lmites cronolgicos aproximados pero la fecha final se establecer por la organizacin de ingeniera. El esfuerzo se distribuye para conseguir el mejor empleo de los recursos y se define una fecha final despus de un cuidadoso anlisis. Desgraciadamente la primer aproximacin es la ms comn.

2.3 Control del Proyecto

Principios Bsicos
1. Modularidad 2. Interdependencia 3. Cotizacin 4. Organizacin 5. Rentabilidad Cmo debe dividirse? Cmo debe relacionarse? Cmo debe financiarse? Cmo debe Trabajarse? Qu resultados dar?

2.3 Control del Proyecto

Herramientas de apoyo:
Tcnica de evaluacin y revisin de programas (PERT)

Mtodo del camino crtico (CPM)

Grficas de Gannt (Barras) Anlisis del Valor Ganado (AVG)

2.4 Proceso de Adquisicin

La decisin de desarrollar o comprar
En muchas reas de aplicacin del software, a menudo es ms rentable adquirir el software que desarrollarlo. Por lo que los administradores se enfrentan con la decisin entre comprar o desarrollar, que adems se complica por las opciones de compra que existen:

+ Comercialmente al 100% + Parcialmente experimentado con alguna empresa + Construir el software en su totalidad (Insourcing/Outsourcing)

2.4 Proceso de Adquisicin

Directrices recomendadas:
1. Anlisis de necesidades 2. Limites de recursos (tiempo y presupuesto)

3. Seleccin de opciones de proveedores (candidatos)

4. Valores agregados para otras aplicaciones 5. Pruebas exhaustivas de los candidatos

6. Solicitud de referencias profesionales de los candidatos

7. Desarrollo de una matriz de comparacin de resultados 8. Validacin de la decisin final por el equipo de trabajo

Unidad III: Evaluacin de Proyectos

3.1 Seleccin de Proyectos (Estudios de Factibilidad)

3.2 Estimacin de recursos y costos

3.3 Anlisis y Gestin del Riesgo

3.1 Seleccin de Proyectos. Estudio de Factibilidad

ESTUDIOS
FACTIBILIDAD TECNICA FACTIBILIDAD FINANCIERA FACTIBILIDAD LEGAL FACTIBILIDAD ORGANIZACIONAL
Factores EXTERNOS inflacionarios, tipos de cambio, etc.

RESULTADOS
APORTACIONES CUALITATIVAS DEL PROYECTO

APORTACIONES CUANTITATIVAS DEL PROYECTO

ESTUDIO DE FACTIBILIDAD ECONOMICA

Flujo de aportaciones de informacin de cada estudio para la justificacin econmica.

3.1 Seleccin de Proyectos. Estudio de Factibilidad

Estudio de Factibilidad Tcnica
Esta determina si una solucin propuesta puede ser implantada con el Software, Hardware y los Recursos Tcnicos disponibles. Entendiendo por Software a: Sistemas en General, Aplicacin en General y Aplicacin Especfica. Al Hardware: Equipos de Cmputo, Equipos de Comunicacin Activos y Pasivos. Tecnologas: Wireless, BCR, PALM Arquitecturas: C/S-2,3, Host Oriented, DCE Metodologas: OOP, 4GL, DBMS, Data Mining Aplicaciones: SAP R/3, Sybase, Oracle Administracin: OpenView, ArcServe, NAV

3.1 Seleccin de Proyectos. Estudio de Factibilidad

Estudio de Factibilidad Financiera
El estudio tiene como finalidad definir una estrategia que permita al proyecto allegarse los recursos necesarios para su implantacin, y contar con la suficiente liquidez y solvencia para desarrollar ininterrumpidamente operaciones productivas. Aporta informacin necesaria para estimar la rentabilidad de los recursos que se utilizarn, susceptible de compararse con la de otras opciones. Los estados financieros son el producto sinttico y final del proceso de registrar la forma exacta, sistemtica y cronolgica de todas las operaciones del proyecto. Presupuesto. Cmo se va a gastar? Evaluacin. Esta siendo eficiente? Indicadores Financieros. Uso de la TIR, VPN, C/B Indicadores para la evaluacin Social. Creacin de empleos, Valor Agregado

3.1 Seleccin de Proyectos. Estudio de Factibilidad

Estudio de Factibilidad Organizacional
Impide una cuantificacin correcta de las inversiones y costos de operacin que se originan para efectos de la administracin del proyecto, obliga a definir una estructura organizativa acorde con los requisitos propios que exija su ejecucin Dimensin y distribucin fsica. Equipamiento para los usuarios. Inversiones adicionales. Teora clsica de Henry Fayol Organizacin burocrtica de Max Weber Teoras contemporneas

3.1 Seleccin de Proyectos. Estudio de Factibilidad

Estudio de Factibilidad Legal
El ordenamiento jurdico de capa pas, fijado por su constitucin poltica, leyes, reglamentos, decretos y costumbres, entre otros, determinan las condiciones que se traducen en normas permisivas o prohibitivas que pueden afectar directa o indirectamente al flujo de caja que se elabora para el proyecto que se evala. Leyes Aduanales: Importaciones, TLC, Aranceles Personal Sindicalizado: Puestos protegidos, reemplazos, incapacidades Disposiciones Fiscales: IVA, Deducibilidad, Depreciacin Certificaciones: ISO, IEEE, ISACA

3.2 Estimacin de recursos y costos

Antes de que el proyecto comience se debe realizar una estimacin del trabajo a realizar, de los recursos necesarios y del tiempo que transcurrir desde el comienzo hasta el final de su realizacin. Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignados cierto grado de incertidumbre.

3.2 Estimacin de recursos y costos

La disponibilidad de informacin histrica tiene una fuerte influencia en el riesgo de la estimacin. Al mirar atrs, podemos emular lo que se ha trabajado y mejorar las reas en donde surgieron problemas. La estimacin del costo y del esfuerzo nunca ser una ciencia exacta. Son demasiadas las variables (Humanas, Tcnicas, Entorno, Polticas, etc.) que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

3.2 Estimacin de recursos y costos

Para hacer estimaciones seguras se tienen varias opciones:
Dejar la estimacin para ms adelante (Para realizar estimaciones

casi 100% fiables tras haber terminado el proyecto). Basar estimaciones en proyecto similares ya terminados Utilizar tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costo y esfuerzo. Utilizar uno o ms modelos empricos para estimacin del costo y esfuerzo.

3.2 Estimacin de recursos y costos

Desgraciadamente, la primera opcin, aunque atractiva no es prctica, ya que las estimaciones deben ser a priori, sin embargo, mientras ms esperemos ms cosas sabremos y menor ser la probabilidad de cometer serios errores. La segunda, puede funcionar razonablemente bien, si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias son similares. Por desgracia, la experiencia anterior no ha sido siempre un buen indicador de futuros resultados.

3.2 Estimacin de recursos y costos

Tcnicas de Descomposicin
La estimacin de proyectos es una forma de resolucin de problemas y en la mayora de los casos, el problema a resolver es demasiado complejo para considerarlo como un todo. Por esta razn, descomponemos el problema, volvindolo a definir como un conjunto de pequeos problemas.
Estimacin basada en el tamao del Software
Estimacin basada en el problema Estimacin basada en el proceso

3.2 Estimacin de recursos y costos

Modelos Empricos de Estimacin.
Un modelo de estimacin utiliza frmulas derivadas empricamente para predecir el esfuerzo. Los datos empricos que soportan la mayora de los modelos se obtienen de una muestra limitada de proyectos. Por esta razn este tipo de modelos no son adecuados para todas las clases de software y en todos los entornos de desarrollo. Por consiguiente, los resultados obtenidos de dichos modelos se deben utilizar con prudencia.
Modelo COCOMO Ecuacin del Software

3.2 Estimacin de recursos y costos

Ecuacin del Software
Es un modelo mutivariable dinmico que asume una distribucin especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo. El modelo se ha obtenido a partir de los datos de productividad para unos 4,000 proyectos actuales de software. La ecuacin tiene la siguiente forma:
E = [LDC x B**.3333 / P]**3 x ( 1 / t**4) en donde: E = Esfuerzo de Persona mes o Persona ao. t = Duracin del proyecto en meses o aos. B = Factor Especial de destreza (.16 o .39 dependiendo de los KLDC, de 5 a 15; .16 ms de 70; .39). P = Parmetro de Productividad que refleja:
Madurez global del proceso de las prcticas de administracin La amplitud hasta donde se utilizan correctamente las normas de ingeniera El nivel de los lenguajes de programacin utilizados La complejidad de la aplicacin Las habilidades y experiencias del equipo

3.3 Anlisis y Gestin del Riesgo

Definiciones de Riesgo
El riesgo es definido como la probabilidad de que algn evento ocurra, ya sea por parte de la naturaleza (impredecibles casi siempre) o por causa humana (accidental, imprudencial, intencional). Para el caso del Software, dan peso a la ocurrencia del evento que por lo general resulta daino para nuestro proyecto. Segn Robert Charette: En primer lugar, el riesgo afecta a los futuros acontecimientos. En segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinin, de acciones o lugares. En tercer lugar, el riesgo implica eleccin y la incertidumbre que implica la eleccin. Peter Drucker dijo una vez: Mientras que es intil intentar eliminar el riesgo y cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos adecuados.

3.3 Anlisis y Gestin del Riesgo

Estrategias de Riesgo: Proactivas vs. Reactivas.
La estrategia reactiva nunca se preocupa de los problemas hasta que ocurren, y entonces se reacciona de alguna manera heroica. Sin embargo, la mayora de los equipos confan slo en este tipo de estrategias. En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsin de posibles riesgos. Cuando algo pasa mal, el equipo vuela para corregir el problema rpidamente (Bomberos), pero cuando falla la Gestin de Crisis, el proyecto se encuentra en peligro real. Una estrategia considerablemente ms inteligente es la Proactiva que empieza mucho antes de que empiecen los trabajos tcnicos. Se identifican los riesgos, se evala su probabilidad y su impacto y se establece una prioridad segn su importancia, despus el equipo establece un plan para controlar el riesgo.

3.3 Anlisis y Gestin del Riesgo

Riesgo del Software.
Un riesgo siempre implica 2 caractersticas: Incertidumbre: de que el acontecimiento que caracteriza al riesgo puede o no ocurrir. Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas. Los riesgos identifican problemas de Presupuesto, Planeacin, Personal (Asignacin y Organizacin), Recursos, Complejidad, Tamao, Grado de Incertidumbre Estructural, Clientes y Requisitos y su impacto en el mismo.
Riesgos Tcnicos: Causados por el uso de Hardware y Software de apoyo Riesgos del Negocio: Relacionados con la organizacin y su personal Conocidos: Son descubiertos despus de una evaluacin Predecibles: Se extrapolan de la experiencia de proyectos anteriores. Impredecibles: Son extremadamente difciles de identificar por adelantado.

3.3 Anlisis y Gestin del Riesgo

Identificacin del Riesgo.
La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan, identificando los riesgos conocidos y predecibles, en donde el administrador trata de evitarlos cuando sea posible y controlarlos cuando sea necesario.
Tamao del Producto Impacto en el negocio Definicin de Procesos Entorno de Desarrollo Tecnologa a Construir Tamao y Experiencia de la Plantilla

3.3 Anlisis y Gestin del Riesgo

$
Virus Informtico Terremoto

Falla de Luz

Presupuesto de Contingencia

Presupuesto de Operacin

Prdida de Datos

Unidad IV. Control de Calidad

4.1 Elementos de la Calidad 4.2 Requisitos de un Software de Calidad 4.3 Factores de la productividad en el desarrollo de Software 4.4 Tcnicas formales de revisin y seguimiento del proyecto

4.1 Elementos de la Calidad

Porqu la Calidad?

1. Por una tendencia

2. Por un ahorro de presupuesto 3. Por un proceso de mejora continua del MIS

4. Por el establecimiento de reglas claras en el rea

4.1 Elementos de la Calidad

Concepto de la Calidad Hacer las cosas bien a la primera El atributo de algn objeto El grado de satisfaccin de requisitos La aceptacin del cliente respecto a algo

4.1 Elementos de la Calidad

Ciclo de la Calidad Anlisis Requisitos del usuario

Diseo
Construccin Pruebas Implantacin Soporte y Mantenimiento

Armado de Diagramas
Programacin completa Piloto y Paralelo Integracin del usuario Apoyo 7x24

4.1 Elementos de la Calidad

Control de la Calidad Se entiende por una serie de inspecciones, revisiones y pruebas utilizados a lo largo del proceso del software para asegurar que cumple con los requisitos esperados.
Quality Assurance

Quality Control

MIS

4.1 Elementos de la Calidad

Garanta de la Calidad La garanta de calidad consiste en la auditora y las funciones de informacin de la gestin. El objetivo de la garanta de calidad es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms profunda y segura de que la calidad del producto est cumpliendo sus objetivos.

4.1 Elementos de la Calidad

Costo de la Calidad El control de calidad es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados.

Software

4.2 Requisitos de un Software de Calidad

Internos
Correcto: Un programa es funcionalmente correcto cuando se desenvuelve de acuerdo con las especificaciones de funcionamiento que provee, es decir es la equivalencia entre el software y las especificaciones del mismo. Confiable: Se dice que un software es confiable en la medida en la que el usuario puede depender del mismo. Una desviacin en el funcionamiento del software, comparado con las especificaciones, lo determinar como falto de confiabilidad. La confiabilidad de un software se pude determinar en funcin de la confiabilidad de otro del mismo tipo, o con especificaciones similares. Robusto: un software es robusto cuando es capaz de responder razonablemente bien en cualquier circunstancia que no hubiese anticipado en los requerimientos del mismo. Capacidad del programa de responder ante la entrada de datos no vlidos.

4.2 Requisitos de un Software de Calidad

Externos
Amigable: Que puede ser utilizado fcilmente, es decir cualquier persona, sin demasiados conocimientos del rea, puede hacer uso del mismo. En general se refiere a que exista consistencia en las interfaces de usuario.

Verificable: Un software es verificable si las propiedades del mismo pueden ser revisadas fcilmente. El diseo modular, la disciplina en el cdigo y el uso de un apropiado lenguaje de programacin son elementos que determinan la verificabilidad.
Reparable: Un software es reparable siempre y cuando se puedan corregir los errores del mismo con un mnimo de trabajo. El software debe ser maleable, para poder hacerle modificaciones que resulten fciles en la aplicacin o la implementacin.

4.2 Requisitos de un Software de Calidad

Factores de Influencia
Capacidad individual Comunicacin en el grupo Complejidad del producto Empleo de tcnicas y notaciones propias Enfoques sistemticos Habilidades de los lderes de proyecto Nivel tecnolgico Nivel de confianza Captacin del problema Tiempo disponible Especificacin requerida Facilidades y recursos Entrenamiento adecuado Control de cambios Metas apropiadas Administracin de proyectos

4.3 Factores de la productividad en el desarrollo de Software

La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Para controlar la calidad del software es necesario, definir los parmetros, indicadores o criterios de medicin. El software posee determinados ndices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.

4.3 Factores de la productividad en el desarrollo de Software

Una vez seleccionados los ndices de calidad, debe establecerse el proceso de control, que requiere los siguientes pasos:
1. Definir el software que va a ser controlado: clasificacin por tipo, esfera de aplicacin, complejidad, etc., de acuerdo con los estndares establecidos para el desarrollo del software. 2. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. 3. Crear o determinar los mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios periciales y herramientas automatizadas para medir los criterios de clculo. 4. Definir las regulaciones organizativas para realizar el control: quines participan en el control de la calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc.

4.3 Factores de la productividad en el desarrollo de Software

La calidad del software debe ser una disciplina ms dentro de la Ingeniera del software. El principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de Calidad. El plan se basa en unas normas o estndares genricos y en unos procedimientos particulares.
o Familia de normas ISO 9000 y en especial, la ISO 9001 y la ISO 9000-3.2: 1996 o Quality Management and Quality Assurance Standards ISO 8402: 1994 o IEEE 730/1984, Standard for Software Quality Assurance Plans o IEEE Std 1028: 1989, IEEE Standard for Software Reviews and Audits o El Plan General de Garanta de Calidad del Consejo Superior de Informtica. MAP. o CMM. Capability Maturity Model o ISO/IEC JTC1 15504. SPICE. Software Process Improvement and Capability determination. o Modelo de EFQM. Modelo de la Fundacin Europea de Gestin de Calidad

4.4 Tcnicas formales de revisin y seguimiento del proyecto

La administracin de la calidad cuenta con dos niveles de trabajo: El nivel de entidad u organizacin. Donde se trata de crear y gestionar una infraestructura que fomente la calidad de los productos software mediante la adecuacin y mejora de las actividades y procesos involucrados en su produccin e, incluso, en su comercializacin y en la interaccin con los clientes. El nivel del proyecto. Donde las guas que la infraestructura organizativa prev para las distintas actividades y mantenimiento del software deben ser adaptadas a las caractersticas concretas del proyecto y de su entorno para ser aplicadas a la practica.

4.4 Tcnicas formales de revisin y seguimiento del proyecto

La idea a la necesidad de realizar pruebas en fases tempranas, conduce a realizar un mecanismo bsico que permite las Revisiones Tcnica Formales. Una revisin tcnica formal (RTF) es una actividad
que garantiza la calidad del software y que es llevada a cabo por los profesionales de la ingeniera de software. Los objetivos de la RTF son:
o Descubrir errores en la funcin, la lgica o la implementacin de cualquier SW o Verificar que el software bajo revisin alcance sus requisitos; o Garantizar que el SW ha sido representado de acuerdo con ciertos estndares o Conseguir un software desarrollado de forma uniforme y o Hacer que los proyectos sean ms manejables.

4.4 Tcnicas formales de revisin y seguimiento del proyecto

Las revisiones tcnicas formales son bsicamente una clase de revisin que agrupa en s diversos mecanismos de revisin y permite establecer un marco comn para la definicin de distintas etapas de revisin en el ciclo de vida del software, este mecanismo no slo est pensado para las etapas tempranas del ciclo de vida sino que tambin puede -y debe ser utilizado en etapas como la de prueba de software y el mantenimiento. El mecanismo ms comn para su implementacin es la reunin de revisin, la cual deber regirse, para asegurar su xito, por una buena planificacin, control y, sobre todo, por la participacin dedicada de todos y cada uno de los involucrados, lo que lleva a que su orientacin sea muy especfica, en el sentido que cada RTF debe centrarse en una parte muy bien delimitada del software total.

4.4 Tcnicas formales de revisin y seguimiento del proyecto

Se pueden realizar inspecciones para cada mdulo o pequeo grupo de mdulos que conformen un sistema. Al limitar el centro de atencin de la RTF la probabilidad de descubrir errores es mayor.

Unidad V. Herramientas C.A.S.E.

5.1 Introduccin 5.2 Estructura 5.3 Clasificacin 5.4 Reingeniera de Software

5.1 Introduccin
La Ingeniera de Software apoyada por computadora (CASE), es la automatizacin de metodologas paso a paso para el desarrollo de software; tratan de....
1. Respetar la metodologa de desarrollo 2. Mejorar la comunicacin 3. Organizar y correlacionar los componentes 4. Automatizar porciones tediosas y proclives 5. Automatizar agendas de pruebas y controles

5.1 Introduccin (Evolucin)

La mayora de las herramientas CASE implementan las tcnicas de diseo manuales surgidas durante los aos 60 y 70. Durante los 80s las metodologas se introdujeron en las herramientas CASE a medida que las estaciones grficas y las computadoras personales se hicieron accesibles.

Las herramientas CASE han buscado su perfeccionamiento desde la pasada dcada, y se han visto influenciadas por el desarrollo tecnolgico del Hardware y Software

5.1 Introduccin (Beneficios)

Especificacin de requerimientos completa. Especificacin del diseo adecuada. Especificaciones de diseo actualizadas. Reduccin del tiempo de desarrollo. Cdigo mantenible y ampliable.

Las herramientas CASE ayudan a los gestores y practicantes de la ingeniera del software en todas las actividades asociadas a los procesos de software. Automatizan las actividades de gestin de proyectos, gestionan todos los productos de los trabajos elaborados a travs del proceso, y ayudan a los ingenieros en el trabajo de anlisis, diseo y codificacin. La ingeniera del software asistida por computadora puede ser tan sencilla como una nica herramienta que preste su apoyo para una nica actividad de ingeniera del software, o tan compleja como todo un entorno que abarque herramientas, una base de datos, personas, hardware, una red, sistemas operativos, estndares, y otros componentes.

5.2 Estructura (Bloques de Construccin)

Cada bloque de construccin forma el fundamento del siguiente, estando las herramientas situadas en la parte superior. Los entornos para la ingeniera del software se construyen con xito sobre una arquitectura que abarca un hardware y un software de sistemas adecuados.

5.2 Estructura (Caractersticas)

Una interfase grfica de usuario amigable y rpida, utilizando la tcnica de multiventanas y con un sistema experto que permita variar smbolos y mtodos con rapidez y a gusto del usuario. Un diccionario de datos o repositorio de fcil acceso y rpido en todo momento, mediante un sistema similar al SQL, lo que constituye la base de toda la herramienta. Mdulos para cubrir todas las fases, incluyendo diseo de pantallas, mens y listados, con posibilidad de crear prototipos a partir de este diseo, generacin completa de cdigo y procedimientos de test. Un sistema de documentacin rpido y completo, que permita incluir los grficos desarrollados durante cada una de las fases, as como interfaces para la conexin con editores grficos y de texto externos.

5.2 Estructura (Qu es y Qu NO es)

Las herramientas CASE pueden: Automatizar muchas tareas manuales de desarrollo de sistemas Las herramientas CASE NO pueden: Proporcionar automticamente un sistema funcional relevante.

Promover la estandarizacin basndose en una metodologa nica

Promover una consistencia y coordinacin durante el desarrollo de un proyecto. Generar gran parte de la documentacin para un sistema.

Tener fcilmente interfaces con las bases de datos y con los lenguajes de cuarta generacin.
Forzar automticamente a los analistas para que usen una metodologa prescrita o crear una metodologa cuando esta no exista. Transformar radicalmente el anlisis de sistemas y el proceso de diseo.

5.2 Estructura (Componentes)

Herramientas para diagramas Verificador de Sintxis Herramientas para prototipos Almacn de Informacin Generadores de Cdigo

Metodologa de Desarrollo
Herramientas de Administracin

5.3 Clasificacin (Formal)

a) Upper Case Lower Case b) ICASE IPSE

c) McClure
d) Sommerville e) Fuggetta

5.3 Clasificacin (Funcional)

a) De Gestin b) De Soporte y Documentacin

c) De Anlisis y Diseo
d) De Programacin e) De Integracin y Pruebas

f) De Creacin de Prototipo

5.4 Reingeniera de Software

Es una metodologa que ataca el problema del envejecimiento del software.
El propsito de la reingeniera es salvar mucho del software, revaluarlo de manera que el usuario pueda evitar y proyecto largo y caro de reemplazo.

La Reingeniera implica tres pasos:

1. Ingeniera Reversiva 2. Revisin del diseo y especificacin de programas 3. Ingeniera Prospectiva

Unidad VI. Mtodos de certificacin.

6.1 Agencias Reguladoras de Estndares 6.2 COBIT 6.3 ISO9000

6.1 Agencias Reguladoras de Estndares

Asociacin, Organizacin o Instituto.

Objetivo Principal

Ao de Fundacin

Campo

Sede

Estndares que indican lmites elctricos y electromagnticos para la seguridad del paciente.
Desarrollar la normalizacin y certificacin del sector elctrico. Desarrollo y publicacin de estndares internacionales en diferentes tecnologas elctricas y electrnicas. Laboratorios para probar la seguridad de un equipo elctrico.

1967

Equipo Mdico
Elctrico
Electrotecnologa

Virginia (USA)
Mxico Suiza

1992 1906

1894

Elctrico

Alrededor del mundo EEUU

Instancia reguladora de comunicacin, medios y servicios relacionados.

1934

Comunicaciones

6.1 Agencias Reguladoras de Estndares

Asociacin, Organizacin o Instituto.

Objetivo Principal

Ao de Fundacin

Campo

Sede

Promueve la utilizacin de estndares para mejor la competencia y calidad global. Estndares para productos que desean ser vendidos en la Comunidad Europea. Avanzar en la teora y la prctica de la ingeniera elctrica, electrnica y computacional. Promover el desarrollo de la estandarizacin para facilitar el intercambio internacional de bienes y servicios. Normas mexicanas que establecen reglas, caractersticas y especificaciones aplicables a un producto, servicio o actividad.

1918

Todos

Nueva York (USA) Comunidad Europea Nueva Jersey (USA) Suiza

1985

Todos

1884

1947

Ingeniera elctrica, electrnica y computacin Todos

NOM

1992

Todos

Mxico

6.2 COBIT

(Control Objectives for Information and Related Technology)

La misin y Objetivos de COBIT es Investigar, Desarrollar, Publicitar y promocionar Objetivos de Control de TI internacionales, actualizados a la realidad actual para ser usado por los Gerentes de Negocios y Auditores. Bsicamente consta de 4 libros, a saber:
1. Resumen Ejecutivo 2. Antecedentes y Marco de Referencia 3. Guas de Auditora 4. Herramienta de Implementacin

6.2 COBIT

(Control Objectives for Information and Related Technology) Este estndar aparentemente sencillo, intenta responder a las necesidades organizacionales, tratando de ser independiente de las plataformas tcnicas de TI adoptadas por las empresas. Basados en esto, los cuatro objetivos de control buscan:
1. 2. 3. 4. El desarrollo de un marco de referencia para el control de la TI, basados en el principio de cada objetivo y como un facilitador de la investigacin y la auditoria. Conciliar aquellos objetivos de forman el marco de referencia y los individuales de cada organizacin, tanto de facto como de jure. La revisin a detalle de las diferentes actividades necesarias para el cumplimiento de los objetivos, y su especificacin en tablas, normas, reglas. La evaluacin a detalle y actualizacin de las directrices para la ejecucin de los procesos de auditora de sistemas de TI.

6.3 ISO9000
Para el caso de desarrollo y mantenimiento de software, el estndar ISO 9000-3 (1991) es el encargado de fijar los requerimientos a cumplir para asegurar la calidad del sistema. Este estndar est planeado para describir controles y mtodos sugeridos para producir software que cumpla los requerimientos del cliente. Esto puede ser llevado a cabo previniendo las fallas en todas las etapas del ciclo de vida del software, desde el desarrollo hasta el mantenimiento. La obtencin de la certificacin de ISO 9000 es importante para demostrar que se tiene calidad en el producto. Es tambin importante porque con ella se puede obtener la marca "CE". Existen dos normas que se basan en la norma ISO9000:

6.3 ISO9000
1. La norma ISO 1799, permite identificar, manejar y minimizar aquellos errores que normalmente se presentan en la administracin de la seguridad de los Sistemas de Informacin. Se usa ampliamente en Reino Unido y sus reas de influencia, y se ha convertido en un estndar de facto en la regin Asia/Pacfico. El resultado obtenido se denomina Information Security Management System (ISMS), el cual apoya al tradicional MIS en el rea de seguridad y control. 2. La versin 2000 de las normas ISO-9000, redescubre el concepto tan elemental para las organizaciones como es la administracin basada en procesos, es aqu donde surgen las preguntas: por qu est tomando tanta importancia en las organizaciones el enfoque y administracin basada en procesos? Qu sucedi con la manera tradicional de administrar las organizaciones? Por qu ahora los expertos en normatividad incluyen de manera explcita la importancia de tener un enfoque basado en procesos?.