s8 - Ingenieria - de - Software PDF

FACULTAD DE CIENCIAS Y TECNOLOGIA
RED NACIONAL UNIVERSITARIA
SYLLABUS
Facultad de Ciencias y Tecnologa
Ingeniera de Sistemas OCTAVO SEMESTRE
Ingeniera de Software
Gestin Acadmica I / 2011
Syllabus elaborado por: Ing. Reynaldo Einar Zabaleta Rioja
U N
I V E R S
I D A D 1
A Q U
I N
B O L
I V
I A
UDABOL
UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLENA mediante R. M. 288/01
VISIN DE LA UNIVERSIDAD Ser la Universidad lder en calidad educativa.
MISIN DE LA UNIVERSIDAD Desarrollar la Educacin Superior Universitaria con calidad 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 empeos en la planificacin de los procesos de enseanza para brindarte una educacin de la ms alta calidad. Este documento te servir de gua para que organices mejor tus procesos de aprendizaje y los hagas mucho ms productivos. Esperamos que sepas apreciarlo y cuidarlo.
U N
I V E R S
I D A D 2
A Q U
I N
B O L
I V
I A
SYLLABUS
I. Asignatura: Cdigo: Requisito: Carga horaria: Horas tericas: Horas prcticas: Crditos: II. OBJETIVOS GENERALES DE LA ASIGNATURA. Valorar la aplicacin de un modelo orientado a objetos en la estructura de objetos, no en la estructura de procedimientos. Definir los elementos de un sistema especfico mediante el modelado, diseo e implementacin del mtodo orientado a objetos. Justificar la utilidad del desarrollo orientado a objetos a travs de ejemplos. Evaluar proyectos relacionados modelado y diseo orientado a objetos Fundamentar conceptos tericos, mtodos y tcnicas del enfoque orientado a objetos Modelar un sistema desde tres puntos de vista distintos: Modelo de objetos, modelo dinmico, modelo funcional. Construir un modelo de un dominio de aplicacin con detalles de implementacin en el diseo del sistema. Traducir las clases de objetos y las relaciones desarrolladas en un lenguaje de programacin. Ingeniera de Software CMP 518 CMP 425 80 horas 80 4
III. PROGRAMA ANALTICO DE LA ASIGNATURA. UNIDAD 1: SOFTWARE E INGENIERA DE SOFTWARE TEMA 1. INTRODUCCIN 1.1. Objetivos de la ingeniera de software. 1.2. Clasificacin y tipos 1.3. El ciclo de vida de un sistema de software. 1.4. Especificacin, codificacin y prueba de algoritmos. 1.5. Correccin. 1.6. Verificabilidad. 1.7. Confiabilidad. 1.8. Eficiencia. 1.9. Facilidad de mantenimiento. 1.10. Reusabilidad y portabilidad. TEMA 2. GESTIN DE PROYECTOS 2.1. Introduccin 2.2. Modelo de procesos IEEE 1074/991 2.3. Planificacin 2.4. Gestin de configuracin 2.5. Gestin de calidad.
U N I V E R S I D A D 3 D E A Q U I N O B O L I V I A
UNIDAD 2: ANLISIS DE REQUISITOS DEL SOFTWARE Y DIMENSIONAMIENTO TEMA 3. INGENIERA DE REQUISITOS 1.1. Introduccin a la ingeniera de requisitos 1.2. Tipos de requerimientos. 1.3. Clasificacin de los requerimientos. 1.4. El proceso de la ingeniera de requerimientos. 1.5. La factibilidad del proyecto. 1.6. La definicin de requerimientos. 1.7. La especificacin de requerimientos. 1.8. Tcnicas para especificar los requerimientos TEMA 4. HERRAMIENTAS PARA CONSTRUIR PROGRAMAS 2.1. Introduccin 2.2. Tipos de herramientas. 2.3. Caractersticas deseadas. 2.4. Funciones de las herramientas case 2.5. Estudio de Rational Rose., Case 2 studio, Architect. etc. UNIDAD 3: DISEO, CODIFICACIN, PRUEBA Y MANTENIMIENTO TEMA 5. PROCESO DE DISEO. E IMPLEMENTACIN 1.1. Consideraciones al proceso de diseo 1.2. El ambiente de implementacin. 1.3. El modelo de diseo. 1.4. El diagrama de clases mediante patrones 1.5. El diagrama de secuencia. 1.6. El diagrama de interaccin 1.7. El diagrama de componentes. 1.8. El diagrama de nodos TEMA 6. EL PROCESO DE CODIFICACIN 2.1. Consideraciones al proceso de codificacin 2.2. Tareas asociadas. 2.3. Paradigmas de programacin 2.4. Lenguajes de programacin 2.5. Mapeo al cdigo de los elementos del diseo.
U N
I V E R S
I D A D 4
A Q U
I N
B O L
I V
I A
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 integracin 3.5. Plan de actividades. 3.6. Validacin 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 5
A Q U
I N
B O L
I V
I A
IV. SISTEMA DE EVALUACIN DE APRENDIZAJES. El sistema de evaluacin hace hincapi en varios tipos de calificacin: Diagnstica: es la evaluacin 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 organizacin y estructuracin de las secuencias de aprendizaje, de modo que estas tengan en cuenta no slo el punto de partida del grupo con el que trabajar durante el semestre sino adems las diferencias y especificidades de cada estudiante para que los aprendizajes resulten ms efectivos y permitan el ptimo desarrollo integral de cada uno(a). Procesual o de desempeo o formativa: en esta forma de evaluacin se valora el avance del o de la estudiante de su nivel de desarrollo real (detectado mediante la evaluacin diagnstica) a su nivel de desarrollo potencial (detectado mediante diversas actividades o tareas). Esta forma de evaluacin, 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 prximo (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 ponderacin de la asignatura de Ingenieria de Software dentro la Evaluacin Procesual, contempla la realizacin de actividades formativas a desarrollar (Work Papers, Difs, Participacin, Evaluacin Diaria, Investigacin, Congresos, Jornadas Cientficas y Seminarios) y su calificacin es sobre el 50 % de la calificacin del primer y segundo parcial, estimando un promedio de todas las actividades. De resultados del proceso de aprendizaje: es la valoracin de los resultados de los procesos de aprendizaje del o de la, estudiante durante el semestre. Esta forma de evaluacin es tanto cualitativa como cuantitativa, por su naturaleza y por la funcin que cumple dentro de la evaluacin. La evaluacin de resultados en la asignatura especfica se llevar a cabo de forma terica y prctica aplicada a sistemas reales. La ponderacin de esta evaluacin es sobre 50 % de la calificacin 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 PARCIAL 1 PARCIAL 2 FINAL PROCESUAL 50% 50% 50% DE RESULTADO 50% 50% 50% TOTAL 100% 100% 100% 100%
EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL
U N
I V E R S
I D A D 6
A Q U
I N
B O L
I V
I A
V. BIBLIOGRAFA. Bibliografa bsica Booch G., "Anlisis y Diseo Orientado a Objetos con Aplicaciones" - Segunda Edicin - Editorial AddisonWesley/Diaz de Santos - 1996. Pressman R., "Ingeniera del Software, un Enfoque Prctico" - Tercera Edicin - Editorial Mc Graw-Hill 1993. Rumbaugh J., "Modelado y Diseo Orientado a Objetos" Editorial Prentice Hall 1997.
Bibliografa complementaria Rumbaugh J., Jacobson I., Booch G., "El Lenguaje Unificado de Modelado. Manual de Referencia" Editorial Addison-Wesley - 2000. Larman C., "UML y Patrones" - Segunda Edicin - Editorial Prentice-Hall 2003.
U N
I V E R S
I D A D 7
A Q U
I N
B O L
I V
I A
VI. PLAN CALENDARIO

UNIVERSIDAD DE AQUINO-BOLIVIA UNIDAD ACADMICA DE ORURO
CALENDARIO ACADMICO
GESTIN I/2011 TURNOS REGULAR-TRABAJO ESTUDIANTES NUEVOS-ANTIGUOS
SEMANA 1ra. 2da. 3ra. 4ta. 5ta. 6ta. 7ma. 8va. 9na. 10ma. 11ra. 12da. 13ra. 14ta. 15ta. 16ta. 17ma. 18va. 19na. 20va. 21ra. DEL 09-Mar 14-Mar 21-Mar 28-Mar 04-Abr 11-Abr 18-Abr 25-Abr 02-May 09-May 16-May 23-May 30-May 06-Jun 13-Jun 20-Jun 27-Jun 04-Jul 11-Jul 18-Jul 25-Jul AL 12-Mar 19-Mar 26-Mar 02-Abr 09-Abr 16-Abr 23-Abr 30-Abr 07-May 14-May 21-May 28-May 04-Jun 11-Jun 18-Jun 25-Jun 02-Jul 09-Jul 16-Jul 23-Jul 26-Jul Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia ACTIVIDADES TEMA 1. INTRODUCCIN TEMA 1. INTRODUCCIN TEMA 2. GESTIN DE PROYECTOS TEMA 3. INGENIERA DE REQUISITOS TEMA 3. INGENIERA DE REQUISITOS Inicio Primera Evaluacin Parcial Conclusin Primera Evaluacin Parcial TEMA 3. INGENIERA DE REQUISITOS TEMA 4. HERRAMIENTAS PARA CONSTRUIR PROGRAMAS TEMA 4. HERRAMIENTAS PARA CONSTRUIR PROGRAMAS TEMA 5. PROCESO DE DISEO. E IMPLEMENTACIN Inicio Segunda Evaluacin Parcial Conclusin Segunda Evaluacin Parcial TEMA 6. EL PROCESO DE CODIFICACIN TEMA 6. EL PROCESO DE CODIFICACIN TEMA 7. EL PROCESO DE PRUEBA Y MANTENIMIENTO TEMA 7. EL PROCESO DE PRUEBA Y MANTENIMIENTO Inicio Evaluacin Final Conclusin Evaluacin Final Evaluacin del segundo turno Cierre de Gestin FERIADOS 22 de abril 1 de mayo 23 de junio Viernes Santo Da del Trabajo Corpus Christi Presentacin de Notas Transcripcin de Notas Transcripcin de Notas Presentacin de Notas Presentacin de Notas Presentacin de Notas Presentacin de Notas OBSERVACIONES
U N
I V E R S
I D A D 8
A Q U
I N
B O L
I V
I A
VII. CONTROL DE EVALUACIONES 1 evaluacin parcial Fecha: Nota: 2 evaluacin parcial Fecha: Nota: Examen final Fecha: Nota: APUNTES
U N
I V E R S
I D A D 9
A Q U
I N
B O L
I V
I A
WORK PAPER # 1
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 4
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja
CDIGO: CMP 518
TTULO DEL WORK PAPER: LA INGENIERA DE SOFTWARE Y EL PARADIGMA DE LO ORIENTADO A OBJETOS
DPTO.: Facultad de Ingeniera UDABOL-ORURO DESTINADO A: DOCENTES OBSERVACIONES: ALUMNOS X ADMINIST. OTROS
FECHA DE DIFUSIN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
U N
I V E R S
I D A D
D 10
A Q U
I N
B O L
I V
I A
LA INGENIERA DE SOFTWARE Y EL PARADIGMA ORIENTADO A OBJETOS Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un producto diseado para un usuario". En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin 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 diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson 1998]. El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin. La concepcin define le alcance del proyecto y desarrolla un caso de negocio. La elaboracin define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. La construccin crea el producto y la transicin 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 informacin. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnologa de informacin OO. El OMG tiene como objetivo central la promocin, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnologa OO. Una de las especificaciones ms importantes es la adopcin en 1998 del Lenguaje de Modelado Unificado o UML (del ingls Unified Modeling Language) como un estndar, que junto con el Proceso Unificado estn consolidando la tecnologa OO. EL PARADIGMA DE LO ORIENTADO A OBJETOS Antes de analizar los pasos del proceso de desarrollo de software se expondrn los conceptos fundamentales del paradigma que gua la tecnologa OO. Existen conceptos ligados en torno a la tecnologa orientada a objetos: el paradigma, los principios, el anlisis y el diseo, mismos que a continuacin se comentan.
U N
I V E R S
I D A D
D 11
A Q U
I N
B O L
I V
I A
LA PROGRAMACIN ORIENTADA A OBJETOS La Programacin Orientada a Objetos (OOP por sus siglas en ingls de Object Oriented Programming) como paradigma, "es una forma de pensar, una filosofa, de la cual surge una cultura nueva que incorpora tcnicas y metodologas diferentes. Pero estas tcnicas y metodologas, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontolgica: el universo computacional est poblado por objetos, cada uno responsabilizndose por s mismo, y comunicndose con los dems por medio de mensajes" [Greiff 1994]. Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodologa (coleccin de caractersticas para la ingeniera de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP ms a una metodologa, que al paradigma. De aqu que "el inters en la OOP radica ms en los mecanismos que aporta para la construccin de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994]. La Programacin Orientada a Objetos desde el punto de vista computacional "es un mtodo de implementacin en el cul 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 jerarqua de clases unidas va 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 ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. 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 abstraccin, 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: abstraccin, encapsulacin, modularidad y jerarqua, fundamentalmente, y en menor grado tipificacin (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. Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Es el orden de las abstracciones organizado por niveles. Tipificacin. Es la definicin 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 travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado). Segn [Booch 1986], los beneficios del enfoque OO son:
U N I V E R S I D A D D 12 E A Q U I N O B O L I V I A
Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programacin 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 diseos completos. Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa. 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 funcin 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 actan 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 Anlisis Orientado a Objetos (OOA por sus siglas en ingls de Object Oriented Analysis) "es un mtodo de anlisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema". Segn [Booch 1986], el Diseo Orientado a Objetos "es un mtodo de diseo abarcando el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos lgico y fsico tal como los modelos estticos y dinmicos del sistema bajo diseo". En cuanto a las metodologas OO, diremos que hay un gran nmero de mtodos orientado a objetos actualmente. Muchos de los mtodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientacin a objetos. Algunos de las metodologas ms conocidas y estudiadas hasta antes del UML segn [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 metodologas ms importantes de anlisis y diseo 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 Ingeniera de software Como define la IEEE a la Ingeniera de Software Que es un proceso dentro de la Ingeniera 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 programacin orientada a objetos. Explicar los Fundamentos de lo Orientado a Objetos Que es Abstraccin, Encapsulacin y Modularidad. Que es Jerarqua o herencia, Concurrencia, Persistencia.
U N
I V E R S
I D A D
D 13
A Q U
I N
B O L
I V
I A
WORK PAPER # 2
No. DE HOJAS: 6
CDIGO: CMP 518
TTULO DEL WORK PAPER: CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE I
FECHA DE DIFUSIN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
U N
I V E R S
I D A D
D 14
A Q U
I N
B O L
I V
I A
CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE I DEFINICIN 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 ejecucin 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 informacin que permite al sistema operativo su planificacin. Esta definicin vara ligeramente en el caso de sistemas operativos multihilo donde un proceso consta de uno o ms hilos, la memoria de trabajo (compartida por todos los hilos) y la informacin de planificacin. Cada hilo consta de instrucciones y estado de ejecucin. Los procesos son creados y destruidos por el sistema operativo, as como tambin este se debe hacer cargo de la comunicacin entre procesos, pero lo hace a peticin de otros procesos. El mecanismo por el cual un proceso crea otro proceso se denomina bifurcacin (fork). Los nuevos procesos son independientes y no comparten memoria (es decir, informacin) 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 concepcin de la idea que hace surgir la necesidad de disear un sistema software, pasando por el anlisis, desarrollo, implantacin 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 mximo rendimiento de UML se debera considerar un proceso que fuese: Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto bsico para establecer el comportamiento del deseado del sistema, para validar la arquitectura, para las pruebas y para la comunicacin entre las personas involucradas en el proyecto. Centrado en la arquitectura de modo que sea el artefacto bsico para conceptuar, construir, gestionar y hacer evolucionar el sistema. Un proceso iterativo, que es aquel que involucra la gestin del flujo de ejecutables del sistema, e incremental, que es aquel donde cada nueva versin 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 versin se ataca y reducen los riesgos ms 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 15
A Q U
I N
B O L
I V
I A
En el ciclo de vida de un proyecto software existen cuatro fases. La iniciacin, que es cuando la idea inicial est lo suficientemente fundada para poder garantizar la entrada en la fase de elaboracin, esta fase es cuando se produce la definicin de la arquitectura y la visin 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 construccin, que es cuando se pasa de la base arquitectnica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan los requisitos y las pruebas que ha de soportar. La transicin, 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 transicin, incluso durante esta fase el proyecto es continuamente reexaminado y mejorado erradicando errores y aadiendo nuevas funcionalidades no contempladas. Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteracin, que es un conjunto bien definido de actividades, con un plan y unos criterios de evaluacin, que acaban en una versin del producto, bien interna o externa. Ciclo de Vida: Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs 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 gestin 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 tecnologas empleadas. La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamao, con lo que rpidamente se hara inabordable si no fuera por la vieja tctica de divide y vencers. De esta forma la divisin de los proyectos en fases sucesivas es un primer paso para la reduccin de su complejidad, tratndose de escoger las partes de manera que sus relaciones entre s sean lo ms simples posibles. La definicin 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 subcontratacin 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 tambin se ve facilitado si la separacin 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 prctica acumulada en el diseo 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. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones de los resultados intermedios que se van produciendo (realimentacin).
U N
I V E R S
I D A D
D 16
A Q U
I N
B O L
I V
I A
Para un adecuado control de la progresin de las fases de un proyecto se hace necesario especificar con suficiente precisin 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 continuacin 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 agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos (humanos, financieros o materiales). Cuanto ms grande y complejo sea un proyecto, mayor detalle se necesitar en la definicin 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 inters de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestin.
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 17
A Q U
I N
B O L
I V
I A
Esquema general de operacin 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 adecuacin o no a los requisitos funcionales y de condiciones de realizacin previamente establecidos. Cada una de estas evaluaciones puede servir, adems, 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 estn en: o El alcance del ciclo dependiendo de hasta dnde 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, fabricacin, y modificaciones posteriores hasta su retirada del mercado. o Las caractersticas (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 avin que un puente), o de la organizacin (inters de reflejar en la divisin en fases aspectos de la divisin interna o externa del trabajo). o La estructura de la sucesin de las fases que puede ser lineal, con prototipado, o en espiral. Vemoslo con ms detalle: CICLO DE VIDA LINEAL: Es el ms utilizado, siempre que es posible, precisamente por ser el ms 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 fcil 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 (realimentacin), aunque pueden admitirse ciertos supuestos de realimentacin correctiva. Desde el punto de vista de la gestin (para decisiones de planificacin), requiere tambin 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 18
A Q U
I N
B O L
I V
I A
Ejemplo de ciclo lineal para un proyecto de construccin CICLO DE VIDA CON PROTOTIPADO: A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prev la utilizacin de tecnologas nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologas, impiden iniciar un proyecto lineal con especificaciones cerradas. Si no se conoce exactamente cmo desarrollar un determinado producto o cules 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 evaluacin deben permitir la definicin de las especificaciones ms 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 definicin, diseo y construccin dos veces: para el prototipo y para el producto real.
Cuestionario: 1. 2. 3. 4. 5. 6. 7. Dentro de la Ingeniera moderno cual es el concepto de Proceso informtico. 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 ms se utiliza.
U N
I V E R S
I D A D
D 19
A Q U
I N
B O L
I V
I A
WORK PAPER # 3
No. DE HOJAS: 6
CDIGO: CMP 518
TTULO DEL WORK PAPER: CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE 2
FECHA DE DIFUSIN: Abril 2011
FECHA DE ENTREGA: Abril 2011
U N
I V E R S
I D A D
D 20
A Q U
I N
B O L
I V
I A
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 generalizacin del anterior para los casos en que no basta con una sola evaluacin de un prototipo para asegurar la desaparicin de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede as considerarse como una sucesin 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 la fuente de incertidumbres es el propio cliente, que aunque sepa en trminos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluacin 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 especificacin, diseo, realizacin y evaluacin (o conceptos y trminos anlogos). En cada vuelta el producto gana en madurez (aproximacin al final deseado) hasta que en una vuelta la evaluacin lo apruebe y el bucle pueda abandonarse. MODELOS DE PROCESOS DE SOFTWARE: Al da de hoy, ha aumentado la complejidad con la que se desarrollan sistemas de informacin para la industria, por lo que resulta difcil generar productos que cumplan cabalmente con las expectativas del cliente. Para responder a esta situacin, han surgido una serie de herramientas, tcnicas y modelos que facilitan a las organizaciones, encargadas de las tecnologas de la informacin, generar productos que cumplan las expectativas del cliente e incluso las rebasen, herramientas que prometen ser la solucin 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 reconoca la necesidad de crear software de calidad, no se haba 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 pases como la India o Irlanda. Afortunadamente, dicha situacin ha cambiado; nuestro gobierno en conjunto con la industria, ha iniciado un esfuerzo serio para impulsar la industria del software a travs 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 tecnologas de informacin con objeto de contribuir de manera sostenible al crecimiento de la economa y la generacin de empleos bien remunerados.
U N
I V E R S
I D A D
D 21
A Q U
I N
B O L
I V
I A
Con el programa, se pretende establecer una industria de software competitiva internacionalmente y asegurar su crecimiento a largo plazo, lo que situara a Mxico como lder de esta industria en Latinoamrica en 2012, adems de convertirlo en lder desarrollador de soluciones de tecnologas de informacin de alta calidad y uso de software en Latinoamrica. 1. 2. 3. 4. 5. 6. 7. 8. Este programa tiene siete estrategias de donde emergen varios proyectos que ayudarn a que se alcancen las metas previstas en ste: Promover las exportaciones y la atraccin 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. Alcanzar niveles internacionales en capacidad de procesos. Promover acciones conjuntas con los gobiernos estatales y construir infraestructura.
Para el caso de la estrategia 6, la Asociacin Mexicana para la Calidad en Ingeniera de Software (AMCIS), con el auspicio de la Secretara de Economa propone un modelo concebido, diseado y desarrollado por mentes mexicanas, adecuado para las necesidades especficas de Mxico y con ventajas respecto de otros. El nuevo modelo, denominado MoProSoft, ofrece caractersticas que los otros no tienen de manera independiente; para su concepcin, se tomaron las mejores prcticas de los otros modelos y se integraron y mejoraron otras; a continuacin, 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 organizacin para cumplir los requisitos del cliente, los reglamentarios y los propios de la organizacin. Ventajas Tiene un mecanismo de certificacin bien establecido. Est disponible y es conocida. Desventajas No es especfica para la industria de software. No es fcil de entender. No est definida como un conjunto de procesos. No es fcil de aplicar. Capability Maturity Model (CMM) Es un marco evolutivo organizado en cinco niveles para lograr la mejora continua de procesos. Ventajas Especfico para el desarrollo y mantenimiento de software. Definido como un conjunto de reas clave de procesos. Tiene un modelo de evaluacin. Desde 1998 empez a popularizarse en Mxico. Existen organizaciones evaluadas. Desventajas Es un modelo extranjero, no internacional. No es fcil de entender (ingls, 18 KPAs, 220 pginas). No es fcil de aplicar (pensado para organizaciones grandes). La mejora no est enfocada directamente a los objetivos de negocio. La evaluacin 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 22
A Q U
I N
B O L
I V
I A
ISO/IEC TR 15504 Define el modelo de referencia de procesos de software y de capacidades de procesos que constituyen la base para la evaluacin de procesos de software. Se compone de 9 partes de las cuales la 2, 3 y 9 son normativas y las dems informativas. Especfico para el desarrollo y mantenimiento de software. Fcil de entender (24 procesos, 16 pginas). Definido como un conjunto de procesos. Orientado a mejorar los procesos para contribuir a los objetivos del negocio. Desventajas No es prctico ni fcil de aplicar. Tiene solamente lineamientos para un mecanismo de evaluacin. Todava no es norma internacional.

Ventajas
MoProSoft Es un Modelo de Procesos para la Industria de Software que fomenta la estandarizacin de su operacin, a travs de la incorporacin de las mejores prcticas en gestin e ingeniera de software. La adopcin del modelo permite elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Ventajas Fcil de entender. Fcil de aplicar. No es costoso en su adopcin. Sirve de base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 o CMM.1 V1.1. A decir de sus creadores, el modelo est orientado a pequeas y medianas empresas, hecho favorable si se considera que aproximadamente el 80% de las empresas desarrolladoras de software del pas caen en esta categora. Su principal fortaleza es que integra varias de las prcticas 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 evaluacin; adems, 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 fcil resulta su implantacin determinando los recursos necesarios. Lo interesante para nosotros como academia, es que tenemos la oportunidad de proponer productos concebidos y desarrollados en Mxico, adecuados a nuestros requerimientos y realidad, lo que repercute de manera directa en la gama de soluciones que tiene una organizacin para resolver sus necesidades. MODELO DE CASCADA: En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. Anlisis de requisitos 2. Diseo 3. Codificacin 4. Pruebas
5. 6.
Implantacin Mantenimiento
De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy. FASES DEL MODELO Anlisis 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 Especificacin de Requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. Diseo 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 Diseo del Software), que contiene la descripcin de la estructura global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Codificacin Es la fase de programacin propiamente dicha. Aqu se desarrolla el cdigo fuente, haciendo uso de prototipos as como pruebas y ensayos para corregir errores. Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotacin. Implantacin El software obtenido se pone en produccin. Mantenimiento Durante la explotacin 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 24
A Q U
I N
B O L
I V
I A
MODELO DE RIESGO Y ESPIRAL: Qu es el Modelo Espiral? Desarrollado por B. Boehm, bsicamente, 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 deberan 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, deberan entonces retroceder o volver al punto de partida para definir e implementar ms y mejores partes. El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseo. Eso introduce un ciclo de prototipo iterativo. En cada iteracin, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo. Este mtodo esta basado en dos importantes principios: 1. La practica de dise profesional es caracterizar en trminos de conocer, actuar en situaciones, conversacin con la situacin y reflexin en accin. Hay un distinto medio de proceso - orientacin en esta aproximacin al diseo. Es raro que el diseador tenga el diseo en su cabeza por adelantado y que despus meramente lo transcriba. Gran parte del tiempo del diseador esta inmiscuido en una progresiva relacin con su entorno. Una buena metfora para describirlo es "la conversacin con el material", como un escultor, quien esta ocupado en una conversacin 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 diseadores de tomar la practica de trabajo seriamente, de supervisar las formas en las que el trabajo se esta haciendo, en el sentido de una solucin abierta y desplegada para aumentar la complejidad de una situacin que el diseador 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 cooperacin y comunicacin. Una visin 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 25
A Q U
I N
B O L
I V
I A
WORK PAPER # 4
No. DE HOJAS: 6
CDIGO: CMP 518
TTULO DEL WORK PAPER: LA GERENCIA DE PROYECTOS DE SOFTWARE
FECHA DE DIFUSIN: Mayo 2011
FECHA DE ENTREGA: Mayo 2011
U N
I V E R S
I D A D
D 26
A Q U
I N
B O L
I V
I A
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 lder cuyo objetivo consiste en mediar entre intereses y motivaciones diversas con el fin de llegar a una solucin 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 dcadas. Iniciativas como la del Project Management Institute, PMI. Pretenden asentar las bases que conduzcan a la estandarizacin y clasificacin 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 terico y conceptual avanza vertiginosamente mientras los resultados de su aplicacin en la ejecucin de proyectos de software an 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 mtricas que brinden una idea del tamao del proyecto, no hay una metodologa, buena o mala, a seguir durante la ejecucin del proyecto. Resulta normal tambin 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 tecnologa con la cul 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 solucin es el directo responsable de los resultados del proyecto, una adecuada planeacin, gestin y evaluacin del avance constituyen herramientas fundamentales para la toma de decisiones del cliente. Un alto porcentaje de los riesgos inducidos en los proyectos de tecnologas de informacin se deben a deficiencias en la planeacin inicial. Definicin pobre del alcance del proyecto y asignacin 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 definicin de cronogramas y costos de los proyectos en instancias incipientes, en las cuales no se ha efectuado una definicin detallada de requerimientos hecho que obliga a tener amplios mrgenes de error en la estimacin 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 prctica disminuye significativamente la competitividad del proveedor y eleva innecesariamente los costos de desarrollo para los clientes, hecho que aumenta su inversin general en soluciones de software pero empobrece el alcance de los proyectos. Resulta conveniente efectuar labores de planeacin detallada al interior de las organizaciones cliente, previas al inicio de los proyectos y a la apertura de concursos y licitaciones. Dichas tareas permitirn establecer con un buen nivel de detalle el objetivo que se pretende alcanzar con el desarrollo e implantacin de la solucin, las prestaciones o funcionalidad necesarias en la solucin, una adecuada priorizacin de los requerimientos y una asignacin de recursos, no solo econmicos sino humanos, responsables de manejar el flujo de informacin y requerimientos cliente-proveedor y proveedor-cliente.
La planeacin detallada conducir a obtener los mximos beneficios al invertir en soluciones de TI, adicionalmente le dar elementos para la toma de mejores decisiones en la ejecucin del proyecto y ser una herramienta para la evaluacin de sus proveedores de tecnologa. La prxima vez que su proveedor de soluciones de software le pida profundizar en el anlisis, previo a establecer compromisos de presupuesto y cronograma, seguramente se debe a que est interesado en ofrecerle una solucin que se ajuste a su necesidad y de ofrecerle una perspectiva realista de planeacin. Funciones de gerencia de proyectos de software: Partamos de la siguiente definicin de administracin de un proyecto: "La administracin de un proyecto, se define como un sistema de procedimientos, prcticas, tecnologas y conocimientos del tema que permiten la planificacin, organizacin, designacin de personal, direccin y control necesarios, para poder manejar con xito un proyecto de ingeniera de software" 1 Por tanto Tahyer, es concreto en afirmar que el "concepto de la universalidad de la administracin nos permite usar las funciones de administracin y actividades bsicas de las principales corrientes de administracin, como las funciones y actividades de alto nivel de la administracin de proyectos de ingeniera de software". En consecuencia, es necesario conocer cuales son las actividades y funciones de la administracin:
Figura 1: Modelo de funciones de gerencia ACTIVIDAD Planificacin Organizacin Dotacin de personal Direccin Control DEFINICIN Pre-determinar un curso de accin para lograr los objetivos de la organizacin Arreglar y relacionar el trabajo para lograr los objetivos y para delegar responsabilidad y autoridad para lograr esos objetivos Seleccionar y capacitar al personal para los puestos en la organizacin Crear una atmsfera que ayudar y motivar a la gente para lograr los resultados finales deseados 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 administracin
U N
I V E R S
I D A D
D 28
A Q U
I N
B O L
I V
I A
Funciones de gerencia
Actividades fundamentales de la gerencia

Planificacin
Determinar los objetivos o metas Desarrollar estrategias Determinar cursos de accin 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
Organizacin
Dotacin de personal
Dotacin de personal
Llenar los puestos de la organizacin 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 asignacin de personal Proporcionar liderazgo Supervisar al personal Delegar autoridad Motivar al personal Coordinar actividades Facilitar las comunicaciones Resolver conflictos Manejar los cambios Documentar las decisiones de direccin Desarrollar estndares de rendimiento Establecer sistemas de monitoreo e informes Medir los resultados Iniciar acciones correctivas Premios y disciplina Documentar mtodos de control
Direccin
Control
Tabla 2: Principales actividades de gerencia
U N
I V E R S
I D A D
D 29
A Q U
I N
B O L
I V
I A
Por tanto un gerente de proyectos, planifica, dirige, dota de personal, y controla un proyecto de ingeniera de software. Actividades de la administracin de proyectos de ingeniera de software Ahora nos enfocaremos a la segunda pregunta que nos hicimos: Cmo administrar proyectos de ingeniera de software? 1. Planificacin Imagine por un momento que usted es director tcnico de un equipo de ftbol, y tiene un juego muy importante dentro de un par de semanas, usted elaborara su estrategia de juego y tctica antes o durante el juego? de esta respuesta depender el xito o fracaso del encuentro. De manera anloga, 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 crticos 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 despus, hacer una evaluacin post-proyecto y determinar si el proyecto fue exitoso o no. En esta parte debe plantearse por ejemplo, cuales sern los entregables del proyecto, entregar documentacin, subsistemas, etc. Adems as como un director tcnico, plantea una estrategia de juego para el encuentro, de manera anloga deber elegir que metodologa de desarrollo utilizar, el ciclo de vida tradicional? El modelo en espiral? RUP? Programacin extrema?, etc., cual de todas las metodologas de desarrollo de software o de ingeniera de software existentes o que combinacin de ellas, es la mas adecuada para lograr el xito del proyecto. Es por eso mi estimado lector, que usted deber de tener un slido conocimiento de ingeniera de software como lo haba mencionado antes, no solo basta ser un buen administrador, tambin debe conocer bien el terreno de accin. 2. Organizacin Un proyecto as como una empresa, tiene una estructura organizacional, esta estructura tender a ser compleja cuando el proyecto tenga ms entes involucrados y el proyecto en s sea ms 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, lnea 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 disear una estructura organizativa del proyecto. Esta estructura organizativa, solo tendr validez durante la existencia del proyecto, una vez culminado este, esta organizacin desaparecer. Por ejemplo, usted puede ser analista de sistemas para su empresa, pero en la organizacin del proyecto, usted puede tener el rol de jefe del equipo de desarrollo, es por eso que el proyecto tiene una organizacin propia, donde intervienen gerentes de proyectos, ingenieros de software, analistas funcionales, arquitectos de software, desarrolladores, especialistas en redes y comunicaciones, soporte tcnico, etc. 3. Dotacin 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 tcnico de un equipo de ftbol, tener una tctica para asegurar el triunfo de su equipo, es necesario tambin 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 organizacin del proyecto diseada, que especialistas necesita, con que conocimientos, aos de experiencia, perfil profesional. En esta actividad usted deber seleccionar, evaluar y asignar al personal idneo para el proyecto. Y no solo deber basarse en la parte profesional del personal, sino tambin 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 vara de un individuo a otro. 4. Direccin Aqu llegamos a un punto crtico, usted tiene que tener claro que el ttulo de Gerente de proyecto, es un ttulo comercial y organizativo que le da su empresa, pero usted en realidad debe ser un lder para el personal involucrado en el proyecto. Un lder que dirija al personal por el camino del xito del proyecto, un lder que trasmita al personal involucrado en el proyecto, el porque ellos deben poner el mejor empeo y dedicacin en el proyecto. Usted como lder conoce cual es el camino, es decir los objetivos y metas del proyecto, lo que el cliente quiere del proyecto, eso
tiene que hacer que sean los objetivos y metas del personal. Recuerde algo muy importante, "cuando un proyecto es exitoso el mrito 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 ejecucin 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 estn 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 podran impactar en el proyecto se estn dando o no. La nica manera de controlar es a travs de la medicin. Cmo usted controla que un determinado recurso este invirtiendo el tiempo planificado en una determinada tarea? La respuesta es a travs de un sistema de medicin, 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 accin 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 travs de entregables e hitos claros que marquen la finalizacin de cada actividad del proyecto y finalmente el conjunto de la xitosa finalizacin de estas actividades lleven a la exitosa finalizacin del proyecto. En esta parte de vital importancia el feedback del proyecto hacia su gerencia y su cliente, es decir, elaborar informes de avance, grficos y todos los medios que permitan comunicar del estado del proyecto tanto a su cliente como a su gerencia, y esto debe hacerse peridicamente, incluso deben hacerse reuniones de revisin 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 informacin 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 razn 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 31
A Q U
I N
B O L
I V
I A
WORK PAPER # 5
No. DE HOJAS: 5
CDIGO: CMP 518
TTULO DEL WORK PAPER: PLANIFICACIN Y PROYECTOS DE SOFTWARE
FECHA DE DIFUSIN: Mayo 2011
FECHA DE ENTREGA: Mayo 2011
U N
I V E R S
I D A D
D 32
A Q U
I N
B O L
I V
I A
PLANIFICACIN Y PROYECTOS DE SOFTWARE Qu es un proyecto de Sistema o Software? Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimacin, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software. Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El Tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software. La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la estimacin. Objetivos de la Planificacin del Proyecto. El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables. Actividades asociadas al proyecto de software. mbito del Software. Es la primera actividad de llevada a cabo durante la planificacin del proyecto de Software. En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los lmites 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 estimacin y existen algunos elementos que se debe tomar en cuenta como es: La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo. RECURSOS: La Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y
Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los Componentes reutilizables. Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro caractersticas: Descripcin del Recurso. Informes de disponibilidad. Fecha cronolgica 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 despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin y la especialidad que desempeara cada profesional. Recursos o componentes de software reutilizables. Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la reutilizacin de bloques de construccin de Software. Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para la tambin fcil integracin. El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en cuenta a medida que se avanza con la planificacin: Componentes ya desarrollados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes nuevos. Recursos de entorno. El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera 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 Ingeniera del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estn disponibles. Muchas veces el desarrollo de las pruebas de validacin de un proyecto de software para la composicin automatizada puede necesitar un compositor de fotografas en algn punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software. ESTIMACIN DEL PROYECTO DE SOFTWARE. En el principio el costo del Software constitua un pequeo porcentaje del costo total de los sistemas basados en Computadoras. Hoy en da el Software es el elemento ms caro de la mayora de los sistemas informticos. Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:

Deje la estimacin para ms adelante (obviamente podemos realizar una estimacin al cien por cien fiable despus de haber terminado el proyecto. Base las estimaciones en proyectos similares ya terminados. Utilice tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software.
Desdichadamente la primera opcin, aunque atractiva no es prctica. La Segunda opcin 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 mtodos viables para la estimacin del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada una de ellas como comprobacin de las otras. Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del software a construir y generar una estimacin de su tamao. Estimacin basada en el Proceso. Es la tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea. Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso comienza en una delineacin 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 funcin y la actividad del proceso de software. DIFERENTES MODELOS DE ESTIMACIN. Existen diferentes modelos de estimacin como son: Los Modelos Empricos: Donde los datos que soportan la mayora de los modelos de estimacin obtienen una muestra limitada de proyectos. Por esta razn, el modelo de estimacin 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 clsico sobre economa de la Ingeniera del Software, introduce una jerarqua de modelos de estimacin de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarqua de modelos de Boehm esta constituida por los siguientes: Modelo I. El Modelo COCOMO bsico calcula el esfuerzo y el costo del desarrollo de Software en funcin del tamao del programa, expresado en las lneas estimadas. Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del programa y de un conjunto de conductores de costos que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
Modelo III. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin del impacto de los conductores de costos en cada caso (anlisis, diseo, etc.) del proceso de ingeniera de Software. Herramientas Automticas De Estimacin. Las herramientas automticas de estimacin permiten al planificador estimar costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la seleccin del personal. Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas generales y todas requieren de una o ms clases de datos. A partir de estos datos, el modelo implementado por la herramienta automtica de estimacin proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos casos la planificacin 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. Adems 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 tcnicas referidas anteriormente. Mediante la comparacin y la conciliacin de las estimaciones obtenidas con las diferentes tcnicas, el planificador puede obtener una estimacin ms exacta. La estimacin del proyecto de software nunca ser una ciencia exacta, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin. Cuestionario: 1. 2. 3. 4. 5. Cual es la diferencia entre un proyecto de Software y un proyecto convencional. Cual es la razn 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 trminos econmicos por que debe existir la estimacin de un proyecto de s.w. Explicar los distintos modelos de estimacin del s.w.
U N
I V E R S
I D A D
D 36
A Q U
I N
B O L
I V
I A
WORK PAPER # 6
No. DE HOJAS: 6
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja TTULO DEL WORK PAPER: DISEO DE SISTEMAS DE COMPUTACIN.
CDIGO: CMP 518
FECHA DE DIFUSIN: Junio 2011
FECHA DE ENTREGA: Junio 2011
U N
I V E R S
I D A D
D 37
A Q U
I N
B O L
I V
I A
DISEO DE SISTEMAS DE COMPUTACIN. CONCEPTOS Y PRINCIPIOS: El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. La etapa del Diseo del Sistema encierra cuatro etapas: EL DISEO DE LOS DATOS. Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software. EL DISEO ARQUITECTNICO. Define la relacin entre cada uno de los elementos estructurales del programa. El Diseo 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 Diseo de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente. El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas: El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente. Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software. El Diseo 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 Implementacin. Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como son: Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software. El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y subfunciones especificas. Un diseo debe contener abstracciones de datos y procedimientos. Debe producir mdulos que presenten caractersticas de funcionamiento independiente. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior.
Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obtenida durante el anlisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva. Cuando se va a disear un Sistema de Computadoras se debe tener presente que el proceso de un diseo incluye, concebir y planear algo en la mente, as como hacer un dibujo o modelo o croquis. DISEO DE LA SALIDA. En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la mayora de los usuarios la salida es la nica razn para el desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente: Determine que informacin presentar. Decidir si la informacin ser presentada en forma visual, verbal o impresora y seleccionar el medio de salida. Disponga la presentacin de la informacin en un formato aceptable. Decida como distribuir la salida entre los posibles destinatarios. DISEO 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 histricos, o informacin de referencia. Entre las decisiones que se toman durante el diseo 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 caractersticas de los datos que contenga. La secuencia a disposicin de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial, indexada o relativa).
No todos los sistemas requieren del diseo de todos los archivos, ya que la mayora de ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los registros. DISEO DE INTERACCIONES CON LA BASE DE DATOS. La mayora de los sistemas de informacin ya sean implantado en sistemas de cmputos grandes o pequeos, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razn estos sistemas utilizan u administrador de base de datos, en este caso el diseador 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 DISEO DE SISTEMAS. Apoyan el proceso de formular las caractersticas que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del anlisis: Herramientas de especificacin. Apoyan el proceso de formular las caractersticas que debe tener una aplicacin, 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 39
A Q U
I N
B O L
I V
I A
Herramientas para presentacin. Se utilizan para describir la posicin 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 diseos en aplicaciones funcionales. HERRAMIENTAS PARA INGENIERA DE SOFTWARE. Apoyan el Proceso de formular diseos de Software, incluyendo procedimientos y controles, as como la documentacin correspondiente. GENERADORES DE CDIGOS. Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas. HERRAMIENTAS PARA PRUEBAS. Apoyan la fase de la evaluacin de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operacin del Sistema as como el grado de perfeccin alcanzado en comparacin con las expectativas. La revolucin del procesamiento de datos de manera computarizada, junto con las practicas de Diseo sofisticadas estn cambiando de forma dramtica la manera en que se trasladan las especificaciones de Diseo d Sistemas de Informacin funcionales. En Conclusiones Generales. En una organizacin o Empresa, el anlisis y Diseo de Sistemas, es el proceso de estudiar su Situacin 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 situacin actual de la empresa. La informacin reunida con este estudio sirve como base para crear varias estrategias de Diseo. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez mas con el uso de computadoras estn teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son Sistemas que actan 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 Implantacin. IMPLANTACIN, EVALUACIN Y PRUEBAS. IMPLANTACIN. Concepto y Definicin. Es la ltima fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un anlisis y diseo previo como resultado de la sustitucin o mejoramiento de la forma de llevar a cavo un proceso automatizado. Al Implantar un Sistema de Informacin lo primero que debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del anlisis y permitir que los usuarios puedan operarlo.
Existen varios enfoques de Implementacin: Es darle responsabilidad a los grupos. Uso de diferentes estrategias para el entrenamiento de los usuarios. El Analista de Sistemas necesita ponderar la situacin y proponer un plan de conversin que sea adecuado para la organizacin. El Analista necesita formular medidas de desempeo con las cuales evaluar a los Usuarios. Debe Convertir fsicamente el sistema de informacin antiguo, al nuevo modificado. En la preparacin de la Implantacin, aunque el Sistema este bien diseado y desarrollado correctamente su xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento. CAPACITACIN DE USUARIOS DEL SISTEMA: Es ensear a los usuarios que se relacionan u operan en un proceso de implantacin. La Responsabilidad de esta capacitacin 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 seccin 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 timn". Aun y cuando la Empresa puede contratar los Servicios de Instructores externos, el analista es la persona que puede ofrecer la mejor capacitacin debido a que conoce el personal y al Sistema mejor que cualquier otro. A la falta o imposibilidad del analista la organizacin puede contratar otros servicios de capacitacin como son: Vendedores: Son aquellos que proporcionan capacitacin gratuita fuera de la Empresa de uno o dos das. Instructor pagado externamente: Son aquellos que pueden ensear todo acerca de las computadoras pero para algunos usuarios esta no es una capacitacin necesaria. Instructores en casa: Estn familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltara experiencia en Sistemas de Informacin que es realmente la necesidad del usuario.

En nuestro pas existe una ley institucional (Ley 116 del 16 de Enero de 1980) creado durante el gobierno del Presidente Antonio Guzmn Fernndez llamada INFOTEP, representante de los trabajadores y empresarios en el mbito de Capacitacin y entrenamiento, la cual Asesora y brinda Sus servicios a las Empresas y Sus trabajadores. OBJETIVOS DE LA CAPACITACIN: Es lograr que los usuarios tengan el Dominio necesario de las cosas bsicas acerca de las maquinarias y procesos que se emplean para su operacin de manera eficiente y segura. LA EVALUACIN DEL SISTEMA: Se lleva a cabo para identificar puntos dbiles y fuertes del Sistema implantado. La evaluacin ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones:
U N
I V E R S
I D A D
D 41
A Q U
I N
B O L
I V
I A
EVALUACIN OPERACIONAL: Es el Momento en que s evala 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 Informacin, 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 desempeo laboral e impacto competitivo, Impacto, rapidez y organizacin en el flujo de Informacin interna y externa. DESEMPEO DEL DESARROLLO. Es la evaluacin del Proceso de desarrollo adecuado tomando en cuentas ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con presupuesto y estndares y otros criterios de Administracin de Proyectos. Adems se incluyen la valoracin de los mtodos y herramientas utilizados durante el desarrollo del Sistema. PRUEBA DE SISTEMAS. Dependiendo del tamao de la Empresa que usara el Sistema y el riesgo asociado a su uso, puede hacerse la eleccin de comenzar la operacin 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 simultnea o paralela con la finalidad de comparar los resultados que ambos ofrecen en su operacin, adems dar tiempo al personal para su entrenamiento y adaptacin al nuevo Sistema. Durante el Proceso de Implantacin 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 evaluacin de Sistemas no siempre recibe la atencin 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 Diseo de los Sistemas de Computacin. Explicar con un ejemplo el diseo Arquitectnico de los Sistemas de Computacin. Investigar y explicar el diseo Arquitectnico en tres capas. Cual es la Herramienta ms importante dentro del Diseo. Cual es la etapa mas importante dentro de la Implantacin, Evaluacin y las Pruebas.
U N
I V E R S
I D A D
D 42
A Q U
I N
B O L
I V
I A
WORK PAPER # 7
No. DE HOJAS: 7
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja TTULO DEL WORK PAPER: BASE DE DATOS CORPORATIVA
CDIGO: CMP 316
FECHA DE DIFUSIN: Julio 2011
FECHA DE ENTREGA: Julio 2011
U N
I V E R S
I D A D
D 43
A Q U
I N
B O L
I V
I A
BASE DE DATOS CORPORATIVA Integra toda la informacin de la compaa, 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 informacin 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 caractersticas; las principales son las siguientes:

GDSS. Sistemas diseados especialmente para apoyar las decisiones en grupo. La meta de GDSS. Es apoyar a los tomadores de decisiones en su trabajo. GDSS. Es fcil de aprender y de usar. Accesible para usuarios con diferentes niveles de conocimiento computacional y de soporte a la decisin. Tales como ventas, produccin, recursos humanos, administracin y finanzas. Un GDSS. Contiene mecanismo para evitar el desarrollo de conductas negativas en el grupo, como son los problemas de comunicacin. Un GDSS debe motivar a todos los miembros del grupo a participar de manera activa. Es importante que pueda existir anonimato de la participacin.
Las principales ventajas de GDSS son:

Motiva a los miembros del grupo a trabajar juntos Da la misma oportunidad de participacin a todos los miembros del grupo. Se optimiza el uso de la informacin 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 decisin puede diluirse.
APLICACIONES DE LOS DGSS.

Establecimiento de la misin de una empresa. Formulacin de estrategias que ayudarn a que la misin se cumpla. Evaluacin de administradores. Para incrementar el sueldo de un administrador o para verificar que est cumpliendo con su deber. Planeacin de sistemas de informacin. Cuando se requiere introducir nueva tecnologa de sistemas de informacin es necesario modificar el plan de sistemas
Soporte en negociaciones. Apoyar los trabajos que visuales, como la seleccin de un empaque para un nuevo producto. Apoyar los trabajos que involucran diseo y revisiones de control de calidad. Apoyar una decisin en particular.
Sistemas Expertos de Soporte para la Toma de Decisiones (EDSS: Expert Decision Support Systems). Los sistemas expertos constituyen el rea de la inteligencia artificial que quiz en este momento tiene ms relacin con el apoyo al proceso de la toma de decisiones en las organizaciones. Beneficios de la utilizacin de un sistema GDSS: o Reduccin en la dependencia de personal clave se debe a tener los conocimientos del personal especializado son detenidos durante el proceso de aprendizaje y estn listos para ser utilizados por diferentes personas. Facilitar el entrenamiento del personal. Capacitacin y adiestramiento del personal sin experiencia. Mejora en la calidad y eficiencia en el proceso de la toma de decisiones. Las decisiones podrn tomarse de una forma ms gil con el apoyo de un sistema experto. Transferencia de la capacidad de decisiones. Un sistema experto puede facilitar la descentralizacin de datos en el proceso de la toma de decisiones en aquellos casos que se consideren convenientes.
o o o
COSTO QUE INVOLUCRA:

El Shell o paquete generador del sistema experto. El equipo computacional o hardware que se requiera. Consultorio especializado. Contratacin o pago a los ingenieros especialistas. El tiempo de los expertos. Costos de implantacin. Costos involucrados con el mantenimiento y se guimiento del sistema.
Sistemas de Informacin para Ejecutivos (EIS: Executive Information Systems) CARACTERSTICAS DE UN EIS.

Estn diseados para cubrir las necesidades especficas y particulares de la alta administracin de la empresa. Extraen, filtran, comprimen y dan seguimiento a formacin crtica del negocio. Pueden acceder informacin que se encuentra en lnea, extrayndose en forma directa de las bases de datos de la organizacin El sistema est soportado por elementos especializados de hardware, tales como monitores o videos de alta resolucin y sensibles al tacto.
Las siguientes caractersticas adicionales deben estar presentes para considerar a un ESS:

Contempla las facilidades de comunicacin electrnica. Capacidad de anlisis de datos, tales como hoja electrnica de clculo. Herramientas para la organizacin personal del ejecutivo, tales como calendario.
U N
I V E R S
I D A D
D 45
A Q U
I N
B O L
I V
I A
FACTORES DEL XITO DE UN EIS. Es necesario que cumpla con los siguientes factores: Que se vea bien. Debe de estar orientado al uso grfico de las pantallas. Que sea relevante. Debe dar a los ejecutivos acceso a los datos que son importantes para la organizacin y que se han identificado como crticos para el xito de la empresa. Que sea rpido. Se necesitan tiempos de respuesta cortos, de lo contrario los ejecutivos dirn que estn perdiendo su tiempo. Que la informacin est disponible y actualizada. Un ELS debe proporcionar a los ejecutivos la informacin 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 caractersticas 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 tcnicas utilizadas para el anlisis y desarrollo de los tradicionales sistemas transaccionales no necesariamente funcionan100% de manera similar durante el desarrollo de un EIS. A continuacin se propone una metodologa para su desarrollo e implantacin. 1.-Identificacin de las alternativas para el desarrollo del sistema. Existen diferentes alternativas para el desarrollo de un EIS. A continuacin 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 aplicacin. 2.-Creacin de la propuesta. En este paso debe escribirse o elaborarse una presentacin de la propuesta del EIS. La creacin de la propuesta ayudar a tener un apoyo ms slido 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 creacin y presentacin 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 visin ms clara de lo que es un EIS, de las expectativas con respecto a su uso y de los recursos que requiere su desarrollo.
3.-.Determinacin 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 cules son las preguntas que le gustara 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 informacin necesaria para darle seguimiento. Preguntar a los ejecutivos cules son los datos que no les gustara que llegaran a manos de la competencia. A travs de simple observacin o entrevistas de terminar la informacin que utiliza en la actualidad el ejecutivo para monitorear la situacin de la empresa. 4.- Creacin del sistema y presentacin de un prototipo. La clave para la creacin 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 informacin son vistos adems 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 estratgica considera a los sistemas de informacin como una herramienta para mejorar la estructura competitiva del negocio, por lo que tienen su rea de influencia en el medio ambiente de la organizacin, a travs de nuevos servicios a clientes, nuevos negocios y oportunidades de inversin. Wiseman define la visin gerencial o estrategia como <<la necesidad de entender de qu forma la tecnologa de la informacin es utilizada para soportar o dar forma a la estrategia competitiva de la empresa>>. Esta habilidad de ver y entender el nuevo rol de los sistemas de informacin constituye la esencia de la visin de los sistemas de informacin estratgica. Sus principales caractersticas son:

Proporcionar informacin para apoyar la toma de decisiones. No pueden adaptarse fcilmente a paquetes disponibles en el mercado. Tpicamente su forma de desarrollo es a base de incrementos y a travs de su evolucin dentro de la organizacin. Su funcin 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 estratgicos son creados de barreras de entrada al negocio. Apoyan los procesos de innovacin de productos y proceso dentro de la empresa. Una forma de hacerlo es innovando o creando productos y procesos.
Wisenman utiliza el trmino impulsos estratgicos para connotar los movimientos que hace una empresa con el fin de ganar o mantener algn tipo de ventaja competitiva. Las cinco categoras que contempla Wiseman en cuanto a los impulsos estratgicos.
U N
I V E R S
I D A D
D 47
A Q U
I N
B O L
I V
I A
DIFERENCIACIN.
Este impulso estratgico se refiere a la diferenciacin de los productos o servicios a travs de precios, plazas o promociones. Proceso de diferenciacin puede trabajar en dos direcciones. La primera de ellas se refiere a lograr ventajas de diferenciacin sobre los competidores utilizando la tecnologa de la informacin; la segunda consiste en identificar oportunidades para reducir las ventajas de diferenciacin 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 reduccin de costos a proveedores o clientes, con el fin de obtener un trato preferencial. Las economas de escala se logran cuando se aumenta el volumen de la ventas de productos o servicios para reducir los costos unitarios, a travs de mejores negociaciones con proveedores de servicio debidas a mayor volumen de compra. o CRECIMIENTO.
El impulso estratgico del crecimiento permite la consecucin de ventas competitivas, mediante el incremento del volumen de operaciones en el negocio. El crecimiento de producto o mercado se refiere a la expansin de mercados, satisfaccin de nuevas necesidades o la incorporacin de nuevas tecnologas 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 estratgico de la globalizacin es, segn Wiseman, un impulso de crecimiento que involucra elementos forneos al producto neto de la compaa. o ALIANZAS.
Las alianzas son definidas por Wiseman como la combinacin de dos ms grupos o individuos que se unen para lograr un objetivo comn. o INNOVACIN.
Otro de los impulsos estratgicas que puede ser apoyando a travs de la tecnologa de informacin, ya sea en productos o en tecnologa de informacin, ya sea en productos o en procesos nuevos. Para que un proceso de innovacin tenga xito requiere respuestas rpidas a las oportunidades que se representan, sin embargo, existen riesgos inherentes debido a la naturaleza del proceso, ya que es difcil innovar sin correr riesgos. El proceso de innovacin consta de las siguientes fases: nacimiento de una idea, venta de la idea a una persona con poder de decisin, 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 innovacin para protegerse de los competidores.
U N
I V E R S
I D A D
D 48
A Q U
I N
B O L
I V
I A
Cuestionario: 1. 2. 3. 4. 5. 6. 7. 8. Que es una base de datos y una bases de datos corporativa Como interacta 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 49
A Q U
I N
B O L
I V
I A
PROGRAMA DE CALIDAD UDABOL DIF 001

SISTEMAS DE SOPORTE PARA LA TOMA DE DECISIONES (DSS: DECISION SUPPORT SYSTEMS) Caractersticas

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 utilizacin frecuente por parte de la administracin. 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 decisin sin la participacin operativa de profesionales en informtica. Interaccin ambiental. Permite la posibilidad de interactuar con informacin externa como parte de los modelos de decisin. Comunicacin nter organizacional. Facilita la comunicacin de informacin relevante de los niveles altos a los niveles operativos y viceversa, a travs de grficas. Acceso a bases de datos. Tiene la capacidad de acceder informacin de las bases de datos corporativas. Simplicidad. Simple y fcil de aprender y utilizar por el usuario final.
Recuerde: DSS integran en su mayora 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 consolidacin en la administracin de la informacin. Problemas de seguridad de la informacin. Perdida del control administrativa por parte del rea de informtica.
Las diferentes opciones para la implantacin de los DSS

Implantacin aislada en microcomputadoras. Implantacin en microcomputadoras interconectadas y que constituyen una red local. Microcomputadoras conectadas a mini computadoras o servidores.
MDULOS FUNCIONALES QUE INTEGRAN UN DSS. Una de las caractersticas que poseen los DSS es la facilidad de que un usuario, sin tener conocimientos amplios sobre sistemas computacionales, pueda desarrollar sus propios modelos de decisin. Estos modelos son construidos con la ayuda de las herramientas, que en trminos generales se clasifican en herramientas de hardware y de software.
U N
I V E R S
I D A D
D 50
A Q U
I N
B O L
I V
I A
MANEJO DE MODELOS. Permite al usuario utilizar modelos clsicos, que se encuentran desarrollados y disponibles, formando la base de modelos. Pueden incluir:

Inventarios Control de proyectos Programacin lineal Simulacin Colas Anlisis estadsticos Planeacin financiera y generacin de esencias
MANEJO Y ADMINISTRACIN DE DATOS. Recuerde: Incluye funciones tales como:

Acceso a las bases de datos corporativos Generacin de informacin privada en bases de datos locales. Manipulacin de la informacin a travs de tcnicas de manejo de informacin.
DESARROLLO DE APLICACIONES. La mayora de los DSS permite a los usuarios desarrollar sus propios modelos de decisin. En este sentido, el usuario disea 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 travs de los cambios. Prototipo, es diferente al proceso tradicional de desarrollo de un sistema tradicional de desarrollo de un sistema transaccional tpico. Recuerde: Las Aplicaciones desechables, es decir, modelos de decisin que fueron desarrollados en tiempo muy corto, para apoyar una decisin en particular. INTERFACES GRFICAS, REPORTES Y CONSULTAS. Facilidad para explorar la informacin a travs de graficas de alta calidad y reportes que se disean y obtienen en intervalos cortos de tiempo, la disponibilidad de lenguajes de muy alto nivel para facilitar la consulta de informacin que contienen las bases de datos.
U N
I V E R S
I D A D
D 51
A Q U
I N
B O L
I V
I A
PROGRAMA DE CALIDAD UDABOL DIF 002 PROCESO UNIFICADO Y MSF; COMPLEMENTOS TECNOLGICOS Segn M&R 1998, "ms que una metodologa, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guan a una organizacin sobre como ensamblar los recursos, el personal y las tcnicas necesaria para asegurar que su infraestructura tecnolgica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relacin clara entre los objetivos de negocio y las implementaciones tecnolgicas". Recuerde: "MSF se puede utilizar por s mismo o con otras herramientas y tcnicas 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 varan en tamao y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa de objetos en el desarrollo de software de misin crtica en una variedad de industrias. Uno de los componentes clave es el UML" [M&R 1998]. MSF proporciona las tcnicas ligadas a la tecnologa y el Proceso Unificado la gua detallada para el desarrollo de software minimizando los riesgos. El Proceso Unificado ha adoptado un enfoque que se caracteriza por:

Interaccin con el usuario continua desde un inicio Mitigacin 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 organizacin y de cmo son apoyados por una infraestructura tecnolgica basada en servicios. Arquitectura de Aplicacin Adopta un modelo de aplicacin de toda la empresa para disear y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. Arquitectura de Informacin Define qu informacin es necesaria para apoyar el proceso de negocios y como poner esa informacin eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. Arquitectura Tecnolgica Define los estndares y guas para la adquisicin y despliegue de herramientas, bloques de construccin 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 52
A Q U
I N
B O L
I V
I A
El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeo para crear soluciones ms rpido, mejor y ms 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 ms detalle y gua para algunos de los roles en el proyecto. Recuerde: Una vista arquitectnica es "una descripcin simplificada (una abstraccin) 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]. Segn el mismo autor, las caractersticas primordiales del Proceso Unificado son:

Iterativo e incremental Centrado en la arquitectura Guiado por casos de uso Confrontacin de riesgos
Recuerde: El Proceso Unificado es un proceso porque "define quin est haciendo qu, cundo lo hacer y cmo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson 1998]. Segn [Booch 1998], los conceptos clave del Proceso Unificado son:
Fase e iteraciones Flujos de trabajo de procesos (actividades y pasos) Artefactos (modelos, reportes, documentos) Trabajador: un arquitecto
Cundo se hace? Qu se est haciendo? Qu se produjo? Quin lo hace?)
U N
I V E R S
I D A D
D 53
A Q U
I N
B O L
I V
I A
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: concepcin, elaboracin, construccin y transicin. La concepcin es definir el alcance del proyecto y definir el caso de uso. La elaboracin es proyectar un plan, definir las caractersticas y cimentar la arquitectura. La construccin es crear el producto y la transicin es transferir el producto a sus usuarios [Booch 1998].
Estructura del Proceso Unificado Segn [Microsoft 1997], el diseo de software se realiza a tres niveles: conceptual, lgico y fsico.
Arquitectura lgica de tres capas de una aplicacin cliente/servidor Recuerde: Un ingeniero de software necesita de herramientas, entre ellas las herramientas de Rational son las ms avanzadas, pero son muy costosas. Tambin puede utilizar las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de cdigo abierto y an estn de desarrollo. Utiliza las que ms te sean de utilidad.
U N
I V E R S
I D A D
D 54
A Q U
I N
B O L
I V
I A
PROGRAMA DE CALIDAD UDABOL DIF 004 PODREDUMBRE DEL SOFTWARE Qu le pasa al software? El diseo de muchas aplicaciones comienza con una imagen clara en la mente del diseador. En este estado el diseo es claro, conciso y elegante. Diseadores y programadores desean verlo funcionar. Algunos de estos proyectos mantienen esta pureza de diseo hasta la primera versin. Pero algo comienza a pasar. Al principio apenas es perceptible. Un parche por aqu, una apa por all, aunque el diseo todava mantiene la filosofa inicial. El software comienza a pudrirse. Las apas continan y poco a poco el software se corrompe mas y mas hasta llegar un punto en el que afecta a toda la aplicacin. El programa se convierte en una ingente masa de cdigo que cada vez es ms difcil de mantener. Entonces el esfuerzo requerido para hacer el ms simple de los cambios es tal que los responsables de producto se plantean hacer un rediseo de la aplicacin. Los rediseos normalmente no fructifican. Aunque las intenciones de los diseadores son buenas se dan cuenta de que es una tarea imposible. El sistema continua evolucionando, cambiando y el nuevo rediseo nunca termina. Un da la cantidad de problemas vuelve a ser tal que se los diseadores lloran por otro rediseo. Sntomas de un mal diseo Recuerde: Hay cuatro indicios principales que nos indican que el software se esta pudriendo. No son dependientes y estn relacionados unos con otros, son: rigidez, fragilidad, inmovilidad y viscosidad. Rigidez. Es la tendencia del software a ser difcil de cambiar, incluso en las cosas ms sencillas. Cada cambio produce una cascada de cambios en mdulos dependientes. Lo que pareca un cambio de dos das en un mdulo resulta ser varias semanas de cambios de mdulos tirando del hilo a travs de la aplicacin. Cuando el software toma este camino, los gestores temen decir a los programadores que arreglen pequeos problemas que no son crticos. 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 aplicacin. De manera que, lo que empez siendo un diseo ineficiente acaba siendo una mala poltica de gestin. 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 estn 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 algn lugar inesperado. Conforme la fragilidad empeora, la probabilidad de que el software se rompa incrementa con el tiempo, acercndose cada vez ms a 1. Este software es imposible de mantener. Cada arreglo lo hace peor, introduciendo ms problemas de los que son solucionados. Recuerde: Este software causa que los gestores y los clientes tengan la impresin de que los desarrolladores han perdido el control del software, perdindose as la credibilidad de los desarrolladores. Y frases como "Rompes ms 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 mdulo que es muy parecido a otro
que ha desarrollado otro programador. Sin embargo, tambin pasa muchas veces que el mdulo en cuestin depende demasiado de la aplicacin en la que est integrado. Despus 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 diseo es la dificultad de mantener la filosofa del diseo original. Cuando se afronta un cambio los programadores encuentran normalmente ms de una manera de realizarlo. Algunas de estas formas preservan la filosofa del diseo y otras no. Cuando las formas de implementar el cambio preservando el diseo son ms difciles de realizar que las que no lo preservan, entonces la viscosidad del diseo es alta. Es fcil hacerlo mal y difcil hacerlo bien. Estos cuatro sntomas son reveladores de un diseo de arquitectura pobre. Cualquier aplicacin que muestra estos sntomas adolece de un diseo pobre. Qu causa que el diseo se deteriore? Requisitos cambiantes La causa de la degradacin del diseo es muy conocida. Los requisitos han ido cambiando de manera que no estaba previsto en el diseo inicial. A menudo los cambios necesitan hacerse rpidamente y hechos por programadores que no estn familiarizados con el diseo original. Entonces, aunque los cambios funcionan, violan el diseo original. Poco a poco los cambios continan y las violaciones se acumulan hasta que el diseo se rompe. An 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 diseo que soporte modificaciones sin que este pierda su consistencia. Control de dependencias Qu tipos de cambios hacen que un diseo 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 mdulos del software. Son las dependencias de la arquitectura lo que se degrada y con ellas el mantenimiento del software. Para anticiparse a la degradacin de las dependencias del diseo de la arquitectura, deben ser controladas las dependencias entre mdulos de una aplicacin. Este control consiste en la creacin de "cortafuegos" de dependencias. A travs de estos cortafuegos las dependencias no se propagan. Recuerde: El diseo orientado a objetos esta repleto de principios y tcnicas que nos permiten construir estos cortafuegos y controlar estas dependencias.
U N
I V E R S
I D A D
D 56
A Q U
I N
B O L
I V
I A
PROGRAMA DE CALIDAD UDABOL DIF 005 PATRONES DE DISEO Diseo de Software Orientado a Objetos Patrones de diseo o ms comnmente conocidos como "Design Patterns". Qu son los patrones de diseo? Son soluciones simples y elegantes a problemas especficos y comunes del diseo 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 diseos de aplicaciones hay problemas que se repiten o que son anlogos, es decir, que responden a un cierto patrn. Sera deseable tener una coleccin de dichos patrones con las soluciones ms ptimas para cada caso. En este artculo presentamos una lista con los ms comunes y conocidos. Recuerde: Los patrones de diseo no son fciles de entender, pero una vez entendido su funcionamiento, los diseos sern mucho ms flexibles, modulares y reutilizables. Han revolucionado el diseo orientado a objetos y todo buen arquitecto de software debera conocerlos. A continuacin una lista con los patrones de diseo a objetos ms habituales publicados en el libro "Design Patterns ", escrito por los que comnmente se conoce como GoF (gang of four, "pandilla de los cuatro"). Patrones de creacin

Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre s, sin especificar sus clases concretas. Builder. Separa la construccin de un objeto complejo de su representacin, de forma que el mismo proceso de construccin 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 creacin de objetos. Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototpica, y crear nuevos objetos copiando este prototipo. Singleton. Garantiza que una clase slo 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 podran por tener interfaces incompatibles. Bridge. Desvincula una abstraccin de su implementacin, de manera que ambas puedan variar de forma independiente. Composite. Combina objetos en estructuras de rbol para representar jerarquas de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos. Decorator. Aade dinmicamente 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 ms fcil de usar. Flyweight. Usa el compartimiento para permitir un gran nmero 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 57
A Q U
I N
B O L
I V
I A
Patrones de comportamiento
Chain of Responsibility. Evita acoplar el emisor de una peticin a su receptor, al dar a ms de un objeto la posibilidad de responder a la peticin. Crea una cadena con los objetos receptores y pasa la peticin a travs de la cadena hasta que esta sea tratada por algn objeto. Command. Encapsula una peticin 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 representacin de su gramtica junto con un intrprete que usa dicha representacin para interpretar las sentencias del lenguaje. Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representacin interna. Mediator. Define un objeto que encapsula cmo interactan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explcitamente, y permite variar la interaccin entre ellos de forma independiente. Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulacin, de forma que ste puede volver a dicho estado ms tarde. Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automticamente 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 vare independientemente de los clientes que lo usan. Template Method. Define en una operacin 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 operacin sobre los elementos de una estructura de objetos. Permite definir una nueva operacin sin cambiar las clases de los elementos sobre los que opera.
Recuerde: Es necesario que el grupo de resolucin 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 58
A Q U
I N
B O L
I V
I A
PROGRAMA DE CALIDAD UDABOL DIF 006 SEGUIMIENTO Y GESTIN DE ERRORES, BUG TRACKING Recuerde: Es inevitable, los programas tienen errores. No importa cuanto lo pruebes y el cuidado que tengas en desarrollar la aplicacin, 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 mtodo 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

Recuerde: A quin no le ha pasado alguna de estas cosas? Estos son algunos de los problemas tpicos que nos podemos encontrar si no tenemos una gestin 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 llegarn partes de errores decentes, con toda la informacin necesaria para poder arreglarlo. No pierdes errores y te evitas broncas de porqu no arreglaste aquel
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 cmo provocar el bug, no puede reproducirlo y por tanto no puede arreglarlo. Causa: Mala descripcin del bug. El programador cree que ha arreglado el bug, cambia una cosa que funcionaba y deja el bug. Causa: No sabe cmo deba funcionar. El programador reproduce el bug y lo arregla, nadie se entera, al cliente nunca le llega el programa arreglado. Causa: Deficiente comunicacin. Alguien encuentra un bug y habla con distintos programadores para que se arregle, varios programadores se ponen a arreglarlo entorpecindose y perdiendo tiempo. Causa: No hay una canalizacin 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 gestin 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 resolucin. 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 ms importantes que otros, pero el tiempo est limitado, los programadores pierden el tiempo arreglado bugs triviales mientras que los bugs crticos siguen sin arreglar. Causa: Los bugs no estn priorizados.
U N
I V E R S
I D A D
D 59
A Q U
I N
B O L
I V
I A
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 estn arreglando y cuales se han arreglado, ponerles prioridad, sabes que no se perdern, decidir cuales quieres que se arreglen para esta versin y cuales para la siguiente. Como personal de soporte te beneficia, tienes un sistema para reportar los errores que el cliente detecta, tambin puedes introducir las mejoras que el cliente te sugiere, puedes buscar en la base de datos si el error es conocido y enviarle la versin 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 60
A Q U
I N
B O L
I V
I A
PROGRAMA DE CALIDAD UDABOL DIF 007 CONTROL DE CDIGO FUENTE Recuerde: Es necesario que se lea detenidamente este Dif para poder analizarlo adecuadamente. Tienes ms de 2 personas trabajando en un mismo proyecto? Los programadores machacan su cdigo fuente? Quieres llevar un control de versiones de tu software? Necesitas tener bajo control tu cdigo fuente. Recuerde: Al principio no hay problemas, t desarrollas solo, tienes todos los ficheros fuente. Aades, editas, borras ficheros fuente conforme te parece y vas necesitando. Esto funciona bien si el proyecto es pequeo y no tienes necesidad de ms programadores. Pero un da llega el momento en que el proyecto es un poco ms grande y estn trabajando simultneamente 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 ms normal es que dos programadores estn editando el mismo fichero fuente y uno de los dos machaque el trabajo del otro, con el consiguiente enfado del perjudicado. Y ms vale que esto no ocurra ms de una vez porque si no el posible pequeo enfado se puede convertir en represalia y ya te puedes imaginar las consecuencias que esto tiene. As que en un alarde de imaginacin 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 algn fichero "general" que avise a los dems para que no lo editen al mismo tiempo. No hace falta pensar mucho para darse cuenta que al rato esto nos lleva a la situacin del principio, machacndose unos ficheros a los otros. Primero porque la separacin en partes disjuntas no est clara y sobre todo porque cuando tienes que avisar a los dems de que vas a editar un fichero comn, a veces se te olvida y no lo haces, o piensas que slo lo abres para verlo y no vas a tocar nada, pero que luego resulta que si modificas. As que si tienes ms 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 cdigo de otro inconscientemente, tambin 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 ms se ajuste a vuestras necesidades.
RCS. Revisin Control Sistema. Uno de los ms antiguos (1980) y tambin de los ms sencillos de usar. Desarrollado para entornos UNIX aunque tambin est portado a Windows. Recomendado para proyectos no muy complejos en entorno UNIX bajo la misma mquina. MS Visual SourceSafe. La alternativa Microsoft. Se integra muy bien, como sera de esperar, con las herramientas de desarrollo de Microsoft. Si tu entorno de desarrollo es Microsoft, esta es tu primera opcin.
U N
I V E R S
I D A D
D 61
A Q U
I N
B O L
I V
I A
Es viejo, feo (estilo W95) y mil veces parcheado, pero es lo que hay. Funciona decentemente bien y no da muchos problemas.
CVS. Concurren Versiona Sistema. Posiblemente sea uno de los mejores. Adems de hacer lo que los anteriores tambin puede funcionar como cliente/servidor a travs de Internet, puede manejar distintas ramas y realizar mezclas de ellas cuando sea necesario, y otras muchas cosas. Si bien los clientes pueden correr en muchos sistemas operativos de la familia UNIX y de la familia Windows, el servidor ha de estar en un sistema de la familia UNIX. Existen versiones que corren bajo Windows pero recomiendan no usarlas en entornos de produccin. Aadir que por su buena integracin en Internet, es una de las herramientas ms usadas en el desarrollo de proyectos geogrficamente distribuidos como puede ser los proyectos de software libre. IBM Rational ClearCase. El caro. Con estos dos padres IBM y Racional, que ms podemos decir. No lo he usado en entornos productivos, pero he estado trasteando con la versin de evaluacin y la verdad es que parece muy bueno. Con las capacidades de CVS y adems un entorno grfico amigable. Se integra bien con las herramientas de Microsoft aunque no tan bien como SourceSafe.
Recuerde: Si tienes un equipo de trabajo necesitas que tus ficheros fuente estn bajo control. Elige el que ms se ajuste a tus necesidades y muchos de tus problemas con la gestin del cdigo fuente desaparecern. Recuerde: Debes asegrate que tu herramienta de desarrollo se integra bien con tu gestor de cdigo fuente y todo el mundo ser feliz. Si no, los desarrolladores se van a quejar y eso significa que no lo usaran y entonces volvers a estar como al principio.
U N
I V E R S
I D A D
D 62
A Q U
I N
B O L
I V
I A

s8 - Ingenieria - de - Software PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

s8 - Ingenieria - de - Software PDF

Hochgeladen von

Copyright:

Verfügbare Formate

FACULTAD DE CIENCIAS Y TECNOLOGIA

RED NACIONAL UNIVERSITARIA

Facultad de Ciencias y Tecnologa

Ingeniera de Sistemas OCTAVO SEMESTRE

Gestin Acadmica I / 2011

Syllabus elaborado por: Ing. Reynaldo Einar Zabaleta Rioja

FACULTAD DE CIENCIAS Y TECNOLOGIA

VISIN DE LA UNIVERSIDAD Ser la Universidad lder en calidad educativa.

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

VI. PLAN CALENDARIO

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

No. DE PROCEDIMIENTO: APRO 07

ELABOR: Ing. Reynaldo Einar Zabaleta Rioja

CDIGO: CMP 518

TTULO DEL WORK PAPER: LA INGENIERA DE SOFTWARE Y EL PARADIGMA DE LO ORIENTADO A OBJETOS

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

No. DE PROCEDIMIENTO: APRO 07

ELABOR: Ing. Reynaldo Einar Zabaleta Rioja

CDIGO: CMP 518

TTULO DEL WORK PAPER: CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE I

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

Esquema general de operacin de una fase

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

No. DE PROCEDIMIENTO: APRO 07

ELABOR: Ing. Reynaldo Einar Zabaleta Rioja

CDIGO: CMP 518

TTULO DEL WORK PAPER: CICLOS DE VIDA Y MODELO DE PROCESOS DE SOFTWARE 2

FECHA DE DIFUSIN: Abril 2011

FECHA DE ENTREGA: Abril 2011

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

No. DE PROCEDIMIENTO: APRO 07

ELABOR: Ing. Reynaldo Einar Zabaleta Rioja

CDIGO: CMP 518

TTULO DEL WORK PAPER: LA GERENCIA DE PROYECTOS DE SOFTWARE

FECHA DE DIFUSIN: Mayo 2011

FECHA DE ENTREGA: Mayo 2011