FACULTAD DE CIENCIAS Y TECNOLOGIA
RED NACIONAL UNIVERSITARIA
SYLLABUS
Facul Facultad tad de Cienci Ciencias as y Tecnol Tecnología ogía Ingeniería de Sistemas OCTAVO SEMESTRE Ingeniería de Soft Software ware
Gestión Académica I / 2011
Syllabus elaborado po r: Ing. Reynaldo Einar Zabaleta Rioja
U N I V E R S I D A D
D E 1
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
UDABOL UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLE P LENA NA mediante mediante R. M. 288/01
VISIÓN DE L A UNIVERSIDAD Ser la Universidad líder en calidad educativa.
MISIÓN DE LA UNIVERSIDAD Desarrollar la Educación Superior Universitaria con calidad c alidad y competitividad al servicio de la sociedad.
Estimado(a) estudiante: El syllabus que ponemos en tus manos es el fruto del trabajo intelectual de tus docentes, quienes han puesto sus mejores empeños en la planificación de los procesos de enseñanza para brindarte una educación educación de la más alta calidad. calidad. Este documento te servirá de guía para que organices mejor tus procesos de aprendizaje y los hagas mucho más productivos. Esperamos que sepas apreciarlo y cuidarlo.
U N I V E R S I D A D
D E 2
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
UDABOL UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLE P LENA NA mediante mediante R. M. 288/01
VISIÓN DE L A UNIVERSIDAD Ser la Universidad líder en calidad educativa.
MISIÓN DE LA UNIVERSIDAD Desarrollar la Educación Superior Universitaria con calidad c alidad y competitividad al servicio de la sociedad.
Estimado(a) estudiante: El syllabus que ponemos en tus manos es el fruto del trabajo intelectual de tus docentes, quienes han puesto sus mejores empeños en la planificación de los procesos de enseñanza para brindarte una educación educación de la más alta calidad. calidad. Este documento te servirá de guía para que organices mejor tus procesos de aprendizaje y los hagas mucho más productivos. Esperamos que sepas apreciarlo y cuidarlo.
U N I V E R S I D A D
D E 2
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
SYLLABUS I. Asignatura: Código: Requisito: Carga horaria: Horas teóricas: Horas prácticas: Créditos:
Ingeniería de Software CMP 518 CMP 425 80 horas 80 4
II. OBJETIVOS GENERALES DE LA ASIGNATURA. •
•
• • • • • •
Valorar la aplicación de un modelo orientado a objetos en la estructura de objetos, no en la estructura de procedimientos. Definir los elementos de un sistema específico mediante el modelado, diseño e implementación del método orientado a objetos. Justificar la utilidad del desarrollo orientado a objetos a través de ejemplos. Evaluar proyectos relacionados modelado y diseño orientado a objetos Fundamentar conceptos teóricos, métodos y técnicas del enfoque orientado a objetos Modelar un sistema desde tres puntos de vista distintos: Modelo de objetos, modelo dinámico, modelo funcional. Construir un modelo de un dominio de aplicación con detalles de implementación en el diseño del sistema. Traducir las clases de objetos y las relaciones desarrolladas en un lenguaje de programación.
III. PROGRAMA PROGRAMA ANALÍTICO ANA LÍTICO DE LA ASIGNATURA. ASIGNATURA. UNIDAD 1: SOFTWARE E INGENIERÍA DE SOFTWARE TEMA 1. INTRODUCCIÓN 1.1. Objetivos de la ingeniería de software. 1.2. Clasificación y tipos 1.3. El ciclo de vida de un sistema de software. 1.4. Especificación, codificación y prueba de algoritmos. 1.5. Corrección. 1.6. Verificabilidad. 1.7. Confiabilidad. 1.8. Eficiencia. 1.9. Facilidad de mantenimiento. 1.10. Reusabilidad y portabilidad. TEMA 2. GESTIÓN DE PROYECTOS 2.1. Introducción 2.2. Modelo de procesos IEEE 1074/991 2.3. Planificación 2.4. Gestión de configuración 2.5. Gestión de calidad. U N I V E R S I D A D
D E 3
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
UNIDAD 2: ANÁLISIS DE REQUISITOS DEL SOFTWARE Y DIMENSIONAMIENTO TEMA 3. INGENIERÍA DE REQUISITOS 1.1. Introducción a la ingeniería de requisitos 1.2. Tipos de requerimientos. 1.3. Clasificación de los requerimientos. 1.4. El proceso de la ingeniería de requerimientos. 1.5. La factibilidad del proyecto. 1.6. La definición de requerimientos. 1.7. La especificación de requerimientos. 1.8. Técnicas para especificar los requerimientos TEMA 4. HERRAMIENTAS PARA CONSTRUIR PROGRAMAS 2.1. Introducción 2.2. Tipos de herramientas. 2.3. Características deseadas. 2.4. Funciones de las herramientas case 2.5. Estudio de Rational Rose., Case 2 studio, Architect. etc. UNIDAD 3: DISEÑO, CODIFICACIÓN, PRUEBA Y MANTENIMIENTO TEMA 5. PROCESO DE DISEÑO. E IMPLEMENTACIÓN 1.1. Consideraciones al proceso de diseño 1.2. El ambiente de implementación. 1.3. El modelo de diseño. 1.4. El diagrama de clases mediante patrones 1.5. El diagrama de secuencia. 1.6. El diagrama de interacción 1.7. El diagrama de componentes. 1.8. El diagrama de nodos TEMA 6. EL PROCESO DE CODIFICACIÓN 2.1. Consideraciones al proceso de codificación 2.2. Tareas asociadas. 2.3. Paradigmas de programación 2.4. Lenguajes de programación 2.5. Mapeo al código de los elementos del diseño.
U N I V E R S I D A D
D E 4
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
TEMA 7. EL PROCESO DE PRUEBA Y MANTENIMIENTO 3.1. Prueba tradicional. 3.2. Prueba orientada a objetos. 3.3. Prueba de unidad. 3.4. Prueba de integración 3.5. Plan de actividades. 3.6. Validación de los casos de uso 3.7. Mantenimiento. 3.8. Tipos de mantenimiento 3.9. Actividades del mantenimiento.
U N I V E R S I D A D
D E 5
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
IV. SISTEMA DE EVALUACIÓN DE APRENDIZAJES. El sistema de evaluación hace hincapié en varios tipos de calificación: Diagnóstica: es la evaluación de los saberes o conocimientos previos de los y las estudiantes, así como de sus ritmos y estilos de aprendizaje y sus tipos de inteligencia, que sirve al docente como punto de partida para, el desarrollo curricular, para la mejor organización y estructuración de las secuencias de aprendizaje, de modo que estas tengan en cuenta no sólo el punto de partida del grupo con el que trabajará durante el semestre sino además las diferencias y especificidades de cada estudiante para que los aprendizajes resulten más efectivos y permitan el óptimo desarrollo integral de cada uno(a). Procesual o de desempeño o formativa: en esta forma de evaluación se valora el avance del o de la estudiante de su nivel de desarrollo real (detectado mediante la evaluación diagnóstica) a su nivel de desarrollo potencial (detectado mediante diversas actividades o tareas). Esta forma de evaluación, por su naturaleza, es eminentemente cualitativa aunque puede ser valorada cuantitativamente mediante un sistema de puntaje que permita apreciar los avances del o de la estudiante en su zona de desarrollo próximo (zdp) (o, incluso, fuera de ella, en el caso de que el proceso de aprendizaje rebase la misma y dé lugar a nuevas zdp). La ponderación de la asignatura de Ingenieria de Software dentro la Evaluación Procesual, contempla la realización de actividades formativas a desarrollar (Work Papers, Difs, Participación, Evaluación Diaria, Investigación, Congresos, Jornadas Científicas y Seminarios) y su calificación es sobre el 50 % de la calificación del primer y segundo parcial, estimando un promedio de todas las actividades. De resultados del proceso de aprendizaje: es la valoración de los resultados de los procesos de aprendizaje del o de la, estudiante durante el semestre. Esta forma de evaluación es tanto cualitativa como cuantitativa, por su naturaleza y por la función que cumple dentro de la evaluación. La evaluación de resultados en la asignatura específica se llevará a cabo de forma teórica y práctica aplicada a sistemas reales. La ponderación de esta evaluación es sobre 50 % de la calificación del primer y segundo parcial, en el caso del examen final es de 100%, que por disposiciones actuales esta dividido en 50% como prueba final y 50% procesual. . EVALUACION PROCESUAL DE RESULTADO PARCIAL 1 50% 50% PARCIAL 2 50% 50% FINAL 50% 50% EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL
U N I V E R S I D A D
D E 6
A Q U I N O
TOTAL 100% 100% 100% 100%
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
V. BIBLIOGRAFÍA. Bibliografía básica •
•
•
Booch G., "Análisis y Diseño Orientado a Objetos con Aplicaciones" - Segunda Edición - Editorial AddisonWesley/Diaz de Santos - 1996. Pressman R., "Ingeniería del Software, un Enfoque Práctico" - Tercera Edición - Editorial Mc Graw-Hill 1993. Rumbaugh J., "Modelado y Diseño Orientado a Objetos" – Editorial Prentice Hall – 1997.
Bibliografía co mplementaria •
•
Rumbaugh J., Jacobson I., Booch G., "El Lenguaje Unificado de Modelado. Manual de Referencia" Editorial Addison-Wesley - 2000. Larman C., "UML y Patrones" - Segunda Edición - Editorial Prentice-Hall – 2003.
U N I V E R S I D A D
D E 7
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
VI. PLAN CALENDARIO UNIVERSIDAD DE AQUINO-BOLIVIA UNIDAD ACADÉMICA DE ORURO
CALENDARIO ACADÉMICO GESTIÓN I/2011 TURNOS REGULAR-TRABAJO ESTUDIANTES NUEVOS-ANTIGUOS SEMANA
DEL
AL
ACTIVIDADES
OBSERVACIONES
1ra.
09-Mar
12-Mar
Avance de materia
TEMA 1. INTRODUCCIÓN
2da.
14-Mar
19-Mar
Avance de materia
TEMA 1. INTRODUCCIÓN
3ra.
21-Mar
26-Mar
Avance de materia
TEMA 2. GESTIÓN DE PROYECTOS
4ta.
28-Mar
02-Abr
Avance de materia
TEMA3. INGENIERÍA DE REQUISITOS
5ta.
04-Abr
09-Abr
Avance de materia
TEMA3. INGENIERÍA DE REQUISITOS
6ta.
11-Abr
16-Abr
Avance de materia
Inicio Primera Evaluación Parcial
Presentación de Notas
7ma.
18-Abr
23-Abr
Avance de materia
Conclusión Primera Evaluación Parcial
Presentación de Notas
8va.
25-Abr
30-Abr
Avance de materia
TEMA3. INGENIERÍA DE REQUISITOS
9na.
02-May
07-May
Avance de materia
10ma.
09-May
14-May
Avance de materia
11ra.
16-May
21-May
Avance de materia
12da.
23-May
28-May
Avance de materia
Inicio Segunda Evaluación Parcial
Presentación de Notas
13ra.
30-May
04-Jun
Avance de materia
Conclusión Segunda Evaluación Parcial
Presentación de Notas
14ta.
06-Jun
11-Jun
Avance de materia
TEMA6. EL PROCESO DE CODIFICACIÓN
15ta.
13-Jun
18-Jun
Avance de materia
TEMA6. EL PROCESODE CODIFICACIÓN
16ta.
20-Jun
25-Jun
Avance de materia
17ma.
27-Jun
02-Jul
Avance de materia
18va.
04-Jul
09-Jul
Inicio Evaluación Final
Presentación de Notas
19na.
11-Jul
16-Jul
Conclusión Evaluación Final
Transcripción de Notas
20va.
18-Jul
23-Jul
Evaluación del segundo turno
Transcripción de Notas
21ra.
25-Jul
26-Jul
Cierre de Gestión
TEMA 4. HERRAMIENTAS PARA CONSTRUIR PROGRAMAS TEMA 4. HERRAMIENTAS PARA CONSTRUIR PROGRAMAS TEMA5. PROCESO DE DISE O. E IMPLEMENTACIÓN
TEMA 7. EL PROCESO DE PRUEBA Y MANTENIMIENTO TEMA 7. EL PROCESO DE PRUEBA Y MANTENIMIENTO
FERIADOS 22 de abril
Viernes Santo
1 de mayo
Día del Trabajo
23 de junio
CorpusChristi
U N I V E R S I D A D
D E 8
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
VII. CONTROL DE EVALUACIONES 1° evaluación parcial Fecha: Nota: 2° evaluación parcial Fecha: Nota: Examen final Fecha: Nota: APUNTES
U N I V E R S I D A D
D E 9
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 1
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 4
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 518
TÍTULO DEL WORK PAPER: LA INGENIERÍA DE SOFTWARE Y EL PARADIGMA DE LO ORIENTADO A OBJETOS
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
U N I V E R S I D A D
D E 10
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
LA INGENIERÍA DE SOFTWARE Y EL PARADIGMA ORIENTADO A OBJETOS Según la definición del IEEE, citada por [Lewis 1994] " software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo". Según el mismo autor, "un producto de software es un producto diseñado para un usuario". En este contexto, la Ingeniería de Software (SE del inglés Software Engineering) es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software", que en palabras más llanas, se considera que "la Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad" [Jacobson 1998]. El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo". Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo" [Jacobson 1998]. El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define le alcance del proyecto y desarrolla un caso de negocio. La elaboración define un plan del proyecto, especifica las características y fundamenta la arquitectura. La construcción crea el producto y la transición transfiere el producto a los usuarios. Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés Unified Modeling Language) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO. EL PARADIGMA DE LO ORIENTADO A OBJETOS Antes de analizar los pasos del proceso de desarrollo de software se expondrán los conceptos fundamentales del paradigma que guía la tecnología OO. Existen conceptos ligados en torno a la tecnología orientada a objetos: el paradigma, los principios, el análisis y el diseño, mismos que a continuación se comentan.
U N I V E R S I D A D
D E 11
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
LA PROGRAMACIÓN ORIENTADA A OBJETOS La Programación Orientada a Objetos (OOP por sus siglas en inglés de Object Oriented Programming) como paradigma, "es una forma de pensar, una filosofía, de la cual surge una cultura nueva que incorpora técnicas y metodologías diferentes. Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontológica: el universo computacional está poblado por objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio de mensajes" [Greiff 1994]. Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodología (colección de características para la ingeniería de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP más a una metodología, que al paradigma. De aquí que "el interés en la OOP radica más en los mecanismos que aporta para la construcción de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994]. La Programación Orientada a Objetos desde el punto de vista computacional "es un método de implementación en el cuál los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarquía de clases unidas vía relaciones de herencia" [Greiff 1994]. Fundamentos de lo Orientado a Objetos El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto. En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO. Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulación. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes. Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles. Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia. Es la propiedad que distingue un objeto que está activo de uno que no lo está. Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado). Según [Booch 1986], los beneficios del enfoque OO son: •
•
•
• •
• •
U N I V E R S I D A D
D E 12
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada y recientemente Java. Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseños completos. Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología. El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad. •
• •
Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor , si su única función es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada. [Greiff 1994] comenta que el Análisis Orientado a Objetos (OOA por sus siglas en inglés de Object Oriented Analysis) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema". Según [Booch 1986], el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos lógico y físico tal como los modelos estáticos y dinámicos del sistema bajo diseño". En cuanto a las metodologías OO, diremos que hay un gran número de métodos orientado a objetos actualmente. Muchos de los métodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. Algunos de las metodologías más conocidas y estudiadas hasta antes del UML según [Jacobson 1992] son: Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros. Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group. • • • • • • •
Cuestionario: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Que entiende por el Ingeniería de software Como define la IEEE a la Ingeniería de Software Que es un proceso dentro de la Ingeniería de Software Definir que es el ciclo de vida del Software Explicar que es UML Que entiende por el paradigma orientado a objetos. Que es la programación orientada a objetos. Explicar los Fundamentos de lo Orientado a Objetos Que es Abstracción, Encapsulación y Modularidad. Que es Jerarquía o herencia, Concurrencia, Persistencia.
U N I V E R S I D A D
D E 13
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 2
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 6
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 518
TÍTULO DEL WORK PAPER: CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE I
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
U N I V E R S I D A D
D E 14
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE I DEFINICIÓN DE PROCESO: Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto formado por: Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador. Su estado de ejecución en un momento dado, esto es, los valores de los registros de la CPU para dicho programa. Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos. Otra información que permite al sistema operativo su planificación. • •
• •
Esta definición varía ligeramente en el caso de sistemas operativos multihilo donde un proceso consta de uno o más hilos, la memoria de trabajo (compartida por todos los hilos) y la información de planificación. Cada hilo consta de instrucciones y estado de ejecución. Los procesos son creados y destruidos por el sistema operativo, así como también este se debe hacer cargo de la comunicación entre procesos, pero lo hace a petición de otros procesos. El mecanismo por el cual un proceso crea otro proceso se denomina bifurcación (fork). Los nuevos procesos son independientes y no comparten memoria (es decir, información) con el proceso que los ha creado. En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La diferencia estriba en que un proceso solamente puede crear hilos para sí mismo y en que dichos hilos comparten toda la memoria reservada para el proceso. CICLO DE VIDA DE UN PROYECTO DE SOFTWARE: Se entiende por ciclo de vida de un proyecto software a todas las etapas por las que pasa un proyecto, desde la concepción de la idea que hace surgir la necesidad de diseñar un sistema software, pasando por el análisis, desarrollo, implantación y mantenimiento del mismo y hasta que finalmente muere por ser sustituido por otro sistema. Aunque UML es bastante independiente del proceso, para obtener el máximo rendimiento de UML se debería considerar un proceso que fuese: Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto básico para establecer el comportamiento del deseado del sistema, para validar la arquitectura, para las pruebas y para la comunicación entre las personas involucradas en el proyecto. Centrado en la arquitectura de modo que sea el artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema. Un proceso iterativo, que es aquel que involucra la gestión del flujo de ejecutables del sistema, e incremental, que es aquel donde cada nueva versión corrige defectos de la anterior e incorpora nueva funcionalidad. Un proceso iterativo e incremental se denomina dirigido por el riesgo, lo que significa que cada nueva versión se ataca y reducen los riesgos más significativos para el éxito del proyecto. Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo e incremental pude descomponerse en fases, donde cada fase es el intervalo de tiempo entre dos hitos importantes del proceso, cuando se cumplen los objetivos bien definidos, se completan los artefactos y se toman decisiones sobre si pasar o no a la siguiente fase.
U N I V E R S I D A D
D E 15
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
En el ciclo de vida de un proyecto software existen cuatro fases. La iniciación, que es cuando la idea inicial está lo suficientemente fundada para poder garantizar la entrada en la fase de elaboración, esta fase es cuando se produce la definición de la arquitectura y la visión del producto. En esta fase se deben determinar los requisitos del sistema y las pruebas sobre el mismo. Posteriormente se pasa a la fase de construcción, que es cuando se pasa de la base arquitectónica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan los requisitos y las pruebas que ha de soportar. La transición, cuarta fase del proceso, que es cuando el software se pone en mano de los usuarios. Raramente el proceso del software termina en la etapa de transición, incluso durante esta fase el proyecto es continuamente reexaminado y mejorado erradicando errores y añadiendo nuevas funcionalidades no contempladas. Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteración, que es un conjunto bien definido de actividades, con un plan y unos criterios de evaluación, que acaban en una versión del producto, bien interna o externa. Ciclo de Vida: Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”. Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas. La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles. La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos). De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos. ELEMENTOS DE UN CICLO DE VIDA: Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
U N I V E R S I D A D
D E 16
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases. A continuación presentamos los distintos elementos que integran un ciclo de vida: Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). •
Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases. Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
U N I V E R S I D A D
D E 17
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Esquema general de operación de una fase
Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto. •
TIPOS DE MODELOS DE UN CICLO DE VIDA: Las principales diferencias entre distintos modelos de ciclo de vida están en: o El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado. o Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo). o La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle: CICLO DE VIDA LINEAL: Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase). Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
U N I V E R S I D A D
D E 18
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Ejemplo de ciclo lineal para un proyecto de construcción
CICLO DE VIDA CON PROTOTIPADO: A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas. Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo. A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.
Cuestionario: 1. 2. 3. 4. 5. 6. 7.
Dentro de la Ingeniería moderno cual es el concepto de Proceso informático. Cual es el concepto de aplicabilidad del termino multihilo Que es el ciclo de vida de un proyecto de Software Cuales son los Elementos del ciclo de vida del s.w. Que son datos de entrada y salida. Como se establecen los distintos Tipos de Modelos del ciclo de vida del S.w. Resumir un ciclo de vida del s.w. con el cual más se utiliza.
U N I V E R S I D A D
D E 19
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 3
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 6
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 518
TÍTULO DEL WORK PAPER: CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE 2
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Abril 2011
FECHA DE ENTREGA: Abril 2011
U N I V E R S I D A D
D E 20
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE 2 CICLO DE VIDA EN ESPIRAL: El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente. A menudo lafuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces. El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos). En cada vuelta el producto gana en “madurez” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse. MODELOS DE PROCESOS DE SOFTWARE: Al día de hoy, ha aumentado la complejidad con la que se desarrollan sistemas de información para la industria, por lo que resulta difícil generar productos que cumplan cabalmente con las expectativas del cliente. Para responder a esta situación, han surgido una serie de herramientas, técnicas y modelos que facilitan a las organizaciones, encargadas de las tecnologías de la información, generar productos que cumplan las expectativas del cliente e incluso las rebasen, herramientas que prometen ser la solución a los problemas de calidad, costo y tiempos de desarrollo; de éstas podemos mencionar a los “modelos de calidad” como la norma ISO 9000-2000, la ISO/IEC TR 15504 y el modelo CMM (Capability Maturity Model del Software Engineerig Institute SEI). Aunque en el pasado se reconocía la necesidad de crear software de calidad, no se había hecho un esfuerzo serio para que nuestra industria generara productos que nos dieran la oportunidad de competir en el mercado internacional, con calidad equiparable o superior a la de países como la India o Irlanda. Afortunadamente, dicha situación ha cambiado; nuestro gobierno en conjunto con la industria, ha iniciado un esfuerzo serio para impulsar la industria del software a través del Programa para el Desarrollo de la Industria del Software (PROSOFT). PROSOFT reconoce el estado incipiente de la industria mexicana de software, así como la necesidad de invertir cantidades crecientes de recursos en capital de tecnologías de información con objeto de contribuir de manera sostenible al crecimiento de la economía y la generación de empleos bien remunerados.
U N I V E R S I D A D
D E 21
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Con el programa, se pretende establecer una industria de software competitiva internacionalmente y asegurar su crecimiento a largo plazo, lo que situaría a México como líder de esta industria en Latinoamérica en 2012, además de convertirlo en líder desarrollador de soluciones de tecnologías de información de alta calidad y uso de software en Latinoamérica. 1. 2. 3. 4. 5. 6. 7. 8.
Este programa tiene siete estrategias de donde emergen varios proyectos que ayudarán a que se alcancen las metas previstas en éste: Promover las exportaciones y la atracción de inversiones. Educar y formar personal competente en el desarrollo de software, en cantidad y calidad convenientes. Contar con un marco legal promotor de la industria. Desarrollar el mercado interno. Fortalecer a la industria local. Alc Alca anzar nive iveles les inte intern rna acion ionales les en capacida idad de proc rocesos. Promover acciones conjuntas con los gobiernos estatales y construir infraestructura.
Para el caso de la estrategia 6, la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS), con el auspicio de la Secretaría de Economía propone un modelo concebido, diseñado y desarrollado por mentes mexicanas, adecuado para las necesidades específicas de México y con ventajas respecto de otros. El nuevo modelo, denominado MoProSoft, ofrece características que los otros no tienen de manera independiente; para su concepción, se tomaron las mejores prácticas de los otros modelos y se integraron y mejoraron otras; a continuación, mencionamos a qué se refiere cada modelo y algunas de sus ventajas y desventajas. NORMA ISO 9000-2000 Es una norma internacional destinada a evaluar la capacidad de la organización para cumplir los requisitos del cliente, los reglamentarios y los propios de la organización. Ventajas Tiene un mecanismo de certificación bien establecido. Está disponible y es conocida. Desventajas No es específica para la industria de software. No es fácil de entender. No está definida como un conjunto de procesos. No es fácil de aplicar. Capability Maturity Model (CMM) Es un marco evolutivo organizado en cinco niveles para lograr la mejora continua de procesos. Ventajas Específico para el desarrollo y mantenimiento de software. Definido como un conjunto de áreas clave de procesos. Tiene un modelo de evaluación. Desde 1998 empezó a popularizarse en México. Existen organizaciones evaluadas. Desventajas Es un modelo extranjero, no internacional. No es fácil de entender (inglés, 18 KPAs, 220 páginas). No es fácil de aplicar (pensado para organizaciones grandes). La mejora no está enfocada directamente a los objetivos de negocio. La evaluación es costosa y no tiene periodo de vigencia. Se está abandonando a favor de CMM-I (el SEI dejará de dar soporte a partir del 2005). • •
• • • •
• • • • •
• • • • • •
U N I V E R S I D A D
D E 22
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
ISO/IEC TR 15504 Define el modelo de referencia de procesos de software y de capacidades de procesos que constituyen la base para la evaluación de procesos de software. Se compone de 9 partes de las cuales la 2, 3 y 9 son normativas y las demás informativas. Ventajas Específico para el desarrollo y mantenimiento de software. Fácil de entender (24 procesos, 16 páginas). Definido como un conjunto de procesos. Orientado a mejorar los procesos para contribuir a los objetivos del negocio. Desventajas No es práctico ni fácil de aplicar. Tiene solamente lineamientos para un mecanismo de evaluación. Todavía no es norma internacional. • • • •
• • •
MoProSoft Es un Modelo de Procesos para la Industria de Software que fomenta la estandarización de su operación, a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Ventajas Fácil de entender. Fácil de aplicar. No es costoso en su adopción. Sirve de base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 o CMM.1 V1.1. • • • •
A de decir de de su sus cre creadores res, el modelo es está ori orie entad tado a pe pequeñas y median ianas em empres resas, hecho fav favorab rable si si se considera que aproximadamente el 80% de las empresas desarrolladoras de software del país caen en esta categoría. Su principal fortaleza es que integra varias de las prácticas propuestas por los otros modelos y corrige algunas de sus desventajas, como son el hecho de que no ha sido liberado por completo o al menos falta el modelo de evaluación; además, está en proceso de convertirse en norma compitiendo con el proyecto de norma ISO/IEC TR 15504 y aunque no ha sido probado, se planea realizar pilotos en algunas organizaciones para evaluar qué tan fácil resulta su implantación determinando los recursos necesarios. Lo interesante para nosotros como academia, es que tenemos la oportunidad de proponer productos concebidos y desarrollados en México, adecuados a nuestros requerimientos y realidad, lo que repercute de manera directa en la gama de soluciones que tiene una organización para resolver sus necesidades. MODELO DE CASCADA: En Ingeniería de software el desarrollo en cascada, cascada, también llamado modelo en cascada, cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. Un ejemplo de una metodología de desarrollo en cascada es: 1. An Anális lisis de req requisit isito os 2. Diseño 3. Codificación 4. Pruebas U N I V E R S I D A D
D E 23
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
5. 6.
Implantación Mantenimiento
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy. FASES DEL MODELO Análisis de requisitos Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Diseño Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Codificación Es la fase de programación propiamente dicha. Aquí se desarrolla el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. corregir errores. Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. Implantación El software obtenido se pone en producción. Mantenimiento Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios. Variantes Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos. MODELO DE PROTOTIPO:
U N I V E R S I D A D
D E 24
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
MODELO DE RIESGO Y ESPIRAL: Qué es el Modelo Espiral? Desarrollado por B. Boehm, básicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa; esta orientado a evitar riesgos de trabajo. No define en detalle el sistema completo a la primera. Los desarrollares deberían solamente definir las mas altas prioridades. Definir e implementarlas y entonces obtener un feedback de los usuarios (tal y como feedback distingue desarrollo "evolutivo" de "incremental"). Con este conocimiento, deberían entonces retroceder o volver al punto de partida para definir e implementar más y mejores partes. El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo. Este método esta basado en dos importantes principios: 1. La practica de diseñó profesional es caracterizar en términos de conocer, actuar en situaciones, conversación con la situación y reflexión en acción. Hay un distinto medio de proceso - orientación en esta aproximación al diseño. Es raro que el diseñador tenga el diseño en su cabeza por adelantado y que después meramente lo transcriba. Gran parte del tiempo del diseñador esta inmiscuido en una progresiva relación con su entorno. Una buena metáfora para describirlo es "la conversación con el material", como un escultor, quien esta ocupado en una conversación con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser. 2. La necesidad para diseñadores de tomar la practica de trabajo seriamente, de supervisar las formas en las que el trabajo se esta haciendo, en el sentido de una solución abierta y desplegada para aumentar la complejidad de una situación que el diseñador solo entiende parcialmente. El hecho por el cual se esta tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperación y comunicación. Una visión general del Modelo de Cascada puede ser la siguiente:
Cuestionario: 1. 2. 3. 4. 5.
Explicar el Ciclo de Vida en Espiral Que son los Modelos de Procesos de Software Investigar el modelo CMM (Capability Maturity Model del Software Engineerig Institute SEI) Explicar y ejemplificar el modelo de desarrollo de S.w. en cascada. Explicar y ejemplificar el modelo de desarrollo de S.w. en espiral.
U N I V E R S I D A D
D E 25
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 4
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 6
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 518
TÍTULO DEL WORK PAPER: LA GERENCIA DE PROYECTOS DE SOFTWARE
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Mayo 2011
FECHA DE ENTREGA: Mayo 2011
U N I V E R S I D A D
D E 26
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
LA GERENCIA DE PROYECTOS DE SOFTWARE En un contexto complejo, agudizado por la superficialidad generalizada con que se asumen las fases previas al inicio de los proyectos de software, emerge el gerente de proyecto. El líder cuyo objetivo consiste en mediar entre intereses y motivaciones diversas con el fin de llegar a una solución cuyos dividendos sean positivos tanto para el cliente como para el proveedor a quien representa. La gerencia de proyectos es un área que ha tenido un vasto desarrollo conceptual en las últimas 2 décadas. Iniciativas como la del Project Management Institute, PMI. Pretenden asentar las bases que conduzcan a la estandarización y clasificación de las actividades propias de la gerencia en diferentes áreas de conocimiento. Sin embargo, al igual que ocurre en otras ciencias relacionadas con el software, el desarrollo teórico y conceptual avanza vertiginosamente mientras los resultados de su aplicación en la ejecución de proyectos de software aún se encuentran en deuda. El mercado de soluciones de TI. Ha impuesto una serie de condiciones a la Gerencia de los proyectos que la han hecho particularmente distante de la gerencia de proyectos en otras áreas. Al iniciar un proyecto de software es normal que el alcance del proyecto no esté definido, no existen métricas que brinden una idea del tamaño del proyecto, no hay una metodología, buena o mala, a seguir durante la ejecución del proyecto. Resulta normal también que al inicio del proyecto se tenga un grupo de personas que nunca ha trabajado como equipo, un buen porcentaje de las personas desconoce la tecnología con la cuál debe trabajar y con una alta probabilidad es el primer proyecto que el gerente asume, cargo al que llegó gracias a que es un desarrollador destacado. El cliente, factor determinante del éxito de un proyecto de software Aunque a primera vista el proveedor de la solución es el directo responsable de los resultados del proyecto, una adecuada planeación, gestión y evaluación del avance constituyen herramientas fundamentales para la toma de decisiones del cliente. Un alto porcentaje de los riesgos inducidos en los proyectos de tecnologías de información se deben a deficiencias en la planeación inicial. Definición pobre del alcance del proyecto y asignación de recursos, presupuesto y cronograma aislada de los objetivos que se quieren alcanzar son algunos de los riesgos comunes que inducen los clientes en las primeras instancias de los proyectos. El mercado de soluciones de software demanda estrategias orientadas hacia la definición de cronogramas y costos de los proyectos en instancias incipientes, en las cuales no se ha efectuado una definición detallada de requerimientos hecho que obliga a tener amplios márgenes de error en la estimación de tiempo y costo en los proveedores. Algunos proveedores de soluciones de software optan por mitigar el riesgo elevando el costo de sus servicios con el fin poder asumir la responsabilidad en caso tal que el riesgo se concrete. Esta práctica disminuye significativamente la competitividad del proveedor y eleva innecesariamente los costos de desarrollo para los clientes, hecho que aumenta su inversión general en soluciones de software pero empobrece el alcance de los proyectos. Resulta conveniente efectuar labores de planeación detallada al interior de las organizaciones cliente, previas al inicio de los proyectos y a la apertura de concursos y licitaciones. Dichas tareas permitirán establecer con un buen nivel de detalle el objetivo que se pretende alcanzar con el desarrollo e implantación de la solución, las prestaciones o funcionalidad necesarias en la solución, una adecuada priorización de los requerimientos y una asignación de recursos, no solo económicos sino humanos, responsables de manejar el flujo de información y requerimientos cliente-proveedor y proveedor-cliente. U N I V E R S I D A D
D E 27
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
La planeación detallada conducirá a obtener los máximos beneficios al invertir en soluciones de TI, adicionalmente le dará elementos para la toma de mejores decisiones en la ejecución del proyecto y será una herramienta para la evaluación de sus proveedores de tecnología. La próxima vez que su proveedor de soluciones de software le pida profundizar en el análisis, previo a establecer compromisos de presupuesto y cronograma, seguramente se debe a que está interesado en ofrecerle una solución que se ajuste a su necesidad y de ofrecerle una perspectiva realista de planeación. Funciones de gerencia de proyectos de software: Partamos de la siguiente definición de administración de un proyecto: "La administración de un proyect o, se define como un sistema de procedimientos, prácti cas, tecnologí as y conocimientos del tema que permiten la planificación, organización, designación de personal, dirección y control necesarios, para poder manejar con é xito un proyecto de i ngenierí a de software" 1
Por tanto Tahyer, es concreto en afirmar que el "concepto de la universalidad de la administración nos permite usar las funciones de administración y actividades básicas de las principales corrientes de administración, como las funciones y actividades de alto nivel de la administración de proyectos de ingeniería de software". En consecuencia, es necesario conocer cuales son las actividades y funciones de la administración:
Figura 1: Modelo de funciones de gerencia ACTIVIDAD
DEFINICIÓN
Planificación
Pre-determinar un curso de acción para lograr los objetivos de la organización
Organización
Arreglar y relacionar el trabajo para lograr los objetivos y para delegar responsabilidad y autoridad para lograr esos objetivos
Dotación de personal
Seleccionar y capacitar al personal para los puestos en la organización
Dirección
Crear una atmósfera que ayudará y motivará a la gente para lograr los resultados finales deseados
Control
Medir y corregir el rendimiento de las actividades que se dirigen hacia los objetivos, de acuerdo a lo planificado Tabla 1: Principales funciones de la administración
U N I V E R S I D A D
D E 28
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Funcion es de gerencia
Actividades fundamentales de la gerencia
Planificación
Organización
Dotación de personal
Determinar los objetivos o metas Desarrollar estrategias Determinar cursos de acción Tomar decisiones Establecer procedimientos y reglas Desarrollar programas Predecir situaciones futuras Preparar presupuestos Documentar los planes del proyecto Identificar y agrupar las tareas requeridas Seleccionar y establecer las estructuras organizativas Definir responsabilidades y autoridad Documentar estructuras organizativas Identificar y agrupar las tareas requeridas Seleccionar y establecer las estructuras organizativas Definir responsabilidades y autoridad Documentar estructuras organizativas
Llenar los puestos de la organización Asimilar personal asignado recientemente Educar o entrenar al personal Hacer previsiones para el desarrollo general Compensar Finalizar las asignaciones Documentar las decisiones referentes a la asignación de personal
Dotación de personal
Dirección
Control
Proporcionar liderazgo Supervisar al personal Delegar autoridad Motivar al personal Coordinar actividades Facilitar las comunicaciones Resolver conflictos Manejar los cambios Documentar las decisiones de dirección Desarrollar estándares de rendimiento Establecer sistemas de monitoreo e informes Medir los resultados Iniciar acciones correctivas Premios y disciplina Documentar métodos de control
Tabla 2: Principales actividades de gerencia
U N I V E R S I D A D
D E 29
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Por tanto un gerente de proyectos, planifica, dirige, dota de personal, y controla un proyecto de ingeniería de software. Actividades de la administración de p royectos de ingeniería de software Ahora nos enfocaremos a la segunda pregunta que nos hicimos: ¿Cómo administrar proyectos de ingeniería de software? 1. Planificación Imagine por un momento que usted es director técnico de un equipo de fútbol, y tiene un juego muy importante dentro de un par de semanas, ¿usted elaboraría su estrategia de juego y táctica antes o durante el juego? de esta respuesta dependerá el éxito o fracaso del encuentro. De manera análoga, si usted es Gerente de un Proyecto es vital que elabore un plan de proyecto. En este plan, usted definirá, de acuerdo a las necesidades de su cliente, los objetivos y metas del proyecto, factores críticos de éxito, estimará los tiempos de cada actividad y tarea del proyecto, analizará los riesgos del proyecto, elaborará el presupuesto del proyecto. Este plan es la base que le permitirá después, hacer una evaluación post-proyecto y determinar si el proyecto fue exitoso o no. En esta parte debe plantearse por ejemplo, cuales serán los entregables del proyecto, entregará documentación, subsistemas, etc. Además así como un director técnico, plantea una estrategia de juego para el encuentro, de manera análoga deberá elegir que metodología de desarrollo utilizará, ¿el ciclo de vida tradicional? ¿El modelo en espiral? ¿RUP? ¿Programación extrema?, etc., cual de todas las metodologías de desarrollo de software o de ingeniería de software existentes o que combinación de ellas, es la mas adecuada para lograr el éxito del proyecto. Es por eso mi estimado lector, que usted deberá de tener un sólido conocimiento de ingeniería de software como lo había mencionado antes, no solo basta ser un buen administrador, también debe conocer bien el terreno de acción. 2. Organización Un proyecto así como una empresa, tiene una estructura organizacional, esta estructura tenderá a ser compleja cuando el proyecto tenga más entes involucrados y el proyecto en sí sea más complejo. Esto se cumple cuando usted tiene que organizar un proyecto en donde no solo intervienen el proveedor y el cliente, sino, por ejemplo, otros proveedores de su cliente o proveedores del proveedor por ejemplo. Es necesario determinar las responsabilidades para las actividades y tareas, línea de mando de cada ente. Esta actividad consiste en organizar actividades y tareas, agruparlas, definir roles y relaciones de autoridad en el proyecto, es decir diseñar una estructura organizativa del proyecto. Esta estructura organizativa, solo tendrá validez durante la existencia del proyecto, una vez culminado este, esta organización desaparecerá. Por ejemplo, usted puede ser analista de sistemas para su empresa, pero en la organización del proyecto, usted puede tener el rol de jefe del equipo de desarrollo, es por eso que el proyecto tiene una organización propia, donde intervienen gerentes de proyectos, ingenieros de software, analistas funcionales, arquitectos de software, desarrolladores, especialistas en redes y comunicaciones, soporte técnico, etc. 3. Dotación de personal Una vez que el proyecto fue aprobado y deberá ser ejecutado, usted tiene que solicitar y/o asignar al personal adecuado para el proyecto, así como es necesario para un director técnico de un equipo de fútbol, tener una táctica para asegurar el triunfo de su equipo, es necesario también formar el mejor equipo. Esto es parte de la estrategia y de las decisiones que usted deberá tomar antes de iniciar el proyecto. Usted tiene que tener claro, de acuerdo a la organización del proyecto diseñada, que especialistas necesita, con que conocimientos, años de experiencia, perfil profesional. En esta actividad usted deberá seleccionar, evaluar y asignar al personal idóneo para el proyecto. Y no solo deberá basarse en la parte profesional del personal, sino también deberá tomar en cuenta las fortalezas y debilidades personales de cada recurso, pues la parte personal es muy importante, es una variable a tomar en cuenta, es por eso que la productividad y el nivel de compromiso del proyecto varía de un individuo a otro. 4. Dirección Aquí llegamos a un punto crítico, usted tiene que tener claro que el título de Gerente de proyecto, es un título comercial y organizativo que le da su empresa, pero usted en realidad debe ser un líder para el personal involucrado en el proyecto. Un líder que dirija al personal por el camino del éxito del proyecto, un líder que trasmita al personal involucrado en el proyecto, el porque ellos deben poner el mejor empeño y dedicación en el proyecto. Usted como líder conoce cual es el camino, es decir los objetivos y metas del proyecto, lo que el cliente quiere del proyecto, eso U N I V E R S I D A D
D E 30
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
tiene que hacer que sean los objetivos y metas del personal. Recuerde algo muy importante, "cuando un proyecto es exitoso el mérito es del equipo del proyecto, y cuando el proyecto fracasa, la responsabilidad es del Gerente del Proyecto". Así que usted debe proporcionar liderazgo, esto implica motivar al personal, guiar al personal, supervisar el rendimiento del personal y delegar responsabilidades cuando sea necesario. 5. Control Esta actividad se lleva a cabo durante la ejecución del proyecto y marca un punto de quiebre, entre lo planificado y lo real, solo en un mundo ideal se dan las cosas exactamente como usted las planificó, es por eso que un gerente de proyecto debe medir el progreso del proyecto, esto implica conocer si las tareas del proyecto se están cumpliendo en las fechas programadas, si el presupuesto que planificó esta dentro de lo esperado, si los riesgos y en general situaciones futuras que usted planificó podrían impactar en el proyecto se están dando o no. La única manera de controlar es a través de la medición. ¿Cómo usted controla que un determinado recurso este invirtiendo el tiempo planificado en una determinada tarea? La respuesta es a través de un sistema de medición, por ejemplo puede hacer que el personal durante el curso del proyecto registre las horas invertidas en cada tarea, de manera que usted pueda identificar retrasos e implemente estrategias y/o mecanismos de acción para retomar el deathline del proyecto. Es mucho mas importante, medir el avance real del proyecto, esto no se mide en base a el dinero que a la fecha se ha invertido en el proyecto, o a las horas que ya han sido consumidas por los recursos, sino a través de entregables e hitos claros que marquen la finalización de cada actividad del proyecto y finalmente el conjunto de la éxitosa finalización de estas actividades lleven a la exitosa finalización del proyecto. En esta parte de vital importancia el feedback del proyecto hacia su gerencia y su cliente, es decir, elaborar informes de avance, gráficos y todos los medios que permitan comunicar del estado del proyecto tanto a su cliente como a su gerencia, y esto debe hacerse periódicamente, incluso deben hacerse reuniones de revisión del estado del proyecto. Así mismo, para un adecuado control, usted debe implementar mecanismos y/o sistemas de monitoreo efectivos que le permitan recopilar la información del estado del proyecto y poder plasmarlo finalmente en un informe de avance del proyecto. Con respecto al esfuerzo que un Gerente de Proyectos deberá desplegar a lo largo de un proyecto, podemos decir, que el esfuerzo desarrollado por un gerente de proyectos, es fuerte al comienzo, baja a la mitad del proyecto y vuelve a ser pesado hacia el final. Cuestionario: 1. 2. 3. 4. 5.
Cual es la razón de existir la gerencia de proyectos de s.w. Por que el cliente es un factor determinante del éxito de un proyecto de software. Cuales son las funciones de gerencia de proyectos de software. Cuales son las principales actividades de la gerencia de un proyecto de software. Ejemplificar cada una de estas actividades con un proyecto de software propuesto por Ud.
U N I V E R S I D A D
D E 31
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 5
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 5
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 518
TÍTULO DEL WORK PAPER: PLANIFICACIÓN Y PROYECTOS DE SOFTWARE
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Mayo 2011
FECHA DE ENTREGA: Mayo 2011
U N I V E R S I D A D
D E 32
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PLANIFICACIÓN Y PROYECTOS DE SOFTWARE Qué es un proyecto de Sistema o Software? Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software. Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación. Objetivos de la Planificación del Proyecto. El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables. Actividades asociadas al pro yecto de software. Ámbito del Software. Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software. En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. El Ámbito se define como un pre-requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es: La Obtención de la Información necesaria para el software. Para esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo. •
RECURSOS: La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y U N I V E R S I D A D
D E 33
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables. Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro características: • • • •
Descripción del Recurso. Informes de disponibilidad. Fecha cronológica en la que se requiere el recurso. Tiempo durante el que será aplicado el recurso.
Recursos Humanos. La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara cada profesional. Recursos o componentes de software reutilizables. Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la creación y la reutilización de bloques de construcción de Software. Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la también fácil integración. El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación: • • • •
Componentes ya desarrollados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes nuevos.
Recursos d e entorno. El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces el desarrollo de las pruebas de validación de un proyecto de software para la composición automatizada puede necesitar un compositor de fotografías en algún punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software. ESTIMACIÓN DEL PROYECTO DE SOFTWARE. En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento más caro de la mayoría de los sistemas informáticos. Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo. U N I V E R S I D A D
D E 34
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles: •
• •
•
Deje la estimación para más adelante (obviamente podemos realizar una estimación al cien por cien fiable después de haber terminado el proyecto. Base las estimaciones en proyectos similares ya terminados. Utilice técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo empírico para él cálculo de costos y esfuerzos del Software.
Desdichadamente la primera opción, aunque atractiva no es práctica. La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras. Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir y generar una estimación de su tamaño. Estimación basada en el Proceso. Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software. DIFERENTES MODELOS DE ESTIMACIÓN. Existen diferentes modelos de estimación como son: Los Modelos Empíricos: Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia. El Modelo COCOMO. Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm esta constituida por los siguientes: Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de Software en función del tamaño del programa, expresado en las líneas estimadas. Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del p royecto. U N I V E R S I D A D
D E 35
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Modelo III. El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.
Herramientas Automáticas De Estimación. Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos. A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado. Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación. Cuestionario: 1. 2. 3. 4. 5.
Cual es la diferencia entre un proyecto de Software y un proyecto convencional. Cual es la razón de planificar de un proyecto de s.w. Cual es la diferencia entre recursos entre un Proyecto de Desarrollo de s.w. y uno convencional. En términos económicos por que debe existir la estimación de un proyecto de s.w. Explicar los distintos modelos de estimación del s.w.
U N I V E R S I D A D
D E 36
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 6
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 6
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 518
TÍTULO DEL WORK PAPER: DISEÑO DE SISTEMAS DE COMPUTACIÓN.
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Junio 2011
FECHA DE ENTREGA: Junio 2011
U N I V E R S I D A D
D E 37
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
DISEÑO DE SISTEMAS DE COMPUTACIÓN. CONCEPTOS Y PRINCIPIOS: El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física. La etapa del Diseño del Sistema encierra cuatro etapas: EL DISEÑO DE LOS DATOS. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. EL DISEÑO ARQUITECTÓNICO. Define la relación entre cada uno de los elementos estructurales del programa. El Diseño de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean. El Diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad , dentro del diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los requerimientos del cliente. El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación. Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son: •
•
• • •
Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software. El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y subfunciones especificas. Un diseño debe contener abstracciones de datos y procedimientos. Debe producir módulos que presenten características de funcionamiento independiente. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior. U N I V E R S I D A D
D E 38
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software.
•
Estos criterios no se consiguen por casualidad. El proceso de Diseño del Software exige buena calidad a través de la aplicación de principios fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva.
Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el proceso de un diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o croquis. DISEÑO DE LA SALIDA. En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la mayoría de los usuarios la salida es la única razón para el desarrollo de un Sistema y la base de evaluación de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente:
Determine que información presentar. Decidir si la información será presentada en forma visual, verbal o impresora y seleccionar el medio de salida. Disponga la presentación de la información en un formato aceptable. Decida como distribuir la salida entre los posibles destinatarios.
DISEÑO DE ARCHIVOS. Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. Entre las decisiones que se toman durante el diseño de archivos, se encuentran las siguientes: Los datos que deben incluirse en el formato de registros contenidos en el archivo. La longitud de cada registro, con base en las características de los datos que contenga. La secuencia a disposición de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial, indexada o relativa). • • •
•
No todos los sistemas requieren del diseño de todos los archivos, ya que la mayoría de ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los registros. DISEÑO DE INTERACCIONES CON LA BASE DE DATOS. La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos grandes o pequeños, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razón estos sistemas utilizan u administrador de base de datos, en este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema. HERRAMIENTAS PARA EL DISEÑO DE SISTEMAS. Apoyan el proceso de formular las características que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del análisis: Herramientas de especificación. Apoyan el proceso de formular las características que debe tener una aplicación, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos.
U N I V E R S I D A D
D E 39
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Herramientas para presentación. Se utilizan para describir la posición de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida. HERRAMIENTAS PARA EL DESARROLLO DE SISTEMAS. Estas herramientas nos ayudan como analistas a trasladar diseños en aplicaciones funcionales. HERRAMIENTAS PARA INGENIERÍA DE SOFTWARE. Apoyan el Proceso de formular diseños de Software, incluyendo procedimientos y controles, así como la documentación correspondiente. GENERADORES DE CÓDIGOS. Producen el código fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas. HERRAMIENTAS PARA PRUEBAS. Apoyan la fase de la evaluación de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operación del Sistema así como el grado de perfección alcanzado en comparación con las expectativas. La revolución del procesamiento de datos de manera computarizada, junto con las practicas de Diseño sofisticadas están cambiando de forma dramática la manera en que se trasladan las especificaciones de Diseño d Sistemas de Informaciónfuncionales. En Conclusiones Generales. En una organización o Empresa, el análisis y Diseño de Sistemas, es el proceso de estudiar su Situación con la finalidad de observar como trabaja y decidir si es necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el analista de sistemas. Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los detalles de la situación actual de la empresa. La información reunida con este estudio sirve como base para crear varias estrategias de Diseño. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez mas con el uso de computadoras están teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son Sistemas que actúan de manera reciproca con su medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar formados por otros Sistemas de denominan Sub-sistemas y funcionan para alcanzar los fines de su Implantación.
IMPLANTACIÓN, EVALUACIÓN Y PRUEBAS. IMPLANTACIÓN. Concepto y Definición. Es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un análisis y diseño previo como resultado de la sustitución o mejoramiento de la forma de llevar a cavo un proceso automatizado. Al Implantar un Sistema de Información lo primero que debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios puedan operarlo. U N I V E R S I D A D
D E 40
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Existen varios enfoques de Implementación: • • •
• •
Es darle responsabilidad a los grupos. Uso de diferentes estrategias para el entrenamiento de los usuarios. El Analista de Sistemas necesita ponderar la situación y proponer un plan de conversión que sea adecuado para la organización. El Analista necesita formular medidas de desempeño con las cuales evaluar a los Usuarios. Debe Convertir físicamente el sistema de información antiguo, al nuevo modificado.
En la preparación de la Implantación, aunque el Sistema este bien diseñado y desarrollado correctamente su éxito dependerá de su implantación y ejecución por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento. CAPACITACIÓN DE USUARIOS DEL SISTEMA: Es enseñar a los usuarios que se relacionan u operan en un proceso de implantación. La Responsabilidad de esta capacitación de los Usuarios primarios y secundarios es del Analista, desde el personal de captura de datos hasta aquellos que toman las decisiones sin usar una Computadora. No se debe incluir a personas de diferentes niveles de habilidad e intereses de trabajo; debido a que si en una Empresa existen trabajadores inexpertos no se pueden incluir en la misma sección de los expertos ya que ambos grupos quedaran perdidos. "Es como querer conducir dos Barcos con diferentes destinos con un mismo Mapa de rutas o con el mismo timón". Aun y cuando la Empresa puede contratar los Servicios de Instructores externos, el analista es la persona que puede ofrecer la mejor capacitación debido a que conoce el personal y al Sistema mejor que cualquier otro. A la falta o imposibilidad del analista la organización puede contratar otros servicios de capacitación como son: Vendedores: Son aquellos que proporcionan capacitación gratuita fuera de la Empresa de uno o dos días. Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de las computadoras pero para algunos usuarios esta no es una capacitación necesaria. Instructores en casa: Están familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltaría experiencia en Sistemas de Información que es realmente la necesidad del usuario. • •
•
En nuestro país existe una ley institucional (Ley 116 del 16 de Enero de 1980) creado durante el gobierno del Presidente Antonio Guzmán Fernández llamada INFOTEP, representante de los trabajadores y empresarios en el ámbito de Capacitación y entrenamiento, la cual Asesora y brinda Sus servicios a las Empresas y Sus trabajadores. OBJETIVOS DE LA CAPACITACIÓN: Es lograr que los usuarios tengan el Dominio necesario de las cosas básicas acerca de las maquinarias y procesos que se emplean para su operación de manera eficiente y segura. LA EVALUACIÓN DEL SISTEMA: Se lleva a cabo para identificar puntos débiles y fuertes del Sistema implantado. La evaluación ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones:
U N I V E R S I D A D
D E 41
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
EVALUACIÓN OPERACIONAL: Es el Momento en que sé evalúa la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la Información, contabilidad global y su nivel de Utilidad. IMPACTO ORGANIZACIONAL: Identifica y mide los beneficios operacionales para la Empresa en áreas tales como, Finanzas (Costos, Ingresos y Ganancias), eficiencia en el desempeño laboral e impacto competitivo, Impacto, rapidez y organización en el flujo de Información interna y externa. DESEMPEÑO DEL DESARROLLO. Es la evaluación del Proceso de desarrollo adecuado tomando en cuentas ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con presupuesto y estándares y otros criterios de Administración de Proyectos. Además se incluyen la valoración de los métodos y herramientas utilizados durante el desarrollo del Sistema. PRUEBA DE SISTEMAS. Dependiendo del tamaño de la Empresa que usara el Sistema y el riesgo asociado a su uso, puede hacerse la elección de comenzar la operación del Sistema solo en un área de la Empresa (como una Prueba piloto), que puede llevarse a cabo en un Departamento o con una o dos personas. Cuando se implanta un nuevo sistema lo aconsejable es que el viejo y el nuevo funcionen de manera simultánea o paralela con la finalidad de comparar los resultados que ambos ofrecen en su operación, además dar tiempo al personal para su entrenamiento y adaptación al nuevo Sistema. Durante el Proceso de Implantación y Prueba se deben implementar todas las estrategias posibles para garantizar que en el uso inicial del Sistema este se encuentre libre de problemas lo cual se puede descubrir durante este proceso y levar a cabo las correcciones de lugar para su buen funcionamiento. Desdichadamente la evaluación de Sistemas no siempre recibe la atención que merece, sin embargo cuando se lleva a cabo de manera adecuada proporciona muchas informaciones que pueden ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones futuras. Cuestionario: 1. 2. 3. 4. 5.
Justificar los conceptos y principios del Diseño de los Sistemas de Computación. Explicar con un ejemplo el diseño Arquitectónico de los Sistemas de Computación. Investigar y explicar el diseño Arquitectónico en tres capas. Cual es la Herramienta más importante dentro del Diseño. Cual es la etapa mas importante dentro de la Implantación, Evaluación y las Pruebas.
U N I V E R S I D A D
D E 42
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
WORK PAPER # 7
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 7
ELABORÓ: Ing. Reynaldo Einar Zabaleta Rioja
CÓDIGO: CMP 316
TÍTULO DEL WORK PAPER: BASE DE DATOS CORPORATIVA
DPTO.: Facultad de Ingeniería UDABOL-ORURO DESTINADO A: DOCENTES
ALUMNOS
X
ADMINIST.
OTROS
OBSERVACIONES:
FECHA DE DIFUSIÓN: Julio 2011
FECHA DE ENTREGA: Julio 2011
U N I V E R S I D A D
D E 43
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
BASE DE DATOS CORPORATIVA Integra toda la información de la compañía, la cual pueden consultar los diferentes usuarios para construir y utilizar herramientas para la toma de decisiones. BASES DE DATOS LOCALES Y ARCHIVOS PROPIETARIOS. Las bases de datos locales y los archivos propietarios son generados y utilizados por los usuarios, para lo cual debe tomarse información de la de datos corporativa. Pueden ser manipulados por el usuario. Sistemas de Soporte para la Toma de Decisiones de Grupo (GSS: Group Decision Support Systems) Los sistemas de Soporte para la Toma de Decisiones de Grupo (GDSS) para considerarse como tal deben reunir un conjunto de características; las principales son las siguientes: • • •
•
•
GDSS. Sistemas diseñados especialmente para apoyar las decisiones en grupo. La meta de GDSS. Es apoyar a los tomadores de decisiones en su trabajo. GDSS. Es fácil de aprender y de usar. Accesible para usuarios con diferentes niveles de conocimiento computacional y de soporte a la decisión. Tales como ventas, producción, recursos humanos, administración y finanzas. Un GDSS. Contiene mecanismo para evitar el desarrollo de conductas negativas en el grupo, como son los problemas de comunicación. Un GDSS debe motivar a todos los miembros del grupo a participar de manera activa. Es importante que pueda existir anonimato de la participación.
•
Las principales ventajas de GDSS son: • • • • • • •
Motiva a los miembros del grupo a trabajar juntos Da la misma oportunidad de participación a todos los miembros del grupo. Se optimiza el uso de la información que aporta cada miembro del grupo. Proporciona un mecanismo para enfocar a grupo en problemas clave. Apoya el desarrollo de una memoria organizacional. Mejora la calidad de toma de decisiones. Incrementa la creatividad en la toma de decisiones.
•
Las principales desventajas de GDSS son: • • •
Falta de costumbre al utilizar un sistema para soportar el proceso de toma de decisiones. Resistencia al cambiar por parte de los administradores. La responsabilidad al tomar una decisión puede diluirse.
APLICACIONES DE LOS DGSS. • • •
•
Establecimiento de la misión de una empresa. Formulación de estrategias que ayudarán a que la misión se cumpla. Evaluación de administradores. Para incrementar el sueldo de un administrador o para verificar que esté cumpliendo con su deber. Planeación de sistemas de información. Cuando se requiere introducir nueva tecnología de sistemas de información es necesario modificar el plan de sistemas U N I V E R S I D A D
D E 44
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
• • • •
Soporte en negociaciones. Apoyar los trabajos que visuales, como la selección de un empaque para un nuevo producto. Apoyar los trabajos que involucran diseño y revisiones de control de calidad. Apoyar una decisión en particular.
Sistemas Expertos de Soporte para la Toma de Decisiones (EDSS: Expert Decisi on Support Systems).
Los sistemas expertos constituyen el área de la inteligencia artificial que quizá en este momento tiene más relación con el apoyo al proceso de la toma de decisiones en las organizaciones. Beneficios de la utilización de un sistema GDSS: o
o o
o
Reducción en la dependencia de personal clave se debe a tener los conocimientos del personal especializado son detenidos durante el proceso de aprendizaje y están listos para ser utilizados por diferentes personas. Facilitar el entrenamiento del personal. Capacitación y adiestramiento del personal sin experiencia. Mejora en la calidad y eficiencia en el proceso de la toma de decisiones. Las decisiones podrán tomarse de una forma más ágil con el apoyo de un sistema experto. Transferencia de la capacidad de decisiones. Un sistema experto puede facilitar la descentralización de datos en el proceso de la toma de decisiones en aquellos casos que se consideren convenientes.
COSTO QUE INVOLUCRA: • • • • • • •
El Shell o paquete generador del sistema experto. El equipo computacional o hardware que se requiera. Consultorio especializado. Contratación o pago a los ingenieros especialistas. El tiempo de los expertos. Costos de implantación. Costos involucrados con el mantenimiento y se guimiento del sistema.
Sistemas de Información para Ejecutivos (EIS: Executive Information Systems) CARACTERÍSTICAS DE UN EIS. •
• •
•
Están diseñados para cubrir las necesidades específicas y particulares de la alta administración de la empresa. Extraen, filtran, comprimen y dan seguimiento a formación crítica del negocio. Pueden acceder información que se encuentra en línea, extrayéndose en forma directa de las bases de datos de la organización El sistema está soportado por elementos especializados de hardware, tales como monitores o videos de alta resolución y sensibles al tacto.
Las siguientes características adicionales deben estar presentes para considerar a un ESS: • • •
Contempla las facilidades de comunicación electrónica. Capacidad de análisis de datos, tales como hoja electrónica de cálculo. Herramientas para la organización personal del ejecutivo, tales como calendario.
U N I V E R S I D A D
D E 45
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
FACTORES DEL ÉXITO DE UN EIS. Es necesario que cumpla con los siguientes factores: Que se vea bien. Debe de estar orientado al uso gráfico de las pantallas. Que sea relevante. Debe dar a los ejecutivos acceso a los datos que son importantes para la organización y que se han identificado como críticos para el éxito de la empresa. Que sea rápido. Se necesitan tiempos de respuesta cortos, de lo contrario los ejecutivos dirán que están perdiendo su tiempo. Que la información esté disponible y actualizada. Un ELS debe proporcionar a los ejecutivos la información en el momento oportuno, es decir, cuando ellos la requieren. Los cuatros factores anteriores aseguran que un EIS se utilice en una empresa y que tenga el éxito esperado. • •
•
•
EL PROCESO DE DESARROLLO DE UN EIS. El proceso de desarrollo de un EIS tiene características que lo hacen único. En la primera instancia, por que es el primer sistema que se desarrolla en la empresa dirigida al ejecutivo, en segundo lugar, las técnicas utilizadas para el análisis y desarrollo de los tradicionales sistemas transaccionales no necesariamente funcionan100% de manera similar durante el desarrollo de un EIS. A continuación se propone una metodología para su desarrollo e implantación. 1.-Identificación de las alternativas para el desarrollo del sistema. Existen diferentes alternativas para el desarrollo de un EIS. A continuación se mencionan algunas de las alternativas que existen para su desarrollo: Desarrollar sistema de manera interna y partiendo de cero. Hacer modificaciones a los sistemas actuales con el fin de cubrir los requisitos del ejecutivo. Desarrollar el sistema partiendo de cero con la ayuda de desarrolladores externos con experiencia previa en EIS. Cada una de estas alternativas tiene ventajas y desventajas en reglones tales como costo tiempo y control durante el desarrollo de la aplicación. • • •
•
2.-Creación de la propuesta. En este paso debe escribirse o elaborarse una presentación de la propuesta del EIS. La creación de la propuesta ayudará a tener un apoyo más sólido para el desarrollo del EIS. Las principales razones que existen para presentar de manera formal una propuesta de un EIS son: •
• •
•
Claro entendimiento con el ejecutivo. Esto se refiere a que el desarrollo del EIS se haga tomando como base lo que piensa el desarrollador y lo que espera el ejecutivo. Reducir la resistencia al cambio. Manejar las expectativas. En la creación y presentación de una propuesta deben ponerse en una balanza las expectativas. De la misma manera en que se hable de los beneficios que pueden lograrse con un EIS, deben informarse los riesgos que implica y de los recursos que requiere. Lograr el compromiso de los recursos.
Con todo esto, el ejecutivo tendrá una visión más clara de lo que es un EIS, de las expectativas con respecto a su uso y de los recursos que requiere su desarrollo. U N I V E R S I D A D
D E 46
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
3.-.Determinación de las necesidades del ejecutivo . Este paso consiste en determinar las necesidades del ejecutivo. Turban surgiere un conjunto de estrategias para lograr lo anterior: Cuestionar al ejecutivo acerca de cuáles son las preguntas que le gustaría formular al regresar de un periodo vacacional de tres semanas. Realizar entrevistas con los directores o gerentes de las diferentes áreas funcionales de la empresa. Listar los principales objetivos de la empresa a corto y mediano plazos y definir la información necesaria para darle seguimiento. Preguntar a los ejecutivos cuáles son los datos que no les gustaría que llegaran a manos de la competencia. A través de simple observación o entrevistas de terminar la información que utiliza en la actualidad el ejecutivo para monitorear la situación de la empresa. •
• •
•
•
4.- Creación del sistema y presentación de un prototipo. La clave para la creación de un EIS exitoso es el prototipo. En ocasiones en EIS se describe como un prototipo. SISTEMAS GERENCIALES. Una herramienta para soportar las funciones operativas. La perspectiva actual y futura tiende a cambiar este enfoque radicalmente, los sistemas de información son vistos además como áreas de oportunidad para lograr ventajas en el terreno de los negocios, y éstas representan un diferencial o valor agregado con respecto a los competidores. La perspectiva estratégica considera a los sistemas de información como una herramienta para mejorar la estructura competitiva del negocio, por lo que tienen su área de influencia en el medio ambiente de la organización, a través de nuevos servicios a clientes, nuevos negocios y oportunidades de inversión. Wiseman define la visión gerencial o estrategia como <>. Esta habilidad de ver y entender el nuevo rol de los sistemas de información constituye la esencia de la visión de los sistemas de información estratégica. Sus principales características son: • • •
•
•
Proporcionar información para apoyar la toma de decisiones. No pueden adaptarse fácilmente a paquetes disponibles en el mercado. Típicamente su forma de desarrollo es a base de incrementos y a través de su evolución dentro de la organización. Su función es lograr ventajas que los competidores no posean, tales como ventajas en costos y servicios diferenciados con clientes y proveedores. En este contexto, los sistemas estratégicos son creados de barreras de entrada al negocio. Apoyan los procesos de innovación de productos y proceso dentro de la empresa. Una forma de hacerlo es innovando o creando productos y procesos.
•
Wisenman utiliza el término impulsos estratégicos para connotar los movimientos que hace una empresa con el fin de ganar o mantener algún tipo de ventaja competitiva. Las cinco categorías que contempla Wiseman en cuanto a los impulsos estratégicos.
U N I V E R S I D A D
D E 47
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
o
DIFERENCIACIÓN.
Este impulso estratégico se refiere a la diferenciación de los productos o servicios a través de precios, plazas o promociones. Proceso de diferenciación puede trabajar en dos direcciones. La primera de ellas se refiere a lograr ventajas de diferenciación sobre los competidores utilizando la tecnología de la información; la segunda consiste en identificar oportunidades para reducir las ventajas de diferenciación de los competidores, clientes o proveedores. o
COSTO.
Se refiere a los movimientos que puede hacer la empresa para reducir sus costos o bien provocar la reducción de costos a proveedores o clientes, con el fin de obtener un trato preferencial. Las economías de escala se logran cuando se aumenta el volumen de la ventas de productos o servicios para reducir los costos unitarios, a través de mejores negociaciones con proveedores de servicio debidas a mayor volumen de compra. o
CRECIMIENTO.
El impulso estratégico del crecimiento permite la consecución de ventas competitivas, mediante el incremento del volumen de operaciones en el negocio. El crecimiento de producto o mercado se refiere a la expansión de mercados, satisfacción de nuevas necesidades o la incorporación de nuevas tecnologías asociadas al producto. El crecimiento puede darse funcionalmente, es decir, sustituyendo los servicios que proporcionan los proveedores, las funciones que llevan a cabo los clientes (hacia delante). Pueden lograrse ventajas competitivas, el impulso estratégico de la globalización es, según Wiseman, un impulso de crecimiento que involucra elementos foráneos al producto neto de la compañía. o
ALIANZAS.
Las alianzas son definidas por Wiseman como la combinación de dos más grupos o individuos que se unen para lograr un objetivo común. o
INNOVACIÓN.
Otro de los impulsos estratégicas que puede ser apoyando a través de la tecnología de información, ya sea en productos o en tecnología de información, ya sea en productos o en procesos nuevos. Para que un proceso de innovación tenga éxito requiere respuestas rápidas a las oportunidades que se representan, sin embargo, existen riesgos inherentes debido a la naturaleza del proceso, ya que es difícil innovar sin correr riesgos. El proceso de innovación consta de las siguientes fases: nacimiento de una idea, venta de la idea a una persona con poder de decisión, desarrollo de la idea y lanzamiento al mercado de la idea desarrollada. Alcanzar al mercado la idea puede tenerse éxito o fracaso en el proceso. Si se tiene éxito deben construirse barreras de entrada a esta innovación para protegerse de los competidores.
U N I V E R S I D A D
D E 48
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Cuestionario: 1. 2. 3. 4. 5. 6. 7. 8.
Que es una base de datos y una bases de datos corporativa Como interactúa las bases de datos con los DSS y GSS Cuales son las principales ventajas de los GDSS, ejemplificar Cuales son las aplicaciones de los DGSS Cuales son las Principales desventajas de los GDSS, ejemplificar Explicar los EDSS Explicar los EIS Explicar los Sistemas Gerenciales
U N I V E R S I D A D
D E 49
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 001 SISTEMAS DE SOPORTE PARA L A TOMA DE DECISIONES (DSS: DECISION SUPPORT SYSTEMS) Características • • • • • •
•
•
• •
Interactividad. Interactuar en forma amigable y con el cargado de tomar decisiones. Tipo de decisiones. Apoya el proceso de toma de decisiones estructuradas y no estructuradas. Frecuencia de uso. Tiene una utilización frecuente por parte de la administración. Variedad de usuario. Puede emplearse por usuarios de diferentes áreas funcionales. Flexibilidad. Permite acoplarse a una variedad determinada de estilos administrativos participativos. Desarrollo que el usuario desarrolle de manera directa modelos de decisión sin la participación operativa de profesionales en informática. Interacción ambiental. Permite la posibilidad de interactuar con información externa como parte de los modelos de decisión. Comunicación ínter organizacional. Facilita la comunicación de información relevante de los niveles altos a los niveles operativos y viceversa, a través de gráficas. Acceso a bases de datos. Tiene la capacidad de acceder información de las bases de datos corporativas. Simplicidad. Simple y fácil de aprender y utilizar por el usuario final.
Recuerde: DSS integran en su mayoría un conjunto de modelos que apoyan las diferentes decisiones a las que se enfrenta el tomador de decisiones. Recuerde: Ventajas del uso de los DSS. • •
•
Menores costos. Disponibilidad de una gran variedad de herramientas en el mercado que operan en el ambiente de microcomputadoras. Muy baja dependencia de personas que se encuentran fuera del control de tomador de decisiones.
Recuerde: Desventajas pueden ser: • • •
Falta de integridad y consolidación en la administración de la información. Problemas de seguridad de la información. Perdida del control administrativa por parte del área de informática.
Las diferentes opciones para la implantación de los DSS • • •
Implantación aislada en microcomputadoras. Implantación en microcomputadoras interconectadas y que constituyen una red local. Microcomputadoras conectadas a mini computadoras o servidores.
MÓDULOS FUNCIONALES QUE INTEGRAN UN DSS. Una de las características que poseen los DSS es la facilidad de que un usuario, sin tener conocimientos amplios sobre sistemas computacionales, pueda desarrollar sus propios modelos de decisión. Estos modelos son construidos con la ayuda de las herramientas, que en términos generales se clasifican en herramientas de hardware y de software.
U N I V E R S I D A D
D E 50
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
MANEJO DE MODELOS. Permite al usuario utilizar modelos clásicos, que se encuentran desarrollados y disponibles, formando la base de modelos. Pueden incluir: • • • • • • •
Inventarios Control de proyectos Programación lineal Simulación Colas Análisis estadísticos Planeación financiera y generación de esencias
MANEJO Y ADMINISTRACIÓN DE DATOS. Recuerde: Incluye funciones tales como: • • •
Acceso a las bases de datos corporativos Generación de información privada en bases de datos locales. Manipulación de la información a través de técnicas de manejo de información.
DESARROLLO DE APLICACIONES. La mayoría de los DSS permite a los usuarios desarrollar sus propios modelos de decisión. En este sentido, el usuario diseña sus propios formatos de entrada y salida, así como la estructura de almacenamiento y las funciones de procesamiento, tal forma que el sistema puede evolucionar de manera permanente, a través de los cambios. Prototipo, es diferente al proceso tradicional de desarrollo de un sistema tradicional de desarrollo de un sistema transaccional típico. Recuerde: Las Aplicaciones desechables, es decir, modelos de decisión que fueron desarrollados en tiempo muy corto, para apoyar una decisión en particular. INTERFACES GRÁFICAS, REPORTES Y CONSULTAS. Facilidad para explorar la información a través de graficas de alta calidad y reportes que se diseñan y obtienen en intervalos cortos de tiempo, la disponibilidad de lenguajes de muy alto nivel para facilitar la consulta de información que contienen las bases de datos.
U N I V E R S I D A D
D E 51
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 002 PROCESO UNIFICADO Y MSF; COMPLEMENTOS TECNOLÓGICOS Según M&R 1998, "más que una metodología, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guían a una organización sobre como ensamblar los recursos, el personal y las técnicas necesaria para asegurar que su infraestructura tecnológica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relación clara entre los objetivos de negocio y las implementaciones tecnológicas". Recuerde: "MSF se puede utilizar por sí mismo o con otras herramientas y técnicas como el Proceso Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de negocio a la medida" [M&R 1998]. Recuerde: "El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varían en tamaño y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología de objetos en el desarrollo de software de misión crítica en una variedad de industrias. Uno de los componentes clave es el UML" [M&R 1998]. MSF proporciona las técnicas ligadas a la tecnología y el Proceso Unificado la guía detallada para el desarrollo de software minimizando los riesgos. El Proceso Unificado ha adoptado un enfoque que se caracteriza por: • • • • • •
Interacción con el usuario continua desde un inicio Mitigación de riesgos antes de que ocurran Liberaciones frecuentes Aseguramiento de la calidad Involucramiento del equipo en todas las decisiones del proyecto Anticiparse al cambio de requerimientos
El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reuso. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa [M&R 1998]: •
•
•
•
Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios. Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios y como poner esa información eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.
U N I V E R S I D A D
D E 52
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeño para crear soluciones más rápido, mejor y más baratas. El Modelo de Equipo de MSF se basa en las formas de organizar equipos para crear los propios productos de Microsoft. Hace énfasis en las comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso Unificado proporciona más detalle y guía para algunos de los roles en el proyecto. Recuerde: Una vista arquitectónica es "una descripción simplificada (una abstracción) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva" [Booch 1998]. Según el mismo autor, las características primordiales del Proceso Unificado son: • • • •
Iterativo e incremental Centrado en la arquitectura Guiado por casos de uso Confrontación de riesgos
Recuerde: El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson 1998]. Según [Booch 1998], los conceptos clave del Proceso Unificado son:
Fase e iteraciones
¿Cuándo se hace?
Flujos de trabajo de procesos (actividades y pasos)
¿Qué se está haciendo?
Artefactos (modelos, reportes, documentos)
¿Qué se produjo?
Trabajador: un arquitecto
¿Quién lo hace?)
U N I V E R S I D A D
D E 53
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 003 EL CICLO DE VIDA DEL SOFTWARE EN EL PROCESO UNIFICADO Las fases del ciclo de vida del software son: concepción, elaboración, construcción y transición. La concepción es definir el alcance del proyecto y definir el caso de uso. La elaboración es proyectar un plan, definir las características y cimentar la arquitectura. La construcción es crear el producto y la transición es transferir el producto a sus usuarios [Booch 1998].
Estructura del Proceso Unificado Según [Microsoft 1997], el diseño de software se realiza a tres niveles: conceptual, lógico y físico.
Arquitectura lógica de tres capas de una aplicación cliente/servidor Recuerde: Un ingeniero de software necesita de herramientas, entre ellas las herramientas de Rational son las más avanzadas, pero son muy costosas. También puede utilizar las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de código abierto y aún están de desarrollo. Utiliza las que más te sean de utilidad.
U N I V E R S I D A D
D E 54
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 004 PODREDUMBRE DEL SOFTWARE ¿Qué le pasa al software? El diseño de muchas aplicaciones comienza con una imagen clara en la mente del diseñador. En este estado el diseño es claro, conciso y elegante. Diseñadores y programadores desean verlo funcionar. Algunos de estos proyectos mantienen esta pureza de diseño hasta la primera versión. Pero algo comienza a pasar. Al principio apenas es perceptible. Un parche por aquí, una ñapa por allá, aunque el diseño todavía mantiene la filosofía inicial. El software comienza a pudrirse. Las ñapas continúan y poco a poco el software se corrompe mas y mas hasta llegar un punto en el que afecta a toda la aplicación. El programa se convierte en una ingente masa de código que cada vez es más difícil de mantener. Entonces el esfuerzo requerido para hacer el más simple de los cambios es tal que los responsables de producto se plantean hacer un rediseño de la aplicación. Los rediseños normalmente no fructifican. Aunque las intenciones de los diseñadores son buenas se dan cuenta de que es una tarea imposible. El sistema continua evolucionando, cambiando y el nuevo rediseño nunca termina. Un día la cantidad de problemas vuelve a ser tal que se los diseñadores lloran por otro rediseño. Síntomas de un mal diseño Recuerde: Hay cuatro indicios principales que nos indican que el software se esta pudriendo. No son dependientes y están relacionados unos con otros, son: rigidez, fragilidad, inmovilidad y viscosidad. Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en las cosas más sencillas. Cada cambio produce una cascada de cambios en módulos dependientes. Lo que parecía un cambio de dos días en un módulo resulta ser varias semanas de cambios de módulos tirando del hilo a través de la aplicación. Cuando el software toma este camino, los gestores temen decir a los programadores que arreglen pequeños problemas que no son críticos. Esto ocurre porque ellos no saben con seguridad cuando acabaran los programadores. Todo el mundo hace "check-in" y nadie hace "check-out". El miedo del gestor puede llegar a ser tan agudo que se niegue a realizar modificaciones en la aplicación. De manera que, lo que empezó siendo un diseño ineficiente acaba siendo una mala política de gestión. Fragilidad. Muy relacionada con la rigidez está la fragilidad. La fragilidad es la tendencia que tiene el software a romperse por muchos sitios cada vez que se cambia algo. Muchas de las roturas ocurren en sitios que no están relacionados conceptualmente con el área que se está cambiando. Cada vez que los gestores autorizan un cambio tienen miedo de que el programa se rompa por algún lugar inesperado. Conforme la fragilidad empeora, la probabilidad de que el software se rompa incrementa con el tiempo, acercándose cada vez más a 1. Este software es imposible de mantener. Cada arreglo lo hace peor, introduciendo más problemas de los que son solucionados. Recuerde: Este software causa que los gestores y los clientes tengan la impresión de que los desarrolladores han perdido el control del software, perdiéndose así la credibilidad de los desarrolladores. Y frases como " Rompes más de lo que arreglas", comienzan a ser habituales. Inmovilidad. La inmovilidad es la resistencia del software a ser reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces que un programador descubre que necesita un módulo que es muy parecido a otro U N I V E R S I D A D
D E 55
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
que ha desarrollado otro programador. Sin embargo, también pasa muchas veces que el módulo en cuestión depende demasiado de la aplicación en la que está integrado. Después de mucho trabajo los desarrolladores descubren que el trabajo necesario para separar las partes reutilizables de las partes no reutilizables es demasiado alto. Y entonces el software simplemente se rescribe en vez de ser reutilizado. Viscosidad. La viscosidad de diseño es la dificultad de mantener la filosofía del diseño original. Cuando se afronta un cambio los programadores encuentran normalmente más de una manera de realizarlo. Algunas de estas formas preservan la filosofía del diseño y otras no. Cuando las formas de implementar el cambio preservando el diseño son más difíciles de realizar que las que no lo preservan, entonces la viscosidad del diseño es alta. Es fácil hacerlo mal y difícil hacerlo bien. Estos cuatro síntomas son reveladores de un di seño de arquitectura pobre. Cualquier aplicación que muestra estos síntomas adolece de un diseño pobre. ¿Qué causa que el diseño se deteriore? Requisitos cambiantes La causa de la degradación del diseño es muy conocida. Los requisitos han ido cambiando de manera que no estaba previsto en el diseño inicial. A menudo los cambios necesitan hacerse rápidamente y hechos por programadores que no están familiarizados con el diseño original. Entonces, aunque los cambios funcionan, violan el diseño original. Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe. Aún así no podemos echar la culpa a que los requisitos cambian y cruzarnos de brazos. Como desarrolladores, todos sabemos que los requisitos van a cambiar. Así que debemos realizar un diseño que soporte modificaciones sin que este pierda su consistencia. Control de dependencias ¿Qué tipos de cambios hacen que un diseño se pudra? Los cambios que introducen nuevas e imprevistas dependencias. Cada una de las cuatro causas mencionadas anteriormente está relacionada directa o indirectamente con dependencias entre módulos del software. Son las dependencias de la arquitectura lo que se degrada y con ellas el mantenimiento del software. Para anticiparse a la degradación de las dependencias del diseño de la arquitectura, deben ser controladas las dependencias entre módulos de una aplicación. Este control consiste en la creación de "cortafuegos" de dependencias. A través de estos cortafuegos las dependencias no se propagan. Recuerde: El diseño orientado a objetos esta repleto de principios y técnicas que nos permiten construir estos cortafuegos y controlar estas dependencias.
U N I V E R S I D A D
D E 56
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 005 PATRONES DE DISEÑO Diseño de Software Orientado a Objetos Patrones de diseño o más comúnmente conocidos como "Design Patterns". ¿Qué son los patrones de diseño? Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan. Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso. En este artículo presentamos una lista con los más comunes y conocidos. Recuerde: Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos. A continuación una lista con los patrones de diseño a objetos más habituales publicados en el libro "Design Patterns ", escrito por los que comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro"). Patrones de creación •
•
•
•
•
Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas. Builder . Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones. Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos. Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo. Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.
Patrones estructurales •
•
•
•
•
• •
Adapter . Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles. Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente. Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos. Decorator . Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad. Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar. Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente. Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.
U N I V E R S I D A D
D E 57
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
Patrones de comportamiento •
•
•
•
•
•
•
•
•
•
•
Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto. Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones. Interpreter . Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje. Iterator . Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna. Mediator . Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente. Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde. Observer . Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos. State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto. Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan. Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura. Visitor . Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
Recuerde: Es necesario que el grupo de resolución del presente Dif discuta estos patrones aplicando a situaciones de desarrollo de Software reales.
U N I V E R S I D A D
D E 58
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 006 SEGUIMIENTO Y GESTIÓN DE ERRORES, BUG TRACKING Recuerde: Es inevitable, los programas tienen errores. No importa cuanto lo pruebes y el cuidado que tengas en desarrollar la aplicación, siempre salen errores inesperados. Como personas relacionadas con el software tenemos que saber convivir con ellos y no taparnos los ojos intentando ignorarlos. Puesto que los errores forman parte del software y son bastante peligrosos, en cuanto a coste e imagen, es mejor tenerlos controlados. Normalmente cuando alguien encuentra un error se comunica con el programador y este lo intenta arreglar. Este método de manejar los errores tiene un problema, que no está gestionado. Te voy a contar algunas situaciones que seguro que has vivido y te resultan familiares. Alguien encuentra un bug y… •
•
•
•
•
•
•
•
•
El programador está en otro proyecto o haciendo otra cosa, lo anota en un trozo de papel… se le olvida y se pierde (intencionadamente o no). Causa: No hay registro de bugs. El programador no sabe cómo provocar el bug, no puede reproducirlo y por tanto no puede arreglarlo. Causa: Mala descripción del bug. El programador cree que ha arreglado el bug, cambia una cosa que funcionaba y deja el bug. Causa: No sabe cómo debía funcionar . El programador reproduce el bug y lo arregla, nadie se entera, al cliente nunca le llega el programa arreglado. Causa: Deficiente c omunicación. Alguien encuentra un bug y habla con distintos programadores para que se arregle, varios programadores se ponen a arreglarlo entorpeciéndose y perdiendo tiempo. Causa: No hay una canalización adecuada de los bugs. Hay muchos bugs que se comunican al programador en persona de manera que el programador no puede arreglar ninguno porque no tiene tiempo.Causa: Mala gestión de los bugs. Se interrumpe constantemente al programador para preguntar el estado de los bugs. Causa: No hay un listado de bugs con sus estados de resolución. El bug llega al equipo de desarrollo. El programador A piensa que lo tiene que arreglar el programador B y el B piensa que es tarea de A. Nadie lo arregla. Causa: El bug no está asignado a nadie en concreto. Existen muchos bugs, unos más importantes que otros, pero el tiempo está limitado, los programadores pierden el tiempo arreglado bugs triviales mientras que los bugs críticos siguen sin arreglar. Causa: Los bugs no están priorizados.
•
Recuerde: ¿A quién no le ha pasado alguna de estas cosas? Estos son algunos de los problemas típicos que nos podemos encontrar si no tenemos una gestión y seguimiento de errores. Es evidente que estas situaciones repercuten en la calidad del producto y en la imagen que damos a nuestros clientes. De acuerdo, pero… ¿En qué me beneficia? Como programador tener el sistema te beneficia ya que te llegarán partes de errores decentes, con toda la información necesaria para poder arreglarlo. No pierdes errores y te evitas broncas de porqué no arreglaste aquel
U N I V E R S I D A D
D E 59
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
error que se dijo. Evitando que te pregunten cada 5 minutos si arreglaste tal error. Como gestor tener el sistema te beneficia, puedes ver todos los errores que se están arreglando y cuales se han arreglado, ponerles prioridad, sabes que no se perderán, decidir cuales quieres que se arreglen para esta versión y cuales para la siguiente. Como personal de soporte te beneficia, tienes un sistema para reportar los errores que el cliente detecta, también puedes introducir las mejoras que el cliente te sugiere, puedes buscar en la base de datos si el error es conocido y enviarle la versión en la que está arreglado. Como puedes ver, gestionar beneficia a todo el mundo y sobre todo el gran beneficiado es el software resultante. Recuerde: Necesita un programa de seguimiento y control de errores (Bug Tracking Software).
U N I V E R S I D A D
D E 60
A Q U I N O
B O L I V I A
FACULTAD DE CIENCIAS Y TECNOLOGIA
PROGRAMA DE CALIDAD UDABOL DIF – 007 CONTROL DE CÓDIGO FUENTE Recuerde: Es necesario que se lea detenidamente este Dif para poder analizarlo adecuadamente. ¿Tienes más de 2 personas trabajando en un mismo proyecto? ¿Los programadores machacan su código fuente? ¿Quieres llevar un control de versiones de tu software? Necesitas tener bajo control tu código fuente. Recuerde: Al principio no hay problemas, tú desarrollas solo, tienes todos los ficheros fuente. Añades, editas, borras ficheros fuente conforme te parece y vas necesitando. Esto funciona bien si el proyecto es pequeño y no tienes necesidad de más programadores. Pero un día llega el momento en que el proyecto es un poco más grande y están trabajando simultáneamente con los ficheros fuentes 2 o 3 personas, y lo que antes era tan sencillo como editar un fichero fuente se convierte en una pesadilla. Lo primero que se te ocurre es compartir un directorio en el que todo el mundo puede crear, editar y borrar ficheros a su parecer. A los 10 minutos te das cuenta que eso no funciona, lo más normal es que dos programadores estén editando el mismo fichero fuente y uno de los dos machaque el trabajo del otro, con el consiguiente enfado del perjudicado. Y más vale que esto no ocurra más de una vez porque si no el posible pequeño enfado se puede convertir en represalia y ya te puedes imaginar las consecuencias que esto tiene. Así que en un alarde de imaginación organizativa decides que cada uno trabaje en su parte, que las partes sean distintas, de forma que nadie necesite editar ficheros que otro esté editando (sniff...) y que si alguien va a editar algún fichero "general" que avise a los demás para que no lo editen al mismo tiempo. No hace falta pensar mucho para darse cuenta que al rato esto nos lleva a la situación del principio, machacándose unos ficheros a los otros. Primero porque la separación en partes disjuntas no está clara y sobre todo porque cuando tienes que avisar a los demás de que vas a editar un fichero común, a veces se te olvida y no lo haces, o piensas que sólo lo abres para verlo y no vas a tocar nada, pero que luego resulta que si modificas. Así que si tienes más de un programador necesitas que alguien controle el acceso a las fuentes para evitar estos problemas. Afortunadamente existen herramientas que permiten realizar este control sobre los ficheros fuente. Estas herramientas evitan que nadie machaque código de otro inconscientemente, también permiten saber qué modificó cada programador, guardar versiones anteriores que se pueden recuperar posteriormente, etiquetar conjuntos de ficheros fuente bajo un mismo nombre. Recuerde: Se presenta algunas opciones para que puedas elegir la que más se ajuste a vuestras necesidades. •
•
RCS. Revisión Control Sistema. Uno de los más antiguos (1980) y también de los más sencillos de usar. Desarrollado para entornos UNIX aunque también está portado a Windows. Recomendado para proyectos no muy complejos en entorno UNIX bajo la misma máquina. MS Visual SourceSafe. La alternativa Microsoft. Se integra muy bien, como sería de esperar, con las herramientas de desarrollo de Microsoft. Si tu entorno de desarrollo es Microsoft, esta es tu primera opción.
U N I V E R S I D A D
D E 61
A Q U I N O
B O L I V I A