Negocios tipos de proyectos: análisis de mejora y mantenimiento de software, cunas y externalización

El tipo de los impactos del proyecto las categorías de requisitos que provocan, analizar y comunicar en su análisis de negocio. Recuerde, existe hay una talla única para todos los mencionados de análisis de negocio. En su lugar, asegúrese de que conoce todas las herramientas que tienes a tu alcance para determinar cómo va a completar su proyecto.

Proyectos de mejora de Software o de mantenimiento

En el desarrollo de software, mantenimiento de software se refiere a la modificación de los productos de software después del parto con el fin de corregir los fallos, mejorar el rendimiento u otros atributos, o para adaptar el producto a un entorno modificado.

Con estos proyectos, puede implementar nuevas características o hacer mejoras en el rendimiento para mantener actualizado el software al día en un entorno cambiante y competitivo. En otras palabras, un proyecto de mantenimiento de software puede involucrar cualquier cambio (reactivo o proactivo) de software o sistemas existentes.

Estos son algunos ejemplos de proyectos de mejora y mantenimiento:

• Adición de una nueva característica o función a un sistema existente

• La implementación de un cambio de política de negocio

• Corrección de un problema con el sistema actual o mejorar el rendimiento de software operativo

• Portar (mover los componentes de software) de software operacional para una plataforma de hardware diferente

Proyectos de mantenimiento o mejora varían en tamaño y complejidad. La planificación de elementos comunes en todos los ámbitos con este tipo de proyectos es un reto significativo porque muchas variables en juego, pero aquí hay algunos consejos a tener en cuenta cuando se señalan sus estimaciones del plan y de tiempo de trabajo:

• Lo que hay que centrarse en: Dedique tiempo a centrarse en obtener, analizar y comunicar los requisitos funcionales y no funcionales más que cualesquiera otros requisitos.

• ¿Cómo lidiar con-path rápido o de emergencia solicitudes: Estas solicitudes pueden acechar un proyecto muy fácilmente si no tienes cuidado. Para mantener el proyecto en marcha y en el tiempo, considerar la creación de la documentación después de la implementación de ahorrar por adelantado tiempo.

• ¿Cómo lidiar con otras peticiones importantes: Realizar una evaluación de costo / beneficio para determinar si la solicitud es viable.

• Cómo hacer análisis de múltiples solicitudes de un solo lanzamiento / iteración: Para estos proyectos, sólo tienes una oportunidad de hacer las cosas bien. Realizar un análisis a nivel de código y construir en los puestos de control para reducir el riesgo de redundancia, el conflicto entre las peticiones, y la introducción de errores en la producción.

  LA control es un momento en el proyecto al revisar los entregables para asegurarse de que están alineados con los objetivos de los proyectos originales y ámbito de aplicación. Una revisión del documento de requisitos funcionales antes de la construcción de la solución es un gran ejemplo de un puesto de control.

Proyectos off-the-shelf Comerciales

La gente compra off-the-shelf (COTS) de software comercial para ahorrar tiempo y coste de desarrollo. Una empresa puede implementar un paquete COTS como está, personalizar el paquete, o configurarlo después de la instalación.

El escenario ideal cuando se trabaja en un proyecto COTS es aquella en la que se puede obtener y analizar los requerimientos del negocio de las partes interesadas antes de seleccionar un paquete. En realidad, sin embargo, algunas empresas compran paquetes de software y luego pregunte a su equipo para implementar el software después del hecho.

Para los proyectos de COTS, su enfoque principal está en los requerimientos del negocio - incluyendo los procesos de negocio y las necesidades de datos. Usted debe hacer menos trabajo en los requisitos funcionales y no funcionales a menos que estés personalizar el sistema.

Si se toma en un proyecto COTS, las tareas que se necesitan para construir en su plan de trabajo después de que haya determinado la necesidad de negocios suelen ser los siguientes:

• Realizar un análisis de las deficiencias en la funcionalidad existente para el proceso de negocio que va a cambiar: Mediante la realización de una análisis de las deficiencias de los objetivos, los requisitos de datos, el mapeo de procesos entre el proceso actual y el proceso asociado con el producto COTS, y facilidad de uso, usted puede ayudar a determinar si un producto COTS puede ser implementado como está o necesita personalizaciones. Este proceso es el como es o Cómo análisis.

  Independientemente del tamaño del producto COTS, asegúrese de que su plan de trabajo le da tiempo suficiente para determinar la necesidad y el impacto de las personalizaciones o cambios en los procesos operativos. Si las personalizaciones son necesarios, pueden ser caro y causan mejoras a ser largo.

• Confirmando la solución recomendada y determinar si la personalización es necesario: Este es el ser o Cómo análisis.

Proyectos de desarrollo externalizados o en alta mar

Proyectos actuales incluyen generalmente los miembros del equipo en varias ubicaciones y con frecuencia implican la contratación externa. Estos proyectos tienen una mayor dificultad y el riesgo de fracaso debido a potencialmente conflictivos cultura y la comunicación normas.

Las partes interesadas en diferentes lugares pueden influir negativamente en el impulso y la capacidad del equipo a todos tienen una comprensión clara de los objetivos y la dirección del proyecto. A menudo, la planificación formal es necesaria para garantizar con éxito que todos tengan claro cómo se llevará a cabo el esfuerzo de análisis. En general, se trabaja con la empresa directamente a comprender sus necesidades en lugar de con los miembros del equipo de desarrollo en otro país.

Cuando se trata de proyectos de desarrollo externalizados o en alta mar, incluir este tipo de tareas en el plan de trabajo:

• Llevar a cabo un estudio de viabilidad para dar a los miembros del equipo un sentido de lo que pueden lograr.

• Definir los objetivos y las medidas clave para el éxito para que los miembros pueden señalar de nuevo a ellos durante el proyecto para asegurarse de que están en el buen camino.

• Ganancia acuerdo (incluyendo un proceso de revisión formal) para las entregas.

• Crear un glosario de proyecto para todos los términos y las definiciones correspondientes.

• Documento y discutir todos los supuestos, riesgos y limitaciones.

• Definir los criterios de aceptación claros para los requisitos.

• Planee actividades para la comunicación de trabajo en equipo con el equipo externo.

Además, usted y su equipo debe buscar la manera de complementar sus esfuerzos de comunicación mediante el uso de herramientas de colaboración.

Tenga en cuenta que la decisión de externalizar o utilizar de desarrollo offshore se hace a menudo fuera del alcance de su proyecto y de su control. Su equipo tiene que priorizar claramente los requisitos y adoptar un enfoque para trabajar de forma incremental en una función o característica a la vez.

Debido a que muchos equipos de desarrollo offshore se encuentran en diferentes zonas horarias de los usuarios y el resto del equipo, que trabaja en un pequeño subconjunto de características a la vez es más manejable que tratar de completar los requisitos para todas las funciones. Trabajando en pequeños trozos hace que sea más manejable para el equipo.