Las 4 P's de PRESSMAN

Inicialmente eran 3, luego se agregó la cuarta

• Personal: Altamente calificado.
• Producto: Establecer objetivos y ámbito de cada objetivo.

Ejemplo: En la primer etapa del ciclo de vida de esta metodología de sistemas consistente en la ingeniería de software, o sea PESI (planeamiento estratégico de los sistemas de información), el alcance es la organización en su totalidad y el objetivo es la creación de una estrategia en sistemas, alinear los sistemas al contexto de la organización. En la siguiente etapa ANÁLISIS, el alcance es por áreas o sectores (divisional, seccional, funcional, geográfico o por unidades de producto) y el objetivo es la generación de un bosquejo con todos los requerimientos del usuario a considerar en el diseño.

En el DISEÑO, el alcance es la aplicación propiamente dicha y el objetivo es generar una foto, que contemple las especificaciones del bosquejo alcanzado en la etapa anterior. Luego del diseño no deben generarse sorpresas, si en la codificación surge la necesidad de tomar alguna decisión significa que no se realizó un diseño adecuado.

Se tiene que especificar lo más completo posible para que el desarrollador lo comprenda y la generación de código sea automática o semi-automáticas mediante las herramientas CASE (Ingeniería de Software asistido por computadora). Se reduce el esfuerzo en programación que antes de esta metodología implicaba un 80%.

Establece también soluciones alternativas, restricciones técnicas y de gestión (presupuesto/tiempos)

Lo más caro en un proyecto informático integral es el software. Inicialmente el mayor costo correspondía al HW, que ahora cambia salvo proyectos excepcionales. El desarrollo de software es una empresa humana, hasta ahora no hay pc 's que se programan solas.

Existen diferentes dificultades para conseguir recursos humanos. Costo en SAP (u otros enlatados) en la adaptación a las necesidades de la empresa (customización).

Puede ser una gran noticia (sobredemanda).

Por cada ingreso en el país queda más de lo que se va.

Existe distintas dificultades a la hora de conseguir RRHH:

• Es difícil conseguir personal altamente capacitado.
• Es difícil capacitar al personal.
• Es difícil desarrollar, motivar, organizar y mantener la fuerza de trabajo.
• Es difícil reemplazar personal. Al reemplazar uno por otro con iguales condiciones (sin importar si es mejor o peor) pasa el tiempo.
• Es difícil disponer de recursos a tiempo y forma.

Ley de rendimientos decrecientes

David Ricardo en economía agraria. Se aplica a la construcción de software. Los beneficios que genera la adición de un programador adicional se reduce y llegado a un momento genera pérdidas.

La solución no es incorporar un programador más, por ahí la incorporación de un cuarto programador hace que todo ande.

ESTIMACIÓN:

Estimar qué recursos vamos a emplear en el proyecto, cuándo se necesitarán y por cuánto tiempo. Se realiza esta tarea al momento cero.

Recursos de software (licencia), hardware, humanos.

PROYECTO

Ambientales y de entorno (HW y oficina)

RRHH

• Cuantas personas
• Habilidades
• Ubicación (teletrabajo, trabajo a distancia).

HW Y REDES

Alquiler o compra de espacio físico (costos directos tipo electricidad que son insignificantes, no cuentan para el proyecto).

RECURSOS DE software REUTILIZABLES

Compra de una rutina, en vez de hacerlo lo compro.

Experiencia completa: Desarrollo completo

Experiencia parcial: Customizo

Componentes nuevos

La estimación es más un arte que una ciencia, y es muy difícil realizar una adecuada estimación.

Afectada por:

• Complejidad (no es lo mismo estimar lo que ya hice).
• Tamaño (no es lo mismo un software chico que uno grande).
• Riesgos (la mejor estimación tiene riesgos ej. Enfermedad de un programador).
• Información histórica: Asimila la experiencia. Si tengo información histórica y además sistemática y disponible entonces podré estimar mejor.
• Ley de Murphy.

Claves:

1. Cuando más adelante se haga la estimación, más certera será. Ej: Estoy en casa ¿voy a tardar?
2. Descomponer el proyecto en partes facilita la estimación.
3. Aunque es difícil puede desarrollarse un modelo empírico de cálculo de costos y esfuerzo.

La mejor estimación es la que se hace al final, además es la más inútil.

Generalmente, se pospone la estimación hasta contar con más información.

No presupuestar todo el sistema pero sí partes. Cómo es diferente el mercado de la informática => no se usa esto (descomposición).

Descomponer un proyecto en partes para hacer la estimación más entera. 2 formas:

• Basada en el proceso: Descompone en funciones de los procesos: análisis, diseño.
• Basada en problemas: Descompone en funciones de los procesos en función de los problemas que va a atacar (Ej: ABM, listados, por problemas).

Modelo COCOMO II (COnstructive COst MOdel)

Desventaja: Se basa en líneas de código

CALENDARIZACIÓN:

Poner esas estimaciones en un calendario, ponerle fecha. Busco mantener el software dentro de los plazos previstos.

Problemas:

• Fechas irreales o establecidas externamente. Deberían surgir de la estimación, no de afuera.
• Requerimientos variables del cliente.
• Subestimación de la complejidad (honesta), sin ser un chanta que estimó cualquier cosa.
• Riesgos varios.
• Problemas humanos no previsibles (enfermedades).
• Faltas o fallas en la comunicación.
• Falla en la administración de retrasos.

Habilidad, experiencia, pericia, utilización de herramientas (ej. Hs. Project) de quien lleva a cabo el proyecto son decisivas, a la hora de cumplir en tiempo y forma con lo pautado.

Utilización de herramientas de calendarización, que colaboren en la tarea.

Se encarga el PM (Project Manager/ Líder de Proyecto)

PLAN DE PROYECTO

Ojo con las fechas fijadas por fuera. Pero una fecha clave es fin de mes, para los pagos (le tengo que presentar la factura, y para ello necesito XXX ) .

PERT -> Fecha de finalización

Facilidad para ver el camino crítico (en rojo).

GANTT: Actividades vistas en un calendario.

Facilidad para ver las fechas del proyecto.

El seguimiento del calendario implica:

-Reuniones periódicas vinculadas con el estado y avance del proyecto.

-Comparar fechas reales con las previstas.

-Evaluar resultados con revisiones efectuadas.

-Controlar el logro de los hitos formales del proyecto.

-Reuniones y contratos formales para conocer el grado de avance.

-Utilizar técnicas de seguimiento y control.

Valor ganado: Estimó en función de lo que ya hice. Ej: Tiempo de un viaje en colectivo.

Mido cada proyecto en base a la experiencia sobre el mismo proyecto (si cada tarea me lleva tanto tiempo entonces las demás…).

-Ser prudentes, hábiles en realizar esto.

-Avisar siempre que no se llega (dar alternativas). Ppio. de prudencia. Renegociar plazos. Ej: llego tarde => avisar con tiempo.

DECISIÓN: Desarrollar internamente vs. Comprar

¿Qué puede comprarse?

El software ya está desarrollado.

1. Componentes ya desarrollados.
2. Desarrollo a medida contratado a un tercero.

¿Qué debe evaluarse?

1. ¿Qué porcentaje de mi operatoria cubre el sistema ya desarrollado?
2. Puede ser cambiado o modificado en el futuro?
3. ¿El plazo de entrega es menor al desarrollo interno? (ver cuánto tarda la entrega de desarrollo).
4. ¿El costo será menor que un desarrollo?
5. Cuánto sale el soporte?
6. Existen costos ocultos o futuros? Si por ejemplo el costo del cambio es muy elevado por la implementación, entonces habrá un cambio radical de toda la infraestructura.

Solución

1. Desarrollo
2. Paquete
3. Outsourcing (total o parcial).

Ventajas de 3)

• Ahorro de costos en desarrollo.
• Menos personal.
• Menor instalación de HW.
• Mantener la copia en la nube.

Desventajas

• El cliente puede perder el control del sistema.
• Datos críticos en manos de un tercero (en empresas con grandes exigencias de privacidad y seguridad de datos).
• La vuelta atrás no siempre es posible.

Ver ejemplo de la empresa de transporte que en el 2000 revierte el proceso mediante el outsourcing.

Consecuencia: Pérdida de ventajas competitivas de los outsourcers.

Outsourcing en la nube.