30

Universidad Abierta y a Distancia de Mxico

Fundamentos de Administracin

Unidad 1Autorreflexin: Etapas de la gestin de proyectos en el desarrollo de softwareAlumno: Julio Molina CarreoMatrcula: AL12501614Febrero, 2013Contenido3Presentacin

4I Ciclo de vida de un proyecto

6Inicio

6Planeacin

7Ejecucin

7Monitoreo y control

7Cierre

8El CMMI

12II Procesos del software

14III La administracin de proyectos de software

15Planificacin y calendarizacin

16Administracin del riesgo

18Administracin de personal

20Administracin de los costos de software

21Administracin de la calidad

22IV El administrador del proyecto

24V Reflexin

Presentacin

Es poco probable encontrar proyectos que se hayan completado a tiempo, con la calidad deseada y con el presupuesto planificado inicialmente; muchas veces se llega a cumplir con uno o dos de ellos con mucho esfuerzo.

En la primera dcada del siglo XXI, las empresas que desarrollan software requieren de personal calificado y certificado en la administracin de proyectos de software. Sin embargo, la educacin formal tradicionalmente se ha centrado en los aspectos tcnicos del software (formacin integral en el rea de desarrollo de software) y ha dejado la adquisicin de las habilidades de la administracin de proyectos a la escuela de la vida (participacin en proyectos hasta adquirir la experiencia suficiente).Existen varias instituciones educativas y algunas organizaciones civiles que han desarrollado cursos para que las personas interesadas en ste tema, adquieran las habilidades necesarias. A nivel internacional, la organizacin Project Management Institute (PMI) es reconocida por promover la administracin de proyectos como una carrera y por ofrecer el apoyo a nivel capacitacin y certificacin. Para ello, el PMI ha creado diversos estndares entre ellos el PMBOK Guide (Project Management Body of Knowledge), que es una gua que contiene tcnicas y conocimientos para la administracin de casi todo tipo de proyectos.Por lo anterior, es importante comprender cules son los elementos que conforman la administracin de proyectos y en particular cul es la relacin que guarda con la administracin de proyectos de software. Finalmente, es importante mantenerse actualizado tanto en las tcnicas de desarrollo de software como en las tcnicas para la administracin de proyectos de software. En Internet hay sitios que ofrecen informacin sobre calendarios de cursos referentes a la administracin de proyectos, entre ellos: http://www.liderdeproyecto.com http://www.milestone.com.mxJulio Molina CarreoMxico, febrero de 2013

I Ciclo de vida de un proyecto

Un proyecto es una secuencia bien definida de eventos con un principio y un final identificados, que se centra en alcanzar un objetivo claro. Cada proyecto crea un nico producto, servicio o resultado.Aunque de naturaleza temporal, los proyectos son un medio para el logro de las metas y los planes estratgicos de una organizacin. Los proyectos son autorizados como resultado de una o ms de las siguientes consideraciones:

Demanda del mercado.

Oportunidad estratgica.

Solicitud de un cliente.

Avance en la tecnologa.

Requisitos legales.

Los proyectos requieren de la administracin de proyectos, mientras que las operaciones (que son actividades permanentes que producen salidas repetitivas, es el da a da), requieren que la empresa se auxilie del proceso administrativo, aunque en muchas ocasiones los proyectos pueden llegar a coincidir con las operaciones de la empresa.

Las organizaciones que ejecutan proyectos normalmente los dividen en varias fases a fin de permitir una mejor administracin y un control adecuado. Existen varios modelos entre ellos el que el PMI propone con las siguientes fases:

Inicio. Son aquellos procesos que se realizan para definir un nuevo proyecto o una nueva fase de un proyecto ya existente por medio de la autorizacin para el comienzo de la fase o del proyecto. Planeacin. Son aquellos procesos que permiten establecer el alcance del proyecto, refinar los objetivos y definir el curso de accin para alcanzar los objetivos que el proyecto tiene comprometidos. Ejecucin. Son aquellos procesos realizados para completar el trabajo definido en el plan de administracin del proyecto, para satisfacer las especificaciones del proyecto. Monitoreo y control. Son aquellos procesos requeridos para realizar el seguimiento, revisar y regular el progreso y el desempeo del proyecto, identificar las reas en las que los cambios en el plan son necesarios; e iniciar los cambios correspondientes. Cierre. Son aquellos procesos realizados para terminar con todas las actividades en todos los Grupos de Procesos y dar el cierre formal del proyecto o de una fase.Colectivamente estas fases son mejor conocidas como ciclo de vida de un proyecto. La estructura en fases permite segmentar al proyecto en subconjuntos lgicos para facilitar su administracin, planificacin y control. Tanto la segmentacin en fases, el nmero de fases, y el grado de control por aplicar, depende del tamao, de la complejidad y el potencial impacto del proyecto. Independientemente del nmero de fases que contenga un proyecto, todas las fases tienen caractersticas similares.Desde hace varios decenios, la administracin de proyectos ha contribuido de manera significativa a que las organizaciones puedan planear, dirigir y sobre todo controlar mejor sus recursos de manera estructurada y ptima. Esta forma de trabajo permite encarar retos antes insuperables por la administracin tradicional. Con esta filosofa se genera creatividad, iniciativa y la delegacin de autoridad entre los miembros del equipo del proyecto y hace trabajar en conjuncin recursos multidisciplinarios para lograr un bien comn.

Antes de comenzar un proyecto, se debe determinar su objetivo. Un objetivo especfico clarifica el mbito del proyecto, las personas afectadas y el periodo de tiempo.

Con la administracin de proyectos se aplican los conocimientos, habilidades, herramientas y tcnicas para cumplir con los requerimientos con los requerimientos de los proyectos; esto requiere del conocimiento y de la administracin efectiva de los procesos correspondientes.Inicio

En este proceso se define el alcance inicial del proyecto. Se identifican a las personas interesadas (stakeholders). Si el administrador del proyecto an no ha sido asignado, este es el momento. Se genera el Acta de Constitucin del Proyecto (ACP).Por lo general, cuando se permite la participacin de los clientes y de otros interesados, es ms probable la existencia de la responsabilidad compartida, la aceptacin de los entregables de este proceso y la satisfaccin de los clientes.Planeacin

Este proceso consiste en todas aquellas actividades orientadas a:

El establecimiento del esfuerzo total necesario.

Definir y refinar los objetivos. Desarrollar el curso de accin requerido para alcanzar esos objetivos.

En este proceso se realiza el plan de administracin del proyecto y aquellos documentos que se utilizarn para llevar a cabo el proyecto. Los documentos pretenden explorar los siguientes aspectos:

El alcance.

Los tiempos.

Los costos.

La calidad.

La comunicacin.

Los riesgos.

Las contrataciones.

As, el plan de administracin del proyecto se convierte en la fuente de informacin primaria pues es donde se visualiza la planificacin, la ejecucin, el monitoreo y control, y el cierre del mismo. Para este proceso, la naturaleza multidimensional de la administracin de proyectos crea ciclos con retroalimentacin para anlisis adicionales.

Ejecucin

Este proceso consiste en todas las actividades necesarias para completar el trabajo definido en el plan del proyecto, con el objetivo de cumplir con las especificaciones del proyecto. Estas actividades incluyen aquellas que corresponden a la coordinacin de los recursos disponibles, as como la integracin y desempeo de las actividades establecidas en el plan del proyecto.En este proceso se realizan actualizaciones al proyecto y en particular a la lnea base.

Monitoreo y control

En este proceso se realizan las siguientes actividades que permiten hacer el seguimiento, la evaluacin, ajustar el progreso y la ejecucin del proyecto. Se identifican las reas en las que se necesita realizar los cambios al plan del proyecto. El seguimiento continuo proporciona una visin de la salud del proyecto e identifica las reas que requieren atencin adicional.Cierre

En este proceso se realizan todas aquellas actividades que permiten dar fin a todas las actividades de los otros procesos del proyecto con el objetivo de dar por terminado al proyecto y cumplir con las obligaciones contractuales con el cliente. Se verifica que todos los procesos definidos en el plan se hayan completado de manera apropiada y establece de manera formal el trmino del proyecto.Al cierre del proyecto se presenta lo siguiente:

Se obtiene la aceptacin del cliente.

Se lleva a cabo una fase de revisin final.

Se documentan las lecciones aprendidas.

Se almacenan todos los documentos relevantes para ser utilizados como datos histricos.

El CMMIEl anterior es uno de los modelos existentes para identificar el ciclo de vida de un proyecto y para su administracin, pero no es el nico; existen otros modelos. Uno de ellos es el conocido como Capability Maturity Model Integration (CMMI) El CMMI es un modelo de madurez de mejora de los procesos para el desarrollo de productos y de servicios, que consiste en las mejores prcticas que tratan las actividades de desarrollo y de mantenimiento que cubren el ciclo de vida del producto, desde la concepcin a la entrega y el mantenimiento.En la dcada de los 30, Walter Shewhart comenz a trabajar en la mejora de procesos introduciendo los principios del control estadstico de la calidad [Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming [Deming 1986], Phillip Crosby [Crosby 1979] y Joseph Juran [Juran 1988]. Watts Humphrey, Ron Radice y otros los ampliaron y comenzaron a aplicarlos al software en su trabajo en IBM y en el Software Engineering Institute (SEI) [Humphrey 1989]. En el libro de Humphrey Managing the Software Process se describen los principios y conceptos bsicos en los cuales se basan muchos de los modelos de madurez y de capacidad (CMMs).

El SEI tom la premisa de la administracin de proceso y defini los CMMs que lo reflejan. La adhesin a este principio se encuentra en el seno de los movimientos de calidad de todo el mundo, como lo muestra la ISO/IEC (International Organization for Standardization/International Electrotechnical Comission) en su conjunto de estndares.Desde 1991, los CMM se han desarrollado para innumerables disciplinas. Algunas de las ms notables comprenden modelos para la ingeniera de sistemas, la ingeniera del software, la adquisicin del software, el desarrollo y la gestin del personal, y el desarrollo integrado de productos y procesos (IPPD).El proyecto de integracin de CMM ha sido realizado para regular el problema de utilizar mltiples CMM. La misin inicial del equipo del producto CMMI (CMMI Product Team) fue combinar tres modelos fuente:

1. SW-CMM (Capability Maturity Model for Software), versin v2.0 draft C [SEI 1997b]

2. SECM ( Systems Engineering Capability Model) [EIA 1998]

3. IPD-CMM (Integrated Product Development Capability Maturity Model), version v0.98 [SEI 1997a]Estos tres modelos fuente fueron seleccionados debido a su extensa adopcin por las comunidades de desarrollo de sistemas y de software y tambin porque proponen diversos acercamientos a la mejora de procesos en el seno de una organizacin.El CMMI le permite aproximarse a la mejora de procesos y a las evaluaciones usando dos representaciones diferentes: Continua. Esta representacin permite a una organizacin seleccionar un rea de proceso (o un grupo de reas de proceso) y mejorar los procesos relacionados con sta.

Por etapas. Esta representacin utiliza conjuntos predefinidos de reas de proceso para definir un camino de mejora para una organizacin. Este camino de mejora se caracteriza por diversos niveles de madurez. Cada nivel de madurez proporciona un conjunto de reas de proceso que caracterizan diferentes comportamientos organizativos.Los componentes del modelo se agrupan en tres categoras:

Requerido. Describen lo que una organizacin debe realizar para satisfacer un rea de proceso. Este logro se debe implementar de forma visible en los procesos de una organizacin. Los componentes requeridos en CMMI son las metas especficas y los objetivos genricos. La satisfaccin de objetivos se utiliza en las evaluaciones como base para determinar si un rea de proceso ha sido realizada y satisfecha.

Esperado. Describen lo que una organizacin puede implementar para lograr un componente requerido. Los componentes esperados guan a los que implementan mejoras o realizan evaluaciones. Los componentes esperados incluyen las prcticas especficas y las prcticas genricas.

Informativo. Proporcionan detalles que ayudan a las organizaciones a comenzar a pensar en cmo aproximarse a los componentes requeridos y esperados. Las sub-prcticas, los productos de trabajo tpicos, las ampliaciones, las elaboraciones de las prcticas genricas, los ttulos de metas y prcticas, las notas de metas y prcticas, y las referencias son ejemplos de componentes informativos del modelo.reas de proceso

Un rea de proceso es un grupo de prcticas relacionadas en un rea que, cuando se implementan de forma conjunta, satisfacen un grupo de objetivos considerados importantes para la mejora en ese rea. Hay 22 reas de proceso: Anlisis causal y resolucin (CAR).

Gestin de configuracin (CM).

Anlisis de decisiones y resolucin (DAR).

Gestin integrada del proyecto + IPPD (IPM + IPPD)1.

Medicin y anlisis (MA).

Innovacin y despliegue en la organizacin (OID).

Definicin de procesos de la organizacin + IPPD (OPD + IPPD)1.

Enfoque en procesos de la organizacin (OPF).

Rendimiento del proceso de la organizacin (OPP).

Formacin organizativa (OT).

Integracin de producto (PI).

Monitorizacin y control del proyecto (PMC).

Planificacin de proyecto (PP).

Aseguramiento de la calidad de proceso y de producto (PPQA).

Gestin cuantitativa de proyecto (QPM).

Desarrollo de requerimientos (RD).

Gestin de requerimientos (REQM).

Gestin de riesgos (RSKM).

Gestin de acuerdos con proveedores (SAM). Solucin tcnica (TS).

Validacin (VAL).

Verificacin (VER).II Procesos del softwareUn proceso del software es un conjunto de actividades que conducen a la creacin de un producto de software. Los procesos de software suelen ser complejos y dependen de las personas que toman decisiones. No existe un proceso ideal, y muchas organizaciones han desarrollado su propio enfoque; sin embargo, algunas actividades fundamentales son comunes entre todos ellos:

Especificacin del software. Especificacin del software o ingeniera de requerimientos, es el proceso de comprensin y definicin de qu servicios se requieren del sistema y de identificacin de las restricciones del funcionamiento del mismo. Los errores en esta etapa originan inevitablemente problemas posteriores en el diseo e implementacin del sistema. En los mtodos giles los requerimientos se desarrollan de forma incremental conforme a las prioridades del usuario y la obtencin de requerimientos viene de los usuarios que forman parte del equipo de desarrollo. Diseo e implementacin del software. Un diseo es una descripcin de la estructura del software que se va a implementar. Se debe producir software que cumpla con las especificaciones; una especificacin del sistema se convierte en un sistema ejecutable. El resultado final del proceso son especificaciones precisas de los algoritmos y estructuras de datos a implementarse. Validacin del software. Se debe validar el software para asegurar que hace lo que el cliente desea. Se utiliza para mostrar que el sistema se ajusta a las especificaciones cumpliendo las expectativas del usuario. Evolucin del software. El software debe evolucionar para cubrir las necesidades cambiantes del cliente. Se pueden hacer cambios al software en cualquier momento durante o despus del desarrollo del sistema.Por otra parte, un modelo del proceso del software es una representacin abstracta de un proceso de software que se pueden utilizar para explicar diferentes enfoques para el desarrollo del software. Algunos de estos procesos son:

El modelo en cascada. Considera las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin, y los representa como fases separadas del proceso. Una ventaja importante consiste en la produccin de la documentacin en cada fase, mientras que una desventaja es no poder dar una respuesta rpida a los cambios a los nuevos requerimientos del cliente. Desarrollo evolutivo. Este enfoque enlaza las actividades de especificacin, desarrollo y validacin. La documentacin no se puede generar fcilmente, pero el desarrollo del sistema es ms rpido y se le puede presentar al cliente al poco tiempo de haber iniciado con la etapa de especificacin. Ingeniera del software basada en componentes. Este enfoque se basa en la existencia de un nmero significativo de componentes reutilizables (software que ya se encuentra desarrollado por terceros). El proceso del desarrollo del sistema se enfoca en integrar estos componentes en el sistema ms que en desarrollarlos desde cero. La ventaja principal es la reduccin de software a desarrollarse reduciendo as los costos.Las cuatro actividades bsicas de los modelos del proceso de software se organizan de manera distinta en diferentes procesos del desarrollo; en el enfoque en cascada estn organizadas en secuencia, mientras que en el desarrollo evolutivo se entrelazan. Cmo se llevan a cabo estas actividades, depende del tipo de software, de las personas y de la estructura organizacional implicada. No hay una forma correcta o incorrecta de organizar estas actividades.

Estos modelos de procesos genricos se utilizan ampliamente en la prctica actual de la ingeniera de software. A menudo se utilizan juntos; de hecho, el proceso conocido como RUP (Rational Unified Process) combina elementos de todos estos modelos.

Por otra parte, un mtodo de ingeniera de software es un enfoque estructurado para el desarrollo de software cuyo propsito es el de facilitar la produccin de software de alta calidad y a bajo costo. Algunos ejemplos son: Anlisis estructurado (De Marco, 1978), JSD (Jackson, 1983), UML (Booch et al., 1999; Rumbaugh et al., 1999).

III La administracin de proyectos de software

La administracin de proyectos de software es una parte de la ingeniera del software y es necesaria debido a que en muchas ocasiones, sino es que siempre, existen restricciones de tiempo y presupuesto. Los administradores de proyectos de software son la columna vertebral de una larga red de informacin y son responsables de conducir el proyecto hacia un final con xito. Las principales responsabilidades del administrador son:

La planificacin y la fijacin de los tiempos del desarrollo de los proyectos. La supervisin del trabajo para asegurar que se lleva a cabo conforme a los estndares requeridos.

La supervisin del progreso para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto.

Los administradores de proyectos de software hacen el mismo tipo de trabajo que otros administradores de proyectos; sin embargo, la ingeniera de software es diferente en varios aspectos, entre ellos: El producto es intangible. El administrador de un proyecto de construccin puede ver el producto mientras se est desarrollando. Si hay un desfase en el calendario, el efecto en el producto es visible. El software es intangible. No hay procesos de software estndar. En muchas de las disciplinas de la ingeniera hay un largo historial de conocimientos para la prueba y verificacin de procesos. Sin embargo, los procesos de software varan de una organizacin a otra. Los proyectos grandes son nicos. Por lo general, los proyectos grandes de software son diferentes de proyectos previos; por lo que aun cuando se cuente con gran experiencia, sta no es suficiente para anticipar los problemas. Adems, los rpidos cambios en la tecnologa y los nuevos paradigmas de programacin hacen parecer obsoleta la experiencia previa. Las lecciones aprendidas en esas experiencias pueden no ser transferibles a los nuevos proyectos.Por lo anterior, no es de sorprender que algunos proyectos de software se retrasen, sobrepasen el presupuesto y/o se entreguen fuera de tiempo.

La administracin de proyectos de software contiene varias etapas, entre ellas:

Planificacin.

Calendarizacin.

Administracin del riesgo.

Administracin de personal.

Administracin de los costos de software.

Administracin de la calidad.

Planificacin y calendarizacinEsta etapa se realiza lo siguiente:

Valorar las restricciones que afectan al proyecto. Por ejemplo: fecha de entrega, recursos humanos disponibles, presupuesto, etctera.

Estimar los parmetros del proyecto. Estructura, tamao y distribucin de funciones (Estructura de descomposicin del trabajo, EDT). Definir Hitos. Estos son los puntos finales de una actividad del proceso del software. Para establecer los hitos el proceso del software se debe dividir en actividades bsicas con sus salidas correspondientes. Definir entregables.

Preparar el calendario del proyecto. Es una de las tareas ms difciles; se estima el tiempo y los recursos requeridos para completar las actividades y se organizan en una sucesin coherente.Existen diferentes tipos de planes que dependen del tipo de metodologa que se siga para la administracin de proyectos de software; en algunas organizaciones el plan del proyecto es un nico documento que incluye todos los diferentes tipos de planes (Tabla 1). En otros casos, el plan se refiere nicamente al proceso de desarrollo.PlanDescripcin

Plan de calidadDescribe los procedimientos y los estndares de calidad que se utilizarn en un proyecto.

Plan de validacinDescribe el enfoque, los recursos y la programacin utilizados para la validacin del sistema

Plan de administracin de configuracionesDescribe los procedimientos para la administracin de configuraciones y las estructuras a utilizar.

Plan de mantenimientoPredice los requerimientos del mantenimiento del sistema, los costos del mantenimiento y el esfuerzo requerido.

Plan de desarrollo del personalDescribe cmo se desarrollan las habilidades y experiencia de los miembros del equipo del proyecto.

Tabla 1. Tipo de planComo resultado de las actividades anteriores, se obtiene el Plan del proyecto, que por lo general se presenta con una grfica de barras y su red de actividades.

La grfica de barras muestra quin es el responsable de cada actividad y cundo debe comenzar y finalizar sta; mientras, la red de actividades muestra las dependencias entre las diferentes actividades del proyecto.

Actualmente existen diferentes herramientas de software para la administracin de proyectos, entre ellas: Microsoft Project, Microsoft Project Server, JIRA, etctera.

Si el proyecto contina, se inicia con el ciclo Revisin-Actualizacin hasta el trmino del mismo. Si el proyecto se retrasa, se tienen que renegociar con el cliente las restricciones del mismo y las entregas. Si la negociacin no tiene xito, se debe hacer una revisin tcnica del plan con el propsito de encontrar un enfoque alternativo que se ajuste a las restricciones del proyecto y que cumpla con las metas del calendario.

Administracin del riesgo

En el plan del proyecto se deben identificar los riesgos que podran afectar al calendario del proyecto o a la calidad del software a desarrollar, y en consecuencia emprender las acciones correspondientes para evitar esos riesgos; se debe comprender el impacto de stos en el proyecto, en el producto y en el negocio. Aunque los riesgos de un proyecto dependen del proyecto mismo y del entorno donde se desarrolla, muchos riesgos son universales. La Tabla 2 muestra algunos de estos riesgos.RiesgoTipoDescripcin

Rotacin de personalProyectoPersonal con experiencia abandona el proyecto antes de que finalice.

Cambio de administracinProyectoHabr un cambio de administracin en la empresa cliente con diferentes prioridades.

No disponibilidad del hardwareProyectoEl hardware esencial para el proyecto no ser entregado a tiempo.

Cambio de requerimientosProyecto y productoHabr ms cambios en los requerimientos de lo esperado.

Retrasos en la especificacinProyecto y productoLas especificaciones de las interfaces esenciales no estarn a tiempo.

Subestimacin del tamaoProyecto y productoEl tamao del sistema se ha subestimado

Cambio de tecnologaNegocioLa tecnologa fundamental sobre la que se construir el sistema se sustituye por nueva tecnologa.

Competencia del productoNegocioUn producto competitivo se pone en venta antes de que el sistema se complete.

Tabla 2. Posibles riesgos del softwareLas etapas de la administracin del riesgo comprenden: Identificacin de riesgos. Identificar los posibles riesgos para el proyecto, el producto y el negocio.

Anlisis de riesgos. Valorar las probabilidades y consecuencias de los riesgos identificados.

Planificacin de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos.

Supervisin de riesgos. Valorar los riesgos de forma constante y revisar los planes para la mitigacin de riesgos tan pronto como la informacin de los riesgos est disponible.

Administracin de personalPor lo general el administrador del proyecto no tiene una libre eleccin del personal que trabajar en el mismo; en casos excepcionales se puede designar a las personas que mejor se adecuan a un trabajo, independientemente de sus otras responsabilidades o de las consideraciones de presupuesto. La limitacin de presupuesto restringe el nmero de costosos ingenieros con experiencia que pueden trabajar en el proyecto.

La decisin de quines sern designados para un proyecto, por lo general, se lleva a cabo utilizando tres tipos de informacin: El CV. Es la informacin suministrada por los candidatos acerca de sus conocimientos y experiencia; esta suele ser la informacin ms fiable de la que se dispone para juzgar qu candidatos son adecuados.

La entrevista. La informacin obtenida al entrevistar a los candidatos da una buena visin de qu candidatos son buenos comunicadores y cundo stos tienen buenas habilidades sociales. Sin embargo, las pruebas han demostrado que los entrevistadores son obligados a aceptar o rechazar candidatos haciendo rpidos juicios subjetivos. Por lo tanto las entrevistas no son mtodos fiables para juzgar las capacidades tcnicas.

Recomendaciones. La opinin de algunas personas que han trabajado con los candidatos puede ser objetiva cuando se conoce a la persona que hace la recomendacin. De otro modo, las recomendaciones pueden no ser ciertas, por lo que deben tener poco peso den la decisin a la hora de formar un equipo.

La Tabla 3 muestra los factores que pueden influir en la decisin al momento de seleccionar el personal para un proyecto de software. Los factores ms importantes varan dependiendo del dominio de la aplicacin, del tipo de proyecto y de las habilidades de los otros miembros del proyecto. En proyectos de larga duracin es ms importante entender los conceptos y el dominio de la aplicacin que los conocimientos especficos.Factor Explicacin

Experiencia en el dominio de la aplicacinPara desarrollar bien un sistema, los desarrolladores deben entender el dominio de la aplicacin. Es esencial que algunos de los miembros del equipo de desarrollo tengan alguna experiencia en el dominio de la aplicacin.

Experiencia en la plataformaEste factor es importante si la programacin a bajo nivel es necesaria. En otro caso, no es un atributo crtico.

Experiencia en el lenguaje de programacinNormalmente esto slo es importante para proyectos de corta duracin donde no existe tiempo suficiente para aprender un nuevo lenguaje. Mientras que aprender el lenguaje propiamente dicho no es difcil, empezar a utilizar las libreras y componentes de forma competente pueden llevar varios meses.

Habilidades para resolver problemasEsto es muy importante para ingenieros de software, los cuales tienen que resolver constantemente problemas tcnicos. Sin embargo, es casi imposible de juzgar sin conocer el trabajo del candidato.

Soporte educativoEsto provee un indicador de los fundamentos bsicos que el candidato debe conocer y de la habilidad para aprender. Este factor cada vez es ms irrelevante, puesto que los ingenieros obtienen experiencia a travs de los proyectos.

Habilidad de comunicacin Esto es importante debido a que el personal del proyecto necesita comunicarse oralmente y por escrito con los otros ingenieros, administradores y clientes.

AdaptabilidadLa adaptabilidad se valora observando las diversas experiencias obtenidas por los candidatos. Este es un atributo importante puesto que indica una habilidad para aprender.

ActitudEl personal de proyecto debe tener una actitud positiva con respecto a su trabajo y debe estar deseoso de aprender nuevas habilidades. Este es un atributo importante, pero a menudo muy difcil de valorar.

PersonalidadEste es un atributo importante pero difcil de valorar. Los candidatos deben ser razonablemente compatibles con los otros miembros del equipo. Ningn tipo de personalidad es ms o menos adecuada para la ingeniera de software.

Tabla 3. Factores que determinan la seleccin de personalAlgunas compaas prueban a los candidatos con pruebas de aptitud a la programacin y pruebas psicomtricas donde los candidatos completan una serie de ejercicios en un periodo de tiempo relativamente breve. Las pruebas psicomtricas estn dirigidas a conseguir el perfil psicolgico del candidato, indicando sus capacidades y habilidades para ciertos tipos de tareas. Se duda si las pruebas de aptitud proveen informacin til acerca de la capacidad para resolver problemas. No parece que las habilidades necesarias para la resolucin de problemas complejos sean comparables a las habilidades necesarias para completar pruebas de aptitud simples.

Administracin de los costos de softwareEn las primeras etapas del proyecto se necesitan algunas estimaciones de costos para establecer un presupuesto o para asignar el precio para el software a desarrollar para algn cliente. Existen tres parmetros involucrados:

Los costos de hardware y software.

Los costos de viajes y capacitacin.

Los costos del esfuerzo. Una vez iniciado el proyecto se deben actualizar regularmente las estimaciones de tiempo y costo. Si los gastos actuales son significativamente mayores que los estimados el administrador del proyecto debe tomar algunas decisiones. Al respecto, el administrador del proyecto tiene que estimar la productividad del personal involucrado en el proyecto de desarrollo de software. Estas estimaciones de productividad se basan en la medicin de alguno de los atributos del software y se divide el resultado entre el esfuerzo total requerido para el desarrollo.

Sin embargo, no existe una forma simple de realizar una estimacin precisa. Las estimaciones iniciales se hacen partiendo de la definicin de requerimientos del usuario que en muchas ocasiones son incompletos.En aos recientes se han introducido nuevas tcnicas y mtodos de desarrollo de software que pueden afectar las estimaciones que se basan nicamente en la experiencia; si el administrador del proyecto de software no ha trabajado con esas tcnicas, su experiencia previa no le ayudar a estimar los costos. Entre stas tcnicas se tienen las siguientes:

Sistemas orientados a objetos.

Uso de servicios web.

Uso de ERP.

Uso de paquetes de software ajenos (componentes) en lugar de desarrollar todo el software propio.

Administracin de la calidad

La calidad del software es un concepto complejo que no es directamente comparable con la calidad de la manufactura de productos. En la manufactura, la calidad viene dada por la similitud entre el producto desarrollado y su especificacin (Crosby, 1979).

La administracin de la calidad del software se divide en tres actividades principales: Garanta de la calidad. Es el proceso que define cmo lograr la calidad del software al definir o seleccionar los estndares que deben ser aplicados durante el desarrollo del software. Planificacin de la calidad. Es el proceso en el que se desarrolla un plan de calidad para un proyecto, en el que se define la calidad del software deseado y describe cmo evaluarlo. El plan de calidad depende del tamao y del tipo de sistema que se desarrolle. Control de la calidad. Es el proceso durante el cual se realiza la vigilancia del proceso del desarrollo del software para asegurar que se siguen los estndares establecidos en el proceso de Garanta de la calidad. Los pasos clave para el proceso de medicin son: Seleccionar las medidas a realizar, Seleccionar los componentes a evaluar, Medir las caractersticas de los componentes, identificar las mediciones anmalas y analizar los componentes anmalos.Un equipo independiente debe ser el responsable de la administracin de la calidad y debe mantener informado al administrador del proyecto. Es recomendable que el equipo de calidad no deba estar asociado con ningn grupo de desarrollo.IV El administrador del proyecto

Algunas de las responsabilidades del administrador de proyectos de software son:

Redaccin de la propuesta. La propuesta describe los objetivos de proyecto y cmo se llevara a cabo. Esta propuesta puede incluir: la estimacin de tiempo y costos, la justificacin de quin debe realizar el desarrollo del producto. La redaccin de la propuesta es una habilidad que se adquiere con la prctica y la experiencia. Planificacin y calendarizacin del proyecto. Se identifican las actividades, hitos y entregas de un proyecto, se establece el orden de las actividades y su duracin, se determina la manera en la que se relacionan las actividades, etctera. Es decir, se bosqueja el plan del proyecto para la consecucin de las metas.

Estimacin de costos del proyecto. Esta es una actividad que va relacionada con la estimacin de los recursos requeridos para llevar a cabo el plan del proyecto. Supervisin y revisin del proyecto. Esta es una actividad continua. El administrador del proyecto debe tener conocimiento del progreso del proyecto y comparar los costos actuales contra los planificados. Aunque no es comn, el resultado de una revisin puede tener como consecuencia la cancelacin dl proyecto. Redaccin y presentacin de informes. El administrador del proyecto es el responsable de informar a los clientes sobre el proyecto, por lo que la comunicacin efectiva tanto oral como escrita son habilidades esenciales en un buen administrador.El administrador del proyecto debe reflejar en el plan del proyecto la suficiente holgura para que las contingencias, restricciones e hitos no se tengan que negociar cada vez que se efecta el ciclo Revisin-Actualizacin.

Otro de los papeles del administrador del proyecto es motivar al personal del proyecto; motivacin significa organizar el trabajo y su entorno para estimular a las personas a trabajar de la forma ms efectiva y eficaz posible. Si las personas no son motivadas, no se interesarn en el trabajo que hacen, stas trabajarn lentamente, cometern ms errores y no contribuirn a las metas del equipo ni de la organizacin (Maslow, 1954).

V Reflexin

Cada una de las reas exploradas en las secciones anteriores forma un cuerpo de conocimientos en s mismo y forma parte de una o ms especializaciones de estudio.Es importante distinguir la aplicacin del proceso administrativo del da a da y del proceso administrativo para los proyectos. Esta distincin permite al administrador tomar en cuenta la temporalidad a la que se somete un proyecto y que es diferente a la temporalidad de las actividades continuas de una empresa.

La administracin de proyectos de software se caracteriza por estar ligado al ciclo de vida del desarrollo de software. Esto implica que se deben identificar de manera adecuada las etapas del ciclo de software y saberlas distinguir de aquellas pertenecientes a la administracin de proyectos.

Bibliografa

Colmenar, Antonio et. al. Gestin de proyectos con Microsoft Project 2007. Alfaomega Grupo Editor. Mxico. 2007. Chamoun, Yamal. Professional Project Management, The Guide. Mc-GRaw Hill Interamericana. Mxico. 2006.

Chrissis, Mary Beth et al. CMMI Gua para la integracin de procesos y la mejora de productos. Carnegie Mellon University Estados Unidos. 2006. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Cuarta edicin. Estados Unidos. 2008.

Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006. St-Pierre, Armand et. al. Microsoft Project 98, gua prctica con ejercicios. Ed. Trillas. Mxico. 2000.Document license

LICENCIA DE USO

Software para Administracin de la Base de Conocimiento KWE 2.0 para la Norma NMX-I-059-NYCE-2005 (MoProSoft)

Software para Autoevaluacin de la Norma NMX-I-059-NYCE-2005 (MoProSoft)

Esta licencia rige las condiciones de uso del Software para Administracin de la Base de Conocimiento KWE 2.0 para la Norma NMX-I-059-NYCE-2005 (MoProSoft) y del Software para Autoevaluacin de la Norma NMX-I-059-NYCE-2005 (MoProSoft) (conjuntamente el Software, salvo que se mencionen de manera separada), independientemente de su forma de acceso. Al acceder por cualquier va y/o instalar y/o usar el Software en cualquier medida, Usted expresa su consentimiento a los trminos de la presente licencia de uso (la Aceptacin). Esta licencia de uso constituye el contrato ntegro y exclusivo entre Normalizacin y Certificacin Electrnica, A.C. y Usted en relacin con los derechos de uso autorizado del Software. Para estos efectos, en el presente contrato Usted en su carcter de usuario por cualquier medio ser denominado como el Usuario, y NYCE es Normalizacin y Certificacin Electrnica, A.C., con domicilio en Avenida Lomas de Sotelo 1097, Colonia Lomas de Sotelo, C.P. 11200 en Mxico, Distrito Federal.

1. Por virtud del presente contrato de licencia de uso, NYCE otorga al Usuario el derecho de uso del Software bajo los trminos y condiciones establecidos en el presente contrato. El derecho que se otorga slo incluye el uso del Software de forma personal por parte del Usuario, para los fines para los cuales el Software est naturalmente diseado, con la funcionalidad y especificaciones originales. NYCE slo autoriza el uso del Software y/o cualquiera de sus aplicaciones o formas de operacin ntegramente en la forma proporcionada y/u operada por NYCE.

2. NYCE se reserva la titularidad y ejercicio de todos los derechos sobre el Software y/o cualquiera de sus componentes, programas y/o aplicaciones, incluyendo aqullos de propiedad intelectual y cualquier presentacin o forma de operacin, y prohbe expresamente la reproduccin permanente o provisional del Software o cualquiera de sus componentes, programas o aplicaciones, incluyendo cualquiera de sus presentaciones o formas de operacin; la traduccin, adaptacin, arreglo o cualquier otra forma de modificacin del portal o cualquiera de sus componentes, programas o aplicaciones, incluyendo la reproduccin de cualquier obra resultante; la distribucin, arrendamiento o cualquier otra forma de enajenacin y/o facilitacin a terceros o aprovechamiento por s o por terceros, directa o indirectamente bajo cualquier ttulo, diferente al uso personal exclusivo otorgado bajo los trminos y condiciones de uso establecidos en el presente contrato, as como la decompilacin y/o cualquiera proceso para revertir la ingeniera o desensamblaje, salvo autorizacin previa y por escrito de NYCE. Los derechos de uso referidos en esta licencia son los nicos concedidos por NYCE en relacin con el Software, independientemente de la forma de enajenacin por parte de NYCE y/o la forma de adquisicin por parte del Usuario, con o sin contraprestacin monetaria reclamada por NYCE y/o pagada por el Usuario.

3. El Usuario se obliga a hacer el correcto uso del Software y/o cualquiera de sus aplicaciones o formas de operacin conforme a sus propsitos naturales, y en consecuencia se obliga a no usar o intentar usar cualquier recurso relacionado con ste, directa o indirectamente para la ejecucin o intento de ejecucin de cualquier prctica contraria a los buenos usos mercantiles o a la ley, incluyendo sin limitar cualquier prctica de remisin masiva de correos electrnicos no solicitados (spamming), incluyendo aqullos que tengan como objeto o efecto el bloqueo de servidores de la red (mail bombing), as como cualquier prctica que pongan a prueba o intenten poner a prueba la seguridad o integridad del propio Software o de bienes o servidores en lnea, realizando o intentando realizar cualquier tipo de acceso o accin que no resulte estrictamente necesaria para el disfrute del Software y/o cualquiera de sus aplicaciones o formas de operacin por parte del Usuario conforme al presente contrato. La infraccin a la presente disposicin dar derecho a NYCE de dar por terminado el contrato inmediatamente. El Usuario asume la responsabilidad total y directa por todas y cualquier reclamacin que pudiera surgir con motivo de los aspectos aqu convenidos, y libera y se obliga a sacar en paz y a salvo a NYCE o en su caso indemnizarla por cualquiera responsabilidad que pudiera reclamarse a NYCE a este respecto.

4. El Usuario ser el nico y exclusivo responsable de la integridad de toda la informacin de carcter privado y/o bases de datos bajo su generacin, operacin, titularidad, manejo, tratamiento o cualquiera otra forma de posesin o detentacin, bajo cualquier ttulo. El Usuario ser el nico responsable del mantenimiento y creacin de sus propias copias de seguridad sobre cualquier informacin en su posesin, as como de la configuracin y de toda la informacin que use, publique o interacte con el Software y/o cualquiera de sus aplicaciones o formas de operacin. Asimismo el Usuario ser el responsable nico y exclusivo de la seguridad y confidencialidad de sus propias claves de acceso, teniendo la obligacin y la nica y exclusiva responsabilidad de guardarlas y custodiarlas en lugar seguro con el fin de impedir el acceso a terceros no autorizados. NYCE no efecta ninguna forma de retencin o monitoreo deliberado o voluntario de informacin que eventual, necesaria o circunstancialmente resida o transite temporalmente por bienes y/o servidores bajo el control razonable de NYCE, y en consecuencia no asume ni puede asumir responsabilidad alguna por dicha informacin en forma alguna.

5. El Usuario ser el nico y exclusivo responsable de la operacin o interaccin de mecanismos de verificacin de identidad, seguridad en lnea, o en general de seguridad informtica de cualquier tipo en relacin con el uso del Software y/o cualquiera de sus aplicaciones o formas de operacin, en la medida en que cualquiera de dichas funciones cumplan con la legislacin aplicable vigente, y no contravengan las polticas y/o procedimientos de NYCE o los trminos y condiciones de la presente licencia.

6. NYCE no es responsable por cualquier habilitacin y/o configuracin tcnica necesaria y/o conveniente para la operacin del Software por parte del Usuario. Las partes convienen y reconocen la responsabilidad de NYCE se limita a poner a disposicin del Usuario el uso del Software bajo los trminos y condiciones del presente contrato de licencia de uso, y que en consecuencia NYCE no es responsable de cualquier otro aspecto como la interoperabilidad o compatibilidad del Software y/o de cualquier de sus componentes o aplicaciones en relacin con cualquier equipo, programa, plataforma, datos, sistemas, portales o cualquier otro bien, configuraciones o informacin del Usuario y/u operados por el Usuario, as como de los posibles conflictos tcnicos que pudieran suscitarse por tales motivos, los cuales son de la responsabilidad exclusiva del Usuario.

7. En todo caso el Usuario ser responsable de forma nica y exclusiva por cualquier dao causado a la operacin del Software y/o cualquiera de sus aplicaciones o formas de operacin derivada o relacionada con la intervencin no autorizada de terceros directamente al Software y/o cualquiera de sus aplicaciones o formas de operacin o sus componentes, programas o aplicaciones, o a equipos, programas, plataformas, datos, sistemas, portales o cualquier otro bien del Usuario y/u operados por el Usuario que resulten en la generacin de conflictos y/o daos con la operacin del Software y/o cualquiera de sus aplicaciones o formas de operacin.

8. Salvo que existan causas ajenas al control de NYCE y/o que deriven de circunstancias atribuibles al Usuario y/o cualquier otro aspecto como la interoperabilidad o compatibilidad del Software y/o cualquiera de sus aplicaciones o formas de operacin, y/o de cualquiera de sus componentes o aplicaciones con cualquier equipo, programas, plataformas, datos, sistemas, portales o cualquier otro bien del Usuario y/u operados por el Usuario, NYCE declara que el Software y/o sus aplicaciones o formas de operacin operarn dentro de parmetros comercialmente razonables. Para operaciones en lnea, las partes convienen y reconocen que NYCE a su sola discrecin, podr interrumpir temporalmente la operacin del Software de forma controlada y deliberada, preferentemente en horas y/o das inhbiles, para implementar mejoras o actualizaciones o ejecutar actividades de reparacin de los medios tcnicos utilizados para su operacin, sin responsabilidad.

9. Las partes convienen y reconocen que NYCE no ofrece garanta alguna sobre el Software y/o cualquiera de sus aplicaciones o formas de operacin, ni garantiza de forma alguna la adecuacin del Software y/o cualquiera de sus aplicaciones o formas de operacin para un fin determinado o deseado o esperado por el Usuario, ni de desempeo especfico en relacin con objetivos determinados o deseados o esperados por el Usuario, de expectativas de ventas, cumplimiento de obligaciones o de cualquier otra clase, ni garanta o promesa alguna de cualquier otra naturaleza.

10. La presente licencia incluye el derecho de uso de versiones pblicas posteriores proporcionadas por NYCE. NYCE se reserva el derecho de sustituir cualquier versin del Software y/o cualquiera de sus aplicaciones o formas de operacin y/o cualquiera de sus componentes, programas y/o aplicaciones por otras ms recientes o por cualesquiera otras que NYCE estime ms convenientes a su solo juicio. Si el Usuario se negare a adoptar cualquier versin del Software y/o cualquiera de sus aplicaciones o formas de operacin y/o cualquiera de sus componentes, programas y/o aplicaciones ms recientes o cualquier otra que NYCE estime ms convenientes a su solo juicio, cualquiera de las partes tendr el derecho de dar por terminado el contrato, sin responsabilidad para NYCE.

11. Para operaciones en lnea, NYCE no ser responsable de la no-disponibilidad del Software y/o cualquiera de sus aplicaciones o formas de operacin por cualquier circunstancia tcnica o de fuerza mayor o caso fortuito, no atribuibles ni bajo la responsabilidad o control razonable de NYCE, incluyendo sin limitar defectos de operacin actual o potencialmente derivados de equipos, programas, plataformas, datos, sistemas, portales o cualquier otro bien del Usuario y/u operados por el Usuario en conflicto con la operacin del Software y/o cualquiera de sus aplicaciones o formas de operacin, o cualquiera intervencin de terceros a bienes del Usuario o al Software y/o cualquiera de sus aplicaciones o formas de operacin. NYCE har los esfuerzos de buena fe y comercialmente razonables que estn bajo su control, para mantener la disponibilidad del Software y/o cualquiera de sus aplicaciones o formas de operacin ante el incidente de que se trate, en el entendido de que no asumir costo alguno por las actividades de restitucin o restablecimiento que debieren efectuarse con motivo de cualquiera de las causas indicadas.

12. La presente licencia permanecer vigente durante un ao contado a partir de la fecha de Aceptacin, y se renovar automticamente por perodos iguales y sucesivos salvo que ocurra alguna de las causas de terminacin previstas en el presente contrato. NYCE podr restringir el derecho de uso del Usuario ante la infraccin por parte del Usuario de cualquiera de las obligaciones o prohibiciones contenidas en la presente licencia. A la terminacin del presente contrato por cualquier causa, el Usuario se obliga a dejar de usar el Software y/o cualquiera de sus aplicaciones o formas de operacin cualquier indicacin.

13. NYCE se hace nicamente responsable del Software para Administracin de la Base de Conocimiento KWE 2.0 para la Norma NMX-I-059-NYCE-2005 (MoProSoft) y Software para Autoevaluacin de la Norma NMX-I-059-NYCE-2005 (MoProSoft), cualquier software diferente a este es responsabilidad total de la empresa u organizacin que lo instale. El directorio virtual proporcionado por NYCE puede tener instalado el Sistema Operativo Windows XP, Windows Vista y Windows 7, as como del Manejador de Base de Datos SQL Server 2008 y el cual la institucin no se responsabiliza de dichas aplicaciones, ya que son aplicaciones de prueba y el cual el usuario final tendr que ingresar una licencia valida para su activacin y registro antes las instituciones pertinentes.

14. En caso de que cualquier clusula del presente documento sea declarada nula, las dems clusulas seguirn vigentes. El no ejercicio de cualquier derecho conferido a NYCE bajo el presente Contrato, no se entender en ningn caso como renuncia al derecho que le asista.

15. El presente contrato se rige por las leyes de Mxico. Para la resolucin de cualquier interpretacin o controversia, las partes se someten expresamente a los tribunales competentes en la ciudad de Mxico, D.F., y renuncian expresamente a cualquier otro fuero o jurisdiccin que pudiere corresponderles con motivo de sus domicilios presentes o futuros, o por cualquiera otra causa. Se puede visitar el sitio http://www.pmi.org para conocer ms sobre esta organizacin, fundada en 1969 el PMI cuenta con diversos captulos entre ellos el PMI Captulo Mxico y se puede visitar la pgina http://www.pmimexico.org para mayor informacin.

Colmenar, Antonio et al. Gestin de proyectos con Microsoft Project 2007. Alfaomega Grupo Editor. Mxico. 2007. p. 29.

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Cuarta edicin. Estados Unidos. 2008. p.5.

Idem. p. 10.

Idem. p. 12.

Idem. p. 6. Aunque tcnicamente este material integra cada una de las fases con procesos y es as como los denomina: grupo de procesos; sin embargo se hace la aclaracin de que fases y procesos son dos elementos conceptuales diferentes.

St-Pierre, Armand et al. Microsoft Project 98, gua prctica con ejercicios. Ed. Trillas. Mxico. 2000. p. 21.

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Cuarta edicin. Estados Unidos. 2008. p.18.

St-Pierre, Armand et al. Microsoft Project 98, gua prctica con ejercicios. Ed. Trillas. Mxico. 2000. p. 14.

Colmenar, Antonio et al. Gestin de proyectos con Microsoft Project 2007. Alfaomega Grupo Editor. Mxico. 2007. p. 30.

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Cuarta edicin. Estados Unidos. 2008. p.37.

Para lograr un proyecto exitoso, es necesario comenzarlos apoyndonos en un documento formal que ayude a que todos los participantes en el proyecto estn alineados a los objetivos que se plantearon para llevarlo a cabo. Este documento debe contener la suficiente informacin para conocer la razn por la cual se realizar el proyecto; cules son los objetivos; quines son los participantes clave del proyecto y qu esperan de l; documentar las restricciones que se tengan; quin ser el responsable de coordinarlo. Toda esta informacin se consolida en un documento que en Administracin Profesional de Proyectos se le denomina Charter (Chamoun, 2002:53), o acta de nacimiento del proyecto el documento debe venir firmado por quien asigna al responsable del proyecto y por la persona encargada o gerente de proyecto. Este documento ser la base para realizar la planeacin y el comienzo de una comunicacin efectiva entre todos los participantes del proyecto. (Trevio Guajardo, Ma. Del Roble. Cmo iniciar un proyecto.)

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Cuarta edicin. Estados Unidos. 2008. p.46.

Chrissis, Mary Beth et al. CMMI Gua para la integracin de procesos y la mejora de productos. Carnegie Mellon University Estados Unidos. 2006. p. XI.

Idem. p. 5.

Para mayor informacin se puede visitar los siguientes sitios: http://cmmiinstitute.com/cmmi-getting-started/, http://www.sei.cmu.edu/process/index.cfm

Idem. p. 11.

El Modelo de Capacidad de la Ingeniera de Sistemas tambin se conoce como Alianza de Industrias Electrnicas (EIA 731)

Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006. p. 60.

Uno de los ms utilizados actualmente es el SCRUM. El concepto de SCRUM tiene su origen en un estudio sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japn y los Estados Unidos (Takeuchi, Hirotaka. The New Product Development Game. Harvard Business Review, Enero-Febrero de 1986). En 1993 se realiz el primer SCRUM para desarrollo de software (Jeff Sutherland, John Scumniotales y Jeff McKenna lo concibieron, lo ejecutaron y lo documentaron) y en 1995 el proceso fue formalizado por Ken Schwaber para la industria de desarrollo de software.

Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006. p. 61.

RUP es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, actualmente constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos.

Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006. p. 89.

Idem. p. 88.

Idem. p. 96.

Idem. p. 97.

Idem. p. 545.

Idem. p. 547.

Idem. p. 547.

Idem. p. 562.

Idem. p. 588.

Algunos ejemplos son: el estndar 830-1998 IEEE Recommended Practice for Software Requirements Specifications, que se refiere a la Especificacin de Requisitos de Software y que expresa la manera de organizar el documento de requerimientos (vase http://standards.ieee.org/findstds/standard/830-1998.html); el estndar 730-2002 - IEEE Standard for Software Quality Assurance Plans (http://standards.ieee.org/findstds/standard/730-2002.html), que muestra el formato y el cmo se organiza el contenido del plan de aseguramiento de la calidad del software .

Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006. p. 601.

Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006. p. 548.