Ingeniería Del Software

1. Ingeniera del Software 2.
Nuevo orden (Sistemas basados en computadoras) No hay nada ms difcil de llevar a cabo, ms peligroso de realizar o de xito ms incierto que tomar el liderazgo en la introduccin de un nuevo orden de cosas. Maquiavello 3. Concepto
o
La ingeniera del software ocurre como consecuencia de un proceso denominado ingeniera de sistemas de computadora . No solo se concentra en el software, sino que se concentra en una variedad de elementos, analizando, diseando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnologa para la transformacin de informacin o control de informacin.
4. Gestin de Proyectos tres pes5. El Espectro de la gestin

o
El gestor que se olvida de que el trabajo de ingeniera del SW es un esfuerzo humano intenso, nunca tendr xito en la gestin de proyectos. Un gestor que no fomenta una minuciosa comunicacin con el cliente al principio de la evolucin del proyecto se arriesga a construir una elegante solucin para un problema equivocado. Finalmente, el administrador que presta poca atencin al proceso corre el riesgo de arrojar mtodos tcnicos y herramientas eficaces al vaco.
6. Conceptos sobre gestin de proyectos

o o
La gestin eficaz de un proyecto de software se centra en las Tres PES: Personal. Problema. Proceso.
7. Personal
o o o
Modelo de madurez de la capacidad de gestin de persona. Aumentar la preparacin de organizaciones del software para llevar a cabo las cada vez ms complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software.
8. Personal
o
El MMCGP (Modelo de Madurez de la capacidad de gestin de personal) define las siguientes reas prcticas clave para el personal que desarrolla software: Reclutamiento.
o o o o o o
Seleccin. Gestin de rendimiento. Entrenamiento. Retribucin. Desarrollo cultural. Espritu de equipo.
9. Personal Las organizaciones que alcanzan una gran madurez en el rea de gestin de personal tienen una mayor probabilidad de implementar unas eficaces prcticas de ingeniera del software. 10. Personal
o o
Los participantes Gestores superiores , que definen los aspectos de negocio que a menudo tienen una significativa influencia en el proyecto. Gestores (tcnicos) del proyecto , que deben planificar, modificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software. Profesionales , que proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin. Clientes , que especifican los requisitos para la ingeniera del SW. Usuarios finales , que interaccionan con el SW una vez que se ha entregado para la produccin.
o o
11. Jefes de Equipos

o
Qu es lo que buscamos cuando seleccionamos a alguien para dirigir un proyecto de SW?

Motivacin. Organizacin. Ideas o Innovacin.
12. Motivacin
o
La habilidad para motivar al personal tcnico para que produzca conforme a sus mejores capacidades.
13. Organizacin
o
La habilidad para moldear procesos existentes que permita al concepto inicial transformarse en un proyecto final.
14. Ideas o Innovacin

o
La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los lmites establecidos para un producto o aplicacin de SW particular
15. Gestor de Proyectos

o o o o o o o
las caractersticas que definen a un gestor de proyecto eficiente resalta cuatro apartados claves: Resolucin del problema. Dotes de gestin. Incentivo de los logros. Influencia y construccin de espritu de equipo.
16. Resolucin del problema

o o o o
Un gestor puede diagnosticar los aspectos tecnolgicos y de organizacin. Estructurar una posible solucin Aplicar todo lo aprendido en proyectos anteriores. Flexibilidad para cambiar la gestin si los intentos iniciales no dan el resultado esperado.
17. Dotes de Gestin

o o o
Un buen gestor de proyecto de SW debe tomar las riendas. Debe tener confianza para asumir el control cuando sea necesario. garantizar que los buenos tcnicos sigan su instinto.
18. Incentivos de los logros

o o
Recompensar la iniciativa y los logros. Demostrar, a travs de sus acciones que no se penalizar si se corren riesgos controlados.
19. Influencia y construccin de espritu de equipo.

o o o o
Debe de ser capaz de leer a la gente. Debe se capaz de entender mensajes verbales y no verbales. Reaccionar ante la necesidades de las personas que mandan seales. El gestor debe mantener el control en situaciones de gran estrs.
20. El Equipo de SW
o o o o
Existen casi tantas estructuras de organizacin de personal para el desarrollo de SW como organizaciones que se dedican a ello.
21.
o
las polticas y prcticas de un cambio en la organizacin no estn dentro del alcance de las responsabilidades del gestor de un proyecto de SW. la organizacin del personal directamente involucrado en un nuevo proyecto de SW esta dentro del mbito del gestor del proyecto.
El Equipo de SW 22. o La mejor estructura de personas que compondr el equipo, sus niveles de preparacin y la dificultas general del problema.
o
Se sugieren tres organigramas de equipo genrico. Descentralizado democrtico (DD). Descentralizado controlado (DC). Centralizado controlado (CC).
El Equipo de SW 23. o No tiene un jefe permanente.

o o o
Se nombran coordinadores de tareas a corto plazo. se sustituyen por otros para diferentes tareas. Las decisiones sobre problemas y enfoques se hacen por consenso del grupo. La comunicacin entre los miembros del equipo es horizontal.
Descentralizado democrtico (DD) 24. o Tiene un jefe definido.

o
coordina tareas especficas y jefes secundarios. La resolucin de problemas sigue siendo una actividad del grupo. La implementacin de soluciones se reparte entre subgrupos por el jefe de equipo. La comunicacin entre subgrupos e individuo es horizontal. Hay comunicacin vertical a lo largo de la jerarqua de control.
o o
Descentralizado controlado (DC) 25. o El jefe del equipo se encarga de la resolucin de problemas de alto nivel y la coordinacin interna del grupo.
o
La comunicacin entre el jefe y los miembros del equipo es vertical.
Centralizado controlado (CC) 26. o Siete factores a considerar
o o o o o o o
La dificultad del problema que hay que resolver. el tamao del programa resultante en lneas de cdigo. el tiempo que el equipo estar junto(T de vida del equipo. el grado en que el problema puede ser modularizado. la calidad requerida y fiabilidad del sistema que se va a construir. la rigidez de la fecha de entrega. el grado de comunicacin requerido para el proyecto.
Factores a considerar 27. Paradigmas de organizacin

o o o o o
Para equipos de ingeniera del SW Paradigma cerrado. Paradigma aleatorio. Paradigma abierto. Paradigma sincronizado.
28. Paradigma cerrado

o
Estructura a un equipo con una jerarqua tradicional de autoridad (similar al equipo CC). Trabajan bien cuando producen SW similar a otros anteriores. Menos innovadores.
o o
29. Paradigma aleatorio

o
Estructura al equipo libremente y depende de la iniciativa individual de los miembros. se requiere innovacin o avances tecnolgicos. son excelentes. chocan cuando se requiere un rendimiento ordenado.
o o o
30. Paradigma abierto

o
Intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado. Utiliza mucha de la innovacin que tiene lugar cuando se utiliza el paradigma aleatorio. El trabajo se desarrolla con mucha comunicacin y toma decisiones consensuadas. son adecuados para la resolucin de problemas complejos. Pueden no tener un rendimiento tan eficiente como otros equipos.
o o o
31. Paradigma Sincronizado

o o
Se basa en la compartimentacin natural de un problema. Organiza los miembros del equipo para trabajar en partes del problema con poca comunicacin activa entre ellos.
32. Cohesin de equipos

o o o o o o o o o
Tendemos a usar la palabra equipo demasiado libremente en el mundo de los negocios, denominado equipo a cualquier grupo de gente asignado para trabajar junta. Pero muchos de estos grupos no parecen equipos. No tienen una definicin comn de xito o un espritu de equipo identificable. Lo que falta es un fenmeno que denominamos cuajar.

o
Un equipo cuajado es un grupo de gente tejido tan fuertemente que el todo es mayor que la suma de las partes.

o
Cuando el equipo empieza a cuajar, la probabilidad de xito empieza a subir. El equipo puede convertirse en imparable, un monstruo de xito. No necesita ser dirigidos de una manera tradicional y no necesitan que se les motive. Estn en su gran momento. Comparten una meta en comn
35. Tcnicas de coordinacin de proyectos

o o o o o
Formal, enfoque impersonal. Formal, procedimientos interpersonales. Informal, procedimientos interpersonales. Comunicacin electrnica. Red interpersonal.
36. Formal, enfoque impersonal

o
Incluyen documentos de Ingeniera del SW y entregas (Cod. fuente) memorandos tcnicos, planificaciones del programa y herramientas de control del proyecto, peticiones de cambios, informes de seguimiento de errores e informacin de estado e inspecciones de diseo y de cdigo.
37. Formal, procedimientos interpersonales
Se concentra en las actividades de garanta de calidad. Aplicada a productos de ingeniera del SW. Incluyen reuniones de revisin de estado e inspecciones de diseo y de cdigo.
38. Informal, procedimientos interpersonales

o
Incluye reuniones de grupo para la divulgacin de informacin y resolucin de problemas. Definicin de requisitos y del personal de desarrollo.
39. Comunicacin electrnica

o o o o
Agrupa correo electrnico. Boletines de noticias electrnicos. Pgina WEB. Sistemas de video conferencia.
40. Red interpersonal

o
Discusiones informales con personas que no estn en el proyecto pero que pueden tener experiencia. discusin de puntos.
41. Problema
o o o o o o o o
El gestor del proyecto requiere estimaciones cuantitativas y un plan organizado. Pero no dispones de informacin slida. Un anlisis detallado de los requisitos dara la informacin necesaria para las estimaciones. A menudo lleva semanas o meses. Los requisitos pueden ser fluidos, cambiando a medida que progresa el proyecto. An as, necesita un plan YA.Debe examinar el problema justo al inicio del proyecto
42. mbito del SW

o o o o o o
La primera actividad de gestin es determinar el mbito del SW. Se define respondiendo a las siguientes cuestiones: Contexto. Objetivos de informacin. Funcin y rendimiento.
43. Contexto
o
Encajar el SW a construir en un sistema. La limitaciones se imponen como resultado del contexto.
44. Objetivos de informacin

o
Qu datos visibles se obtienen del cliente. Qu datos son requeridos de entrada.
45. Funcin y rendimiento

o
Qu funcin realiza el SW para transformar la informacin de entrada en una salida.
46. mbito de proyecto

o
Los enunciados del SW estar delimitados. N de usuarios simultneos, tamao de la lista de correo, mximo de T de respuesta.
47. Descomposicin del problema

o o o
El particionamiento, es el corazn del anlisis de requerimiento. Se aplica en: La funcionalidad que debe entregarse. El proceso que se emplear para entregarlo
48. Proceso
o o o o o o o o
El gestor del proyecto debe decidir qu modelo de proceso es le ms adecuado para el proyecto, despus debe definir un plan preliminar basado en un conjunto de actividades vlidas. Una vez establecido el plan preliminar, empieza la descomposicin del proceso. Se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades.
49. Maduracin del problema y proceso

o
La planificacin de un proyecto empieza con la maduracin del problema y del proceso. Todas las funciones se deben tratar dentro de un proceso de ingeniera por el equipo de SW. Conjunto de actividades:

Comunicacin con el cliente. Planificacin.
Anlisis de riesgo. Ingeniera. Construccin y entrega. Evaluacin del cliente.
50. Comunicacin con el Cliente

o
Tareas requeridas para establecer una comunicacin eficiente entre el desarrollador y el cliente.
51. Planificacin
o o o o
Tareas requeridas para definir los recursos, la planificacin temporal del proyecto y cualquier informacin relativa a l.
52. Anlisis de riesgo

o
Tareas requeridas para valorar los riesgos tcnicos y de gestin.
53. Ingeniera
o
Tareas requeridas para construir una o ms representaciones de la aplicacin.
54. Construccin y entrega

o o o
Tareas requeridas para construir, probar instalar y proporcionar asistencia al usuario.
55. Evaluacin del cliente

o o o o o o
Tareas requeridas para obtener informacin de la opinin del cliente basadas en la evaluacin de las representaciones de SW creadas durante la fase de ingeniera e implementacin durante la fase de instalacin
56. Gestin efectiva de un proyecto de software 57.

o o o
10 Causas de fracaso Solucin en busca de un problema. Solo el equipo del proyecto esta interesado en el resultado final.
o o o o o o o o
Nadie a cargo. Plan carece de estructura. Plan carece de detalle. Presupuesto inferior al requerido. Recursos asignados insuficientes. No hay seguimiento contra un plan. El equipo no se comunica. El proyecto se aparta de sus metas originales.
Gestin efectiva de un proyecto de software 58. Gestin Efectiva

o o o o o o o
Ambito de trabajo. Riesgos. Recursos. Tareas. Hitos. Esfuerzo. Plan.
59. Recursos - Software

o o o o o o o
Gestin de proyectos Soporte Anlisis y Diseo Programacin Prueba e Integracin Simulacin y creacin de prototipos Mantenimiento
60. Integracin de Sistemas 61.

o o o o o
La actividad de asumir responsabilidades contractuales por la combinacin de productos y/o servicios propios y/o de terceros en una solucin que satisfaga los requerimientos especficos del Cliente.
Integracin de sistemas 62. o Elementos Esenciales

o o o
Manejo del Riesgo. Manejo de Proyectos. Integracin y Testeo.
Integracin de sistemas 63. Integracin de Sistemas

o o o o o o
Componentes Tpicos Precio Fijo. Desarrollo Standard. Manejo de Subcontratistas. Test de Aceptacin. Garantizar el Funcionamiento.
64. Integracin de Sistemas 65. Integracin de Sistemas

o o o o o o o
Factores Crticos de xito Involucrarse tempranamente. Acordar relaciones de trabajo con el cliente. Acordar relaciones de trabajo con los distintos grupos. Efectiva utilizacin de terceras partes. Soporte continuo de la gerencia. Capacidad de gerenciamiento Tcnico y Comercial de los recursos y capacidades tcnicas. Mediciones /Incentivos apropiados. Seguimiento positivo de logros y xitos.
o o
66. Integracin de Sistemas

o o o
Qu es un contrato? Un acuerdo entre dos ms partes para hacer no hacer alguna cosa definida. Un acuerdo exigible por ley.
67. Desarrollo y Gerenciamiento

o
Objetivos del Manejo de Proyectos
Producir un resultado o producto definido en total concordancia con el presupuesto y cronograma.

o o
Consideraciones: Cada cliente tiene necesidades nicas. Cada proyecto tiene nico requerimientos, cronogramas, ambientes, etc.. Manejo de un proyecto debe ser: Flexible. Adaptado a un proyecto especfico. Trabajado/Adaptado continuamente para asegurar el xito.

o o o o
Principales causas de problemas Tomar compromisos anticipadamente a la definicin de requerimientos. Baja estimacin del alcance y complejidad del proyecto. Aceptar cambios sin una clara valoracin del impacto sobre el costo y plan del proyecto. No totalmente definido y/o manejado el riesgo. Incompleto manejo de los Subcontratistas.
o o

o o o o
La actividad de subcontratar desarrollo de Software es uno de los mayores riesgos. Para contener el riesgo se debe trabajar con los subcontratistas. Desarrollar un plan de gerenciamiento:

Asegurar que el/los subcontratista/s tengan aceptables desarrollos. Metodologa - Ciclo de vida de desarrollo. Estndares - Codificacin, Documentacin, Planes de Testeo, etc. Asegurarnos que los subcontratistas nos entienden. Requerimientos para inspecciones. Criterios de Aceptacin. Educar, entrenar y dar direccin de gerenciamiento donde hay dficit de conocimientos. Regularmente revisar sus progresos. Proveer un efectiva interface el/los sub/s y el Cliente.
Ayudarlos a tener xito.
71.
o o o o o
Gerente de Proyecto nico punto de responsabilidad para alcanzar todos los compromisos del Proyecto. Representar la empresa frente al cliente en todos los temas del Proyecto. Puede delegar tareas en otros pero retiene la totalidad de la Responsabilidad. El Cliente y cada subcontratista deben identificar un correspondiente Gerente de Proyecto como la primer interface.
Desarrollo y Gerenciamiento 72. o Manejo del Riesgo

o o o o
El manejo esta siempre presente a travs del ciclo de vida de un sistema. Desafiar cada suposicin hecha sobre el programa. La fase de propuesta es el perodo de tiempo Crtico. Se requiere Identificacin temprana, Evaluacin y Planeamiento de la contencin.
Desarrollo y Gerenciamiento 73. o Manejo del Riesgo

o
Resistir la tentacin de dimensionar el riesgo demasiado bajo. Una medida de la calidad de la propuesta es una realista y contenida evaluacin del riesgo. NO BAJO RIESGO. El Mayor Riesgo determina el Mayor Precio para el Cliente.
VERDADERO- Pero compartiendo parte de nuestra evaluacin de riesgo y planes de contencin con el cliente se demostrar nuestro profesionalismo.
Desarrollo y Gerenciamiento 74. o Sumario

o o o o o o o
El xito del Gerenciamiento de Proyecto requiere del Gerente de Proyecto y del Equipo del Proyecto: Entender El proceso de desarrollo. Los requerimientos. La solucin. Planificar
o o
La implementacin. La organizacin.
Desarrollo y Gerenciamiento 75. o Sumario

o o o o o o o o
Manejar Los recursos del Proyecto (Propios, del Cliente y Sucontratistas). El Plan. El Riego. Controlar El progreso. Los problemas. Los cambios.
Desarrollo y Gerenciamiento 76. Trabajo en Equipo De quin es el trabajo? 77. Primeras Restricciones
o o o
Fechas de entrega. Presupuesto. Disponibilidad del Personal.
78. Planificacin Temporal

o o o o o o
Identificar tareas. Fijar interdependencias entre tareas. Estimar esfuerzo de cada tarea. Asignar personal. Construir la red. Establecer el camino crtico.
79. Anlisis de Riesgos

o o o o o o
Identificacin. Clculo. Priorizacin. Estrategias de control. Resolucin. Supervisin.
80. Trabajo en Equipo

o
Esta es la historia acerca de cuatro personas llamadas TODOS, ALGUIEN, CUALQUIERA y NADIE . Haba que cumplir una tarea muy importante, y se le orden a TODOS hacerla. TODOS estaban seguros de que ALGUIEN lo hara, pero NADIE lo hizo. ALGUIEN se enoj, porque era un trabajo de TODOS. TODOS pensaron que CUALQUIERA pudo haberlo hecho, pero NADIE se dio cuenta de que TODOS no lo iban a hacer. Al fin, TODOS acusaron a ALGUIEN cuando NADIE hizo lo que CUALQUIERA pudo haberlo hecho.

o o
Una aproximacin: Una reunin de gente trabajando coordinadamente, por un objetivo comn, que logra un mejor resultado que los que obtendran los mismos individuos trabajando por su cuenta.

o
Qu es Trabajo en Equipo? (por lo que No es) No es reunionismo. No es necesariamente toma de decisiones en equipo. No es perdida de individualidad. No es perdida de autoridad.

o
Qu es Trabajo en Equipo? (por lo que Si es) Tener un objetivo meta comn. Estar dispuesto a sacrificar intereses. personales del grupo, momentneamente. Tener confianza en los dems. Disposicin a compartir informacin. Sentir en carne propia los problemas ajenos.

o
Diagnosticando la salud del grupo Intercomunicacin entre los miembros del grupo. Objetividad del grupo con respecto a su propio funcionamiento.
Responsabilidad interdependiente de todos los miembros. Adecuada coherencia del grupo.
85. Mtricas - Lnea Base

o o o o
Beneficios: Estratgicos. Proyecto. Tcnicos.
86. Por qu fallan las estimaciones ? 87. Factores claves

o o o o o o o o
Cambio constante en los requerimientos. Falta de tcnicas. Falta de planificacin. Ausencia de recaudos. Falta de conocimiento de procesos de estimacin. Mal manejo de problemas polticos. No tomar como base casos anteriores. Factores clave para estimar bien: Disponibilidad de registros precisos sobre proyectos anteriores. Adopcin de metodologas estndar. Estos dos factores ayudaran a concebir las mtricas.
88.
o o o o
Factores Claves 89. Mtricas del proyecto Por qu mtricas ? 90. Mtricas Que miden Productividad Calidad Beneficios Futuras Estimaciones Medidas Directas Indirectas 91. Qu se puede medir ?
o o
El proceso del software (para mejorarlo). El proyecto del software (para ayudar a estimar, control de calidad, evaluacin de productividad, control de proyectos). Calidad del producto (para ayudar el la toma de decisiones tcticas a medida que el proyecto evoluciona).
92. Medidas , mtricas e indicadores
Medida: Indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto. Medicin: Es el acto de determinar una medida. Mtrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Indicador: Es una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del SW, del proyecto del SW o del producto en s.
o o
93. Mediciones del software

o
Las mediciones del mundo fsico se pueden clasificar de dos maneras: Medidas directas : Ej. Longitud de un tornillo Medidas indirectas : Ej. Calidad de los tornillos producidos, medidos contando los artculos defectuosos Las mtricas del SW, se categorizan de forma similar
Directas: lneas de cdigo producidas (LDC), velocidad de ejecucin, tamao de memoria Indirectas: funcionalidad, calidad, complejidad.
94. Costo y mtricas de calidad

o o
Defecto/fallo Vs. Error Defecto y fallo: son sinnimos dentro del contexto del proceso del software. Implican un problema de calidad que es descubierto una vez entregado el software al cliente. Error: Problema de calidad detectado por los ingenieros u otros dentro del proceso del software. Revisiones tcnicas formales Encontrar errores durante el proceso de forma que no se conviertan en defectos despus de la entrega. Tratar de descubrir errores al principio para que no se propaguen al paso siguiente del proceso del software.
95.
o o
Costo y mtricas de calidad 96. o Las actividades de diseo introducen entre el 50 al 65 % de todos los errores (y en ltimo lugar todos los defectos).
o
Sin embargo, se ha demostrado que las revisiones tcnicas formales (RTF) son efectivas en un 75 % a la hora de detectar errores. Con la deteccin y eliminacin de un gran porcentaje de errores, el RTF reduce el costo de los pasos siguientes en la fase de desarrollo y de mantenimiento.
Costo y mtricas de calidad 97. o Datos basados en Experiencia

o o o o o o
Implementating software inspections IBM Error descubierto en diseo cuesta corregirlo 1,0 unidad monetaria Tomando la medida como base Antes de la prueba 6,5 unidades Durante la prueba 15 unidades Despus de la entrega 60-100 unidades
Costo y mtricas de calidad 98. Indicadores Proyecto/Proceso

o
Indicadores de proceso: Permiten a una organizacin de ingeniera del software tener una visin profunda de la eficacia de un proceso ya existente. (las mtricas del proceso se recopilan de todos los proyectos y durante un largo perodo de tiempo) Indicadores de proyecto: Permiten al gestor de proyectos del SW (1) evaluar el estado de un proyecto en curso; (2) seguir la pista de los riesgos potenciales; (3) detectar la reas de problemas antes de que se conviertan en crticas; (4) ajustar el flujo y las tareas del trabajo; (5) evaluar la habilidad del equipo.
99. Mtricas orientadas al tamao

o
Si una organizacin mantiene registros sencillos, se puede crear una tabla de datos orientados al tamao. Mtricas simples - orientadas al tamaoErrores por KLDC (miles de lneas de cdigo, KiloLDC). Defectos por KLDC. Pginas de documentos por KLDC. Errores/persona-mes. LDC/persona mes. Para lograr buenas mtricas Utilice el sentido comn y una sensibilidad organizativa al interpretar datos de mtricas. No utilice mtricas para evaluar a particulares. Trabaje con profesionales y equipos para establecer objetivos claros y mtricas que se vayan a utilizar para alcanzarlos. No utilice nunca mtricas que amenacen a particulares y/o equipos. Factor de complejidad
100.
o o o o o
101.
o
o o
102.
o o o o o o o
Evaluar cada factor en una escala de 0 a 5 0 No influencia. 1 Incidental. 2 Moderado. 3 Medio. 4 Significativo. 5 Esencial.
103. o No sabemos si estamos mejorando

o
No podemos establecer metas
Qu pasa si no medimos? 104. o Duracin de entrevistas.

o o
Extrapolacin. Estndares de programacin.
Otras Tcnicas 105. Sugerencias para lograr buenas mtricas

o
Utilice el sentido comn y una sensibilidad organizativa al interpretar datos de mtricas. No utilice mtricas para evaluar a particulares. Trabaje con profesionales y equipos para establecer objetivos claros y mtricas que se vayan a utilizar para alcanzarlos. No utilice nunca mtricas que amenacen a particulares y/o equipos. Estimaciones - Factores de riesgo Tamao del esfuerzo. Grado de estructuracin, definicin y variabilidad. Complejidad basada en esfuerzos pasados. Ambito del Software Funcin. Rendimiento. Restricciones. Interfaces. Fiabilidad. Recursos
o o
106.
o o o
107.
o o o o o
108.
o o o o
Humanos. Hardware. Software. Reusabilidad. Control de calidad del software Control de calidad del software Mito La calidad del software es algo en lo que se empieza a preocupar una vez que se ha generado el cdigo. NO !
109. 110.
o o
111. o Calidad: Una caracterstica o atributo de algo.
Como atributo de un artculo, la calidad se refiere a las caractersticas mensurables.
Cosas que se pueden comparar con estndares: Longitud, color, etc Sin embargo el SW como entidad intelectual es mas difcil.
Complejidad ciclomtica, cohesin, lneas de cdigo.
Control de calidad del software 112. o Calidad

o
De Diseo: caractersticas que especifican los Ingeniera del SW para un artculo.(grado de materiales, tolerancias, especificaciones de rendimiento) Etapa de diseo. Calidad de concordancia: grado de cumplimiento de las especificaciones de diseo Etapa de implementacin
Control de calidad del software 113. o Control de calidad

o
Es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. Feedback Las actividades de control pueden ser

o o
Manuales Automatizadas Combinacin
Control de calidad del software 114. o Garanta de calidad: o aseguramiento de

o o o
La calidad, consiste en la auditora y las funciones de gestin. Esto asegura que la calidad del producto se est cumpliendo y de no ser as es responsabilidad del rea de control afrontar los problemas y revisiones
Control de calidad del software 115. o Costo de la calidad Incluye los costos asociados a la bsqueda de la calidad o relacionados en la obtencin de la calidad

Prevencin Planificacin de la calidad Revisiones tcnicas formales Equipo de pruebas Formacin Evaluacin Inspeccin en el proceso y entre procesos Mantenimiento de equipos Pruebas
Control de calidad del software 116. o Fallos (antes de ser entregados al cliente)
o
Revisin. Reparacin. Anlisis de modalidades de fallos. Fallos externos (ya entregado al cliente) Resolucin de quejas. Devolucin y sustitucin de productos. Soporte en lnea. Trabajo de garanta.
Control de calidad del software 117. Control de calidad del software

o o
La garanta de calidad del software (SQA)Software Quality assurance) es una
actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera del software.
118. o La SQA engloba un enfoque de gestin de calidad; tecnologa de ingeniera del software efectiva (mtodos y herramientas), revisiones tcnicas formales que se aplican durante el proceso del software; una estrategia de software multiescalada; control de la documentacin del software y de los cambios realizados, un procedimiento que asegure un ajuste a los estndares de desarrollo del software (cuando sea posible); y mecanismos de medicin y de generacin de informes. Control de calidad del software 119. o Calidad del software
o
Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado
Control de calidad del software 120. o Variacin entre muestras

o
Ejemplos : Circuitos integrados Rutina de bsqueda Hay que reducir la variacin es el centro de control de calidad.
Control de calidad del software 121. o Ejemplo: Queremos reducir la diferencia entre los recursos necesarios planificados para terminar proyecto y los recursos reales utilizados (personas, equipo y tiempo).

Reduccin de errores ocultos. Reduccin de diferencias de velocidad. Precisin en respuestas de soporte.
Control de calidad del software 122. Los requisitos del software son la base de las medidas de calidad.
Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del SW. Existe un conjunto de requisitos implcitos que a menudo no se mencionan (Ej. buen mantenimiento)
Control de calidad del software 123. o Actividades del SQA
Ingeniera del SW: Aplican mtodos tcnicos slidos y medidas, realizando revisiones tcnicas formales y llevando a cabo pruebas del software bien planificadas. Auditoria y control de gestin
Control de calidad del software 124. o Propsito del plan

o o o o
Referencia Gestin. Organizacin. Tareas. Responsabilidad. Documentacin. Propsito Documentos requeridos de ingeniera del software Otros documentos Estndares, prcticas y convenciones
Control de calidad del software 125. Manejo de Riesgo del Proyecto 126. Manejo de Riesgo del Proyecto Una Definicin En primer lugar, el riesgo concierne a lo que ocurra en el futuro. El hoy y el ayer ya no nos conciernen realmente, porque ahora ya estamos recogiendo los frutos de lo que sembramos en el pasado. La cuestin es si podemos, entonces, modificando nuestras acciones de este momento, crear una oportunidad para una situacin diferente y mas esperanzada de nuestro maana. Esto significa, en segundo lugar, que el riesgo implica un cambio que puede venir dado por cambios de opiniones, acciones lugares.(En tercer lugar), el riesgo implica una eleccin, y falta de certeza de que la eleccin sea la correcta. As, paradjicamente, el riesgo, como la muerte los impuestos, es una de las pocas cosas inevitables de la vida. Robert Charette 127.
o o
Manejo del Riesgo del Proyecto Que es Riesgo? Riesgo es un evento posible, indeseable y no planificable que puede resultar en la no concrecin de uno o ms de los objetivos del proyecto . El Riesgo tiene tres componentes

Un evento Probabilidad de ocurrencia de ese evento Impacto de ese evento
Nota : Todos los proyectos tienen riesgos. Si los riesgos son ignorados, Ud. esta incrementando la probabilidad que el proyecto pueda fallar de alguna manera. Manejo del Riesgo del Proyecto Porque Manejo del Riesgo? Para Proteger

128.
o o
Costo. Cronogramas. Requerimientos. Prevenir sorpresas Focalizarnos en producir la oferta correcta la primer vez. Prevenir a la gerencia por las crisis Prevenir/minimizar los problemas antes de su ocurrencia , si estos ocurren, antes que crezcan. Manejo del Riesgo del Proyecto El Manejo de Riesgo de un proyecto incluye los procesos relacionados con la identificacin, anlisis y tratamiento del riesgo del proyecto. Lo cual implica la maximizacin de los eventos positivos y la minimizacin de las consecuencias de los eventos negativos. Manejo del Riesgo del Proyecto Los principales procesos del Manejo de Riesgo del proyecto son: Identificacin del riesgo, determinando cuales riesgos son potenciales a afectar el proyecto, documentando las caractersticas de cada uno. Clasificacin del riesgo, evaluando riesgos e interacciones entre riesgos para dimensionar los resultados posibles del proyecto. Desarrollo de la respuesta al riesgo, definicin de los paso para la intensificacin de las oportunidades y el manejo de las amenazas. Control de la respuesta al riesgo, respondiendo a los cambios en el riesgo sobre el curso de accin del proyecto. Manejo del Riesgo del Proyecto Identificacin del Riesgo: Internos/Externos
o o o o
129.
o
130.
o o
131.
o o o
Asignaciones del Staff/Estimaciones de Costo. Campos del Mercado/Acciones del Gobierno. Del Proyecto
o o
Presupuestarios/de Agenda/de Recursos/del Cliente. Tcnicos Diseo/Implementacin/Tecnologa de Punta. Del Negocio Excelente Producto que Nadie Quiere/Prdida del Soporte de los gestores. Prdidas Presupuestarias y/o de Personal. Manejo del Riesgo del Proyecto Clasificacin del Riesgo:
132.
o o
Probabilidad de que riesgo ocurra (sea real). Consecuencias del riesgo sobre el proyecto. Actividades para la calificacin del riesgo. Establecimiento de una escala que refleje la probabilidad del riesgo. Definicin de las consecuencias del riesgo. Estimacin del impacto del riesgo. Documentacin de la exactitud general de la proyeccin del riesgo. Manejo del Riesgo del Proyecto Desarrollo de la respuesta al riesgo: Invalidacin
133.
o o o
Eliminacin de una amenaza, usualmente por eliminacin de la causa. Mitigacin Reduccin de la probabilidad de ocurrencia del riesgo, reduccin del impacto del riesgo en el proyecto ambos. Aceptacin
Activa, desarrollo de un plan de contingencia. Pasiva, aceptacin de una menor ganancia en caso de ocurrencia. Manejo del Riesgo del Proyecto Mensajes claves del Manejo de Riesgos Manejar el riesgo es esencial para el xito del proyecto. El riesgo incluye oportunidades de ganar as como potencialmente de perder. Manejar el riesgo requiere disciplina. El Manejo del riesgo es un proceso repetitivo hecho a travs del ciclo de vida del proyecto.
134.
o o o o o
El Riesgo puede ser MANEJADO
Procesos De Ingenieria Del Software - Document Transcript

1. PROCESOS DE INGENIERA DEL SOFTWARE Armando Cabrera Raquel Solano Mayra Montalvn Loja, Ecuador Loja, Ecuador Loja, Ecuador aacabrera@utpl.edu.ec rfsolano@utpl.edu.ec mamontalvan@utpl.edu.ec RESUMEN Cuando puedas medir lo que ests diciendo y expresarlo en nmeros, sabrs algo acerca de eso; pero cuando no puedes El proceso de Ingeniera del Software se basa en modelos, medirlo, cuando no puedes expresarlo en nmeros, tus mtodos y herramientas que sirven como una gua para los conocimientos sern escasos y no satisfactorios ingenieros del software durante el proceso de desarrollo, con la finalidad de mejorar la calidad de los proyectos, procesos y Lord Kelvin productos mediante la evaluacin y medicin de los mismos. El objetivo de las organizaciones desarrolladoras de estos modelos, La medicin en general tiene tres principales objetivos: entender procesos y metodologas es que en las empresas desarrolladoras qu ocurre durante el desarrollo y el mantenimiento, mejorar de software se los ponga en prctica para ver las mejoras en los nuestros procesos y nuestros productos y controlar lo que ocurre procesos de cada una de las fases de desarrollo. Otro tema en nuestros proyectos. Dentro de la gestin de proyectos de importante son los modelos del ciclo de vida del software, los desarrollo de software las mtricas juegan un papel importante cuales se basan en diferentes tcnicas y fases pero todos tienen un para entender, monitorizar, controlar, predecir y probar el mismo fin. desarrollo de software. Las mtricas son medio para asegurar la calidad en los PRODUCTOS / PROCESOS / PROYECTOS El fin de este trabajo es establecer un entorno general alrededor de SOFTWARE. las aplicaciones y definiciones actuales del Proceso de Ingeniera del Software, el mismo que puede reconocerse en dos niveles: el Objetivos primero involucra actividades tcnicas y de gestin durante la Los principales objetivos del desarrollo de este trabajo son: adquisicin, desarrollo, mantenimiento y retirada del software en el procesos del ciclo de vida del software y el segundo se refiere a Comprender los conceptos principales relacionados con la definicin, implementacin, valoracin, medicin, gestin, el proceso de ingeniera de software y ciclo de vida del cambios y mejoras de los procesos mismo del ciclo de vida del software. software. Algunos modelos estandarizados para la medicin de la Conocer los mtodos y modelos que se aplican calidad como lo son: CMMI e ISO 9000, son mencionados. actualmente en la ingeniera del software. Conocer los principales ciclos de vida del software. Trminos Generales Software, Procesos, Mtodos, Modelos, Desarrollo de Software, 2.ESTADO DEL ARTE Ingeniera del Software, Procesos del Software Palabras claves 2.1 Conceptos de procesos de ingeniera del CMMI software QIP Modelo gil RUP Modelo Cascada 1.INTRODUCCIN El proceso de ingeniera del software puede ser visto desde dos enfoques: El primero: ciclo de vida del software, procesos durante la adquisicin, desarrollo, mantenimiento y cierre y el segundo con definicin, implementacin, evaluacin, manejo, cambio y mejora del ciclo de vida del software El principal objetivo del manejo del proceso de vida de software es implementar nuevos o mejores procesos en prcticas actuales y Figura 1. Elementos del proceso de software [6] que sean aplicados en el desarrollo de software, tales modelos como CMMI, IDEAL, QIP, entre otros. 2. cuatro grandes fases: concepcin, elaboracin, construccin y transicin. Concepcin: Define el alcance del proyecto y desarrolla un caso de negocio. Elaboracin: Define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. Construccin: Crea el producto. Transicin: Transfiere el producto a los usuarios. En la Figura 1, se muestra los elementos principales del proceso de Software que son: Personal. Mtodos y Procedimientos y Herramientas y Tecnologas. En la Figura 2, se muestra los tipos de elementos para modelar o representar un Proceso de Software Figura 2. Tipos de elementos para modelar/representar un Proceso Software [6] 2.1.4Ciclo de vida del Software 2.1.1Proceso de Software Un concepto dado por IEEE 1074 [6] es, el ciclo de vida del software es una aproximacin lgica a la adquisicin, el Segn Piatini [2] El proceso de software es un conjunto coherente suministro, el desarrollo, la explotacin y el mantenimiento del de: polticas, estructuras organizacionales, tecnologas, software procedimientos y artefactos; que son necesarios para: concebir, Y otro concepto dado por ISO
12207 Es un marco de referencia desarrollar, instalar y mantener un producto software. que contiene los procesos, las actividades y las tareas 2.1.2Ingeniera del Software involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde Se puede decir que Ingeniera de software [1], es la disciplina o la definicin de los requisitos hasta la finalizacin de su uso rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad. 2.2Procesos de implementacin y cambios Existen algunos conceptos de Ingenierita del Software, a 2.2.1Modelos para Procesos de Implementacin y continuacin se lista conceptos de autores ms reconocidos: Cambios Ingeniera de Software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de A continuacin se trata dos modelos principales para sistemas software (Zelkovitz, 1978) mejoramiento de procesos: Modelo IDEAL y modelo QIP (Quality Improvement Paradigm) Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin 2.2.1.1Modelo IDEAL asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como Desarrollo de Software o Produccin de Software (Bohem, 1976). Ingeniera de Software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972). Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la ingeniera al software (IEEE, 1993). 2.1.3Proceso de Ingeniera del Software El proceso de ingeniera de software [3], se define como "un conjunto de etapas parcialmente ordenadas con la intencin de Figura 3. Modelo IDEAL [23] lograr un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998]. A este proceso El modelo IDEAL [4], es un ciclo de mejoramiento de procesos, tambin se le llama el ciclo de vida del software que comprende proporciona un conjunto de actividades coherentes para sustentar 3. la adopcin de las prcticas recomendadas por el CMM, teniendo variaciones de una entidad a otra dependiendo del tipo de industria de software, tamao de organizacin y modalidades de operacin. Las 5 fases principales que componen el modelo son: 1. Iniciar.- Establece los fundamentos bsicos para garantizar la iniciativa de mejoramiento de procesos. Cuyas actividades son: a. Estimulo para iniciar el mejoramiento b. Establecimiento del contexto c. Establecer patrocinio de la gerencia d. Establecer infraestructura para el mejoramiento e. Evaluar y caracterizar el estado actual de las practicas Figura 4. Modelo QIP [24] f. Desarrollar recomendaciones y documentar los resultados de la fase Otro de los modelos reconocidos es el modelo QIP [5] El propsito de este modelo es apoyar el proceso de mejora continua 2. Diagnosticar.- Evala mediante un mtodo formal las y la ingeniera de los procesos de desarrollo, para ayudar en la fortalezas y debilidades del proceso seguido por los tecnologa de perfusin. Una forma de ver el modelo es tambin proyectos. Las principales actividades son: verlo como un modelo para la organizacin de aprendizaje, donde a. Evaluar y caracterizar el estado actual de las la organizacin establece una forma de desarrollar las prcticas a practicas travs de la experimentacin con ellos y, a continuacin, la captura y el paquete en una forma que pueden ser reutilizados en b. Desarrollar recomendaciones y documentar otras partes, dentro de ciertos lmites. los resultados de la fase QIP esta basado en las principales disciplinas del software, por 3. Establecer.- realiza la planificacin especifica de los eso es natural, revolucionario y experimental. El trabajo para mejoramientos que desea alcanzar. Principales desarrollo de software se basa en los humanos y su diseo de actividades: trabajo. a. Establecer los equipos de accin de procesos 2.3Definicin de procesos b. Elaboracin del Plan de Accin 2.3.1Modelos del ciclo de Vida del Software 4. Actuar.- Implementa el mejoramiento de procesos Existen varios modelos del ciclo de vida del software, sin llevando a cabo el plan de accin. Sus caractersticas embargo los mas utilizados son: Cascada, Prototipado, son: Incremental y en Espiral a. Planificar, ejecutar y seguir la instalacin b. Planificar y ejecutar proyectos piloto 2.3.1.1Cascada c. Refinar la solucin d. Implementar la solucin 5. Difundir.- Aprende de la experiencia del ciclo recin realizado y aumenta la habilidad de la empresa u organizacin para mejorar los procesos en forma continua. Sus caractersticas son: a. Documentar y analizar las lecciones. b. Revisar el enfoque seguido y proponer acciones futuras. 2.2.1.2Modelo QIP Figura 5. Modelo en Cascada [6] Este modelo es conocido tambin como ciclo de vida lineal o bsica. Este modelo admite la posibilidad de hacer iteraciones. Se 4. define como una secuencia de fases como se muestra en la Figura El modelo prototipado [26], modela el producto final y permite 5, en la que al final de cada una de ellas se rene la efectuar un test sobre determinados atributos del mismo sin documentacin para garantizar que cumple las especificaciones y necesidad de que este disponible. Se trata, simplemente, de testear los requisitos antes de pasar a la fase siguiente. [25] haciendo uso del modelo. Esta tcnica puede ser utilizada en Sus principales caractersticas son [6]: cualquier etapa de desarrollo. A medida que el
proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez ms Cada fase empieza cuando se ha terminado la fase las caractersticas del producto final. En la Figura 6 se listan las anterior fases del modelo Prototipado. Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa Existen varios tipos como: Al final de cada fase el personal tcnico y los usuarios Prototipado Rpido tienen la oportunidad de revisar el progreso del Prototipado Evolutivo proyecto Prototipado Operacional Prototipado Reutilizable Las ventajas y desventajas [21], de este modelo se describen a continuacin: Los prototipos [6], tienen una doble funcin: El cliente ve el producto y refina sus requisitos 2.3.1.1.1Ventajas El desarrollador comprende mejor lo que necesita hacer Ayuda a prevenir que se sobrepasen las fechas de Sus principales caractersticas son: entrega y los costes esperados Bajo riesgo para desarrollos bien comprendidos Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuario utilizando tecnologa conocida. o Reduce costos y aumenta la probabilidad de Este modelo es sencillo ya que sigue los pasos intuitivos xito necesarios a la hora de desarrollar el software. o Exige disponer de las herramientas adecuadas o No presenta calidad ni robustez 2.3.1.1.2Desventajas Suele utilizarse principalmente en dos reas: Su inflexibilidad en la divisin del proyecto en distintas o Prototipado de la interfaz de usuario etapas o Prototipado del rendimiento Esto hace difcil poder responder a los cambios en los Las ventajas y desventajas [27], [28], se listan a continuacin: requerimientos del cliente. 2.3.1.2.1Ventajas Se tarda mucho tiempo en pasar por todo el ciclo El mantenimiento se realiza en el cdigo fuente Las revisiones de proyectos de gran complejidad son Es mucho mejor y conveniente usar este modelo porque muy difciles es el nico apto para desarrollos en los que se utiliza nueva tecnologa. Para obtener resultados se debe llegar a la etapa final del proyecto. Un error importante no detectado hasta El prototipado es un medio excelente para recoger la que el programa este funcionando puede ser desastroso. realimentacin del usuario final, as como tambin es mucho ms rpido de desarrollarse. 2.3.1.2Prototipado El cliente se va familiarizando con el nuevo producto. Permite proporcionar una funcionalidad til en manos del cliente sin tener la aplicacin finalizada. 2.3.1.2.2Desventajas No hay que usar en casos experimentales ya que no puede funcionar. La gestin de desarrollo que es lenta porque da vueltas hasta que el usuario este de acuerdo, o se pongan limites. Imposibilidad de conocer a priori el tiempo de desarrollo Es muy difcil y complejo realizarlo 2.3.1.3Iterativo e Incremental Estos modelos disminuyen riesgos y nos ayudan a tener un mejor desarrollo de software ya que se basan en la retroalimentacin por lo que nos ayudan a tener una mejor arquitectura del software y Figura 6. Modelo Prototipado [6] son muy tiles cuando el usuario tiene ms requerimientos. 5. El modelo iterativo: Este modelo mejora cada versin Difcil de aplicar a sistemas transaccionales que tienden es decir mejora la funcin que tiene la versin. a ser integrados y a operar como un todo. El modelo incremental: Este modelo mantiene la Los errores en los requisitos se detectan tarde y su funcin anterior y aumenta otra, ya que puede ser que el correccin resulta costosa primer incremento no hubiera tenido todos los Necesitan una gran planeacin. requerimientos que necesitaba el proyecto. Debido a la interaccin con los usuarios finales, cuando sea necesaria la retroalimentacin hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a avances extremadamente lentos. No es una aplicacin ideal para desarrollos en los que de antemano se sabe que sern grandes en el consumo de recursos y largos en el tiempo. Al requerir constantemente la ayuda de los usuarios finales, se agrega un costo extra a la compaa, pues mientras estos usuarios evalan el software dejan de ser directamente productivos para la compaa. 2.3.1.4En espiral Figura 7. Modelo Iterativo e Incremental [6] En la Figura 7, se muestra el modelo Incremental, en este modelo se aplican secuencias lineales de forma escalonada mientras progresa el calendario. Sus principales caractersticas son: Corrige la necesidad de una secuencia no lineal de pasos de desarrollo El sistema se crea aadiendo componentes funcionales al sistema incrementos El sistema no se ve como una entidad monoltica con una fecha fija de entrega, sino que es una integracin de resultados sucesivos obtenidos despus de cada iteracin Figura 8. Modelo en Espiral [6] Se ajusta a entornos de alta incertidumbre El modelo en Espiral que se muestra en la Figura 8, es un modelo Las ventajas y desventajas de este modelo son [30] [32]: de proceso de software evolutivo que combina la naturaleza iterativa de construccin de prototipos con los aspectos 2.3.1.3.1Ventajas controlados y sistemticos del modelo lineal secuencial. Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. Segn Wikipedia [31], las actividades de este modelo se El usuario se involucra ms. conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn Mayor retorno de la inversin. fijadas a priori, sino que las siguientes se eligen en funcin del Disminuyen riesgos anlisis de riesgo, comenzando por el bucle interior. El software Se puede cambiar los requerimientos pues como nos se desarrolla en una serie de versiones incrementales. basamos en una
versin a esta la aumentamos o la modificamos. Durante las primeras iteraciones, la versin incremental Reduce costos, si algo sale mal solo volvemos a la podra ser un modelo en papel o un prototipo. antigua versin y comenzamos de nuevo. Durante las ltimas iteraciones, se producen versiones Al usuario se le entrega parte del producto, es decir una cada vez ms completas del sistema diseado. versin con la cual el puede trabajar. Sus principales caractersticas son: 2.3.1.3.2Desventajas Cada ciclo empieza identificando: Difcil de evaluar el coste total. o Los objetivos de la porcin correspondiente Requiere gestores experimentados. 6. o Las alternativas Demostrar valor iterativamente. o Restricciones Elevar el valor de abstraccin. Se evalan las alternativas respecto a los objetivos y las Enfocarse en la calidad. restricciones. Se formula una estrategia efectiva para resolver las 2.3.2.1.1Ciclo de vida de RUP fuentes de riesgos (simulacin, prototipado, etc.). Se plantea el prximo prototipo. El proceso del RUP est dividido en 4 fases, en estas fases se Una vez resueltos los riesgos se sigue el ciclo en realiza varias iteraciones de acuerdo al proyecto, en la Figura 9 se cascada muestra grficamente las 4 fases del RUP, cuyas iteraciones estn Cada ciclo se completa con una revisin que incluye representadas con lneas verticales y marcadas con la letra todo el ciclo anterior y el plan para el siguiente. correspondiente a la inicial de la fase, la fase Inicial tiene una sola iteracin. Las ventajas y desventajas de este modelo son [31]: 2.3.1.4.1Ventajas No necesita una definicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el final de la primera iteracin es mas fcil validar los requisitos El riesgo en general es menor, porque si todo se hace mal , solo se ha perdido el tiempo y recursos invertidos en una iteracin El riesgo de sufrir retrasos es menor ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos, El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Figura 9. Fases del RUP [35] Integra el desarrollo con el mantenimiento, etc. 2.3.2.1.2Fase de Inicio 2.3.1.4.2Desventajas Es difcil evaluar los riesgos En esta fase se define el modelo del negocio y el alcance del Necesita de la participacin continua por parte del proyecto, se identifican los autores y casos de usos y se disean cliente los casos de uso esenciales. Cuando se subcontrata hay que producir previamente Los objetivos son: una especificacin completa de lo que se necesita y esto lleva tiempo. Establecer el mbito del proyecto y sus limites Genera mucho tiempo en el desarrollo del sistema Encontrar los casos de uso crticos del sistema, los Modelo costoso requiere experiencia en la escenarios bsicos. identificacin de riesgos Mostrar una arquitectura para los escenarios principales. Estimar el coste en recursos y tiempo en todo el 2.3.2Metodologas de desarrollo de software proyecto. Estimar los riesgos, las fuentes de incertidumbre. 2.3.2.1RUP Los resultados de la fase son: Documento de visin RUP [35] es un proceso para el desarrollo de un proyecto de Modelo inicial de casos de uso software que define quien, como, cuando y que debe hacerse en el Glosario inicial proyecto, con 3 caractersticas esenciales como: Casos de uso, centrado n la arquitectura y es iterativo e incremental. Caso de negocio Lista de riesgos y plan de contingencia El RUP maneja 6 principios clave: Plan del proyecto Adaptacin del proceso. Modelo de negocio Balancear prioridades. Colaboracin entre equipos. 7. 2.3.2.1.3Fase de Elaboracin configuracin, instalacin y facilidad de uso del producto. En esta fase tambin se realiza: En esta fase se analiza el dominio del problema, establece los cimientos de la arquitectura, desarrolla el plan del proyecto y La prueba de la versin beta para validar al nuevo elimina los riesgos mayores. Se construye un prototipo de la sistema frente a las expectativas del usuario. arquitectura que evoluciona en iteraciones sucesivas hasta Funcionamiento paralelo con los sistemas legados que convertirse en el sistema final. estn siendo sustituidos por el nuevo proyecto. Los objetivos de esta fase son: Conversin de las bases de datos operacionales. Definir, validar y cimentar la arquitectura. Entrenamiento de los usuarios y tcnicos de Completar la visin mantenimiento. Crear un plan para la fase de construccin Traspaso del producto a los equipos de marketing, Demostrar que la arquitectura propuesta soportara la distribucin y venta. visin Los objetivos de esta fase son: Los resultados son los siguientes: Un modelo de casos de uso al menos el 80% Conseguir que el usuario se valga por si mismo. Requisitos adicionales que capturan los requisitos no Un producto final que cumpla los requisitos esperados, funcionales. que funcione y satisfaga suficientemente al usuario. Descripcin de la arquitectura software Los resultados son: Prototipo ejecutable de la arquitectura. Lista de riesgos y caso de negocio revisados Plan de desarrollo para el proyecto Prototipo operacional Manual de usuario preliminar. Documentos legales Caso del negocio completo Lnea base del producto completa y corregida que 2.3.2.1.4Fase de Construccin incluye todos los modelos del sistema Descripcin de la Arquitectura completa y corregida. En esta fase la finalidad es alcanzar la capacidad operacional del Las iteraciones de esta fase irn dirigidas normalmente producto de forma incremental a
travs de las sucesivas a conseguir una nueva versin. iteraciones, en esta fase todas las componentes, caractersticas y requisitos deben ser implementados, integrados y cambiados en su Los criterios de evaluacin de esta fase son: totalidad. Los objetivos son: El usuario se encuentra satisfecho. Minimizar los costes de desarrollo mediante la Son aceptables los gastos actuales versus los gastos planificados. optimizacin de recursos. Conseguir calidad adecuada. Conseguir versiones funcionales tan rpido como sea prctico. 2.3.2.2MSF Los resultados de la fase de construccin deben ser: La metodologa MSF (Microsoft Solucion Framework) [40], es flexible e interrelacionada con una serie de conceptos, modelos y Modelos completos(casos de uso, anlisis, diseo, prcticas de uso, y guas para disear y desarrollar soluciones despliegue e implementacin) empresariales de una manera que asegura que todos los elementos Arquitectura integra. del proyecto tal como gente, procesos y herramientas, puedan ser Riesgos presentados mitigados exitosamente conducidos. Plan del proyecto para la fase de transicin. Manual inicial de usuario. MSF no slo es aplicable al desarrollo de proyectos de desarrollo, Prototipo operacional. tambin es aplicable a otros proyectos de TI, como el despliegue Caso del negocio actualizado. o proyectos de infraestructura o redes. MSF no fuerza al desarrollador a utilizar una metodologa especfica (Cascada, 2.3.2.1.5Fase de Transicin gil), pero les permite decidir qu mtodo utilizar. En esta fase se pone el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentacin, entrenar al usuario en el manejo del producto y tareas relacionadas con el ajuste, 8. Escalable: Puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: Es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: Porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa. Principios fundamentales en los que se basa MSF MSF propone una secuencia generalizada de actividades para la construccin de soluciones empresariales, este proceso es flexible y se puede adaptar al diseo y desarrollo de una amplia gama de proyectos de una empresa, adems est basado en fases, puntos de transicin y de carga de forma iterativa que se puede aplicar en el desarrollo de aplicaciones tradicionales, soluciones empresariales para comercio electrnico as como aplicaciones Web distribuidas. Los principios en los que se fundamenta MSF son: Figura 10. Fases del modelo MSF [41] Fomentar la comunicacin abierta. El MSF est compuesto 6 por fases, como se muestra en la Figura Trabajar en pro de una visin compartida. 10, las fases se listan a continuacin: La autonoma de los miembros del equipo. 1. Visin: donde se rene un equipo del proyecto, define Establecer una clara rendicin de cuentas y la la visin y el mbito de una solucin que cumplir los responsabilidad compartida. objetivos del cliente. El equipo organiza entonces el Centrarse en entregar valor de negocio. proyecto y proporciona un documento de visin/mbito Mantenerse gil a espera del cambio. aprobado. Las personas encargadas de funciones de Invertir en calidad. administracin de productos y administracin de Aprender de todas las experiencias. programas toman el mando en esta fase. 2. Planeacin: donde se desarrollan los procesos de MSF para Metodologas de Desarrollo gil (MSF4ASD) diseo conceptual, lgico y fsico, as como la MSF para Metodologas de Desarrollo gil es un proceso de especificacin funcional. La persona encargada de desarrollo manejado por escenarios, basado en contexto, que funciones de administracin de programas toma el utiliza muchas de las ideas incorporadas en Team System mando durante esta fase y crea planes de proyecto que (herramientas de Microsoft). Este proceso incorpora las prcticas tratan el desarrollo, la comunicacin y otras tareas; y probadas desarrolladas en Microsoft con respecto a los cada funcin proporciona los datos para crear la requerimientos, diseo, seguridades, rendimiento y pruebas programacin del proyecto. (testing) [42]. MSF para metodologas de desarrollo gil presenta una gua 3. Desarrollo: El equipo crea y prueba la solucin. La persona encargada de funciones de desarrollo toma el muy recomendable a los Desarrolladores y Gestores de proyectos mando durante esta fase. de software que pueden adaptarla a la metodologa de su empresa, en la que incluye documentos de ejemplo, plantillas, archivos en 4. Estabilizacin: El equipo crea la solucin piloto en blanco de Project, Excel y Word para la administracin de preparacin para el lanzamiento de produccin. La proyectos, requerimientos, seguridad y pruebas. persona encargada de las funciones de prueba toma el mando durante esta fase. MSF para CMMI (MSF4CMMI) EL MSF4CMMI para CMMI es una metodologa formal para la 5. Instalacin. ingeniera de software es un proceso de mejora que proporciona a las organizaciones los elementos esenciales del proceso continuo 6. Soporte de mejora que den lugar a una reduccin de Ciclo de vida del Las caractersticas ms relevantes del MSF son: Desarrollo de Software, la mejora de la capacidad para satisfacer Adaptable: Es parecido a un comps, usado en las metas de costos y el calendario, la construccin de productos cualquier parte como un mapa, del cual su uso es de alta calidad. limitado a un especfico lugar. El MSF4CMMI se ha ampliado una orientacin MSF4ASD con una formalidad adicional, evaluacin, verificacin y auditora [43].
9.
Una de las ventajas de utilizar el proceso CMMI es el estndar de Essential Unified EssUP evaluacin por la que uno puede comparar la capacidad de Process desarrollar software en otras organizaciones. Feature Driven FDD De Luca & Coad Development 1998 Palmer & 2.3.2.3Modelo gil Felsing 2002, Lean LD Charette 2001, Development El Modelo de Desarrollo gil se origin a mediados de los aos Mary y Tom 1990 y se podra decir que fue extrado del modelo de desarrollo Poppendieck en cascada, pues ste ltimo era visto como burocrtico, lento, Programacin XP Beck 1999 degradante e inconsistente por lo exigente y muy estructurado en Extrema sus formas de desarrollo de software que sin embargo realizaban un trabajo eficiente. Scrum Scrum Sutherland 1994 En el ao 2001, miembros prominentes de la comunidad de la Schwaber 1995 industria del software se reunieron en Sonwbird, Utah, y Microsoft MSF Microsoft 1994 adoptaron el nombre de "Metodologas giles"[36]. Solutions El modelo de desarrollo gil es un paradigma de Desarrollo de Framework Software que utiliza procesos giles (pequeas y frecuentes Rapid RAD McConnell 1996 entregas con ciclos rpidos) enfocados en la gente y resultados, se Development podra decir que es: Open Unified OpenUP Cooperativo, clientes y desarrolladores trabajan constantemente con una comunicacin muy fina y Process constante, Rational Unified RUP Krutchen 1996 Sencillo, mtodo fcil de aprender y modificar para el Process equipo pues la reduccin de documentacin se reemplaza por la constante comunicacin, y Algunas empresas que usan metodologas de desarrollo gil en Adaptativo, capaz de permitir cambios de ltimo algunos de sus proyectos, son: momento. Google, El objetivo de este modelo es desarrollar software rpidamente, respondiendo a los cambios que puedan surgir a lo largo del Oracle, proyecto. Yahoo, Canon, Esta metodologa propone que un pequeo grupo de personas (10 como mximo) conformado de los ms experimentados y capaces Xerox, ingenieros de software, trabajen en el desarrollo de iteraciones Sun, (software desarrollado en una unidad de tiempo) con una duracin HP, mxima de hasta 4 semanas y desarrollando una serie de user Nokia, stories (Casos de Uso) que al final cumplan con los Honda, requerimientos establecidos en lnea directa por los usuarios Toyota, etc. finales del sistema [37]. 2.3.2.3.2Ventajas: 2.3.2.3.1Metodologas Agiles Mtodos de comunicacin ms eficaces en este tipo de Hacemos mencin de algunas metodologas giles de desarrollo metodologas. de software en la Tabla 1, estas metodologas son: Es posible identificar y atacar los problemas ms crticos y controversiales del proyecto en las primeras Tabla 1. Lista de Metodologas giles etapas. El cliente comenzar a ver su sistema lo ms pronto Metodologa Acrnimo Creacin posible y verificar que se estn cubriendo sus Adaptive ASD Highsmith 2000 requerimientos de forma adecuada. Software Entrega de resultados tangibles en etapas tempranas del Development proyecto. Agile Modeling AM Ambler 2002 2.3.2.3.3Desventajas: Agile RUP dx Booch, Martin, Proceso menos controlado y con pocos principios. Newkirk 1998 No existe contrato tradicional o al menos es bastante Crystal Methods CM Cockbum 1998 flexible.
10. Grupos pequeos, trabajando en el mismo sitio y no documentacin de actividades de mantenimiento de distribuidos adecuadamente. software. Menos nfasis en la arquitectura del software, siendo sta primordial para el xito del proyecto de software. 2.3.3.2.2 ISO 14764:1998 2.3.2.3.4Uso de Metodologas ste estndar internacional como es ISO 14764 [34] aclara los requerimientos para el Proceso de Mantenimiento del Software. El Mantenimiento del Software es un proceso primario en el ciclo El surgimiento de estas revolucionarias metodologas que no solo de vida de un producto software. En muchos proyectos, nacen para el desarrollo de sistemas software sino para el manejo especialmente aquellos que tienen una vida larga, el o desarrollo de productos los incrementos en adeptos se presentan mantenimiento del software es con seguridad una de las gradualmente con el tiempo y las tecnologas. En la Figura 11, se consideraciones ms importantes del proyecto. Por esta razn es muestra [38] necesario ser capaces de corregir los fallos que se encuentran durante su manejo. Mantenimiento de Software se puede hacer combinando herramientas software, mtodos y tcnicas, se aplica a programas de ordenador, cdigo, datos, y documentacin. Se intenta que se aplique a productos software creados durante el desarrollo del producto software. ste estndar internacional est pensado para su uso en todos los esfuerzos de mantenimiento, independientemente del ciclo de vida o del enfoque usado en el desarrollo. 2.3.3.3ISO 9001-2000 Figura 11. Uso de Mtodos giles [38] El estndar o norma ISO 9001:2000 (Quality management systems Requirements) que significa Calidad del manejo de requerimientos del sistema, especifica los requerimientos para el 2.3.3Procesos del ciclo de vida del Software manejo de la calidad de un sistema organizacional proveyendo requerimientos de los productos y satisfaccin del cliente. Primario se basa en la calidad del software, y segundo en los 2.3.3.1Estndar IEEE 1074 procesos de ingeniera del software. El estndar IEEE 1074 [7] y [8], es un estndar para la generacin de los que rigen el proceso de desarrollo de software y mantenimiento de un proyecto. Este estndar requiere la seleccin 2.4Evaluacin de Procesos de
proyectos de software y modelos de ciclo de vida, basado en la misin, visin, metas y recursos de las organizaciones. Tambin 2.4.1Modelos de Evaluacin del proceso describe las diferentes actividades que van a ser asignada en el modelo seleccionado. Sin embargo, este estndar no es una gua 2.4.1.1CMMI de instruccin. Tambin puede ser utilizado para desarrollar los procesos de organizacin para apoyar el desarrollo de software y CMMi intenta proveer una gua para los procesos. Las reas procesos que tiene una nica funcin dentro de un proyecto. especficas relacionadas son: 2.3.3.2Procesos de Mantenimiento: Calidad de proceso y producto 2.3.3.2.1 IEEE 1219-1998 Verificacin del proceso Validacin del proceso El estndar IEEE 1219-1998 [9], se basa en procesos iterativos para ejecutar y manejar el mantenimiento de software. Hubo inicialmente algn debate sobre si la ISO 9001 o CMMi Los procesos estn aplicados a: podran ser usadas por los ingenieros del software para asegurar la calidad. Este debate fue publicado y como resultado la decisin Planeacin de mantenimiento mientras el producto est ha sido tomada que los dos son complementarios y que desarrollndose. teniendo certificacin ISO 9001 puede ayudar grandiosamente en Planeacin y ejecucin de mantenimiento para altos niveles de madurez del CMMi. [6] productos de software existente. El modelo CMMI es un modelo de calidad del software que Aplica cualquiera de los modelos del ciclo de vida clasifica las empresas en niveles de madurez. Estos niveles sirven disponibles. para conocer la madurez de los procesos que se realizan para Estndares prescriben los requerimientos para procesos, producir software. control y manejo de la planeacin, ejecucin y 11. 2.4.2Mtodos de evaluacin del proceso Estos medos fueron desarrollados por el SW-CMM Planificar el Proceso de Medicin que implica tareas como: 2.4.2.1CBA-IPI o Obtener caractersticas de la Organizacin. o Identificar las necesidades de la Informacin. El CBA-IPI [39], es un mtodo de evaluacin basado en CMM o Seleccionar las medidas. sirve para mejorar internamente los procesos, fue desarrollado por o Definir los procedimientos de recoleccin de el Softare Engneer Institute de la Universidad Carnegie Mellon. datos, anlisis e informes. Es una herramienta de diagnostico que permite a las o Definir los criterios de evaluacin de los organizaciones y proyectos el poder determinar las fortalezas y de productos de informacin y el proceso de sus procesos de desarrollo de software, utiliza el mtodo de medicin. madurez de capacidades para software desarrollado por el SEI o Revisar, aprobar y proporcionar recursos para las tareas de medicin. 2.4.2.2SCAMPI o Adquirir y utilizar tecnologas de apoyo. Los mtodos SCAMPI son grandes torres de evaluacin CMMi. Realizar el Proceso de Medicin que implica tareas Las actividades ejecutadas durante una evaluacin, la distribucin como: de esfuerzo en estas actividades como la atmosfera durante una o Integrar los procedimientos, evaluacin son diferentes cuando son de mejora para la o Recoger los datos, adjudicacin de un contrato. o Analizar los datos y desarrollar productos de informacin. o Comunicar los resultados. 2.5Medidas de Productos y Procesos Evaluar la Medicin que implica tareas como: o Evaluar productos de informacin y el La medicin de software es una disciplina relativamente joven, proceso de medicin, consenso general sobre la definicin exacta de los conceptos y o Identificar las mejoras potenciales. terminologa que maneja, aunque trminos clave de medicin del software y mtodos de medicin han sido definidos en la ISO/IEC 15939 basados en el vocabulario ISO internacional de metrologa. 2.5.1Medicin del Proceso: ISO 15539-02 A pesar de todo, los lectores encontrarn diferencias terminolgicas en la literatura; por ejemplo, el trmino mtrica La medicin del Proceso significa recoger, analizar e interpretar se utiliza a veces en vez de medida. En la Figura1 se muestra el informacin cuantitativa sobre nuestros procesos, para identificar mbito de ISO/IEC 15939: [10] las fuerzas y las debilidades de los mismos y para evaluarlos despus de que hayan sido implementados y/o cambiados. Muchos son los propsitos que abarca la medicin del Proceso en el presente caso de estudio nos centraremos en la medicin del proceso para gestionar un proyecto de software enfocado en la implementacin y cambio del proceso. El medir un proceso de software implica medir las actividades relacionadas con el software como por ejemplo el esfuerzo, el coste y los defectos encontrados, mientras que se pueden hacer algunos esfuerzos para valorar la utilizacin de herramientas y de hardware, un recurso principal que necesita ser gestionado en la ingeniera del software es el personal. Existen tres tipos de mtricas de proceso: Tiempo requerido para completar un proceso en particular: total del proyecto, por ingeniero, por actividad, etc. Recursos requeridos para un proceso en particular: esfuerzo en personas/da, costes de viajes, recursos de hardware, etc. Figura 12. mbito de la ISO/IEC 15939 [10] Nmero de Ocurrencias de un Evento nmero de defectos descubiertos durante la revisin del cdigo, Las actividades de la ISO/IEC 15939 son: nmero de peticiones de cambio en requerimientos, nmero promedio de lneas de cdigo (LDC) Establecer y Mantener el Compromiso de Medicin que modificadas en respuesta a un cambio de implica tareas como: requerimientos, errores detectados por el usuario, etc. o Aceptar los requisitos de medicin. o Asignar recursos.
12. Justificacin que el software satisfaga las necesidades del usuario), que son manifestadas externamente cuando el software es utilizado, y son La recoleccin de mtricas del proceso es esencial para la mejora un resultado de atributos internos del software. El modelo de del mismo y se utilizan para evaluar la eficiencia de un proceso y calidad de ISO 9126-1 establece 3 niveles: (1) Caracterstica, (2) si ste ha mejorado con los cambios realizados. Subcaracterstica y (3) Mtricas. [12] Las dos primeras mtricas ayudan a descubrir si los Caractersticas de calidad del ISO 9126-1:2001: cambios en el proceso mejoran la eficiencia de un Funcionalidad: conjunto de atributos que se relacionan proceso. Por ejemplo, se puede medir el tiempo y con la existencia de un conjunto de funciones y sus esfuerzo necesarios para moverse de un hitos fijo a otro, propiedades especficas. Las funciones son aquellas que como la aceptacin de requerimientos, terminacin de satisfacen lo indicado o implica necesidades. Las un diseo arquitectnico, etc. Esos valores ayudan a subcaractersticas son: Idoneidad, Exactitud identificar reas de mejora en el proceso. Una vez Interoperabilidad, Seguridad, Cumplimiento de normas. introducidos los cambios, las mediciones posteriores indican si los cambios han sido positivos. Fiabilidad: conjunto de atributos relacionados con la capacidad del software de mantener su nivel de El nmero de ocurrencias de un Evento Tienen prestacin bajo condiciones establecidas durante un influencia directa en la calidad del software. Por perodo de tiempo establecido. Las subcaractersticas ejemplo, incrementar el nmero de defectos son: Madurez, Tolerancia a fallas, Facilidad de descubiertos al cambiar el proceso de revisin del Recuperacin, Conformidad de Fiabilidad. cdigo probablemente se reflejar en una mejora de la calidad del producto, aunque tiene que confirmarse por Usabilidad: conjunto de atributos relacionados con el mediciones posteriores del producto. esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado Se describira a las salidas de los procesos como: calidad del conjunto de usuarios. Las subcaractersticas son: producto (errores por KLOC (Kilo Lneas de Cdigo) o por Punto Aprendizaje, Comprensin, Operatividad, Atractividad, Funcin (FP)), mantenibilidad (el esfuerzo para hacer un cierto Conformidad de Usabilidad tipo de cambio), productividad (LDC (Lneas de Cdigo)) o Puntos Funcin por persona-mes), tiempo-de-mercado, o Eficiencia: conjunto de atributos que se refieren a las satisfaccin del cliente (como medidos por medio de una encuesta relaciones entre el nivel de rendimiento del software y a clientes). Esta relacin depende del contexto particular (por la cantidad de recursos utilizados bajo unas condiciones ejemplo, el tamao de la organizacin o el tamao del proyecto). predefinidas. Las subcaractersticas son: Compartimiento en el tiempo, Compartimiento de De all que el obtener las salidas del proceso que deseamos recursos, Conformidad de eficiencia. significa que se debi haber implementado los procesos Mantenibilidad: conjunto de atributos relacionados con adecuados. la facilidad de extender, modificar o corregir errores en un sistema software. Las subcaractersticas de la 2.5.2Medicin del Producto: ISO 9126-01 Facilidad de Mantenimiento son: Facilidad de anlisis, Facilidad de cambio, Estabilidad y Facilidad de prueba. Qu es un producto de software? Portabilidad: conjunto de atributos relacionados con la Un producto de software se lo puede describir en un sentido capacidad de un sistema software para ser transferido extenso como: los ejecutables, cdigo fuente, descripciones de desde una plataforma a otra. Las subcaractersticas de la arquitectura, y as. Portabilidad son: Capacidad de instalacin, capacidad de reemplazamiento, Adaptabilidad y Co-Existencia. De all que las mtricas del producto se refieren a las caractersticas del propio software que incluye: la medicin del tamao del producto, la estructura del producto y la calidad del 2.5.2.2Mtricas Externas ISO 9126-2:2003 producto. Las cuales miden el software en s mismo o software en ejecucin Un estndar internacional para la evaluacin del Software es el (Calidad Externa Ambiente de Prueba). ISO 9126 supervisado por el proyecto SQuaRE, ISO 25000:2005. [11] Permite evaluar la calidad del software desde distintas 2.5.2.3Mtricas Internas ISO 9126-3: 2003 perspectivas relacionadas con el desarrollo, adquisicin, Las cuales miden el comportamiento del sistema, dichas mtricas requerimientos, uso, evaluacin, mantenimiento, aseguramiento se aplican cuando el software no est en ejecucin por ejemplo de la calidad. durante el diseo y codificacin. (Calidad Interna Ambiente de El estndar est dividido en cuatro partes las cuales dirigen, Desarrollo) respectivamente, lo siguiente: 2.5.2.4Calidad en UsoISO 9126-4: 2004 El cual mide el efecto de usar el software en un contexto 2.5.2.1Modelo de la Calidad especfico (Ambiente de Produccin). Describe el modelo de calidad del producto de software ISO 9126-2, ISO 9126-3 e ISO 9126-4 estn encaminados en especificando 6 caractersticas de calidad interna (evala el total ambientes de Prueba, Desarrollo y Produccin respectivamente. de atributos que un software debe satisfacer) y externa (evala 13. Quin puede utilizar esta norma? Desarrollo y mejora de los procesos de la Esta Norma puede ser usada por desarrolladores, evaluadores organizacin independientes y grupos de aseguramiento de la calidad Definicin de los procesos de la organizacin responsable de especificar y evaluar la calidad del software. Planificacin de la
formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones 3.MODELOS ESTANDARIZADOS DISPONIBLES Cuantitativamente Gestionado o Nivel 4 CMM CMMI: Nivel 4 a ms de contar con procesos definidos para el desarrollo de los proyectos se utilizan tcnicas cuantitativas 3.1CMMI para el control de los procesos, como pueden por ejemplo se CMMI es un modelo de calidad del software que clasifica las usan las mtricas para gestionar la organizacin. empresas en niveles de madurez. Estos niveles sirven para Los procesos que hay que implantar para alcanzar este nivel conocer la madurez de los procesos que se realizan para producir son: software. Gestin cuantitativa de proyectos 3.1.1Niveles CMM CMMI Mejora de los procesos de la organizacin Optimizado o Nivel 5 CMM CMMI Los niveles CMM - CMMI son 5: Los procesos de los proyectos y de la organizacin en este nivel a ms de ser cuantitativamente gestionados estn Inicial o Nivel 1 CMM CMMI: En este nivel pertenecen orientados a la mejora de las actividades mediante el uso de aquellas empresas que no tienen sus procesos bien definidos. mtricas. Caractersticas comunes de este tipo de empresas son: los Los procesos que hay que implantar para alcanzar este nivel presupuestos se disparan, no se entrega el proyecto en fechas son: establecidas, no hay control sobre el estado y desarrollo del Innovacin organizacional. proyecto. El simple hecho de existir como empresa de Anlisis y resolucin de las causas. software se est en el nivel1. 3.2ISO 9000 Repetible o Nivel 2 CMM CMMI: El objetivo que pretende alcanzar el nivel 2 es que los proyectos que lleve a ISO 9000 se refiere a una serie de normas internacionales que cabo las empresas se los ejecute con una adecuada gestin de define un sistema de Garanta de Calidad en las organizaciones: los procesos lo que implica planeacin, ejecucin, control, ISO 9001, ISO 9002, ISO 9003 e ISO 9004 (y sus subnormas) medicin de los mismos. Es un nivel difcil de alcanzar pues desarrollado por la Organizacin Internacional de Normalizacin al establecer procesos se est pretendiendo cambiar la forma (ISO). Esta norma ha sido adoptada por 90 pases en todo el de trabajar de la empresa que muchas de las veces implica un mundo y est compuesta por representantes de normas nacionales cambio cultural de la misma y por ende lo ms importante de ms de 100 pases. aqu es saber si se cuenta con el apoyo de la direccin para afrontar este cambio. Sin este apoyo no se podra alcanzar el La familia de normas apareci por primera vez en 1987 teniendo CMM-CMMI nivel 2. como base una norma estndar britnica (BS), y se extendi principalmente a partir de su versin de 1994, estando Los procesos que hay que implantar para alcanzar este nivel actualmente en su versin 2008, publicada el 13 de noviembre de son: 2008. La principal norma de la familia es actualmente la: ISO Gestin de requisitos 9001:2008 - Sistemas de Gestin de la Calidad - Requisitos. [15] Planificacin de proyectos Seguimiento y control de proyectos 3.2.1Proceso de Certificacin Gestin de proveedores Para brindar una certificacin bajo la norma ISO Aseguramiento de la calidad 9000 a determinada empresa u organizacin, Gestin de la configuracin existen las entidades certificadoras vigiladas por organismos nacionales que les dan su acreditacin Definido o Nivel 3 CMM CMMI: Pertenecer a este nivel y son las encargadas de verificar que dichas significa que los proyectos que se llevan a cabo a ms de organizaciones o empresas cumplen con los contar con procesos gestionados, la organizacin o empresa requisitos de la norma, una vez que stas hayan debe contar con una forma definida para desarrollar dichos elegido el alcance de la actividad profesional que proyectos es decir sus procesos deben estar establecidos, se va a registrar, seleccionado un registro, documentados y contar con mtricas para la consecucin de someterse a la auditora y haber concretado con objetivos concretos. xito dicho proceso; se les otorga un certificado y sello. Los procesos que hay que implantar para alcanzar este nivel Qu hacer ante el incumplimiento? son: Desarrollo de requisitos Si un auditor/registrador encuentra reas de incumplimiento la Solucin Tcnica organizacin o empresa tiene un plazo para adoptar medidas Integracin del producto correctivas, sin perder la vigencia de la certificacin o la Verificacin continuidad en el proceso de certificacin. Validacin 14. 3.2.2 Marco Conceptual La Computer Society declara "dedicada al avance de la teora, la prctica y la aplicacin de la informtica y la tecnologa de La ISO 9001 y la ISO 9002 son normas de sistema. ISO 9001 se procesamiento de la informacin." Procura "ser el proveedor lder aplica a las empresas que se dedican al diseo de productos o de informacin tcnica y servicios a los profesionales del mundo servicios y tambin a su produccin o implementacin. ISO 9002 de la informtica". [19] simplemente excluye el elemento de diseo de un modelo similar para garanta de calidad. Los certificados que pueden concederse mediante ellas sealan 4.4 RUSSOFT Association que una organizacin es perfectamente capaz de cumplir las Con sede en San Petersburgo, es un multi-nacional de la necesidades y requisitos de sus clientes de manera planificada y asociacin de software de empresas de Rusia, Ucrania y controlada [16]. Si quiere ir ms all y lograr la excelencia, Bielorrusia. Fue fundada el 9 de septiembre de 1999 y se ha debera cumplir requisitos adicionales. La ISO 9004:2000 fusionado con la de Fort-Ross Consorcio en
mayo de 2004. establece estos requisitos adicionales. Al igual que en la India NASSCOM, RUSSOFT fue creado para 4.ORGANIZACIONES representar a empresas rusas de desarrollo de software en el mercado mundial, a fin de mejorar la comercializacin y actividades de relaciones pblicas de sus miembros, y para 4.1Software Engineering Institute (SEI) presionar a sus intereses en sus pases los gobiernos. [20] Es un instituto federal estadounidense de investigacin y desarrollo, fundado por el Congreso de los Estados Unidos en 5.MEJORA DE LOS PROCESOS DE 1984 para desarrollar modelos de evaluacin y mejora en el desarrollo de software, que dieran respuesta a los problemas que SOFTWARE generaba al ejrcito estadounidense la programacin e integracin de los sub-sistemas de software en la construccin de complejos La mejora de procesos de Software (MPS) es un trmino que se sistemas militares. Financiado por el Departamento de Defensa de usa cuando se referencian mejoras al proceso de software. los Estados Unidos y administrado por la Universidad Carnegie Histricamente CMMI (y otros estndares y mtodos envueltos) y Mellon. otras organizaciones aadieron un S para ampliar el alcance a Es un referente en Ingeniera de Software por realizar el sistemas y procesos de software (MPSS), mientras que otras desarrollo del modelo SW-CMM (1991) que ha sido el punto de organizaciones reemplazaron Software por Sistemas para arranque de todos los que han ido formando parte del modelo que guardar el mismo acrnimo: Mejora de Procesos de Sistemas ha desarrollado sobre el concepto de capacidad y madurez, hasta (MPS) e incluir HW, SW, FW y WW. [21] el actual CMMI. [17] 5.1Enfoque para MPS 4.2 British Computer Society (BCS): En la mejora de procesos de software podemos encontrar tres enfoques principales (o paradigmas) para la mejora de procesos Es una organizacin profesional y una sociedad cientfica que de sistemas/software que se usan independientes o combinadas: representa a las personas que trabajan en la tecnologa de la informacin. Establecida en 1957, es el ms grande de Reino Mejora apoyada en Modelos: este enfoque se basa en Unido basados en un organismo profesional de la informtica. el uso de prcticas aceptadas por la industria como un modelo para mejorar una organizacin, que no est Cubre los ms de 68.000 miembros en ms de 100 pases, BCS es consolidada a estas prcticas. Frecuentemente se usan una sin fines de lucro y se incorpor por Carta Real en 1984. Sus dos modelos: objetivos son promover el estudio y la aplicacin de la tecnologa de las comunicaciones y la informtica y la tecnologa para o Modelo de Madurez de capacidad integrada avanzar en el conocimiento de la educacin en las TIC en (CMMI) del Instituto de Ingeniera de Software beneficio de los profesionales y el pblico en general. [18] (SEI). o Conjunto de estndares de la ISO-9000 de la 4.3 IEEE Computer Society Organizacin Internacional para la estandarizacin. Mejora de Procesos Bottom-Up: este enfoque se En una unidad de organizacin del Instituto de Ingenieros centra en hacer mediciones como tamao, esfuerzo, Elctricos y Electrnicos (IEEE). Se estableci en 1963 cuando el productividad, defectos, reuso y otros indicadores de Instituto Americano de Ingenieros Elctricos (AIEE) y el Instituto procesos consiguiendo as datos de lneas-base y cuando de Ingenieros de Radio (IRE) se fusionaron para crear el IEEE. se determina que habido mejoras potenciales el cambio En el momento de la fusin, la AIEE del Subcomit de gran se implementa. El efecto del cambio determina la escala de Computacin (creado en 1946) se fusion con el IRE ocurrencia de una mejora significativa y el resultado es del Comit Tcnico de Electrnica Informtica (establecida 1948) usado para manejar el cambio organizacional. para crear el Grupo de IEEE Computer. El grupo se convirti en el IEEE Computer Society en 1971. 15. Reingeniera de Negocios: establece mejor un cambio 7.REFERENCIAS radical que un cambio incremental, un poco similar al enfoque Mejora de Procesos Bottom-Up. [1] Mario Piattini, Francisco J. Pino y Flix Garca, 5.2 Grupos de Procesos de Ingeniera de Contribucin de los estndares internacionales a la gestin Sistemas e Ingeniera de Software (SEPG) de procesos software, Facultad de Ingeniera Electrnica y Telecomunicaciones, Universidad del Cauca, Colombia http://www.aemes.org/rpm/descargar.php?volumen=4&nume Software Engineering Process Group, nombre original dado al ro=2&articulo=1 servicio registrado del Instituto de Igeniera del Software (SEI) a los grupos responsables por las actividades de proceso de las [2] Wikipedia, Ingeniera de software, organizaciones del software. Algunos de estos grupos son: http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwar e SEPG: Grupo de Procesos de Ingeniera de Sistemas. [3] Zavala R. 2000. Diseo de un Sistema de Informacin SSEPG: Grupo de Procesos de Ingeniera de Software y Geogrfica sobre internet. Tesis de Maestra en Ciencias de Sistemas. la Computacin. Universidad Autnoma Metropolitana- SSPG: Grupo de Procesos de Software y Sistemas. Azcapotzalco. Mxico, D.F. En prensa, http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware. PEG: Grupo de Ingeniera de Procesos. html#IngSoft PIG: Grupo de Mejora de Procesos. [4] Luciano Guerrero, Monerreal: Canad, 1999, Ciclo de QIG: Grupo de Mejora de Calidad. Mejoramiento de Procesos, El modelo PTIG: Grupo de Mejora de Procesos y Tecnologa.
IDEAL,www.geocities.com/SiliconValley/Lab/3629/IDEA L_ciclo.pdf 6.CONCLUSIONES [5] Software process engineering systems: models and industry cases, http://herkules.oulu.fi/isbn9514265084/html/x287.html Finalmente se puede concluir acerca del tema: [6] Francisco Ruiz, Procesos de Ingeniera del Software, Dentro del proceso de Ingeniera del Software los tres http://personales.unican.es/ruizfr/is1/doc/teo/02/is1-t02- factores ms importantes son: Personal, Mtodos y trans.pdf Procedimientos y Herramientas y Tcnicas. El proceso de ingeniera del software est basado en [7] IEEE, IEEE 1074-2006, http://www.techstreet.com/cgi- procesos y modelos a la definicin, evaluacin y medicin bin/detail?product_id=1277365 del software. [8] IEEE Standard Association, IEEE Std 1074-1997 IEEE Existen modelos y procesos aplicados en las diferentes Standard for Developing Software Life Cycle Processes - etapas del proceso de software. Description, La facilidad de entendimiento humano y comunicacin, http://standards.ieee.org/reading/ieee/std_public/description/s ayuda a llevar una buena definicin de los procesos. e/1074-1997_desc.html La medicin del Proceso de un Proyecto de Desarrollo de Software es primordial pues gracias a ste nos permite [9] Jin Lyu, Kyle Hancock y Linus Luotsinen, IEEE Standard identificar las fuerzas y las debilidades del mismo y a su 1219-1998 Software Maintenance, vez del proyecto. http://classes.cecs.ucf.edu/eel6883/berrios/slides/ch%209%2 La recoleccin de mtricas del proceso es esencial para la 0-%20art%202%20-%20IEEE%20Standard%201219- mejora del mismo y se utilizan para evaluar la eficiencia 1998.ppt de un proceso y si ste ha mejorado con los cambios [10] Mtricas, disponible en: http://alarcos.inf- realizados. r.uclm.es/doc/Calidad/capitulo09.ppt Un producto de software constituye: los ejecutables, [11] ISO/IEC 9126 disponible en: cdigo fuente, descripciones de arquitectura, y as. http://es.wikipedia.org/wiki/ISO/IEC_9126 Medir un producto de software implica: la medicin del tamao del producto, la estructura del producto y la [12] Fernanda Scalone, Software Quality Management, calidad del producto. disponible en: http://softqm.blogspot.com/2007/01/visin- Las mtricas en un proyecto de desarrollo de software e se general-acerca-de-iso-9126.html pueden aplicar a procesos y productos. [13] Mara Del Carmen Sosa Sierra, Inteligencia artificial en la Las mtricas del proceso permiten a una organizacin de gestin financiera empresarial, ingeniera del software tener una visin profunda de la http://ciruelo.uninorte.edu.co/pdf/pensamiento_gestion/23/6_ eficacia de un proceso ya existente Inteligencia%20artificial.pdf Dos modelos estandarizados que se los puede utilizar para la medicin de la calidad del Software son: CMMI y ISO [14] Carlos J. Alonso Gonzlez, Departamento de Informtica, 9000. Induccin de Reglas Proposicionales, http://www.infor.uva.es/~calonso/IAII/Aprendizaje/Induccio nReglasProposicionales.pdf 16. [15] Wikipedia, Normas ISO 9000 disponible en: [36] Wikipedia, disponible http://es.wikipedia.org/wiki/Normas_ISO_9000 en:http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gi [16] CINTERFOR, Gestin de calidad en la formacin l_de_software disponible en: [37] Gucoba disponible en: http://www.ilo.org/public/spanish/region/ampro/cinterfor/te http://gucoba.com/index.php?option=com_content&vi mas/calidad/doc/cedefop1.htm ew=article&id=56&Itemid=57 [17] Wikipedia, Software Engineering Institute disponible en: [38] Monografias, disponibe en: http://es.wikipedia.org/wiki/Software_Engineering_Institute http://www.monografias.com/trabajos67/metodologia- [18] Wikipedia, British Computer Society disponible en: desarrollo-softwares/metodologia-desarrollo- http://en.wikipedia.org/wiki/British_Computer_Society softwares2.shtml [19] Wikipedia, IEEE Computer Society disponible en: [39] Mtodo CBA IPI para la evaluacin de proyectos, http://en.wikipedia.org/wiki/IEEE_Computer_Society Disponible en: [20] Wikipedia, RUSSOFT disponible en: http://www.geocities.com/SiliconValley/Lab/3629/cbai http://en.wikipedia.org/wiki/RUSSOFT, disponible en: pi.htm http://www.slideshare.net/aacevedolipes/spin-colombia [40] Metodologas De Desarrollo De Software, Mara A. [21] Rduardo A. Rodrguez Tello, Procesos de software, 2008, Mendoza Sanchez , 2004, http://www.tamps.cinvestav.mx/~ertello/swe/sesion03.pdf http://www.willydev.net/InsiteCreation/v1.0/descargas [22] Chirstian Tzec, Fundamentos de Desarrollo de Sistemas, /cualmetodologia.pdf http://www.scribd.com/doc/16416960/Modelo-cascada- [41] Microsoft Solution Framework, figura tomada de: espiralincremental http://caraujo334.blogspot.es/img/msf1.jpeg [23] https://www.mytconsulting.com/principal/images/12207_5.p [42] http://www.mentores.net/default.aspx?tabid=104&type ng =art&site=183&parentid=32 [24] http://www.cs.umd.edu/users/basili/qip/img007.gif [43] http://en.wikipedia.org/wiki/Microsoft_Solutions_Fra [25] http://es.kioskea.net/contents/genie-logiciel/cycle-de- mework vie.php3 [26] Sid@r, Prototipado, http://www.sidar.org/recur/desdi/traduc/es/visitable/tecnicas/ Prototyping.htm [27] Introduccin a la Ingeniera de Software, http://oacosta334.blogspot.es/tags/prototipo/ [28] Wikipedia, Modelo de prototipos, 2009,
http://es.wikipedia.org/wiki/Modelo_de_prototipos [29] http://cmunoz334.blogspot.es/tags/Modelo/ [30] MODELOS DE PROCESO ITERATIVOS E INCREMENTALES, http://scruz334.blogspot.es/1193793960/ [31] Wikipedia, Desarrollo en espiral, Modificado: 16 abril del 2009, http://es.wikipedia.org/wiki/Desarrollo_en_espiral#Ventajas [32] Wikipedia, Desarrollo iterativo y creciente, Modificado 18 de Junio 2009, http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente #Debilidades_de_este_modelo_de_desarrollo [33] Samira Lamayzi, La norma ISO 14764, 1999, http://alarcos.infcr.uclm.es/per/fruiz/cur/mso/comple/ISO14764.pdf [34] http://www.aemes.org/rpm/descargar.php?volumen=4&nume ro=2&articulo=1 [35] Juan Pablo Gomez Gallego, Fundamentos de la Metodologa RUP Rational Unified Process, 2007
Metodologia Estructurada - Presentation Transcript

1. 2. 3. Metodologas Anlisis Objetivos
o o
4.
Brindar conceptos y herramientas actualmente utilizadas en el Desarrollo de Sistemas de Informacin. Compartir el valor agregado de la investigacin y la experiencia de los docentes y alumnos Funciones y responsabilidades
5.
o o o
Gerente Planifica, presupuesta, optimiza recursos, trata con proveedores Funciones y responsabilidades
6.
o o o o o o o
Jefe de Soporte Mantiene el hardware de PCs, estudia nuevos productos, atiende requerimientos de usuarios, aplica estndares de seguridad de los datos (resguardos de acceso-veracidad de los datos). Implementa sistemas de backup.
Funciones y responsabilidades 7.
Jefe de Desarrollo
o o o o o o
Optimiza recursos humanos y tcnicos. Planifica. Realiza seguimiento y control de proyectos, administra base de datos. Implementa sistemas de seguridad para los datos. Controla interconectividad entre los diferentes sistemas. Funciones y responsabilidades
8.
o o o o o o o
Analista Interpreta los requerimientos de los usuarios, emplea tcnicas adecuadas para traducir a trminos adecuados el valor que el usuario asigna a dichos requerimientos. Modela. Controla (prueba). Instala. Documenta el sistema.
o o o o o o o
Programador Convierte en programa de operacin los requerimientos planteados por el analista, para ello debe recibir informacin precisa del analista para cada mdulo o accin del proceso: Datos de ingreso, tratamiento, datos de salida. Funciones y responsabilidades
10.
o o o o o o
Analista de organizacin y mtodos Anlisis de la circulacin de la informacin, optimizacin de circuitos administrativos, diseo de formularios. Estudios de la informacin legal para los distintos tipos de negocios. Funciones y responsabilidades
11.
Documentadores
o o o o o
Escribe los manuales de usuario para la operacin de los sistemas. Describe los circuitos administrativos para la circulacin de la informacin. Escribe los manuales del sistema.
o o o o o
Jefe de Centro de Cmputos Organiza recursos. Prueba corridas de sistemas. Controla estndares. Planifica sistemas de backups. Organiza y administra soportes magnticos. Funciones y responsabilidades
13. Funciones y responsabilidades Ejemplo Direccin de Informtica Programacin y Control de Gestin Comit de Usuarios de Sistemas de Informacin Redes y Comunicaciones Servicios de Tecnologa de Informacin Planificacin y Desarrollo de Sistemas de Informacin 14. Funciones y responsabilidades Programacin y Control de Gestin Planificacin y Control Polticas, Normas y Proced. Investigacin y Desarrollo Nuevas Tec. Administracin Recursos Informticos 15.
o o o o o o o o
Programacin y Control de Gestin P lanificacin y Control de Gestin. Presupuesto y control. Administracin de polticas, metodologas, normas y procedimientos. Investigacin y desarrollo de nuevas tecnologas. Administracin de requerimientos y contrataciones informticas. Administracin del parque Informtico. Seguimiento de proyectos especficos por decisin de la Direccin.
Funciones y responsabilidades 16. Funciones y responsabilidades Planificacin y Desarrollo de Sistemas de Informacin Lderes de Proyectos Analistas Programadores Adm. de Datos 17.
o o o o o
Planificacin y Desarrollo de Sist. de Informacin Planificacin de Proyectos y asignacin de recursos en acuerdo con el Comit de Usuarios . Desarrollo de Aplica. Estadsticas Sociodemogrficas. Desarrollo de Aplicaciones Econmicas . Desarrollo de Aplicaciones de Gestin Interna.
o o o o
Desarrollo de Aplicaciones Administrativas . Desarrollo de Aplicaciones Internet . Integracin con el rea Metodolgica para el serv. a c/ rea temtica Adm. de las DB (Lgico) y del diccionario nico. Funciones y responsabilidades
18. Funciones y responsabilidades Servicios de Tecnologa de Informacin Administracin de Servidores Produccin Soporte a Usuarios Centro de Ingreso Operaciones Help Desk Soporte de Hard Soporte de Soft Unix Netware Windows XP 19.
o o o o o o o o o
Servicios de Tecnologa de Informacin Adm. y Operacin de los servidores de Produccin. Implementacin de actual. de versiones de Hard y Soft. Soporte tcnico a Usuarios. Administracin del Help Desk. Coordinacin de los Centros de Ingreso. Implementacin del Plan de Contingencias. Implementacin y control de polticas de resguardo y seguridad de acceso a datos y aplicaciones Instalacin de nuevas Tecnologas relativas a Servidores, Redes LAN, S.O. y herramientas de escritorio Funciones y responsabilidades
20. Funciones y responsabilidades Redes y Comunicaciones Redes Comunicaciones 21.
o o o o o o
Redes y Comunicaciones Administracin de la Red fsica y lgica. Monitoreo del Sistema Nacional de Comunicaciones. Administracin de los servicios de Red. Administracin de los accesos a Internet e Intranet Administracin de los sistemas de control de acceso a la Red (Firewall - Proxy)
Funciones y responsabilidades 22. Ciclo de Vida Clsico Relevamiento Anlisis Diseo Preliminar Prueba de Sistema Prueba de unidad Prueba de Subsistema Estudio de hardware requerimientos del usuario Calendario, presupuesto pedido de hardware especificacin funcional necesidades de rendimiento especificacin del sistema configuracin final especificacin del programa mdulos codificados mdulos probados subsistemas probados sistema probado Diseo detallado Codificacin 23. Ciclo de Vida Estructurado 1. Factibilidad 2. Anlisis 3. Diseo 8. Conversin de Bases 6. Ctrol. de Calidad 4. Implemen- tacin 9. Instalacin Usuarios Directorio Operaciones 5. Pruebas de Aceptacin 7. Desc. de Proced. Directorio requerimientos del sistema polticas de usuario restricciones restricciones operacionales base de datos existentes documento especificacin estructurada especificacin de diseo sistema instalado Informe tentativo costo-
beneficio restricciones reporte de costo- beneficio conjunto de pruebas de control de calidad manual del usuario sistema integrado sistema aceptado base de datos convertidas 24. Diferencias de los Ciclos
o o o o o o o o o o o o o o
secuencial descriptivas sistemas implementados pobre mnimos Bottom-Up mucho plan con poco resultado paralela grficas por modelo exhaustivos constantes y suficiente Top-Down plan + resultado ACTIVIDAD HERRAMIENTAS EVALUACION ANALISIS CONTROLES DESARROLLO CONCLUSION CLASICO ESTRUCTURADO
25. Prototipo
o o
Se asemeja a una implementacin TOP-DOWN Radical. Diferencia antes o despus se dispondr de un modelo grfico completo del sistema, que ser la va para reemplazarlo por el sistema definitivo.
o o
Implica que pueda incurrirse peligrosamente en suponer que el prototipo es el sistema en produccin. Inferimos No puede manejar altos volmenes de transacciones. Carece de detalles operativos, tales como, recuperaciones de errores, rastreos de auditora, facilidades de backups, documentacin para el usuario y procedimiento de conversin.
26. Estrategia de modelado A partir del modelo fsico actual Modificar Modelo Esencial Actual Usuario Modelar Sistema Fsico Actual Derivar Esencia Sistema Actual Informacin del sistema actual Nuevos requerimientos Modelo lgico actual Nuevo modelo lgico Modelo fsico actual Usuario Modelar Sistema Fsico Actual Modificar Modelo Esencial Actual Usuario Modelar Sistema Fsico Actual Derivar Esencia Sistema Actual Modificar Modelo Esencial Actual Usuario Modelar Sistema Fsico Actual
27. Estrategia de modelado Con abstraccin de la encarnacin actual Modificar Modelo Esencial Actual Usuario Modelar Esencia Sistema Actual Informacin del sistema actual Nuevos requerimientos Nuevo modelo lgico Modelo lgico actual Modificar Modelo Esencial Actual Usuario Modelar Esencia Sistema Actual 28.
o o o o o o o o o
1- Estudio de Factibilidad. 2- Anlisis. 3- Diseo. 4- Implementacin. 5- Generacin de Test de Aceptacin. 6- Control de Calidad. 7- Descripcin de Procedimientos. 8- Conversin de Base de Datos. 9- Instalacin. Ciclo de Vida de un Proyecto 1- Estudio de Factibilidad. 2- Anlisis. 3- Diseo. 4- Implementacin. 5- Generacin de Test de Aceptacin. 6- Control de Calidad. 7- Descripcin de Procedimientos. 8- Conversin de Base de Datos. 9-
Instalacin. 29. Factibilidad
o o o o
30.
Operativa Tcnica Econmica Legal
o o o o o
1 Estudio de Factibilidad 1.1 Identificar las deficiencias actuales. 1.2 Establecer nuevas metas del sistema. 1.3 Generar escenarios aceptables. 1.4 Preparar un esquema de proyecto.
Ciclo de Vida de un Proyecto 31.
o o o o o
2 Anlisis 2.1 Desarrollar el modelo ambiental. 2.2 Desarrollo del modelo de comportamiento. 2.3 Establecer fronteras hombre/mquina. 2.4 Realizar el anlisis de costo/beneficio. 2.5 Seleccionar la opcin.
2.6 Determinar las restricciones fsicas del sistema. 2.7 Empaquetar especificaciones.
o o o o o o o o
3 Diseo 3.1 Asignar especificaciones de proceso. 3.2 Asignar especificaciones a tareas. 3.3 Derivar Diagrama Estructurado. 3.4 Evaluar diagrama de Estructura. 3.5 Disear Mdulos. 3.6 Disear Base de Datos. 3.7 Empaquetar Diseo. Ciclo de Vida de un Proyecto
33.
o o o o
4 Implementacin 4.1 Seleccionar el prximo mdulo. 4.2 Codificar mdulo. 4.3 Testear el Esqueleto del sistema. Ciclo de Vida de un Proyecto
34.
o o o o o o
5 Generacin de Test de Aceptacin 5.1 Generar plan de test. 5.2 Preparar test de performance. 5.3 Preparar test normal. 5.4 Preparar test de errores. 5.5 Empaquetar test. Ciclo de Vida de un Proyecto
35.
o o o o
6 Control de Calidad 6.1 Se decide si corresponde o no aceptar el sistema para su instalacin. 6.2 Examinar la documentacin asociada con el proyecto para asegurar que es completa, acorde a los estndares establecidos. 6.3 Examinar la codificacin de los programas. para asegurar que han seguido los estndares de programacin. 6.4Examinar todo el sistema desde el punto de vista de seguridad y su auditora.
o o
o o o o o o o o o o
7 Descripcin de procedimiento Es la descripcin de procedimientos, en la misma se vuelcan todas las especificaciones consideradas para le anlisis y el diseo, en un manual del usuario. Es importante enfatizar que tanto los productos obtenidos del anlisis como del diseo deben ser descriptos. En esta etapa se describen las entradas, salidas, pantallas y procedimientos de todo el sistema para dejar documentado la totalidad del mismo. Ciclo de Vida de un Proyecto
37.
o o o o o o o o o o
8 Conversin de Base de Datos Tiene por objeto convertir las bases de datos del sistema actual al formato de las nuevas bases de datos, esto comprende tambin archivos que por su organizacin no sean bases de datos y adems cuando se trata de un sistema nuevo el cual no estuviese computarizado, es decir que contare de almacenamientos fsicos no magnticos, se requiera incorporar la informacin que se lleva en papel a la nueva base de datos. Ciclo de Vida de un Proyecto
38.
o o o o o o o o
9 Instalacin La instalacin cierra el ciclo de vida del proyecto, se pone en funcionamiento el sistema en manos del usuario, se lo declara oficialmente operativo. En pequeos proyectos esta actividad se realiza normalmente en un clima de tranquilidad, lo contrario sucede cuando se instalan grandes sistemas, este es el momento de la realidad, de los
o o o
nervios y las tensiones, en consecuencia, se debe tener en cuenta aspectos que dificulten llevar a cabo esta actividad.
o o
Establecer la hora adecuada para la instalacin... Determinar el momento oportuno para desmantelar el viejo sistema, definir la duracin del procesamiento en paralelo....
Determinar si el sistema debe ser implementado en forma integral o parcial de acuerdo al nivel de complejidad del mismo y a las restricciones operativas ......
Decidir el momento y forma adecuada para capacitar al usuario .......
Ciclo de Vida de un Proyecto 40. Tcnicas de Relevamiento
Las tcnicas ms utilizadas en anlisis son: Entrevista. Observacin personal y directa. Revisin, lectura y estudio de documentacin y antecedentes. Cuestionarios (puestos a puesto, por procedimientos). Muestreo.
41. Tcnicas de Relevamiento
o o o
Entrevistas Finalidad: Obtener la informacin relacionada con el sistema actual, y los nuevos requerimientos. reas de aplicacin: Todas las etapas que conforman el anlisis de sistema.
42. Entrevista
o o
43.
Etapas Tipos de usuarios
Etapas de la Entrevista:
La Preparacin. El Desarrollo. La Finalizacin.
Tcnicas de Relevamiento 44.
o o o o o o
Preparacin: Dar conocimiento al personal. Confeccionar listado con nombres, funciones y tareas que efectan las personas a entrevistar. Decidir la secuencia de entrevistas a efectuar. Confeccionar una lista de temas a tratar. Tomar conocimiento de las tareas que realizan. Tcnicas de Relevamiento
45.
Desarrollo Atmsfera. Prejuicios del analista. Actitud imparcial. Conduccin de la entrevista.
Abierta. Cerrada. Dirigida.
Desarrollo Situacin del entrevistado. Coordinacin de las entrevistas. Intercalacin de temas de relajamiento. Pertenencia. Ausencia de crtica. Tiempo para pensar.
Desarrollo Distraccin externa o interna. Evitar el sarcasmo y el humor. Animar el razonamiento. Preguntas del entrevistado. Mostrar inters. Manejar desacuerdos.
Personalidad del entrevistado.
Tcnicas de Relevamiento 48. Tcnicas de Relevamiento Tipos de usuarios
o o o o o o o o o o o o
Paciente. Confuso. Voluble. Autmata. Emperador. Obstruccionista. Suficiente. Desconfiado. Tmido. Limitado. Pedante. Simulador.
49. Tcnicas de Relevamiento Tipos de Preguntas Reenvo (sugerencias) Por su forma de expresin Por su naturaleza Despiertan confianza Informativas Investigacin Despiertan desconfianza 50.
Finalizacin
Abrupta. (postergacin de la entrevista) Normal. (charla y resumen)
Toma de notas
Ventajas
Mantener la mente en el asunto. Centrar la entrevista en el tema. Recordar hechos. Registrar detalles.
Desventajas
Demasiado tiempo. Vacilacin del entrevistado.
Conclusin
No creer todo lo que oye. Comprobar todo. Desconfiar de necesidades artificiales. Importancia de recibir documentacin. Distinguir informaciones emocionales y de hecho.
o o
Conclusin Diferenciar entre:
Dato: informacin no verificada. Hecho: dato verificado informal con pruebas. Opinin: comentario sin certeza. Deduccin: afirmaciones que surgen indirectamente de la observacin de los hechos.
Tcnicas de Relevamiento 54. Modelo De Datos
El modelo de datos tiene por objeto capturar la informacin referida a los datos y su significado.
55. Modelo de Datos: Clasificacin
No Semnticos: reconocen solo las siguientes clases de objetos:
Entidades y Asociaciones. Atributos. Vinculaciones. Valores y dominio de valores.
Semnticos: Adems de reconocer las clases de objetos mencionados anteriormente, permite tipificarlos e identificar ROLES que desempean en el negocio que estemos considerando.
56.
o o o
Elementos para su construccin: 1-Elementos Primarios Los elementos primarios sirven de base para la construccin de estructuras de datos de mayor nivel, estos elementos son: - Datos Elementales - Vinculaciones
o o
Modelo De Datos 57.
o o
Elementos para su construccin: 2 Elementos Estructurados.
Es el conjunto de datos elementales relacionados entre si con un objeto comn. Los datos elementales informan acerca del objeto, calificndolo o especificando algo sobre el mismo. La informacin referida al objeto, esta determinada por una serie de de ATRIBUTOS que caracterizan al objeto.
Modelo De Datos 58. Entidades
Definimos a la Entidad, como una familia de objetos con los mismos atributos. Las Entidades constituyen el inters principal del anlisis de los datos.
59. Atributos
o o
Los Atributos son los datos elementales que nos pueden brindar informacin de inters de una Entidad. Los atributos de acuerdo al rol que desempean pueden clasificarse en atributos que: Identifican a la entidad (N de documento). Describen a la entidad (Marca). Vinculan a la entidad con otra entidad.
60. Valores
Un atributo puede tomar un valor de un conjunto de valores posible, denominado su Dominio de Valores (un color del conjunto de colores).
Cada atributo tiene un dominio de valores. Atributos de la misma u otras entidades pueden tener el mismo dominio de valores comunes.
61. Identificador nico
Es un atributo que identifica unvocamente a cada miembro (atributo) de una entidad. Una entidad puede tener uno, varios o ningn identificador nico. Cuando no existe un identificador se suele asignar uno artificialmente, el cual recibe el nombre de TAG. El valor TAG es asignado manual o automticamente por el sistema.
De los identificadores nicos que puede tener una entidad se elige uno como principal, denominado CLAVE PRIMARIA de la entidad.
62. Consideraciones sobre las claves
Las claves deben responder a las siguientes propiedades: Identificar unvocamente a cada miembro de la entidad. Ningn atributo de la clave puede ser desechado sin destruir la propiedad de identificacin unvoca.
63. Claves Candidatas
Algunas entidades pueden tener ms de un atributo que cumpla con las propiedades mencionadas, a esos atributos se los denomina claves candidatas.
64. Eleccin de la clave primaria
La eleccin de la clave primaria de entre las claves candidatas debe realizarse teniendo en cuenta que: No se puedan dar valores indefinidos para la misma Sea la de uso ms natural para los usuarios
La cantidad de atributos que la componen sea la menor. La cantidad de caracteres que la componen sea la menor posible
65. Vinculaciones
Podemos distinguir dos tipo: Vinculaciones entre entidades. Vinculaciones entre atributos de una entidad.
66. Vinculaciones entre entidades
Las vinculaciones entre dos conjuntos de informacin pueden ser: Uno a Uno: A cada elemento de un conjunto le corresponde un nico elemento del otro asociado y viceversa. Uno a Varios: Un elemento de un conjunto tiene uno, varios o ningn elemento asociado del otro conjunto con cada elemento del segundo. Varios a Varios: Un elemento de un conjunto tiene uno, varios o ningn elemento asociado del otro conjunto y viceversa.
67. Vinculaciones entre atributos
Las vinculaciones entre atributos pueden ser de: Dependencia Directa: En una entidad se considera que los atributos que la describen DEPENDEN de los que la identifican. Dependencia Transitiva: Esto significa que un atributo dependiente puede depender de otro atributo dependiente (Ej: Precio depende del modelo de la entidad moto).
68. Modelo del Sistema
o o o
Modelo Esencial Encarnacin Modelo de Implementacin
69. Modelo Esencial Ambiental de Comportamiento de Act. Esenciales de la Memoria Esencial 70. Modelo Esencial
Es una representacin de lo que el sistema debe hacer sin tener en cuenta los aspectos tcnicos de como lo har.
71. Esencia
o o
Es la naturaleza de las cosas, lo permanente e invariable en ellas. Todas las caractersticas de un sistema de respuesta planificada que existiran si el sistema hubiese sido implementado con tecnologa perfecta .
72. Tecnologa perfecta
o o
Lleva a cabo una cantidad infinita de tareas en cantidades infinitas y en forma instantnea. No consume energa.
o o o o
73.
No ocupa espacio. No genera costo. No comete errores. No deja de prestar servicio.
o o
Componentes Actividades esenciales: son aquellas que el sistema debera realizar considerando que el mismo pudiera ser implementado con tecnologa perfecta.
Memoria esencial: son los datos mnimos necesarios para llevar a cabo las actividades esenciales.
Esencia 74.
o o
Actividades esenciales Actividades fundamentales: son las que realizan las tareas que forman parte del sistema y permiten que el mismo cumpla con su propsito.
Actividades custodiales: tienen por objeto establecer y mantener la memoria esencial del sistema.
Esencia 75. Esencia Almacenamiento Estmulo 1 Estmulo 2 Respuesta Proceso 1 Proceso 2 Ejemplo de Actividades esenciales 76. Diagrama de flujo de datos
o o
Diagrama de flujo de datos es una representacin grfica de un sistema en forma de red.
Herramienta grfica. Particionamiento de actividades en diferentes niveles. Multidimensional.
77. Diagrama de flujo de datos
o o o o o
Los elementos de un DFD son cuatro : Flujo de datos , representados por un vector con nombre. Procesos , representados por un crculo o burbujas. Almacenamientos , representados por dos lneas paralelas. Terminales, tambin denominados, Entidades Externas .
o o o
Flujo de datos: Un Flujo de datos es una interfase entre distintos componentes de DFD.
Remito 79. Diagrama de flujo de datos
o o o o o
Proceso: Un proceso es una transformacin de los flujos que ingresan, en los flujos que salen del mismo. Cada burbuja requiere un nombre el cual especifique lo que hace.
Procesar ventas 80. Diagrama de flujo de datos
o o o
Almacenamiento: Es un repositorio temporal de datos, puede ser un formulario, diskette, etc.. Stock
o o o o o o o o
Entidades Externas: Es una persona u organizacin perteneciente al contexto del sistema, la cual, origina o recibe datos del mismo. No esta comprendido dentro del mbito del sistema, sino que Interacta con el sistema por medio de los estmulos que genera y por las respuestas que a dichos Estmulos produce el sistema. Cliente
o o o o o o o o
Guas para dibujar DFD.: Identificar todos los flujos de datos de entrada y salida y dibujarlos en la parte externa del diagrama. Dibujar los procesos uniendo entradas con salidas o viceversa. Asignar cuidadosamente, nombres a los flujos de datos. Asignar nombres a las burbujas de acuerdo a sus entradas y salidas. Ignorar las E.E. Omitir las referencias a errores. No mostrar flujos de control ni informacin referida al mismo.
83. Encarnacin
Comprende a las personas y elementos necesarios para que el sistema funcione y pueda llevar a cabo todos los procesos que deba elaborar para cumplimentar los requerimientos para lo cual fue creado.
84. Modelo de Implementacin
Es una representacin de como construiremos el sistema una vez que comprendimos lo que debe hacer y definimos la encarnacin a utilizar.
85. Modelo de Implementacin de Imp. del Sistema de Programas de Tareas de Procesadores 86. Herramientas 87. Modelo Esencial Ambiental de Comportamiento de Act. Esenciales de la Memoria Esencial 88.
o o o
Objetivos: Describir los requerimientos de interaccin del sistema con su contexto (entorno). Visualizar las personas, organizaciones y otros sistemas con los que debe interactuar, los eventos a los cuales debe dar respuesta y los flujos de datos que intercambia el sistema con el contexto. Fijar el alcance del sistema. Modelo Ambiental
89. Modelo Ambiental
o o o
Propsito del sistema Lista de eventos Diagrama de Contexto
Componentes 90. Modelo Ambiental
o o
Propsito: Debe ser una descripcin breve y concisa en la que se indique para que existe el sistema y reflejar claramente el entorno y alcance del mismo.
o
91.
No expresa lo que el sistema har, mucho menos como lo har.
o o o
Lista de evento: Muestra las cosas que ocurren en el entorno y a las cuales debe dar respuesta el sistema. Muestra que o quien inicia los eventos.
Modelo Ambiental 92.
o o o o o o
Eventos Entidades Externas Estmulos Respuestas Tipo de Activacin Tipo de Actividad
Objetos esenciales
Modelo Ambiental Elementos de la Lista de eventos 93.
Es una accin producida en el contexto por las entidades externas, las cuales originan un estmulo que activa el sistema para que este genere una respuesta planificada.
Modelo Ambiental Concepto de evento 94.
o o
Activados por flujos Activados por el tiempo
Modelo Ambiental Tipos de eventos 95.
Los ms triviales de determinar, analizando para c/uno de los determinados si existen variaciones significativas si es opuesto si hay eventos que deban precederlos si hay eventos que deban sucederlos
Modelo Ambiental Identificacin de eventos 96.
Debe contener un Sujeto. Verbo. Objeto.
Modelo Ambiental Descripcin de los eventos 97. Modelo Ambiental Ejemplo de Lista de eventos Evento Entidad externa Estmulo Respuesta Tipo de activac. Tipo de activid. Objetos esenciales Un cliente enva un pedido de cotizacin cliente pedido de cotizacin cotizacin de la mercadera F F clientes, pedidos, cotizaciones Ventas informa datos de nuevos clientes ventas datos nuevos clientes --------------- F C clientes A fin del da ------------ ---------------- Lista de deudores T F clientes 98.
Tiene por objeto definir que esta afuera de los lmites del sistema e interacta con l, es decir, delinear el dominio del sistema. Modelo Ambiental Diagrama de Contexto
99. Modelo Ambiental Ejemplo de Diagrama de Contexto Entidad Externa 1 Entidad Externa 2 Sistema Estmulo 1 Estmulo 2 Respuesta 1 100.
o o
Minimizar los errores en la determinacin de los eventos del sistema. Balancear el Diagrama de contexto con la lista de eventos. Debe existir en ambos, la misma cantidad de estmulos y respuestas.
Modelo Ambiental Consideraciones 101. Modelo Esencial Ambiental de Act. Esenciales de la Memoria Esencial de Comportamiento 102. Modelo de Comportamiento
o o o
Describe la forma en que el sistema debe reaccionar ante los distintos estmulos. Muestra las funciones que deben ser llevadas a cabo por el mismo, con tecnologa perfecta. Muestra lo que debe hacer el sistema pero no como lo har.
Caractersticas 103.
o o o
Derivar el modelo de procesos (Act. esenciales) Derivar el modelo de datos (memoria esencial) Completar el modelo (Leveling) Modelo de Comportamiento Desarrollo
104. Modelo de Comportamiento DD Lista de eventos DC DFD DER 105.
o o o
Representa las funciones esenciales del sistema. Describe ante cada evento como responde el sistema. Muestra los procesos de transformacin necesarios para elaborar las respuestas generadas por cada actividad fundamental.
Modelo de Comportamiento Modelo de las Act. esenciales 106.
o o o
Diagrama de flujo de datos. Diccionario de datos. Especificaciones de procesos. Modelo de Comportamiento Modelo de las Act. esenciales Herramientas utilizadas para el modelado
107. Modelo de Comportamiento
o o o
Construir un DFD preliminar en base a la lista de eventos. Desarrollar el DFD de Nivel 1. Desarrollar el leveling de cada actividad esencial.
Derivar el modelo de procesos 108. Modelo de Comportamiento
o o o o
Dibujar una burbuja por c/actividad esencial. Conectar los estmulos y respuestas que corresponden a cada actividad esencial. Conectar los almacenamientos necesarios para cada actividad esencial. Conectar las actividades esenciales entre s a travs de los almacenamientos.
Construccin del DFD preliminar y el Nivel 1 109. Modelo de Comportamiento
La descripcin del comportamiento esta dada por la descomposicin de las actividades esenciales hasta llegar a las primitivas funcionales .
La transformacin de un DFD puede ser expandida en otro DFD o ser descripta mediante una especificacin de procesos . Descomposicin del Nivel 1
110. Modelo de Comportamiento Leveling 111. Modelo Esencial
o o
De las especificaciones mediante la verificacin de las reglas de consistencia. Del comportamiento simular el comportamiento.
Verificacin - Criterios 112.
o o o o
Todo flujo o almacenamiento debe estar definido en el D.D. Toda transformacin debe tener un DFD de nivel inferior o una especificacin de procesos. Toda transformacin descripta debe cumplir con el balanceo. Las entidades en el modelo de datos deben figurar como almacenamientos en el modelo de procesos.
Modelo Esencial Verificacin de las especificaciones 113.
o o o
Se simula la ocurrencia de cada evento para verificar la respuesta del sistema. Reglas: dar valores iniciales a los almacenamientos. dar valores a los flujos de datos entrantes. recorrer las transformaciones siguiendo las especificaciones de procesos.
Modelo Esencial Verificacin del comportamiento 114.
o o
Nadie esta motivado para descubrir sus propios errores No lo haga Ud. Mismo!
Recomendacin Esencial 115. Modelo Esencial Ambiental de Comportamiento de Act. Esenciales de la Memoria Esencial 116. Modelo Esencial
o o o
Representar los datos esenciales del sistema Los datos que componen los flujos de datos del diagrama de contexto. Para que un elemento de datos pueda ser extrado, primero deber ser introducido en el almacenamiento.
Modelo de la Memoria esencial 117. Modelo Esencial
o o o
Describir la composicin de los flujos del Diagrama de contexto. Normalizar los datos identificando las entidades y relaciones. Construir el Diagrama de Entidad Relacin. Derivar el Modelo de datos
118. Particionamiento de la memoria
o o o
Sentido Comn. Identificacin de: Objetos con existencia independiente sobre el que se almacenan datos. Relaciones: asociacin de entre objetos. Rangos y Significados de valores. Normalizacin.
119. Normalizacin
o o o o o o o o o
La normalizacin es un conjunto de reglas Estructuradas que se aplican a atributos asociados a entidades. Se aplican originalmente al conjunto de datos que se quieren almacenar en la base de datos y que luego ser dividido en distintas tablas. Cada forma normal hace que la informacin est m s organizada que en la anterior. Las formas normales deben ser aplicadas en orden correlativo.
120. Notacin especfica Smbolo/Codificacin Significado Ejemplo # Nmero #calle (nmero de calle) T Texto T_calle (texto de calle) C Cdigo C_Postal (cdigo postal) D Fecha D_nacimiento (fecha de nac.) {} Indica grupos repetitivos {c_materia + T_materia} [ ] Campo opcional, puede o no estar completo [e_mail] ( ) Opciones Sexo(M/F) 121. Primera Forma Normal
o o
Una entidad esta en primera forma normal si no contiene grupos repetitivos
122. Primera Forma Normal Si aplicamos la 1r a forma normal, extraeremos los grupos repetitivos y los colocaremos en otra entidad nueva, arrastrando adems la clave de la entidad original y agregando algn otro atributo que permita una identificacin unvoca de cada registro. 123. Porqu aplicar la PFN?
o o o o o o o
Si quisiramos guardar la informacin de un grupo repetitivo dentro de la tabla original, deberamos generar una tabla que tenga tantas veces repetidos los campos que se repiten como el mximo de veces que se puedan repetir. De esa manera, si tenemos registros con menos repeticiones desperdiciamos espacio ya que fue reservado, pero no contiene
o o o
informacin. Adems sera una estructura rgida y si se presentara algn caso con mas repeticiones se debe modificar la tabla.
124. Segunda Forma Normal
o o o
Una entidad esta en segunda forma normal si todos sus atributos dependen de la totalidad de la clave primaria y no solo de una parte.
125. Segunda Forma Normal
o o o o o o o o
Si aplicamos la 2da forma normal, extraeremos aquellos atributos que dependen de solo parte de la clave primaria y los colocaremos en otra entidad nueva, arrastrando adems la parte de la clave de la cual dependen, este ultimo campo ser la clave primaria de la nueva entidad. Esta forma normal se da solamente en aquellas entidades cuya clave primaria esta compuesta por ms de un campo.
126. Tercera Forma Normal
o o o
Una entidad esta en tercera forma normal s i no contiene atributos que dependan de atributos que no formen parte de la clave.
127. Tercera Forma Normal
o o o o o o o o
Si aplicamos la 3ra forma normal, extraeremos aquellos atributos que dependen de atributos no clave y los colocaremos en otra entidad nueva, arrastrando adems el campo del cual dependen, este ultimo campo ser la clave primaria de la nueva entidad, pero quedar en la entidad primera, como campo relacionante con la nueva entidad o foreign key (se indica con lnea punteada).
128. Porqu aplicar la 2da. y 3 t r a . FN ?
o o
Porque ahorramos espacio por la cantidad de informacin que se guarda y facilita el
mantenimiento de la informacin .
129. Matriz de Claves
o o o o o o o o
Una vez que hemos finalizado la normalizacin , ( no se puede normalizar ms la informacin ) . Tomamos las entidades que nos quedan (las que quedaron completamente normalizadas) y tambin los campos claves y generamos una matriz. En la matriz, marcaremos con una X los campos que son claves principales en una entidad y con una O los campos que son claves relacionales para esa entidad.
130. Ejemplo Alumno: C_alumno + C_carrera + T_carrera + T_NomApellido + T_calle + #_calle + #_piso + T_dpto + C_postal + T_TelefonoPart + T_telCelular + T_email + D_nacimiento + {C_materia + T_Materia + #_NotaFinal} 131. 1ra Forma Normal
o o
1FN/Alumno A1: C_alumno + C_carrera + T_carrera + T_NomApellido + T_calle + #_calle + #_piso + T_dpto + C_postal + T_TelefonoPart + T_telCelular + T_email + D_nacimiento
A2: C_alumno + C_materia + T_Materia + #_NotaFinal
132. 2da Forma Normal
o o o o o
2FN/ A1: No aplicable 2FN/A2: A3: C_alumno + C_materia + #_NotaFinal A4: C_materia + T_Materia
133. 3ra Forma Normal
o o o o o o o o o
3 FN/ A1: A5: C_alumno + C_carrera +T_NomApellido + T_calle + #_calle + #_piso + T_dpto + C_postal +T_TelefonoPart + T_telCelular + T_email + D_nacimiento A6: C_carrera + T_carrera 3FN/ A3: No aplicable 3FN/ A4:
No aplicable C_materia X X C_Carrera OX
134. Matriz de Claves A3 A4 A5 A6 C_Alumno X X
135. Diagrama de Entidad Relacin A3 A4 A6 A5 C_materia C_carrera 136. Diseo 137. Modelo de Implementacin del Usuario de Imp. del Sistema de Programas de Tareas de Procesadores 138. Herramientas Herramientas MODELO LE DC DD DFD DER MINI DIAL. DE LIS PANT ESENCIAL Ambiental X X X Comportamiento X X - Act. esenciales X X - Memoria esencial X X X X iMPLEMENTACION Usuario X X X X X Imp. del Sistema X X - Procesadores X X X - Tareas X X Programas X X X 139.
o o o
Representar un sistema que cumpla con el comportamiento deseado. Previamente, debe definirse la encarnacin. Si bien para un problema puede haber mltiples soluciones, es conveniente desarrollar una. Modelo de Implementacin Objetivo y caractersticas
140. Modelo de Implementacin
o o
Definir la encarnacin significa decidir con que tecnologa se quiere implementar el sistema. Comprende todos los recursos necesarios para que el sistema funcione y lleve a cabo todos los procesos para poder cumplimentar los requerimientos del mismo.
Encarnacin 141. Modelo de Implementacin Encarnacin
o o o o o
Definir la arquitectura del sistema de computacin. Definir el equipamiento. Definir los procedimientos. Definir el modo de procesamiento. Definir los procesadores a utilizar .
142. Modelo de Imp. del Sistema
o o o
Muestra los procesadores que deben llevar a cabo las distintas actividades del sistema. Muestra lo que debe hacer el sistema y como lo har. Describe la forma en que el sistema reaccionar ante los distintos estmulos .
143. Modelo de Implementacin Informe Tcnico
Situaciones 1. existencia de equipamiento usable 2. existencia de equipamiento obsoleto o fuera de contexto 3. combinacin de las dos anteriores 4. no existencia de equipamiento
Entornos Condicionante (Econmico, Tcnico) No condicionante
o o o o o
Arquitectura completa del sistema que soporta al proyecto. Volumen de Informacin (general). Volumen de Transacciones (general, por puesto). Tipo de Interfaces requerida (grfica o textual, por puesto). Volumen y tipo de info. manejada (por puesto).
o o o
Ubicacin del procesamiento (local/remoto/centralizado, por puesto ) Modalidad del procesamiento (transaccional, analtico, ambas, por puesto ) Tipo de confidencialidad (alta/acotada/nula, por puesto)
146. Modelo de Imp. del Sistema de Imp. del Sistema de Programas de Tareas de Procesadores del Usuario 147.
o o
Muestra quien o que ejecutar cada transformacin descripta en el Modelo de Comportamiento.
Modelo de Procesadores Objeto 148. Modelo de Procesadores Tipos de Procesadores
o o o
149.
Hardware Software Humanos
o o
Se representa por medio de un solo D.F.D. Cada burbuja del D.F.D. representa a alguien o algo (procesador) que ejecutar una parte del procesamiento requerido para poder implementar el sistema. Modelo de Procesadores Composicin
150. Modelo de Procesadores Composicin P1 P2 P3 151. Modelo de Procesadores Relacin con el Diagrama de Contexto P1 P2 P3 Sistema XXX 152.
o o
Si todo el sistema fuera atendido por un nico procesador ambos modelos deben coincidir. Modelo de Procesadores Relacin con el Diagrama de Contexto
153.
Descripcin de las caractersticas tecnolgicas de cada procesador incluido.
o o o o o
Descripcin de la configuracin de cada procesador incluido. Descripcin de la red fsica que une los procesadores. Descripcin de los flujos de datos externos e intraprocesadores. Descripcin del soporte tecnolgico de los flujos de datos (pantallas, listados, documentos, protocolos de comunicacin, etc....)
Incorporar la versin del modelo, en los casos que corresponda.
Modelo de Procesadores Completamiento del Modelo 154.
As como el Modelo Ambiental fija el alcance del sistema, el Modelo de Procesadores fija el alcance de la Implementacin. Puede ser til presentar al usuario varios modelos, mostrando as varias alternativas de implementacin y encarnacin.
Modelo de Procesadores Alcance de la implementacin 155.
Las restricciones que se impongan a la implementacin del sistema pesan sobre la decisin de cmo construirlo. Es posible llegar a un punto en el cual las restricciones no sean compatibles con los requerimientos. Modelo de Procesadores Restricciones
156.
o o
Restringir los requerimientos, implementando parcialmente el modelo esencial. Levantar las restricciones, posibilitando la implementacin total del modelo esencial. Modelo de Procesadores Alternativas ante las Restricciones
157. Modelo de Imp. del Sistema de Imp. del Sistema de Programas del Usuario de Tareas de Procesadores 158.
o o
Describir las tareas a efectuar por los distintos procesadores.
Modelo de Tareas Objeto 159.
o o
El Modelo de Tareas es al Modelo de Procesadores, lo que el de Comportamiento es al Ambiental. Cada burbuja del Modelo de Procesadores representa el contexto propio de un procesador.
Modelo de Tareas Caractersticas 160. Modelo de Tareas Relacin con el Modelo de Procesadores F1 F2 F4 F5 F3 Pa Pb Pc Tarea 1 Tarea 2 F1 F4 F5 A2 A1 Nivel 1 del Procesador a 161.
En el Modelo de Comportamiento figuran las transformaciones que el sistema debe ejecutar. En el Modelo de Tareas figura como se ejecutan las transformaciones. El comportamiento describe la esencia y las tareas su implementacin. Modelo de Tareas Diferencias con el Modelo de Comportamiento
162.
o o o
Para la descripcin de tareas se aplica la misma tcnica que para las funciones: Desagregacin . Cada procesador se expande en un D.F.D de nivel 1, y estos en D.F.D. de nivel 2 y as sucesivamente. Los modelos diferirn del Modelo de Comportamiento en funcin de las restricciones tecnolgicas de cada procesador.
Modelo de Tareas Desarrollo del Modelo de Tareas 163.
o o o
La distribucin de transformaciones entre procesadores obliga tambin a distribuir los datos. La representacin de los datos en cada procesador estar ligada al soporte fsico que se utilice. El diagrama de entidad-relacin puede no ser una herramienta vlida para la representacin de los datos. Modelo de Tareas Desarrollo del Modelo de Datos
164.
o o
El D.F.D. describe que transformaciones se efectan en un sistema. La especificacin de procesos describe como se efecta una transformacin. En algunos casos puede ser necesario describir cuando tiene lugar una transformacin. Este es el objetivo que persigue el agregado del Flujo de Control en los D.F.D. Modelo de Tareas Agregado del Flujo de Control
165. Modelo de Tareas Descripcin del Flujo de Control Flujo de Control Proceso de Control 166.
o o o
Los flujos de control no acarrean datos, solo indican que algo ha ocurrido. Pueden provenir del entorno o de una transformacin de los datos. Las transformaciones de control procesan estos flujos y generan otros que activan o desactivan la ejecucin de procesos.
Modelo de Tareas El Flujo de Control 167.
Cuando la implementacin requiere que se controle la posibilidad de ejecutar o no una transformacin en un momento dado. Esto se da cuando
Un proceso no puede ser activado durante la ejecucin de otro. Un proceso puede ser activado solo si otro esta activado. Un proceso puede ser activado solo durante un perodo de tiempo.
Modelo de Tareas Cuando modelar el Control 168. Modelo de Tareas Descripcin de las transformaciones de Control PEDIDOS CONTROLAR RECEPCIN DE PEDIDOS PRODUCTOS HABILITAR DESHABILITAR RECIBIR PEDIDOS PREPARAR ENTREGAS ENTREGAS PEDIDOS CLIENTES HABILITAR DESHABILITAR ENTREGAS PREPARADAS SON LAS 8:00 SON LAS 18:00 169. Modelo de Tareas Diagrama de Transicin de Estado Enfatiza el comportamiento dependiente del tiempo del sistema. 170. Modelo de Tareas Diagrama de Transicin de Estado
Notacin
Estados Cada rectngulo representa un estado en el que se puede encontrar el sistema.
171. Modelo de Tareas Diagrama de Transicin de Estado Un conjunto de circunstancias o atributos que caracterizan a una persona o cosa en un tiempo dado; forma de ser; condicin. 172. Modelo de Tareas Diagrama de Transicin de Estado
Notacin Flechas
Que representan los cambios de estado.
173. Modelo de Tareas Diagrama de Transicin de Estado
Condiciones y acciones Condiciones que causan un cambio de estado. Acciones que el sistema toma cuando cambia de estado.
174. Modelo de Tareas Diagrama de Transicin de Estado ESTADO 1 ESTADO 2 Condicin Accin 175. Modelo de Tareas Relacin entre un DFD y un DTE 1 3 2 X Y ESTADO 1 ESTADO 2 Seal X Activar Burbuja 2 ESTADO 3 Seal Y Activar Burbuja 3 176. Modelo de Tareas Relacin entre un DFD y un DTE En la mayora de los casos, el DTE representa una especificacin de proceso para una burbuja de control en un DFD. Note que la condiciones en un DTE corresponden a los flujos de control entrantes en un DFD y las acciones en el DTE corresponden a los flujos de control de salida en el DFD. 177. Modelo de Tareas Diagrama de Transicin de Estado Espera Recibiendo pedidos Preparando entregas Entregas preparadas Son las 8 Activar recibir pedidos Son las 18 Desactivar recibir pedidos Activar preparar entregas Son las 8 Desactivar preparar entregas y Activar recibir pedidos 178. Modelo de Implementacin de Procesadores de Programas del Usuario de Imp. del Sistema de Tareas 179.
Describir una tarea computarizada en funcin de los mdulos de software que interactan para poder ejecutarla. Modelo de Programas Objeto
180.
En los modelos de tareas que corresponden a ambiente computarizado, las tareas se implementan a travs de programas.
o o
Estas tareas requieren un nivel ms de modelado. La herramienta utilizada para modelar los programas es el diagrama de estructura. Modelo de Programas Desarrollo
181. Modelo de Programas Diagrama de flujo de datos Baja de cliente clientes Cancelar cta. del cliente pedidos 182. Modelo de Programas Diagrama de estructura Cancelar Cta. de Clte. Recibir baja de cliente Registrar causa de baja Cancelar pedidos pend. Leer cliente Actualizar cliente Leer pedidos de cliente Cancelar pedido Baja de clte. # clte. Baja de clte. # clte. clte. clte. estado # clte. # pedido fin # pedido fin 183.
o o o o o
Disminuir los costos de programacin Tener una visin clara de la estructura de los programas. Facilitar la construccin. Facilitar la prueba. Facilitar el mantenimiento.
Modelo de Programas Razones para modelar programas 184.
En todo sistema existen tareas que ejecutan rutinas comunes organizadas de forma diferente. El modelar los programas permite ubicar esas rutinas y construirlas por nica vez para todo el sistema. El mayor costo de desarrollo se recupera con creces al momento de mantener el sistema. Modelo de Programas Rutinas comunes
185.
o o
Si la transformacin ser implementada utilizando algn utilitario de software disponible. Si el grado de complejidad es tan bajo que una especificacin de procesos de la transformacin es suficiente. Modelo de Programas Cuando NO modelar la estructura
186.
o o o o o o
Desarrollar la implementacin del modelo de datos. Desarrollar los mdulos comunes a distintas tareas. Desarrollar los mdulos propios de cada tarea. Cargar el modelo de datos. Probar las tareas unitariamente. Probar el sistema en su conjunto. Modelo de Programas Organizacin de la construccin
187.
o o o
Es la fuerza de interconexin entre mdulos, es decir de que manera se relacionan los distintos mdulos.
Modelo de Programas Acoplamiento 188.
o o
Agregar detalle de acoplamiento y cohesin. FAN IN - FAN OUT.
Modelo de Programas 189.
o o o o
Por estructura Global Comn. Por Contenido. Por Control. Por Datos.
Modelo de Programas Tipos de acoplamiento 190.
El diseo modular intenta minimizar la relacin entre elementos que no estn en el mismo mdulo. Esto se logra minimizando las relaciones entre mdulos y maximizando entre elementos del mismo mdulos.
La cohesin nos indica la relacin entre elementos internos.
Modelo de Programas Cohesin 191.
o o o o o o o
Por Coincidencia. Lgica. Temporal. Por Procedimiento. Por Comunicacin. Secuencial. Funcional. Modelo de Programas Tipos de cohesin
192.
o o o o o o
Dividir la Decisin. Estructura del Sistema. Reporte de Errores. Edicin. Estado de la Memoria. Matcheando la Estructura del Programa a la Estructura de Datos. Modelo de Programas Recomendaciones para el diseo
193.
o o o o o o
Mdulo de Derechos Exclusivos. Inicializacin y Finalizacin de Mdulos. Generalidad y Restriccin. Redundancia. FAN-IN. FAN-OUT. Modelo de Programas Recomendaciones para el diseo

Ingeniería Del Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería Del Software

Cargado por

Copyright:

Formatos disponibles

1. Ingeniera del Software 2.

4. Gestin de Proyectos tres pes5. El Espectro de la gestin

6. Conceptos sobre gestin de proyectos

Seleccin. Gestin de rendimiento. Entrenamiento. Retribucin. Desarrollo cultural. Espritu de equipo.

11. Jefes de Equipos

Qu es lo que buscamos cuando seleccionamos a alguien para dirigir un proyecto de SW?

Motivacin. Organizacin. Ideas o Innovacin.

14. Ideas o Innovacin

15. Gestor de Proyectos

16. Resolucin del problema

17. Dotes de Gestin

18. Incentivos de los logros

19. Influencia y construccin de espritu de equipo.

El Equipo de SW 23. o No tiene un jefe permanente.

Descentralizado democrtico (DD) 24. o Tiene un jefe definido.

La comunicacin entre el jefe y los miembros del equipo es vertical.

Centralizado controlado (CC) 26. o Siete factores a considerar

Factores a considerar 27. Paradigmas de organizacin

28. Paradigma cerrado

29. Paradigma aleatorio

30. Paradigma abierto

31. Paradigma Sincronizado

32. Cohesin de equipos

33. Cohesin de equipos

34. Cohesin de equipos

35. Tcnicas de coordinacin de proyectos

36. Formal, enfoque impersonal

37. Formal, procedimientos interpersonales

38. Informal, procedimientos interpersonales

39. Comunicacin electrnica

40. Red interpersonal

42. mbito del SW

Encajar el SW a construir en un sistema. La limitaciones se imponen como resultado del contexto.

44. Objetivos de informacin

Qu datos visibles se obtienen del cliente. Qu datos son requeridos de entrada.

45. Funcin y rendimiento

Qu funcin realiza el SW para transformar la informacin de entrada en una salida.

46. mbito de proyecto

47. Descomposicin del problema

49. Maduracin del problema y proceso

Comunicacin con el cliente. Planificacin.

Anlisis de riesgo. Ingeniera. Construccin y entrega. Evaluacin del cliente.

50. Comunicacin con el Cliente

52. Anlisis de riesgo

Tareas requeridas para valorar los riesgos tcnicos y de gestin.

Tareas requeridas para construir una o ms representaciones de la aplicacin.

54. Construccin y entrega

Tareas requeridas para construir, probar instalar y proporcionar asistencia al usuario.

55. Evaluacin del cliente

56. Gestin efectiva de un proyecto de software 57.

Gestin efectiva de un proyecto de software 58. Gestin Efectiva

Ambito de trabajo. Riesgos. Recursos. Tareas. Hitos. Esfuerzo. Plan.

59. Recursos - Software

60. Integracin de Sistemas 61.

Integracin de sistemas 62. o Elementos Esenciales

Manejo del Riesgo. Manejo de Proyectos. Integracin y Testeo.

Integracin de sistemas 63. Integracin de Sistemas

64. Integracin de Sistemas 65. Integracin de Sistemas

66. Integracin de Sistemas

67. Desarrollo y Gerenciamiento

Objetivos del Manejo de Proyectos

Producir un resultado o producto definido en total concordancia con el presupuesto y cronograma.

68. Desarrollo y Gerenciamiento