UNIVERSIDAD LAICA ELOY ALFARO DE MANABI

Facultad de Ciencias Informticas

Gestin de la Calidad del Software Docente Ing. Marco Ayovi Ramirez Alumno Bello Flores Ramn David

Planificacin de Proyectos de Software

Sexto Nivel Paralelo B, 1er Parcial

Contenido
Introduccin .................................................................................................................................. 3 Lectura Comprensiva..................................................................................................................... 4 Planteamiento del problema. ....................................................................................................... 5 Objetivos ....................................................................................................................................... 6 Objetivo General: ...................................................................................................................... 6 Objetivo Especfico. .................................................................................................................. 6 Maco Terico................................................................................................................................. 7 1 Planificacin de Proyectos de Software ................................................................................. 7 1.1 Principios y consideraciones para la Planificacin ............................................................. 7 1.2 Ciclo de Planificacin de Proyectos de Desarrollo de Software ......................................... 7 1.3 Plan del Proyecto de Desarrollo de Software. ..................................................................... 8 1.3.1 Para qu se usa el plan del proyecto? ......................................................................... 9 1.4 Fallas en la Planificacin..................................................................................................... 9 1.5 Especificacin de Requerimientos. ................................................................................... 10 1.5.1 Terminologa y modelo de referencia para el ciclo de vida del Software. ................. 11 1.5.2 De la especificacin del Software .............................................................................. 13 1.5.3 Procesos y productos del ciclo de vida. ...................................................................... 13 1.5.4 Lenguaje Unificado de Modelamiento (UML) .......................................................... 16 1.6 Metodologa de Desarrollo de Productos de Software ..................................................... 18 1.6.1 Proceso de Definicin del Proyecto ........................................................................... 19 1.6.2 Proceso de Desarrollo de Software ............................................................................ 20 1.7 Herramientas de Apoyo al Proceso de desarrollo ............................................................. 21 En la siguiente tabla se mostraran las etapas y las herramientas que las apoyan. .................... 21 Palabras ....................................................................................................................................... 22 Prefactibilidad ......................................................................................................................... 22 Bidimensional ......................................................................................................................... 22 Planificacin............................................................................................................................ 22 Estimacin ............................................................................................................................... 22 Consideraciones ...................................................................................................................... 22 Conclusiones ............................................................................................................................... 23 Recomendaciones ....................................................................................................................... 24 F.O.D.A ........................................................................................................................................ 24 Fortaleza: ................................................................................................................................. 24 Oportunidades: ........................................................................................................................ 24

Debilidades.............................................................................................................................. 25 Amenazas ................................................................................................................................ 25 Referencias .................................................................................................................................. 26

Introduccin
La Planificacin es un proceso que comienza con una misin, se trazan metas y objetivos que deben lograrse y para aquello se desarrollan planes, procedimientos y se establece una organizacin para asigna recursos y responsabilidades con el propsito de alcanzar los objetivos propuestos. El resultado principal de la planificacin es el Plan del Proyecto la planeacin efectiva de un proyecto de software depende de la planeacin detallada de su avance, anticipando problemas que puedan surgir y preparando con anticipacin soluciones a ellos. Se supondr que el administrador del proyecto es responsable de la planeacin desde la definicin de requisitos hasta la entrega del sistema terminado.

Lectura Comprensiva
Planificacin de Proyectos de 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, y estimar es dar un vistazo al futuro. Aunque la estimacin, es ms 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. Y no se debe olvidar de la disponibilidad de informacin Histrica que es otro elemento que determina el riesgo de la estimacin.

Planteamiento del problema.

En aspectos relacionados con la gestin de proyectos encontramos diferentes categoras pero esta investigacin se centrara en el tema: Planificacin de Proyectos de Software. En el Ecuador los criterios de organizacin a nivel corporativo, por lo general en pequeas y medianas industrias, es un tema poco acogido o ms bien poco entendido ya que como requerimiento en la realizacin de un proyecto intervienen diversas gestiones entre estas incluye la gestin que se tratara: Gestin de Planeacin de Proyecto de Software. En la ciudad de Manta la Universidad Laica Eloy Alfaro de Manab, en la Facultad de Ciencias Informticas, se desempea la labor de impartir conocimientos sobre desarrollo de software para los estudiantes de Sexto Nivel. El comprender la parte tcnica organizativa en la realizacin de proyectos de software, es labor fundamental y con una importancia relevante para todas las personas que conforman la Facultad. Esta investigacin, pretende dar a conocer que es la Gestin de Proyecto de Software y que mtodos y tcnicas se deben aplicar para tener un mejor desarrollo y cumplimiento en la secuencia de cada proyecto a realizar.

Objetivos
Objetivo General:
Investigar acerca de la Planificacin de los Proyectos de Software para conocer sobre el tema investigado.

Objetivo Especfico.
Investigar la que es Planificacin de los Proyectos de Software Entender los tema investigado Analizar la investigacin realizada Conocer la importancia del porqu se realiza la planeacin de proyectos.

Maco Terico
1 Planificacin de Proyectos de Software 1.1 Principios y consideraciones para la Planificacin
Todas las organizaciones planifican, pero por lo general no se realiza de la manera adecuada, muchas veces la planificacin se realiza de manera informal cuando debiera ser formal. La planificacin formal es aquella que es: Documentada. Uniforme y regularmente aplicada. Con resultados concretos, distribuidos, entendidos y comprometidos por organizacin. En una planificacin formal deben quedar claramente identificados los planes, procedimientos, la organizacin, la asignacin de recursos y las responsabilidades. El proceso de planificacin produce idealmente un conjunto de planes, clasificados como esenciales y de soporte. Los planes esenciales son aquellos que se consideran imprescindibles en cada proyecto, dentro de estos estn: Plan de Proyecto, Plan de Pruebas y Plan de Instalacin. Los planes de soporte no siempre son necesarios, entre ellos estn: Plan de Entrenamiento, Plan de Control de Cambios. La planificacin es un proceso continuo, no es un esfuerzo que se realiza una nica vez en el proyecto. Si los mecanismos de control identifican algn problema, probablemente los planes debern ajustarse a esta nueva situacin. La planificacin es un proceso de toma de decisiones. No se toman decisiones futuras, sino ms bien, se evala el impacto futuro de decisiones actuales. A medida que se planifica se decide lo que debera hacerse y lo que no. Debe comprometer a aquellos individuos que poseen la habilidad de poner en marcha las cosas, obteniendo resultados concretos. Al planificar no se intenta eliminar el riesgo, con o sin planificacin existen circunstancias que pueden atentar contra el xito de un proyecto, la planificacin no puede prevenirlos, pero puede ayudar a reducir su impacto y a controlar el riesgo. La planificacin de proyectos requiere soporte de la administracin y de otras reas organizacionales. Todo el esfuerzo puede frustrarse cuando no se cuenta con este soporte.

1.2 Ciclo de Planificacin de Proyectos de Desarrollo de Software

El ciclo de planificacin de proyectos de Desarrollo de Software, comienza con los requerimientos iniciales y tiene las siguientes etapas: Negociacin de Compromisos. El jefe de proyecto y el cliente y/o usuario negocian los compromisos mutuos, los cuales se establecen sobre la base de los requerimientos del producto de software y objetivos del proyecto.

Descomposicin de Requerimientos. El producto de software se divide en elementos claves denominados Estructuras de Divisin del Trabajo (EDTo WBS). Una EDT es un organigrama jerrquico donde se establecen las distintas partes de un producto de software. Representa una jerarqua de componentes o bien de procesos. La jerarqua de componentes identifica cada uno de los componentes del software y la manera en que stos se relacionan. La jerarqua de procesos representa las actividades de trabajo requeridas para desarrollar el software y sus interrelaciones. Si se usa este tipo de EDT se deben considerar las fases, actividades y tareas estndares definidas por la organizacin y tambin las tareas especiales del proyecto. Estimacin del Tamao de un producto de Software. Una vez establecido el estndar de medicin (Lneas de Cdigo, Puntos de Funcin, Puntos Objetos), se utiliza la EDT de componentes para estimar el tamao de cada componente del software. El tamao total del producto de software se obtiene al sumar los valores estimados para cada componente y al ajustar la estimacin de acuerdo a la informacin histrica de la organizacin, si es necesario. Estimacin de Recursos. El tamao del producto de software sirve de base para estimar esfuerzo (Persona-Mes, Hombres-Hora), tiempo y costo de desarrollo. Los modelos empricos de estimacin de costos de software cumplen ste propsito. La estimacin de recursos puede hacerse en el mbito de proyecto, de fases y de actividades y tareas. Desarrollo de Itinerario del Proyecto. El itinerario del proyecto se confecciona distribuyendo el esfuerzo estimado dentro del marco de tiempo establecido. El itinerario debe considerar los hitos del proyecto.

1.3 Plan del Proyecto de Desarrollo de Software.

Como se mencion anteriormente, el Plan del Proyecto es el resultado principal del proceso de planificacin. Este plan existe slo cuando est documentado, distribuido, entendido y comprometido. El contenido bsico del plan del proyecto se indica en la Figura

La Descripcin del Proyecto proporciona las caractersticas generales de ste. La Organizacin refleja la forma en que el grupo de proyecto ha sido estructurado para llevar a cabo el trabajo y los responsables de las funciones clave. Los Productos a Entregar incluyen los documentos u otro tipo de producto, con compromiso de entrega al usuario o a otros grupos de trabajo interno del proyecto, as como los responsables de la entrega. El Calendario comprende tanto las estimaciones realizadas para confeccionar y justificar el itinerario del proyecto, como ste mismo.

1.3.1 Para qu se usa el plan del proyecto?

Los proyectos de Desarrollo de Software involucran a diversos participantes y cada uno de ellos da un uso distinto al plan del proyecto, ver Tabla.

Tabla 2.1: Uso del Plan del Proyecto.

1.4 Fallas en la Planificacin.

Los problemas ms comunes que enfrentan hoy en da los proyectos de desarrollo de software, tales como: retrasos en la entrega del producto final, aumento de los costos de desarrollo y mantenimiento y escasa calidad del software, se deben principalmente a una mala o escasa planificacin. Las principales causas de las fallas en la planificacin de proyectos de Desarrollo de Software son las siguientes: Inadecuada definicin del proyecto. Comprensin errnea del problema. Desconocimiento o inexperiencia de cmo planificar. Incumplimiento del ciclo de planificacin. Escasa negociacin de compromisos con el usuario al inicio del proyecto Definicin incompleta de los requerimientos. Estimaciones optimistas. Supuestos y restricciones del proyecto invlidos o no verificados. Aplicacin errnea o no-utilizacin de la informacin histrica de la organizacin. Mala administracin del proyecto. Fallas en el uso de los planes. Carencia de control de cambios. Escasa motivacin. Estilo errneo de liderazgo. Carencia de control y gestin. Organizacin errnea del grupo de trabajo.

1.5 Especificacin de Requerimientos.

La especificacin es el resultado del proceso de planificacin y puede ser vista como un proceso de representacin. La ejecucin del plan concluye en la instanciacin de un producto o proceso en particular. La especificacin del producto describe la visin externa del producto. La especificacin del proceso describe cmo realizar un determinado proceso. La especificacin de requerimientos es una descripcin detallada y precisa de la funcionalidad del sistema teniendo en cuenta las restricciones del mismo. Generalmente, la especificacin de requerimientos sirve como base para el contrato entre los desarrolladores y el cliente. Como ejemplo, la especificacin del diseo de Software. Esta puede contener: La especificacin del tipo de producto de entrada (producto de los requerimientos), incluyendo una sintaxis formal y descripcin semntica para el documento de requerimientos (ANSI / IEEE-Std-830). La especificacin del tipo de producto de salida (producto del diseo), incluyendo una sintaxis formal y la descripcin semntica para el documento de diseo. La especificacin del tipo de proceso (proceso de diseo), incluyendo una pauta para el uso de una tcnica de diseo especfica, como Diseo estructurado o Diseo Orientado a Objetos (DOO). Esta fase trata de aclarar qu es lo que un sistema debe de hacer. Describe la funcin y el rendimiento del sistema y las restricciones que gobernarn su desarrollo. Tambin describe la informacin (control y datos) que sirve de entrada y salida al sistema. Es evidente que, en esta etapa, el sistema objetivo est sujeto a muchos cambios antes de que sea realmente implantado.

Para la especificacin Balzer y Goldman proponen ocho principios para una buena especificacin: Principio 1: Separar funcionalidad de implementacin. Las especificaciones deben describir que se desea realizar, no cmo se va a realizar. Principio 2: Se necesita utilizar un lenguaje de especificacin de sistemas orientado a procesos. Si se considera un entorno dinmico, donde los cambios afectan al comportamiento de algunas entidades, entonces los sistemas no pueden ser representados formalmente. Por lo tanto, se puede usar una descripcin orientada al proceso, en la cual la especificacin se obtiene mediante un modelo de comportamiento deseado en trminos de respuestas funcionales ante distintos estmulos del entorno. Ejemplo, Sistemas Empotrados. Principio 3: Debe abarcar el sistema del cual el software es un componente. Un sistema resulta de la interaccin de sus componentes. Slo dentro del contexto del sistema completo y de la interaccin entre sus partes puede ser definido el comportamiento de un componente especfico. Principio 4: Debe abarcar el entorno en el cual opera el sistema. Se debe especificar el entorno en el cual el sistema opera e interacta. Es necesario reconocer que el propio entorno es un sistema compuesto de objetos que interactan, pasivos y activos. Con ello se permite especificar la interfaz del sistema.

Principio 5: Debe ser un modelo cognitivo. La especificacin debe ser un modelo cognitivo, en vez de un modelo de diseo o de implementacin, debe describir un sistema tal como es percibido por su comunidad de usuarios y los objetivos que manipula deben corresponderse con objetivos reales de dicho dominio. Principio 6: La especificacin debe ser operacional. La especificacin debe ser completa y lo suficientemente formal para que pueda usarse para determinar si una implementacin propuesta satisface la especificacin, en casos de prueba elegidos arbitrariamente. Principio 7: La especificacin debe ser tolerable con la incompletitud y ampliable. La especificacin nunca est totalmente completa ya que el entorno en el que existe es demasiado complejo para esto, por lo que la especificacin es una abstraccin de alguna situacin real o imaginada. Las herramientas de anlisis que apoyan y prueban la especificacin deben ser capaces de tratar con la incompletitud. Esto debilita el anlisis. Principio 8: Debe ser localizada y dbilmente acoplada Los principios anteriores tratan con la especificacin como una entidad esttica. Aun cuando la especificacin debe servir como base al diseo y la implementacin, no es un objeto esttico sino ms bien dinmico ya que sufre considerables modificaciones. Estas modificaciones se presentan tres actividades: formulacin, desarrollo, y mantenimiento.

1.5.1 Terminologa y modelo de referencia para el ciclo de vida del Software. Las especificaciones del proceso y los productos se crean para, se usan en, son afectadas por y son modificadas durante cada fase en particular. Las fases de acuerdo al modelo adoptado son: necesidades del Software, requerimientos del cliente, requerimientos del diseador, diseo del Software y construccin. Se pueden incluir otras fases: verificacin y validacin, integracin, mantenimiento y entrenamiento.

El modelo de referencia es el que se muestra en la Figura 2.2, en la columna de la izquierda. Aqu se distinguen los siguientes tipos de productos:

Preguntas para cada etapa del Ciclo de Vida Estndar

CAPITULO III

1.5.2 De la especificacin del Software Propsito y Contexto. La especificacin describe todas las caractersticas importantes de un producto o proceso particular en algn formato. Las caractersticas deseables, as como el formato adecuado para representarlas, estn determinadas por el propsito y contexto del tipo dentro del proyecto de desarrollo de Software.

Perspectiva del producto. Las especificaciones estn dirigidas a crear los productos del ciclo de vida (que son los productos del proyecto) a satisfaccin del usuario. Se caracterizan los tipos de productos por aplicacin y requerimientos de calidad.

Tipo de Aplicacin. El tipo de aplicacin tiene un fuerte impacto en los productos y procesos que necesitan ser especificados. Las posibles clasificaciones son basadas en las caractersticas de los flujos de control del Software (secuencial, concurrente, tiempo real), o basadas en la aplicacin (comercial, sistemas, control de procesos, cientfica, integrada).

Requerimientos de calidad. Estas caractersticas tienen impactos en los aspectos que deben ser especificados y en sus atributos. Algunas caractersticas posibles son: confiabilidad, correctitud, tolerancia a fallas, mantenibilidad, portabilidad, amigabilidad, disponibilidad. Perspectiva del proceso. Se caracteriza en trminos del modelo de ciclo de vida y las fases individuales. Los modelos del ciclo de vida de un proyecto se analizan con mayor detalle en el Anexo B. 1.5.3 Procesos y productos del ciclo de vida. Comunicacin. La existencia de las especificaciones permite que los miembros del equipo alcancen un consenso acerca de sus roles, haciendo explcitos los objetivos, contexto y procedimientos del proyecto. Son un medio para ensear y entrenar al personal. Creacin de productos. Muchas de las tareas de un proyecto estn orientadas a crear, en una forma trazable, instancias de un tipo de producto en otro (por ejemplo, un producto del diseo a partir de los requerimientos del Diseador). Las especificaciones explcitas para los tipos de productos y los procesos creativos, ayudan a guiar y controlar las tareas. Si todas las especificaciones son completas y formales, el producto deseado puede ser creado automticamente.

Modificacin de productos y procesos. Los proyectos de Software deben adaptarse oportunamente a los cambios. Un cambio o aumento de requerimientos durante el mantenimiento requiere modificar productos existentes, cambiando o no las especificaciones del producto. El cambiar el proyecto o las caractersticas ambientales, ya sea agregando nuevo personal o introduciendo nueva tecnologa, requiere modificar los procesos existentes y posiblemente las especificaciones subyacentes. La existencia de especificaciones explcitas del producto y el proceso, permite incorporar cambios en forma sistemtica.

Productos de validacin y verificacin. El propsito de la V&V es demostrar que algn producto del ciclo de vida, el cdigo por ejemplo, es consistente con el producto del ciclo de vida de tipo diferente, el producto del Diseo por ejemplo. Este tipo de chequeo cruzado entre productos se facilita si existen especificaciones explcitas. Certificacin de cumplimiento a lo planificado. La certificacin de calidad del Software (SQA) se refiere a la certeza de que el desarrollo de Software se realiza de acuerdo al plan. Mucho del trabajo de SQA es comparar los productos de Software y los procesos con sus especificaciones. Es importante tener en cuenta los estndares.

Perspectiva del personal. Las especificaciones se crean o son usadas por diferentes audiencias que juegan diversos roles en el proyecto. Aunque algunas especificaciones estn dirigidas para ser usadas por mquinas, las personas deben comprenderlas. Las personas que participan en un proyecto de software son:

Cliente. Usuario final. Sub contratista. Analista de requerimientos. Ingeniero de especificacin. Diseador. Codificador. Personal de Verificacin y Validacin. Personal de SQA (Software Quality Assurance). Personal de SCM (Software Configuration Management) Personal de Mantenimiento Gerente.

Es por esto que los documentos deben ser elaborados con tal claridad, que toda persona que lo lea y analice, debe entender los mismos requerimientos. En otras palabras la documentacin debe ser clara, completa y precisa.

Contenido. El contenido se caracteriza por aquellos aspectos y atributos necesarios para el producto o proceso.

Aspectos especiales. Se requieren algunas definiciones previas para caracterizar el contenido tanto del producto como del proceso. Dinmica. Caracterstica relativa al uso. En un proceso pueden ser capturadas durante su ejecucin, por ejemplo, el conjunto de decisiones tomadas por el diseador o datos histricos sobre la cantidad de tiempo requerida para el diseo en proyectos pasados. Esttica. Caractersticas de un objeto relativo a su representacin. Las caractersticas estticas de un proceso tienen que hacerse durante su especificacin (los pasos en un proceso de Diseo) Los aspectos estticos en un producto se describen en el producto en s y en sus especificaciones (estructura de datos o estructuras de control algortmicas). Funcionales. Caractersticas de un objeto de cualquier tipo relativo a sus requerimientos de funcionamiento. (funciones como almacenar y recuperar). No funcionales. Se identifican al analizar cmo son provistos los servicios por el objeto (una de las funciones del producto debe ser provista en un tiempo menor que t, el producto del diseo debe ser obtenido para un determinado proceso dentro de un lapso de tiempo y presupuesto dado). Externa. Caracterstica de un objeto visto como caja negra. Interna. Caracterstica de un objeto visto como caja blanca. Se utilizarn estas definiciones para caracterizar y explicar aspectos del producto o proceso que se desean establecer en las especificaciones. Comportamiento (externo, dinmico): La respuesta externa observable del producto o proceso frente a un estmulo estando en uso real. Puede incluir estados externos observables, salidas o condiciones de borde en la validez de entradas y estados. Interfaces (externa, esttica): La estructura de la frontera entre el producto o proceso y su ambiente. Flujo (interno, dinmico): La dinmica interna de un producto o proceso en uso. Esto puede incluir los flujos de control, data, e informacin entre las unidades estructurales del producto o proceso. Estructura (interna, esttica): La organizacin de un producto o proceso en partes interactuantes. Incluye la descomposicin en unidades bsicas. La estructura de datos, algortmico, o de arquitectura, as como las interfaces internas entre superestructuras, es de inters.

Atributos. En general cada uno de los aspectos anteriores puede ser representado en una variedad de formas. El propsito y contexto del producto o tipo de proceso de inters, requieren una forma adecuada para mostrar ciertos atributos.

Por ejemplo, si el flujo de datos de un producto de diseo necesita ser validado, se puede especificar que su representacin necesita exhibir los atributos de consistente y ejecutable.

Representacin. Ciertos aspectos del Software deben ser representados de manera de exhibir los atributos deseados. El formato de representacin usado se basa en modelos y lenguajes. Los modelos permiten la formulacin de aspectos de inters. Los lenguajes permiten un reflejo fiel de esos modelos en una forma tal que muestra los atributos deseados. Algunos modelos son: Modelos funcionales. Input - output, algebraicos, axiomticos. Modelos de estado finito. Cartas de estado. Modelos de estmulo respuesta. Modelos de redes de Petri. Modelos de estructura de datos. Modelos de flujo de informacin. Modelos de estructura de datos. Modelos entidad relacin. Modelos relacionales.

Lenguajes. Se distinguen entre Formales, semiformales e informales. Hay diferentes paradigmas de lenguajes: imperativo, declarativo u orientado a los datos. La eleccin del lenguaje se acota con el problema, las habilidades del equipo de desarrollo y los requerimientos especficos del cliente.

Soporte. Es necesario tener un soporte eficaz para crear las especificaciones.

1.5.4 Lenguaje Unificado de Modelamiento (UML) Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Su aplicacin est en entender, disear, configurar, mantener y controlar la informacin sobre los sistemas a construir. UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un sistema. Un sistema se modela como una coleccin de objetos discretos que interactan para realizar un trabajo que finalmente beneficia a un usuario externo. El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de modelado e incorporar las mejores prcticas actuales en un acercamiento estndar. Las herramientas pueden ofrecer generadores de cdigo de UML para una gran variedad de lenguaje de programacin, as como construir modelos por ingeniera inversa a partir de programas existentes.

Los objetivos de UML se pueden resumir en: Ser un lenguaje de modelado de propsito general que pueden usar todos los modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. No pretende ser un mtodo de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una slida arquitectura para resolver requisitos dirigidos por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribucin, as como tambin los mecanismos de la ingeniera de software, como son la encapsulacin y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propsito general. Imponer un estndar mundial. La Arquitectura es de cuatro capas, definida a fin de cumplir con la especificacin Meta Object Facility del OMG : Meta-meta modelo: define el lenguaje para especificar meta modelos. Meta modelo: define el lenguaje para especificar modelos. Modelo: define el lenguaje para describir un dominio de informacin. define un dominio de informacin especfico. Objetos de usuario:

Representacin de UML UML se encuentra diseado para dibujar los esquemas en superficies bidimensionales, considerando que algunas formas corresponden a proyecciones tridimensionales en el plano bidimensional. Hay cuatro clases de construcciones grficas que se usan en la notacin de UML: conos, smbolos bidimensionales, rutas y cadenas.

Un icono es una figura grfica con un tamao y forma fijos. Pueden aparecer dentro de smbolos de rea, como terminales en las rutas o como smbolos independientes que puedan o no conectar con las rutas.

Los smbolos de dos dimensiones tienen alto y ancho variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros smbolos. Muchos de ellos estn divididos en compartimientos similares o de tipos diferentes.

Las rutas se conectan con los smbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas. Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales.

Las cadenas presentan varias clases de informacin en una forma "no analizada", UML asume que cada uso de una cadena en la notacin tiene una sintaxis por la cual pueda ser analizada la informacin del modelo. Las cadenas pueden existir como el contenido de un cuadro, como elementos en las listas, como etiquetas unidas a los smbolos o a las rutas, o como elementos independientes en un diagrama.

Sobre la base de las definiciones anteriores, UML contempla una serie de diagramas que ayudan al desarrollo. La tabla siguiente, seala los diagramas de acuerdo al rea particular.
AREA VISTA Vista Esttica DIAGRAMA Diagrama de Clases CONCEPTOS PRINCIPALES Clase, asociacin, generalizacin, dependencia, realizacin, interfaz. Casos de Uso Caso de Uso, actor, Asociacin, extensin, generalizacin. Componente, interfaz, dependencia, realizacin. Nodo, componente, dependencia, localizacin. Estado, evento, transicin, accin. Estado, actividad, transicin, determinacin, divisin, unin. Interaccin, objeto, mensaje, activacin. Colaboracin, interaccin, rol de colaboracin, mensaje. Paquetes, subsistema, modelo. Restriccin, estereotipo, valores, etiquetados.

Vista de Casos de Uso Estructural Vista de Implementacin

Diagramas de Casos de Uso

Diagrama de Componentes

Vista de Despliegue

Diagrama de Despliegue

Vista de Estados de Mquina

Diagramas de Estado

Vista de Actividad Dinmica

Diagramas de Actividad

Diagramas de Secuencia Vista de Interaccin Diagramas de Colaboracin Gestin de Modelo Extensin de UML

Vista de Gestin de Modelo

Diagramas de Clases

Todas

Todos

Diagrama UML

1.6 Metodologa de Desarrollo de Productos de Software

La metodologa de desarrollo a estudiar, est definida en trminos de dos procesos que cubren la realizacin de proyectos:

Proceso de Definicin del Proyecto

 Proceso de Desarrollo de Software

El proceso de Definicin del Proyecto comprende las actividades de la Ingeniera de Sistemas necesarias para establecer las bases del proyecto a realizar. El proceso de Desarrollo de Software est enmarcado dentro de un modelo de desarrollo (Modelo Espiral, por ejemplo) que resulta ser altamente dinmico y flexible, ya que facilita el desarrollo de diversos tipos de productos de software, permite la incorporacin de tcnicas modernas de ingeniera de software, no presenta rigidez frente a los cambios y puede utilizarse para desarrollar un producto de software completo o por componentes individuales. 1.6.1 Proceso de Definicin del Proyecto El objetivo del proceso de definicin del proyecto est orientado a establecer las bases del proyecto. Est compuesto por tres actividades:

Identificacin de Necesidades Objetivo: Identificar y estudiar las necesidades del usuario a fin de establecer el origen del problema, objetivos, alcances y restricciones del sistema computacional a construir.

Desarrollo de Alternativas de Configuracin del Sistema Computacional

Objetivo: Establecer las posibles configuraciones del sistema computacional concordantes con los objetivos, alcances y restricciones establecidos en la actividad anterior. Estudio de Prefactibilidad del Proyecto Objetivo: Evaluar la factibilidad de la implantacin de las alternativas de configuracin del sistema computacional propuestas.

1.6.2 Proceso de Desarrollo de Software El objetivo de este proceso es transformar las necesidades del usuario en un producto de software aprobado y certificado para su operacin. El proceso de desarrollo est compuesto por las siguientes fases:

Definicin de Requerimientos

Diseo

Codificacin

Pruebas

Instalacin

1.7 Herramientas de Apoyo al Proceso de desarrollo

En la siguiente tabla se mostraran las etapas y las herramientas que las apoyan.

Palabras
Prefactibilidad Supone un anlisis preliminar de una idea para determinar si es viable convertirla en un proyecto. El concepto suele emplearse en el mbito empresarial y comercial. Bidimensional Es algo que tiene dos dimensiones, por ejemplo, ancho y largo, pero no profundidad. Los planos son bidimensionales, y slo pueden contener cuerpos unidimensionales o bidimensionales.

Planificacin Es el proceso metdico diseado para obtener un objetivo determinado. En el sentido ms universal, implica tener uno o varios objetivos a realizar junto con las acciones requeridas para concluirse exitosamente. Otras definiciones, ms precisas, incluyen "La planificacin es un proceso de toma de decisiones para alcanzar un futuro deseado, teniendo en cuenta la situacin actual y los factores internos y externos que pueden influir en el logro de los objetivos" Estimacin Aprecio y valor que se da y en que se tasa o considera una cosa. Aprecio, consideracin, afecto Incompletitud
Propiedad de los sistemas lgicos en los que cualquier expresin cerrada no es derivable, dentro del mismo sistema

Consideraciones Reflexin que se hace con atencin y cuidado para formar una opinin acerca de una cosa.

Conclusiones
Una planificacin para el desarrollo de un proyecto de software es una de las actividades principales, porque por medio de esta, se establecen y se asignan actividades a los miembros del proyecto, llevando as a un producto de buena calidad y rapidez en el proceso de desarrollo. El propsito de la planificacin del proyecto es identificar el alcance del proyecto, estimar el trabajo en cuestin, y crear un cronograma del proyecto. La planificacin del proyecto comienza con los requisitos que definen el software a desarrollar. El plan del proyecto es desarrollado para describir las tareas que llevarn a la terminacin. Un paso fundamental en el desarrollo de un software es la planificacin, porque en esta etapa es donde moldeamos la estructura del mismo, por ello es importante realizar bien la misma siguiendo los pasos uno a uno.

Recomendaciones
Al momento de levantar requerimientos realizarlos de la mejor manera puesto que esto influye el modelo a usar para el desarrollo. Tener en cuenta que la planificacin es aplicable a todo tipo de proyecto de software, su fin es el desarrollo del software de una forma ordenada. Obtener ms informacin acerca de estrategias ms tcnicas para implementar en el proyecto y sobre todo con el equipo de trabajo, ya que esto se realizaba de manera emprica. A pesar de tener experiencia en el desarrollo de una Planeacin es fundamental que el Tutor est disponible para consultar las dudas que tenga el grupo de trabajo. Que tanto el grupo como cada uno de los integrantes del equipo de trabajo sin excepcin, sean responsables de su trabajo y cumplan con sus avances en la fechas establecidas

F.O.D.A
Fortaleza:
Considerar el Uso de Internet Saber la importancia del tema investigado Conocer nuevos conceptos

Oportunidades:
Desarrollar mejores tcnicas de entendimiento Conocer la planificacin de proyectos Analizar los conceptos abarcado en el tema investigado

Debilidades
Desconocimiento del Deber

Amenazas
Concluir la investigacin un pocas horas antes de entregarla

Referencias
definicion.de. (21 de 11 de 2013). Obtenido de definicion.de: http://definicion.de/gestion/ definicion.de. (21 de 11 de 2013). Obtenido de definicion.de: http://definicion.de/prefactibilidad/#ixzz2lHbVkkt1 e-mas.co.cl. (21 de 11 de 2013). Obtenido de e-mas.co.cl: http://www.emas.co.cl/categorias/informatica/analisisyd.htm es.thefreedictionary.com. (21 de 11 de 2012). Obtenido de es.thefreedictionary.com: http://es.thefreedictionary.com/consideraciones es.wikipedia.org. (21 de 11 de 2013). Obtenido de es.wikipedia.org: http://es.wikipedia.org/wiki/Bidimensional hidrozachin.gob.ec. (12 de 10 de 2013). Obtenido de hidrozachin.gob.ec: http://hidrozachin.gob.ec/index.php/servicios/enlaces/13-empresa/hidrozachin/30estructura-organica ILOVEPDF.COM. (s.f.). setasign.de. Obtenido de setasign.de: www.setasign.com isittla12.blogspot.com. (21 de 11 de 2013). Obtenido de isittla12.blogspot.com: http://isittla12.blogspot.com/2012/11/unidad-3planificacion-del-proyecto-de.html