Gestión de Proyectos de Software


Gestión de Proyectos de Software

Ingeniería de Software

03/06/2011

Universidad Mariano Gálvez de Guatemala

Gestión de proyecto de Software

Introducción

En un mudo donde la tecnología y los sistemas se apropian de todos los campos donde se desarrolla el ser humano, es importante brindar soluciones informáticas de alta calidad y precisión. Donde el factor tiempo es indispensable, los Ingenieros en Sistemas tienen la responsabilidad de responder a estos cambios y necesidades de una forma integral y sostenible. La Ingeniería de Software plantea un panorama lleno de ideas, métodos, procedimientos y técnicas para afrontar la demanda de sistemas de alta calidad, que proporcionan soluciones a medida, a través de la GESTION DE PROYECTOS DE SOFTWARE, el ingeniero en sistemas puede apoyarse en el desarrollo e implementación de dichos sistemas, encaminado a la creación de estándares en el desarrollo de las actividades que implica una solución informática.

AMBITO DEL PROYECTO

En esta oportunidad presento un trabajo que fue solicitado dentro de la organización para la cual trabajo, prestando los servicios de Analista de Sistemas, siendo una necesidad verídica y latente, el desarrollo de un sistema de Control y Manejo de Expedientes, para una de las unidades de la empresa, Ventanilla Única que tiene a su cargo la gestión de proyectos de construcción y emisión de licencias de agua. Cumpliendo con el requerimiento del curso de Ingeniería de Software, fue planteada la situación en la empresa para solicitar la autorización correspondiente, para la implementación de dicho Sistema de Información. Presentando en este trabajo, toda la documentación respectiva del análisis, diseño, codificación, pruebas, he implementación que se llevo a cabo, bajo las directrices de la GESTION DE PROYECTOS DE SOFTWARE.

NOMBRE DEL PROYECTO:
Sistema de Control de Expedientes 
SUBGERENCIA SOLICITANTE:
Sub-gerencia de Atención al Cliente 
DIRECCION O DEPENDENCIA SOLICITANTE:
Ventanilla Única – EMPGUA –
OBJETIVO DEL PROYECTO:
 Necesitamos un sistema que cumpla con las necesidades básicas y especi-
 fichas, que sustituya al actual sistema POT (Planificación y Ordenamiento
Territorial). Que actualice el estado de los expedientes nuevos así como los
Ya ingresados en el sistema actual, que permita seguimiento puntual de
Cada una de las tareas o pasos que lleva ejecutados, así como el mantenimi-
ento y continuidad de los expedientes dentro del sistema.
Retroalimentación de información hacia el sistema POT municipal.
BREVE DESCRIPCION DE LA SITUACIÓN FUTURA:
Mejoras que introduce:
Homogenización de información, entre el sistema Municipal POT  y el nuevo
Sistema de Control de Expedientes.
Control puntual de trabajos y estados del expediente.
Minimización del tiempo de solución de un expediente.
Justificación Económica
 Al agilizar el dictamen de un Expediente se percibirá un mayor ingreso
Económico, y confianza para el ingreso de estos trámites por parte de los
Usuarios. Minimizando el tiempo solución.
DESCRIPCION DE LA SITUACIÓN ACTUAL:
Se tiene un sistema, que inicialmente fue concebido para realización de estas
Tareas (Control y seguimiento de expedientes). Pero nunca hubo una
Solución completa, ya que no se puede realizar con éxito el seguimiento de
Todos los trabajos realizados a los expedientes, sin haber un seguimiento
Adecuado, se volvió obsoleto, dejando simplemente la funcionabilidad de
Impresión de algunos formatos, preestablecidos que sirven para notificar o
Solicitar distintas tareas o trabajos.
DESCRIPCIÓN DE LA SOLICITUD:
 Por lo que se solicita, sea brindada la solución informática adecuada, que
Cumpla con dichos requerimientos, los cuales serán expuestos especifica-
mente, en la reunión planificada para el viernes 11-03-2011. En la oficina
Del departamento de Sistemas Empagua.
¿EXISTE FECHA NECESARIA DE IMPLEMENTACIÓN?:
SI    x                  NO
INDIQUE: 
 La fecha de implementación será el 06-06-2011.
 Previo se contemplaran todo tipo de pruebas para asegurar el correcto
Funcionamientos del sistema.
Fecha Nombre del Responsable Sello y Firma del responsable
Dependencia Solicitante: Ventanilla Única Arq. Claudia Muñoz
Visto Bueno Sub Gerencia Solicitante Atención al Cliente Ing. Freddy Guzmán
Para uso exclusivo de Subgerencia de Sistemas de Información
Actividades del proyecto:
 Estudios de Factibilidad del ProyectoEncargados:

  1. Jorge Oliveros (Director de Aplicaciones)
  2. Victor Mazariegos (Experto en Aplicaciones y Sistemas)
  3. Luis Geovanni García (Analista programador)
  4. Joan Carlo Cifuentes (Analista programador)

Recurso Humano:

Se contará con dos Analistas programadores para el desarrollo completo del Sistema de Control de Expedientes.

Recurso técnico:

Se cuenta con un servidor de aplicaciones tanto en desarrollo como en producción. Cada analista programador cuenta con su equipo portátil, con todas las herramientas de desarrollo que utilizará.

La Base de Datos es común a todas las aplicaciones de la empresa, se creó un esquema independiente para esta aplicación.

Recurso financiero:

El costo de equipo necesario en los puntos de trabajo corre a cuenta de la Unidad de Ventanilla Única, no de sistemas.

El equipo técnico a utilizar, ya se encuentra implementado en el departamento por lo que no habrá necesidad de invertir ningún recurso  financiero, mas se incluye dentro del cuadro de costes.

Análisis y planificación de ActividadesEncargados:

  1. Luis Geovanni García
  2. Joan Carlo Cifuentes
Fecha de Implementación
Fecha Nombre del Responsable Firma del responsable
Personal Asignado 06-06-2011 Luis Geovanni García Ordoñez
Aceptación del proyecto
Fecha Nombre del Responsable Sellos y Firma del responsable
Dependencia Solicitante: Ventanilla Única Arq. Claudia Muñoz
Dirección Asignada Subgerencia de Sistemas de Información Ing. Rubén Martínez

Árbol de decisión

Considerando

Partiendo de que la empresa cuenta con un departamento de sistemas propio y personal Outsource. Todos los software para uso interno, son desarrollados dentro de la empresa.
El personal Outsource, es de tiempo completo y cobra por hora, es un contrato definido a 1 año y renovable.

Se tiene el compromiso de brindar todo el apoyo necesario para el cumplimiento de las metas y objetivos, tanto internos como externos, se toma como base el recurso técnico disponible dentro de la empresa (Equipos de cómputo, Servidores, Enlaces de datos, mobiliario, espacio laboral, viáticos, etc.)
Por tanto
Se toma la decisión de DESARROLLAR internamente el software requerido por el departamento de Ventanilla única.

Etapa de planificación:

Lista de tareas para el análisis, diseño, desarrollo e implementación de sistemas

  1. REQUISITOS
    1. Establecimiento de requisitos generales del sistema.

i.        Punto de vista del usuario (historias de usuario).

ii.        Que es lo que queremos hacer?

  1. Establecer requisitos específicos, por modulo o subsistema.

i.        Lista de requisitos del producto.

ii.        Asignación de prioridades.

  1. ANALISIS
    1. Análisis de la viabilidad del sistema.
    2. Metodología de desarrollo.

i.        (SCRUM)

  1. Sprint cortos, entregas frecuentes.
  2. Sprint Product backlog (lista en la que se detalla él COMO se van a construir los diferentes requisitos del producto)
  3. Daily standup (Reuniones Scrum)
  1. RECURSOS
    1. Humanos

i.        Definición de ROLES

  1. CERDO
    1. Product Owner (la voz del cliente)
    2. ScrumMaster(o Facilitador)
    3. Equipo.
    4. GALLINA
      1. POLLOS

i.        Los usuarios del producto o aplicación

ii.        Los clientes y vendedores

iii.        Los gestores y directivos

iv.        Reunión diaria, transparencia total.

  1. Stakeholders (Clientes y Proveedores)

Solo participan en las revisiones del sprint.

  1. Manager

Es la gente que establece el ambiente para el desarrollo del producto.

  1. Tecnológicos

i.    Software

ii.    Hardware

  1. Financieros
  1. DISEÑO
    1. a.    REVISION DE LOS AVANCES

(DAILY STANDUP)

i.        ¿Qué has hecho desde ayer?

ii.        ¿Qué es lo que estas planeando hacer hoy?

iii.        ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo (Es el papel del ScrumMaster recordar estos impedimentos)

  1. Estructura de los datos.

i.    Relacional

ii.    Transaccional

  1. Arquitectura del software

i.    N-Capas

  1. Representación de la interfaz

i.    Web

  1. Y detalle procedimental
  2. Documentación

i.    Product backlog

ii.    Sprint backlog

iii.    Burn down

  1. GENERACIÓN DE CODIGO
  1. PRUEBAS
    1. Funcionamiento lógico del software
    2. Check list de los requisitos.
    3. Prueba de módulos o sub-programas.
    4. Prueba de los procedimientos.
  1. MANTENIMIENTO

Recurso humano

En el departamento de sistemas se cuenta con el siguiente personal, detallando sus funciones, responsabilidades:

Jefe del Departamento de Sistemas:

Responsabilidades: Proponer, formular, organizar, dirigir e implementar las políticas y planes de aplicación y de uso de tecnologías de la información y de las comunicaciones, de manera que estos provean soporte a la operación de la empresa.

Funciones: Planificar, organizar, dirigir y controlar las actividades relacionadas con los sistemas de información.

Obligaciones: Planear y desarrollar sistemas informáticos e implementar nuevas tecnologías para optimizar los existentes.

Dones De Mando: Jefe de desarrollo, jefe de soporte, secretaria.

Jefe de Desarrollo:

Responsabilidades: Proponer, formular, organizar, dirigir e implementar planes de aplicación y de uso de tecnologías de desarrollo y de las comunicaciones.

Funciones: Planificar, organizar, dirigir y controlar las actividades relacionadas con los sistemas de información.

Obligaciones: Planear y desarrollar sistemas informáticos e implementar nuevas tecnologías para optimizar los existentes.

DBA:

Responsabilidades: Proponer, formular, organizar, dirigir e implementar las normas y técnicas para la creación y administración de bases de datos.

Funciones: Planificar, organizar, dirigir y controlar las actividades relacionadas con las bases de datos.

Obligaciones: Planear y desarrollar sistemas informáticos e implementar nuevas tecnologías para optimizar las bases de datos existentes.

Analista:

Responsabilidades: Proponer, y entregar informes al gerente de desarrollo y supervisar a los programadores, elaborar un equipo

Funciones: Controla y analiza el trabajo de los programadores, para asegurar que los clientes reciben la mejor aplicación.

Obligaciones: Planear y desarrollar normas de calidad a los sistemas informáticos e implementar nuevas tecnologías para optimizar tiempos de entrega de proyectos.

Programadores:

Funciones: Se dedica a una o más facetas del proceso de desarrollo de software, un ámbito algo más amplio de la programación. Esta persona puede contribuye  a la visión general del proyecto más a nivel de aplicación que a nivel de componentes o en las tareas de programación individuales.

Responsabilidades: Suele desempeñar todas estas tareas:

Participa en la definición del producto de software que se va a comercializar, incluyendo el análisis de los nichos de mercado al que va dirigido a la especificaciones del software, el análisis de requerimientos del software, diseño y mejora de prototipos y de demos para validar requerimientos.  El análisis del costo-beneficio, que incluye elegir el tipo de arquitectura y el framework que implica tener claro el presupuesto y el calendario de trabajo diseño, programación, implementación, documentación para los usuarios del software desarrollado, testeo de las aplicaciones y supervisión del proceso de arranque de prueba de la aplicación mantenimiento.

Roles: Se encargada de aspectos que se puede definir como la gestión de proyectos de desarrollo de software.

Jefe de Soporte:

Responsabilidades: Administrar, planear e implementar las comunicaciones  y la infraestructura tecnológica de la compañía.

Funciones: Delegar responsabilidades a los técnicos de la empresa.

Obligaciones: Mantener la estructura e infraestructura de la red en óptimas condiciones para que todo funcione de lo mejor manera.

Técnicos:

Responsabilidades.  Operadores expertos en telecomunicaciones e infraestructura del equipo.

Funciones: Su función principal es la de reparar cualquier aparato eléctrico, en este caso, todos los instrumentos implantados en nuestro proyecto como maquinas, servidores, switchs,  etc. incluyendo aquellos aparatos que aun cumplen con tiempo de garantía en tiempo bueno.

Secretaria:

Responsabilidades: Prestar un buen servicio al cliente y mantener en óptimas condiciones el equipo de trabajo.

Funciones: Darle soporte a la empresa apoyando labores secretariales, controles, archivo y atención a los clientes que visitan la empresa.

Obligaciones:

ü  Atender llamadas telefónicas.

ü  Asistir al departamento de recursos humanos

ü  Archivo.

ü  Atención al cliente.

Presupuesto de Infraestructura

No. Equipo Costo unidad Costo toal

7

computadoras para los usuarios de ventanilla única  Q        4,000.00  Q  28,000.00

1

computadora para el encargado de área  Q        7,000.00  Q    7,000.00

1

computadora para secretaria  Q        4,000.00  Q    4,000.00
 Q  39,000.00

Presupuesto de Desarrollo

No. Persona horas/día días Costos / hora Costo toal

1

Analista Programador 1

8

60

 Q              37.50  Q  18,000.00

1

Analista Programador 2

4

60

 Q              39.58  Q    9,500.00

1

Analista Programador 3

3

60

 Q              41.67  Q    7,500.00

1

Programador (reportes)

4

20

 Q              29.17  Q    2,333.33
 Q  37,333.33

Manejo de Comunicaciones

Se cuenta con el servicio de internet, el cual se recibe de forma inalámbrica.   La señal del router se distribuye a través de un patch panel para luego distribuir la señal a través de la intranet.

La red interna está realizada físicamente a través de cableado y hubs que se encargan de distribuir la señal.

Desde el exterior de la intranet es posible acceder a través de VPNs.

Esquema de Comunicaciones

Manejo de las redes

La red interna está compuesta por cableado categoría E5, la cual está conectada por Hubs los cuales van conectados al patch panel principal que distribuye la señal en toda la intranet.

ESQUEMA DE  RED

Periféricos Adicionales

  • Impresoras
  • Fax
  • Scanner
  • Teléfonos
  • Fotocopiadora

Evaluación de la Seguridad:

Sistema de Acceso

Para evitar los fraudes computarizados se debe contemplar de forma clara los accesos a las computadoras de acuerdo a:

• Nivel de seguridad de acceso

• Empleo de las claves de acceso

• Evaluar la seguridad contemplando la relación costo, ya que a mayor tecnología de acceso mayor costo.

Cantidad y Tipo de Información

El tipo y la cantidad de información que se introduce en las computadoras debe considerarse como un factor de alto riesgo ya que podrían producir que:

• La información esté en manos de algunas personas

• La alta dependencia en caso de pérdida de datos.

Planificación

Pruebas de Compatibilidad de software 48 hrs. (6 días) 2 personas (8500/30)/8 3400
 Navegadores 96 hrs. (12 días) 2 personas (8500/30)/8 6800
 Sistema Operativo  –  –  –  –
 Redes  36 hrs. (5 días)  1 Persona  (8000/30)/8  1200

METRICAS DE LA PLANIFICACIÓN

CUMPLIMIENTO DE ACTIVIDES EN FECHA

Indicador

Descripción

% de riesgo

0 – 20 %

Revisión de tiempo definido en la planificación (Replanteo). Fracaso

100%

21 – 40 %

Revisión de tiempo por actividad y personal involucrado (Verificar carga de trabajo)

80%

41 -60 %

Convoca reunión con personal involucrado en actividades criticas (distribución de tareas)

50%

61 – 80 %

Motivación, ajuste de tiempos, cargas de trabajo.

20%

81 – 100 %

Seguimiento de actividades terminadas para nueva fase (pruebas)

0 – 10%

DESVIACIÓN DEL PRESUPUESTO

Indicador

Descripción

% de riesgo

0 – 20 %

Verificar avance de tareas, priorizar.

0 – 10%

21 – 40 %

Revisar y analizar las tareas asignadas, comprometer tiempos.

20%

41 -60 %

Convoca reunión y entrega de informes (horas/hombre, tareas/hombre), en vista de fracasar.

50%

61 – 80 %

Convoca reunión y entrega de informes (horas/hombre, tareas/hombre) revisión de viáticos, fracaso inminente del proyecto.

80%

81 – 100 %

Fracaso total del proyecto

100%

ASIGNACION DE RECURSOS

Indicador

Descripción

% de riesgo

0 – 20 %

No se tiene compromiso de parte de la dirección (Fracaso total)

100%

21 – 40 %

Falta de apoyo, compromiso y responsabilidad de los directivos. Convoca reunión, reafirmar el compromiso

80%

41 -60 %

Verificación de las actividades, consulta de necesidades, prioridad de las tareas.

50%

61 – 80 %

Verificación de las tareas vrs. Recurso disponible.

20%

81 – 100 %

Cumplimiento de los recursos planificados, análisis de los resultados

0 – 10%

% DE VARIACION DE EJECUCION / PLANIFICACION

Indicador

Descripción

% de riesgo

0 – 20 %

Revisar planificación y asignación de actividades. Convoca reunión analizar situación y tiempos.

100%

21 – 40 %

Revisar y analizar las tareas asignadas, comprometer tiempos.

80%

41 -60 %

Convoca reunión y entrega de informes (horas/hombre, tareas/hombre), en vista de fracasar.

50%

61 – 80 %

Verificación de estatus de tareas pendientes, motivar, comprender y mejorar.

20%

81 – 100 %

En  busca de la calidad total.

0 – 10%

METRICAS DEL PROYECTO

CUMPLIMIENTO DE PLANIFICACION

Indicador

Descripción

% de riesgo

0 – 20 %

Fracaso total

100%

21 – 40 %

Revisión jefe de proyecto, equipo de trabajo.

80%

41 -60 %

Revisión jefe de proyecto, equipo de trabajo, análisis de tiempos vencidos. (puede fracasar)

50%

61 – 80 %

Revisión jefe de proyecto, equipo de trabajo, análisis de tiempos vencidos. (se debe comprometer más esfuerzo)

20%

81 – 100 %

RUMBO A LA CALIDAD TOTAL

0 – 10%

RESUMEN DE APEGO A PROCESOS

Apartado

Preguntas aprobadas

% de apego

Observaciones

Introducción

3

100%

Datos Generales

3

100%

Organización del proyecto

2

100%

Opciones y desviaciones del proceso

1

100%

Planificación del proyecto

6

100%

Programación

1

100%

Planes para las actividades de soporte

5

100%

Monitoreo y control del proyecto

3

100%

Total

24

100%

Verificación

Condiciones

Observaciones

Si

No

No Aplica

Introducción

1

¿Se ha descrito el propósito del plan de desarrollo del software?

X

2

¿Se han definido el alcance del plan de desarrollo del software?

X

3

¿Se han listado todos los documentos referenciados en el plan de desarrollo del software?

X

Datos Generales

4

¿Se ha definido el objetivo de negocio que intenta cubrir el proyecto?

X

5

¿Se ha definido el objetivo que intenta cubrir el proyecto?

X

6

¿Se han listado los entregables que se generan durante la ejecución del proyecto describiendo sus objetivos de calidad en términos de requerimientos de salidas a producción?

X

Organización del proyecto

7

¿Se ha descrito la estructura organizacional del equipo de trabajo del Proyecto?

X

8

¿Se han definido los roles y responsabilidades?

X

Opciones y Desviaciones del Proceso

9

¿Se ha identificado el ciclo de vida y las fases e iteraciones a ser utilizadas en el proyecto?

X

Planificación del Proyecto

10

¿Se ha referenciado o descrito las estimaciones del tamaño, esfuerzo y cualquier cálculo e información de soporte? ¿Se ha referenciado a un documento separado o incluido las estimaciones de costo e información de soporte?

X

11

¿Las estimaciones cuentas con información Histórica?

X

12

¿Se ha descrito un Plan de Equipamiento necesario?

X

13

¿Se indicaron las necesidades de infraestructura?

X

14

¿Se ha descrito o referenciado un Plan de Recursos Humanos?

X

15

¿Se ha identificado las capacitación requerida por los recursos afectados y como se llevara a cabo? Indicando horas de duración del curso/taller y lista de los nombres de los recursos asistentes.

X

Programación

16

¿Se ha referenciado o incluido la programación de las actividades, tareas, recursos y responsabilidades asignadas?

X

Planes para las actividades de Soporte

17

¿Se ha descrito o referenciado el Plan de Calidad?

X

18

¿Se ha descrito o referenciado el Plan de Administración de Riesgo?

X

19

¿Se ha descrito o referenciado el Plan de Administración de Configuración de Software?

X

20

¿Se ha descrito o referenciado un Plan de Pruebas de Software?

X

21

¿Se ha descrito o referenciado el Plan de Comunicaciones? ¿Se han identificado las dependencias Críticas?

X

Monitorear y Control del Proyecto

22

¿Se ha especificado el tipo y frecuencia de producción de los  reportes del proyecto?

X

23

¿Se ha especificado la frecuencia y asistencia a las Reuniones del Equipo de Trabajo?

X

24

¿Se ha especificado la frecuencia de Reuniones de aceptación Fase/Etapa?

X

METRICAS DEL PRODUCTO

1.    Establecer el Costo del Sistema de Seguridad (Análisis Costo vs Beneficio)

Este estudio se realiza considerando el costo que se presenta cuando se pierde la información vs el costo de un sistema de seguridad.

Para realizar este estudio se debe considerar lo siguiente:

• Clasificar la instalación en términos de riesgo (alto, mediano, pequeño)

• Identificar las aplicaciones que tengan alto riesgo

• Cuantificar el impacto en el caso de suspensión del servicio aquellas aplicaciones con un alto riesgo

• Formular las medidas de seguridad necesarias dependiendo del nivel de seguridad que se requiera

• La justificación del costo de implantar las medidas de seguridad

  1. 2.    Evaluación de Rendimiento (respuesta = operación /tiempo).
  2. 3.    Evaluación de Confiabilidad (% Transacciones grabadas exitosamente).
  3. 4.    Rendimiento BD (% de consumo de recursos, sesiones, usuarios conectados).
  4. 5.    Navegación eficiente (Estructura de navegación / percepción de usuario).
  5. 6.    Respuesta ambiente web (operación /tiempo)

 

 

CUMPLIMIENTO DE TAREAS/RESPONSABLE

Indicador

Descripción

% de riesgo

6/6

Excelente

0%

5/6

Bueno

10%

4/6

Mejorar

40%

3/6

Regular

50%

2/6

Malo

80%

1/6

Muy malo

100%

ENTREGA DE FACES O ETAPAS

Indicador

Descripción

% de riesgo

1/1

Éxito

0%

0/1

Fracaso

100%

FACILIDAD DE USO

Indicador

Descripción

% de riesgo

5/25

Muy malo

100%

10/25

Malo

80%

15/25

Regular

50%

20/25

Aceptable

20%

25/25

Excelente (RUMBO A LA CALIDAD TOTAL)

0%

FACILIDAD DE MANTENIMIENTO

Indicador

Descripción

% de riesgo

0 – 20 %

Fracaso total

100%

21 – 40 %

Revisión jefe de proyecto, equipo de trabajo.

80%

41 -60 %

Revisión jefe de proyecto, equipo de trabajo, análisis de tiempos vencidos. (puede fracasar)

50%

61 – 80 %

Revisión jefe de proyecto, equipo de trabajo, análisis de tiempos vencidos. (se debe comprometer más esfuerzo)

20%

81 – 100 %

RUMBO A LA CALIDAD TOTAL

0 – 10%

Listado de Requisitos

Requerimiento # 1
Nombre: Control de recepción de expedientes desde la Municipalidad
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 03/03/2011
Tipo: Funcional
Condiciones: Pre:–          Que el expediente este  asignado a Empagua en el Sistema de la Municipalidad.
Post:–          Tener una fecha creación y recepción del expediente.
Descripción: Se necesita brindar una solución informática para la recepción de expedientes provenientes del sistema de la Municipalidad.En donde conste la fecha de ingreso al Sistema de Control de expedientes, identificando el usuario y área a la que se asigna.
Criterio de Aceptación: Pantalla o pantallas funcionales para la recepción de expedientes.
Fecha de Entrega: Persona Recibe:
Requerimiento # 2
Nombre: Permitir la asignación de expedientes a las Áreas de Trabajo.
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 03/03/2011
Tipo: Funcional
Condiciones: Pre:–          Que el expediente ya se encuentre recepcionado en el Sistema de Control de Expedientes.-          Disposición del catalogo de áreas y usuarios disponibles dentro del Sistema.
Post:–          Expedientes asignados a las áreas de trabajo dentro del Sistema.
Descripción: Se necesita brindar una solución informática para la asignación de expedientes a las áreas de trabajo, si y solo si ya se encuentran recepcionados dentro del SCE.Esta actividad estará restringida únicamente al área de jefatura.
Criterio de Aceptación: Pantalla o pantallas funcionales para la Asignación de expedientes dentro del SCE.
Fecha de Entrega: Persona Recibe:
Requerimiento # 3
Nombre: Creación de proceso y flujos para los expedientes dentro del área asignada.
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 03/03/2011
Tipo: Funcional
Condiciones: Pre:–          Tener una asignación valida dentro del SCE.-          Estar en el área correcta para inicio de los procesos.-          Catalogo de procesos disponibles.-          Asignación de responsabilidades.
Post:–          Procesos en curso para los Expedientes asignados.
Descripción: Se necesita brindar una solución informática para la creación y asignación de procesos a los expedientes para inicio de labores del sistema. Con el fin de evaluar y dictaminar un expediente según sea requerido dentro del sistema. Estos trabajos están divididos por áreas y tiene que tener un tiempo límite de ejecución.
Criterio de Aceptación: Pantalla o pantallas funcionales para la creación de procesos dentro del SCE.
Fecha de Entrega: Persona Recibe:
Requerimiento # 4
Nombre: Parametrización de los procesos
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 03/03/2011
Tipo: No Funcional
Condiciones: Pre:
Post:–          Establecimiento de parámetros para cada proceso.
Descripción: Se necesita parametrizar los procesos aplicables dentro del sistema, con el objetivo de ajustar los tiempos máximos y mínimos para ejecución de dichos procesos. Esto servirá para ajustar y cumplir lo solicitado por los sistemas de la Municipalidad.
Criterio de Aceptación: Opciones de parametrización de de procesos.
Fecha de Entrega: Persona Recibe:
Requerimiento # 5
Nombre: Creación de flujos o etapas para los procesos
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 03/03/2011
Tipo: No Funcional
Condiciones: Pre:–          Definición de los flujos o etapas para los procesos.
Post:–          Creación de flujo específico o alternativo para los procesos del sistema.
Descripción: Algunos trabajos es necesario crearles un flujo, porque no se pueden realizar de una sola vez, o las actividades ocurrentes en el proceso, son responsabilidad de distintas personas. Esto permitirá delegar y asignar responsabilidades dentro del sistema para la ejecución de tareas.
Criterio de Aceptación: Creación de flujos o etapas para los procesos.
Fecha de Entrega: Persona Recibe:
Requerimiento # 6
Nombre: Alerta de colores
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 03/03/2011
Tipo: Funcional
Condiciones: Pre:–          Parametrización de los procesos.
Post:–          Identificación de las alertas de colores para cada expediente.
Descripción: Se necesita que el sistema contenga una alerta visual (colores tipo semáforo) para alertar del estado del expediente dentro de todo el sistema. Al estar dentro de rango de vigencia por tarea, el color será verde, al aproximarse a su vencimiento cambiara a amarillo y al estar vencida la tarea o actividad se pintara en rojo el registro.Esto es aplicable tanto a los procesos, como también a estatus general del expediente según su clasificación.
Criterio de Aceptación: Visualización de la alerta de colores.
Fecha de Entrega: Persona Recibe:
Requerimiento # 7
Nombre: Evaluación de Expedientes
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 10/05/2011
Tipo: Funcional
Condiciones: Pre:–          Creación de objeto para el catalogo para la evaluación del expediente.-          Modificación de la ficha del expediente,  para incluir los campos para la evaluación del expediente.-          Modificación del catalogo de trabajos y etapas para establecer tiempos máximos según tipo de evaluación del expediente.-          Ingreso de información para expedientes nuevos.-          Homologación de información para aplicar cambios en tiempos y colores.
Post:–          Tiempos y colores acorde al tipo de evaluación del expediente.-          Etiqueta de identificación acorde al tipo de evaluación del expediente.
Descripción: Modificar la aplicación, de tal forma que siempre se pueda identificar qué tipo de proyecto se está trabajando. Esta información debe mostrarse en todas aquellas pantallas que listen información propiamente del expediente. Modificar los tiempos para que sean de acuerdo al tipo de expedientes que se esté trabajando.
Criterio de Aceptación: Indicar correctamente que tipo de proyecto se está trabajando,  hacer corresponder las alertas de colores según la evaluación del expediente.
Fecha de Entrega: Persona Recibe:
Requerimiento # 8
Nombre: Anulación de expedientes
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 10/05/2011
Tipo: Funcional
Condiciones: Pre:–          Que el expediente exista y este dado de alta en el sistema.-          Se posea permiso para anular.-          Que el usuario sea de área de jefatura.
Post:–          Dejar constancia de la operación, con datos como: Usuario, fecha operación, motivo u observaciones.-          Cortar todo tiempo que este en curso, de asignaciones, trabajos y etapas.-          Estado (anulado) de los documentos generados hasta el momento.
Descripción: Es necesario contar con una opción de anulación del expediente, dejando consistencia en todos los datos que se pudieron haber generado a través del mismo. Debe anularse todo tipo de documentos a nombre de este expediente. Los tiempos se deberán detener.
Criterio de Aceptación: Consulta de los expedientes anulados, recorrido y documentos consistentes.
Fecha de Entrega: Persona Recibe:
Requerimiento # 9
Nombre: Creación de Actividades en el Área de Secretaria
Solicitado por: Claudia Beatriz Muñoz
Fecha Solicitud: 10/05/2011
Tipo: Funcional
Condiciones: Pre:–          Debe existir el expediente dentro del sistema.-          Se tiene que tener un área de Secretaría existente.-          Se tiene que tener una asignación abierta al área de secretaria.-          Identificar los trabajos asignados al área de secretaria.-          Identificación de las etapas por trabajos en secretaria.-          Asignación de tiempos por trabajos.
Post:–          Control de las actividades administrativas del expediente dentro de VU.-          Información del expediente dentro del proceso de VU.
Descripción: JUSTIFICACION DE LA SOLICITUD:a)      El área de SECRETARIA nos servirá para incluir en ella todos los pasos que conllevan una Licencia, una Factibilidad y una Nota de Aviso, que ya no son responsabilidad de los Analistas si no parte del proceso administrativo de la Unidad.b)      Al separar los procesos administrativos de los técnicos se podrá FINALIZAR una asignación de ANALISIS DE DRENAJES sin afectar los procesos que se realizan después de que una Licencia, Factibilidad o Nota de Aviso se aprueba en Jefatura.c)      Al observar que las áreas técnicas (agua y drenajes) ya están finalizadas y únicamente esta sin finalizar el área administrativa de Secretaría, se podrá asumir fácilmente que el proceso en el que se encuentra el expediente ya es el último.  Esto le sirve directamente al personal administrativo de la Unidad que constantemente da información al vecino sobre los expedientes en análisis en la Unidad.ESTRUCTURA DE LO SOLICITADO:1)      Agregar al área de SECRETARÍA los siguientes TRABAJOS:

  1. Licencia
  2. Factibilidad Específica
  3. Nota de Aviso
  4. Nota de Requisitos

2)      Agregar al área de SECRETARÍA las siguientes actividades en las ETAPAS:

  1. Imprimir dictamen
  2. Firma
  3. Recepción de expediente
  4. Validación
  5. Recepción de correcciones
  6. Anexión de documentos al caso
  7. Aprobación UCMAN retenida no pago de Licencia
  8. Envío de consulta a DCT
  9. Envío de consulta a Catastro
  10. Aprobación UCMAN notificada
  11. Archivo seguimiento pago de Licencia
  12. Recepción constancia pago de Licencia
  13. Emisión providencia de traslado
  14. Envío expediente a Obras para supervisión
  15. Archivo final
  16. Envío de dictamen
  17. Envío a UCMAN

3)      Agregar al área de SECRETARÍA los siguientes usuarios responsables:

Ingrid Carolina y Cindy

GESTION DEL RIESGO

Qué pasaría si?

Riesgos del software

Se han producido amplios debates sobre la definición adecuada para riesgo de software, y hay acuerdo común en que el riesgo siempre implica dos características:

• Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad.


• Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.


Los riesgos del proyecto amenazan al plan del proyecto.

  1. Retraso en la planificación temporal del proyecto.
  2. Aumento de los costos.
  3. Asignación de recursos (Humanos, técnicos y financieros).

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir.

  1. Implementación difícil o imposible.
  2. Problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento.
  3. Ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las “tecnologías punta”.

Los riesgos del negocio amenazan la viabilidad del software a construir.

  1.  Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado)
  2.  Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico)
  3. Construir un producto que el departamento de ventas no sabe cómo vender.
  4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección).
  5. Perder presupuesto o personal asignado (riesgos de presupuesto).

Fechas de entrega poco realistas.

Falta de especificación de requisitos o de ámbito del software.

Entorno pobre de desarrollo.

Nos podemos apoyar en experiencias pasadas como:

  1. Cambio de personal.
  2. Mala comunicación con el cliente.
  3. Disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento.
ID requisito Respuesta Impacto Componente Medida
R1 SI SI Desempeño Catastrófico
R2 NO NO Desempeño Catastrófico
R3 NO NO Desempeño Catastrófico
R4 NO NO Desempeño Crítica
R5 NO NO Desempeño Crítica
R6 NO NO Costo Marginal
R7 NO NO Desempeño Marginal
R8 NO NO Desempeño Marginal
R9 NO NO Desempeño Crítica
Riesgo Tipo de riesgo Descripción
Rotación de personal Proyecto, producto y negocio Personal con experiencia abandona el proyecto antes de que finalice
Cambios de requisitos Proyecto y producto Existencia de más cambios de requerimientos de los previstos inicialmente
Retrasos en la especificación Proyecto y producto Retrasos en las especificaciones de interfaces esenciales
Subestimación del tamaño Proyecto y producto El tamaño del requisito (la ERS, del proceso de IR) se ha subestimado
Bajo rendimiento de la herramienta CASE Producto Las herramientas CASE que ayudan al proyecto no tienen el rendimiento y las funcionalidades esperadas

 

ID Requisito Tipo de Riesgo Riesgos
R1 De personal El personal no cuenta con los conocimientos requeridos para enfrentar la complejidad del requisito
Miembros del equipo no disponibles en momentos críticos
De requisitos Cambios de requisitos que precisan modificaciones en el diseño
Los clientes no comprenden el impacto de los cambios en los requerimientos
De estimación El tiempo requerido para desarrollar el proceso de ingeniería de requisitos está subestimado
De comunicación El cliente no pueda participar en revisiones y en reuniones
Tipo de riesgo Posibles riesgos
Personal Imposible contratar personal con los conocimientos requeridos.
Organizativos La organización se reestructura y una nueva administración se responsabiliza del proyecto.
Herramientas Las distintas herramientas CASE no están disponibles
Requerimientos Cambios de requerimientos que precisan modificaciones en el diseño.
Estimación El tamaño del sistema a desarrollar está subestimado.
Riesgo Probabilidad Efectos
Problemas financieros de la organización reducen el presupuesto del proyecto baja catastrófico
Imposible contratar personal con los conocimientos requeridos alta catastrófico
Personal clave enfermo o no disponible en momentos críticos moderada Crítica
Cambios de requerimientos que precisan modificaciones en la codificación moderada Crítica
El tiempo requerido para desarrollar el proceso de IR está subestimado alta Crítica
Los clientes no comprenden el impacto de los cambios en los requerimientos moderada Marginal
No en la duración del proyecto
No aplica, ya se cuenta con el personal
Se ajustaran las tareas y tiempo para seguir con el procedimiento
Se analizaran si proceden y cotejaran estimaciones de tiempo, costo, salida a producción
Involucrar a mas personal en la tarea de análisis
Se tratara de aclarar el impacto de los cambios a los requerimientos originales
Tipo de riesgo Indicadores potenciales
Tecnología Entrega retrasada del hardware. Existencia de informes sobre problemas tecnológicos.
Personal Baja moral del personal, malas relaciones entre miembros del equipo, plazas vacantes,
Organizacional Rumores. Falta de iniciativa de la dirección.
Herramientas Rechazo de los miembros del equipo a utilizar herramientas. Quejas sobre las CASE
Requisitos Peticiones de muchos cambios en los requisitos. Quejas del cliente
Estimación Fracaso en el cumplimiento de los tiempos planificados.

Anuncios

Un comentario en “Gestión de Proyectos de Software

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s